| Message ID | 56307B33.90608@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello! > The question is - do you prefer us to send a following up patch or to > fix it by amending the commit? > > Here is a fix which can be squashed into these two commits: By the way, since we are discussing fixing these commits... After hardcoded SROMc handling has been removed, Exynos5410-based machines stopped handling it entirely, because the description has never been added to exynos5410.dtsi (which does not include exynos5.dtsi). Shouldn't the description be added there too? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 28.10.2015 16:49, Pavel Fedin wrote: > Hello! > >> The question is - do you prefer us to send a following up patch or to >> fix it by amending the commit? >> >> Here is a fix which can be squashed into these two commits: > > By the way, since we are discussing fixing these commits... > After hardcoded SROMc handling has been removed, Exynos5410-based machines stopped handling it entirely, because the description > has never been added to exynos5410.dtsi (which does not include exynos5.dtsi). Shouldn't the description be added there too? No, it is not needed. The Exynos5410 in current form does not have suspend capability. During boot you should see in dmesg: Failed to find PMU node coming from mach-exynos/suspend.c. In suspend.c there is no compatible for Exynos5410. Best regards, Krzysztof
Hello! > The Exynos5410 in current form does not have suspend capability. During > boot you should see in dmesg: > Failed to find PMU node > coming from mach-exynos/suspend.c. Indeed. By the way, can this be a reason why reboot stopped working? It worked in v4.1. Isn't this a regression? Ok, nevertheless, here is v3 of my patchset. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On 28.10.2015 17:00, Pavel Fedin wrote: > Hello! > >> The Exynos5410 in current form does not have suspend capability. During >> boot you should see in dmesg: >> Failed to find PMU node >> coming from mach-exynos/suspend.c. > > Indeed. By the way, can this be a reason why reboot stopped working? It worked in v4.1. Isn't this a regression? > Ok, nevertheless, here is v3 of my patchset. The noticeable change between v4.1 and v4.2 was for example: c4241a582d22 ("ARM: EXYNOS: use PS_HOLD based poweroff for all supported SoCs") Can you try whether reverting it fixes the issue? I don't recall any other changes which could affect Exynos5410. Best regards, Krzysztof
Hello! > The noticeable change between v4.1 and v4.2 was for example: > c4241a582d22 ("ARM: EXYNOS: use PS_HOLD based poweroff for all supported > SoCs") First of all, sorry for misinforming you. It was not v4.1 which worked, but 3.18 one. I never ran 4.1 on this board, it's my memory's fault... Second, the commit which actually broke 5410 is 8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart code into pmu driver"). And we don't have 5410 PMU description in our DT, that's the problem. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
On Wed, Oct 28, 2015 at 04:37:23PM +0900, Krzysztof Kozlowski wrote: > On 24.10.2015 06:26, Kukjin Kim wrote: > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > tags/samsung-driver > > > > for you to fetch changes up to c612d5a7785b307df96938d590c3a1edfb624ccf: > > > > cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs (2015-10-24 > > 04:34:50 +0900) > > > > ---------------------------------------------------------------- > > Samsung driver udpates for v4.4 > > > > - add support for exynos SROM controller DT based driver > > (drivers/soc/samsung/exynos-srom.c) > > : Since the exynos SROM registers are used during Suspend to RAM > > so the exynos SROM driver handles the S2R and then we can remove > > static mapping for SROM registers. > > : Pankaj tested boot and S2R functionality on Peach-Pi chromebook > > : Pavel tested on SMDK5410 board > > : Krzysztof tested on Trats2 (exynos4412) board > > - update Maintainer entry accordingly > > - remove superfluous CONFIG_PM ifdefs with Viresh's ack > > > > ---------------------------------------------------------------- > > Bartlomiej Zolnierkiewicz (1): > > cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs > > > > Pankaj Dubey (8): > > ARM: EXYNOS: remove unused static mapping of CMU for exynos5 > > ARM: EXYNOS: code cleanup in map.h > > dt-bindings: add exynos-srom device tree binding > > ARM: dts: add SROM device node for exynos4 > > ARM: dts: add SROM device node for exynos5 > > Hi Olof and Kukjin, > > I see that this pull request was not pulled yet. (Un)Fortunately I > spotted one mistake in DTS changes above - the length of mapped region > is too small by one word. This does not produce any visible effect but > actually is wrong because driver will read from unmapped memory. Yeah, I started looking now at why I didn't merge it since I had just not touched it nor replied to it. It looks like it contains an slight jumble of patches. It modifies DT contents, which we always ask to get in the dt branch. Please resend after -rc1 and we'll merge this for 4.5. Thanks, -Olof
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 2f31f773b096..ffda7f5118cd 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -78,7 +78,7 @@ sromc@12570000 { compatible = "samsung,exynos-srom"; - reg = <0x12570000 0x10>; + reg = <0x12570000 0x14>; }; mipi_phy: video-phy@10020710 { diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi index b5d3437922c5..fb52d16fba33 100644 --- a/arch/arm/boot/dts/exynos5.dtsi +++ b/arch/arm/boot/dts/exynos5.dtsi @@ -32,7 +32,7 @@ sromc@12250000 { compatible = "samsung,exynos-srom"; - reg = <0x12250000 0x10>; + reg = <0x12250000 0x14>; }; combiner: interrupt-controller@10440000 {