| Message ID | 4ac236b3-b980-f653-f644-53e586570724@st.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 01eea23687ed0aa4e251f80ae795fc586e68343a |
| Headers | show |
| Series | [GIT,PULL] STM32 DT fixes for v5.10 #1 | expand |
From: Arnd Bergmann <arnd@arndb.de> On Wed, 28 Oct 2020 16:28:33 +0100, Alexandre Torgue wrote: > On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in > regulator framework which highlights that our supplies are not well > described. This PR fixes it for STM32 boards that I have on my desk: ED1 > and DKx. > > I assume that same patch has to be done for other STM32 boards, but as I > don't have schematics I can't provide it. So a round2 has to be done for: > - stinger96 > - MC-1 > - Odyssey SOM > - DHCOR /DHCOM > > [...] Merged into arm/fixes, thanks! merge commit: 01eea23687ed0aa4e251f80ae795fc586e68343a Arnd
Hello: This pull request was applied to soc/soc.git (refs/heads/arm/fixes): On Wed, 28 Oct 2020 16:28:33 +0100 you wrote: > Hi Arnd, Olof and Kevin, > > On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in > regulator framework which highlights that our supplies are not well > described. This PR fixes it for STM32 boards that I have on my desk: ED1 > and DKx. > > [...] Here is the summary with links: - [GIT,PULL] STM32 DT fixes for v5.10 #1 https://git.kernel.org/soc/soc/c/01eea23687ed You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Hello Alex, On 10/28/20 4:28 PM, Alexandre Torgue wrote: > Hi Arnd, Olof and Kevin, > > On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx. Which change triggered the regression? > I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for: > - stinger96 > - MC-1 > - Odyssey SOM > - DHCOR /DHCOM > > Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance. Your change doesn't look right. If I set vref_ddr-supply to a fixed regulator, the MC-1 now boots again as well, but that seems to just mask the real issue: - vref_ddr is an _output_ of the PMIC, why should one have to specify a supply for it? - This is actually incompatible with the binding. vref_ddr-supply isn't specified as an allowed property (not to mention a required one) - Isn't the kernel supposed to stay compatible to old device trees? I think the stpmic driver is at fault here and that the regulator framework change just made that apparent. Cheers, Ahmad > > > Regards > Alex > > > The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: > > Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git tags/stm32-dt-for-v5.10-fixes-1 > > for you to fetch changes up to 728a7e225ad807b4b4de3be3fb653424199f8a76: > > ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board (2020-10-28 15:08:24 +0100) > > ---------------------------------------------------------------- > STM32 DT fixes for v5.10, round 1 > > Highlights: > ----------- > > -On STM32MP157 DK & ED boards: Add Vin supply description to avoid > random kernel crash due to vref_ddr regulator issue. > > ---------------------------------------------------------------- > Pascal Paillet (2): > ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx board > ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board > > arch/arm/boot/dts/stm32mp157c-ed1.dts | 15 +++++++++++++++ > arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 17 +++++++++++++++++ > 2 files changed, 32 insertions(+) >
On 10/28/20 6:38 PM, Ahmad Fatoum wrote: > Hello Alex, Hi, > On 10/28/20 4:28 PM, Alexandre Torgue wrote: >> Hi Arnd, Olof and Kevin, >> >> On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx. > > Which change triggered the regression? I think it might be: aea6cb99703e ("regulator: resolve supply after creating regulator") which landed in 5.4.73 as 0120ec32a777 ("regulator: resolve supply after creating regulator") >> I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for: >> - stinger96 >> - MC-1 >> - Odyssey SOM >> - DHCOR /DHCOM >> >> Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance. > > Your change doesn't look right. If I set vref_ddr-supply to a fixed regulator, > the MC-1 now boots again as well, but that seems to just mask the real issue: > > - vref_ddr is an _output_ of the PMIC, why should one have to specify a supply for it? > > - This is actually incompatible with the binding. vref_ddr-supply isn't specified > as an allowed property (not to mention a required one) > > - Isn't the kernel supposed to stay compatible to old device trees? > > I think the stpmic driver is at fault here and that the regulator framework change just > made that apparent. I agree updating the DT is not the right approach.
Hello Marek, On 10/30/20 10:04 AM, Marek Vasut wrote: > On 10/28/20 6:38 PM, Ahmad Fatoum wrote: >> Hello Alex, > > Hi, > >> On 10/28/20 4:28 PM, Alexandre Torgue wrote: >>> Hi Arnd, Olof and Kevin, >>> >>> On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx. >> >> Which change triggered the regression? > > I think it might be: > aea6cb99703e ("regulator: resolve supply after creating regulator") > which landed in 5.4.73 as > 0120ec32a777 ("regulator: resolve supply after creating regulator") Thanks. I just replied (with a CC to the ML here) to another thread reporting issues to the author's patch. > >>> I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for: >>> - stinger96 >>> - MC-1 >>> - Odyssey SOM >>> - DHCOR /DHCOM >>> >>> Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance. >> >> Your change doesn't look right. If I set vref_ddr-supply to a fixed regulator, >> the MC-1 now boots again as well, but that seems to just mask the real issue: >> >> - vref_ddr is an _output_ of the PMIC, why should one have to specify a supply for it? >> >> - This is actually incompatible with the binding. vref_ddr-supply isn't specified >> as an allowed property (not to mention a required one) >> >> - Isn't the kernel supposed to stay compatible to old device trees? >> >> I think the stpmic driver is at fault here and that the regulator framework change just >> made that apparent. > > I agree updating the DT is not the right approach. >
Hi guys On 11/2/20 1:52 PM, Ahmad Fatoum wrote: > Hello Marek, > > On 10/30/20 10:04 AM, Marek Vasut wrote: >> On 10/28/20 6:38 PM, Ahmad Fatoum wrote: >>> Hello Alex, >> >> Hi, >> >>> On 10/28/20 4:28 PM, Alexandre Torgue wrote: >>>> Hi Arnd, Olof and Kevin, >>>> >>>> On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx. >>> >>> Which change triggered the regression? >> >> I think it might be: >> aea6cb99703e ("regulator: resolve supply after creating regulator") >> which landed in 5.4.73 as >> 0120ec32a777 ("regulator: resolve supply after creating regulator") > > Thanks. I just replied (with a CC to the ML here) to another thread > reporting issues to the author's patch. Thanks Ahmad > >> >>>> I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for: >>>> - stinger96 >>>> - MC-1 >>>> - Odyssey SOM >>>> - DHCOR /DHCOM >>>> >>>> Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance. >>> >>> Your change doesn't look right. If I set vref_ddr-supply to a fixed regulator, >>> the MC-1 now boots again as well, but that seems to just mask the real issue: >>> >>> - vref_ddr is an _output_ of the PMIC, why should one have to specify a supply for it? >>> >>> - This is actually incompatible with the binding. vref_ddr-supply isn't specified >>> as an allowed property (not to mention a required one) >>> >>> - Isn't the kernel supposed to stay compatible to old device trees? >>> >>> I think the stpmic driver is at fault here and that the regulator framework change just >>> made that apparent. >> >> I agree updating the DT is not the right approach. >> > I agree with you. Regulator framework change should not impose a change in DT (except if it explicitly mentioned in binding documentation). As I explained to Marek this morning, I had this patch in my backlog, and it allows to boot STM32 DK/EV boards for rc cycle. Now, let's have on "regulator: resolve supply after creating regulator". ----- ret = set_machine_constraints(rdev, constraints); if (ret == -EPROBE_DEFER) { /* Regulator might be in bypass mode and so needs its supply * to set the constraints */ /* FIXME: this currently triggers a chicken-and-egg problem * when creating -SUPPLY symlink in sysfs to a regulator * that is just being created */ ret = regulator_resolve_supply(rdev); if (!ret) ret = set_machine_constraints(rdev, constraints); else rdev_dbg(rdev, "unable to resolve supply early: %pe\n", ERR_PTR(ret)); } if (ret < 0) goto wash; ----- --> regulator_resolve_supply(rdev); is no longer called which seems to be the starting point of our issue. Note that the "FIXME" comment could a clue. cheers alex
Hi Arnd, Olof and Kevin, On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx. I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for: - stinger96 - MC-1 - Odyssey SOM - DHCOR /DHCOM Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance. Regards Alex The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git tags/stm32-dt-for-v5.10-fixes-1 for you to fetch changes up to 728a7e225ad807b4b4de3be3fb653424199f8a76: ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board (2020-10-28 15:08:24 +0100) ---------------------------------------------------------------- STM32 DT fixes for v5.10, round 1 Highlights: ----------- -On STM32MP157 DK & ED boards: Add Vin supply description to avoid random kernel crash due to vref_ddr regulator issue. ---------------------------------------------------------------- Pascal Paillet (2): ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx board ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board arch/arm/boot/dts/stm32mp157c-ed1.dts | 15 +++++++++++++++ arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 17 +++++++++++++++++ 2 files changed, 32 insertions(+)