diff for duplicates of <1504625867.32565.34.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index cb0767e..3b36e7e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,54 +1,49 @@ -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) 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 - http://patchwork.ozlabs.org/patch/801240/ - 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. - -We may indeed proceed with mentioned solution for ARC but if that makes -sense for somebody else it might worth getting something similar in generic -init code. Any thoughts? - -All comments and suggestions are more than welcome. - --Alexey +SGVsbG8sDQoNCkknZCBsaWtlIHRvIGdldCBzb21lIGZlZWRiYWNrIG9uIG91ciBpZGVhIGFzIHdl +bGwgYXMgY2hlY2sNCmlmIHNvbWVib2R5IGZhY2VzIHNpbWlsYXIgc2l0dWF0aW9ucyBhbmQgaWYg +c28gd2hhdCB3b3VsZCBiZSB0aGUgYmVzdA0Kd2F5IHRvIGltcGxlbWVudCBzb21lIGdlbmVyaWMg +c29sdXRpb24gdGhhdCBzdWl0cyBldmVyeW9uZS4NCg0KU28gdGhhdCdzIG91ciBwcm9ibGVtOg0K +MS4gT24gcG93ZXItb24gaGFyZHdhcmUgbWlnaHQgc3RhcnQgY2xvY2tpbmcgQ1BVIHdpdGggZWl0 +aGVyDQrCoCDCoHRvbyBoaWdoIGZyZXF1ZW5jeSAoc3VjaCB0aGF0IENQVSBtYXkgZ2V0IHN0dWNr +IGF0IHNvbWUgcG9pbnQpDQrCoCDCoG9yIHRvbyBsb3cgZnJlcXVlbmN5Lg0KDQrCoCDCoFRoYXQg +YWxsIHNvdW5kcyBzdHVwaWQgYnV0IGxldCBtZSBlbGFib3JhdGUgYSBiaXQgaGVyZS4NCsKgIMKg +SSdtIHRhbGtpbmcgYWJvdXQgRlBHQS1iYXNlZCBkZXZib2FyZHMgZmlybXdhcmUgZm9yIHdoaWNo +DQrCoCDCoChoZXJlIEkgbWVhbiBqdXN0IGltYWdlIGxvYWRlZCBpbiBGUEdBIHdpdGggQ1BVIGlt +cGxlbWVudGF0aW9uDQrCoCDCoGJ1dCBub3Qgc29tZSBzb2Z0d2FyZSB5ZXQpIG1pZ2h0IG5vdCBi +ZSBzdGFibGUgb3IgYmUgZXZlbiBleHBlcmltZW50YWwuDQoNCsKgIMKgRm9yIGV4YW1wbGUgd2Ug +bWF5IGRlYWwgd2l0aCBkdWFsLWNvcmUgb3IgcXVhZC1jb3JlIGRlc2lnbnMuDQrCoCDCoEZvcm1l +ciBtaWdodCBiZSBPSyBydW5uaW5nIEAxMDBNSHogYW5kIGxhdHRlciBpcyBvbmx5IHVzYWJsZQ0K +wqAgwqBANzVNSHogYW5kIGxvd2VyLiBUaGUgc2ltcGxlc3Qgc29sdXRpb24gbWlnaHQgYmUgdG8g +dXNlIHNvbWUgc2FmZQ0KwqAgwqB2YWx1ZSBiZWZvcmUgc29tZXRoaW5nIGxpa2UgQ1BVZnJlcSBr +aWNrcyBpbi4gQnV0IHdlIGRvbid0IHlldCBoYXZlDQrCoCDCoENQVWZyZXEgZm9yIEFSQyAod2Ug +ZG8gcGxhbiB0byBnZXQgaXQgd29ya2luZyBzb21ldGltZSBzb29uKSB3aGljaA0KwqAgwqBtZWFu +cyBzaW1wbGUgY2hhbmdlIG9mIENQVSBmcmVxdWVuY3kgb25jZSB0aW1lLWtlZXBpbmcgaW5mcmFz +dHJ1Y3R1cmUNCsKgIMKgd2FzIGJyb3VnaHQtdXAgaXMgbm90IGFuIG9wdGlvbi4uLiBJLmUuIHdl +J2xsIGVuZCB1cCB3aXRoIHRoZSBzeXN0ZW0gcnVubmluZw0KwqAgwqBtdWNoIHNsb3dlciBjb21w +YXJlZCB3aGF0IGNvdWxkIGhhdmUgYmVlbiBwb3NzaWJsZS4NCg0KMi4gVXAgdW50aWwgbm93IHdl +IHVzZWQgdG8gZG8gZGlydHkgaGFja3MgaW4gZWFybHkgcGxhdGZvcm0gaW5pdCBjb2RlLg0KwqAg +wqBOYW1lbHkgKHNlZcKgYXhzMTAzX2Vhcmx5X2luaXQoKSBpbsKgYXJjaC9hcmMvcGxhdC1heHMx +MHgvYXhzMTB4LmMpOg0KwqAgwqAgMSkgUmVhZCBDUFUncyAiY2xvY2stZnJlcXVlbmN5IiBmcm9t +IC5kdGIgKHJlbWVtYmVyIHdlJ3JlIG9uIHZlcnkgZWFybHkNCsKgIMKgIMKgIMKgYm9vdCBzdGFn +ZSBzdGlsbCBzbyBubyBleHBhbmRlZCBEZXZUcmVlIHlldCBleGlzdHMpLg0KwqAgwqAgMikgQ2hl +Y2sgaG93IG1hbnkgY29yZXMgd2UgaGF2ZSBhbmQgd2hpY2ggZnJlcSBpcyB1c2FibGUNCsKgIMKg +IDMpIFVwZGF0ZSBQTEwgc2V0dGluZ3MgcmlnaHQgaW4gcGxhY2UgaWYgbmV3IGZyZXEgIT0gZXhp +c3RpbmcgaW4gUExMLg0KDQrCoCDCoEV2ZW4gdGhvdWdoIGl0IGlzIHByb3ZlbiB0byB3b3JrIGJ1 +dCB3aXRoIG1vcmUgcGxhdGZvcm1zIGluIHRoZSBwaXBlbGluZQ0KwqAgwqB3ZSdsbCBuZWVkIHRv +IGNvcHktcGFzdGUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3R1ZmYgYWNyb3NzIGFsbCBhZmZlY3Rl +ZA0KwqAgwqBwbGF0cy4gV2hpY2ggaXMgbm90IG5pY2UuDQoNCsKgIMKgTW9yZW92ZXIgYmFjayBp +biB0aGUgZGF5IHdlIGRpZG4ndCBoYXZlIGEgcHJvcGVyIGNsayBkcml2ZXIgZm9yIENQVSdzIFBM +TC4NCsKgIMKgVGh1cyBhY3Rpbmcgb24gUExMIHJlZ2lzdGVycyByaWdodCBpbiBwbGFjZSB3YXMg +dGhlIG9ubHkgdGhpbmcgd2Ugd2VyZSBhYmxlDQrCoCDCoHRvIGRvLiBOb3cgd2l0aCBpbnRyb2R1 +Y3Rpb24gb2Ygbm9ybWFsIGNsayBkcml2ZXINCsKgIMKgKHNlZcKgZHJpdmVycy9jbGsvYXhzMTB4 +L3BsbF9jbG9jay5jIGluIGxpbnV4LW5leHQpIHdlJ2QgbGlrZSB0byB1dGlsaXplDQrCoCDCoGl0 +IGFuZCBoYXZlIGEgY2xlYW5lciBhbmQgbW9yZSB1bml2ZXJzYWwgc29sdXRpb24gdG8gdGhlIHBy +b2JsZW0uDQoNCsKgIMKgVGhhdCdzIGhvdyBpdCBjb3VsZCBiZSBkb25lIC3CoGh0dHA6Ly9wYXRj +aHdvcmsub3psYWJzLm9yZy9wYXRjaC84MDEyNDAvDQrCoCDCoEJhc2ljYWxseSBpbiBhcmNoaXRl +Y3R1cmUncyB0aW1lX2luaXQoKSB3ZSBjaGVjayBpZiB0aGVyZSdzIGV4cGxpY2l0bHkNCsKgIMKg +c3BlY2lmaWVkICJjbG9jay1mcmVxdWVuY3kiIHBhcmFtZXRlciBpbiBjcHUncyBub2RlIGluIERl +dmljZSBUcmVlIGFuZA0KwqAgwqBpZiB0aGVyZSdzIG9uZSB3ZSBzZXQgaXQgdmlhIGp1c3QgaW5z +dGFudGlhdGVkIGNsayBkcml2ZXIuDQoNCldlIG1heSBpbmRlZWQgcHJvY2VlZCB3aXRoIG1lbnRp +b25lZCBzb2x1dGlvbiBmb3IgQVJDIGJ1dCBpZiB0aGF0IG1ha2VzDQpzZW5zZSBmb3Igc29tZWJv +ZHkgZWxzZSBpdCBtaWdodCB3b3J0aCBnZXR0aW5nIHNvbWV0aGluZyBzaW1pbGFyIGluIGdlbmVy +aWMNCmluaXQgY29kZS4gQW55IHRob3VnaHRzPw0KDQpBbGwgY29tbWVudHMgYW5kIHN1Z2dlc3Rp +b25zIGFyZSBtb3JlIHRoYW4gd2VsY29tZS4NCg0KLUFsZXhleQ== diff --git a/a/content_digest b/N1/content_digest index 4cfb2ae..7cf1106 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,59 +9,54 @@ " devicetree@vger.kernel.org <devicetree@vger.kernel.org>\0" "\00:1\0" "b\0" - "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\240too high frequency (such that CPU may get stuck at some point)\n" - "\302\240 \302\240or too low frequency.\n" - "\n" - "\302\240 \302\240That all sounds stupid but let me elaborate a bit here.\n" - "\302\240 \302\240I'm talking about FPGA-based devboards firmware for which\n" - "\302\240 \302\240(here I mean just image loaded in FPGA with CPU implementation\n" - "\302\240 \302\240but not some software yet) might not be stable or be even experimental.\n" - "\n" - "\302\240 \302\240For example we may deal with dual-core or quad-core designs.\n" - "\302\240 \302\240Former might be OK running @100MHz and latter is only usable\n" - "\302\240 \302\240@75MHz and lower. The simplest solution might be to use some safe\n" - "\302\240 \302\240value before something like CPUfreq kicks in. But we don't yet have\n" - "\302\240 \302\240CPUfreq for ARC (we do plan to get it working sometime soon) which\n" - "\302\240 \302\240means simple change of CPU frequency once time-keeping infrastructure\n" - "\302\240 \302\240was brought-up is not an option... I.e. we'll end up with the system running\n" - "\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\240Namely (see\302\240axs103_early_init() in\302\240arch/arc/plat-axs10x/axs10x.c):\n" - "\302\240 \302\240 1) Read CPU's \"clock-frequency\" from .dtb (remember we're on very early\n" - "\302\240 \302\240 \302\240 \302\240boot stage still so no expanded DevTree yet exists).\n" - "\302\240 \302\240 2) Check how many cores we have and which freq is usable\n" - "\302\240 \302\240 3) Update PLL settings right in place if new freq != existing in PLL.\n" - "\n" - "\302\240 \302\240Even though it is proven to work but with more platforms in the pipeline\n" - "\302\240 \302\240we'll need to copy-paste pretty much the same stuff across all affected\n" - "\302\240 \302\240plats. Which is not nice.\n" - "\n" - "\302\240 \302\240Moreover back in the day we didn't have a proper clk driver for CPU's PLL.\n" - "\302\240 \302\240Thus acting on PLL registers right in place was the only thing we were able\n" - "\302\240 \302\240to do. Now with introduction of normal clk driver\n" - "\302\240 \302\240(see\302\240drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize\n" - "\302\240 \302\240it and have a cleaner and more universal solution to the problem.\n" - "\n" - "\302\240 \302\240That's how it could be done -\302\240http://patchwork.ozlabs.org/patch/801240/\n" - "\302\240 \302\240Basically in architecture's time_init() we check if there's explicitly\n" - "\302\240 \302\240specified \"clock-frequency\" parameter in cpu's node in Device Tree and\n" - "\302\240 \302\240if there's one we set it via just instantiated clk driver.\n" - "\n" - "We may indeed proceed with mentioned solution for ARC but if that makes\n" - "sense for somebody else it might worth getting something similar in generic\n" - "init code. Any thoughts?\n" - "\n" - "All comments and suggestions are more than welcome.\n" - "\n" - -Alexey + "SGVsbG8sDQoNCkknZCBsaWtlIHRvIGdldCBzb21lIGZlZWRiYWNrIG9uIG91ciBpZGVhIGFzIHdl\n" + "bGwgYXMgY2hlY2sNCmlmIHNvbWVib2R5IGZhY2VzIHNpbWlsYXIgc2l0dWF0aW9ucyBhbmQgaWYg\n" + "c28gd2hhdCB3b3VsZCBiZSB0aGUgYmVzdA0Kd2F5IHRvIGltcGxlbWVudCBzb21lIGdlbmVyaWMg\n" + "c29sdXRpb24gdGhhdCBzdWl0cyBldmVyeW9uZS4NCg0KU28gdGhhdCdzIG91ciBwcm9ibGVtOg0K\n" + "MS4gT24gcG93ZXItb24gaGFyZHdhcmUgbWlnaHQgc3RhcnQgY2xvY2tpbmcgQ1BVIHdpdGggZWl0\n" + "aGVyDQrCoCDCoHRvbyBoaWdoIGZyZXF1ZW5jeSAoc3VjaCB0aGF0IENQVSBtYXkgZ2V0IHN0dWNr\n" + "IGF0IHNvbWUgcG9pbnQpDQrCoCDCoG9yIHRvbyBsb3cgZnJlcXVlbmN5Lg0KDQrCoCDCoFRoYXQg\n" + "YWxsIHNvdW5kcyBzdHVwaWQgYnV0IGxldCBtZSBlbGFib3JhdGUgYSBiaXQgaGVyZS4NCsKgIMKg\n" + "SSdtIHRhbGtpbmcgYWJvdXQgRlBHQS1iYXNlZCBkZXZib2FyZHMgZmlybXdhcmUgZm9yIHdoaWNo\n" + "DQrCoCDCoChoZXJlIEkgbWVhbiBqdXN0IGltYWdlIGxvYWRlZCBpbiBGUEdBIHdpdGggQ1BVIGlt\n" + "cGxlbWVudGF0aW9uDQrCoCDCoGJ1dCBub3Qgc29tZSBzb2Z0d2FyZSB5ZXQpIG1pZ2h0IG5vdCBi\n" + "ZSBzdGFibGUgb3IgYmUgZXZlbiBleHBlcmltZW50YWwuDQoNCsKgIMKgRm9yIGV4YW1wbGUgd2Ug\n" + "bWF5IGRlYWwgd2l0aCBkdWFsLWNvcmUgb3IgcXVhZC1jb3JlIGRlc2lnbnMuDQrCoCDCoEZvcm1l\n" + "ciBtaWdodCBiZSBPSyBydW5uaW5nIEAxMDBNSHogYW5kIGxhdHRlciBpcyBvbmx5IHVzYWJsZQ0K\n" + "wqAgwqBANzVNSHogYW5kIGxvd2VyLiBUaGUgc2ltcGxlc3Qgc29sdXRpb24gbWlnaHQgYmUgdG8g\n" + "dXNlIHNvbWUgc2FmZQ0KwqAgwqB2YWx1ZSBiZWZvcmUgc29tZXRoaW5nIGxpa2UgQ1BVZnJlcSBr\n" + "aWNrcyBpbi4gQnV0IHdlIGRvbid0IHlldCBoYXZlDQrCoCDCoENQVWZyZXEgZm9yIEFSQyAod2Ug\n" + "ZG8gcGxhbiB0byBnZXQgaXQgd29ya2luZyBzb21ldGltZSBzb29uKSB3aGljaA0KwqAgwqBtZWFu\n" + "cyBzaW1wbGUgY2hhbmdlIG9mIENQVSBmcmVxdWVuY3kgb25jZSB0aW1lLWtlZXBpbmcgaW5mcmFz\n" + "dHJ1Y3R1cmUNCsKgIMKgd2FzIGJyb3VnaHQtdXAgaXMgbm90IGFuIG9wdGlvbi4uLiBJLmUuIHdl\n" + "J2xsIGVuZCB1cCB3aXRoIHRoZSBzeXN0ZW0gcnVubmluZw0KwqAgwqBtdWNoIHNsb3dlciBjb21w\n" + "YXJlZCB3aGF0IGNvdWxkIGhhdmUgYmVlbiBwb3NzaWJsZS4NCg0KMi4gVXAgdW50aWwgbm93IHdl\n" + "IHVzZWQgdG8gZG8gZGlydHkgaGFja3MgaW4gZWFybHkgcGxhdGZvcm0gaW5pdCBjb2RlLg0KwqAg\n" + "wqBOYW1lbHkgKHNlZcKgYXhzMTAzX2Vhcmx5X2luaXQoKSBpbsKgYXJjaC9hcmMvcGxhdC1heHMx\n" + "MHgvYXhzMTB4LmMpOg0KwqAgwqAgMSkgUmVhZCBDUFUncyAiY2xvY2stZnJlcXVlbmN5IiBmcm9t\n" + "IC5kdGIgKHJlbWVtYmVyIHdlJ3JlIG9uIHZlcnkgZWFybHkNCsKgIMKgIMKgIMKgYm9vdCBzdGFn\n" + "ZSBzdGlsbCBzbyBubyBleHBhbmRlZCBEZXZUcmVlIHlldCBleGlzdHMpLg0KwqAgwqAgMikgQ2hl\n" + "Y2sgaG93IG1hbnkgY29yZXMgd2UgaGF2ZSBhbmQgd2hpY2ggZnJlcSBpcyB1c2FibGUNCsKgIMKg\n" + "IDMpIFVwZGF0ZSBQTEwgc2V0dGluZ3MgcmlnaHQgaW4gcGxhY2UgaWYgbmV3IGZyZXEgIT0gZXhp\n" + "c3RpbmcgaW4gUExMLg0KDQrCoCDCoEV2ZW4gdGhvdWdoIGl0IGlzIHByb3ZlbiB0byB3b3JrIGJ1\n" + "dCB3aXRoIG1vcmUgcGxhdGZvcm1zIGluIHRoZSBwaXBlbGluZQ0KwqAgwqB3ZSdsbCBuZWVkIHRv\n" + "IGNvcHktcGFzdGUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3R1ZmYgYWNyb3NzIGFsbCBhZmZlY3Rl\n" + "ZA0KwqAgwqBwbGF0cy4gV2hpY2ggaXMgbm90IG5pY2UuDQoNCsKgIMKgTW9yZW92ZXIgYmFjayBp\n" + "biB0aGUgZGF5IHdlIGRpZG4ndCBoYXZlIGEgcHJvcGVyIGNsayBkcml2ZXIgZm9yIENQVSdzIFBM\n" + "TC4NCsKgIMKgVGh1cyBhY3Rpbmcgb24gUExMIHJlZ2lzdGVycyByaWdodCBpbiBwbGFjZSB3YXMg\n" + "dGhlIG9ubHkgdGhpbmcgd2Ugd2VyZSBhYmxlDQrCoCDCoHRvIGRvLiBOb3cgd2l0aCBpbnRyb2R1\n" + "Y3Rpb24gb2Ygbm9ybWFsIGNsayBkcml2ZXINCsKgIMKgKHNlZcKgZHJpdmVycy9jbGsvYXhzMTB4\n" + "L3BsbF9jbG9jay5jIGluIGxpbnV4LW5leHQpIHdlJ2QgbGlrZSB0byB1dGlsaXplDQrCoCDCoGl0\n" + "IGFuZCBoYXZlIGEgY2xlYW5lciBhbmQgbW9yZSB1bml2ZXJzYWwgc29sdXRpb24gdG8gdGhlIHBy\n" + "b2JsZW0uDQoNCsKgIMKgVGhhdCdzIGhvdyBpdCBjb3VsZCBiZSBkb25lIC3CoGh0dHA6Ly9wYXRj\n" + "aHdvcmsub3psYWJzLm9yZy9wYXRjaC84MDEyNDAvDQrCoCDCoEJhc2ljYWxseSBpbiBhcmNoaXRl\n" + "Y3R1cmUncyB0aW1lX2luaXQoKSB3ZSBjaGVjayBpZiB0aGVyZSdzIGV4cGxpY2l0bHkNCsKgIMKg\n" + "c3BlY2lmaWVkICJjbG9jay1mcmVxdWVuY3kiIHBhcmFtZXRlciBpbiBjcHUncyBub2RlIGluIERl\n" + "dmljZSBUcmVlIGFuZA0KwqAgwqBpZiB0aGVyZSdzIG9uZSB3ZSBzZXQgaXQgdmlhIGp1c3QgaW5z\n" + "dGFudGlhdGVkIGNsayBkcml2ZXIuDQoNCldlIG1heSBpbmRlZWQgcHJvY2VlZCB3aXRoIG1lbnRp\n" + "b25lZCBzb2x1dGlvbiBmb3IgQVJDIGJ1dCBpZiB0aGF0IG1ha2VzDQpzZW5zZSBmb3Igc29tZWJv\n" + "ZHkgZWxzZSBpdCBtaWdodCB3b3J0aCBnZXR0aW5nIHNvbWV0aGluZyBzaW1pbGFyIGluIGdlbmVy\n" + "aWMNCmluaXQgY29kZS4gQW55IHRob3VnaHRzPw0KDQpBbGwgY29tbWVudHMgYW5kIHN1Z2dlc3Rp\n" + b25zIGFyZSBtb3JlIHRoYW4gd2VsY29tZS4NCg0KLUFsZXhleQ== -cf8ae0ed0c62638493e5905b6caacfc8b5d1fed3cc13cd40861c10caa68e1d0d +0fa12b24c7d83225a408d26a898dd1212d353193119b1dccae833a96830e0507
diff --git a/a/1.txt b/N2/1.txt index cb0767e..11bfb4d 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -6,44 +6,44 @@ 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) 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. +? ?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) 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 - http://patchwork.ozlabs.org/patch/801240/ - 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. +? ?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 -?http://patchwork.ozlabs.org/patch/801240/ +? ?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. We may indeed proceed with mentioned solution for ARC but if that makes sense for somebody else it might worth getting something similar in generic diff --git a/a/content_digest b/N2/content_digest index 4cfb2ae..c80566c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,7 @@ - "From\0Alexey Brodkin <Alexey.Brodkin@synopsys.com>\0" + "From\0Alexey.Brodkin@synopsys.com (Alexey Brodkin)\0" "Subject\0Setting CPU clock frequency on early boot\0" "Date\0Tue, 5 Sep 2017 15:37:48 +0000\0" - "To\0linux-clk@vger.kernel.org <linux-clk@vger.kernel.org>\0" - "Cc\0linux-arch@vger.kernel.org <linux-arch@vger.kernel.org>" - mturquette@baylibre.com <mturquette@baylibre.com> - sboyd@codeaurora.org <sboyd@codeaurora.org> - linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org> - " devicetree@vger.kernel.org <devicetree@vger.kernel.org>\0" + "To\0linux-snps-arc@lists.infradead.org\0" "\00:1\0" "b\0" "Hello,\n" @@ -17,44 +12,44 @@ "\n" "So that's our problem:\n" "1. On power-on hardware might start clocking CPU with either\n" - "\302\240 \302\240too high frequency (such that CPU may get stuck at some point)\n" - "\302\240 \302\240or too low frequency.\n" - "\n" - "\302\240 \302\240That all sounds stupid but let me elaborate a bit here.\n" - "\302\240 \302\240I'm talking about FPGA-based devboards firmware for which\n" - "\302\240 \302\240(here I mean just image loaded in FPGA with CPU implementation\n" - "\302\240 \302\240but not some software yet) might not be stable or be even experimental.\n" - "\n" - "\302\240 \302\240For example we may deal with dual-core or quad-core designs.\n" - "\302\240 \302\240Former might be OK running @100MHz and latter is only usable\n" - "\302\240 \302\240@75MHz and lower. The simplest solution might be to use some safe\n" - "\302\240 \302\240value before something like CPUfreq kicks in. But we don't yet have\n" - "\302\240 \302\240CPUfreq for ARC (we do plan to get it working sometime soon) which\n" - "\302\240 \302\240means simple change of CPU frequency once time-keeping infrastructure\n" - "\302\240 \302\240was brought-up is not an option... I.e. we'll end up with the system running\n" - "\302\240 \302\240much slower compared what could have been possible.\n" + "? ?too high frequency (such that CPU may get stuck at some point)\n" + "? ?or too low frequency.\n" + "\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" + "? ?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) which\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\240Namely (see\302\240axs103_early_init() in\302\240arch/arc/plat-axs10x/axs10x.c):\n" - "\302\240 \302\240 1) Read CPU's \"clock-frequency\" from .dtb (remember we're on very early\n" - "\302\240 \302\240 \302\240 \302\240boot stage still so no expanded DevTree yet exists).\n" - "\302\240 \302\240 2) Check how many cores we have and which freq is usable\n" - "\302\240 \302\240 3) Update PLL settings right in place if new freq != existing in PLL.\n" - "\n" - "\302\240 \302\240Even though it is proven to work but with more platforms in the pipeline\n" - "\302\240 \302\240we'll need to copy-paste pretty much the same stuff across all affected\n" - "\302\240 \302\240plats. Which is not nice.\n" - "\n" - "\302\240 \302\240Moreover back in the day we didn't have a proper clk driver for CPU's PLL.\n" - "\302\240 \302\240Thus acting on PLL registers right in place was the only thing we were able\n" - "\302\240 \302\240to do. Now with introduction of normal clk driver\n" - "\302\240 \302\240(see\302\240drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize\n" - "\302\240 \302\240it and have a cleaner and more universal solution to the problem.\n" - "\n" - "\302\240 \302\240That's how it could be done -\302\240http://patchwork.ozlabs.org/patch/801240/\n" - "\302\240 \302\240Basically in architecture's time_init() we check if there's explicitly\n" - "\302\240 \302\240specified \"clock-frequency\" parameter in cpu's node in Device Tree and\n" - "\302\240 \302\240if there's one we set it via just instantiated clk driver.\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" + "? ?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" + "? ?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" + "? ?That's how it could be done -?http://patchwork.ozlabs.org/patch/801240/\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" "\n" "We may indeed proceed with mentioned solution for ARC but if that makes\n" "sense for somebody else it might worth getting something similar in generic\n" @@ -64,4 +59,4 @@ "\n" -Alexey -cf8ae0ed0c62638493e5905b6caacfc8b5d1fed3cc13cd40861c10caa68e1d0d +18af6e913e8f354bbd44b2a1416b9e3f8810b06d3aa17fce62b44f4456a3d31a
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.