From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Icenowy Zheng To: Andre Przywara , Jean-Francois Moine Cc: "devicetree@vger.kernel.org" , Mike Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , Chen-Yu Tsai , Rob Herring , Maxime Ripard , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" In-Reply-To: <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> References: <20160726203041.29366-1-maxime.ripard@free-electrons.com> <20160801103024.cc74c093466d7fdfd91a2587@free.fr> <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> Subject: Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng MIME-Version: 1.0 Message-Id: <70891470053994@web8m.yandex.ru> Date: Mon, 01 Aug 2016 20:19:54 +0800 Content-Type: text/plain; charset=utf-8 List-ID: Hi Andre, 01.08.2016, 18:48, "Andre Przywara" : > Hi Jean-Francois, > > On 01/08/16 09:30, Jean-Francois Moine wrote: >>  On Mon, 1 Aug 2016 02:43:06 +0100 >>  André Przywara 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: icenowy@aosc.xyz (Icenowy Zheng) Date: Mon, 01 Aug 2016 20:19:54 +0800 Subject: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng In-Reply-To: <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> References: <20160726203041.29366-1-maxime.ripard@free-electrons.com> <20160801103024.cc74c093466d7fdfd91a2587@free.fr> <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> Message-ID: <70891470053994@web8m.yandex.ru> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Andre, 01.08.2016, 18:48, "Andre Przywara" : > Hi Jean-Francois, > > On 01/08/16 09:30, Jean-Francois Moine wrote: >> ?On Mon, 1 Aug 2016 02:43:06 +0100 >> ?Andr? Przywara 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Icenowy Zheng Subject: Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Date: Mon, 01 Aug 2016 20:19:54 +0800 Message-ID: <70891470053994@web8m.yandex.ru> References: <20160726203041.29366-1-maxime.ripard@free-electrons.com> <20160801103024.cc74c093466d7fdfd91a2587@free.fr> <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <8b4d1f09-b1ce-5708-f815-29dbd438c2db@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Andre Przywara , Jean-Francois Moine Cc: "devicetree@vger.kernel.org" , Mike Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , Chen-Yu Tsai , Rob Herring , Maxime Ripard , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org SGkgQW5kcmUsCgowMS4wOC4yMDE2LCAxODo0OCwgIkFuZHJlIFByenl3YXJhIiA8YW5kcmUucHJ6 eXdhcmFAYXJtLmNvbT46Cj4gSGkgSmVhbi1GcmFuY29pcywKPgo+IE9uIDAxLzA4LzE2IDA5OjMw LCBKZWFuLUZyYW5jb2lzIE1vaW5lIHdyb3RlOgo+PiDCoE9uIE1vbiwgMSBBdWcgMjAxNiAwMjo0 MzowNiArMDEwMAo+PiDCoEFuZHLDqSBQcnp5d2FyYSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT4g d3JvdGU6Cj4+Cj4+PiDCoEFzIHRoaXMgYmVjYW1lIHF1aXRlIGEgbG9uZyByZWFkLCBoZXJlIGEg VEw7RFI6Cj4+PiDCoC0gV2UgY29uc2lkZXIgdXNpbmcgYW4gU0NQSSBiYXNlZCBjbG9jayBzeXN0 ZW0gZm9yIHRoZSBBNjQsIGFsb25nc2lkZQo+Pj4gwqBhbGx3aW5uZXIsc2ltcGxlLWdhdGVzIGFu ZCBmaXhlZCBjbG9ja3MuIFdlIHRyeSB0byBhdm9pZCBhbnkgQWxsd2lubmVyCj4+PiDCoHNwZWNp ZmljIGNsb2NrcyAoYXBhcnQgZnJvbSB0aGUgc2ltcGxlLWdhdGVzKS4KPj4+IMKgLSBBUk0gVHJ1 c3RlZCBGaXJtd2FyZSBwcm92aWRlcyB0aGUgU0NQSSBpbXBsZW1lbnRhdGlvbiAtIGZvciBub3cs IGxhdGVyCj4+PiDCoHdlIG1heSBtb3ZlIHRoaXMgaW50byBhIHBvc3NpYmxlIGFyaXNjIGZpcm13 YXJlLgo+Pj4gwqAtIFdlIHVwc3RyZWFtIHNvbWUgYmFzaWMgRFQgZmlyc3QsIHBvc3NpYmx5IG9t aXR0aW5nIGFueSBjb250cm92ZXJzaWFsCj4+PiDCoGNsb2NrIHBhcnRzIGF0IGFsbC4KPj4+Cj4+ PiDCoExldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rIQo+Pgo+PiDCoEhpIEFuZHLDqSwKPj4KPj4g wqBUaGlzIGxvb2tzIGludGVyZXN0aW5nLgo+PiDCoEFzIEkgdW5kZXJzdGFuZCwgdGhlIGNsb2Nr IGVuYWJsZS9yYXRlIHNldHRpbmcgZnVuY3Rpb25zIHdvdWxkIGJlIGluCj4+IMKgdGhlIGFyaXNj LiBUaGUgYXJpc2MgZmlybXdhcmUgd291bGQgYmUgbG9hZGVkIG9ubHkgb25jZSBpbiB0aGUgU29j IGFuZAo+PiDCoHdvdWxkIGNvbnRhaW4gdGhlIGNvZGUgZm9yIGhhbmRsaW5nIHRoaXMgc3BlY2lm aWMgU29DLgo+PiDCoEZyb20gbXkgY2FsY3VsYXRpb25zLCB0aGlzIHdvdWxkIHNhdmUgYWJvdXQg MU1iIG9mIGNsb2NrIGRlc2NyaXB0aW9ucwo+PiDCoGluIHRoZSBrZXJuZWwgZm9yIGEgdW5pdmVy c2FsIEFsbHdpbm5lciBrZXJuZWwuCj4KPiBUaGlzIGlzIHRoZSByb3VnaCBpZGVhLCB5ZXMuIElu IHRoZSBtb21lbnQgdGhlIGNsb2NrIGNvZGUgc2l0cyBpbiB0aGUKPiBBUk0gVHJ1c3RlZCBGaXJt d2FyZSBwYXJ0LCBidXQgaW4gZmFjdCB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4K PiBUaGVvcmV0aWNhbGx5IHdlIGNvdWxkIGFsc28gbW92ZSB0aGF0IGNsb2NrIGNvZGUgdG8gVS1C b290IG9uIDMyLWJpdAo+IFNvQ3MgdG8gc2l0IG5leHQgdG8gdGhlIFBTQ0kgaW1wbGVtZW50YXRp b24sIHdoaWNoIHVzZXMgdGhlIHNhbWUgc21jCj4gY2FsbCBtZWNoYW5pc20gYXMgSSBkbyBpbiB0 aGlzIGZpcnN0IGltcGxlbWVudGF0aW9uLgo+IEJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGNhbm5vdCBy ZW1vdmUgdGhlIGV4aXN0aW5nIGNvZGUgZnJvbSB0aGUga2VybmVsLAo+IHNpbmNlIHRoYXQgd291 bGQgYnJlYWsgYWxsIGV4aXN0aW5nIHVzZXJzICh1bmxlc3MgdGhleSB1cGdyYWRlIHRoZWlyCj4g ZmlybXdhcmUpLiBTbyBJIGFtIG5vdCBzdXJlIGlmIHN1cHBvcnRpbmcgb2xkZXIgU29DcyB3aXRo IHRoaXMgbWVjaGFuaXNtCj4gaXMgd29ydGh3aGlsZS4KPgo+IEJ1dDogeWVzLCBJIHdhbnQgdG8g YXZvaWQgYWRkaW5nIHRlZGlvdXMgY2xvY2sgZGVzY3JpcHRpb25zIGZvciBlYWNoIGFuZAo+IGV2 ZXJ5IG5ldyBTb0MgdG8gdGhlIGtlcm5lbC4gV2hhdCByZWFsbHkgd29ycmllcyBtZSBpcyB0aGF0 IHN1bnhpLW5nCj4gbWFrZXMgdGhpcyBzaXR1YXRpb24gcHJvYmFibHkgd29yc2UsIGFzIHdlIG5v dyBoYXZlIHRvIGFkZCBTb0Mgc3BlY2lmaWMKPiAiY29kZSIgKGluIGZhY3Q6IGNsb2NrIGRlc2Ny aXB0aW9ucykgZm9yIGV2ZXJ5IFNvQywgZXZlbiBpZiB0aGF0IGNoaXAKPiBkb2Vzbid0IGludHJv ZHVjZSBhbnkgbmV3IGNsb2NrIHR5cGUuCj4KPj4gwqBCdXQgSSBkb24ndCBzZWUgd2h5IHlvdSBh cmUga2VlcGluZyB0aGUgc2ltcGxlLWdhdGVzLiBUaGUgYnVzIGdhdGUgbWF5Cj4+IMKgYmUgdW5n YXRlZC9nYXRlZCB3aGVuIHRoZSBjbG9jayBpcyBlbmFibGVkL2Rpc2FibGVkLCBhbmQgdGhhdCdz IHdoYXQKPj4gwqBBbGx3aW5uZXIncyBzb2Z0d2FyZSBkb2VzLgo+Cj4gV2UgY291bGQgZG8uIEJ1 dCBTQ1BJIGRvZXMgbm90IGhhdmUgYW4gZXhwbGljaXQgZW5hYmxlL2Rpc2FibGUKPiBpbnRlcmZh Y2UsIGl0IG9ubHkgZGVzY3JpYmVzIHRoYXQgc2V0dGluZyB0aGUgZnJlcXVlbmN5IHRvIDAgZGlz YWJsZXMKPiB0aGUgY2xvY2suIEZvciBlbmFibGluZyBpdCBvbmUgd291bGQgaGF2ZSB0byBzZXQg c29tZSBmcmVxdWVuY3kgKCE9IDApLAo+IHdoaWNoIHRoZSBmaXJtd2FyZSBjb3VsZCB0aGVuIHRy YW5zbGF0ZSBpbnRvIGEgInNldCB0aGF0IGJpdCBpbiB0aGUgZ2F0ZQo+IHJlZ2lzdGVyIiBmb3Ig YW55IGdhdGUtb25seSBjbG9jaywgd2hpY2ggc291bmRzIHJhdGhlciBoYWNraXNoIHRvIG1lLgo+ IEFsc28gaXQgd291bGQgcmVxdWlyZSB0byBhbHRlciB0aGUgU0NQSSBjbG9jayBkcml2ZXIgdG8g aW1wbGVtZW50IHRoZQo+IGVuYWJsZS9kaXNhYmxlIG9wcywgc2luY2UgSSB0aGluayB3ZSBuZXZl ciBjYWxsIHNldF9yYXRlIGZvciB0aG9zZSBjbG9ja3MuCj4KPiBTbyBoYXZpbmcgdGhlIHF1aXRl IHN0cmFpZ2h0IGZvcndhcmQgInNpbXBsZS1nYXRlcyIgZHJpdmVyIGFyb3VuZCBzZWVtcwo+IG1v cmUgc2FuZS4gSW4gdGhlIGVuZCB0aGlzIGRyaXZlciBqdXN0IHRyYW5zbGF0ZXMgImNsb2NrIG51 bWJlciB4IiBpbnRvCj4gImJpdCBudW1iZXIgeCIgaW4gdGhhdCByZWdpc3Rlciwgd2hpY2ggaXMg dmVyeSBnZW5lcmljLiBUaGF0J3Mgd2h5IEkKPiB1cmdlZCB0byBpbnRyb2R1Y2UgYSBmYWxsYmFj ayBjb21wYXRpYmxlIG5hbWUgdG8gZXhwcmVzcyB0aGlzIHZlcnkgZmVhdHVyZS4KPgo+IENoZWVy cywKPiBBbmRyZS4KPgpJdCBtYXkgYmUgdW5wb2xpdGUgdG8gc2F5IHRoYXQsIGJ1dCBJIGp1c3Qg d2FudCBhIHdvcmtpbmcgQTY0IG1haW5saW5lIGtlcm5lbCBhdCBmaXJzdC4KSSdtIHRyeWluZyB0 byBzdWJtaXQgdGhlIGRyaXZlcnMgb2YgdGhlIGNoYW5nZWQgSVAgYmxvY2tzIG5vdywgYnV0IGl0 J3MgYSBwaXR5IHRoYXQgSQpjYW5ub3Qgc3VibWl0IHRoZSBEVCBwYXRjaGVzIG5vdy4KY2xvY2st bmcgaXMgYXQgbGVhc3Qgbm93IGEgdXNhYmxlIHNvbHV0aW9uLgpPciBjYW4geW91IHdvcmsgb3V0 IHN1Y2ggYSBmaXJtd2FyZS1iYXNlZCBjbG9jayBkcml2ZXIgYXMgc29vbiBhcyBwb3NzaWJsZT8K CkknbSBleHBlY3RpbmcgeW91ciBTQ1BJLWJhc2VkIGRyaXZlciEKKEFSTSBpcyBub3cgc3VjaCBh IG1lc3MgdGhhdCBpdCByZWFsbHkgbmVlZHMgYSBzdGFuZGFyZC4pCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBsaW51eC1hcm0ta2VybmVsIG1haWxp bmcgbGlzdAo+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwo+IGh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtl cm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0 dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5l bAo=