RE: [PATCH v2 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver
Hi,
On Wednesday, October 01, 2014 7:23 PM Guenter Roeck wrote:
> On 10/01/2014 04:36 AM, Pankaj Dubey wrote:
> > Let's register reboot_notifier from PMU driver for reboot
> > functionality. So that we can remove restart hooks from machine
> > specific file, and thus moving ahead when PMU moved to driver folder,
> > this functionality can be reused for ARM64 based Exynos SoC's.
> >
> > Signed-off-by: Pankaj Dubey
> > ---
> > arch/arm/mach-exynos/common.h |1 -
> > arch/arm/mach-exynos/exynos.c |6 --
> > arch/arm/mach-exynos/pmu.c| 25
> +
> > 3 files changed, 25 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/common.h
> > b/arch/arm/mach-exynos/common.h index 431be1b..865f878 100644
> > --- a/arch/arm/mach-exynos/common.h
> > +++ b/arch/arm/mach-exynos/common.h
> > @@ -12,7 +12,6 @@
> > #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
> > #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
> >
> > -#include
> > #include
> >
> > #define EXYNOS3250_SOC_ID 0xE3472000
> > diff --git a/arch/arm/mach-exynos/exynos.c
> > b/arch/arm/mach-exynos/exynos.c index aa394cb..3aa75b8e 100644
> > --- a/arch/arm/mach-exynos/exynos.c
> > +++ b/arch/arm/mach-exynos/exynos.c
> > @@ -137,11 +137,6 @@ static struct map_desc exynos5_iodesc[] __initdata
= {
> > },
> > };
> >
> > -static void exynos_restart(enum reboot_mode mode, const char *cmd) -{
> > - __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET);
> > -}
> > -
> > static struct platform_device exynos_cpuidle = {
> > .name = "exynos_cpuidle",
> > #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
> > @@ -365,7 +360,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG
> EXYNOS (Flattened Device Tree)")
> > .init_machine = exynos_dt_machine_init,
> > .init_late = exynos_init_late,
> > .dt_compat = exynos_dt_compat,
> > - .restart= exynos_restart,
> > .reserve= exynos_reserve,
> > .dt_fixup = exynos_dt_fixup,
> > MACHINE_END
> > diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> > index 1993e08..c0855a5 100644
> > --- a/arch/arm/mach-exynos/pmu.c
> > +++ b/arch/arm/mach-exynos/pmu.c
> > @@ -11,7 +11,10 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > +#include
> >
> > #include "exynos-pmu.h"
> > #include "regs-pmu.h"
> > @@ -439,6 +442,15 @@ static void exynos5250_pmu_init(void)
> > pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
> > }
> >
> > +static int pmu_reboot_notify_handler(struct notifier_block *this,
> > + unsigned long code, void *unused)
> > +{
> > + if (code == SYS_RESTART)
> > + pmu_raw_writel(0x1, EXYNOS_SWRESET);
> > +
> > + return NOTIFY_DONE;
> > +}
> > +
> > static const struct exynos_pmu_data exynos4210_pmu_data = {
> > .pmu_config = exynos4210_pmu_config,
> > };
> > @@ -478,11 +490,20 @@ static const struct of_device_id
> exynos_pmu_of_device_ids[] = {
> > { /*sentinel*/ },
> > };
> >
> > +/*
> > + * Exynos PMU reboot notifier, handles reboot functionality */
> > +static struct notifier_block pmu_reboot_notifier = {
> > + .notifier_call = pmu_reboot_notify_handler,
> > + .priority = 128,
> > +};
> > +
> > static int exynos_pmu_probe(struct platform_device *pdev)
> > {
> > const struct of_device_id *match;
> > struct device *dev = &pdev->dev;
> > struct resource *res;
> > + int ret;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pmu_base_addr = devm_ioremap_resource(dev, res); @@ -507,6 +528,10
> > @@ static int exynos_pmu_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, pmu_context);
> >
> > + ret = register_reboot_notifier(&pmu_reboot_notifier);
> > + if (ret)
> > + dev_err(dev, "can't register reboot notifier err=%d\n",
ret);
> > +
> > dev_dbg(dev, "Exynos PMU Driver probe done\n");
> > return 0;
> > }
> >
>
> Something went wrong here.
>
> You don't want to register with reboot_notifier, but with
restart_notifier.
> The code is not SYS_RESTART, but the value of reboot_mode.
>
> The same applies to the other patch as well.
>
Yes, you are right. Thanks for review and pointing out this.
Originally restart hooks of Exynos machine_desc are getting called from
machine_restart,
so I should have registered restart_notifier. Somehow I missed this part. I
will update both patches shortly.
Thanks,
Pankaj Dubey
> Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
Tomasz Figa wrote: > > On 30.09.2014 17:12, Abhilash Kesavan wrote: > > Hi Tomasz, > > > > On Mon, Sep 22, 2014 at 2:22 PM, Tomasz Figa wrote: > >> Hi Abhilash, > >> > >> On 22.09.2014 06:47, Abhilash Kesavan wrote: > >>> Changes since v4: > >>> - Fixed comments from Tomasz Figa: > >>> - Changed the namespace prefix from exynos to samsung > >>> - Defined bindings to take all input clocks > >>> - Sorted the Kconfig entries alphabetically in clock Makefile > >>> - Used consistent 1 tab line breaks across the clock file > >>> - Statically initialized the samsung_cmu_info struct > >>> - Enabled exynos7 in the arm64 defconfig as per Catalin Marinas' comment. > >>> - Added Kukjin Kim's ack along with Thomas Abraham's tested and reviewed > >>> tags. > >>> > >> > >> The clock patches look good to me, but since they are doing quite a lot > >> of code moving I'd prefer to take them through clk tree. Based on the > >> fact that there are no code dependencies between clock patches and > >> remaining ones and Exynos7 is a new material for 3.18, I'm inclined to > >> apply them to my tree if nobody minds. > > > > Will you be picking up the clock changes soon ? > > I'd like to do so. Kukjin, since clock changes are a part of this > series, might I have your Ack for them to be applied separately? > Sure, I'm fine so please go ahead with my ack on the changes. Acked-by: Kukjin Kim Thanks for your asking. - 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 0/2] ARM: Exynos: Convert PMU implementation into a platform driver
Pankaj Dubey wrote: > > This patch series, modifies Exynos Power Management Unit (PMU) related code > for converting it into a platform_driver. This is also preparation for moving > PMU related code out of machine folder into a either "drivers/mfd", or > "drivers/power" or some other suitable place so that ARM64 based SoC can > utilize common piece of code. > > These patches are created on top of Kukjin Kim's for-next. > > Vikas Sajjan have tested these patches on Exynos5420 based Peach board for > system boot and S2R. > > This patch series depends on following patch series: > [1]: mfd: syscon: Decouple syscon interface from syscon devices. > https://lkml.org/lkml/2014/9/30/156 > > Patch v8 and discussion can be found here: > http://www.spinics.net/lists/arm-kernel/msg366831.html > > Change since v8: > - Changed __raw_readl/writel into readl/writel_relaxed as suggested by Arnd. > > Change since v7: > - Removing registration of syscon provider. As it will be handled now by >syscon patch [1]. > - Rebased on top of latest kgene/for-next. > > Change since v6: > - Removed NULL check for pmu_data in pmu.c. > - Moved pmu_raw_readl and pmu_raw_writel inline helper function >into common.h. > > Change Since v5: > - Squashed patch "Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c" >into patch "Refactored code for using PMU address via DT". > - Addressed review comments from Tomasz Figa. > - Using init_irq machine function to initialize PMU mapping instead >of init_time. > - Rebased on latest Kukjin Kim's for-next branch. > > Changes Since v4: > - Splitted patch series in two parts. Part 1 has code cleanup under > mach-exynos >and posted as separate patch [2]. Current patchset is part 2 which modified >exynos pmu implementation for making it platform driver. > - Removed dependency over early_syscon API. > - Removed usage of regmap read/write APIs. > - Modified probe function to register exynos pmu as syscon provider using >Tomasz Figa's syscon patch [1]. > - Address various other review comments from Tomasz Figa. > - Removed signed-off-by of Young-Gun Jang , >as this id is no more valid. Taking ownership of all his patches. > > Changes Since v3: > - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init >as suggested by Vikas Sajjan. > - Modified syscon_early_regmap_lookup_by_phandle and >syscon_regmap_lookup_by_phandle function call to pass property as NULL. > > Changes Since v2: > - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. > - Removed early mapping of PMU base address from exynos.c and removed >"get_exynos_pmuaddr" function. Instead of this added code in platsmp.c >to get PMU base address using of_iomap as suggested by Tomasz Figa. > - Converted PMU implementation into platform_driver by using static >platform_device method. > > Changes Since v1: > - Rebased on latest for-next of Kukjin Kim's tree. > - Updated patch: Add support for mapping PMU base address via DT > - Removed __initdata from declaration of "exynos_pmu_base", as it caused > kernel crash as pointed out by Vikas Sajjan. > - Added support for Syscon initialization and getting PMU regmap handle > as suggested by Sylwester. Since current implementation of early > intialization [1] has limitation that "early_syscon_init" requires > DT to be unflattened and system should be able to allocate memory, > we can't use regmap handles for platsmp.c file as "smp_secondary_init" > will be called before DT unflattening. So I have kept both method for > accessing PMU base address. platsmp.c will use ioremmaped address where > as rest other files can use regmap handle. > - Updated patch: Refactored code for PMU register mapping via DT > - Modified to use regmap_read/write when using regmap handle. > - Added patch: Add device tree based initialization support for PMU. > - Convert existing PMU implementation to be a device tree based >before moving it to "drivers/mfd" folder. As suggested by Bartlomiej. > - Dropped making a platform_driver for PMU, as currently PMU binding > has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", > once we enable MFD_SYSCON config option, current "syscon" driver probe > gets called and PMU probe never gets called. So modified PMU > initialization code to scan DT and match against supported compatiblity > string in driver code, and once we get matching node use that for > accessing PMU regmap handle using > "syscon_early_regmap_lookup_by_phandle". > If there is any better solution please suggest. > > > Pankaj Dubey (2): > ARM: EXYNOS: Add platform driver support for Exynos PMU > ARM: EXYNOS: Move PMU specific definitions from common.h > > arch/arm/mach-exynos/Kconfig |1 + > arch/arm/mach-exynos/common.h | 17 > arch/arm/mach-exyn
RE: [PATCH] ARM: dts: Specify Odroid X2/U3 audio clock parents and rates
Sylwester Nawrocki wrote:
>
> On 10/09/14 16:43, Sylwester Nawrocki wrote:
> > This ensures the core and the audio subsystem clocks are configured
> > properly, as expected by the sound machine driver. These bits are
> > missing to obtain proper audio sample rates in kernel v3.17, where
> > audio support for Odroid X2/U3 was first added.
> >
> > Signed-off-by: Sylwester Nawrocki
> > ---
> > It would be good to have it applied as a fix for v3.17.
>
> Anything happened to this patch ? I can't see it neither in Linus' nor
> -next tree. And we are already at 3.18 merge window.
>
Hi Sylwester,
Sorry about that. I'll queue this one into fixes for -3.18 and stable maybe
+3.17 only if stable-3.17 is available...
Thanks for your gentle reminder.
- Kukjin
> > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-
> common.dtsi
> > index adadaf9..b40f766 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -45,6 +45,16 @@
> > compatible = "samsung,odroidx2-audio";
> > samsung,i2s-controller = <&i2s0>;
> > samsung,audio-codec = <&max98090>;
> > + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> > + <&clock_audss EXYNOS_MOUT_I2S>,
> > + <&clock_audss EXYNOS_DOUT_SRP>,
> > + <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> > + assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
> > + <&clock_audss EXYNOS_MOUT_AUDSS>;
> > + assigned-clock-rates = <0>,
> > + <0>,
> > + <19200>,
> > + <1920>;
> > };
> >
> > mmc@1255 {
> > --
> > 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] usb: Remove references to non-existent PLAT_S5P symbol
On Tuesday, October 07, 2014 12:47 AM, Sylwester Nawrocki wrote:
>
> The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
> ("ARM: SAMSUNG: Remove remaining legacy code"). There are still
> some references left, fix that by replacing them with ARCH_S5PV210.
>
> Reported-by: Paul Bolle
> Signed-off-by: Sylwester Nawrocki
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/usb/host/Kconfig |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 82800a7..6f1d48e 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -220,7 +220,7 @@ config USB_EHCI_SH
>
> config USB_EHCI_EXYNOS
> tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
> - depends on PLAT_S5P || ARCH_EXYNOS
> + depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
> Enable support for the Samsung Exynos SOC's on-chip EHCI controller.
>
> @@ -527,7 +527,7 @@ config USB_OHCI_SH
>
> config USB_OHCI_EXYNOS
> tristate "OHCI support for Samsung S5P/EXYNOS SoC Series"
> - depends on PLAT_S5P || ARCH_EXYNOS
> + depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
>Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
>
> --
> 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] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board
Bartlomiej, On Thu, Oct 2, 2014 at 10:24 AM, Bartlomiej Zolnierkiewicz 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 >> 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 >> >> 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 >> >> > Cc: Yuvaraj Kumar C D >> >> > Cc: Ulf Hansson >> >> > Signed-off-by: Bartlomiej Zolnierkiewicz >> >> > Acked-by: Kyungmin Park >> >> > --- >> >> > 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? -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] ARM: dts: Specify Odroid X2/U3 audio clock parents and rates
On 10/09/14 16:43, Sylwester Nawrocki wrote:
> This ensures the core and the audio subsystem clocks are configured
> properly, as expected by the sound machine driver. These bits are
> missing to obtain proper audio sample rates in kernel v3.17, where
> audio support for Odroid X2/U3 was first added.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> It would be good to have it applied as a fix for v3.17.
Anything happened to this patch ? I can't see it neither in Linus' nor
-next tree. And we are already at 3.18 merge window.
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index adadaf9..b40f766 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -45,6 +45,16 @@
> compatible = "samsung,odroidx2-audio";
> samsung,i2s-controller = <&i2s0>;
> samsung,audio-codec = <&max98090>;
> + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> + <&clock_audss EXYNOS_MOUT_I2S>,
> + <&clock_audss EXYNOS_DOUT_SRP>,
> + <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> + assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
> + <&clock_audss EXYNOS_MOUT_AUDSS>;
> + assigned-clock-rates = <0>,
> + <0>,
> + <19200>,
> + <1920>;
> };
>
> mmc@1255 {
> --
> 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] usb: Remove references to non-existent PLAT_S5P symbol
On Mon, 2014-10-06 at 17:47 +0200, Sylwester Nawrocki wrote:
> The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
> ("ARM: SAMSUNG: Remove remaining legacy code"). There are still
> some references left, fix that by replacing them with ARCH_S5PV210.
>
> Reported-by: Paul Bolle
> Signed-off-by: Sylwester Nawrocki
As with the "[media]" patch: should
Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
be added so this will end up in stable for v3.17?
> drivers/usb/host/Kconfig |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 82800a7..6f1d48e 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -220,7 +220,7 @@ config USB_EHCI_SH
>
> config USB_EHCI_EXYNOS
> tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
> - depends on PLAT_S5P || ARCH_EXYNOS
> + depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
> Enable support for the Samsung Exynos SOC's on-chip EHCI controller.
>
> @@ -527,7 +527,7 @@ config USB_OHCI_SH
>
> config USB_OHCI_EXYNOS
> tristate "OHCI support for Samsung S5P/EXYNOS SoC Series"
> - depends on PLAT_S5P || ARCH_EXYNOS
> + depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
>Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
>
Thanks again!
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-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] [media] Remove references to non-existent PLAT_S5P symbol
On Mon, 2014-10-06 at 18:10 +0200, Sylwester Nawrocki wrote:
> The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
> ("ARM: SAMSUNG: Remove remaining legacy code"). However, there
> are still some references to that symbol left, fix that by
> substituting them with ARCH_S5PV210.
>
> Reported-by: Paul Bolle
> Signed-off-by: Sylwester Nawrocki
Thanks for picking this up!
Should
Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
be added so this will end up in stable for v3.17?
> drivers/media/platform/Kconfig|6 +++---
> drivers/media/platform/exynos4-is/Kconfig |2 +-
> drivers/media/platform/s5p-tv/Kconfig |2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index bee9074..3aac88f 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
> config VIDEO_SAMSUNG_S5P_G2D
> tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
> depends on VIDEO_DEV && VIDEO_V4L2
> - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
> + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> depends on HAS_DMA
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> @@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
> config VIDEO_SAMSUNG_S5P_JPEG
> tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
> depends on VIDEO_DEV && VIDEO_V4L2
> - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
> + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> depends on HAS_DMA
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> @@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
> config VIDEO_SAMSUNG_S5P_MFC
> tristate "Samsung S5P MFC Video Codec"
> depends on VIDEO_DEV && VIDEO_V4L2
> - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
> + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> depends on HAS_DMA
> select VIDEOBUF2_DMA_CONTIG
> default n
> diff --git a/drivers/media/platform/exynos4-is/Kconfig
> b/drivers/media/platform/exynos4-is/Kconfig
> index 77c9512..b7b2e47 100644
> --- a/drivers/media/platform/exynos4-is/Kconfig
> +++ b/drivers/media/platform/exynos4-is/Kconfig
> @@ -2,7 +2,7 @@
> config VIDEO_SAMSUNG_EXYNOS4_IS
> bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
> depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
> + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> depends on OF && COMMON_CLK
> help
> Say Y here to enable camera host interface devices for
> diff --git a/drivers/media/platform/s5p-tv/Kconfig
> b/drivers/media/platform/s5p-tv/Kconfig
> index a9d56f8..beb180e 100644
> --- a/drivers/media/platform/s5p-tv/Kconfig
> +++ b/drivers/media/platform/s5p-tv/Kconfig
> @@ -9,7 +9,7 @@
> config VIDEO_SAMSUNG_S5P_TV
> bool "Samsung TV driver for S5P platform"
> depends on PM_RUNTIME
> - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
> + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> default n
> ---help---
> Say Y here to enable selecting the TV output devices for
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v7] mfd: syscon: Decouple syscon interface from platform devices
On Mon, 06 Oct 2014, Pankaj Dubey wrote: > Hi Lee, > > On Tuesday, September 30, 2014 9:39 PM Doug Anderson wrote, > > Subject: Re: [PATCH v7] mfd: syscon: Decouple syscon interface from platform > > devices > > > > Pankaj, > > > > On Tue, Sep 30, 2014 at 1:35 AM, Pankaj Dubey > > wrote: > > > Currently a syscon entity can be only registered directly through a > > > platform device that binds to a dedicated syscon driver. However in > > > certain use cases it is desirable to make a device used with another > > > driver a syscon interface provider. > > > > > > For example, certain SoCs (e.g. Exynos) contain system controller > > > blocks which perform various functions such as power domain control, > > > CPU power management, low power mode control, but in addition contain > > > certain IP integration glue, such as various signal masks, coprocessor > > > power control, etc. In such case, there is a need to have a dedicated > > > driver for such system controller but also share registers with other > > > drivers. The latter is where the syscon interface is helpful. > > > > > > In case of DT based platforms, this patch decouples syscon object from > > > syscon platform driver, and allows to create syscon objects first time > > > when it is required by calling of syscon_regmap_lookup_by APIs and > > > keep a list of such syscon objects along with syscon provider > > > device_nodes and regmap handles. > > > > > > For non-DT based platforms, this patch keeps syscon platform driver > > > structure so that syscon can be probed and such non-DT based drivers > > > can use syscon_regmap_lookup_by_pdev API and access regmap handles. > > > Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based, > > > we can completely remove platform driver of syscon, and keep only > > > helper functions to get regmap handles. > > > > > > Suggested-by: Arnd Bergmann > > > Suggested-by: Tomasz Figa > > > Tested-by: Vivek Gautam > > > Tested-by: Javier Martinez Canillas > > > Signed-off-by: Pankaj Dubey > > > Reviewed-by: Arnd Bergmann > > > Tested-by: Heiko Stuebner > > > Reviewed-by: Heiko Stuebner > > > --- > > > Patch v6 and related discussions can be found here [1]. > > > > > > Change since v5: > > > - Addressed review comments from "Heiko Stuebner". > > > - Updated commit description. > > > - Including Arnd's and Heiko's Reviewed-by. > > > > > > Change since v5: > > > - Dropping creation of dummy platform device in of_syscon_register. > > > - As we are changing syscon to decouple from platform_device, creation of > > >dummy platform_device does not look good option, and as suggested by > > > Arnd, > > >I made another attempt so that regmap_mmio_init API should work with > > > NULL > > >dev pointer itself. Since regmap needs to know about Syscon device node > > >properties so let's parse device node of syscon in syscon itself for > > > any > > >such properties and using regmap_config parameter pass all such > > > information > > >to regmap. Other concern of crashes due to NULL dev pointer in regmap > > > already > > >addressed in separate patches of regmap. Please see [2] and [3]. > > > > > > Changes since v4: > > > - Addressed Tomasz Figa's comments for v4. > > > - Added error handing in of_syscon_register function. > > > - Using devm_regmap_init_mmio instead of regmap_init_mmio. > > > > > > Changes since v3: > > > - Addressed Arnd's comment for v2. > > > - Updated of_syscon_register for adding dev pointer in regmap_init_mmio. > > > - For early users created dummy platform device. > > > > > > Changes since v2: > > > - Added back platform device support from syscon, with one change that > > >syscon will not be probed for DT based platform. > > > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base > > >users of syscon will not be broken. > > > - Removed unwanted change in syscon.h. > > > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and > > >Arnd Bergmann. > > > - Added Tested-by of Vivek Gautam for testing on Exynos platform. > > > > > > Changes since v1: > > > - Removed of_syscon_unregister function. > > > - Modified of_syscon_register function and it will be used by syscon.c > > >to create syscon objects whenever required. > > > - Removed platform device support from syscon. > > > - Removed syscon_regmap_lookup_by_pdevname API support. > > > - As there are significant changes w.r.t patchset v1, I am taking over > > >author for this patchset from Tomasz Figa. > > > > > > [1]: https://lkml.org/lkml/2014/9/29/99 > > > [2]: https://lkml.org/lkml/2014/9/18/130 > > > [3]: https://lkml.org/lkml/2014/9/27/2 > > > drivers/mfd/syscon.c | 96 > > ++ > > > 1 file changed, 74 insertions(+), 22 deletions(-) > > > > You probably already have enough tags, but just in case. ;) On an > > rk3288-based > > system (this patch backported to 3.14): > > > > Teste
[PATCH v2] [media] Remove references to non-existent PLAT_S5P symbol
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). However, there
are still some references to that symbol left, fix that by
substituting them with ARCH_S5PV210.
Reported-by: Paul Bolle
Signed-off-by: Sylwester Nawrocki
---
drivers/media/platform/Kconfig|6 +++---
drivers/media/platform/exynos4-is/Kconfig |2 +-
drivers/media/platform/s5p-tv/Kconfig |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index bee9074..3aac88f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
config VIDEO_SAMSUNG_S5P_JPEG
tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
config VIDEO_SAMSUNG_S5P_MFC
tristate "Samsung S5P MFC Video Codec"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 77c9512..b7b2e47 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on OF && COMMON_CLK
help
Say Y here to enable camera host interface devices for
diff --git a/drivers/media/platform/s5p-tv/Kconfig
b/drivers/media/platform/s5p-tv/Kconfig
index a9d56f8..beb180e 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -9,7 +9,7 @@
config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform"
depends on PM_RUNTIME
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
default n
---help---
Say Y here to enable selecting the TV output devices for
--
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] [media] Remove references to non-existent PLAT_S5P symbol
On 06/10/14 17:52, Tomasz Figa wrote: > On 06.10.2014 17:39, Sylwester Nawrocki wrote: >> diff --git a/drivers/media/platform/exynos4-is/Kconfig >> b/drivers/media/platform/exynos4-is/Kconfig >> index 77c9512..b3b270a 100644 >> --- a/drivers/media/platform/exynos4-is/Kconfig >> +++ b/drivers/media/platform/exynos4-is/Kconfig >> @@ -2,7 +2,7 @@ >> config VIDEO_SAMSUNG_EXYNOS4_IS >> bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver" >> depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> -depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) >> +depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST >> depends on OF && COMMON_CLK >> help >>Say Y here to enable camera host interface devices for >> @@ -57,7 +57,7 @@ endif >> >> config VIDEO_EXYNOS4_FIMC_IS >> tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver" >> -depends on HAS_DMA >> +depends on HAS_DMA && !ARCH_S5PV210 > > Hmm, does this change really do the intended thing? > > Since both S5PV210 and Exynos are multiplatform-aware, now whenever > ARCH_S5PV210 is enabled, it isn't possible to enable > VIDEO_EXYNOS4_FIMC_IS, even though ARCH_EXYNOS can be enabled as well at > the same time. Sorry, I missed S5PV210 supports ARCH_MULTIPLATFORM, let me resend with that line removed. Thanks for pointing out. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-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] [media] Remove references to non-existent PLAT_S5P symbol
On 06.10.2014 17:39, Sylwester Nawrocki wrote: > diff --git a/drivers/media/platform/exynos4-is/Kconfig > b/drivers/media/platform/exynos4-is/Kconfig > index 77c9512..b3b270a 100644 > --- a/drivers/media/platform/exynos4-is/Kconfig > +++ b/drivers/media/platform/exynos4-is/Kconfig > @@ -2,7 +2,7 @@ > config VIDEO_SAMSUNG_EXYNOS4_IS > bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver" > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) > + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST > depends on OF && COMMON_CLK > help > Say Y here to enable camera host interface devices for > @@ -57,7 +57,7 @@ endif > > config VIDEO_EXYNOS4_FIMC_IS > tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver" > - depends on HAS_DMA > + depends on HAS_DMA && !ARCH_S5PV210 Hmm, does this change really do the intended thing? Since both S5PV210 and Exynos are multiplatform-aware, now whenever ARCH_S5PV210 is enabled, it isn't possible to enable VIDEO_EXYNOS4_FIMC_IS, even though ARCH_EXYNOS can be enabled as well at the same time. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: Remove references to non-existent PLAT_S5P symbol
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). There are still
some references left, fix that by replacing them with ARCH_S5PV210.
Reported-by: Paul Bolle
Signed-off-by: Sylwester Nawrocki
---
drivers/usb/host/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..6f1d48e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -220,7 +220,7 @@ config USB_EHCI_SH
config USB_EHCI_EXYNOS
tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
- depends on PLAT_S5P || ARCH_EXYNOS
+ depends on ARCH_S5PV210 || ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip EHCI controller.
@@ -527,7 +527,7 @@ config USB_OHCI_SH
config USB_OHCI_EXYNOS
tristate "OHCI support for Samsung S5P/EXYNOS SoC Series"
- depends on PLAT_S5P || ARCH_EXYNOS
+ depends on ARCH_S5PV210 || ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
--
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
[PATCH] [media] Remove references to non-existent PLAT_S5P symbol
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). However, there
are still some references to that symbol left, fix that by
substituting them with ARCH_S5PV210.
Reported-by: Paul Bolle
Signed-off-by: Sylwester Nawrocki
---
drivers/media/platform/Kconfig|6 +++---
drivers/media/platform/exynos4-is/Kconfig |4 ++--
drivers/media/platform/s5p-tv/Kconfig |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index bee9074..3aac88f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
config VIDEO_SAMSUNG_S5P_JPEG
tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
config VIDEO_SAMSUNG_S5P_MFC
tristate "Samsung S5P MFC Video Codec"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 77c9512..b3b270a 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on OF && COMMON_CLK
help
Say Y here to enable camera host interface devices for
@@ -57,7 +57,7 @@ endif
config VIDEO_EXYNOS4_FIMC_IS
tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
- depends on HAS_DMA
+ depends on HAS_DMA && !ARCH_S5PV210
select VIDEOBUF2_DMA_CONTIG
depends on OF
select FW_LOADER
diff --git a/drivers/media/platform/s5p-tv/Kconfig
b/drivers/media/platform/s5p-tv/Kconfig
index a9d56f8..beb180e 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -9,7 +9,7 @@
config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform"
depends on PM_RUNTIME
- depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+ depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
default n
---help---
Say Y here to enable selecting the TV output devices for
--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
On Wednesday 24 September 2014 11:42:06 Tomi Valkeinen wrote:
> On 23/09/14 17:45, Thierry Reding wrote:
> > On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
> >> On 23/09/14 12:39, Thierry Reding wrote:
> >>> My point is that if you use plain phandles you usually have the
> >>> meta-data already. Referring to the above example, bridge0 knows that it
> >>> should look for a bridge with phandle &bridge1, whereas bridge1 knows
> >>> that the device it is connected to is a panel.
> >>
> >> The bridge should not care what kind of device is there on the other
> >> end. The bridge just has an output, going to another video component.
> >
> > You'll need to know at some point that one of the devices in a panel,
> > otherwise you can't treat it like a panel.
>
> The bridge doesn't need to treat it like a panel. Someone else might,
> though. But the panel driver knows it is a panel, and can thus register
> needed services, or mark itself as a panel.
>
> Well, I can't say about this particular bridge, but afaik you can
> connect a parallel RGB signal to multiple panels just like that,
> without any muxing.
> >>>
> >>> Right, but in that case you're not reconfiguring the signal in any way
> >>> for each of the panels. You send one single signal to all of them. For
> >>
> >> Yes, that's one use case, cloning. But I was not talking about that.
> >>
> >>> all intents and purposes there is only one panel. Well, I guess you
> >>> could have separate backlights for the panels. In that case though it
> >>> seems better to represent it at least as a virtual mux or bridge, or
> >>> perhaps a "mux panel".
> >>
> >> I was talking about the case where you have two totally different
> >> devices, let's say panels, connected to the same output. One could take
> >> a 16-bit parallel RGB signal, the other 24-bit. Only one of them can be
> >> enabled at a time (from HW perspective both can be enabled at the same
> >> time, but then the other one shows garbage).
> >
> > So we're essentially back to a mux, albeit maybe a virtual one.
>
> Yes. Are you suggesting to model virtual hardware in .dts? I got the
> impression that you wanted to model only the real hardware in .dts =).
>
> But seriously speaking, I was thinking about this. I'd really like to
> have a generic video-mux node, that would still somehow allow us to have
> device specific configurations for the video sources and sinks (which
> the endpoints provide us), without endpoints.
>
> The reason endpoints don't feel right in this case is that it makes
> sense that the mux has a single input and two outputs, but with
> endpoints we need two endpoints from the bridge (which is still ok), but
> we also need two endpoitns in the mux's input side, which doesn't feel
> right.
>
> I came up with the following. It's quite ugly, though. I hope someone
> has ideas how it could be done in a neater way:
>
> bridge1234 {
> bridge1234-cfg1: config1 {
> high-voltage;
> };
>
> bridge1234-cfg2: config2 {
> low-voltage;
> };
>
> output = <&mux>;
> };
>
> mux: video-gpio-mux {
> gpio = <123>;
>
> outputs = <&panel1 &panel2>;
> input-configs = <&bridge1234-cfg1 &bridge1234-cfg2>;
> };
>
> panel1: panel-foo {
>
> };
>
> panel2: panel-foo {
>
> };
>
> So the bridge node has configuration sets. These might be compared to
> pinmux nodes. And the mux has a list of input-configs. When panel1 is to
> be enabled, "bridge1234-cfg1" config becomes active, and the bridge is
> given this configuration.
>
> I have to say the endpoint system feels cleaner than the above, but
> perhaps it's possible to improve the method above somehow.
Isn't it possible for the bridge to compute its configuration at runtime by
querying properties of the downstream video entities ? That would solve the
problem neatly.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Thierry, On Tuesday 23 September 2014 16:49:38 Thierry Reding wrote: > On Tue, Sep 23, 2014 at 02:52:24PM +0300, Laurent Pinchart wrote: > > On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote: > >> On 09/23/2014 01:23 PM, Laurent Pinchart wrote: > [...] > > >>> This becomes an issue even on Linux when considering video-related > >>> devices that can be part of either a capture pipeline or a display > >>> pipeline. If the link always goes in the data flow direction, then it > >>> will be easy to locate the downstream device (bridge or panel) from > >>> the display controller driver, but it would be much more difficult to > >>> locate the same device from a camera driver as all of a sudden the > >>> device would become an upstream device. > >> > >> Why? > >> > >> If you have graph: > >> sensor --> camera > >> > >> Then camera register itself in some framework as a destination device > >> and sensor looks in this framework for the device identified by remote > >> endpoint. Then sensor tells camera it is connected to it and voila. > > > > Except that both kernelspace and userspace deal with cameras the other way > > around, the master device is the camera receiver, not the camera sensor. > > DRM is architected the same way, with the component that performs DMA > > operations being the master device. > > I don't see what's wrong with having the camera reference the sensor by > phandle instead. That's much more natural in my opinion. The problem, as explained by Tomi in a more recent e-mail (let's thus discuss the issue there) is that making the phandles pointing outwards from the CPU point of view stops working when the same chip or IP core can be used in both a camera and a display pipeline (and we have real use cases for that), or when the CPU isn't involved at all in the pipeline. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi and Thierry, On Monday 06 October 2014 14:34:00 Tomi Valkeinen wrote: > On 25/09/14 09:23, Thierry Reding wrote: > > How are cameras different? The CPU wants to capture video data from the > > camera, so it needs to go look for a video capture device, which in turn > > needs to involve a sensor. > > Let's say we have an XXX-to-YYY encoder. We use that encoder to convert > the SoC's XXX output to YYY, which is then shown on a panel. So, in this > case, the encoder's DT node will have a "panel" or "output" phandle, > pointing to the panel. > > We then use the exact same encoder in a setup in which we have a camera > which outputs XXX, which the encoder then converts to YYY, which is then > captured by the SoC. Here the "output" phandle would point to the SoC. phandles are pretty simple and versatile, which is one of the reasons why they are widely used. The drawback is that they are used to model totally different concepts, which then get mixed in our brains. The DT nodes that make a complete system are related in many different ways. DT has picked one of those relationships, namely the control parent-child relationship, made it special, and arranged the nodes in a tree structure based on those relationships. As Thierry mentioned this make sense given that DT addresses the lack of discoverability from a CPU point of view. As many other relationships between nodes had to be represented in DT phandles got introduced. One of their use cases is to reference resources required by devices, such as GPIOs, clocks and regulators. In those cases the distinction between the resource provider and the resource user is clear. The provider and user roles are clearly identified in the relationship, with the user being the master and the provider being the slave. After those first two classes of relationships (control parent/child and resource provider/user), a need to specify data connections in DT arose. Different models got adopted depending on the subsystems and/or devices, all based on phandles. I believe this use case is different compared to the first two in that it defines connections, not master/slave relationships. The connection doesn't model which entity control or use the other (if any), but how data flows between entities. There is no clear master or slave in that model, different control models can then be implemented in device drivers depending on the use cases, but those are very much implementation details from a DT point of view. The composite device model used for display drivers (and camera drivers for that matter) usually sets all devices on equal footing, and then picks a master (which can be one of the hardware devices, or a virtual logical device) depending on the requirements of the kernel and/or userspace subsystem(s). I thus don't think there's any point in arguing which entity is the resource and which entity is the user in this discussion, as that should be unrelated to the DT bindings. If we need to select a single phandle direction from a hardware description point of view, the only direction that makes sense is one based on the data flow direction. Making phandles always point outwards or inwards from the CPU point of view doesn't make sense, especially when the CPU doesn't get involved as a data point in a media pipeline (think about a connector -> processing -> connector pipeline for instance, where data will be processed by hardware only without going through system memory at any point). Now, we also have to keep in mind that the DT description, while it should model the hardware, also needs to be usable from a software point of view. A hardware model that would precisely describe the system in very convoluted ways wouldn't be very useful. We thus need to select a model that will ease software development, while only describing the hardware and without depending on a particular software implementation. That model should be as simple as possible, but doesn't necessarily need to be the simplest model possible if that would result in many implementation issues. I think the OF graph model is a good candidate here. It is unarguably more complex than a single phandle, but it also makes different software implementations possible while still keeping the DT completely low. > >>> If you go the other way around, how do you detect how things connect? > >>> Where do you get the information about the panel so you can trace back > >>> to the origin? > >> > >> When the panel driver probes, it registers itself as a panel and gets > >> its video source. Similarly a bridge in between gets its video source, > >> which often would be the SoC, i.e. the origin. > > > > That sounds backwards to me. The device tree serves the purpose of > > supplementing missing information that can't be probed if hardware is > > too stupid. I guess that's one of the primary reasons for structuring it > > the way we do, from the CPU point of view, because it allows the
Re: [PATCH 2/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P
On 06/10/14 14:37, Sergei Shtylyov wrote: >> diff --git a/drivers/media/platform/exynos4-is/Kconfig >> b/drivers/media/platform/exynos4-is/Kconfig >> index 77c951237744..775c3278d0eb 100644 >> --- a/drivers/media/platform/exynos4-is/Kconfig >> +++ b/drivers/media/platform/exynos4-is/Kconfig >> @@ -2,7 +2,7 @@ >> config VIDEO_SAMSUNG_EXYNOS4_IS >> bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver" >> depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> -depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) >> +depends on (ARCH_EXYNOS || COMPILE_TEST) > > Perhaps it's time to drop the useless parens? Good point, let me prepare patches to clean that up. -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-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/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P
Hello.
On 10/6/2014 1:08 PM, Paul Bolle wrote:
Commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
removed the Kconfig symbol PLAT_S5P. Remove an optional dependency on
that symbol from this Kconfig file too.
Signed-off-by: Paul Bolle
---
drivers/media/platform/exynos4-is/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 77c951237744..775c3278d0eb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+ depends on (ARCH_EXYNOS || COMPILE_TEST)
Perhaps it's time to drop the useless parens?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hi Javier,
On Mon, Oct 6, 2014 at 5:29 PM, Javier Martinez Canillas
wrote:
> Hello Abhilash,
>
> On Mon, Oct 6, 2014 at 11:08 AM, Abhilash Kesavan
> wrote:
> diff --git a/arch/arm/mach-exynos/platsmp.c
> b/arch/arm/mach-exynos/platsmp.c
> index adb36a8..222aa3c 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
> */
> void exynos_cpu_power_up(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
> +* the SYS_PWR_REG value to decide if we are suspending
> +* the system.
> +*/
> + int val = __raw_readl(pmu_base_addr +
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
> + return;
> + }
> pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
> EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> }
The above block of code should be in exynos_cpu_power_down(). Can you
re-test s2r after modifying it ? I have to convert a __raw_readl to
pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
patch I will re-post a v9.
>>>
>>> Thanks, for the information but unfortunately even after this change I
>>> still have the issue reported in [0]. I also removed the lines from
>>> exynos5420_pm_resume() that you asked Vikash [1].
>>
>> I have just tested this on the 5420 that I have and it resumes fine.
>> The difference could be in the bootloader we are using. I'll send out
>> details of my current setup so that you can cross-check if everything
>> is the same.
>
> Thanks a lot for sending me the patches you are using to test.
>
> But after looking at the differences I noticed that your patches are
> not removing the lines that set the CPU0 low power states at the start
> of exynos5420_pm_resume() as you asked Vikas [1] but instead your
> version of this patch does not have the code that does the same
> operation after the early_wakeup label like is made in $subject.
The reason for my asking Vikas to remove the lines that restore the
core low power state register from the base s2r patch was because it
should be part of the mcpm s2r patch where the actual setting of the
register takes place.
Regarding the location of those lines we should be restoring the
register as early as possible, so my next version would have it at the
beginning of exynos5420_pm_resume.
>
> IOW, this [2] is what I had to change on top of $subject to have s2r
> working. After that change, both suspending to ram and resuming due
> the RTC IRQ alarm being triggered and the core pm_test case works well
> on my Exynos5420 Peach Pit.
That's good. Thanks for testing !
Regards,
Abhilash
>
>>
>> Regards,
>> Abhilash
>
> Best regards,
> Javier
>
> [0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.html
> [2]: http://pastebin.com/raw.php?i=XSxJH3Ys
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hello Abhilash,
On Mon, Oct 6, 2014 at 11:08 AM, Abhilash Kesavan
wrote:
diff --git a/arch/arm/mach-exynos/platsmp.c
b/arch/arm/mach-exynos/platsmp.c
index adb36a8..222aa3c 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
*/
void exynos_cpu_power_up(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
+* the SYS_PWR_REG value to decide if we are suspending
+* the system.
+*/
+ int val = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ if (!(val & S5P_CORE_LOCAL_PWR_EN))
+ return;
+ }
pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
EXYNOS_ARM_CORE_CONFIGURATION(cpu));
}
>>>
>>> The above block of code should be in exynos_cpu_power_down(). Can you
>>> re-test s2r after modifying it ? I have to convert a __raw_readl to
>>> pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
>>> patch I will re-post a v9.
>>>
>>
>> Thanks, for the information but unfortunately even after this change I
>> still have the issue reported in [0]. I also removed the lines from
>> exynos5420_pm_resume() that you asked Vikash [1].
>
> I have just tested this on the 5420 that I have and it resumes fine.
> The difference could be in the bootloader we are using. I'll send out
> details of my current setup so that you can cross-check if everything
> is the same.
Thanks a lot for sending me the patches you are using to test.
But after looking at the differences I noticed that your patches are
not removing the lines that set the CPU0 low power states at the start
of exynos5420_pm_resume() as you asked Vikas [1] but instead your
version of this patch does not have the code that does the same
operation after the early_wakeup label like is made in $subject.
IOW, this [2] is what I had to change on top of $subject to have s2r
working. After that change, both suspending to ram and resuming due
the RTC IRQ alarm being triggered and the core pm_test case works well
on my Exynos5420 Peach Pit.
>
> Regards,
> Abhilash
Best regards,
Javier
[0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.html
[2]: http://pastebin.com/raw.php?i=XSxJH3Ys
--
To unsubscribe from this list: send the line "unsubscribe linux-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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On 25/09/14 09:23, Thierry Reding wrote: > How are cameras different? The CPU wants to capture video data from the > camera, so it needs to go look for a video capture device, which in turn > needs to involve a sensor. Let's say we have an XXX-to-YYY encoder. We use that encoder to convert the SoC's XXX output to YYY, which is then shown on a panel. So, in this case, the encoder's DT node will have a "panel" or "output" phandle, pointing to the panel. We then use the exact same encoder in a setup in which we have a camera which outputs XXX, which the encoder then converts to YYY, which is then captured by the SoC. Here the "output" phandle would point to the SoC. >>> If you go the other way around, how do you detect how things connect? >>> Where do you get the information about the panel so you can trace back >>> to the origin? >> >> When the panel driver probes, it registers itself as a panel and gets >> its video source. Similarly a bridge in between gets its video source, >> which often would be the SoC, i.e. the origin. > > That sounds backwards to me. The device tree serves the purpose of > supplementing missing information that can't be probed if hardware is > too stupid. I guess that's one of the primary reasons for structuring it > the way we do, from the CPU point of view, because it allows the CPU to > probe via the device tree. > > Probing is always done downstream, so you'd start by looking at some > type of bus interface and query it for what devices are present on the > bus. Take for example PCI: the CPU only needs to know how to access the > host bridge and will then probe devices behind each of the ports on that > bridge. Some of those devices will be bridges, too, so it will continue > to probe down the hierarchy. > > Without DT you don't have a means to know that there was a panel before > you've actually gone and probed your whole hierarchy and found a GPU > with some sort of output that a panel can be connected to. I think it > makes a lot of sense to describe things in the same way in DT. Maybe I don't quite follow, but it sounds to be you are mixing control and data. For control, all you say is true. The CPU probes the devices on control busses, either with the aid of HW or the aid of DT, going downstream. But the data paths are a different matter. The CPU/SoC may not even be involved in the whole data path. You could have a sensor on the board directly connected to a panel. Both are controlled by the CPU, but the data path goes from the sensor to the panel (or vice versa). There's no way the data paths can be "CPU centric" in that case. Also, a difference with the data paths compared to control paths is that they are not strictly needed for operation. An encoder can generate an output without enabling its input (test pattern or maybe blank screen, or maybe a screen with company logo). Or an encoder with two inputs might only get the second input when the user requests a very high res mode. So it is possible that the data paths are lazily initialized. You do know that there is a panel right after the device is probed according to its control bus. It doesn't mean that the data paths are there yet. In some cases the user space needs to reconfigure the data paths before a panel has an input and can be used to show an image from the SoC's display subsystem. The point here being that the data path bindings don't really relate to the probing part. You can probe no matter which way the data path bindings go, and no matter if there actually exists (yet) a probed device on the other end of a data path phandle. While I think having video data connections in DT either way, downstream or upstream, would work, it has felt most natural for me to have the phandles from video sinks to video sources. The reason for that is that I think the video sink has to be in control of its source. It's the sink that tells the source to start or stop or reconfigure. So I have had need to get the video source from a video sink, but I have never had the need to get the video sinks from video sources. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v9 1/2] ARM: EXYNOS: Add platform driver support for Exynos PMU
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform driver support for Exynos PMU IP.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynosXYZ().
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/pmu.c | 171 +++---
2 files changed, 130 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 46f3c0d..0ca168e 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -24,6 +24,7 @@ menuconfig ARCH_EXYNOS
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select SRAM
+ select MFD_SYSCON
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index cfc62e8..1f5aaa7 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -10,12 +10,26 @@
*/
#include
-#include
+#include
+#include
#include "common.h"
#include "regs-pmu.h"
-static const struct exynos_pmu_conf *exynos_pmu_config;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+};
+
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
@@ -336,7 +350,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+static void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -344,7 +358,7 @@ static void exynos5_init_pmu(void)
/*
* Enable both SC_FEEDBACK and SC_COUNTER
*/
- for (i = 0 ; i < ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
+ for (i = 0; i < ARRAY_SIZE(exynos5_list_both_cnt_feed); i++) {
tmp = pmu_raw_readl(exynos5_list_both_cnt_feed[i]);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
@@ -361,7 +375,7 @@ static void exynos5_init_pmu(void)
/*
* Disable WFI/WFE on XXX_OPTION
*/
- for (i = 0 ; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
+ for (i = 0; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe); i++) {
tmp = pmu_raw_readl(exynos5_list_diable_wfi_wfe[i]);
tmp &= ~(EXYNOS5_OPTION_USE_STANDBYWFE |
EXYNOS5_OPTION_USE_STANDBYWFI);
@@ -373,51 +387,124 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
- exynos5_init_pmu();
+ const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
- for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- pmu_raw_writel(exynos_pmu_config[i].val[mode],
- exynos_pmu_config[i].offset);
+ if (pmu_data->powerdown_conf)
+ pmu_data->powerdown_conf(mode);
- if (soc_is_exynos4412()) {
- for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END ;
i++)
- pmu_raw_writel(exynos4412_pmu_config[i].val[mode],
- exynos4412_pmu_config[i].offset);
+ if (pmu_data->pmu_config) {
+ for (i = 0; (pmu_data->pmu_config[i].offset != PMU_TABLE_END);
i++)
+ pmu_raw_writel(pmu_data->pmu_config[i].val[mode],
+ pmu_data->pmu_config[i].offset);
+ }
+
+ if (pmu_data->pmu_config_extra) {
+ for (i = 0; pmu_data->pmu_config_extra[i].offset !=
PMU_TABLE_END; i++)
+ pmu_raw_writel(pmu_data->pmu_config_extra[i].val[mode],
+ pmu_data->pmu_config_extra[i].offset);
}
}
-static int __init exynos_pmu_init(void)
+static void exynos5250_pmu_init(void)
{
unsigned int value;
+ /*
+* When SYS_WDTRESET is set, watchdog timer reset request
+* is ignored by power manageme
[PATCH v9 0/2] ARM: Exynos: Convert PMU implementation into a platform driver
This patch series, modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either "drivers/mfd", or "drivers/power" or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches are created on top of Kukjin Kim's for-next. Vikas Sajjan have tested these patches on Exynos5420 based Peach board for system boot and S2R. This patch series depends on following patch series: [1]: mfd: syscon: Decouple syscon interface from syscon devices. https://lkml.org/lkml/2014/9/30/156 Patch v8 and discussion can be found here: http://www.spinics.net/lists/arm-kernel/msg366831.html Change since v8: - Changed __raw_readl/writel into readl/writel_relaxed as suggested by Arnd. Change since v7: - Removing registration of syscon provider. As it will be handled now by syscon patch [1]. - Rebased on top of latest kgene/for-next. Change since v6: - Removed NULL check for pmu_data in pmu.c. - Moved pmu_raw_readl and pmu_raw_writel inline helper function into common.h. Change Since v5: - Squashed patch "Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c" into patch "Refactored code for using PMU address via DT". - Addressed review comments from Tomasz Figa. - Using init_irq machine function to initialize PMU mapping instead of init_time. - Rebased on latest Kukjin Kim's for-next branch. Changes Since v4: - Splitted patch series in two parts. Part 1 has code cleanup under mach-exynos and posted as separate patch [2]. Current patchset is part 2 which modified exynos pmu implementation for making it platform driver. - Removed dependency over early_syscon API. - Removed usage of regmap read/write APIs. - Modified probe function to register exynos pmu as syscon provider using Tomasz Figa's syscon patch [1]. - Address various other review comments from Tomasz Figa. - Removed signed-off-by of Young-Gun Jang , as this id is no more valid. Taking ownership of all his patches. Changes Since v3: - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init as suggested by Vikas Sajjan. - Modified syscon_early_regmap_lookup_by_phandle and syscon_regmap_lookup_by_phandle function call to pass property as NULL. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed early mapping of PMU base address from exynos.c and removed "get_exynos_pmuaddr" function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of "exynos_pmu_base", as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that "early_syscon_init" requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as "smp_secondary_init" will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to "drivers/mfd" folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", once we enable MFD_SYSCON config option, current "syscon" driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using "syscon_early_regmap_lookup_by_phandle". If there is any better solution please suggest. Pankaj Dubey (2): ARM: EXYNOS: Add platform driver support for Exynos PMU ARM: EXYNOS: Move PMU specific definitions from common.h arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/common.h | 17 arch/arm/mach-exynos/exynos-pmu.h | 24 + arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/pmu.c| 191 - arch/arm/mach-exynos/suspen
[PATCH v9 2/2] ARM: EXYNOS: Move PMU specific definitions from common.h
This patch moves PMU specific definitions into a new file
as exynos-pmu.h.
This will help in reducing dependency of common.h in pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/exynos-pmu.h | 24
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c| 20 +++-
arch/arm/mach-exynos/suspend.c|1 +
5 files changed, 45 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index d4d09bc..431be1b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -139,23 +139,6 @@ extern void exynos_cpu_resume_ns(void);
extern struct smp_operations exynos_smp_ops;
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END (-1U)
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..a2ab0d5
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * 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.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 4f10fa6..86f3ecd 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -26,6 +26,7 @@
#include
#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
#include "regs-sys.h"
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 1f5aaa7..1993e08 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -13,9 +13,16 @@
#include
#include
-#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
+#define PMU_TABLE_END (-1U)
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
const struct exynos_pmu_conf *pmu_config_extra;
@@ -29,8 +36,19 @@ struct exynos_pmu_context {
const struct exynos_pmu_data *pmu_data;
};
+static void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ writel_relaxed(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return readl_relaxed(pmu_base_addr + offset);
+}
+
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f5d9773..079d999 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -33,6 +33,7 @@
#include "common.h"
#include "regs-pmu.h"
#include "regs-sys.h"
+#include "exynos-pmu.h"
#define S5P_CHECK_SLEEP 0x0BAD
--
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 v8] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hi Javier,
On Mon, Oct 6, 2014 at 1:45 PM, Javier Martinez Canillas
wrote:
> Hello Abhilash,
>
> On Mon, Oct 6, 2014 at 5:40 AM, Abhilash Kesavan
> wrote:
>> Hi Javier,
>>
>> [...]
>>
>>> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
>>> index adb36a8..222aa3c 100644
>>> --- a/arch/arm/mach-exynos/platsmp.c
>>> +++ b/arch/arm/mach-exynos/platsmp.c
>>> @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
>>> */
>>> void exynos_cpu_power_up(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
>>> +* the SYS_PWR_REG value to decide if we are suspending
>>> +* the system.
>>> +*/
>>> + int val = __raw_readl(pmu_base_addr +
>>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>>> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>>> + return;
>>> + }
>>> pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
>>> EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>>> }
>>
>> The above block of code should be in exynos_cpu_power_down(). Can you
>> re-test s2r after modifying it ? I have to convert a __raw_readl to
>> pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
>> patch I will re-post a v9.
>>
>
> Thanks, for the information but unfortunately even after this change I
> still have the issue reported in [0]. I also removed the lines from
> exynos5420_pm_resume() that you asked Vikash [1].
I have just tested this on the 5420 that I have and it resumes fine.
The difference could be in the bootloader we are using. I'll send out
details of my current setup so that you can cross-check if everything
is the same.
>
> Which __raw_readl() you had to convert? That is only for consistency
> right? Since I see that the __raw_readl() calls are using
> pmu_base_addr + offset so it seems to be correct.
Yes, it is only for consistency. It should not cause any issues if you
leave it as it is.
>
> I'll test again once you both re-spin your patches then.
OK.
Regards,
Abhilash
>
>> Regards,
>> Abhilash
>
> Best regards,
> Javier
>
> [0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.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
[PATCH 2/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P
Commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
removed the Kconfig symbol PLAT_S5P. Remove an optional dependency on
that symbol from this Kconfig file too.
Signed-off-by: Paul Bolle
---
drivers/media/platform/exynos4-is/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 77c951237744..775c3278d0eb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+ depends on (ARCH_EXYNOS || COMPILE_TEST)
depends on OF && COMMON_CLK
help
Say Y here to enable camera host interface devices for
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Remove optional dependencies on PLAT_S5P
Commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
removed the Kconfig symbol PLAT_S5P. The seven dependencies on that
symbol have evaluated to false since next-20140716 (for linux-next) and
v3.17-rc1 (for mainline). Probably no one noticed because these are all
optional dependencies.
I've mentioned this a few times:
- http://lkml.kernel.org/r/1405505756.4408.24.camel@x220
- http://lkml.kernel.org/r/1409825817.5546.99.camel@x220
- http://lkml.kernel.org/r/1411068565.2017.83.camel@x220
As far as I know no fix for this is pending. So let's remove these
optional dependencies. If it turns out that they should actually be
replaced by another symbol, as was said in a reply to my first message
but never done, this series can be used as a reference for the places
that need fixing.
This series is done on top of next-20141003. It is tested by grepping
the tree only.
Paul Bolle (4):
[media] Remove optional dependencies on PLAT_S5P
[media] exynos4-is: Remove optional dependency on PLAT_S5P
[media] Remove optional dependency on PLAT_S5P
usb: host: Remove optional dependencies on PLAT_S5P
drivers/media/platform/Kconfig| 6 +++---
drivers/media/platform/exynos4-is/Kconfig | 2 +-
drivers/media/platform/s5p-tv/Kconfig | 2 +-
drivers/usb/host/Kconfig | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7] mfd: syscon: Decouple syscon interface from platform devices
Hi Lee, On Tuesday, September 30, 2014 9:39 PM Doug Anderson wrote, > Subject: Re: [PATCH v7] mfd: syscon: Decouple syscon interface from platform > devices > > Pankaj, > > On Tue, Sep 30, 2014 at 1:35 AM, Pankaj Dubey > wrote: > > Currently a syscon entity can be only registered directly through a > > platform device that binds to a dedicated syscon driver. However in > > certain use cases it is desirable to make a device used with another > > driver a syscon interface provider. > > > > For example, certain SoCs (e.g. Exynos) contain system controller > > blocks which perform various functions such as power domain control, > > CPU power management, low power mode control, but in addition contain > > certain IP integration glue, such as various signal masks, coprocessor > > power control, etc. In such case, there is a need to have a dedicated > > driver for such system controller but also share registers with other > > drivers. The latter is where the syscon interface is helpful. > > > > In case of DT based platforms, this patch decouples syscon object from > > syscon platform driver, and allows to create syscon objects first time > > when it is required by calling of syscon_regmap_lookup_by APIs and > > keep a list of such syscon objects along with syscon provider > > device_nodes and regmap handles. > > > > For non-DT based platforms, this patch keeps syscon platform driver > > structure so that syscon can be probed and such non-DT based drivers > > can use syscon_regmap_lookup_by_pdev API and access regmap handles. > > Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based, > > we can completely remove platform driver of syscon, and keep only > > helper functions to get regmap handles. > > > > Suggested-by: Arnd Bergmann > > Suggested-by: Tomasz Figa > > Tested-by: Vivek Gautam > > Tested-by: Javier Martinez Canillas > > Signed-off-by: Pankaj Dubey > > Reviewed-by: Arnd Bergmann > > Tested-by: Heiko Stuebner > > Reviewed-by: Heiko Stuebner > > --- > > Patch v6 and related discussions can be found here [1]. > > > > Change since v5: > > - Addressed review comments from "Heiko Stuebner". > > - Updated commit description. > > - Including Arnd's and Heiko's Reviewed-by. > > > > Change since v5: > > - Dropping creation of dummy platform device in of_syscon_register. > > - As we are changing syscon to decouple from platform_device, creation of > >dummy platform_device does not look good option, and as suggested by > > Arnd, > >I made another attempt so that regmap_mmio_init API should work with NULL > >dev pointer itself. Since regmap needs to know about Syscon device node > >properties so let's parse device node of syscon in syscon itself for any > >such properties and using regmap_config parameter pass all such > > information > >to regmap. Other concern of crashes due to NULL dev pointer in regmap > > already > >addressed in separate patches of regmap. Please see [2] and [3]. > > > > Changes since v4: > > - Addressed Tomasz Figa's comments for v4. > > - Added error handing in of_syscon_register function. > > - Using devm_regmap_init_mmio instead of regmap_init_mmio. > > > > Changes since v3: > > - Addressed Arnd's comment for v2. > > - Updated of_syscon_register for adding dev pointer in regmap_init_mmio. > > - For early users created dummy platform device. > > > > Changes since v2: > > - Added back platform device support from syscon, with one change that > >syscon will not be probed for DT based platform. > > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base > >users of syscon will not be broken. > > - Removed unwanted change in syscon.h. > > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and > >Arnd Bergmann. > > - Added Tested-by of Vivek Gautam for testing on Exynos platform. > > > > Changes since v1: > > - Removed of_syscon_unregister function. > > - Modified of_syscon_register function and it will be used by syscon.c > >to create syscon objects whenever required. > > - Removed platform device support from syscon. > > - Removed syscon_regmap_lookup_by_pdevname API support. > > - As there are significant changes w.r.t patchset v1, I am taking over > >author for this patchset from Tomasz Figa. > > > > [1]: https://lkml.org/lkml/2014/9/29/99 > > [2]: https://lkml.org/lkml/2014/9/18/130 > > [3]: https://lkml.org/lkml/2014/9/27/2 > > drivers/mfd/syscon.c | 96 > ++ > > 1 file changed, 74 insertions(+), 22 deletions(-) > > You probably already have enough tags, but just in case. ;) On an > rk3288-based > system (this patch backported to 3.14): > > Tested-by: Doug Anderson I think now we can take have this patch in. So will you please take this patch. Thanks, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majord
Re: [PATCH v8] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hello Abhilash,
On Mon, Oct 6, 2014 at 5:40 AM, Abhilash Kesavan
wrote:
> Hi Javier,
>
> [...]
>
>> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
>> index adb36a8..222aa3c 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
>> */
>> void exynos_cpu_power_up(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
>> +* the SYS_PWR_REG value to decide if we are suspending
>> +* the system.
>> +*/
>> + int val = __raw_readl(pmu_base_addr +
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>> + return;
>> + }
>> pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
>> EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>> }
>
> The above block of code should be in exynos_cpu_power_down(). Can you
> re-test s2r after modifying it ? I have to convert a __raw_readl to
> pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
> patch I will re-post a v9.
>
Thanks, for the information but unfortunately even after this change I
still have the issue reported in [0]. I also removed the lines from
exynos5420_pm_resume() that you asked Vikash [1].
Which __raw_readl() you had to convert? That is only for consistency
right? Since I see that the __raw_readl() calls are using
pmu_base_addr + offset so it seems to be correct.
I'll test again once you both re-spin your patches then.
> Regards,
> Abhilash
Best regards,
Javier
[0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.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: exynos5420/arndale-octa: imprecise external aborts on exynos_defconfig
Hi Bartlomiej,
On Tue, Sep 30, 2014 at 11:47 PM, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Wednesday, September 17, 2014 05:39:29 PM Kevin Hilman wrote:
>> Thomas Abraham writes:
>>
>> > On Thu, Sep 11, 2014 at 12:16 AM, Kevin Hilman wrote:
>> >> Tyler Baker writes:
>> >>
>> >>> Exynos5420-based Arndale octa boards have recently started failing boot
>> >>> tests due to imprecise external aborts. This only appears to happen
>> >>> when using exynos_defconfig and boots fine with multi_v7_defconfig. The
>> >>> issue seems to be intermittent, so is not reliably reproducable and
>> >>> difficult to bisect. Here are a few boot logs from recent
>> >>> mainline/linux-next kernels that are failing:
>> >>
>> >> FYI, I'm seeing the same periodic aborts. For example, here's my boot
>> >> of next-20140910:
>> >> http://images.armcloud.us/kernel-ci/next/next-20140910/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
>> >>
>> >> However, my userspace is much simpler and doesn't seem to cause a panic,
>> >> so my boot tests report passing. (I should fixup my scripts so these
>> >> imprecise aborts are reported as a FAIL.)
>> >>
>> >> I'm glad you pointed out that it happens only with exynos_defconfig and
>> >> not multi_v7_defconfig because I noticed that too. I haven't had the
>> >> time to track it any further than that, so maybe the exynos folks can
>> >> help track it down from here.
>> >>
>> >> Thanks for reporting this,
>> >>
>> >> Kevin
>> >
>> > Hi Tyler, Kevin,
>> >
>> > From the bootlog you have shared,
>> >
>> > [1.060016] CPU4: failed to come online
>> > [2.070031] CPU5: failed to come online
>> > [3.080049] CPU6: failed to come online
>> > [4.090066] CPU7: failed to come online
>> > [4.090099] Brought up 4 CPUs
>> > [4.090109] SMP: Total of 4 processors activated.
>> > [4.090119] CPU: WARNING: CPU(s) started in wrong/inconsistent
>> > modes (primary CPU mode 0x13)
>> > [4.090128] CPU: This may indicate a broken bootloader or firmware.
>> >
>> > Would it be possible to set max cpus to 1, disable switcher and try
>
> Which "max cpus" do you mean? For NR_CPUS the lower limit is 2.
The "maxcpus=1" kernel parameter could be used here. The reason for
trying with this option was to understand the probable location of
this imprecise abort (mcpm init or secondary cpu boot).
Thanks,
Thomas.
>
>> > again. I don't have a arndale octa board but I have tested mainline
>> > kernel with smdk5420 board. It boots all eight CPUs, switcher works
>> > fine and there are no imprecise aborts seen.
>>
>> Sorry for the delay, I'm travelling this week.
>>
>> FWIW, the same CPU boot failures you hilight above are happening on
>> multi_v7_defconfig[1] which is not getting the imprecise abort. This is
>> only happening on exynos_defconfig[2], so I'm curious why you think the
>> switcher or NR_CPUS might be the issues.
>>
>> Anyways, I narrowed this down a bit and discovered it's
>> CONFIG_EXYNOS5420_MCPM=y that's the root cause. If I use
>> exynos_defconfig and then disable that option, I don't get any more
>> imprecise aborts.
>
> I have exactly the same issue with Exynos5420 Arndale Octa.
>
> CONFIG_EXYNOS5420_MCPM was enabled by commit fc3791f3a95d
> ("ARM: exynos_defconfig: Update exynos_defconfig") which
> get merged into v3.17-rc1. It seems that this part of
> the patch should be reverted for the final v3.17 kernel.
>
>> Kevin
>>
>> [1]
>> http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-multi_v7_defconfig/boot-exynos5420-arndale-octa.html
>> [2]
>> http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
