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

[Marc Zyngier <marc.zyngier@arm.com>]

On 30/07/2019 19:33, Stefan Wahren wrote:
> 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.

From what I gather, these stubs can be updated (and apparently are
updated regularly). So why not fix them once and for all?

> 
>>
>>>>> +		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.

Sure, no problem. I also wonder whether the SoC has the memory-mapped
generic timer, which would make a lot of sense...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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