diff for duplicates of <1492701221.18176.51.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index 3a9bb0c..e0ff4ec 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,78 +1,94 @@ -SGkgU3RlcGhlbiwNCg0KT24gV2VkLCAyMDE3LTA0LTE5IGF0IDA5OjQ5IC0wNzAwLCBzYm95ZEBj -b2RlYXVyb3JhLm9yZyB3cm90ZToNCj4gT24gMDQvMDUsIFZsYWQgWmFraGFyb3Ygd3JvdGU6DQo+ -ID4gDQo+ID4gSGkgU3RlcGhlbiwNCj4gPiANCj4gPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTg6 -MzUgLTA3MDAsIFN0ZXBoZW4gQm95ZCB3cm90ZToNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g -K8KgwqDCoMKgwqAucGxsX3RhYmxlID0gKHN0cnVjdCBwbGxfb2ZfdGFibGUgW10pew0KPiA+ID4g -PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg -wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAucHJhdGUgPSAyNzAwMDAwMCwNCj4gPiA+IA0KPiA+ -ID4gQ2FuIHRoaXMgYmUgYW5vdGhlciBjbGsgaW4gdGhlIGZyYW1ld29yayBpbnN0ZWFkIG9mIGhh -cmRjb2RpbmcNCj4gPiA+IHRoZSBwYXJlbnQgcmF0ZT8NCj4gPiANCj4gPiBJbiBmYWN0IHRoZXJl -IGlzIGFub3RoZXIgY2xrIGluIHRoZSBmcmFtZXdvcmsgdGhhdCByZXByZXNlbnRzIHRoaXMgcGFy -ZW50IGNsb2NrLiBCdXQgdGhpcyBmaWVsZCBpcyBuZWVkZWQgdG8gZ2V0DQo+ID4gYXBwcm9wcmlh -dGUgcGxsX2NmZ190YWJsZSBhcyBpdCBkZXBlbmRzIG9uIHBhcmVudCBjbG9jayBmcmVxdWVuY3ku -IEJlbG93IGluIHBsbF9jZmdfZ2V0IGZ1bmN0aW9uIHdlIGFyZSBzZWFyY2hpbmcNCj4gPiBmb3IN -Cj4gPiB0aGUgY29ycmVjdCB0YWJsZSBjb21wYXJpbmcgLnBhcmVudF9ub2RlIGZpZWxkIHdpdGgg -cmVhbCBoYXJkd2FyZSBwYXJlbnQgY2xvY2sgZnJlcXVlbmN5Og0KPiA+IC0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LQ0KPiA+IGZvciAoaSA9IDA7IHBsbF90YWJsZVtpXS5wcmF0ZSAhPSAwOyBpKyspDQo+ID4gwqAg -wqAgaWYgKHBsbF90YWJsZVtpXS5wcmF0ZSA9PSBwcmF0ZSkNCj4gPiDCoCDCoCDCoCDCoCByZXR1 -cm4gcGxsX3RhYmxlW2ldLnBsbF9jZmdfdGFibGU7DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K -PiBXaGVuIGlzIHRoYXQgZG9uZSB0aG91Z2g/IER1cmluZyByb3VuZF9yYXRlIGFuZCByZWNhbGNf -cmF0ZSB0aGUNCj4gcGFyZW50IGZyZXF1ZW5jeSBpcyBwYXNzZWQgaW50byB0aGUgZnVuY3Rpb24s -IHNvIGl0IHNob3VsZCBiZQ0KPiBwb3NzaWJsZSB0byB1c2UgdGhhdCBpZiB0aGUgdHJlZSBpcyBw -cm9wZXJseSBleHByZXNzZWQuDQo+IA0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2ZW4ndCB1bmRlcnN0 -b29kIGVhY2ggb3RoZXIgY29ycmVjdGx5Lg0KQW55d2F5IEkgaGF2ZSBjaGVja2VkIG91dCBvdXIg -aGFyZHdhcmUgZG9jdW1lbnRhdGlvbnMgYW5kIGZpbmQgb3V0IHRoYXQgaW4gZmFjdCBmb3IgdG9k -YXkncyB2ZXJzaW9uIG9mIGhhcmR3YXJlIHdlIGRvbid0DQpoYXZlIHNpdHVhdGlvbnMgd2hlbiBz -dWNoIHBsbHMgY2FuIGJlIGRyaXZlbiBieSBkaWZmZXJlbnQgcGFyZW50IGNsb2NrLiBTbyB0aGlz -IGFwcHJvYWNoIGlzIG5vdCByZXF1aXJlZCBhdCB0aGUgbW9tZW50Lg0KSSBhbSBnb2luZyB0byBz -aW1wbGlmeSBteSBkcml2ZXIgc28gaXQgd2lsbCByZWZsZWN0IGN1cnJlbnQgdmVyc2lvbiBvZiBo -YXJkd2FyZSBhbmQgaWYgYW55dGhpbmcgY2hhbmdlcyBJIHdpbGwgYmV0dGVyDQpwcm92aWRlIGEg -bmV3IHBhdGNoLg0KDQo+ID4gU3VyZS4gQ291bGQgeW91IGJlIHNvIGtpbmQgdG8gZXhwbGFpbiB3 -aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaHcgYW5kIG5vbi1odyBiYXNlZCBwcm92aWRl -ciBhbmQgY2xrDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gZnVuY3Rpb25zIHBsZWFzZT8gSW4gd2hp -Y2ggY2FzZXMgdGhleSBhcmUgcHJlZmVycmVkP8KgDQo+ID4gDQo+IA0KPiBXZSdyZSB0cnlpbmcg -dG8gc3BsaXQgdGhlIGNvbnN1bWVyIGFuZCBwcm92aWRlciBBUElzIGFsb25nIHN0cnVjdA0KPiBj -bGtfaHcgYW5kIHN0cnVjdCBjbGsgcmVzcGVjdGl2ZWx5LiBJZiB3ZSBjYW4gaGF2ZSBkcml2ZXJz -IG9ubHkNCj4gcmVnaXN0ZXJzIGNsa19odyBwb2ludGVycyBhbmQgbmV2ZXIgZ2V0IGJhY2sgYW55 -dGhpbmcgYnV0IGFuDQo+IGVycm9yIGNvZGUsIHRoZW4gd2UgY2FuIGZvcmNlIGNvbnN1bWVycyB0 -byBhbHdheXMgZ28gdGhyb3VnaCB0aGUNCj4gY2xrX2dldCgpIGZhbWlseSBvZiBBUElzLiBUaGVu -IHdlIGNhbiBlYXNpbHkgdGVsbCB3aG8gaXMgYQ0KPiBwcm92aWRlciwgd2hvIGlzIGEgY29uc3Vt -ZXIsIGFuZCB3aG8gaXMgYSBwcm92aWRlciArIGEgY29uc3VtZXIuDQo+IFJpZ2h0IG5vdyB0aGlz -IGlzbid0IGFsd2F5cyBjbGVhciBjdXQgYmVjYXVzZSBjbGtfaHcgaGFzIGFjY2Vzcw0KPiB0byBz -dHJ1Y3QgY2xrLCBhbmQgYWxzbyBjbGtfcmVnaXN0ZXIoKSByZXR1cm5zIGEgY2xrIHBvaW50ZXIs -IGJ1dA0KPiBpdCBkb2Vzbid0IHJlYWxseSBnZXQgdXNlZCBieSBhbnl0aGluZyBpbiBhIHByb3Zp -ZGVyIGRyaXZlciwNCj4gdW5sZXNzIHByb3ZpZGVyIGRyaXZlcnMgYXJlIGRvaW5nIHNvbWV0aGlu -ZyB3aXRoIHRoZSBjb25zdW1lcg0KPiBBUEkuDQoNCkkgYW0gc29ycnkgZm9yIG15IGZvb2xpc2gg -cXVlc3Rpb25zLCBidXQgYXMgSSB1bmRlcnN0YW5kIEkgc2hvdWxkIHVzZSBody1iYXNlZCBmdW5j -dGlvbnMgZm9yIGNsayBwcm92aWRlcnMgYnV0IGl0IGlzIG5vdA0Kc3RpbGwgY2xlYXIgZW5vdWdo -IGZvciBtZSB3aGVuIHNob3VsZCBJIHVzZSBub24taHcgZnVuY3Rpb25zPyBEb2VzIGFueSBkcml2 -ZXJzIG5lZWQgc3RydWN0IGNsayB3aGVuIHRoZXkgYXJlIGluaXRpYXRpbmcNCm9yIHByb2Jpbmcg -dGhlbXNlbHZlcz8gQW5kIHdoYXQgY2xrIGNvbnN1bWVyIGNhbiBiZSB1c2VkIGZvcj8NCg0KPiAN -Cj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiArfQ0KPiA+ID4gPiArDQo+ -ID4gPiA+ICtDTEtfT0ZfREVDTEFSRShheHMxMHhfcGxsX2Nsb2NrLCAic25wcyxheHMxMHgtYXJj -LXBsbC1jbG9jayIsIG9mX3BsbF9jbGtfc2V0dXApOw0KPiA+ID4gDQo+ID4gPiBEb2VzIHRoaXMg -bmVlZCB0byBiZSBDTEtfT0ZfREVDTEFSRV9EUklWRVI/IEkgbWVhbiBkb2VzIHRoZQ0KPiA+ID4g -ZHJpdmVyIG5lZWQgdG8gcHJvYmUgYW5kIGFsc28gaGF2ZSB0aGlzIG9mIGRlY2xhcmUgaGFwcGVu -PyBJcyB0aGUNCj4gPiA+IFBMTCBzcGVjaWFsIGFuZCBuZWVkcyB0byBiZSB1c2VkIGZvciB0aGUg -dGltZXJzPw0KPiA+IA0KPiA+IEl0IGlzIHNwZWNpYWwgYW5kIGlzIHVzZWQgZm9yIHRoZSB0aW1l -cnMsIHNvIHdlIGhhdmUgdG8gQ0xLX09GX0RFQ0xBUkUgaXQuIE9uIHRoZSBvdGhlciBoYW5kIHNp -bWlsYXIgcGxsIGlzIHVzZWQgdG8NCj4gPiBkcml2ZSBQR1UgY2xvY2sgZnJlcXVlbmN5IGFuZCBv -dGhlciBzdWJzeXN0ZW1zIGFuZCBzbyB3ZSBhZGQgdXN1YWwgcHJvYmUgZnVuYy4NCj4gPiANCj4g -DQo+IFByZXN1bWFibHkgd2UnbGwgaGF2ZSBkaWZmZXJlbnQgY29tcGF0aWJsZSBzdHJpbmdzIGZv -ciB0aGUNCj4gZGlmZmVyZW50IFBMTHMgdGhlbj8gQ0xLX09GX0RFQ0xBUkUoKSB3aWxsIG1ha2Ug -aXQgc28gdGhhdCB0aGUNCj4gZGV2aWNlIG5vZGUgdGhhdCBtYXRjaGVzIG5ldmVyIGdldHMgYSAt -PnByb2JlKCkgZnJvbSBhDQo+IHBsYXRmb3JtX2RyaXZlciBjYWxsZWQgb24gaXQuIElmIHlvdSB3 -YW50IGl0IHRvIGJlIGNhbGxlZCB0d2ljZSwNCj4gdGhlbiB5b3UgbmVlZCB0byB1c2UgQ0xLX09G -X0RFQ0xBUkVfRFJJVkVSKCkgaW5zdGVhZC4NCj4gDQoNCkluIGZhY3Qgd2UgZG9uJ3QgbmVlZCBp -dCB0byBiZSBjYWxsZWQgdHdpY2UuIEFuZCBhcyB5b3UgY2FuIHNlZSBJIGRvIHByYWN0aWNhbGx5 -IHRoZSBzYW1lIHRoaW5ncyBpbiBzZXR1cCBhbmQgcHJvYmUNCmZ1bmN0aW9ucy4gU28gbWF5YmUg -SSBjYW4gc29tZWhvdyBhdm9pZCB0aGlzIGNvZGUgZHVwbGljYXRpb24/wqANCkkgbWVhbiB0aGF0 -IHRoaXMgZHJpdmVyIGlzIGdvaW5nIGVpdGhlciB0byBiZSB1c2VkIGZvciB0aGUgdGltZXJzIG9y -IGFzIGEgc2ltcGxlIHBsYXRmb3JtIGRyaXZlciBmb3IgY2xvY2tpbmcgc29tZQ0KcGVyaXBoZXJh -cy4gU28gZm9yIHRoZSBmaXJzdCBjYXNlIEkgaGF2ZSB3cml0dGVuIGEgc2V0dXAgZnVuY3Rpb24g -dG8gQ0xLX09GX0RFQ0xBUkUgbXkgZHJpdmVyIGFuZCBmb3IgdGhlIHNlY29uZCBjYXNlDQpJJ3Zl -IHdyaXR0ZW4gdXN1YWwgcHJvYmUgZnVuY3Rpb24uIE1heWJlIEkgYW0gbWlzdGFrZW4gYW5kIGl0 -IGlzIG5vdCB0aGUgcmlnaHQgd2F5Pw0KDQpUaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXJzLsKgDQoN -Ci0tIA0KQmVzdCByZWdhcmRzLA0KVmxhZCBaYWtoYXJvdiA8dnpha2hhckBzeW5vcHN5cy5jb20+ +Hi Stephen, + +On Wed, 2017-04-19@09:49 -0700, sboyd@codeaurora.org wrote: +> On 04/05, Vlad Zakharov wrote: +> > +> > Hi Stephen, +> > +> > On Tue, 2017-04-04@18:35 -0700, Stephen Boyd wrote: +> > > +> > > > +> > > > +?????.pll_table = (struct pll_of_table []){ +> > > > +?????????????{ +> > > > +?????????????????????.prate = 27000000, +> > > +> > > Can this be another clk in the framework instead of hardcoding +> > > the parent rate? +> > +> > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get +> > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching +> > for +> > the correct table comparing .parent_node field with real hardware parent clock frequency: +> > ---------------------------------->8------------------------------------ +> > for (i = 0; pll_table[i].prate != 0; i++) +> > ? ? if (pll_table[i].prate == prate) +> > ? ? ? ? return pll_table[i].pll_cfg_table; +> > ---------------------------------->8------------------------------------ +> +> When is that done though? During round_rate and recalc_rate the +> parent frequency is passed into the function, so it should be +> possible to use that if the tree is properly expressed. +> + +I think that we haven't understood each other correctly. +Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't +have situations when such plls can be driven by different parent clock. So this approach is not required at the moment. +I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better +provide a new patch. + +> > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk +> > registration +> > functions please? In which cases they are preferred?? +> > +> +> We're trying to split the consumer and provider APIs along struct +> clk_hw and struct clk respectively. If we can have drivers only +> registers clk_hw pointers and never get back anything but an +> error code, then we can force consumers to always go through the +> clk_get() family of APIs. Then we can easily tell who is a +> provider, who is a consumer, and who is a provider + a consumer. +> Right now this isn't always clear cut because clk_hw has access +> to struct clk, and also clk_register() returns a clk pointer, but +> it doesn't really get used by anything in a provider driver, +> unless provider drivers are doing something with the consumer +> API. + +I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not +still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating +or probing themselves? And what clk consumer can be used for? + +> +> > +> > > +> > > +> > > > +> > > > +} +> > > > + +> > > > +CLK_OF_DECLARE(axs10x_pll_clock, "snps,axs10x-arc-pll-clock", of_pll_clk_setup); +> > > +> > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the +> > > driver need to probe and also have this of declare happen? Is the +> > > PLL special and needs to be used for the timers? +> > +> > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to +> > drive PGU clock frequency and other subsystems and so we add usual probe func. +> > +> +> Presumably we'll have different compatible strings for the +> different PLLs then? CLK_OF_DECLARE() will make it so that the +> device node that matches never gets a ->probe() from a +> platform_driver called on it. If you want it to be called twice, +> then you need to use CLK_OF_DECLARE_DRIVER() instead. +> + +In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe +functions. So maybe I can somehow avoid this code duplication?? +I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some +peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case +I've written usual probe function. Maybe I am mistaken and it is not the right way? + +Thank you for you answers.? + +-- +Best regards, +Vlad Zakharov <vzakhar at synopsys.com> diff --git a/a/content_digest b/N1/content_digest index 944b1fc..96c0ace 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,95 +2,105 @@ "ref\020170405013525.GJ18246@codeaurora.org\0" "ref\01491408370.9650.24.camel@synopsys.com\0" "ref\020170419164949.GH7065@codeaurora.org\0" - "From\0Vlad Zakharov <Vladislav.Zakharov@synopsys.com>\0" - "Subject\0Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver\0" + "From\0Vladislav.Zakharov@synopsys.com (Vlad Zakharov)\0" + "Subject\0[PATCH v2] clk/axs10x: introduce AXS10X pll driver\0" "Date\0Thu, 20 Apr 2017 15:13:41 +0000\0" - "To\0sboyd@codeaurora.org <sboyd@codeaurora.org>\0" - "Cc\0mark.rutland@arm.com <mark.rutland@arm.com>" - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - mturquette@baylibre.com <mturquette@baylibre.com> - Jose.Abreu@synopsys.com <Jose.Abreu@synopsys.com> - linux-clk@vger.kernel.org <linux-clk@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" - "SGkgU3RlcGhlbiwNCg0KT24gV2VkLCAyMDE3LTA0LTE5IGF0IDA5OjQ5IC0wNzAwLCBzYm95ZEBj\n" - "b2RlYXVyb3JhLm9yZyB3cm90ZToNCj4gT24gMDQvMDUsIFZsYWQgWmFraGFyb3Ygd3JvdGU6DQo+\n" - "ID4gDQo+ID4gSGkgU3RlcGhlbiwNCj4gPiANCj4gPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTg6\n" - "MzUgLTA3MDAsIFN0ZXBoZW4gQm95ZCB3cm90ZToNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g\n" - "K8KgwqDCoMKgwqAucGxsX3RhYmxlID0gKHN0cnVjdCBwbGxfb2ZfdGFibGUgW10pew0KPiA+ID4g\n" - "PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg\n" - "wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAucHJhdGUgPSAyNzAwMDAwMCwNCj4gPiA+IA0KPiA+\n" - "ID4gQ2FuIHRoaXMgYmUgYW5vdGhlciBjbGsgaW4gdGhlIGZyYW1ld29yayBpbnN0ZWFkIG9mIGhh\n" - "cmRjb2RpbmcNCj4gPiA+IHRoZSBwYXJlbnQgcmF0ZT8NCj4gPiANCj4gPiBJbiBmYWN0IHRoZXJl\n" - "IGlzIGFub3RoZXIgY2xrIGluIHRoZSBmcmFtZXdvcmsgdGhhdCByZXByZXNlbnRzIHRoaXMgcGFy\n" - "ZW50IGNsb2NrLiBCdXQgdGhpcyBmaWVsZCBpcyBuZWVkZWQgdG8gZ2V0DQo+ID4gYXBwcm9wcmlh\n" - "dGUgcGxsX2NmZ190YWJsZSBhcyBpdCBkZXBlbmRzIG9uIHBhcmVudCBjbG9jayBmcmVxdWVuY3ku\n" - "IEJlbG93IGluIHBsbF9jZmdfZ2V0IGZ1bmN0aW9uIHdlIGFyZSBzZWFyY2hpbmcNCj4gPiBmb3IN\n" - "Cj4gPiB0aGUgY29ycmVjdCB0YWJsZSBjb21wYXJpbmcgLnBhcmVudF9ub2RlIGZpZWxkIHdpdGgg\n" - "cmVhbCBoYXJkd2FyZSBwYXJlbnQgY2xvY2sgZnJlcXVlbmN5Og0KPiA+IC0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LQ0KPiA+IGZvciAoaSA9IDA7IHBsbF90YWJsZVtpXS5wcmF0ZSAhPSAwOyBpKyspDQo+ID4gwqAg\n" - "wqAgaWYgKHBsbF90YWJsZVtpXS5wcmF0ZSA9PSBwcmF0ZSkNCj4gPiDCoCDCoCDCoCDCoCByZXR1\n" - "cm4gcGxsX3RhYmxlW2ldLnBsbF9jZmdfdGFibGU7DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K\n" - "PiBXaGVuIGlzIHRoYXQgZG9uZSB0aG91Z2g/IER1cmluZyByb3VuZF9yYXRlIGFuZCByZWNhbGNf\n" - "cmF0ZSB0aGUNCj4gcGFyZW50IGZyZXF1ZW5jeSBpcyBwYXNzZWQgaW50byB0aGUgZnVuY3Rpb24s\n" - "IHNvIGl0IHNob3VsZCBiZQ0KPiBwb3NzaWJsZSB0byB1c2UgdGhhdCBpZiB0aGUgdHJlZSBpcyBw\n" - "cm9wZXJseSBleHByZXNzZWQuDQo+IA0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2ZW4ndCB1bmRlcnN0\n" - "b29kIGVhY2ggb3RoZXIgY29ycmVjdGx5Lg0KQW55d2F5IEkgaGF2ZSBjaGVja2VkIG91dCBvdXIg\n" - "aGFyZHdhcmUgZG9jdW1lbnRhdGlvbnMgYW5kIGZpbmQgb3V0IHRoYXQgaW4gZmFjdCBmb3IgdG9k\n" - "YXkncyB2ZXJzaW9uIG9mIGhhcmR3YXJlIHdlIGRvbid0DQpoYXZlIHNpdHVhdGlvbnMgd2hlbiBz\n" - "dWNoIHBsbHMgY2FuIGJlIGRyaXZlbiBieSBkaWZmZXJlbnQgcGFyZW50IGNsb2NrLiBTbyB0aGlz\n" - "IGFwcHJvYWNoIGlzIG5vdCByZXF1aXJlZCBhdCB0aGUgbW9tZW50Lg0KSSBhbSBnb2luZyB0byBz\n" - "aW1wbGlmeSBteSBkcml2ZXIgc28gaXQgd2lsbCByZWZsZWN0IGN1cnJlbnQgdmVyc2lvbiBvZiBo\n" - "YXJkd2FyZSBhbmQgaWYgYW55dGhpbmcgY2hhbmdlcyBJIHdpbGwgYmV0dGVyDQpwcm92aWRlIGEg\n" - "bmV3IHBhdGNoLg0KDQo+ID4gU3VyZS4gQ291bGQgeW91IGJlIHNvIGtpbmQgdG8gZXhwbGFpbiB3\n" - "aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaHcgYW5kIG5vbi1odyBiYXNlZCBwcm92aWRl\n" - "ciBhbmQgY2xrDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gZnVuY3Rpb25zIHBsZWFzZT8gSW4gd2hp\n" - "Y2ggY2FzZXMgdGhleSBhcmUgcHJlZmVycmVkP8KgDQo+ID4gDQo+IA0KPiBXZSdyZSB0cnlpbmcg\n" - "dG8gc3BsaXQgdGhlIGNvbnN1bWVyIGFuZCBwcm92aWRlciBBUElzIGFsb25nIHN0cnVjdA0KPiBj\n" - "bGtfaHcgYW5kIHN0cnVjdCBjbGsgcmVzcGVjdGl2ZWx5LiBJZiB3ZSBjYW4gaGF2ZSBkcml2ZXJz\n" - "IG9ubHkNCj4gcmVnaXN0ZXJzIGNsa19odyBwb2ludGVycyBhbmQgbmV2ZXIgZ2V0IGJhY2sgYW55\n" - "dGhpbmcgYnV0IGFuDQo+IGVycm9yIGNvZGUsIHRoZW4gd2UgY2FuIGZvcmNlIGNvbnN1bWVycyB0\n" - "byBhbHdheXMgZ28gdGhyb3VnaCB0aGUNCj4gY2xrX2dldCgpIGZhbWlseSBvZiBBUElzLiBUaGVu\n" - "IHdlIGNhbiBlYXNpbHkgdGVsbCB3aG8gaXMgYQ0KPiBwcm92aWRlciwgd2hvIGlzIGEgY29uc3Vt\n" - "ZXIsIGFuZCB3aG8gaXMgYSBwcm92aWRlciArIGEgY29uc3VtZXIuDQo+IFJpZ2h0IG5vdyB0aGlz\n" - "IGlzbid0IGFsd2F5cyBjbGVhciBjdXQgYmVjYXVzZSBjbGtfaHcgaGFzIGFjY2Vzcw0KPiB0byBz\n" - "dHJ1Y3QgY2xrLCBhbmQgYWxzbyBjbGtfcmVnaXN0ZXIoKSByZXR1cm5zIGEgY2xrIHBvaW50ZXIs\n" - "IGJ1dA0KPiBpdCBkb2Vzbid0IHJlYWxseSBnZXQgdXNlZCBieSBhbnl0aGluZyBpbiBhIHByb3Zp\n" - "ZGVyIGRyaXZlciwNCj4gdW5sZXNzIHByb3ZpZGVyIGRyaXZlcnMgYXJlIGRvaW5nIHNvbWV0aGlu\n" - "ZyB3aXRoIHRoZSBjb25zdW1lcg0KPiBBUEkuDQoNCkkgYW0gc29ycnkgZm9yIG15IGZvb2xpc2gg\n" - "cXVlc3Rpb25zLCBidXQgYXMgSSB1bmRlcnN0YW5kIEkgc2hvdWxkIHVzZSBody1iYXNlZCBmdW5j\n" - "dGlvbnMgZm9yIGNsayBwcm92aWRlcnMgYnV0IGl0IGlzIG5vdA0Kc3RpbGwgY2xlYXIgZW5vdWdo\n" - "IGZvciBtZSB3aGVuIHNob3VsZCBJIHVzZSBub24taHcgZnVuY3Rpb25zPyBEb2VzIGFueSBkcml2\n" - "ZXJzIG5lZWQgc3RydWN0IGNsayB3aGVuIHRoZXkgYXJlIGluaXRpYXRpbmcNCm9yIHByb2Jpbmcg\n" - "dGhlbXNlbHZlcz8gQW5kIHdoYXQgY2xrIGNvbnN1bWVyIGNhbiBiZSB1c2VkIGZvcj8NCg0KPiAN\n" - "Cj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiArfQ0KPiA+ID4gPiArDQo+\n" - "ID4gPiA+ICtDTEtfT0ZfREVDTEFSRShheHMxMHhfcGxsX2Nsb2NrLCAic25wcyxheHMxMHgtYXJj\n" - "LXBsbC1jbG9jayIsIG9mX3BsbF9jbGtfc2V0dXApOw0KPiA+ID4gDQo+ID4gPiBEb2VzIHRoaXMg\n" - "bmVlZCB0byBiZSBDTEtfT0ZfREVDTEFSRV9EUklWRVI/IEkgbWVhbiBkb2VzIHRoZQ0KPiA+ID4g\n" - "ZHJpdmVyIG5lZWQgdG8gcHJvYmUgYW5kIGFsc28gaGF2ZSB0aGlzIG9mIGRlY2xhcmUgaGFwcGVu\n" - "PyBJcyB0aGUNCj4gPiA+IFBMTCBzcGVjaWFsIGFuZCBuZWVkcyB0byBiZSB1c2VkIGZvciB0aGUg\n" - "dGltZXJzPw0KPiA+IA0KPiA+IEl0IGlzIHNwZWNpYWwgYW5kIGlzIHVzZWQgZm9yIHRoZSB0aW1l\n" - "cnMsIHNvIHdlIGhhdmUgdG8gQ0xLX09GX0RFQ0xBUkUgaXQuIE9uIHRoZSBvdGhlciBoYW5kIHNp\n" - "bWlsYXIgcGxsIGlzIHVzZWQgdG8NCj4gPiBkcml2ZSBQR1UgY2xvY2sgZnJlcXVlbmN5IGFuZCBv\n" - "dGhlciBzdWJzeXN0ZW1zIGFuZCBzbyB3ZSBhZGQgdXN1YWwgcHJvYmUgZnVuYy4NCj4gPiANCj4g\n" - "DQo+IFByZXN1bWFibHkgd2UnbGwgaGF2ZSBkaWZmZXJlbnQgY29tcGF0aWJsZSBzdHJpbmdzIGZv\n" - "ciB0aGUNCj4gZGlmZmVyZW50IFBMTHMgdGhlbj8gQ0xLX09GX0RFQ0xBUkUoKSB3aWxsIG1ha2Ug\n" - "aXQgc28gdGhhdCB0aGUNCj4gZGV2aWNlIG5vZGUgdGhhdCBtYXRjaGVzIG5ldmVyIGdldHMgYSAt\n" - "PnByb2JlKCkgZnJvbSBhDQo+IHBsYXRmb3JtX2RyaXZlciBjYWxsZWQgb24gaXQuIElmIHlvdSB3\n" - "YW50IGl0IHRvIGJlIGNhbGxlZCB0d2ljZSwNCj4gdGhlbiB5b3UgbmVlZCB0byB1c2UgQ0xLX09G\n" - "X0RFQ0xBUkVfRFJJVkVSKCkgaW5zdGVhZC4NCj4gDQoNCkluIGZhY3Qgd2UgZG9uJ3QgbmVlZCBp\n" - "dCB0byBiZSBjYWxsZWQgdHdpY2UuIEFuZCBhcyB5b3UgY2FuIHNlZSBJIGRvIHByYWN0aWNhbGx5\n" - "IHRoZSBzYW1lIHRoaW5ncyBpbiBzZXR1cCBhbmQgcHJvYmUNCmZ1bmN0aW9ucy4gU28gbWF5YmUg\n" - "SSBjYW4gc29tZWhvdyBhdm9pZCB0aGlzIGNvZGUgZHVwbGljYXRpb24/wqANCkkgbWVhbiB0aGF0\n" - "IHRoaXMgZHJpdmVyIGlzIGdvaW5nIGVpdGhlciB0byBiZSB1c2VkIGZvciB0aGUgdGltZXJzIG9y\n" - "IGFzIGEgc2ltcGxlIHBsYXRmb3JtIGRyaXZlciBmb3IgY2xvY2tpbmcgc29tZQ0KcGVyaXBoZXJh\n" - "cy4gU28gZm9yIHRoZSBmaXJzdCBjYXNlIEkgaGF2ZSB3cml0dGVuIGEgc2V0dXAgZnVuY3Rpb24g\n" - "dG8gQ0xLX09GX0RFQ0xBUkUgbXkgZHJpdmVyIGFuZCBmb3IgdGhlIHNlY29uZCBjYXNlDQpJJ3Zl\n" - "IHdyaXR0ZW4gdXN1YWwgcHJvYmUgZnVuY3Rpb24uIE1heWJlIEkgYW0gbWlzdGFrZW4gYW5kIGl0\n" - "IGlzIG5vdCB0aGUgcmlnaHQgd2F5Pw0KDQpUaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXJzLsKgDQoN\n" - Ci0tIA0KQmVzdCByZWdhcmRzLA0KVmxhZCBaYWtoYXJvdiA8dnpha2hhckBzeW5vcHN5cy5jb20+ + "Hi Stephen,\n" + "\n" + "On Wed, 2017-04-19@09:49 -0700, sboyd@codeaurora.org wrote:\n" + "> On 04/05, Vlad Zakharov wrote:\n" + "> > \n" + "> > Hi Stephen,\n" + "> > \n" + "> > On Tue, 2017-04-04@18:35 -0700, Stephen Boyd wrote:\n" + "> > > \n" + "> > > > \n" + "> > > > +?????.pll_table = (struct pll_of_table []){\n" + "> > > > +?????????????{\n" + "> > > > +?????????????????????.prate = 27000000,\n" + "> > > \n" + "> > > Can this be another clk in the framework instead of hardcoding\n" + "> > > the parent rate?\n" + "> > \n" + "> > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get\n" + "> > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching\n" + "> > for\n" + "> > the correct table comparing .parent_node field with real hardware parent clock frequency:\n" + "> > ---------------------------------->8------------------------------------\n" + "> > for (i = 0; pll_table[i].prate != 0; i++)\n" + "> > ? ? if (pll_table[i].prate == prate)\n" + "> > ? ? ? ? return pll_table[i].pll_cfg_table;\n" + "> > ---------------------------------->8------------------------------------\n" + "> \n" + "> When is that done though? During round_rate and recalc_rate the\n" + "> parent frequency is passed into the function, so it should be\n" + "> possible to use that if the tree is properly expressed.\n" + "> \n" + "\n" + "I think that we haven't understood each other correctly.\n" + "Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't\n" + "have situations when such plls can be driven by different parent clock. So this approach is not required at the moment.\n" + "I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better\n" + "provide a new patch.\n" + "\n" + "> > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk\n" + "> > registration\n" + "> > functions please? In which cases they are preferred??\n" + "> > \n" + "> \n" + "> We're trying to split the consumer and provider APIs along struct\n" + "> clk_hw and struct clk respectively. If we can have drivers only\n" + "> registers clk_hw pointers and never get back anything but an\n" + "> error code, then we can force consumers to always go through the\n" + "> clk_get() family of APIs. Then we can easily tell who is a\n" + "> provider, who is a consumer, and who is a provider + a consumer.\n" + "> Right now this isn't always clear cut because clk_hw has access\n" + "> to struct clk, and also clk_register() returns a clk pointer, but\n" + "> it doesn't really get used by anything in a provider driver,\n" + "> unless provider drivers are doing something with the consumer\n" + "> API.\n" + "\n" + "I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not\n" + "still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating\n" + "or probing themselves? And what clk consumer can be used for?\n" + "\n" + "> \n" + "> > \n" + "> > > \n" + "> > > \n" + "> > > > \n" + "> > > > +}\n" + "> > > > +\n" + "> > > > +CLK_OF_DECLARE(axs10x_pll_clock, \"snps,axs10x-arc-pll-clock\", of_pll_clk_setup);\n" + "> > > \n" + "> > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the\n" + "> > > driver need to probe and also have this of declare happen? Is the\n" + "> > > PLL special and needs to be used for the timers?\n" + "> > \n" + "> > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to\n" + "> > drive PGU clock frequency and other subsystems and so we add usual probe func.\n" + "> > \n" + "> \n" + "> Presumably we'll have different compatible strings for the\n" + "> different PLLs then? CLK_OF_DECLARE() will make it so that the\n" + "> device node that matches never gets a ->probe() from a\n" + "> platform_driver called on it. If you want it to be called twice,\n" + "> then you need to use CLK_OF_DECLARE_DRIVER() instead.\n" + "> \n" + "\n" + "In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe\n" + "functions. So maybe I can somehow avoid this code duplication??\n" + "I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some\n" + "peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case\n" + "I've written usual probe function. Maybe I am mistaken and it is not the right way?\n" + "\n" + "Thank you for you answers.?\n" + "\n" + "-- \n" + "Best regards,\n" + Vlad Zakharov <vzakhar at synopsys.com> -d11ed90f5a6ef5386ec18bfc4d9d68adec3aeddd9e4dfae997b6e00e94df80a4 +927625bce8a3b2f1e73d2c8908ca5ef169cb3ba01071d068fa7644d9f72a3c21
diff --git a/a/1.txt b/N2/1.txt index 3a9bb0c..96e1c0d 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,78 +1,94 @@ -SGkgU3RlcGhlbiwNCg0KT24gV2VkLCAyMDE3LTA0LTE5IGF0IDA5OjQ5IC0wNzAwLCBzYm95ZEBj -b2RlYXVyb3JhLm9yZyB3cm90ZToNCj4gT24gMDQvMDUsIFZsYWQgWmFraGFyb3Ygd3JvdGU6DQo+ -ID4gDQo+ID4gSGkgU3RlcGhlbiwNCj4gPiANCj4gPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTg6 -MzUgLTA3MDAsIFN0ZXBoZW4gQm95ZCB3cm90ZToNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g -K8KgwqDCoMKgwqAucGxsX3RhYmxlID0gKHN0cnVjdCBwbGxfb2ZfdGFibGUgW10pew0KPiA+ID4g -PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg -wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAucHJhdGUgPSAyNzAwMDAwMCwNCj4gPiA+IA0KPiA+ -ID4gQ2FuIHRoaXMgYmUgYW5vdGhlciBjbGsgaW4gdGhlIGZyYW1ld29yayBpbnN0ZWFkIG9mIGhh -cmRjb2RpbmcNCj4gPiA+IHRoZSBwYXJlbnQgcmF0ZT8NCj4gPiANCj4gPiBJbiBmYWN0IHRoZXJl -IGlzIGFub3RoZXIgY2xrIGluIHRoZSBmcmFtZXdvcmsgdGhhdCByZXByZXNlbnRzIHRoaXMgcGFy -ZW50IGNsb2NrLiBCdXQgdGhpcyBmaWVsZCBpcyBuZWVkZWQgdG8gZ2V0DQo+ID4gYXBwcm9wcmlh -dGUgcGxsX2NmZ190YWJsZSBhcyBpdCBkZXBlbmRzIG9uIHBhcmVudCBjbG9jayBmcmVxdWVuY3ku -IEJlbG93IGluIHBsbF9jZmdfZ2V0IGZ1bmN0aW9uIHdlIGFyZSBzZWFyY2hpbmcNCj4gPiBmb3IN -Cj4gPiB0aGUgY29ycmVjdCB0YWJsZSBjb21wYXJpbmcgLnBhcmVudF9ub2RlIGZpZWxkIHdpdGgg -cmVhbCBoYXJkd2FyZSBwYXJlbnQgY2xvY2sgZnJlcXVlbmN5Og0KPiA+IC0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LQ0KPiA+IGZvciAoaSA9IDA7IHBsbF90YWJsZVtpXS5wcmF0ZSAhPSAwOyBpKyspDQo+ID4gwqAg -wqAgaWYgKHBsbF90YWJsZVtpXS5wcmF0ZSA9PSBwcmF0ZSkNCj4gPiDCoCDCoCDCoCDCoCByZXR1 -cm4gcGxsX3RhYmxlW2ldLnBsbF9jZmdfdGFibGU7DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t -LS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K -PiBXaGVuIGlzIHRoYXQgZG9uZSB0aG91Z2g/IER1cmluZyByb3VuZF9yYXRlIGFuZCByZWNhbGNf -cmF0ZSB0aGUNCj4gcGFyZW50IGZyZXF1ZW5jeSBpcyBwYXNzZWQgaW50byB0aGUgZnVuY3Rpb24s -IHNvIGl0IHNob3VsZCBiZQ0KPiBwb3NzaWJsZSB0byB1c2UgdGhhdCBpZiB0aGUgdHJlZSBpcyBw -cm9wZXJseSBleHByZXNzZWQuDQo+IA0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2ZW4ndCB1bmRlcnN0 -b29kIGVhY2ggb3RoZXIgY29ycmVjdGx5Lg0KQW55d2F5IEkgaGF2ZSBjaGVja2VkIG91dCBvdXIg -aGFyZHdhcmUgZG9jdW1lbnRhdGlvbnMgYW5kIGZpbmQgb3V0IHRoYXQgaW4gZmFjdCBmb3IgdG9k -YXkncyB2ZXJzaW9uIG9mIGhhcmR3YXJlIHdlIGRvbid0DQpoYXZlIHNpdHVhdGlvbnMgd2hlbiBz -dWNoIHBsbHMgY2FuIGJlIGRyaXZlbiBieSBkaWZmZXJlbnQgcGFyZW50IGNsb2NrLiBTbyB0aGlz -IGFwcHJvYWNoIGlzIG5vdCByZXF1aXJlZCBhdCB0aGUgbW9tZW50Lg0KSSBhbSBnb2luZyB0byBz -aW1wbGlmeSBteSBkcml2ZXIgc28gaXQgd2lsbCByZWZsZWN0IGN1cnJlbnQgdmVyc2lvbiBvZiBo -YXJkd2FyZSBhbmQgaWYgYW55dGhpbmcgY2hhbmdlcyBJIHdpbGwgYmV0dGVyDQpwcm92aWRlIGEg -bmV3IHBhdGNoLg0KDQo+ID4gU3VyZS4gQ291bGQgeW91IGJlIHNvIGtpbmQgdG8gZXhwbGFpbiB3 -aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaHcgYW5kIG5vbi1odyBiYXNlZCBwcm92aWRl -ciBhbmQgY2xrDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gZnVuY3Rpb25zIHBsZWFzZT8gSW4gd2hp -Y2ggY2FzZXMgdGhleSBhcmUgcHJlZmVycmVkP8KgDQo+ID4gDQo+IA0KPiBXZSdyZSB0cnlpbmcg -dG8gc3BsaXQgdGhlIGNvbnN1bWVyIGFuZCBwcm92aWRlciBBUElzIGFsb25nIHN0cnVjdA0KPiBj -bGtfaHcgYW5kIHN0cnVjdCBjbGsgcmVzcGVjdGl2ZWx5LiBJZiB3ZSBjYW4gaGF2ZSBkcml2ZXJz -IG9ubHkNCj4gcmVnaXN0ZXJzIGNsa19odyBwb2ludGVycyBhbmQgbmV2ZXIgZ2V0IGJhY2sgYW55 -dGhpbmcgYnV0IGFuDQo+IGVycm9yIGNvZGUsIHRoZW4gd2UgY2FuIGZvcmNlIGNvbnN1bWVycyB0 -byBhbHdheXMgZ28gdGhyb3VnaCB0aGUNCj4gY2xrX2dldCgpIGZhbWlseSBvZiBBUElzLiBUaGVu -IHdlIGNhbiBlYXNpbHkgdGVsbCB3aG8gaXMgYQ0KPiBwcm92aWRlciwgd2hvIGlzIGEgY29uc3Vt -ZXIsIGFuZCB3aG8gaXMgYSBwcm92aWRlciArIGEgY29uc3VtZXIuDQo+IFJpZ2h0IG5vdyB0aGlz -IGlzbid0IGFsd2F5cyBjbGVhciBjdXQgYmVjYXVzZSBjbGtfaHcgaGFzIGFjY2Vzcw0KPiB0byBz -dHJ1Y3QgY2xrLCBhbmQgYWxzbyBjbGtfcmVnaXN0ZXIoKSByZXR1cm5zIGEgY2xrIHBvaW50ZXIs -IGJ1dA0KPiBpdCBkb2Vzbid0IHJlYWxseSBnZXQgdXNlZCBieSBhbnl0aGluZyBpbiBhIHByb3Zp -ZGVyIGRyaXZlciwNCj4gdW5sZXNzIHByb3ZpZGVyIGRyaXZlcnMgYXJlIGRvaW5nIHNvbWV0aGlu -ZyB3aXRoIHRoZSBjb25zdW1lcg0KPiBBUEkuDQoNCkkgYW0gc29ycnkgZm9yIG15IGZvb2xpc2gg -cXVlc3Rpb25zLCBidXQgYXMgSSB1bmRlcnN0YW5kIEkgc2hvdWxkIHVzZSBody1iYXNlZCBmdW5j -dGlvbnMgZm9yIGNsayBwcm92aWRlcnMgYnV0IGl0IGlzIG5vdA0Kc3RpbGwgY2xlYXIgZW5vdWdo -IGZvciBtZSB3aGVuIHNob3VsZCBJIHVzZSBub24taHcgZnVuY3Rpb25zPyBEb2VzIGFueSBkcml2 -ZXJzIG5lZWQgc3RydWN0IGNsayB3aGVuIHRoZXkgYXJlIGluaXRpYXRpbmcNCm9yIHByb2Jpbmcg -dGhlbXNlbHZlcz8gQW5kIHdoYXQgY2xrIGNvbnN1bWVyIGNhbiBiZSB1c2VkIGZvcj8NCg0KPiAN -Cj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiArfQ0KPiA+ID4gPiArDQo+ -ID4gPiA+ICtDTEtfT0ZfREVDTEFSRShheHMxMHhfcGxsX2Nsb2NrLCAic25wcyxheHMxMHgtYXJj -LXBsbC1jbG9jayIsIG9mX3BsbF9jbGtfc2V0dXApOw0KPiA+ID4gDQo+ID4gPiBEb2VzIHRoaXMg -bmVlZCB0byBiZSBDTEtfT0ZfREVDTEFSRV9EUklWRVI/IEkgbWVhbiBkb2VzIHRoZQ0KPiA+ID4g -ZHJpdmVyIG5lZWQgdG8gcHJvYmUgYW5kIGFsc28gaGF2ZSB0aGlzIG9mIGRlY2xhcmUgaGFwcGVu -PyBJcyB0aGUNCj4gPiA+IFBMTCBzcGVjaWFsIGFuZCBuZWVkcyB0byBiZSB1c2VkIGZvciB0aGUg -dGltZXJzPw0KPiA+IA0KPiA+IEl0IGlzIHNwZWNpYWwgYW5kIGlzIHVzZWQgZm9yIHRoZSB0aW1l -cnMsIHNvIHdlIGhhdmUgdG8gQ0xLX09GX0RFQ0xBUkUgaXQuIE9uIHRoZSBvdGhlciBoYW5kIHNp -bWlsYXIgcGxsIGlzIHVzZWQgdG8NCj4gPiBkcml2ZSBQR1UgY2xvY2sgZnJlcXVlbmN5IGFuZCBv -dGhlciBzdWJzeXN0ZW1zIGFuZCBzbyB3ZSBhZGQgdXN1YWwgcHJvYmUgZnVuYy4NCj4gPiANCj4g -DQo+IFByZXN1bWFibHkgd2UnbGwgaGF2ZSBkaWZmZXJlbnQgY29tcGF0aWJsZSBzdHJpbmdzIGZv -ciB0aGUNCj4gZGlmZmVyZW50IFBMTHMgdGhlbj8gQ0xLX09GX0RFQ0xBUkUoKSB3aWxsIG1ha2Ug -aXQgc28gdGhhdCB0aGUNCj4gZGV2aWNlIG5vZGUgdGhhdCBtYXRjaGVzIG5ldmVyIGdldHMgYSAt -PnByb2JlKCkgZnJvbSBhDQo+IHBsYXRmb3JtX2RyaXZlciBjYWxsZWQgb24gaXQuIElmIHlvdSB3 -YW50IGl0IHRvIGJlIGNhbGxlZCB0d2ljZSwNCj4gdGhlbiB5b3UgbmVlZCB0byB1c2UgQ0xLX09G -X0RFQ0xBUkVfRFJJVkVSKCkgaW5zdGVhZC4NCj4gDQoNCkluIGZhY3Qgd2UgZG9uJ3QgbmVlZCBp -dCB0byBiZSBjYWxsZWQgdHdpY2UuIEFuZCBhcyB5b3UgY2FuIHNlZSBJIGRvIHByYWN0aWNhbGx5 -IHRoZSBzYW1lIHRoaW5ncyBpbiBzZXR1cCBhbmQgcHJvYmUNCmZ1bmN0aW9ucy4gU28gbWF5YmUg -SSBjYW4gc29tZWhvdyBhdm9pZCB0aGlzIGNvZGUgZHVwbGljYXRpb24/wqANCkkgbWVhbiB0aGF0 -IHRoaXMgZHJpdmVyIGlzIGdvaW5nIGVpdGhlciB0byBiZSB1c2VkIGZvciB0aGUgdGltZXJzIG9y -IGFzIGEgc2ltcGxlIHBsYXRmb3JtIGRyaXZlciBmb3IgY2xvY2tpbmcgc29tZQ0KcGVyaXBoZXJh -cy4gU28gZm9yIHRoZSBmaXJzdCBjYXNlIEkgaGF2ZSB3cml0dGVuIGEgc2V0dXAgZnVuY3Rpb24g -dG8gQ0xLX09GX0RFQ0xBUkUgbXkgZHJpdmVyIGFuZCBmb3IgdGhlIHNlY29uZCBjYXNlDQpJJ3Zl -IHdyaXR0ZW4gdXN1YWwgcHJvYmUgZnVuY3Rpb24uIE1heWJlIEkgYW0gbWlzdGFrZW4gYW5kIGl0 -IGlzIG5vdCB0aGUgcmlnaHQgd2F5Pw0KDQpUaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXJzLsKgDQoN -Ci0tIA0KQmVzdCByZWdhcmRzLA0KVmxhZCBaYWtoYXJvdiA8dnpha2hhckBzeW5vcHN5cy5jb20+ +Hi Stephen, + +On Wed, 2017-04-19 at 09:49 -0700, sboyd@codeaurora.org wrote: +> On 04/05, Vlad Zakharov wrote: +> > +> > Hi Stephen, +> > +> > On Tue, 2017-04-04 at 18:35 -0700, Stephen Boyd wrote: +> > > +> > > > +> > > > + .pll_table = (struct pll_of_table []){ +> > > > + { +> > > > + .prate = 27000000, +> > > +> > > Can this be another clk in the framework instead of hardcoding +> > > the parent rate? +> > +> > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get +> > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching +> > for +> > the correct table comparing .parent_node field with real hardware parent clock frequency: +> > ---------------------------------->8------------------------------------ +> > for (i = 0; pll_table[i].prate != 0; i++) +> > if (pll_table[i].prate == prate) +> > return pll_table[i].pll_cfg_table; +> > ---------------------------------->8------------------------------------ +> +> When is that done though? During round_rate and recalc_rate the +> parent frequency is passed into the function, so it should be +> possible to use that if the tree is properly expressed. +> + +I think that we haven't understood each other correctly. +Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't +have situations when such plls can be driven by different parent clock. So this approach is not required at the moment. +I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better +provide a new patch. + +> > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk +> > registration +> > functions please? In which cases they are preferred? +> > +> +> We're trying to split the consumer and provider APIs along struct +> clk_hw and struct clk respectively. If we can have drivers only +> registers clk_hw pointers and never get back anything but an +> error code, then we can force consumers to always go through the +> clk_get() family of APIs. Then we can easily tell who is a +> provider, who is a consumer, and who is a provider + a consumer. +> Right now this isn't always clear cut because clk_hw has access +> to struct clk, and also clk_register() returns a clk pointer, but +> it doesn't really get used by anything in a provider driver, +> unless provider drivers are doing something with the consumer +> API. + +I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not +still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating +or probing themselves? And what clk consumer can be used for? + +> +> > +> > > +> > > +> > > > +> > > > +} +> > > > + +> > > > +CLK_OF_DECLARE(axs10x_pll_clock, "snps,axs10x-arc-pll-clock", of_pll_clk_setup); +> > > +> > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the +> > > driver need to probe and also have this of declare happen? Is the +> > > PLL special and needs to be used for the timers? +> > +> > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to +> > drive PGU clock frequency and other subsystems and so we add usual probe func. +> > +> +> Presumably we'll have different compatible strings for the +> different PLLs then? CLK_OF_DECLARE() will make it so that the +> device node that matches never gets a ->probe() from a +> platform_driver called on it. If you want it to be called twice, +> then you need to use CLK_OF_DECLARE_DRIVER() instead. +> + +In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe +functions. So maybe I can somehow avoid this code duplication? +I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some +peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case +I've written usual probe function. Maybe I am mistaken and it is not the right way? + +Thank you for you answers. + +-- +Best regards, +Vlad Zakharov <vzakhar@synopsys.com> diff --git a/a/content_digest b/N2/content_digest index 944b1fc..0367409 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -14,83 +14,99 @@ " linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org>\0" "\00:1\0" "b\0" - "SGkgU3RlcGhlbiwNCg0KT24gV2VkLCAyMDE3LTA0LTE5IGF0IDA5OjQ5IC0wNzAwLCBzYm95ZEBj\n" - "b2RlYXVyb3JhLm9yZyB3cm90ZToNCj4gT24gMDQvMDUsIFZsYWQgWmFraGFyb3Ygd3JvdGU6DQo+\n" - "ID4gDQo+ID4gSGkgU3RlcGhlbiwNCj4gPiANCj4gPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTg6\n" - "MzUgLTA3MDAsIFN0ZXBoZW4gQm95ZCB3cm90ZToNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g\n" - "K8KgwqDCoMKgwqAucGxsX3RhYmxlID0gKHN0cnVjdCBwbGxfb2ZfdGFibGUgW10pew0KPiA+ID4g\n" - "PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg\n" - "wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAucHJhdGUgPSAyNzAwMDAwMCwNCj4gPiA+IA0KPiA+\n" - "ID4gQ2FuIHRoaXMgYmUgYW5vdGhlciBjbGsgaW4gdGhlIGZyYW1ld29yayBpbnN0ZWFkIG9mIGhh\n" - "cmRjb2RpbmcNCj4gPiA+IHRoZSBwYXJlbnQgcmF0ZT8NCj4gPiANCj4gPiBJbiBmYWN0IHRoZXJl\n" - "IGlzIGFub3RoZXIgY2xrIGluIHRoZSBmcmFtZXdvcmsgdGhhdCByZXByZXNlbnRzIHRoaXMgcGFy\n" - "ZW50IGNsb2NrLiBCdXQgdGhpcyBmaWVsZCBpcyBuZWVkZWQgdG8gZ2V0DQo+ID4gYXBwcm9wcmlh\n" - "dGUgcGxsX2NmZ190YWJsZSBhcyBpdCBkZXBlbmRzIG9uIHBhcmVudCBjbG9jayBmcmVxdWVuY3ku\n" - "IEJlbG93IGluIHBsbF9jZmdfZ2V0IGZ1bmN0aW9uIHdlIGFyZSBzZWFyY2hpbmcNCj4gPiBmb3IN\n" - "Cj4gPiB0aGUgY29ycmVjdCB0YWJsZSBjb21wYXJpbmcgLnBhcmVudF9ub2RlIGZpZWxkIHdpdGgg\n" - "cmVhbCBoYXJkd2FyZSBwYXJlbnQgY2xvY2sgZnJlcXVlbmN5Og0KPiA+IC0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LQ0KPiA+IGZvciAoaSA9IDA7IHBsbF90YWJsZVtpXS5wcmF0ZSAhPSAwOyBpKyspDQo+ID4gwqAg\n" - "wqAgaWYgKHBsbF90YWJsZVtpXS5wcmF0ZSA9PSBwcmF0ZSkNCj4gPiDCoCDCoCDCoCDCoCByZXR1\n" - "cm4gcGxsX3RhYmxlW2ldLnBsbF9jZmdfdGFibGU7DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t\n" - "LS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K\n" - "PiBXaGVuIGlzIHRoYXQgZG9uZSB0aG91Z2g/IER1cmluZyByb3VuZF9yYXRlIGFuZCByZWNhbGNf\n" - "cmF0ZSB0aGUNCj4gcGFyZW50IGZyZXF1ZW5jeSBpcyBwYXNzZWQgaW50byB0aGUgZnVuY3Rpb24s\n" - "IHNvIGl0IHNob3VsZCBiZQ0KPiBwb3NzaWJsZSB0byB1c2UgdGhhdCBpZiB0aGUgdHJlZSBpcyBw\n" - "cm9wZXJseSBleHByZXNzZWQuDQo+IA0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2ZW4ndCB1bmRlcnN0\n" - "b29kIGVhY2ggb3RoZXIgY29ycmVjdGx5Lg0KQW55d2F5IEkgaGF2ZSBjaGVja2VkIG91dCBvdXIg\n" - "aGFyZHdhcmUgZG9jdW1lbnRhdGlvbnMgYW5kIGZpbmQgb3V0IHRoYXQgaW4gZmFjdCBmb3IgdG9k\n" - "YXkncyB2ZXJzaW9uIG9mIGhhcmR3YXJlIHdlIGRvbid0DQpoYXZlIHNpdHVhdGlvbnMgd2hlbiBz\n" - "dWNoIHBsbHMgY2FuIGJlIGRyaXZlbiBieSBkaWZmZXJlbnQgcGFyZW50IGNsb2NrLiBTbyB0aGlz\n" - "IGFwcHJvYWNoIGlzIG5vdCByZXF1aXJlZCBhdCB0aGUgbW9tZW50Lg0KSSBhbSBnb2luZyB0byBz\n" - "aW1wbGlmeSBteSBkcml2ZXIgc28gaXQgd2lsbCByZWZsZWN0IGN1cnJlbnQgdmVyc2lvbiBvZiBo\n" - "YXJkd2FyZSBhbmQgaWYgYW55dGhpbmcgY2hhbmdlcyBJIHdpbGwgYmV0dGVyDQpwcm92aWRlIGEg\n" - "bmV3IHBhdGNoLg0KDQo+ID4gU3VyZS4gQ291bGQgeW91IGJlIHNvIGtpbmQgdG8gZXhwbGFpbiB3\n" - "aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaHcgYW5kIG5vbi1odyBiYXNlZCBwcm92aWRl\n" - "ciBhbmQgY2xrDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gZnVuY3Rpb25zIHBsZWFzZT8gSW4gd2hp\n" - "Y2ggY2FzZXMgdGhleSBhcmUgcHJlZmVycmVkP8KgDQo+ID4gDQo+IA0KPiBXZSdyZSB0cnlpbmcg\n" - "dG8gc3BsaXQgdGhlIGNvbnN1bWVyIGFuZCBwcm92aWRlciBBUElzIGFsb25nIHN0cnVjdA0KPiBj\n" - "bGtfaHcgYW5kIHN0cnVjdCBjbGsgcmVzcGVjdGl2ZWx5LiBJZiB3ZSBjYW4gaGF2ZSBkcml2ZXJz\n" - "IG9ubHkNCj4gcmVnaXN0ZXJzIGNsa19odyBwb2ludGVycyBhbmQgbmV2ZXIgZ2V0IGJhY2sgYW55\n" - "dGhpbmcgYnV0IGFuDQo+IGVycm9yIGNvZGUsIHRoZW4gd2UgY2FuIGZvcmNlIGNvbnN1bWVycyB0\n" - "byBhbHdheXMgZ28gdGhyb3VnaCB0aGUNCj4gY2xrX2dldCgpIGZhbWlseSBvZiBBUElzLiBUaGVu\n" - "IHdlIGNhbiBlYXNpbHkgdGVsbCB3aG8gaXMgYQ0KPiBwcm92aWRlciwgd2hvIGlzIGEgY29uc3Vt\n" - "ZXIsIGFuZCB3aG8gaXMgYSBwcm92aWRlciArIGEgY29uc3VtZXIuDQo+IFJpZ2h0IG5vdyB0aGlz\n" - "IGlzbid0IGFsd2F5cyBjbGVhciBjdXQgYmVjYXVzZSBjbGtfaHcgaGFzIGFjY2Vzcw0KPiB0byBz\n" - "dHJ1Y3QgY2xrLCBhbmQgYWxzbyBjbGtfcmVnaXN0ZXIoKSByZXR1cm5zIGEgY2xrIHBvaW50ZXIs\n" - "IGJ1dA0KPiBpdCBkb2Vzbid0IHJlYWxseSBnZXQgdXNlZCBieSBhbnl0aGluZyBpbiBhIHByb3Zp\n" - "ZGVyIGRyaXZlciwNCj4gdW5sZXNzIHByb3ZpZGVyIGRyaXZlcnMgYXJlIGRvaW5nIHNvbWV0aGlu\n" - "ZyB3aXRoIHRoZSBjb25zdW1lcg0KPiBBUEkuDQoNCkkgYW0gc29ycnkgZm9yIG15IGZvb2xpc2gg\n" - "cXVlc3Rpb25zLCBidXQgYXMgSSB1bmRlcnN0YW5kIEkgc2hvdWxkIHVzZSBody1iYXNlZCBmdW5j\n" - "dGlvbnMgZm9yIGNsayBwcm92aWRlcnMgYnV0IGl0IGlzIG5vdA0Kc3RpbGwgY2xlYXIgZW5vdWdo\n" - "IGZvciBtZSB3aGVuIHNob3VsZCBJIHVzZSBub24taHcgZnVuY3Rpb25zPyBEb2VzIGFueSBkcml2\n" - "ZXJzIG5lZWQgc3RydWN0IGNsayB3aGVuIHRoZXkgYXJlIGluaXRpYXRpbmcNCm9yIHByb2Jpbmcg\n" - "dGhlbXNlbHZlcz8gQW5kIHdoYXQgY2xrIGNvbnN1bWVyIGNhbiBiZSB1c2VkIGZvcj8NCg0KPiAN\n" - "Cj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiArfQ0KPiA+ID4gPiArDQo+\n" - "ID4gPiA+ICtDTEtfT0ZfREVDTEFSRShheHMxMHhfcGxsX2Nsb2NrLCAic25wcyxheHMxMHgtYXJj\n" - "LXBsbC1jbG9jayIsIG9mX3BsbF9jbGtfc2V0dXApOw0KPiA+ID4gDQo+ID4gPiBEb2VzIHRoaXMg\n" - "bmVlZCB0byBiZSBDTEtfT0ZfREVDTEFSRV9EUklWRVI/IEkgbWVhbiBkb2VzIHRoZQ0KPiA+ID4g\n" - "ZHJpdmVyIG5lZWQgdG8gcHJvYmUgYW5kIGFsc28gaGF2ZSB0aGlzIG9mIGRlY2xhcmUgaGFwcGVu\n" - "PyBJcyB0aGUNCj4gPiA+IFBMTCBzcGVjaWFsIGFuZCBuZWVkcyB0byBiZSB1c2VkIGZvciB0aGUg\n" - "dGltZXJzPw0KPiA+IA0KPiA+IEl0IGlzIHNwZWNpYWwgYW5kIGlzIHVzZWQgZm9yIHRoZSB0aW1l\n" - "cnMsIHNvIHdlIGhhdmUgdG8gQ0xLX09GX0RFQ0xBUkUgaXQuIE9uIHRoZSBvdGhlciBoYW5kIHNp\n" - "bWlsYXIgcGxsIGlzIHVzZWQgdG8NCj4gPiBkcml2ZSBQR1UgY2xvY2sgZnJlcXVlbmN5IGFuZCBv\n" - "dGhlciBzdWJzeXN0ZW1zIGFuZCBzbyB3ZSBhZGQgdXN1YWwgcHJvYmUgZnVuYy4NCj4gPiANCj4g\n" - "DQo+IFByZXN1bWFibHkgd2UnbGwgaGF2ZSBkaWZmZXJlbnQgY29tcGF0aWJsZSBzdHJpbmdzIGZv\n" - "ciB0aGUNCj4gZGlmZmVyZW50IFBMTHMgdGhlbj8gQ0xLX09GX0RFQ0xBUkUoKSB3aWxsIG1ha2Ug\n" - "aXQgc28gdGhhdCB0aGUNCj4gZGV2aWNlIG5vZGUgdGhhdCBtYXRjaGVzIG5ldmVyIGdldHMgYSAt\n" - "PnByb2JlKCkgZnJvbSBhDQo+IHBsYXRmb3JtX2RyaXZlciBjYWxsZWQgb24gaXQuIElmIHlvdSB3\n" - "YW50IGl0IHRvIGJlIGNhbGxlZCB0d2ljZSwNCj4gdGhlbiB5b3UgbmVlZCB0byB1c2UgQ0xLX09G\n" - "X0RFQ0xBUkVfRFJJVkVSKCkgaW5zdGVhZC4NCj4gDQoNCkluIGZhY3Qgd2UgZG9uJ3QgbmVlZCBp\n" - "dCB0byBiZSBjYWxsZWQgdHdpY2UuIEFuZCBhcyB5b3UgY2FuIHNlZSBJIGRvIHByYWN0aWNhbGx5\n" - "IHRoZSBzYW1lIHRoaW5ncyBpbiBzZXR1cCBhbmQgcHJvYmUNCmZ1bmN0aW9ucy4gU28gbWF5YmUg\n" - "SSBjYW4gc29tZWhvdyBhdm9pZCB0aGlzIGNvZGUgZHVwbGljYXRpb24/wqANCkkgbWVhbiB0aGF0\n" - "IHRoaXMgZHJpdmVyIGlzIGdvaW5nIGVpdGhlciB0byBiZSB1c2VkIGZvciB0aGUgdGltZXJzIG9y\n" - "IGFzIGEgc2ltcGxlIHBsYXRmb3JtIGRyaXZlciBmb3IgY2xvY2tpbmcgc29tZQ0KcGVyaXBoZXJh\n" - "cy4gU28gZm9yIHRoZSBmaXJzdCBjYXNlIEkgaGF2ZSB3cml0dGVuIGEgc2V0dXAgZnVuY3Rpb24g\n" - "dG8gQ0xLX09GX0RFQ0xBUkUgbXkgZHJpdmVyIGFuZCBmb3IgdGhlIHNlY29uZCBjYXNlDQpJJ3Zl\n" - "IHdyaXR0ZW4gdXN1YWwgcHJvYmUgZnVuY3Rpb24uIE1heWJlIEkgYW0gbWlzdGFrZW4gYW5kIGl0\n" - "IGlzIG5vdCB0aGUgcmlnaHQgd2F5Pw0KDQpUaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXJzLsKgDQoN\n" - Ci0tIA0KQmVzdCByZWdhcmRzLA0KVmxhZCBaYWtoYXJvdiA8dnpha2hhckBzeW5vcHN5cy5jb20+ + "Hi Stephen,\n" + "\n" + "On Wed, 2017-04-19 at 09:49 -0700, sboyd@codeaurora.org wrote:\n" + "> On 04/05, Vlad Zakharov wrote:\n" + "> > \n" + "> > Hi Stephen,\n" + "> > \n" + "> > On Tue, 2017-04-04 at 18:35 -0700, Stephen Boyd wrote:\n" + "> > > \n" + "> > > > \n" + "> > > > +\302\240\302\240\302\240\302\240\302\240.pll_table = (struct pll_of_table []){\n" + "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240{\n" + "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240.prate = 27000000,\n" + "> > > \n" + "> > > Can this be another clk in the framework instead of hardcoding\n" + "> > > the parent rate?\n" + "> > \n" + "> > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get\n" + "> > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching\n" + "> > for\n" + "> > the correct table comparing .parent_node field with real hardware parent clock frequency:\n" + "> > ---------------------------------->8------------------------------------\n" + "> > for (i = 0; pll_table[i].prate != 0; i++)\n" + "> > \302\240 \302\240 if (pll_table[i].prate == prate)\n" + "> > \302\240 \302\240 \302\240 \302\240 return pll_table[i].pll_cfg_table;\n" + "> > ---------------------------------->8------------------------------------\n" + "> \n" + "> When is that done though? During round_rate and recalc_rate the\n" + "> parent frequency is passed into the function, so it should be\n" + "> possible to use that if the tree is properly expressed.\n" + "> \n" + "\n" + "I think that we haven't understood each other correctly.\n" + "Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't\n" + "have situations when such plls can be driven by different parent clock. So this approach is not required at the moment.\n" + "I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better\n" + "provide a new patch.\n" + "\n" + "> > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk\n" + "> > registration\n" + "> > functions please? In which cases they are preferred?\302\240\n" + "> > \n" + "> \n" + "> We're trying to split the consumer and provider APIs along struct\n" + "> clk_hw and struct clk respectively. If we can have drivers only\n" + "> registers clk_hw pointers and never get back anything but an\n" + "> error code, then we can force consumers to always go through the\n" + "> clk_get() family of APIs. Then we can easily tell who is a\n" + "> provider, who is a consumer, and who is a provider + a consumer.\n" + "> Right now this isn't always clear cut because clk_hw has access\n" + "> to struct clk, and also clk_register() returns a clk pointer, but\n" + "> it doesn't really get used by anything in a provider driver,\n" + "> unless provider drivers are doing something with the consumer\n" + "> API.\n" + "\n" + "I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not\n" + "still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating\n" + "or probing themselves? And what clk consumer can be used for?\n" + "\n" + "> \n" + "> > \n" + "> > > \n" + "> > > \n" + "> > > > \n" + "> > > > +}\n" + "> > > > +\n" + "> > > > +CLK_OF_DECLARE(axs10x_pll_clock, \"snps,axs10x-arc-pll-clock\", of_pll_clk_setup);\n" + "> > > \n" + "> > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the\n" + "> > > driver need to probe and also have this of declare happen? Is the\n" + "> > > PLL special and needs to be used for the timers?\n" + "> > \n" + "> > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to\n" + "> > drive PGU clock frequency and other subsystems and so we add usual probe func.\n" + "> > \n" + "> \n" + "> Presumably we'll have different compatible strings for the\n" + "> different PLLs then? CLK_OF_DECLARE() will make it so that the\n" + "> device node that matches never gets a ->probe() from a\n" + "> platform_driver called on it. If you want it to be called twice,\n" + "> then you need to use CLK_OF_DECLARE_DRIVER() instead.\n" + "> \n" + "\n" + "In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe\n" + "functions. So maybe I can somehow avoid this code duplication?\302\240\n" + "I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some\n" + "peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case\n" + "I've written usual probe function. Maybe I am mistaken and it is not the right way?\n" + "\n" + "Thank you for you answers.\302\240\n" + "\n" + "-- \n" + "Best regards,\n" + Vlad Zakharov <vzakhar@synopsys.com> -d11ed90f5a6ef5386ec18bfc4d9d68adec3aeddd9e4dfae997b6e00e94df80a4 +1030bf4064419e19e8454b3c55e9a696ecabcfc50aa02fc6ed883f7b032c5c0e
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.