mvebu - switch to orion-timer
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Hi Stefan,
I would like to see this too. I was thinking of doing it per board, but it is more appropriate to enable it for Arch_Kirkwood and Arch_MVEBU.
Thanks, Tony
On Tue, Aug 23, 2022 at 3:33 PM Pali Rohár pali@kernel.org wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Hi Pali,
On 24.08.22 00:33, Pali Rohár wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Yes, I also though about this.
But...
In Linux we have 2 different timer clocksource drivers for Orion / Kirkwood and Armada XP / 370 etc:
drivers/clocksource/timer-orion.c drivers/clocksource/timer-armada-370-xp.c
I did not check, if and why this is necessary to handle those chips via different drivers yet. Perhaps later this week. Or someone of you beats me with this. ;)
Thanks, Stefan
Hi,
On 24.08.22 00:33, Pali Rohár wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Yes, I also though about this.
But...
In Linux we have 2 different timer clocksource drivers for Orion / Kirkwood and Armada XP / 370 etc:
drivers/clocksource/timer-orion.c drivers/clocksource/timer-armada-370-xp.c
I did not check, if and why this is necessary to handle those chips via different drivers yet. Perhaps later this week. Or someone of you beats me with this. ;)
One thing which is definitely missing is https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/arm/mach-mvebu/ti...
I didn't bother to handle that one. And of course all the compatibles are missing.
-michael
Hi Michael, Pali, Tony & all,
On 24.08.22 09:35, Michael Walle wrote:
Hi,
On 24.08.22 00:33, Pali Rohár wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Yes, I also though about this.
But...
In Linux we have 2 different timer clocksource drivers for Orion / Kirkwood and Armada XP / 370 etc:
drivers/clocksource/timer-orion.c drivers/clocksource/timer-armada-370-xp.c
I did not check, if and why this is necessary to handle those chips via different drivers yet. Perhaps later this week. Or someone of you beats me with this. ;)
One thing which is definitely missing is https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/arm/mach-mvebu/ti...
I didn't bother to handle that one. And of course all the compatibles are missing.
Thanks. Just a short status update:
I'm currently busy with this CONFIG_TIMER migration for MVEBU / Kirkwood. Looks good so far - I can only test on Armada XP right now. So I need some extensive testing on all other kind of Marvell 32bit users / developers. I expect to send the first draft patchset in a few days.
Thanks, Stefan
On Monday 29 August 2022 14:07:29 Stefan Roese wrote:
Hi Michael, Pali, Tony & all,
On 24.08.22 09:35, Michael Walle wrote:
Hi,
On 24.08.22 00:33, Pali Rohár wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Yes, I also though about this.
But...
In Linux we have 2 different timer clocksource drivers for Orion / Kirkwood and Armada XP / 370 etc:
drivers/clocksource/timer-orion.c drivers/clocksource/timer-armada-370-xp.c
I did not check, if and why this is necessary to handle those chips via different drivers yet. Perhaps later this week. Or someone of you beats me with this. ;)
One thing which is definitely missing is https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/arm/mach-mvebu/ti...
I didn't bother to handle that one. And of course all the compatibles are missing.
Thanks. Just a short status update:
I'm currently busy with this CONFIG_TIMER migration for MVEBU / Kirkwood. Looks good so far - I can only test on Armada XP right now. So I need some extensive testing on all other kind of Marvell 32bit users / developers. I expect to send the first draft patchset in a few days.
Thanks, Stefan
I will test it on Turris Omnia - A385.
Hi Stefan,
On Mon, Aug 29, 2022 at 5:50 AM Pali Rohár pali@kernel.org wrote:
On Monday 29 August 2022 14:07:29 Stefan Roese wrote:
Hi Michael, Pali, Tony & all,
On 24.08.22 09:35, Michael Walle wrote:
Hi,
On 24.08.22 00:33, Pali Rohár wrote:
Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which Michael wrote, I think that it mvebu platform should switch to use it. Because build process for armada boards prints deprecation warning that new timer is not being used. Could you look at it, if it is possible to do global switch for mach-mvebu and mach-kirkwood? I think it does not make sense to do per-board switching as it is de-facto platform related code.
Yes, I also though about this.
But...
In Linux we have 2 different timer clocksource drivers for Orion / Kirkwood and Armada XP / 370 etc:
drivers/clocksource/timer-orion.c drivers/clocksource/timer-armada-370-xp.c
I did not check, if and why this is necessary to handle those chips via different drivers yet. Perhaps later this week. Or someone of you beats me with this. ;)
One thing which is definitely missing is https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/arm/mach-mvebu/ti...
I didn't bother to handle that one. And of course all the compatibles are missing.
Thanks. Just a short status update:
I'm currently busy with this CONFIG_TIMER migration for MVEBU / Kirkwood. Looks good so far - I can only test on Armada XP right now. So I need some extensive testing on all other kind of Marvell 32bit users / developers. I expect to send the first draft patchset in a few days.
Thanks, Stefan
I will test it on Turris Omnia - A385.
I will test it on a few Kirkwood boards (88F6281, 88F6282, 88F6192). Please let us know if you have any particular suggestion for a good test.
Best, Tony
participants (4)
-
Michael Walle -
Pali Rohár -
Stefan Roese -
Tony Dinh