Re: [PATCH RFC 18/18] ARM: dts: Add minimal Raspberry Pi 4 support

[Stefan Wahren <wahrenst@gmx.net>]

Hi Marc,
>> Hi Marc,
>>
>> Am 23.07.19 um 20:13 schrieb Marc Zyngier:
>>> On Wed, 17 Jul 2019 23:16:04 +0200
>>> Stefan Wahren <wahrenst@gmx.net> wrote:
>>>
>>>> This adds minimal support for the new Raspberry Pi 4 without the
>>>> fancy stuff like GENET, PCIe, XHCI, 40 bit DMA and V3D. The RPi 4 is available
>>>> in 3 different variants (1, 2 and 4 GB RAM), so leave the memory size to zero
>>>> and let the bootloader take care of it.
>>>>
>>>> Other differences to the Raspberry Pi 3:
>>>> - additional GIC 400 Interrupt controller
>>>> - new thermal IP and HWRNG
>>>> - additional MMC interface (emmc2)
>>>> - additional UART, I2C, SPI and PWM interfaces
>>>>
>>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>>>
>>>> ...
>>>> +	};
>>>> +
>>>> +	timer {
>>>> +		compatible = "arm,armv7-timer";
> BTW, this should be "arm,armv8-timer".
>
>>>> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
>>>> +					  IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
>>>> +					  IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
>>>> +					  IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
>>>> +					  IRQ_TYPE_LEVEL_LOW)>;
>>>> +		arm,cpu-registers-not-fw-configured;
>>> Really? :-(
>> i asked about that [1] and they said that the arm stubs [2] only set the
>> timer frequency and zeroing CNTVOFF_EL2.
> Who is "they"? As long as it is done on all CPUs, that's the right
> thing to do, and this property is pretty useless in that case.

"They" are the developer at Raspberry Pi Trading. I forwarded some
questions regarding this topic to them, but didn't get a reply yet. My
current understanding is that the armv8 stubs do setup the timer, but
the armv7 stubs do not. So we probably need to keep it.

>
>>>> +		always-on;
>>> I'm pretty sure that's not the case. This indicates that you can power
>>> the CPU off, bring it back on, and yet have your timer alive and
>>> kicking. The only case this actually exists is for VMs. I can see it
>>> being cargo-culted from previous RPi revisions, but that doesn't make
>>> it true.
>> They said that they used this to suppress high interrupt load for the
>> timers.
> Indeed, and that's the only thing the kernel can do if it isn't
> provided with a global timer that can be used as a backup then the
> CPUs transition to a deep idle state where the timers are not actually
> running.
>
> If you have such a global timer, enable it and you'll see the
> interrupt rate dropping like a rock. Don't you have a
> brcm,bcm2835-system-timer stashed somewhere?

I've got the feedback that the system timer still exists. Unfortunately
i don't have the new interrupt definition yet. So i need to wait for
this before sending a new version of this series.

Best regards
Stefan Wahren

>
> If you don't have such a timer, then the question is whether the CPUs
> can go into a deep enough sleep state where the timer comparator is
> disabled, leading to missed events. If this system can only reach very
> shallow sleep states, then always-on is OK. Otherwise, this is a total
> lie and you're likely to miss timer events.
>
> Thanks,
>
> 	M.
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel