[PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

From: icenowy@aosc•xyz (Icenowy Zheng)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
Date: Mon, 01 Aug 2016 20:19:54 +0800	[thread overview]
Message-ID: <70891470053994@web8m.yandex.ru> (raw)
In-Reply-To: <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com>

Hi Andre,

01.08.2016, 18:48, "Andre Przywara" <andre.przywara@arm•com>:
> Hi Jean-Francois,
>
> On 01/08/16 09:30, Jean-Francois Moine wrote:
>> ?On Mon, 1 Aug 2016 02:43:06 +0100
>> ?Andr? Przywara <andre.przywara@arm•com> wrote:
>>
>>> ?As this became quite a long read, here a TL;DR:
>>> ?- We consider using an SCPI based clock system for the A64, alongside
>>> ?allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>>> ?specific clocks (apart from the simple-gates).
>>> ?- ARM Trusted Firmware provides the SCPI implementation - for now, later
>>> ?we may move this into a possible arisc firmware.
>>> ?- We upstream some basic DT first, possibly omitting any controversial
>>> ?clock parts at all.
>>>
>>> ?Let me know what you think!
>>
>> ?Hi Andr?,
>>
>> ?This looks interesting.
>> ?As I understand, the clock enable/rate setting functions would be in
>> ?the arisc. The arisc firmware would be loaded only once in the Soc and
>> ?would contain the code for handling this specific SoC.
>> ?From my calculations, this would save about 1Mb of clock descriptions
>> ?in the kernel for a universal Allwinner kernel.
>
> This is the rough idea, yes. In the moment the clock code sits in the
> ARM Trusted Firmware part, but in fact this is an implementation detail.
> Theoretically we could also move that clock code to U-Boot on 32-bit
> SoCs to sit next to the PSCI implementation, which uses the same smc
> call mechanism as I do in this first implementation.
> But unfortunately we cannot remove the existing code from the kernel,
> since that would break all existing users (unless they upgrade their
> firmware). So I am not sure if supporting older SoCs with this mechanism
> is worthwhile.
>
> But: yes, I want to avoid adding tedious clock descriptions for each and
> every new SoC to the kernel. What really worries me is that sunxi-ng
> makes this situation probably worse, as we now have to add SoC specific
> "code" (in fact: clock descriptions) for every SoC, even if that chip
> doesn't introduce any new clock type.
>
>> ?But I don't see why you are keeping the simple-gates. The bus gate may
>> ?be ungated/gated when the clock is enabled/disabled, and that's what
>> ?Allwinner's software does.
>
> We could do. But SCPI does not have an explicit enable/disable
> interface, it only describes that setting the frequency to 0 disables
> the clock. For enabling it one would have to set some frequency (!= 0),
> which the firmware could then translate into a "set that bit in the gate
> register" for any gate-only clock, which sounds rather hackish to me.
> Also it would require to alter the SCPI clock driver to implement the
> enable/disable ops, since I think we never call set_rate for those clocks.
>
> So having the quite straight forward "simple-gates" driver around seems
> more sane. In the end this driver just translates "clock number x" into
> "bit number x" in that register, which is very generic. That's why I
> urged to introduce a fallback compatible name to express this very feature.
>
> Cheers,
> Andre.
>
It may be unpolite to say that, but I just want a working A64 mainline kernel at first.
I'm trying to submit the drivers of the changed IP blocks now, but it's a pity that I
cannot submit the DT patches now.
clock-ng is at least now a usable solution.
Or can you work out such a firmware-based clock driver as soon as possible?

I'm expecting your SCPI-based driver!
(ARM is now such a mess that it really needs a standard.)
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel