diff for duplicates of <1504705881.3829.19.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index 01759eb..36ad641 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,98 +1,97 @@ -Hi Vineet, Rob, - -On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: -> On 09/05/2017 03:04 PM, Rob Herring wrote: -> > -> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin -> > <Alexey.Brodkin@synopsys.com> wrote: -> > > -> > > Hello, -> > > -> > > I'd like to get some feedback on our idea as well as check -> > > if somebody faces similar situations and if so what would be the best -> > > way to implement some generic solution that suits everyone. -> > > -> > > So that's our problem: -> > > 1. On power-on hardware might start clocking CPU with either -> > > too high frequency (such that CPU may get stuck at some point) -> > > or too low frequency. -> > > -> > > That all sounds stupid but let me elaborate a bit here. -> > > I'm talking about FPGA-based devboards firmware for which -> > > (here I mean just image loaded in FPGA with CPU implementation -> > > but not some software yet) might not be stable or be even experimental. -> > > -> > > For example we may deal with dual-core or quad-core designs. -> > > Former might be OK running @100MHz and latter is only usable -> > > @75MHz and lower. The simplest solution might be to use some safe -> > > value before something like CPUfreq kicks in. But we don't yet have -> > > CPUfreq for ARC (we do plan to get it working sometime soon) -> -> But even if we had cpufreq driver going - I don't think it would be usable for -> doing large freq switches, since in current implementations of SoCs (or fpga), the -> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as -> discussed before (and pointed to by tglx), timer subsys can't tolerate (on -> purpose) such large drifts. - -Essentially cpufreq only makes sense for "compatible" systems and unfortunately -most of our current boards are not capable due to missing constant [decoupled from -CPU frequency] clock source. But looking forward we are planning to improve on that -so that hopefully even our FPGA-based boards will be usable with cpufreq. - -> > > which -> > > means simple change of CPU frequency once time-keeping infrastructure -> > > was brought-up is not an option... I.e. we'll end up with the system running -> > > much slower compared what could have been possible. -> > > -> > > 2. Up until now we used to do dirty hacks in early platform init code. -> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): -> > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very early -> > > boot stage still so no expanded DevTree yet exists). -> > > 2) Check how many cores we have and which freq is usable -> > > 3) Update PLL settings right in place if new freq != existing in PLL. -> > > -> > > Even though it is proven to work but with more platforms in the pipeline -> > > we'll need to copy-paste pretty much the same stuff across all affected -> > > plats. Which is not nice. -> > > -> > > Moreover back in the day we didn't have a proper clk driver for CPU's PLL. -> > > Thus acting on PLL registers right in place was the only thing we were able -> > > to do. Now with introduction of normal clk driver -> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize -> > > it and have a cleaner and more universal solution to the problem. -> > > -> > > That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF -> > > x7AXWqB0tg&r=c14YS-cH- -> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= -> > > Basically in architecture's time_init() we check if there's explicitly -> > > specified "clock-frequency" parameter in cpu's node in Device Tree and -> > > if there's one we set it via just instantiated clk driver. -> > The patch looks generally okay. I'd move all the logic to the clock -> > driver unless perhaps how to set the cpu freq is defined by the -> > architecture. - -Yeah, that's an interesting question. We may indeed move more smarts to the clock driver -but: - 1. We'll have duplicate code in different clock drivers. Even today that kind of clock - setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers). - - 2. Print out of CPU frequency which is used during boot process for us is important as well - especially during bring-up of new HW. - - 3. If there's no dedicated "clock-frequency" parameter in CPU node we won't - change anything so that non-affected platforms will live as they used to. - -That said IMHO proposed implementation is what we want to kep for now. - -> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to -> do the override - is that acceptable ? - -I think we'll switch to more common "clock-frequency" in the next respin. -Indeed "cpu-freq" might be a bit misleading. - -Also FWIW one MIPS platform uses something similar -(even though their property name is not standard but "mips-hpt-frequency"), -see http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10 -http://elixir.free-electrons.com/linux/latest/source/arch/mips/bmips/setup.c#L141. - --Alexey +SGkgVmluZWV0LCBSb2IsDQoNCk9uIFR1ZSwgMjAxNy0wOS0wNSBhdCAxNjo0MCAtMDcwMCwgVmlu +ZWV0IEd1cHRhIHdyb3RlOg0KPiBPbiAwOS8wNS8yMDE3IDAzOjA0IFBNLCBSb2IgSGVycmluZyB3 +cm90ZToNCj4gPiANCj4gPiBPbiBUdWUsIFNlcCA1LCAyMDE3IGF0IDEwOjM3IEFNLCBBbGV4ZXkg +QnJvZGtpbg0KPiA+IDxBbGV4ZXkuQnJvZGtpbkBzeW5vcHN5cy5jb20+IHdyb3RlOg0KPiA+ID4g +DQo+ID4gPiBIZWxsbywNCj4gPiA+IA0KPiA+ID4gSSdkIGxpa2UgdG8gZ2V0IHNvbWUgZmVlZGJh +Y2sgb24gb3VyIGlkZWEgYXMgd2VsbCBhcyBjaGVjaw0KPiA+ID4gaWYgc29tZWJvZHkgZmFjZXMg +c2ltaWxhciBzaXR1YXRpb25zIGFuZCBpZiBzbyB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0DQo+ID4g +PiB3YXkgdG8gaW1wbGVtZW50IHNvbWUgZ2VuZXJpYyBzb2x1dGlvbiB0aGF0IHN1aXRzIGV2ZXJ5 +b25lLg0KPiA+ID4gDQo+ID4gPiBTbyB0aGF0J3Mgb3VyIHByb2JsZW06DQo+ID4gPiAxLiBPbiBw +b3dlci1vbiBoYXJkd2FyZSBtaWdodCBzdGFydCBjbG9ja2luZyBDUFUgd2l0aCBlaXRoZXINCj4g +PiA+IMKgwqDCoMKgdG9vIGhpZ2ggZnJlcXVlbmN5IChzdWNoIHRoYXQgQ1BVIG1heSBnZXQgc3R1 +Y2sgYXQgc29tZSBwb2ludCkNCj4gPiA+IMKgwqDCoMKgb3IgdG9vIGxvdyBmcmVxdWVuY3kuDQo+ +ID4gPiANCj4gPiA+IMKgwqDCoMKgVGhhdCBhbGwgc291bmRzIHN0dXBpZCBidXQgbGV0IG1lIGVs +YWJvcmF0ZSBhIGJpdCBoZXJlLg0KPiA+ID4gwqDCoMKgwqBJJ20gdGFsa2luZyBhYm91dCBGUEdB +LWJhc2VkIGRldmJvYXJkcyBmaXJtd2FyZSBmb3Igd2hpY2gNCj4gPiA+IMKgwqDCoMKgKGhlcmUg +SSBtZWFuIGp1c3QgaW1hZ2UgbG9hZGVkIGluIEZQR0Egd2l0aCBDUFUgaW1wbGVtZW50YXRpb24N +Cj4gPiA+IMKgwqDCoMKgYnV0IG5vdCBzb21lIHNvZnR3YXJlIHlldCkgbWlnaHQgbm90IGJlIHN0 +YWJsZSBvciBiZSBldmVuIGV4cGVyaW1lbnRhbC4NCj4gPiA+IA0KPiA+ID4gwqDCoMKgwqBGb3Ig +ZXhhbXBsZSB3ZSBtYXkgZGVhbCB3aXRoIGR1YWwtY29yZSBvciBxdWFkLWNvcmUgZGVzaWducy4N +Cj4gPiA+IMKgwqDCoMKgRm9ybWVyIG1pZ2h0IGJlIE9LIHJ1bm5pbmcgQDEwME1IeiBhbmQgbGF0 +dGVyIGlzIG9ubHkgdXNhYmxlDQo+ID4gPiDCoMKgwqDCoEA3NU1IeiBhbmQgbG93ZXIuIFRoZSBz +aW1wbGVzdCBzb2x1dGlvbiBtaWdodCBiZSB0byB1c2Ugc29tZSBzYWZlDQo+ID4gPiDCoMKgwqDC +oHZhbHVlIGJlZm9yZSBzb21ldGhpbmcgbGlrZSBDUFVmcmVxIGtpY2tzIGluLiBCdXQgd2UgZG9u +J3QgeWV0IGhhdmUNCj4gPiA+IMKgwqDCoMKgQ1BVZnJlcSBmb3IgQVJDICh3ZSBkbyBwbGFuIHRv +IGdldCBpdCB3b3JraW5nIHNvbWV0aW1lIHNvb24pDQo+IA0KPiBCdXQgZXZlbiBpZiB3ZSBoYWQg +Y3B1ZnJlcSBkcml2ZXIgZ29pbmcgLSBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIHVzYWJsZSBm +b3LCoA0KPiBkb2luZyBsYXJnZSBmcmVxIHN3aXRjaGVzLCBzaW5jZSBpbiBjdXJyZW50IGltcGxl +bWVudGF0aW9ucyBvZiBTb0NzIChvciBmcGdhKSwgdGhlwqANCj4gY2xrL3BsbCBldGMgZHJpdmlu +ZyBjb3JlIChhbmQgYWxsIHRpbWVycyBldGMpIGFyZSBub3QgZml4ZWQgbGlrZSBzYXkgQVJNLiBB +bmQgYXPCoA0KPiBkaXNjdXNzZWQgYmVmb3JlIChhbmQgcG9pbnRlZCB0byBieSB0Z2x4KSwgdGlt +ZXIgc3Vic3lzIGNhbid0IHRvbGVyYXRlIChvbsKgDQo+IHB1cnBvc2UpIHN1Y2ggbGFyZ2UgZHJp +ZnRzLg0KDQpFc3NlbnRpYWxseSBjcHVmcmVxIG9ubHkgbWFrZXMgc2Vuc2UgZm9yICJjb21wYXRp +YmxlIiBzeXN0ZW1zIGFuZCB1bmZvcnR1bmF0ZWx5DQptb3N0IG9mIG91ciBjdXJyZW50IGJvYXJk +cyBhcmUgbm90IGNhcGFibGUgZHVlIHRvIG1pc3NpbmcgY29uc3RhbnQgW2RlY291cGxlZCBmcm9t +DQpDUFUgZnJlcXVlbmN5XSBjbG9jayBzb3VyY2UuIEJ1dCBsb29raW5nIGZvcndhcmQgd2UgYXJl +IHBsYW5uaW5nIHRvIGltcHJvdmUgb24gdGhhdA0Kc28gdGhhdCBob3BlZnVsbHkgZXZlbiBvdXIg +RlBHQS1iYXNlZCBib2FyZHMgd2lsbCBiZSB1c2FibGUgd2l0aCBjcHVmcmVxLg0KDQo+ID4gPiB3 +aGljaA0KPiA+ID4gwqDCoMKgwqBtZWFucyBzaW1wbGUgY2hhbmdlIG9mIENQVSBmcmVxdWVuY3kg +b25jZSB0aW1lLWtlZXBpbmcgaW5mcmFzdHJ1Y3R1cmUNCj4gPiA+IMKgwqDCoMKgd2FzIGJyb3Vn +aHQtdXAgaXMgbm90IGFuIG9wdGlvbi4uLiBJLmUuIHdlJ2xsIGVuZCB1cCB3aXRoIHRoZSBzeXN0 +ZW0gcnVubmluZw0KPiA+ID4gwqDCoMKgwqBtdWNoIHNsb3dlciBjb21wYXJlZCB3aGF0IGNvdWxk +IGhhdmUgYmVlbiBwb3NzaWJsZS4NCj4gPiA+IA0KPiA+ID4gMi4gVXAgdW50aWwgbm93IHdlIHVz +ZWQgdG8gZG8gZGlydHkgaGFja3MgaW4gZWFybHkgcGxhdGZvcm0gaW5pdCBjb2RlLg0KPiA+ID4g +wqDCoMKgwqBOYW1lbHkgKHNlZSBheHMxMDNfZWFybHlfaW5pdCgpIGluIGFyY2gvYXJjL3BsYXQt +YXhzMTB4L2F4czEweC5jKToNCj4gPiA+IMKgwqDCoMKgwqAxKSBSZWFkIENQVSdzICJjbG9jay1m +cmVxdWVuY3kiIGZyb20gLmR0YiAocmVtZW1iZXIgd2UncmUgb24gdmVyeSBlYXJseQ0KPiA+ID4g +wqDCoMKgwqDCoMKgwqDCoGJvb3Qgc3RhZ2Ugc3RpbGwgc28gbm8gZXhwYW5kZWQgRGV2VHJlZSB5 +ZXQgZXhpc3RzKS4NCj4gPiA+IMKgwqDCoMKgwqAyKSBDaGVjayBob3cgbWFueSBjb3JlcyB3ZSBo +YXZlIGFuZCB3aGljaCBmcmVxIGlzIHVzYWJsZQ0KPiA+ID4gwqDCoMKgwqDCoDMpIFVwZGF0ZSBQ +TEwgc2V0dGluZ3MgcmlnaHQgaW4gcGxhY2UgaWYgbmV3IGZyZXEgIT0gZXhpc3RpbmcgaW4gUExM +Lg0KPiA+ID4gDQo+ID4gPiDCoMKgwqDCoEV2ZW4gdGhvdWdoIGl0IGlzIHByb3ZlbiB0byB3b3Jr +IGJ1dCB3aXRoIG1vcmUgcGxhdGZvcm1zIGluIHRoZSBwaXBlbGluZQ0KPiA+ID4gwqDCoMKgwqB3 +ZSdsbCBuZWVkIHRvIGNvcHktcGFzdGUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3R1ZmYgYWNyb3Nz +IGFsbCBhZmZlY3RlZA0KPiA+ID4gwqDCoMKgwqBwbGF0cy4gV2hpY2ggaXMgbm90IG5pY2UuDQo+ +ID4gPiANCj4gPiA+IMKgwqDCoMKgTW9yZW92ZXIgYmFjayBpbiB0aGUgZGF5IHdlIGRpZG4ndCBo +YXZlIGEgcHJvcGVyIGNsayBkcml2ZXIgZm9yIENQVSdzIFBMTC4NCj4gPiA+IMKgwqDCoMKgVGh1 +cyBhY3Rpbmcgb24gUExMIHJlZ2lzdGVycyByaWdodCBpbiBwbGFjZSB3YXMgdGhlIG9ubHkgdGhp +bmcgd2Ugd2VyZSBhYmxlDQo+ID4gPiDCoMKgwqDCoHRvIGRvLiBOb3cgd2l0aCBpbnRyb2R1Y3Rp +b24gb2Ygbm9ybWFsIGNsayBkcml2ZXINCj4gPiA+IMKgwqDCoMKgKHNlZSBkcml2ZXJzL2Nsay9h +eHMxMHgvcGxsX2Nsb2NrLmMgaW4gbGludXgtbmV4dCkgd2UnZCBsaWtlIHRvIHV0aWxpemUNCj4g +PiA+IMKgwqDCoMKgaXQgYW5kIGhhdmUgYSBjbGVhbmVyIGFuZCBtb3JlIHVuaXZlcnNhbCBzb2x1 +dGlvbiB0byB0aGUgcHJvYmxlbS4NCj4gPiA+IA0KPiA+ID4gwqDCoMKgwqBUaGF0J3MgaG93IGl0 +IGNvdWxkIGJlIGRvbmUgLSBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs +P3U9aHR0cC0zQV9fcGF0Y2h3b3JrLm96bGFicy5vcmdfcGF0Y2hfODAxMjQwXyZkPUR3SUNBZyZj +PURQTDZfWF82SmtYRg0KPiA+ID4geDdBWFdxQjB0ZyZyPWMxNFlTLWNILQ0KPiA+ID4ga2RoVE9X +ODlLb3pGaEJ0QkpnczF6WHNjWm9qRVpRMFRIcyZtPXd1VWNjZVk4Q3o1RWhWa2xXTEFnajdSelUz +cnZwYW51anZRM3FUSkswR3cmcz1ONUlCanFfZUN5T2ZfR1JrWnNrenFHaGN6QlBUYnhMSldfTVVm +YXVLdnVBJmU9DQo+ID4gPiDCoMKgwqDCoEJhc2ljYWxseSBpbiBhcmNoaXRlY3R1cmUncyB0aW1l +X2luaXQoKSB3ZSBjaGVjayBpZiB0aGVyZSdzIGV4cGxpY2l0bHkNCj4gPiA+IMKgwqDCoMKgc3Bl +Y2lmaWVkICJjbG9jay1mcmVxdWVuY3kiIHBhcmFtZXRlciBpbiBjcHUncyBub2RlIGluIERldmlj +ZSBUcmVlIGFuZA0KPiA+ID4gwqDCoMKgwqBpZiB0aGVyZSdzIG9uZSB3ZSBzZXQgaXQgdmlhIGp1 +c3QgaW5zdGFudGlhdGVkIGNsayBkcml2ZXIuDQo+ID4gVGhlIHBhdGNoIGxvb2tzIGdlbmVyYWxs +eSBva2F5LiBJJ2QgbW92ZSBhbGwgdGhlIGxvZ2ljIHRvIHRoZSBjbG9jaw0KPiA+IGRyaXZlciB1 +bmxlc3MgcGVyaGFwcyBob3cgdG8gc2V0IHRoZSBjcHUgZnJlcSBpcyBkZWZpbmVkIGJ5IHRoZQ0K +PiA+IGFyY2hpdGVjdHVyZS4NCg0KWWVhaCwgdGhhdCdzIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9u +LiBXZSBtYXkgaW5kZWVkIG1vdmUgbW9yZSBzbWFydHMgdG8gdGhlIGNsb2NrIGRyaXZlcg0KYnV0 +Og0KwqAxLiBXZSdsbCBoYXZlIGR1cGxpY2F0ZSBjb2RlIGluIGRpZmZlcmVudCBjbG9jayBkcml2 +ZXJzLiBFdmVuIHRvZGF5IHRoYXQga2luZCBvZiBjbG9jaw0KwqAgwqAgc2V0dXAgaXMgYXBwbGlj +YWJsZSB0byBBWFMxMHggYW5kIEhTREsgcGxhdGZvcm1zIChhbmQgdGhleSB1c2UgZGlmZmVyZW50 +IGNsb2NrIGRyaXZlcnMpLg0KDQrCoDIuIFByaW50IG91dCBvZiBDUFUgZnJlcXVlbmN5IHdoaWNo +IGlzIHVzZWQgZHVyaW5nIGJvb3QgcHJvY2VzcyBmb3IgdXMgaXMgaW1wb3J0YW50IGFzIHdlbGwN +CsKgIMKgIGVzcGVjaWFsbHkgZHVyaW5nIGJyaW5nLXVwIG9mIG5ldyBIVy4NCg0KwqAzLiBJZiB0 +aGVyZSdzIG5vIGRlZGljYXRlZCAiY2xvY2stZnJlcXVlbmN5IiBwYXJhbWV0ZXIgaW4gQ1BVIG5v +ZGUgd2Ugd29uJ3QNCsKgIMKgIGNoYW5nZSBhbnl0aGluZyBzbyB0aGF0IG5vbi1hZmZlY3RlZCBw +bGF0Zm9ybXMgd2lsbCBsaXZlIGFzIHRoZXkgdXNlZCB0by4NCg0KVGhhdCBzYWlkIElNSE8gcHJv +cG9zZWQgaW1wbGVtZW50YXRpb24gaXMgd2hhdCB3ZSB3YW50IHRvIGtlcCBmb3Igbm93Lg0KDQo+ +IEFsc28gbm90ZSB0aGF0IHRoaXMgY29kZSBpcyB1c2luZyBhIG5ldyAvIGFkaG9jIERUIGJpbmRp +bmcgY3B1LWZyZXEgaW4gY291IG5vZGUgdG/CoA0KPiBkbyB0aGUgb3ZlcnJpZGUgLSBpcyB0aGF0 +IGFjY2VwdGFibGUgPw0KDQpJIHRoaW5rIHdlJ2xsIHN3aXRjaCB0byBtb3JlIGNvbW1vbiAiY2xv +Y2stZnJlcXVlbmN5IiBpbiB0aGUgbmV4dCByZXNwaW4uDQpJbmRlZWQgImNwdS1mcmVxIiBtaWdo +dCBiZSBhIGJpdCBtaXNsZWFkaW5nLg0KDQpBbHNvIEZXSVcgb25lIE1JUFMgcGxhdGZvcm0gdXNl +cyBzb21ldGhpbmcgc2ltaWxhcg0KKGV2ZW4gdGhvdWdoIHRoZWlyIHByb3BlcnR5IG5hbWUgaXMg +bm90IHN0YW5kYXJkIGJ1dCAibWlwcy1ocHQtZnJlcXVlbmN5IiksDQpzZWXCoGh0dHA6Ly9lbGl4 +aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L2xhdGVzdC9zb3VyY2UvYXJjaC9taXBzL2Jvb3Qv +ZHRzL2JyY20vYmNtMzM2OC5kdHNpI0wxMA0KaHR0cDovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5j +b20vbGludXgvbGF0ZXN0L3NvdXJjZS9hcmNoL21pcHMvYm1pcHMvc2V0dXAuYyNMMTQxLg0KDQot +QWxleGV5 diff --git a/a/content_digest b/N1/content_digest index c4ef37e..1a8225d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -14,103 +14,102 @@ " linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org>\0" "\00:1\0" "b\0" - "Hi Vineet, Rob,\n" - "\n" - "On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:\n" - "> On 09/05/2017 03:04 PM, Rob Herring wrote:\n" - "> > \n" - "> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin\n" - "> > <Alexey.Brodkin@synopsys.com> wrote:\n" - "> > > \n" - "> > > Hello,\n" - "> > > \n" - "> > > I'd like to get some feedback on our idea as well as check\n" - "> > > if somebody faces similar situations and if so what would be the best\n" - "> > > way to implement some generic solution that suits everyone.\n" - "> > > \n" - "> > > So that's our problem:\n" - "> > > 1. On power-on hardware might start clocking CPU with either\n" - "> > > \302\240\302\240\302\240\302\240too high frequency (such that CPU may get stuck at some point)\n" - "> > > \302\240\302\240\302\240\302\240or too low frequency.\n" - "> > > \n" - "> > > \302\240\302\240\302\240\302\240That all sounds stupid but let me elaborate a bit here.\n" - "> > > \302\240\302\240\302\240\302\240I'm talking about FPGA-based devboards firmware for which\n" - "> > > \302\240\302\240\302\240\302\240(here I mean just image loaded in FPGA with CPU implementation\n" - "> > > \302\240\302\240\302\240\302\240but not some software yet) might not be stable or be even experimental.\n" - "> > > \n" - "> > > \302\240\302\240\302\240\302\240For example we may deal with dual-core or quad-core designs.\n" - "> > > \302\240\302\240\302\240\302\240Former might be OK running @100MHz and latter is only usable\n" - "> > > \302\240\302\240\302\240\302\240@75MHz and lower. The simplest solution might be to use some safe\n" - "> > > \302\240\302\240\302\240\302\240value before something like CPUfreq kicks in. But we don't yet have\n" - "> > > \302\240\302\240\302\240\302\240CPUfreq for ARC (we do plan to get it working sometime soon)\n" - "> \n" - "> But even if we had cpufreq driver going - I don't think it would be usable for\302\240\n" - "> doing large freq switches, since in current implementations of SoCs (or fpga), the\302\240\n" - "> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as\302\240\n" - "> discussed before (and pointed to by tglx), timer subsys can't tolerate (on\302\240\n" - "> purpose) such large drifts.\n" - "\n" - "Essentially cpufreq only makes sense for \"compatible\" systems and unfortunately\n" - "most of our current boards are not capable due to missing constant [decoupled from\n" - "CPU frequency] clock source. But looking forward we are planning to improve on that\n" - "so that hopefully even our FPGA-based boards will be usable with cpufreq.\n" - "\n" - "> > > which\n" - "> > > \302\240\302\240\302\240\302\240means simple change of CPU frequency once time-keeping infrastructure\n" - "> > > \302\240\302\240\302\240\302\240was brought-up is not an option... I.e. we'll end up with the system running\n" - "> > > \302\240\302\240\302\240\302\240much slower compared what could have been possible.\n" - "> > > \n" - "> > > 2. Up until now we used to do dirty hacks in early platform init code.\n" - "> > > \302\240\302\240\302\240\302\240Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c):\n" - "> > > \302\240\302\240\302\240\302\240\302\2401) Read CPU's \"clock-frequency\" from .dtb (remember we're on very early\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240boot stage still so no expanded DevTree yet exists).\n" - "> > > \302\240\302\240\302\240\302\240\302\2402) Check how many cores we have and which freq is usable\n" - "> > > \302\240\302\240\302\240\302\240\302\2403) Update PLL settings right in place if new freq != existing in PLL.\n" - "> > > \n" - "> > > \302\240\302\240\302\240\302\240Even though it is proven to work but with more platforms in the pipeline\n" - "> > > \302\240\302\240\302\240\302\240we'll need to copy-paste pretty much the same stuff across all affected\n" - "> > > \302\240\302\240\302\240\302\240plats. Which is not nice.\n" - "> > > \n" - "> > > \302\240\302\240\302\240\302\240Moreover back in the day we didn't have a proper clk driver for CPU's PLL.\n" - "> > > \302\240\302\240\302\240\302\240Thus acting on PLL registers right in place was the only thing we were able\n" - "> > > \302\240\302\240\302\240\302\240to do. Now with introduction of normal clk driver\n" - "> > > \302\240\302\240\302\240\302\240(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize\n" - "> > > \302\240\302\240\302\240\302\240it and have a cleaner and more universal solution to the problem.\n" - "> > > \n" - "> > > \302\240\302\240\302\240\302\240That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF\n" - "> > > x7AXWqB0tg&r=c14YS-cH-\n" - "> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e=\n" - "> > > \302\240\302\240\302\240\302\240Basically in architecture's time_init() we check if there's explicitly\n" - "> > > \302\240\302\240\302\240\302\240specified \"clock-frequency\" parameter in cpu's node in Device Tree and\n" - "> > > \302\240\302\240\302\240\302\240if there's one we set it via just instantiated clk driver.\n" - "> > The patch looks generally okay. I'd move all the logic to the clock\n" - "> > driver unless perhaps how to set the cpu freq is defined by the\n" - "> > architecture.\n" - "\n" - "Yeah, that's an interesting question. We may indeed move more smarts to the clock driver\n" - "but:\n" - "\302\2401. We'll have duplicate code in different clock drivers. Even today that kind of clock\n" - "\302\240 \302\240 setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers).\n" - "\n" - "\302\2402. Print out of CPU frequency which is used during boot process for us is important as well\n" - "\302\240 \302\240 especially during bring-up of new HW.\n" - "\n" - "\302\2403. If there's no dedicated \"clock-frequency\" parameter in CPU node we won't\n" - "\302\240 \302\240 change anything so that non-affected platforms will live as they used to.\n" - "\n" - "That said IMHO proposed implementation is what we want to kep for now.\n" - "\n" - "> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to\302\240\n" - "> do the override - is that acceptable ?\n" - "\n" - "I think we'll switch to more common \"clock-frequency\" in the next respin.\n" - "Indeed \"cpu-freq\" might be a bit misleading.\n" - "\n" - "Also FWIW one MIPS platform uses something similar\n" - "(even though their property name is not standard but \"mips-hpt-frequency\"),\n" - "see\302\240http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10\n" - "http://elixir.free-electrons.com/linux/latest/source/arch/mips/bmips/setup.c#L141.\n" - "\n" - -Alexey + "SGkgVmluZWV0LCBSb2IsDQoNCk9uIFR1ZSwgMjAxNy0wOS0wNSBhdCAxNjo0MCAtMDcwMCwgVmlu\n" + "ZWV0IEd1cHRhIHdyb3RlOg0KPiBPbiAwOS8wNS8yMDE3IDAzOjA0IFBNLCBSb2IgSGVycmluZyB3\n" + "cm90ZToNCj4gPiANCj4gPiBPbiBUdWUsIFNlcCA1LCAyMDE3IGF0IDEwOjM3IEFNLCBBbGV4ZXkg\n" + "QnJvZGtpbg0KPiA+IDxBbGV4ZXkuQnJvZGtpbkBzeW5vcHN5cy5jb20+IHdyb3RlOg0KPiA+ID4g\n" + "DQo+ID4gPiBIZWxsbywNCj4gPiA+IA0KPiA+ID4gSSdkIGxpa2UgdG8gZ2V0IHNvbWUgZmVlZGJh\n" + "Y2sgb24gb3VyIGlkZWEgYXMgd2VsbCBhcyBjaGVjaw0KPiA+ID4gaWYgc29tZWJvZHkgZmFjZXMg\n" + "c2ltaWxhciBzaXR1YXRpb25zIGFuZCBpZiBzbyB3aGF0IHdvdWxkIGJlIHRoZSBiZXN0DQo+ID4g\n" + "PiB3YXkgdG8gaW1wbGVtZW50IHNvbWUgZ2VuZXJpYyBzb2x1dGlvbiB0aGF0IHN1aXRzIGV2ZXJ5\n" + "b25lLg0KPiA+ID4gDQo+ID4gPiBTbyB0aGF0J3Mgb3VyIHByb2JsZW06DQo+ID4gPiAxLiBPbiBw\n" + "b3dlci1vbiBoYXJkd2FyZSBtaWdodCBzdGFydCBjbG9ja2luZyBDUFUgd2l0aCBlaXRoZXINCj4g\n" + "PiA+IMKgwqDCoMKgdG9vIGhpZ2ggZnJlcXVlbmN5IChzdWNoIHRoYXQgQ1BVIG1heSBnZXQgc3R1\n" + "Y2sgYXQgc29tZSBwb2ludCkNCj4gPiA+IMKgwqDCoMKgb3IgdG9vIGxvdyBmcmVxdWVuY3kuDQo+\n" + "ID4gPiANCj4gPiA+IMKgwqDCoMKgVGhhdCBhbGwgc291bmRzIHN0dXBpZCBidXQgbGV0IG1lIGVs\n" + "YWJvcmF0ZSBhIGJpdCBoZXJlLg0KPiA+ID4gwqDCoMKgwqBJJ20gdGFsa2luZyBhYm91dCBGUEdB\n" + "LWJhc2VkIGRldmJvYXJkcyBmaXJtd2FyZSBmb3Igd2hpY2gNCj4gPiA+IMKgwqDCoMKgKGhlcmUg\n" + "SSBtZWFuIGp1c3QgaW1hZ2UgbG9hZGVkIGluIEZQR0Egd2l0aCBDUFUgaW1wbGVtZW50YXRpb24N\n" + "Cj4gPiA+IMKgwqDCoMKgYnV0IG5vdCBzb21lIHNvZnR3YXJlIHlldCkgbWlnaHQgbm90IGJlIHN0\n" + "YWJsZSBvciBiZSBldmVuIGV4cGVyaW1lbnRhbC4NCj4gPiA+IA0KPiA+ID4gwqDCoMKgwqBGb3Ig\n" + "ZXhhbXBsZSB3ZSBtYXkgZGVhbCB3aXRoIGR1YWwtY29yZSBvciBxdWFkLWNvcmUgZGVzaWducy4N\n" + "Cj4gPiA+IMKgwqDCoMKgRm9ybWVyIG1pZ2h0IGJlIE9LIHJ1bm5pbmcgQDEwME1IeiBhbmQgbGF0\n" + "dGVyIGlzIG9ubHkgdXNhYmxlDQo+ID4gPiDCoMKgwqDCoEA3NU1IeiBhbmQgbG93ZXIuIFRoZSBz\n" + "aW1wbGVzdCBzb2x1dGlvbiBtaWdodCBiZSB0byB1c2Ugc29tZSBzYWZlDQo+ID4gPiDCoMKgwqDC\n" + "oHZhbHVlIGJlZm9yZSBzb21ldGhpbmcgbGlrZSBDUFVmcmVxIGtpY2tzIGluLiBCdXQgd2UgZG9u\n" + "J3QgeWV0IGhhdmUNCj4gPiA+IMKgwqDCoMKgQ1BVZnJlcSBmb3IgQVJDICh3ZSBkbyBwbGFuIHRv\n" + "IGdldCBpdCB3b3JraW5nIHNvbWV0aW1lIHNvb24pDQo+IA0KPiBCdXQgZXZlbiBpZiB3ZSBoYWQg\n" + "Y3B1ZnJlcSBkcml2ZXIgZ29pbmcgLSBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIHVzYWJsZSBm\n" + "b3LCoA0KPiBkb2luZyBsYXJnZSBmcmVxIHN3aXRjaGVzLCBzaW5jZSBpbiBjdXJyZW50IGltcGxl\n" + "bWVudGF0aW9ucyBvZiBTb0NzIChvciBmcGdhKSwgdGhlwqANCj4gY2xrL3BsbCBldGMgZHJpdmlu\n" + "ZyBjb3JlIChhbmQgYWxsIHRpbWVycyBldGMpIGFyZSBub3QgZml4ZWQgbGlrZSBzYXkgQVJNLiBB\n" + "bmQgYXPCoA0KPiBkaXNjdXNzZWQgYmVmb3JlIChhbmQgcG9pbnRlZCB0byBieSB0Z2x4KSwgdGlt\n" + "ZXIgc3Vic3lzIGNhbid0IHRvbGVyYXRlIChvbsKgDQo+IHB1cnBvc2UpIHN1Y2ggbGFyZ2UgZHJp\n" + "ZnRzLg0KDQpFc3NlbnRpYWxseSBjcHVmcmVxIG9ubHkgbWFrZXMgc2Vuc2UgZm9yICJjb21wYXRp\n" + "YmxlIiBzeXN0ZW1zIGFuZCB1bmZvcnR1bmF0ZWx5DQptb3N0IG9mIG91ciBjdXJyZW50IGJvYXJk\n" + "cyBhcmUgbm90IGNhcGFibGUgZHVlIHRvIG1pc3NpbmcgY29uc3RhbnQgW2RlY291cGxlZCBmcm9t\n" + "DQpDUFUgZnJlcXVlbmN5XSBjbG9jayBzb3VyY2UuIEJ1dCBsb29raW5nIGZvcndhcmQgd2UgYXJl\n" + "IHBsYW5uaW5nIHRvIGltcHJvdmUgb24gdGhhdA0Kc28gdGhhdCBob3BlZnVsbHkgZXZlbiBvdXIg\n" + "RlBHQS1iYXNlZCBib2FyZHMgd2lsbCBiZSB1c2FibGUgd2l0aCBjcHVmcmVxLg0KDQo+ID4gPiB3\n" + "aGljaA0KPiA+ID4gwqDCoMKgwqBtZWFucyBzaW1wbGUgY2hhbmdlIG9mIENQVSBmcmVxdWVuY3kg\n" + "b25jZSB0aW1lLWtlZXBpbmcgaW5mcmFzdHJ1Y3R1cmUNCj4gPiA+IMKgwqDCoMKgd2FzIGJyb3Vn\n" + "aHQtdXAgaXMgbm90IGFuIG9wdGlvbi4uLiBJLmUuIHdlJ2xsIGVuZCB1cCB3aXRoIHRoZSBzeXN0\n" + "ZW0gcnVubmluZw0KPiA+ID4gwqDCoMKgwqBtdWNoIHNsb3dlciBjb21wYXJlZCB3aGF0IGNvdWxk\n" + "IGhhdmUgYmVlbiBwb3NzaWJsZS4NCj4gPiA+IA0KPiA+ID4gMi4gVXAgdW50aWwgbm93IHdlIHVz\n" + "ZWQgdG8gZG8gZGlydHkgaGFja3MgaW4gZWFybHkgcGxhdGZvcm0gaW5pdCBjb2RlLg0KPiA+ID4g\n" + "wqDCoMKgwqBOYW1lbHkgKHNlZSBheHMxMDNfZWFybHlfaW5pdCgpIGluIGFyY2gvYXJjL3BsYXQt\n" + "YXhzMTB4L2F4czEweC5jKToNCj4gPiA+IMKgwqDCoMKgwqAxKSBSZWFkIENQVSdzICJjbG9jay1m\n" + "cmVxdWVuY3kiIGZyb20gLmR0YiAocmVtZW1iZXIgd2UncmUgb24gdmVyeSBlYXJseQ0KPiA+ID4g\n" + "wqDCoMKgwqDCoMKgwqDCoGJvb3Qgc3RhZ2Ugc3RpbGwgc28gbm8gZXhwYW5kZWQgRGV2VHJlZSB5\n" + "ZXQgZXhpc3RzKS4NCj4gPiA+IMKgwqDCoMKgwqAyKSBDaGVjayBob3cgbWFueSBjb3JlcyB3ZSBo\n" + "YXZlIGFuZCB3aGljaCBmcmVxIGlzIHVzYWJsZQ0KPiA+ID4gwqDCoMKgwqDCoDMpIFVwZGF0ZSBQ\n" + "TEwgc2V0dGluZ3MgcmlnaHQgaW4gcGxhY2UgaWYgbmV3IGZyZXEgIT0gZXhpc3RpbmcgaW4gUExM\n" + "Lg0KPiA+ID4gDQo+ID4gPiDCoMKgwqDCoEV2ZW4gdGhvdWdoIGl0IGlzIHByb3ZlbiB0byB3b3Jr\n" + "IGJ1dCB3aXRoIG1vcmUgcGxhdGZvcm1zIGluIHRoZSBwaXBlbGluZQ0KPiA+ID4gwqDCoMKgwqB3\n" + "ZSdsbCBuZWVkIHRvIGNvcHktcGFzdGUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3R1ZmYgYWNyb3Nz\n" + "IGFsbCBhZmZlY3RlZA0KPiA+ID4gwqDCoMKgwqBwbGF0cy4gV2hpY2ggaXMgbm90IG5pY2UuDQo+\n" + "ID4gPiANCj4gPiA+IMKgwqDCoMKgTW9yZW92ZXIgYmFjayBpbiB0aGUgZGF5IHdlIGRpZG4ndCBo\n" + "YXZlIGEgcHJvcGVyIGNsayBkcml2ZXIgZm9yIENQVSdzIFBMTC4NCj4gPiA+IMKgwqDCoMKgVGh1\n" + "cyBhY3Rpbmcgb24gUExMIHJlZ2lzdGVycyByaWdodCBpbiBwbGFjZSB3YXMgdGhlIG9ubHkgdGhp\n" + "bmcgd2Ugd2VyZSBhYmxlDQo+ID4gPiDCoMKgwqDCoHRvIGRvLiBOb3cgd2l0aCBpbnRyb2R1Y3Rp\n" + "b24gb2Ygbm9ybWFsIGNsayBkcml2ZXINCj4gPiA+IMKgwqDCoMKgKHNlZSBkcml2ZXJzL2Nsay9h\n" + "eHMxMHgvcGxsX2Nsb2NrLmMgaW4gbGludXgtbmV4dCkgd2UnZCBsaWtlIHRvIHV0aWxpemUNCj4g\n" + "PiA+IMKgwqDCoMKgaXQgYW5kIGhhdmUgYSBjbGVhbmVyIGFuZCBtb3JlIHVuaXZlcnNhbCBzb2x1\n" + "dGlvbiB0byB0aGUgcHJvYmxlbS4NCj4gPiA+IA0KPiA+ID4gwqDCoMKgwqBUaGF0J3MgaG93IGl0\n" + "IGNvdWxkIGJlIGRvbmUgLSBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs\n" + "P3U9aHR0cC0zQV9fcGF0Y2h3b3JrLm96bGFicy5vcmdfcGF0Y2hfODAxMjQwXyZkPUR3SUNBZyZj\n" + "PURQTDZfWF82SmtYRg0KPiA+ID4geDdBWFdxQjB0ZyZyPWMxNFlTLWNILQ0KPiA+ID4ga2RoVE9X\n" + "ODlLb3pGaEJ0QkpnczF6WHNjWm9qRVpRMFRIcyZtPXd1VWNjZVk4Q3o1RWhWa2xXTEFnajdSelUz\n" + "cnZwYW51anZRM3FUSkswR3cmcz1ONUlCanFfZUN5T2ZfR1JrWnNrenFHaGN6QlBUYnhMSldfTVVm\n" + "YXVLdnVBJmU9DQo+ID4gPiDCoMKgwqDCoEJhc2ljYWxseSBpbiBhcmNoaXRlY3R1cmUncyB0aW1l\n" + "X2luaXQoKSB3ZSBjaGVjayBpZiB0aGVyZSdzIGV4cGxpY2l0bHkNCj4gPiA+IMKgwqDCoMKgc3Bl\n" + "Y2lmaWVkICJjbG9jay1mcmVxdWVuY3kiIHBhcmFtZXRlciBpbiBjcHUncyBub2RlIGluIERldmlj\n" + "ZSBUcmVlIGFuZA0KPiA+ID4gwqDCoMKgwqBpZiB0aGVyZSdzIG9uZSB3ZSBzZXQgaXQgdmlhIGp1\n" + "c3QgaW5zdGFudGlhdGVkIGNsayBkcml2ZXIuDQo+ID4gVGhlIHBhdGNoIGxvb2tzIGdlbmVyYWxs\n" + "eSBva2F5LiBJJ2QgbW92ZSBhbGwgdGhlIGxvZ2ljIHRvIHRoZSBjbG9jaw0KPiA+IGRyaXZlciB1\n" + "bmxlc3MgcGVyaGFwcyBob3cgdG8gc2V0IHRoZSBjcHUgZnJlcSBpcyBkZWZpbmVkIGJ5IHRoZQ0K\n" + "PiA+IGFyY2hpdGVjdHVyZS4NCg0KWWVhaCwgdGhhdCdzIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9u\n" + "LiBXZSBtYXkgaW5kZWVkIG1vdmUgbW9yZSBzbWFydHMgdG8gdGhlIGNsb2NrIGRyaXZlcg0KYnV0\n" + "Og0KwqAxLiBXZSdsbCBoYXZlIGR1cGxpY2F0ZSBjb2RlIGluIGRpZmZlcmVudCBjbG9jayBkcml2\n" + "ZXJzLiBFdmVuIHRvZGF5IHRoYXQga2luZCBvZiBjbG9jaw0KwqAgwqAgc2V0dXAgaXMgYXBwbGlj\n" + "YWJsZSB0byBBWFMxMHggYW5kIEhTREsgcGxhdGZvcm1zIChhbmQgdGhleSB1c2UgZGlmZmVyZW50\n" + "IGNsb2NrIGRyaXZlcnMpLg0KDQrCoDIuIFByaW50IG91dCBvZiBDUFUgZnJlcXVlbmN5IHdoaWNo\n" + "IGlzIHVzZWQgZHVyaW5nIGJvb3QgcHJvY2VzcyBmb3IgdXMgaXMgaW1wb3J0YW50IGFzIHdlbGwN\n" + "CsKgIMKgIGVzcGVjaWFsbHkgZHVyaW5nIGJyaW5nLXVwIG9mIG5ldyBIVy4NCg0KwqAzLiBJZiB0\n" + "aGVyZSdzIG5vIGRlZGljYXRlZCAiY2xvY2stZnJlcXVlbmN5IiBwYXJhbWV0ZXIgaW4gQ1BVIG5v\n" + "ZGUgd2Ugd29uJ3QNCsKgIMKgIGNoYW5nZSBhbnl0aGluZyBzbyB0aGF0IG5vbi1hZmZlY3RlZCBw\n" + "bGF0Zm9ybXMgd2lsbCBsaXZlIGFzIHRoZXkgdXNlZCB0by4NCg0KVGhhdCBzYWlkIElNSE8gcHJv\n" + "cG9zZWQgaW1wbGVtZW50YXRpb24gaXMgd2hhdCB3ZSB3YW50IHRvIGtlcCBmb3Igbm93Lg0KDQo+\n" + "IEFsc28gbm90ZSB0aGF0IHRoaXMgY29kZSBpcyB1c2luZyBhIG5ldyAvIGFkaG9jIERUIGJpbmRp\n" + "bmcgY3B1LWZyZXEgaW4gY291IG5vZGUgdG/CoA0KPiBkbyB0aGUgb3ZlcnJpZGUgLSBpcyB0aGF0\n" + "IGFjY2VwdGFibGUgPw0KDQpJIHRoaW5rIHdlJ2xsIHN3aXRjaCB0byBtb3JlIGNvbW1vbiAiY2xv\n" + "Y2stZnJlcXVlbmN5IiBpbiB0aGUgbmV4dCByZXNwaW4uDQpJbmRlZWQgImNwdS1mcmVxIiBtaWdo\n" + "dCBiZSBhIGJpdCBtaXNsZWFkaW5nLg0KDQpBbHNvIEZXSVcgb25lIE1JUFMgcGxhdGZvcm0gdXNl\n" + "cyBzb21ldGhpbmcgc2ltaWxhcg0KKGV2ZW4gdGhvdWdoIHRoZWlyIHByb3BlcnR5IG5hbWUgaXMg\n" + "bm90IHN0YW5kYXJkIGJ1dCAibWlwcy1ocHQtZnJlcXVlbmN5IiksDQpzZWXCoGh0dHA6Ly9lbGl4\n" + "aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L2xhdGVzdC9zb3VyY2UvYXJjaC9taXBzL2Jvb3Qv\n" + "ZHRzL2JyY20vYmNtMzM2OC5kdHNpI0wxMA0KaHR0cDovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5j\n" + "b20vbGludXgvbGF0ZXN0L3NvdXJjZS9hcmNoL21pcHMvYm1pcHMvc2V0dXAuYyNMMTQxLg0KDQot\n" + QWxleGV5 -4eafc43b44242e175cdf0f64d137761f0822e2263defcc351f6c6dd61ffee436 +cc4ef3504f05400a5dfb291209efa3327e1d2fad4b909d4c177e7ff16be5cd00
diff --git a/a/1.txt b/N2/1.txt index 01759eb..283c437 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,6 +1,6 @@ Hi Vineet, Rob, -On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: +On Tue, 2017-09-05@16:40 -0700, Vineet Gupta wrote: > On 09/05/2017 03:04 PM, Rob Herring wrote: > > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin @@ -14,24 +14,24 @@ On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: > > > > > > So that's our problem: > > > 1. On power-on hardware might start clocking CPU with either -> > > too high frequency (such that CPU may get stuck at some point) -> > > or too low frequency. +> > > ????too high frequency (such that CPU may get stuck at some point) +> > > ????or too low frequency. > > > -> > > That all sounds stupid but let me elaborate a bit here. -> > > I'm talking about FPGA-based devboards firmware for which -> > > (here I mean just image loaded in FPGA with CPU implementation -> > > but not some software yet) might not be stable or be even experimental. +> > > ????That all sounds stupid but let me elaborate a bit here. +> > > ????I'm talking about FPGA-based devboards firmware for which +> > > ????(here I mean just image loaded in FPGA with CPU implementation +> > > ????but not some software yet) might not be stable or be even experimental. > > > -> > > For example we may deal with dual-core or quad-core designs. -> > > Former might be OK running @100MHz and latter is only usable -> > > @75MHz and lower. The simplest solution might be to use some safe -> > > value before something like CPUfreq kicks in. But we don't yet have -> > > CPUfreq for ARC (we do plan to get it working sometime soon) +> > > ????For example we may deal with dual-core or quad-core designs. +> > > ????Former might be OK running @100MHz and latter is only usable +> > > ????@75MHz and lower. The simplest solution might be to use some safe +> > > ????value before something like CPUfreq kicks in. But we don't yet have +> > > ????CPUfreq for ARC (we do plan to get it working sometime soon) > -> But even if we had cpufreq driver going - I don't think it would be usable for -> doing large freq switches, since in current implementations of SoCs (or fpga), the -> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as -> discussed before (and pointed to by tglx), timer subsys can't tolerate (on +> But even if we had cpufreq driver going - I don't think it would be usable for? +> doing large freq switches, since in current implementations of SoCs (or fpga), the? +> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as? +> discussed before (and pointed to by tglx), timer subsys can't tolerate (on? > purpose) such large drifts. Essentially cpufreq only makes sense for "compatible" systems and unfortunately @@ -40,51 +40,51 @@ CPU frequency] clock source. But looking forward we are planning to improve on t so that hopefully even our FPGA-based boards will be usable with cpufreq. > > > which -> > > means simple change of CPU frequency once time-keeping infrastructure -> > > was brought-up is not an option... I.e. we'll end up with the system running -> > > much slower compared what could have been possible. +> > > ????means simple change of CPU frequency once time-keeping infrastructure +> > > ????was brought-up is not an option... I.e. we'll end up with the system running +> > > ????much slower compared what could have been possible. > > > > > > 2. Up until now we used to do dirty hacks in early platform init code. -> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): -> > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very early -> > > boot stage still so no expanded DevTree yet exists). -> > > 2) Check how many cores we have and which freq is usable -> > > 3) Update PLL settings right in place if new freq != existing in PLL. +> > > ????Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): +> > > ?????1) Read CPU's "clock-frequency" from .dtb (remember we're on very early +> > > ????????boot stage still so no expanded DevTree yet exists). +> > > ?????2) Check how many cores we have and which freq is usable +> > > ?????3) Update PLL settings right in place if new freq != existing in PLL. > > > -> > > Even though it is proven to work but with more platforms in the pipeline -> > > we'll need to copy-paste pretty much the same stuff across all affected -> > > plats. Which is not nice. +> > > ????Even though it is proven to work but with more platforms in the pipeline +> > > ????we'll need to copy-paste pretty much the same stuff across all affected +> > > ????plats. Which is not nice. > > > -> > > Moreover back in the day we didn't have a proper clk driver for CPU's PLL. -> > > Thus acting on PLL registers right in place was the only thing we were able -> > > to do. Now with introduction of normal clk driver -> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize -> > > it and have a cleaner and more universal solution to the problem. +> > > ????Moreover back in the day we didn't have a proper clk driver for CPU's PLL. +> > > ????Thus acting on PLL registers right in place was the only thing we were able +> > > ????to do. Now with introduction of normal clk driver +> > > ????(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize +> > > ????it and have a cleaner and more universal solution to the problem. > > > -> > > That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF +> > > ????That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF > > > x7AXWqB0tg&r=c14YS-cH- > > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= -> > > Basically in architecture's time_init() we check if there's explicitly -> > > specified "clock-frequency" parameter in cpu's node in Device Tree and -> > > if there's one we set it via just instantiated clk driver. +> > > ????Basically in architecture's time_init() we check if there's explicitly +> > > ????specified "clock-frequency" parameter in cpu's node in Device Tree and +> > > ????if there's one we set it via just instantiated clk driver. > > The patch looks generally okay. I'd move all the logic to the clock > > driver unless perhaps how to set the cpu freq is defined by the > > architecture. Yeah, that's an interesting question. We may indeed move more smarts to the clock driver but: - 1. We'll have duplicate code in different clock drivers. Even today that kind of clock - setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers). +?1. We'll have duplicate code in different clock drivers. Even today that kind of clock +? ? setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers). - 2. Print out of CPU frequency which is used during boot process for us is important as well - especially during bring-up of new HW. +?2. Print out of CPU frequency which is used during boot process for us is important as well +? ? especially during bring-up of new HW. - 3. If there's no dedicated "clock-frequency" parameter in CPU node we won't - change anything so that non-affected platforms will live as they used to. +?3. If there's no dedicated "clock-frequency" parameter in CPU node we won't +? ? change anything so that non-affected platforms will live as they used to. That said IMHO proposed implementation is what we want to kep for now. -> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to +> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to? > do the override - is that acceptable ? I think we'll switch to more common "clock-frequency" in the next respin. @@ -92,7 +92,7 @@ Indeed "cpu-freq" might be a bit misleading. Also FWIW one MIPS platform uses something similar (even though their property name is not standard but "mips-hpt-frequency"), -see http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10 +see?http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10 http://elixir.free-electrons.com/linux/latest/source/arch/mips/bmips/setup.c#L141. -Alexey diff --git a/a/content_digest b/N2/content_digest index c4ef37e..2b23d03 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,22 +1,15 @@ "ref\01504625867.32565.34.camel@synopsys.com\0" "ref\0CAL_JsqJ7c-raBnb0U+hL+hka7zN3XosX0pU1Sswoq16nbRFb+g@mail.gmail.com\0" "ref\0b8f7f407-303a-2f3c-1a16-bfb385204930@synopsys.com\0" - "From\0Alexey Brodkin <Alexey.Brodkin@synopsys.com>\0" - "Subject\0Re: Setting CPU clock frequency on early boot\0" + "From\0Alexey.Brodkin@synopsys.com (Alexey Brodkin)\0" + "Subject\0Setting CPU clock frequency on early boot\0" "Date\0Wed, 6 Sep 2017 13:51:22 +0000\0" - "To\0robh@kernel.org <robh@kernel.org>" - " Vineet Gupta <Vineet.Gupta1@synopsys.com>\0" - "Cc\0linux-clk@vger.kernel.org <linux-clk@vger.kernel.org>" - linux-arch@vger.kernel.org <linux-arch@vger.kernel.org> - mturquette@baylibre.com <mturquette@baylibre.com> - sboyd@codeaurora.org <sboyd@codeaurora.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - " linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org>\0" + "To\0linux-snps-arc@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Vineet, Rob,\n" "\n" - "On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:\n" + "On Tue, 2017-09-05@16:40 -0700, Vineet Gupta wrote:\n" "> On 09/05/2017 03:04 PM, Rob Herring wrote:\n" "> > \n" "> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin\n" @@ -30,24 +23,24 @@ "> > > \n" "> > > So that's our problem:\n" "> > > 1. On power-on hardware might start clocking CPU with either\n" - "> > > \302\240\302\240\302\240\302\240too high frequency (such that CPU may get stuck at some point)\n" - "> > > \302\240\302\240\302\240\302\240or too low frequency.\n" + "> > > ????too high frequency (such that CPU may get stuck at some point)\n" + "> > > ????or too low frequency.\n" "> > > \n" - "> > > \302\240\302\240\302\240\302\240That all sounds stupid but let me elaborate a bit here.\n" - "> > > \302\240\302\240\302\240\302\240I'm talking about FPGA-based devboards firmware for which\n" - "> > > \302\240\302\240\302\240\302\240(here I mean just image loaded in FPGA with CPU implementation\n" - "> > > \302\240\302\240\302\240\302\240but not some software yet) might not be stable or be even experimental.\n" + "> > > ????That all sounds stupid but let me elaborate a bit here.\n" + "> > > ????I'm talking about FPGA-based devboards firmware for which\n" + "> > > ????(here I mean just image loaded in FPGA with CPU implementation\n" + "> > > ????but not some software yet) might not be stable or be even experimental.\n" "> > > \n" - "> > > \302\240\302\240\302\240\302\240For example we may deal with dual-core or quad-core designs.\n" - "> > > \302\240\302\240\302\240\302\240Former might be OK running @100MHz and latter is only usable\n" - "> > > \302\240\302\240\302\240\302\240@75MHz and lower. The simplest solution might be to use some safe\n" - "> > > \302\240\302\240\302\240\302\240value before something like CPUfreq kicks in. But we don't yet have\n" - "> > > \302\240\302\240\302\240\302\240CPUfreq for ARC (we do plan to get it working sometime soon)\n" + "> > > ????For example we may deal with dual-core or quad-core designs.\n" + "> > > ????Former might be OK running @100MHz and latter is only usable\n" + "> > > ????@75MHz and lower. The simplest solution might be to use some safe\n" + "> > > ????value before something like CPUfreq kicks in. But we don't yet have\n" + "> > > ????CPUfreq for ARC (we do plan to get it working sometime soon)\n" "> \n" - "> But even if we had cpufreq driver going - I don't think it would be usable for\302\240\n" - "> doing large freq switches, since in current implementations of SoCs (or fpga), the\302\240\n" - "> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as\302\240\n" - "> discussed before (and pointed to by tglx), timer subsys can't tolerate (on\302\240\n" + "> But even if we had cpufreq driver going - I don't think it would be usable for?\n" + "> doing large freq switches, since in current implementations of SoCs (or fpga), the?\n" + "> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. And as?\n" + "> discussed before (and pointed to by tglx), timer subsys can't tolerate (on?\n" "> purpose) such large drifts.\n" "\n" "Essentially cpufreq only makes sense for \"compatible\" systems and unfortunately\n" @@ -56,51 +49,51 @@ "so that hopefully even our FPGA-based boards will be usable with cpufreq.\n" "\n" "> > > which\n" - "> > > \302\240\302\240\302\240\302\240means simple change of CPU frequency once time-keeping infrastructure\n" - "> > > \302\240\302\240\302\240\302\240was brought-up is not an option... I.e. we'll end up with the system running\n" - "> > > \302\240\302\240\302\240\302\240much slower compared what could have been possible.\n" + "> > > ????means simple change of CPU frequency once time-keeping infrastructure\n" + "> > > ????was brought-up is not an option... I.e. we'll end up with the system running\n" + "> > > ????much slower compared what could have been possible.\n" "> > > \n" "> > > 2. Up until now we used to do dirty hacks in early platform init code.\n" - "> > > \302\240\302\240\302\240\302\240Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c):\n" - "> > > \302\240\302\240\302\240\302\240\302\2401) Read CPU's \"clock-frequency\" from .dtb (remember we're on very early\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240boot stage still so no expanded DevTree yet exists).\n" - "> > > \302\240\302\240\302\240\302\240\302\2402) Check how many cores we have and which freq is usable\n" - "> > > \302\240\302\240\302\240\302\240\302\2403) Update PLL settings right in place if new freq != existing in PLL.\n" + "> > > ????Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c):\n" + "> > > ?????1) Read CPU's \"clock-frequency\" from .dtb (remember we're on very early\n" + "> > > ????????boot stage still so no expanded DevTree yet exists).\n" + "> > > ?????2) Check how many cores we have and which freq is usable\n" + "> > > ?????3) Update PLL settings right in place if new freq != existing in PLL.\n" "> > > \n" - "> > > \302\240\302\240\302\240\302\240Even though it is proven to work but with more platforms in the pipeline\n" - "> > > \302\240\302\240\302\240\302\240we'll need to copy-paste pretty much the same stuff across all affected\n" - "> > > \302\240\302\240\302\240\302\240plats. Which is not nice.\n" + "> > > ????Even though it is proven to work but with more platforms in the pipeline\n" + "> > > ????we'll need to copy-paste pretty much the same stuff across all affected\n" + "> > > ????plats. Which is not nice.\n" "> > > \n" - "> > > \302\240\302\240\302\240\302\240Moreover back in the day we didn't have a proper clk driver for CPU's PLL.\n" - "> > > \302\240\302\240\302\240\302\240Thus acting on PLL registers right in place was the only thing we were able\n" - "> > > \302\240\302\240\302\240\302\240to do. Now with introduction of normal clk driver\n" - "> > > \302\240\302\240\302\240\302\240(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize\n" - "> > > \302\240\302\240\302\240\302\240it and have a cleaner and more universal solution to the problem.\n" + "> > > ????Moreover back in the day we didn't have a proper clk driver for CPU's PLL.\n" + "> > > ????Thus acting on PLL registers right in place was the only thing we were able\n" + "> > > ????to do. Now with introduction of normal clk driver\n" + "> > > ????(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize\n" + "> > > ????it and have a cleaner and more universal solution to the problem.\n" "> > > \n" - "> > > \302\240\302\240\302\240\302\240That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF\n" + "> > > ????That's how it could be done - https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF\n" "> > > x7AXWqB0tg&r=c14YS-cH-\n" "> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e=\n" - "> > > \302\240\302\240\302\240\302\240Basically in architecture's time_init() we check if there's explicitly\n" - "> > > \302\240\302\240\302\240\302\240specified \"clock-frequency\" parameter in cpu's node in Device Tree and\n" - "> > > \302\240\302\240\302\240\302\240if there's one we set it via just instantiated clk driver.\n" + "> > > ????Basically in architecture's time_init() we check if there's explicitly\n" + "> > > ????specified \"clock-frequency\" parameter in cpu's node in Device Tree and\n" + "> > > ????if there's one we set it via just instantiated clk driver.\n" "> > The patch looks generally okay. I'd move all the logic to the clock\n" "> > driver unless perhaps how to set the cpu freq is defined by the\n" "> > architecture.\n" "\n" "Yeah, that's an interesting question. We may indeed move more smarts to the clock driver\n" "but:\n" - "\302\2401. We'll have duplicate code in different clock drivers. Even today that kind of clock\n" - "\302\240 \302\240 setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers).\n" + "?1. We'll have duplicate code in different clock drivers. Even today that kind of clock\n" + "? ? setup is applicable to AXS10x and HSDK platforms (and they use different clock drivers).\n" "\n" - "\302\2402. Print out of CPU frequency which is used during boot process for us is important as well\n" - "\302\240 \302\240 especially during bring-up of new HW.\n" + "?2. Print out of CPU frequency which is used during boot process for us is important as well\n" + "? ? especially during bring-up of new HW.\n" "\n" - "\302\2403. If there's no dedicated \"clock-frequency\" parameter in CPU node we won't\n" - "\302\240 \302\240 change anything so that non-affected platforms will live as they used to.\n" + "?3. If there's no dedicated \"clock-frequency\" parameter in CPU node we won't\n" + "? ? change anything so that non-affected platforms will live as they used to.\n" "\n" "That said IMHO proposed implementation is what we want to kep for now.\n" "\n" - "> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to\302\240\n" + "> Also note that this code is using a new / adhoc DT binding cpu-freq in cou node to?\n" "> do the override - is that acceptable ?\n" "\n" "I think we'll switch to more common \"clock-frequency\" in the next respin.\n" @@ -108,9 +101,9 @@ "\n" "Also FWIW one MIPS platform uses something similar\n" "(even though their property name is not standard but \"mips-hpt-frequency\"),\n" - "see\302\240http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10\n" + "see?http://elixir.free-electrons.com/linux/latest/source/arch/mips/boot/dts/brcm/bcm3368.dtsi#L10\n" "http://elixir.free-electrons.com/linux/latest/source/arch/mips/bmips/setup.c#L141.\n" "\n" -Alexey -4eafc43b44242e175cdf0f64d137761f0822e2263defcc351f6c6dd61ffee436 +6428cd48c43fdf5163e3d869b965b1d1b44cc71373c772eba27f57ef1eeeff18
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.