From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Turquette Subject: Re: regression: Clock changes in next-20141205 break at least omap4 Date: Fri, 19 Dec 2014 16:23:49 -0800 Message-ID: <20141220002349.29014.63354@quantum> References: <20141212194238.20398.33333@quantum> <54908F8D.2020202@nvidia.com> <20141216202301.GF11502@n2100.arm.linux.org.uk> <20141216205754.GG11502@n2100.arm.linux.org.uk> <1418809957.3347.1.camel@pengutronix.de> <20141218233739.29014.73421@quantum> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Paul Walmsley Cc: Nishanth Menon , khilman@linaro.org, Russell King - ARM Linux , Tomeu Vizoso , Tony Lindgren , Stephen Boyd , t-kristo@ti.com, Paul Walmsley , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lucas Stach List-Id: linux-omap@vger.kernel.org UXVvdGluZyBQYXVsIFdhbG1zbGV5ICgyMDE0LTEyLTE4IDE4OjE1OjU5KQo+IE9uIFRodSwgMTgg RGVjIDIwMTQsIE1pa2UgVHVycXVldHRlIHdyb3RlOgo+IAo+ID4gUXVvdGluZyBQYXVsIFdhbG1z bGV5ICgyMDE0LTEyLTE4IDExOjIzOjA3KQo+ID4KPiA+ID4gRmxpcHBpbmcgb3ZlciBmcm9tIGhh cmR3YXJlIHRvIHNvZnR3YXJlLCBpbiB0aGUgTGludXggY2xvY2sgdHJlZSwgdGhlcmUncyAKPiA+ ID4gdXN1YWxseSBub3QgbXVjaCBwb2ludCB0byBtb2RlbGluZyB0aGUgVkNPL0RDTyBkaXJlY3Rs eSBiZWNhdXNlIGl0IHRlbmRzIAo+ID4gPiBub3QgdG8gYmUgdW5kZXIgdGhlIGRpcmVjdCBjb250 cm9sIG9mIHRoZSBPUywgYW5kIGl0IGlzIHVzdWFsbHkgdGlnaHRseSAKPiA+ID4gaW50ZWdyYXRl ZCBpbnRvIHRoZSBQTExzIGZyb20gYSBoYXJkd2FyZSBwb2ludCBvZiB2aWV3LiAgQnV0IHVubGlr ZSBtb3N0IAo+ID4gPiBvZiB0aGUgTGludXggY2xvY2sgdHJlZSBub2RlcyB0aGF0IGFyZSBkb3du c3RyZWFtIGZyb20gY2xvY2sgc291cmNlcywgCj4gPiA+IHdoaWNoIHVzZSBjbG9ja3MgdGhhdCBh cmUgZWxlY3RyaWNhbGx5IGRyaXZlbiBieSB0aGUgY2xvY2sgc291cmNlLCB0aGUgCj4gPiA+IGNs b2NrIHNpZ25hbCB0aGF0IFBMTHMgYW5kIFBMTC1saWtlIGNsb2NrcyBnZW5lcmF0ZSBpcyBub3Qg ZGlyZWN0bHkgZHJpdmVuIAo+ID4gPiBieSB0aGUgcmVmZXJlbmNlIGNsb2NrLgo+ID4gCj4gPiBI aSBQYXVsLAo+IAo+IEhpIE1pa2UsCj4gCj4gPiBUaGlzIGlzIGRlYmF0YWJsZSBnaXZlbiB0aGF0 IHRoZSBmb3JtdWxhIHRvIGRldGVybWluZSB0aGUgT01BUCBEUExMIAo+ID4gb3V0cHV0IHJhdGUg ZGlyZWN0bHkgZGVwZW5kcyB1cG9uIHRoZSByYXRlIG9mIHRoZSBpbnB1dCBjbG9jayAob3NjLCAK PiA+IDMyS2h6LCBoc2QsIGJ5cGFzcywgZXRjKS4gSSdtIG5vdCBzcGVha2luZyBmb3IgYWxsIFBM THMsIGp1c3QgZm9yIHRoZSAKPiA+IE9NQVAgb25lcyB0aGF0IEkgYW0gZmFtaWxpYXIgd2l0aC4K PiAKPiBUaGUgZnJlcXVlbmN5IGFuZCBwaGFzZSBub2lzZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl IFBMTCdzIG91dHB1dCBzaWduYWwgCj4gYXJlIHBhcnRpYWxseSBhIGZ1bmN0aW9uIG9mIHRoZSBy ZWZlcmVuY2UgY2xvY2suICBCdXQgdGhhdCdzIG9ubHkgYmVjYXVzZSAKPiB0aGUgcmVmZXJlbmNl IGNsb2NrIGlzIHVzZWQgdG8gc3RlZXIgdGhlIFZDTy4gIEl0J3Mgbm90IGJlY2F1c2UgdGhlIAo+ IHJlZmVyZW5jZSBjbG9jayBpdHNlbGYgYXBwZWFycyBvbiB0aGUgUExMIG91dHB1dC4gIEV2ZW4g aWYgdGhlIHJlZmVyZW5jZSAKPiBjbG9jayBkaXZpZGVycyBhbmQgVkNPIGxvb3AgZGl2aWRlcnMg d2VyZSBib3RoIHNldCB0byBkaXZpZGUtYnktb25lLCB0aGUgCj4gcmVmZXJlbmNlIGNsb2NrIHN0 aWxsIHdvdWxkIG5vdCBhcHBlYXIgb24gdGhlIFBMTCBvdXRwdXQgLSBtZXJlbHkgYSAKPiBzaW11 bGFjcnVtIG9mIGl0LCBvcmlnaW5hdGluZyBieSB0aGUgVkNPLiAgVGhlIFBMTCdzIG91dHB1dCBj bG9jayBpcywgCj4gZWxlY3RyaWNhbGx5LCBkaXJlY3RseSBkcml2ZW4gYnkgdGhlIFZDTy4KPiAK PiBQYWdlIDUgb2YgdGhpcyBQREYgaGFzIGEgbmljZSBmcmVxdWVuY3kgc3ludGhlc2lzIFBMTCBi bG9jayBkaWFncmFtIHdpdGggCj4gaW50ZWdlciBkaXZpZGVyczoKPiAKPiAgICAgaHR0cDovL3d3 dy50aS5jb20vbGl0L2FuL3N3cmEwMjkvc3dyYTAyOS5wZGYKPiAKPiBUbyByZXBocmFzZSwgaWYs IGluIHRoZSBibG9jayBkaWFncmFtIGFib3ZlLCBvbmUgd2VyZSB0byByZW1vdmUgZXZlcnl0aGlu ZyAKPiBmcm9tIHRoZSBUQ1hPIHJlZmVyZW5jZSBjbG9jayBvbiB0aGUgbGVmdCB0byB0aGUgdHJp YW5nbGUgdG8gdGhlIGxlZnQgb2YgCj4gdGhlIFZDTywgYW5kIHRvIHJlcGxhY2UgYWxsIHRoYXQg d2l0aCBhIGNvbnN0YW50IHZvbHRhZ2UgaW5wdXQgdG8gdGhlIFZDTywgCj4geW91J2Qgc3RpbGwg Z2V0IGEgY2xvY2sgc2lnbmFsIG91dCBvZiB0aGUgSVAgYmxvY2ssIGV2ZW4gdGhvdWdoIHRoZSAK PiByZWZlcmVuY2UgY2xvY2sgd291bGQgbm8gbG9uZ2VyIGV4aXN0LgoKWWVzLCB5b3VyIHBvaW50 IGlzIGNvbXBsZXRlbHkgdmFsaWQuIEJ1dCBUSSdzIG93biBjbG9jayB0cmVlIGRpYWdyYW1zCih3 aGljaCBzYWRseSBkbyBub3QgbWFrZSBpdCBpbnRvIGFueSBUUk0gdGhhdCBJIGtub3cgb2YpIHNo b3cgYSBjYXNjYWRlCnN0YXJ0aW5nIGF0IHN5c19jbGssIGNvbnRpbnVpbmcgdGhyb3VnaCBlYWNo IERQTEwsIHRoZSBNeCBvdXRwdXQgYW5kIHNvCm9uIGFuZCBzbyBmb3J0aC4gSSB3b3VsZCBsaW5r IGl0IGlmIGl0IHdhcyBwdWJsaWMgOi0vCgpTYW1zdW5nJ3MgRXh5bm9zIFRSTXMgZG8gYSBncmVh dCBqb2Igb2YgaWxsdXN0cmF0aW5nIHRoZSBjbG9jayB0cmVlCnBhdGhzIGFuZCBteSBmZWVkYmFj ayB0byB0aGUgVFJNIHRlYW0gYXQgVEkgbmV2ZXIgc2VlbWVkIHRvIHRha2Ugcm9vdC4KCkluIGFk ZGl0aW9uIHRoZSBjbG9jayB0cmVlIHRvb2wgZnJvbSBUSVswXSBmb2xsb3dzIHRoZSBzYW1lIHRy ZW5kLiBUaGlzCnRvb2wgaXMgZGV2ZWxvcGVkIGJ5IGFuIGluZGVwZW5kZW50IHRlYW0gdGhhdCBo YXMgbm8gcmVsYXRpb25zaGlwIHRvIHRoZQpmb2xrcyB3b3JraW5nIG9uIFNvQyBvcGVyYXRpbmcg c3lzdGVtIHNvZnR3YXJlLgoKSW4gc2hvcnQsIHRoZSBtYW51ZmFjdHVyZXIncyB2aXN1YWxpemF0 aW9uIG9mIHRoZSBjbG9jayBzaWduYWwgY2hhaW4KdHJlYXRzIHRoZSBzeXN0ZW0gY2xvY2sgYXMg YSBwYXJlbnQgb2YgdGhlIERQTExzLgoKPiAKPiA+ID4gU28gd2h5IGlzIGEgcmVmZXJlbmNlIGNs b2NrIGxpc3RlZCBhcyBhIExpbnV4IHBhcmVudCBjbG9jayBvZiBhbiBPTUFQIFBMTD8gIAo+ID4g PiBBdCBsZWFzdCBmb3IgT01BUCwgaXQgd2FzIHNvcnQgb2Ygc2hvZWhvcm5lZCBpbiB0byByZXBy ZXNlbnQgYSBnYXRpbmcgCj4gPiA+IGRlcGVuZGVuY3kuICBJdCB3YXMgYSB3YXkgb2Ygc3RhdGlu ZyB0aGF0IHRoZSByZWZlcmVuY2UgY2xvY2sgaGFkIHRvIGJlIAo+ID4gPiBlbmFibGVkIGZvciB0 aGUgUExMIHRvIGdlbmVyYXRlIGFuIG91dHB1dCBjbG9jay4gIChUaGUgb2ZmLWNoaXAgY3J5c3Rh bCAKPiA+ID4gb3NjaWxsYXRvciB0aGF0IGRyaXZlcyBtb3N0IG9mIHRoZSBQTEwgcmVmZXJlbmNl IGNsb2NrcyBjb3VsZCBiZSBkaXNhYmxlZCAKPiA+ID4gd2hlbiBhbGwgb2YgaXRzIHVzZXJzIHdl cmUgaWRsZSwgdG8gc2F2ZSBlbmVyZ3kuKSAgQnV0IHRoaXMgdHlwZSBvZiBnYXRpbmcgCj4gPiA+ IGRlcGVuZGVuY3kgaXMgZXF1YWxseSB0cnVlIGZvciwgc2F5LCBhIHNlcGFyYXRlIGZ1bmN0aW9u YWwgY2xvY2sgdGhhdCB0aGUgCj4gPiA+IGNsb2NrIHNvdXJjZSByZXF1aXJlcyBpbiBvcmRlciB0 byBvcGVyYXRlLiAgKE9NQVAgUExMcyBkaWRuJ3QgaGF2ZSBhIAo+ID4gPiBzZXBhcmF0ZSBmdW5j dGlvbmFsIGNsb2NrLCBhdCBsZWFzdCBub3QgdGhhdCBJIHdhcyBhd2FyZSBvZjsgYnV0IHRoYXQn cyAKPiA+ID4gbm90IHRydWUgZm9yIHNvbWUgc2ltaWxhciBjbG9jayBzb3VyY2VzIHVzZWQgaW4g b3RoZXIgU29Dcy4pCj4gPiAKPiA+IFVzaW5nIHlvdXIgdGVybWlub2xvZ3kgYWJvdmUsIGl0IGlz IHBvc3NpYmxlIHRvIGRvIHdoYXQgeW91IHdhbnQgdG8gZG8KPiA+IHRvZGF5IHdpdGhvdXQgYW55 IGNoYW5nZSB0byB0aGUgY2xvY2sgZnJhbWV3b3JrLiBTaW1wbHkgbWFrZSBlYWNoIERQTEwgYQo+ ID4gZGV2aWNlLiBUaGF0IGRldmljZSBjYWxscyBjbGtfZ2V0LCBjbGtfcHJlcGFyZV9lbmFibGUg b24gdGhlIGlucHV0Cj4gPiByZWZlcmVuY2UgY2xvY2suIAo+IAo+IEkgdGhpbmsgSSBkaWQgc29t ZXRoaW5nIGxpa2UgdGhhdCB3aXRoIHRoZSBUZWdyYSBERkxMIGRyaXZlciBsYXN0IHllYXIuICAK PiBFeGNlcHQgdGhlIGNsb2NrIHByb3ZpZGVyIGRldmljZSB3YXMgdGhlIERGTEwgSVAgYmxvY2sg aXRzZWxmLCB3aXRoIGl0cyAKPiBvd24gcmVnaXN0ZXJzLCBldGMuLCBhbmQgbm90IGFuIGFkZGl0 aW9uYWwgYWJzdHJhY3Rpb24sIGlmIEkgcmVjYWxsIAo+IGNvcnJlY3RseS4KClRoaXMgc291bmRz IGxpa2Ugd2hhdCBJIGhhZCBpbiBtaW5kLCBpZiBJIHdhcyBub3QgY2xlYXIgYWJvdmUuCgo+IAo+ IE15IGludGVyZXN0IGlzIG1vc3RseSB0byBkZXRlcm1pbmUgd2hldGhlciBzb21lIG9mIHRoYXQg c3BlY2lhbC1jYXNlIGNvZGUgCj4gY2FuIGJlIGNvbnZlcnRlZCBpbnRvIGRhdGEgdGhhdCB0aGUg Q0NGIGNvcmUgY2FuIG9wZXJhdGUgb24sIGluIGEgCj4gY29uc2lzdGVudCBtYW5uZXIgdGhhdCB3 b3VsZCBiZSB1c2VmdWwgYWNyb3NzIHBsYXRmb3JtcywgYW5kIGluIGEgd2F5IHRoYXQgCj4gc2V2 ZXJhbCBwZW9wbGUgY291bGQgcG90ZW50aWFsbHkgYWdyZWUgb24uCj4gCj4gPiBDb2luY2lkZW50 YWxseSB0aGVzZSBuZXcgRFBMTCBkZXZpY2UgYXJlIGNsb2NrIHByb3ZpZGVycyB0aGVtc2VsdmVz IGFuZCAKPiA+IHRoZXkgcHJvdmlkZSByb290IGNsb2NrcyBvZiB0aGVpciBvd24gd2hpY2ggYXJl IHRoZSBEUExMcyBhbmQgCj4gPiBjb3JyZXNwb25kaW5nIE14IG91dHB1dHMuIFRoaXMgbW9kZWwg d291bGQgdHJlYXQgdGhlIHJlZmVyZW5jZSBjbG9jayBhcyAKPiA+IHNvbWV0aGluZyB0aGF0IGRy aXZlcyB0aGUgRFBMTCBkZXZpY2UncyBsb2dpYywgYnV0IG5vdCBhcyBhIHBhcnQgb2YgdGhlIAo+ ID4gY2xvY2sgc2lnbmFsIGNoYWluLgo+ID4gCj4gPiBJIGRvbid0IHBlcnNvbmFsbHkgYWdyZWUg d2l0aCB0aGUgaWRlYSB0aGF0IHRoZSByZWZlcmVuY2UgY2xvY2sgaXMgbm90IGEKPiA+IHBhcmVu dCBvZiB0aGUgRFBMTCwKPiAKPiBJJ2QgYmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB5b3Ugd291 bGQgZGVmaW5lIGEgcGFyZW50IGNsb2NrLCBpZiBpdCAKPiBkaWZmZXJzIGZyb20gdGhlIGVsZWN0 cmljYWwgInNvdXJjZSBjbG9jayIgZGVmaW5pdGlvbiB0aGF0IEkgbWVudGlvbmVkLgoKTXkgbGVz cy1yaWdvcm91cyBkZWZpbml0aW9uIGlzIGEgY2xvY2sgc2lnbmFsIHdoaWNoIGlzIGZlZCBpbnRv IHNvbWUKc2luayAoaW4gdGhpcyBjYXNlIGFub3RoZXIgY2xvY2sgZ2VuZXJhdG9yIElQKSBhbmQg aGFzIGEgdGFuZ2VudGlhbApyZWxhdGlvbnNoaXAgb3IgZWZmZWN0IG9uIGl0cyBvdXRwdXQgcmF0 ZS4gSW4gdGhlIGV2ZW50IG9mIG1vcmUgdGhhbiBvbmUKYWN0aXZlIGNsb2NrIHNpZ25hbCBnb2lu ZyBpbnRvIHRoZSBJUCBibG9jaywgdGhlbiB0aGUgY3VycmVudCBwYXJlbnQgaXMKdGhlIG9uZSB0 aGF0IGhhcyB0aGUgbW9zdCByZWFzb25hYmxlIGFmZmVjdCBvbiB0aGUgY2xvY2sgc2lnbmFsIHJh dGUgb2YKdGhlIGRvd25zdHJlYW0gY2xvY2sgZ2VuZXJhdG9yLgoKSW4gc2hvcnQsIHRoZSBwYXJl bnQgaXMgdGhlIG9uZSB0aGF0IHlvdSB0aGluaywgIm9oIGdlZSwgdGhhdCdzIHRoZQpwYXJlbnQg Y2xvY2siIHRoZSBmaXJzdCB0aW1lIHRoYXQgeW91IGxvb2sgYXQgdGhlIHNjaGVtYXRpYy4KCj4g Cj4gVGhlIExpbnV4IGNsb2NrIHRyZWUgaXMgYSBzb2Z0d2FyZSBhYnN0cmFjdGlvbi4gIFNvIG9u ZSBjb3VsZCBkZWZpbmUgCj4gInBhcmVudCBjbG9jayIgaG93ZXZlciBvbmUgd2lzaGVzLiAgKFRo YXQncyBub3QgdG8gc2F5IHRoYXQgYWxsIAo+IGRlZmluaXRpb25zIGFyZSBlcXVhbGx5IHVzZWZ1 bC4uLikgCj4gCj4gT25lIGNvdWxkIHN0YXRlLCBmb3IgZXhhbXBsZSwgdGhhdCBhIHBhcmVudCBj bG9jayBpcyBhbnkgY2xvY2sgdGhhdCBoYXMgCj4gc29tZSBlZmZlY3Qgb24gdGhlIG91dHB1dCBv ZiB0aGUgY2hpbGQgY2xvY2suICBUaGF0IHdvdWxkIGJlIG9uZSAKPiBkZWZpbml0aW9uIHdoaWNo IG1pZ2h0IGJlIGNvbnNpc3RlbnQgd2l0aCB5b3VyIGNvbW1lbnRzLiAgVGhlIHByb2JsZW0gd2l0 aCAKPiB0aGF0IGlzIHRoYXQgaXQgbWVhbnMgdGhhdCBhIGNsb2NrIGNhbiBoYXZlIG11bHRpcGxl IHNpbXVsdGFuZW91c2x5LWFjdGl2ZSAKPiBwYXJlbnRzLCB3aGljaCBJJ2QgbmHDr3ZlbHkgdGhp bmsgd2UnZCB3YW50IHRvIGF2b2lkLCBpZiB3ZSBjb3VsZC4KCllvdSdyZSByaWdodCB0byBzYXkg dGhhdCB3ZSdyZSB0YWxraW5nIGFib3V0IGEgc29mdHdhcmUgYWJzdHJhY3Rpb24uIEluCmdlbmVy YWwgd2Ugc2hvdWxkIG1vZGVsIHRoaXMgYWJzdHJhY3Rpb24gYWZ0ZXIgdGhlIGhhcmR3YXJlIGFz IG11Y2ggYXMKcG9zc2libGUgdG8ga2VlcCBkZWJ1Z2dpbmcgYW5kIG91ciB1bmRlcnN0YW5kaW5n IG9mIHRoZSBwbGF0Zm9ybSBzYW5lLgpUaG91Z2ggdGhlcmUgYXJlIGxpbWl0cyB0byBob3cgY2xv c2VseSB3ZSB3YW50IHRvIG1vZGVsIHRoZSBoYXJkd2FyZQoocGxlYXNlIGltYWdpbmUgYSBjbGV2 ZXIgam9rZSBhYm91dCAic3RydWN0IHNwaW5uaW5nX2VsZWN0cm9uIiBoZXJlKS4KCkknbSBoYXBw eSB0byB1cGRhdGUgdGhlIGRvY3VtZW50YXRpb24gd2l0aCBndWlkZWxpbmVzIGZvciBob3cgZHJp dmVyCndyaXRlcnMgc2hvdWxkIHBhcnRpdGlvbiB0aGluZ3MgdG8gc3RheSBpbiBsaW5lIHdpdGgg dGhlaXIgaGFyZHdhcmUgb25jZQp3ZSBoYXZlIHRoYXQgZGlzY3Vzc2lvbiBhbmQgc2V0dGxlIG9u IHNvbWUgZ3VpZGVsaW5lcy4KClVuZGVyc3RhbmRpbmcgb2YgdGhlIGhhcmR3YXJlIHZhcmllcyB3 aWxkbHkgdGhvdWdoLCBvZnRlbiBkdWUgdG8gcG9vciBvcgp6ZXJvIGRvY3VtZW50YXRpb24uIEFu ZCBhZGRpdGlvbmFsbHkgSSBkb24ndCB3YW50IHRvIGNyZWF0ZSBhbnkgbmV3Cmhvb3BzIGZvciBw ZW9wbGUgdG8ganVtcCB0aHJvdWdoIGlmIGl0IGJyaW5ncyBubyB0YW5naWJsZSBnYWluIHRvIHRo ZQpzb2Z0d2FyZSAoYmV0dGVyIGRlYnVnYWJpbGl0eSwgZGVjcmVhc2VkIGNvZGUgc2l6ZSwgYmV0 dGVyIHBvd2VyCnNhdmluZ3MsIG1vcmUgYXdlc29tZXIgYXBpcyBleHBvc2VkIHRvIGRldmljZSBk cml2ZXJzLCBldGMpLgoKRmluYWxseSwgSSBrbm93IEkgY29udGludWUgdG8gYXJndWUgdGhlIHBv aW50LCBidXQgSSB3b3VsZCBub3QgaGF2ZSBhbnkKcHJvYmxlbSBtZXJnaW5nIGNoYW5nZXMgdG8g cmVtb3ZlIHN5c19jbGsgYXMgdGhlIHBhcmVudCBvZiB0aGUgRFBMTHMuIEkKZ3Vlc3MgSSdtIGp1 c3QgZmVlbGluZyBhcmd1bWVudGF0aXZlLiBJZiB5b3UgYW5kIHRoZSBUSSBmb2xrcyBmZWVsIGxp a2UKdGhhdCBpcyB0aGUgcmlnaHQgd2F5IHRvIGdvIHRoZW4gYnkgYWxsIG1lYW5zLgoKWzBdIGh0 dHA6Ly93d3cudGkuY29tL2dlbmVyYWwvZG9jcy93dGJ1L3d0YnVkb2N1bWVudGNlbnRlci50c3A/ dGVtcGxhdGVJZD02MTIzJm5hdmlnYXRpb25JZD0xMjgwNAoKUmVnYXJkcywKTWlrZQoKPiAKPiBJ IGFsc28gaGF2ZSB0byBhZG1pdCB0aGF0IG15IGJpYXMgaXMgdG93YXJkcyBkZWZpbml0aW9ucyB3 aXRoIHNvbWUga2luZCBvZiAKPiByZWxhdGlvbnNoaXAgdG8gdGhlIGhhcmR3YXJlLCB3aGljaCBo ZWxwcyBhdm9pZCB0aGUgInV0dGVyIHJlbGF0aXZpc20iIAo+IHByb2JsZW0gdGhhdCB5b3UgbWVu dGlvbiBiZWxvdy4KPiAKPiA+IGJ1dCBJIGRvbid0IG9wcG9zZSBhbnkgY2hhbmdlIHRvIHRoZSBP TUFQIGNsb2NrIGRyaXZlciBhbG9uZyB0aG9zZSBsaW5lcyAKPiA+IHNvIGxvbmcgYXMgaXQgaXMg ZG9uZSBpbiBhIHNhbmUgd2F5LiBJdCBzZWVtcyB0aGVyZSBpcyBuZXZlciBqdXN0IG9uZSAKPiA+ IGNvcnJlY3Qgd2F5IHRvIGxvb2sgYXQgdGhlc2UgdGhpbmdzLgo+IAo+IEknZCBzYXkgdGhhdCB0 byB0aGUgZXh0ZW50IHRoYXQgb25lIGNvdWxkIGNvbWUgdXAgd2l0aCBjb25jcmV0ZSAKPiBkZWZp bml0aW9ucyBmb3IgdGVybXMgbGlrZSAicGFyZW50IGNsb2NrcywiIGl0IGFsbG93cyBvdGhlcnMg dG8gcmVhc29uIAo+IGFib3V0IGhvdyB0aGUgQ0NGIHNob3VsZCB3b3JrLCBoZWxwcyBkaXN0aW5n dWlzaCBiZXR3ZWVuIGRhdGEgYW5kIGNvZGUgCj4gY2hhbmdlcyB0aGF0IGRvIGFuZCBkb24ndCBt YWtlIHNlbnNlLCBhbmQgaGVscHMgb3RoZXJzIHVuZGVyc3RhbmQgd2hpY2ggCj4gY2hhbmdlcyBt aWdodCBiZSBhY2NlcHRhYmxlIHRvIG1haW50YWluZXJzLgo+IAo+ID4gPiBUaGUgY2xvY2sgZnJh bWV3b3JrIHdhc24ndCByZS1lbnRyYW50IGJhY2sgdGhlbiwgYW5kIHdlIHdhbnRlZCB0byBhdm9p ZCAKPiA+ID4gaW1wbGVtZW50aW5nIHJlLWVudHJhbmN5IGJlY2F1c2Ugd2Ugd2VyZSB3b3JyaWVk IHRoYXQgaXQgY291bGQgdHVybiBpbnRvIGEgCj4gPiA+IG1lc3MuICBTbyB3ZSBqdXN0IHdvdW5k IHVwIGxpc3RpbmcgdGhlIHJlZmVyZW5jZSBjbG9jayBhcyB0aGUgUExMJ3MgTGludXggCj4gPiA+ IHBhcmVudCBjbG9jay4KPiA+ID4gCj4gPiA+IE15IG9yaWdpbmFsIGNvbW1lbnQgd2FzIGp1c3Qg aW50ZW5kZWQgdG8gYmUgYSByZWZsZWN0aW9uIG9uIHdoYXQgaXQgbWVhbnMgCj4gPiA+IHRvIGJl IGEgInBhcmVudCBjbG9jayIgaW4gdGhlIExpbnV4IGNsb2NrIHRyZWUgc2Vuc2UuICBJZiBpdCdz IGludGVuZGVkIHRvIAo+ID4gPiByZXByZXNlbnQgInNvdXJjZSBjbG9ja3MiIGFzIHRoZXkgYXJl IGRlZmluZWQgYWJvdmUsIHRoZW4gUExMcyBhbmQgCj4gPiA+IFBMTC1saWtlIGNsb2NrcyBzaG91 bGQgYmUgcm9vdCBub2RlcywgZXhjZXB0IGZvciB0aGUgZmV3IGNhc2VzIHdoZXJlIGl0J3MgCj4g PiA+IHVzZWZ1bCB0byBhZGQgYSBub2RlIGZvciB0aGUgdW5kZXJseWluZyBzb3VyY2Ugb3NjaWxs YXRvciBkaXJlY3RseSAoZm9yIAo+ID4gPiBleGFtcGxlLCBpZiBvcGVuLWxvb3AgbW9kZSBpcyBz dXBwb3J0ZWQpLgo+ID4gPiAKPiA+ID4gVGhpcyBtaWdodCBiZSB0aGUgcmlnaHQgd2F5IGZvcndh cmQgZm9yIHRoZSB0aW1lIGJlaW5nLCBhbmQgSSBsaWtlIHRoZSAKPiA+ID4gaWRlYSBvZiBzdGF0 aW5nIHRoYXQgTGludXggcGFyZW50IGNsb2NrcyBzaG91bGQgcmVwcmVzZW50IGVsZWN0cmljYWwg Cj4gPiA+ICJzb3VyY2UgY2xvY2siIHJlbGF0aW9uc2hpcHMuICAKPiA+ID4gCj4gPiA+IFRoYXQg cmFpc2VzIHRoZSBxdWVzdGlvbiBvZiB3aGF0IHRvIGRvIGFib3V0IHRoZSBhZGRpdGlvbmFsIGdh dGluZyAKPiA+ID4gcmVsYXRpb25zaGlwcy4gIEF0IHRoZSBtb21lbnQsIHRoZSBjbG9jayB0eXBl IGNvZGUgbmVlZHMgdG8gYmUgcmVzcG9uc2libGUgCj4gPiA+IGZvciBjYWxsaW5nIGNsa19lbmFi bGUoKSBldGMuIG9uIGFsbCBvZiB0aGUgcmVmZXJlbmNlIGFuZCBmdW5jdGlvbmFsIAo+ID4gPiBj bG9ja3MgdGhhdCBuZWVkIHRvIGJlIHVuZ2F0ZWQgZm9yIHRoZSBjbG9jayBzb3VyY2UgdG8gd29y ay4gIEJ1dCBpdCBoYXMgCj4gPiA+IGFsd2F5cyBzZWVtZWQgcHJlZmVyYWJsZSB0byBtZSB0byBy ZXByZXNlbnQgZnVuZGFtZW50YWwgaGFyZHdhcmUgCj4gPiA+IHN0cnVjdHVyYWwgY29uc3RyYWlu dHMgaW4gZGF0YS4gIElmIHRoZSBkYXRhIHN0cnVjdHVyZXMgYXJlIHdlbGwtZGVmaW5lZCwgCj4g PiA+IHRoZW4gdGhlIGRhdGEgc2hvdWxkIGJlIHJlbGF0aXZlbHkgZWFzeSB0byBhbmFseXplLCBy ZWFzb24gYWJvdXQsIAo+ID4gPiBnZW5lcmF0ZSwgdmFsaWRhdGUsIHNoYXJlIGFjcm9zcyBwbGF0 Zm9ybXMsIGFuZCBvcGVyYXRlIHVwb24gaXRlcmF0aXZlbHk7IAo+ID4gPiB1bmxpa2UgY3VzdG9t IHBlci1jbG9ja3R5cGUgY29kZSwgd2hpY2ggb2Z0ZW4gaXNuJ3QuCj4gPiAKPiA+IEkgY29tcGxl dGVseSBhZ3JlZSB0aGF0IHRoZSBpbnRlcmZhY2VzIGFuZCBhYnN0cmFjdGlvbnMgaW4gdGhlIGNs b2NrCj4gPiBmcmFtZXdvcmsgZG8gbm90IHNjYWxlIHdlbGwuIEFzIGFuIGV4YW1wbGUsIHRoZXJl IGNvdWxkIGJlIG11Y2ggbW9yZQo+ID4gcmV1c2UgaWYgY2FsbGJhY2tzIHN1Y2ggYXMgLmdldF9i ZXN0X2RpdigpIGV4aXN0ZWQgYW5kIHRoZSBsYXJnZSB2YXJpZXR5Cj4gPiBvZiAucm91bmRfcmF0 ZSgpIGltcGxlbWVudGF0aW9ucyBjb3VsZCBiZSByZXBsYWNlZCBieSBhIHNpbmdsZSBnZW5lcmlj Cj4gPiBvbmUuCj4gPiAKPiA+IEVhc2llciBtaXhpbmcgYW5kIG1hdGNoaW5nIG9mIGNhbGxiYWNr cyB3b3VsZCBiZSBncmVhdCBhcyB3ZWxsLiBXZSBkb24ndAo+ID4gcXVpdGUgaGF2ZSBwb2x5bW9y cGhpc20gYnV0IHNvbWV0aGluZyBiZXR0ZXIgY291bGQgYmUgYWNoaWV2ZWQgdGhhbiB0aGUKPiA+ IGNvbXBsZXggY2xvY2sgdHlwZS4gTmFtZWx5IHRoZSBhYmlsaXR5IHRvIGNvbWJpbmUgdmFyaW91 cyBjbG9jayBoYXJkd2FyZQo+ID4gb3BzIGF0IHJ1bi10aW1lIHdpdGhvdXQgaGF2aW5nIHRvIGFs d2F5cyBnZW5lcmF0ZSB1bmlxdWUgc3RydWN0IGNsa19vcHMKPiA+IHBlciBwbGF0Zm9ybS4KPiA+ IAo+ID4gSSB0aGluayB0aGVyZSBhcmUgbG90cyBvZiBpZGVhcyBvdXQgdGhlcmUgb24gaG93IHRv IGltcHJvdmUgdGhpcyBzdHVmZi4KPiAKPiBPaCwganVzdCBpbiBjYXNlIGl0IGlzbid0IGNsZWFy LCBteSBvYmplY3RpdmUgd2Fzbid0IHRvIGNyaXRpY2l6ZSB0aGUgCj4gZXhpc3RpbmcgQ0NGLiAg SnVzdCB0aGlua2luZyB0aGF0IGlmIGl0IHdhcyBwb3NzaWJsZSB0byBjb21lIHRvIGFuIAo+IGFn cmVlbWVudCBvbiBob3cgdG8gZGVmaW5lIHNvbWUgb2YgdGhlc2UgZW50aXRpZXMsIGl0IG1pZ2h0 IG1ha2UgaXQgZWFzaWVyIAo+IHRvIHJlYXNvbiB0b2dldGhlciBhYm91dCB3YXlzIHRvIHdvcmsg b24gdGhlIGNvcmUgY29kZSBhbmQgZGF0YSAKPiBzdHJ1Y3R1cmVzLiAgSSdkIGhhdGUgdG8gc3Bl bmQgYSBidW5jaCBvZiB0aW1lIHdvcmtpbmcgb24gY2hhbmdlcyB0aGF0IHlvdSAKPiB3b3VsZCBl dmVudHVhbGx5IG5hY2sgYmVjYXVzZSB3ZSBtaWdodCBub3QgYWdyZWUgb24gd2hhdCBhIHBhcmVu dCBjbG9jayBpcyAKPiA6LSkKPiAKPiAKPiAtIFBhdWwKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: mturquette@linaro.org (Mike Turquette) Date: Fri, 19 Dec 2014 16:23:49 -0800 Subject: regression: Clock changes in next-20141205 break at least omap4 In-Reply-To: References: <20141212194238.20398.33333@quantum> <54908F8D.2020202@nvidia.com> <20141216202301.GF11502@n2100.arm.linux.org.uk> <20141216205754.GG11502@n2100.arm.linux.org.uk> <1418809957.3347.1.camel@pengutronix.de> <20141218233739.29014.73421@quantum> Message-ID: <20141220002349.29014.63354@quantum> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Quoting Paul Walmsley (2014-12-18 18:15:59) > On Thu, 18 Dec 2014, Mike Turquette wrote: > > > Quoting Paul Walmsley (2014-12-18 11:23:07) > > > > > Flipping over from hardware to software, in the Linux clock tree, there's > > > usually not much point to modeling the VCO/DCO directly because it tends > > > not to be under the direct control of the OS, and it is usually tightly > > > integrated into the PLLs from a hardware point of view. But unlike most > > > of the Linux clock tree nodes that are downstream from clock sources, > > > which use clocks that are electrically driven by the clock source, the > > > clock signal that PLLs and PLL-like clocks generate is not directly driven > > > by the reference clock. > > > > Hi Paul, > > Hi Mike, > > > This is debatable given that the formula to determine the OMAP DPLL > > output rate directly depends upon the rate of the input clock (osc, > > 32Khz, hsd, bypass, etc). I'm not speaking for all PLLs, just for the > > OMAP ones that I am familiar with. > > The frequency and phase noise characteristics of the PLL's output signal > are partially a function of the reference clock. But that's only because > the reference clock is used to steer the VCO. It's not because the > reference clock itself appears on the PLL output. Even if the reference > clock dividers and VCO loop dividers were both set to divide-by-one, the > reference clock still would not appear on the PLL output - merely a > simulacrum of it, originating by the VCO. The PLL's output clock is, > electrically, directly driven by the VCO. > > Page 5 of this PDF has a nice frequency synthesis PLL block diagram with > integer dividers: > > http://www.ti.com/lit/an/swra029/swra029.pdf > > To rephrase, if, in the block diagram above, one were to remove everything > from the TCXO reference clock on the left to the triangle to the left of > the VCO, and to replace all that with a constant voltage input to the VCO, > you'd still get a clock signal out of the IP block, even though the > reference clock would no longer exist. Yes, your point is completely valid. But TI's own clock tree diagrams (which sadly do not make it into any TRM that I know of) show a cascade starting at sys_clk, continuing through each DPLL, the Mx output and so on and so forth. I would link it if it was public :-/ Samsung's Exynos TRMs do a great job of illustrating the clock tree paths and my feedback to the TRM team at TI never seemed to take root. In addition the clock tree tool from TI[0] follows the same trend. This tool is developed by an independent team that has no relationship to the folks working on SoC operating system software. In short, the manufacturer's visualization of the clock signal chain treats the system clock as a parent of the DPLLs. > > > > So why is a reference clock listed as a Linux parent clock of an OMAP PLL? > > > At least for OMAP, it was sort of shoehorned in to represent a gating > > > dependency. It was a way of stating that the reference clock had to be > > > enabled for the PLL to generate an output clock. (The off-chip crystal > > > oscillator that drives most of the PLL reference clocks could be disabled > > > when all of its users were idle, to save energy.) But this type of gating > > > dependency is equally true for, say, a separate functional clock that the > > > clock source requires in order to operate. (OMAP PLLs didn't have a > > > separate functional clock, at least not that I was aware of; but that's > > > not true for some similar clock sources used in other SoCs.) > > > > Using your terminology above, it is possible to do what you want to do > > today without any change to the clock framework. Simply make each DPLL a > > device. That device calls clk_get, clk_prepare_enable on the input > > reference clock. > > I think I did something like that with the Tegra DFLL driver last year. > Except the clock provider device was the DFLL IP block itself, with its > own registers, etc., and not an additional abstraction, if I recall > correctly. This sounds like what I had in mind, if I was not clear above. > > My interest is mostly to determine whether some of that special-case code > can be converted into data that the CCF core can operate on, in a > consistent manner that would be useful across platforms, and in a way that > several people could potentially agree on. > > > Coincidentally these new DPLL device are clock providers themselves and > > they provide root clocks of their own which are the DPLLs and > > corresponding Mx outputs. This model would treat the reference clock as > > something that drives the DPLL device's logic, but not as a part of the > > clock signal chain. > > > > I don't personally agree with the idea that the reference clock is not a > > parent of the DPLL, > > I'd be interested to know how you would define a parent clock, if it > differs from the electrical "source clock" definition that I mentioned. My less-rigorous definition is a clock signal which is fed into some sink (in this case another clock generator IP) and has a tangential relationship or effect on its output rate. In the event of more than one active clock signal going into the IP block, then the current parent is the one that has the most reasonable affect on the clock signal rate of the downstream clock generator. In short, the parent is the one that you think, "oh gee, that's the parent clock" the first time that you look at the schematic. > > The Linux clock tree is a software abstraction. So one could define > "parent clock" however one wishes. (That's not to say that all > definitions are equally useful...) > > One could state, for example, that a parent clock is any clock that has > some effect on the output of the child clock. That would be one > definition which might be consistent with your comments. The problem with > that is that it means that a clock can have multiple simultaneously-active > parents, which I'd na?vely think we'd want to avoid, if we could. You're right to say that we're talking about a software abstraction. In general we should model this abstraction after the hardware as much as possible to keep debugging and our understanding of the platform sane. Though there are limits to how closely we want to model the hardware (please imagine a clever joke about "struct spinning_electron" here). I'm happy to update the documentation with guidelines for how driver writers should partition things to stay in line with their hardware once we have that discussion and settle on some guidelines. Understanding of the hardware varies wildly though, often due to poor or zero documentation. And additionally I don't want to create any new hoops for people to jump through if it brings no tangible gain to the software (better debugability, decreased code size, better power savings, more awesomer apis exposed to device drivers, etc). Finally, I know I continue to argue the point, but I would not have any problem merging changes to remove sys_clk as the parent of the DPLLs. I guess I'm just feeling argumentative. If you and the TI folks feel like that is the right way to go then by all means. [0] http://www.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12804 Regards, Mike > > I also have to admit that my bias is towards definitions with some kind of > relationship to the hardware, which helps avoid the "utter relativism" > problem that you mention below. > > > but I don't oppose any change to the OMAP clock driver along those lines > > so long as it is done in a sane way. It seems there is never just one > > correct way to look at these things. > > I'd say that to the extent that one could come up with concrete > definitions for terms like "parent clocks," it allows others to reason > about how the CCF should work, helps distinguish between data and code > changes that do and don't make sense, and helps others understand which > changes might be acceptable to maintainers. > > > > The clock framework wasn't re-entrant back then, and we wanted to avoid > > > implementing re-entrancy because we were worried that it could turn into a > > > mess. So we just wound up listing the reference clock as the PLL's Linux > > > parent clock. > > > > > > My original comment was just intended to be a reflection on what it means > > > to be a "parent clock" in the Linux clock tree sense. If it's intended to > > > represent "source clocks" as they are defined above, then PLLs and > > > PLL-like clocks should be root nodes, except for the few cases where it's > > > useful to add a node for the underlying source oscillator directly (for > > > example, if open-loop mode is supported). > > > > > > This might be the right way forward for the time being, and I like the > > > idea of stating that Linux parent clocks should represent electrical > > > "source clock" relationships. > > > > > > That raises the question of what to do about the additional gating > > > relationships. At the moment, the clock type code needs to be responsible > > > for calling clk_enable() etc. on all of the reference and functional > > > clocks that need to be ungated for the clock source to work. But it has > > > always seemed preferable to me to represent fundamental hardware > > > structural constraints in data. If the data structures are well-defined, > > > then the data should be relatively easy to analyze, reason about, > > > generate, validate, share across platforms, and operate upon iteratively; > > > unlike custom per-clocktype code, which often isn't. > > > > I completely agree that the interfaces and abstractions in the clock > > framework do not scale well. As an example, there could be much more > > reuse if callbacks such as .get_best_div() existed and the large variety > > of .round_rate() implementations could be replaced by a single generic > > one. > > > > Easier mixing and matching of callbacks would be great as well. We don't > > quite have polymorphism but something better could be achieved than the > > complex clock type. Namely the ability to combine various clock hardware > > ops at run-time without having to always generate unique struct clk_ops > > per platform. > > > > I think there are lots of ideas out there on how to improve this stuff. > > Oh, just in case it isn't clear, my objective wasn't to criticize the > existing CCF. Just thinking that if it was possible to come to an > agreement on how to define some of these entities, it might make it easier > to reason together about ways to work on the core code and data > structures. I'd hate to spend a bunch of time working on changes that you > would eventually nack because we might not agree on what a parent clock is > :-) > > > - Paul