Hi Michał,
Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
from NVME.
It turns out that, commit aea6cb99703e ("regulator: resolve supply after
creating regulator") seems to be the cause.
In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
provided by RK808 regulator.
With that commit, now RK808 regulator fails to register:
[ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
[ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
[ 1.419856] rk808 0-001b: failed to register 12 regulator
[ 1.422801] rk808-regulator: probe of rk808-regulator failed with
error -22
Since voltages from rk808 are not proper registered, then it prevents
the rockchip PCIE controller to find its voltage provider:
[ 1.855276] rockchip_pcie_probe: parse_host_dt err=-517
I currently tested with that commit reverted, then the RK808 works again.
Is this a known regression? Or the RK808 device tree is out of spec?
It would help a lot to fix the problem before the regression makes all
RK3399 boards to lose their ability to initialize PCIE controller.
BTW I didn't find that patch submitted to mail lists like
linux-arm-kernel. I doubt if that commit really got enough testing from
arm community, especially considering that currently ARM is the biggest
user of device-tree and regulators.
Maybe it's a good idea to also submit such patches to arm related mail
lists next time?
Thanks,
Qu
Also add Rockchip and device tree mail lists to the CC, just in case we
need to update the device tree for RK808.
On 2020/11/8 下午3:35, Qu Wenruo wrote:
> Hi Michał,
>
> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
> from NVME.
>
> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
> creating regulator") seems to be the cause.
>
> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
> provided by RK808 regulator.
> With that commit, now RK808 regulator fails to register:
>
> [ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
> [ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
> [ 1.419856] rk808 0-001b: failed to register 12 regulator
> [ 1.422801] rk808-regulator: probe of rk808-regulator failed with
> error -22
>
> Since voltages from rk808 are not proper registered, then it prevents
> the rockchip PCIE controller to find its voltage provider:
>
> [ 1.855276] rockchip_pcie_probe: parse_host_dt err=-517
>
>
> I currently tested with that commit reverted, then the RK808 works again.
>
> Is this a known regression? Or the RK808 device tree is out of spec?
>
> It would help a lot to fix the problem before the regression makes all
> RK3399 boards to lose their ability to initialize PCIE controller.
>
>
> BTW I didn't find that patch submitted to mail lists like
> linux-arm-kernel. I doubt if that commit really got enough testing from
> arm community, especially considering that currently ARM is the biggest
> user of device-tree and regulators.
>
> Maybe it's a good idea to also submit such patches to arm related mail
> lists next time?
>
> Thanks,
> Qu
>
On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
> Hi Micha?,
>
> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
> from NVME.
>
> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
> creating regulator") seems to be the cause.
>
> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
> provided by RK808 regulator.
> With that commit, now RK808 regulator fails to register:
>
> [ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
> [ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
> [ 1.419856] rk808 0-001b: failed to register 12 regulator
> [ 1.422801] rk808-regulator: probe of rk808-regulator failed with
> error -22
Hi,
This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer
probe when trying to get voltage from unresolved supply") recently accepted
to regulator tree [1]. Can you verify this?
[1] git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Best Regards
Micha??Miros?aw
On 2020/11/9 上午1:18, Michał Mirosław wrote:
> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>> Hi Michał,
>>
>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
>> from NVME.
>>
>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>> creating regulator") seems to be the cause.
>>
>> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
>> provided by RK808 regulator.
>> With that commit, now RK808 regulator fails to register:
>>
>> [ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
>> [ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
>> [ 1.419856] rk808 0-001b: failed to register 12 regulator
>> [ 1.422801] rk808-regulator: probe of rk808-regulator failed with
>> error -22
>
> Hi,
>
> This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer
> probe when trying to get voltage from unresolved supply") recently accepted
> to regulator tree [1]. Can you verify this?
Thanks, tested with that commit cherry picked to v5.10-rc2 and it solves
the problem.
Thanks,
Qu
>
> [1] git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
>
> Best Regards
> Michał Mirosław
>
On 09.11.20 00:28, Qu Wenruo wrote:
>
>
> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>>> Hi Michał,
>>>
>>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
>>> from NVME.
>>>
>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>> creating regulator") seems to be the cause.
>>>
>>> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
>>> provided by RK808 regulator.
>>> With that commit, now RK808 regulator fails to register:
>>>
>>> [ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
>>> [ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
>>> [ 1.419856] rk808 0-001b: failed to register 12 regulator
>>> [ 1.422801] rk808-regulator: probe of rk808-regulator failed with
>>> error -22
>>
>> Hi,
>>
>> This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer
>> probe when trying to get voltage from unresolved supply") recently accepted
>> to regulator tree [1]. Can you verify this?
>
> Thanks, tested with that commit cherry picked to v5.10-rc2 and it solves
> the problem.
>
We are still missing some magic fix for stable trees: On the STM32MP15x,
things are broken since 5.4.73 now. And 5.9.y is not booting as well on
that board. Reverting the original commit make it boot again.
Linus master is fine, though, but I'm tired of bisecting. Any
suggestions? Or is there something queued up already?
In any case: Is that board in no stable Q&A farm? It's a basic "boot
fails" regression.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
> On 09.11.20 00:28, Qu Wenruo wrote:
> > On 2020/11/9 上午1:18, Michał Mirosław wrote:
> >> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
[...]
> >>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
> >>> creating regulator") seems to be the cause.
[...]
> We are still missing some magic fix for stable trees: On the STM32MP15x,
> things are broken since 5.4.73 now. And 5.9.y is not booting as well on
> that board. Reverting the original commit make it boot again.
>
> Linus master is fine, though, but I'm tired of bisecting. Any
> suggestions? Or is there something queued up already?
You might want to look at `git log --grep=aea6cb99703e` if you can't
wait for a stable backport.
Best Regards
Michał Mirosław
On 22.11.20 17:35, Michał Mirosław wrote:
> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
>> On 09.11.20 00:28, Qu Wenruo wrote:
>>> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>>>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
> [...]
>>>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>>>> creating regulator") seems to be the cause.
> [...]
>> We are still missing some magic fix for stable trees: On the STM32MP15x,
>> things are broken since 5.4.73 now. And 5.9.y is not booting as well on
>> that board. Reverting the original commit make it boot again.
>>
>> Linus master is fine, though, but I'm tired of bisecting. Any
>> suggestions? Or is there something queued up already?
>
> You might want to look at `git log --grep=aea6cb99703e` if you can't
> wait for a stable backport.
>
Good. Is that flagged and tested for 5.9/5.4 (and whatever is also
affected) already?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
On 2020/11/23 下午2:47, Jan Kiszka wrote:
> On 22.11.20 17:35, Michał Mirosław wrote:
>> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
>>> On 09.11.20 00:28, Qu Wenruo wrote:
>>>> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>>>>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>> [...]
>>>>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>>>>> creating regulator") seems to be the cause.
>> [...]
>>> We are still missing some magic fix for stable trees: On the STM32MP15x,
>>> things are broken since 5.4.73 now. And 5.9.y is not booting as well on
>>> that board. Reverting the original commit make it boot again.
>>>
>>> Linus master is fine, though, but I'm tired of bisecting. Any
>>> suggestions? Or is there something queued up already?
>>
>> You might want to look at `git log --grep=aea6cb99703e` if you can't
>> wait for a stable backport.
>>
>
> Good. Is that flagged and tested for 5.9/5.4 (and whatever is also
> affected) already?
The offending commit is only introduced in v5.10, thus I don't beleive
v5.9/v5.4 is affected unless the commit is backported.
Thanks,
Qu
>
> Jan
>