From: Vlad Zakharov <Vladislav.Zakharov@synopsys.com>
To: "sboyd@codeaurora.org" <sboyd@codeaurora.org>
Cc: "mark.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>
Subject: Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver
Date: Thu, 20 Apr 2017 15:13:41 +0000 [thread overview]
Message-ID: <1492701221.18176.51.camel@synopsys.com> (raw)
In-Reply-To: <20170419164949.GH7065@codeaurora.org>
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+
WARNING: multiple messages have this Message-ID (diff)
From: Vladislav.Zakharov@synopsys.com (Vlad Zakharov)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v2] clk/axs10x: introduce AXS10X pll driver
Date: Thu, 20 Apr 2017 15:13:41 +0000 [thread overview]
Message-ID: <1492701221.18176.51.camel@synopsys.com> (raw)
In-Reply-To: <20170419164949.GH7065@codeaurora.org>
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vlad Zakharov <Vladislav.Zakharov@synopsys.com>
To: "sboyd@codeaurora.org" <sboyd@codeaurora.org>
Cc: "mark.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>
Subject: Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver
Date: Thu, 20 Apr 2017 15:13:41 +0000 [thread overview]
Message-ID: <1492701221.18176.51.camel@synopsys.com> (raw)
In-Reply-To: <20170419164949.GH7065@codeaurora.org>
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>
next prev parent reply other threads:[~2017-04-20 15:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 13:11 [PATCH v2] clk/axs10x: introduce AXS10X pll driver Vlad Zakharov
2017-02-21 13:11 ` Vlad Zakharov
2017-03-03 13:18 ` Vlad Zakharov
2017-03-03 13:18 ` Vlad Zakharov
2017-03-03 13:18 ` Vlad Zakharov
2017-03-03 13:18 ` Vlad Zakharov
2017-03-03 23:50 ` Stephen Boyd
2017-03-03 23:50 ` Stephen Boyd
2017-03-03 23:50 ` Stephen Boyd
2017-03-29 11:20 ` Vlad Zakharov
2017-03-29 11:20 ` Vlad Zakharov
2017-03-29 11:20 ` Vlad Zakharov
2017-03-29 11:20 ` Vlad Zakharov
2017-04-03 10:54 ` Jose Abreu
2017-04-03 10:54 ` Jose Abreu
2017-04-03 10:54 ` Jose Abreu
2017-04-05 1:35 ` Stephen Boyd
2017-04-05 1:35 ` Stephen Boyd
2017-04-05 1:35 ` Stephen Boyd
2017-04-05 16:06 ` Vlad Zakharov
2017-04-05 16:06 ` Vlad Zakharov
2017-04-05 16:06 ` Vlad Zakharov
2017-04-19 16:49 ` sboyd
2017-04-19 16:49 ` sboyd
2017-04-20 15:13 ` Vlad Zakharov [this message]
2017-04-20 15:13 ` Vlad Zakharov
2017-04-20 15:13 ` Vlad Zakharov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492701221.18176.51.camel@synopsys.com \
--to=vladislav.zakharov@synopsys.com \
--cc=Jose.Abreu@synopsys.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.