From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too Date: Fri, 3 Aug 2012 09:30:10 +0100 Message-ID: <20120803083009.GC7416@gmail.com> References: <20120731145443.GY4468@opensource.wolfsonmicro.com> <5017F68B.3060400@linaro.org> <20120731151819.GC4468@opensource.wolfsonmicro.com> <5018D880.5090306@linaro.org> <20120801132022.GS11892@opensource.wolfsonmicro.com> <50193428.5000708@linaro.org> <20120801160824.GB11892@opensource.wolfsonmicro.com> <20120801194134.GA4103@sirena.org.uk> <20120802074517.GA19231@gmail.com> <20120802175604.GF4537@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-ey0-f179.google.com (mail-ey0-f179.google.com [209.85.215.179]) by alsa0.perex.cz (Postfix) with ESMTP id 9E1B726521C for ; Fri, 3 Aug 2012 10:30:12 +0200 (CEST) Received: by eaa13 with SMTP id 13so72707eaa.38 for ; Fri, 03 Aug 2012 01:30:14 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120802175604.GF4537@opensource.wolfsonmicro.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: ola.o.lilja@stericsson.com, alsa-devel@alsa-project.org, linus.walleij@stericsson.com, arnd@arndb.de, linux-kernel@vger.kernel.org, olalilja@yahoo.se, STEricsson_nomadik_linux@list.st.com, lrg@ti.com, linux-arm-kernel@lists.infradead.org List-Id: alsa-devel@alsa-project.org T24gVGh1LCBBdWcgMDIsIDIwMTIgYXQgMDY6NTY6MDRQTSArMDEwMCwgTWFyayBCcm93biB3cm90 ZToKPiBPbiBUaHUsIEF1ZyAwMiwgMjAxMiBhdCAwODo0NToxOEFNICswMTAwLCBMZWUgSm9uZXMg d3JvdGU6Cj4gCj4gPiBPdmVyIHRpbWUsIHRoZSByZXF1ZXN0cyBmb3IgTWFpbnRhaW5lcnMgaGF2 ZSBTbm93YmFsbGVkIChwdW4gaW50ZW5kZWQpLiBNeSAKPiA+IHRhc2sgbm93IHNlZW1zIHRvIGJl IGVuYWJsaW5nIGRyaXZlcnMgZm9yIERldmljZSBUcmVlIF9hbmRfIGZpeCBhbGwgCj4gPiBhc3Nv Y2lhdGVkIGRyaXZlciBidWdzLCBpbmNsdWRpbmcgYW55IHJlcXVlc3RlZCByZXN0cnVjdHVyaW5n IGFuZCBBUEkKPiAKPiBPbmUgdGhpbmcgdG8gYmVhciBpbiBtaW5kIHdpdGggZGV2aWNlIHRyZWUg aXMgdGhhdCBpdCdzIGFsbCBhYm91dAo+IGRlZmluaW5nIGFuIEFCSSAtIGl0J3Mgc3VwcG9zZWQg dG8gYmUgc3RhYmxlIGFuZCBPUyBhZ25vc3RpYyBzbyBpdCBwdXRzCj4gYSBsb3Qgb2YgcHJlc3N1 cmUgb24gdG8gcmVhbGx5IGFkZHJlc3MgcXVhbGl0eSBwcm9ibGVtcyB0aGF0IGJlY29tZQo+IHZp c2libGUgaW4gdGhlIGJpbmRpbmdzLiAgVGhpcyBzdHVmZiBpcyBtdWNoIGxlc3MgY3JpdGljYWwg d2l0aCBwbGF0Zm9ybQo+IGRhdGEsIGl0J3MgcmVsYXRpdmVseSBlYXN5IHRvIGNoYW5nZS4KPgo+ ID4gYWRvcHRpb24uIFdoYXQgeW91IGZhaWwgdG8gbm90aWNlIGlzIHRoYXQgSSBhbSBvbmx5IG9u ZSBwZXJzb24sIGFuZCBob3BwaW5nCj4gPiBhbGwgb3ZlciB0aGUgY29kZS1iYXNlIHRyeWluZyB0 byBkbyBldmVyeW9uZSdzIGJpZGRpbmcgaXMgbm8gbWVhbiBmZWF0LiBJbgo+IAo+IEl0J3MgZmFp cmx5IG9idmlvdXMgdGhhdCBpdCdzIG9ubHkgeW91LCBvciBhdCBsZWFzdCBvbmx5IHlvdSBwb3N0 aW5nCj4gc3R1ZmYgKEkga25vdyBzb21ldGltZXMgdGhlcmUgYXJlIGJpZ2dlciB0ZWFtcyBiZWhp bmQgcGVvcGxlKSAtIHRoZQo+IHByZXNzdXJlIHlvdSdyZSB1bmRlciB0byBnZXQgc29tZXRoaW5n IGluIGlzIHZlcnkgY2xlYXIuICBBIGJpZyBwYXJ0IG9mCj4gd2hhdCBJJ20gc2F5aW5nIGhlcmUg aXMgdGhhdCBpdCB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bCBpZiBjb3VsZCB5b3UKPiBzbG93IGRv d24gYSBiaXQsIGRpc2N1c3MgcHJvYmxlbXMgbW9yZSBhbmQgYXZvaWQgY3V0dGluZyBjb3JuZXJz IHNvCj4gbXVjaC4gIFRoaXMgaXMgbGlrZWx5IHRvIHNhdmUgeW91IHRpbWUgb3ZlcmFsbCwgeW91 J2xsIGhhdmUgYSBtdWNoCj4gaGlnaGVyIHN1Y2Nlc3MgcmF0ZSBhbmQgeW91J2xsIGdldCBtdWNo IGJldHRlciBmZWVkYmFjayBpZiBpdCdzIGNsZWFyCj4gd2hhdCdzIGdvaW5nIG9uIGFuZCB0aGF0 IHRoZXJlJ3MgYW4gaW50ZXJlc3QgaW4gdW5kZXJzdGFuZGluZyB0aGUKPiBpc3N1ZXMuCgpJIGRv IGFncmVlIHRoYXQgaXQgc2hvdWxkIGJlIGNvcnJlY3QsIGJ1dCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIGdldHRpbmcKaXQgOTAlIGNvcnJlY3QgYW5kIGFic29sdXRlbHkgcGVyZmVjdCBpbmNyZWFz ZXMgdGhlIGVmZm9ydCBhdCBsZWFzdCB4Mi4KV2l0aCBzbyBtdWNoIGxlZnQgdG8gZG8sIEkgdGhp bmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGdldCBldmVyeXRoaW5nIGluCmFuZCBmdW5jdGlvbmlu ZywgdGhlbiBmaXggdGhlIG1pbm9yIGlzc3VlcyBhcyB3ZSBjb21lIGFjcm9zcyB0aGVtIGxhdGVy LgpUaGlzIGlzIHdoYXQgSSd2ZSBiZWVuIGRvaW5nIGZyb20gdGhlIHN0YXJ0IGFuZCBpdCdzIGFj dHVhbGx5IGxvb2tpbmcKcHJldHR5IGdvb2QuIEkgYWxzbyBhZ3JlZSB0aGF0IERUIHNob3VsZCBi ZSBPUyBhZ25vc3RpYywgYnV0IGJyZWFraW5nIHVwCk1GRHMgaW50byB0aGVpciBmdW5jdGlvbnMg c2hvdWxkbid0IGJlIGFuIGlzc3VlIGZvciBvdGhlciBPU2VzLiBFaXRoZXIKdGhleSBjYW4gY2hv b3NlIHRvIGJyZWFrIHRoZW0gdXAgYW5kIHVzZSB0aGUgaW5kaXZpZHVhbCBjaGlsZCBjb21wYXRp YmxlCnN0cmluZ3MsIG9yIG9ubHkgdXNlIHRoZSBwYXJlbnQgbm9kZS4KCk15IHBlcnNvbmFsIG9w aW5pb24gaXMgaWYgd2UnZCBzYXQgYXJvdW5kIGRpc2N1c3NpbmcgaG93IGl0IHNob3VsZCBsb29r CnByaW9yIHRvIGRvaW5nIGFueSB3b3JrIGEpIHRoZSBwcm9qZWN0IHByb2JhYmx5IHdvdWxkbid0 IGhhdmUgZXZlbiBnb3QKb2ZmIHRoZSBncm91bmQgeWV0IGFuZCBiKSB3ZSB3b3VsZCBoYXZlIG1v c3QgbGlrZWx5IGdvdCBpdCBhbGwgd3JvbmcsIGFzCm1vc3Qgb2Ygb3VyIGxlYXJuaW5nIGFuZCBr bm93bGVkZ2UgaGFzIGJlZW4gZG9uZS9nYWluZWQgYnkgYWN0dWFsbHkgZG9pbmcKdGhlIHdvcmsu IEluc3RlYWQgSSd2ZSBiZWVuIHVzaW5nIHRoZSBKRkRJIChKdXN0IEZyaWNraW4nIERvIEl0KSAK cGhpbG9zb3BoeSwgYW5kIHdlJ3ZlIGFjdHVhbGx5IG1hZGUgc29tZSBhbWF6aW5nIGhlYWR3YXku IEJlaW5nIGJsb2NrZWQKb24gbWlub3IgaXNzdWVzIGFuZCBlYXN5IHRvIGNoYW5nZSwgb3J0aG9n b25hbCBpc3N1ZXMgc3VjaCBhcyB2ZW5kb3IKZGVmaW5lZCBwcm9wZXJ0aWVzIChpMmMpIGlzbid0 IGhlbHBmdWwgdG8gYW55b25lLgogCj4gSWYgeW91IG5lZWQgdG8gZm9jdXMgb24gZGV2aWNlIHRy ZWUgZW5hYmxlbWVudCBhbmQgdGhlcmUgYXJlIHVuZGVybHlpbmcKPiBwcm9ibGVtcyBpbiB0aGUg c3Vic3lzdGVtcyB5b3UncmUgbG9va2luZyBhdCBwZXJoYXBzIHlvdSBuZWVkIHRvIHB1c2gKPiBi YWNrIG9uIHdob2V2ZXIncyBhc2tpbmcgeW91IHRvIGRvIHRoZSB3b3JrIGFuZCBzYXkgeW91IG5l ZWQgdGhlIGRvbWFpbgo+IGV4cGVydHMgdG8gcGl0Y2ggaW4gYW5kIGhlbHAgeW91IG91dC4KCklm IG9ubHkgaXQgd2VyZSB0aGF0IGVhc3kuIFdlJ3JlIG5vdCBidXJzdGluZyBhdCB0aGUgc2VlbXMg d2l0aCByZXNvdXJjZXMKaGVyZS4gSSdtIHdvcmtpbmcgaW4gYSB2ZXJ5IGN1c3RvbWVyIGZvY3Vz ZWQgZWNvc3lzdGVtLiBJZiB0aGV5IGRvbid0IApyZXF1ZXN0IGl0LCBvciBmaWxlIGEgYnVnIGFi b3V0IGl0LCB0aGVyZSdzIG5vIHJlc291cmNlIGFsbG9jYXRpb24gdG8gZml4Cml0LiBIb3dldmVy LCB0aGUgZnV0dXJlIGlzIGxvb2tpbmcgdXAgZnJvbSB0aGF0IHBvaW50IG9mIHZpZXcuIFdlJ3Zl IGp1c3QgCnN0YXJ0ZWQgYSBuZXcgcHJvamVjdCwgd2hpY2ggSSdtIGhvcGluZyB3aWxsIGF0dHJh Y3Qgc29tZSBuZXcgcmVzb3VyY2VzLiAKV2F0Y2ggdGhpcyBzcGFjZS4KCj4gPiByZWFsaXR5IEkg YW0gbm8gbW9yZSBvYmxpZ2VkIHRvIGZpeCBkcml2ZXIgYnVncyB0aGFuIHlvdSBhcmUuIEluIGZh Y3QgYXMKPiA+IHRoZSBNYWludGFpbmVyIG9mIHNvbWUgb2YgdGhlc2Ugc3Vic3lzdGVtcywgcGVy aGFwcyB5b3UgY291bGQgZXZlbiBoZWxwIG91dAo+ID4gYSBiaXQ/Cj4gCj4gWW91J3JlIG5vdCB0 ZWxsaW5nIHVzIGFib3V0IHRoZSBwcm9ibGVtcyB5b3Ugc2VlIHNvIGl0J3MgdmVyeSBkaWZmaWN1 bHQKPiBmb3IgYW55b25lIHRvIGhlbHAgeW91Lgo+IAo+IEZvciBleGFtcGxlIHdpdGggdGhpcyBw YXRjaCB0aGUgb25seSBpbmZvcm1hdGlvbiB5b3UndmUgc2VudCBpcyB0aGUKPiBwYXRjaCBhbmQg dGhlIGZhY3QgdGhhdCB5b3UncmUgc2VlaW5nIHRoZSBlcnJvciB5b3UncmUgaWdub3JpbmcgZ29p bmcKPiBvZmYgb24gdGhlIHN5c3RlbSB5b3UncmUgd29ya2luZyB3aXRoICh3aGljaCBJIGhhZCB0 byBhc2sgdG8gZmluZCBvdXQKPiBhYm91dC4uLikuICBZb3UndmUgbm90IHNob3duIHRoZSBlcnJv ciBtZXNzYWdlIG9yIHByb3ZpZGVkIGFueSBvdGhlcgo+IGhpbnQgd2hpY2ggd291bGQgaGVscCBh bnlvbmUgdW5kZXJzdGFuZCB3aHkgdGhlIGVycm9yIG1pZ2h0IGJlIG9jY3VyaW5nCj4gYW5kIHdo YXQgYSBnb29kIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIGlzLiAgT2xhJ3MgZ3Vlc3Mgc2VlbXMg dmVyeQo+IGxpa2VseSBidXQgbm9ib2R5J3MgZ290IGVub3VnaCBpbmZvcm1hdGlvbiB0byBjb25m aXJtIHRoYXQgdW5sZXNzCj4gdGhlcmUncyBiZWVuIHNvbWUgb2ZmLWxpc3QgU1QvTGluYXJvIGNv bW11bmljYXRpb24uCgpJIG9ubHkgd2VudCBvZmYgd2hhdCBJIGtuZXcuIFNvbWUgb2JqZWN0cyAo d2hpY2ggd291bGRuJ3QgaGF2ZQpwcmV2ZW50ZWQgcGxheWluZyBhdWRpbykgd2VyZSBmYWlsaW5n LiBJdCBzZWVtZWQgd3JvbmcgdG8gc2h1dCBkb3duIHRoZQplbnRpcmUgYXVkaW8gc3lzdGVtIGJl Y2F1c2UgZm9yIGluc3RhbmNlLCAnaGVhZHNldCBtdXRlJyBvciB0aGUgJ3ZpYnJhdG9yJwpsaW5r cyB3ZXJlIGJyb2tlbi4gQXMgSSBzYWlkIHRvIHlvdSBiZWZvcmUsIHRpbWUgaXMgYSBiaWcgZmFj dG9yIGFuZCBJCmhhdmUgYSBtYXNzaXZlIFRPRE8gbGlzdC4gRml4aW5nIGF1ZGlvIGxpbmtzIGEp IGlzbid0IG15IHN1YmplY3Qgb2YKZXhwZXJ0aXNlLCBzbyBpdCB3b3VsZCB0YWtlIG1lIG11Y2gg bG9uZ2VyIHRvIGZpeCB0aGFuIHNvbWVvbmUgd2l0aAphIGdvb2Qga25vd2xlZGdlIG9mIHRoZSBz eXN0ZW0gYW5kIGIpIGlzbid0IHJlYWxseSBteSByZXNwb25zaWJpbGl0eS4KSSd2ZSB0ZXN0ZWQg dGhlIERUIHN0dWZmIGFuZCBpdCB3b3JrcyB3ZWxsLiBOb3cgSSBzaG91bGQgbW92ZSBvbnRvCnNv bWV0aGluZyBlbHNlLCBsaWtlIHByb3ZpZGluZyB0aGUgUFJDTVUgd2l0aCBhIElSUSBEb21haW4s IHdoaWNoIGlzCmN1cnJlbnRseSBibG9ja2luZyB0aGUgbWFpbmxpbmluZyBvZiBvdGhlciAoaS5l LiB0aGVybWFsKSBkcml2ZXJzLgoKPiBPYnZpb3VzbHkgd2l0aCB0aGUgc3R1ZmYgdGhhdCdzIGRl dmljZSBzcGVjaWZpYyB5b3UgYWxzbyBoYXZlIHRvIGNvbnRlbmQKPiB3aXRoIHRoZSBmYWN0IHRo YXQgeW91J3JlIHdvcmtpbmcgb24gaGFyZHdhcmUgd2hpY2gganVzdCBpc24ndCBhbGwgdGhhdAo+ IHdpZGVseSBhdmFpbGFibGUgYW5kIHF1aXRlIHBvc3NpYmx5IGhhcyBjbG9zZWQgZGF0YXNoZWV0 cy4KPiAKPiA+IFdlIGFyZSBhbGwgdHJ5aW5nIHRvIGRvIGdvb2QgdGhpbmdzIGhlcmUuIFBsZWFz ZSB0cnkgbm90IHRvIGJlIHRvbyBvdmVyLQo+ID4gY3JpdGljYWwuIFdlIGFsbCBrbm93IE1haW5s aW5pbmcgaXMgYSBnb29kIHRoaW5nLiBQZXJoYXBzIGxlc3MgcGVvcGxlCj4gPiB3b3VsZCBiZSBz byBmcmlnaHRlbmVkIG9mIGl0LCB0aHVzIG1vcmUgcGVvcGxlIHdvdWxkIGRvIGl0IGlmIHRoZSBy ZXZpZXdzCj4gPiB3ZXJlbid0IHN1Y2ggYSBiYWxsLWFjaGUgKCBmb3Igd2FudCBvZiBhIGJldHRl ciBleHByZXNzaW9uIDopICkuCj4gCj4gVGhpcyBpcyBhIHR3byB3YXkgdGhpbmcgLSBvbmUgb2Yg dGhlIHRvb2xzIHRoYXQgbWFpbnRhaW5lcnMgaGF2ZSB0byB0cnkKPiB0byBkcml2ZSB1cCB0aGUg cXVhbGl0eSBvZiB0aGUgY29kZSBpcyB0byBwdXNoIGJhY2sgb24gcG9vciBxdWFsaXR5Cj4gc3Vi bWlzc2lvbnMgYW5kIGRldm90ZSBsZXNzIGJhbmR3aXRoIHRvIHNvdXJjZXMgb2YgdGhvc2Ugc3Vi bWlzc2lvbnMuCj4gCj4gSXQgaXMgdHJ1ZSB0aGF0IHRoZXJlJ3MgYSBidW5jaCBvZiBwZW9wbGUg d2hvIHNlZW0gdG8gdmlldyByZXZpZXcgYXMKPiBiZWluZyBqdXN0IGFuIGFubm95aW5nIG9ic3Rh Y2xlIHRvIGJlIGRlYWx0IHdpdGggd2l0aCB0aGUgbWluaW11bQo+IHBvc3NpYmxlIGVmZm9ydCBi dXQgaW4gcHJhY3RpY2UgYWxsIHRoYXQgZG9lcyBpcyBtYWtlIHRoaW5ncyBtb3JlCj4gcGFpbmZ1 bCBmb3IgZXZlcnlvbmUsIHRoZXkgZG8gdGVuZCB0byBiZSBtb3JlIG5vdGljYWJsZSBiZWNhdXNl Cj4gImFwcGxpZWQsIHRoYW5rcyIgZG9lc24ndCBtYWtlIGZvciBhIGJpZyB0aHJlYWQuCgpXZWxs IEkga25vdyBteSBzdWJtaXNzaW9ucyBhcmUgbm90IGFsd2F5cyAxMDAlIHBlcmZlY3QsIGJ1dCBJ IGhvcGUgCnlvdSdyZSBub3QgaW1wbHlpbmcgdGhhdCB0aGV5J3JlIHBvb3IgcXVhbGl0eS4gV3Jp dGluZyBjb2RlIGFuZCBmaXhpbmcKdGhpbmdzIHlvdSB2aWV3IGFzIGJ1Z3MgaW4gY29kZSB5b3Ug aGF2ZSBubyBwcmlvciBrbm93bGVkZ2Ugb2YgaXNuJ3QgdGhlIAplYXNpZXN0IHRhc2sgaW4gdGhl IHdvcmxkLiBBbGwgSSBjYW4gZG8gaXMgYXR0ZW1wdCB0byBmaXggdGhlIGlzc3VlcyB0aGF0Ckkg c2VlLCB3aGljaCBnZXQgdGhpbmdzIG9mZiB0aGUgZ3JvdW5kIG9yIG1ha2UgZHJpdmVycyB3b3Jr IGFnYWluIGFuZApzdWJtaXQgdGhlIGNoYW5nZXMuIElmIHRoZXkncmUgd3JvbmcgdGhleSdyZSB3 cm9uZywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhpcwpzaG91bGQgYmUgdmlld2VkIGFzIHBvb3IgcXVh bGl0eSBjb2RlIQoKSSBkaWRuJ3Qgc2F5IHJldmlld3MgaW4gZ2VuZXJhbC4gSSBwZXJzb25hbGx5 IHRoaW5rIHRoYXQgcmV2aWV3cyBhcmUgYQp2ZXJ5IGhhbmR5IHdheSBvZiBlbnN1cmluZyBjb2Rl IGlzIGFzIHRoZSBjb3JyZWN0IGxldmVsIGZvciBlbnRyeSBpbnRvCk1haW5saW5lLiBJdCdzIGFs c28gdml0YWwgZm9yIHRoZSBsZWFybmluZyBwcm9jZXNzLCBhbmQgaXMgd2hlcmUgbW9zdApvZiBt eSBrbm93bGVkZ2UgaGFzIGJlZW4gZ2FpbmVkLiBJdCdzIHRoZSB0eXBlIG9mIHJldmlldyB3aGlj aCBkZWZpbmVzCnRoZSBleHBlcmllbmNlLiBTb21lIE1haW50YWluZXJzIHNheSB0aGluZ3MgbGlr ZSwgIlRoYXQncyB3cm9uZy4gVGhpcwppcyB3cm9uZy4gV2h5IGFyZSB5b3UgZG9pbmcgdGhpcz8i IGV0YyB3aXRob3V0IGV4cGxhaW5pbmcgd2hhdCB0aGUKaXNzdWVzIGFyZS4gVGhhdCdzIG5vdCBh IGdvb2QgcmV2aWV3LCBhbmQgd2lsbCBwdXQgcGVvcGxlIG9mZiB0cnlpbmcKYWdhaW4uIEVxdWFs bHkgYmVpbmcgdG9vIG92ZXJ6ZWFsb3VzIGFuZCBuaXQtcGlja3kgYWJvdXQgc3R1ZmYgdGhhdCBh KQpyZWFsbHkgZG9lc24ndCBtYXR0ZXIgb3IgYikgY2FuIGJlIGNoYW5nZWQgcmVhbGx5IGVhc2ls eSBfaWZfIGluIHRoZQpyYXJlIGNhc2UgdGhlcmUncyBhbiBpc3N1ZS4gSSd2ZSBhbHNvIHN1Ym1p dHRlZCB0byBzb21lIE1haW50YWluZXJzCndobyBhcmUgYSBwbGVhc3VyZSB0byB3b3JrIHdpdGgu IFRoZXkgZXhwbGFpbiB3aGF0J3Mgd3JvbmcgYW5kIHdoeQphbmQgZW5jb3VyYWdlIHJlc3VibWlz c2lvbi4gSSBrbm93IE1haW50YWluZXJzIGFyZW4ndCBzY2hvb2wgdGVhY2hlcnMsCm9yIGxpZmUg Y29hY2hlcywgYnV0IHRoZXkgc2hvdWxkIGJlIGVuY291cmFnaW5nIG1vcmUgcGVvcGxlIHRvIHNo YXJlCnRoZWlyIGdvb2QgKCBhZnRlciBzb21lIGZpeHVwIDspICkgY29kZSBhbmQgbm90IHBsYXlp bmcgdGhlIHJvbGUgb2YgCmFuIGluY3JlZGlibHkgaGFyZCB0byBwbGVhc2UgYm9zcywgb3IgaW1w ZW5ldHJhYmxlIGJyaWNrIHdhbGwuCgpMZXQncyBqdXN0IGRyb3AgdGhpcyBub3csIG9yIHdlJ2xs IGJlIGdvaW5nIHJvdW5kIGFuZCByb3VuZCBmb3JldmVyLgpJIG5lZWQgdG8gbW92ZSBvbiB0byB0 aGlzIFBSQ01VIHN0dWZmLCBhcyBpdCdzIGJsb2NraW5nIGRyaXZlcgpzdWJtaXNzaW9uLiBJZiB5 b3UgY2FuIGxlbmQgYSBoYW5kIHdpdGggdGhlIGF1ZGlvY2xrIHN0dWJzIHRoYXQgd291bGQKYmUg Z3JhbmQuIElmIG5vdCwgbWUgbWlnaHQganVzdCBoYXZlIHRvIHdhaXQgZm9yIE9sYSB0byBjb21l IGJhY2sgZnJvbQpoaXMgd2VsbCBlYXJuZWQgdmFjYXRpb24uCgotLSAKTGVlIEpvbmVzCkxpbmFy byBTVC1Fcmljc3NvbiBMYW5kaW5nIFRlYW0gTGVhZApMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJj ZSBzb2Z0d2FyZSBmb3IgQVJNIFNvQ3MKRm9sbG93IExpbmFybzogRmFjZWJvb2sgfCBUd2l0dGVy IHwgQmxvZwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpB bHNhLWRldmVsIG1haWxpbmcgbGlzdApBbHNhLWRldmVsQGFsc2EtcHJvamVjdC5vcmcKaHR0cDov L21haWxtYW4uYWxzYS1wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fsc2EtZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: lee.jones@linaro.org (Lee Jones) Date: Fri, 3 Aug 2012 09:30:10 +0100 Subject: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too In-Reply-To: <20120802175604.GF4537@opensource.wolfsonmicro.com> References: <20120731145443.GY4468@opensource.wolfsonmicro.com> <5017F68B.3060400@linaro.org> <20120731151819.GC4468@opensource.wolfsonmicro.com> <5018D880.5090306@linaro.org> <20120801132022.GS11892@opensource.wolfsonmicro.com> <50193428.5000708@linaro.org> <20120801160824.GB11892@opensource.wolfsonmicro.com> <20120801194134.GA4103@sirena.org.uk> <20120802074517.GA19231@gmail.com> <20120802175604.GF4537@opensource.wolfsonmicro.com> Message-ID: <20120803083009.GC7416@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Aug 02, 2012 at 06:56:04PM +0100, Mark Brown wrote: > On Thu, Aug 02, 2012 at 08:45:18AM +0100, Lee Jones wrote: > > > Over time, the requests for Maintainers have Snowballed (pun intended). My > > task now seems to be enabling drivers for Device Tree _and_ fix all > > associated driver bugs, including any requested restructuring and API > > One thing to bear in mind with device tree is that it's all about > defining an ABI - it's supposed to be stable and OS agnostic so it puts > a lot of pressure on to really address quality problems that become > visible in the bindings. This stuff is much less critical with platform > data, it's relatively easy to change. > > > adoption. What you fail to notice is that I am only one person, and hopping > > all over the code-base trying to do everyone's bidding is no mean feat. In > > It's fairly obvious that it's only you, or at least only you posting > stuff (I know sometimes there are bigger teams behind people) - the > pressure you're under to get something in is very clear. A big part of > what I'm saying here is that it would be really helpful if could you > slow down a bit, discuss problems more and avoid cutting corners so > much. This is likely to save you time overall, you'll have a much > higher success rate and you'll get much better feedback if it's clear > what's going on and that there's an interest in understanding the > issues. I do agree that it should be correct, but the difference between getting it 90% correct and absolutely perfect increases the effort at least x2. With so much left to do, I think it would be better to get everything in and functioning, then fix the minor issues as we come across them later. This is what I've been doing from the start and it's actually looking pretty good. I also agree that DT should be OS agnostic, but breaking up MFDs into their functions shouldn't be an issue for other OSes. Either they can choose to break them up and use the individual child compatible strings, or only use the parent node. My personal opinion is if we'd sat around discussing how it should look prior to doing any work a) the project probably wouldn't have even got off the ground yet and b) we would have most likely got it all wrong, as most of our learning and knowledge has been done/gained by actually doing the work. Instead I've been using the JFDI (Just Frickin' Do It) philosophy, and we've actually made some amazing headway. Being blocked on minor issues and easy to change, orthogonal issues such as vendor defined properties (i2c) isn't helpful to anyone. > If you need to focus on device tree enablement and there are underlying > problems in the subsystems you're looking at perhaps you need to push > back on whoever's asking you to do the work and say you need the domain > experts to pitch in and help you out. If only it were that easy. We're not bursting at the seems with resources here. I'm working in a very customer focused ecosystem. If they don't request it, or file a bug about it, there's no resource allocation to fix it. However, the future is looking up from that point of view. We've just started a new project, which I'm hoping will attract some new resources. Watch this space. > > reality I am no more obliged to fix driver bugs than you are. In fact as > > the Maintainer of some of these subsystems, perhaps you could even help out > > a bit? > > You're not telling us about the problems you see so it's very difficult > for anyone to help you. > > For example with this patch the only information you've sent is the > patch and the fact that you're seeing the error you're ignoring going > off on the system you're working with (which I had to ask to find out > about...). You've not shown the error message or provided any other > hint which would help anyone understand why the error might be occuring > and what a good solution to the problem is. Ola's guess seems very > likely but nobody's got enough information to confirm that unless > there's been some off-list ST/Linaro communication. I only went off what I knew. Some objects (which wouldn't have prevented playing audio) were failing. It seemed wrong to shut down the entire audio system because for instance, 'headset mute' or the 'vibrator' links were broken. As I said to you before, time is a big factor and I have a massive TODO list. Fixing audio links a) isn't my subject of expertise, so it would take me much longer to fix than someone with a good knowledge of the system and b) isn't really my responsibility. I've tested the DT stuff and it works well. Now I should move onto something else, like providing the PRCMU with a IRQ Domain, which is currently blocking the mainlining of other (i.e. thermal) drivers. > Obviously with the stuff that's device specific you also have to contend > with the fact that you're working on hardware which just isn't all that > widely available and quite possibly has closed datasheets. > > > We are all trying to do good things here. Please try not to be too over- > > critical. We all know Mainlining is a good thing. Perhaps less people > > would be so frightened of it, thus more people would do it if the reviews > > weren't such a ball-ache ( for want of a better expression :) ). > > This is a two way thing - one of the tools that maintainers have to try > to drive up the quality of the code is to push back on poor quality > submissions and devote less bandwith to sources of those submissions. > > It is true that there's a bunch of people who seem to view review as > being just an annoying obstacle to be dealt with with the minimum > possible effort but in practice all that does is make things more > painful for everyone, they do tend to be more noticable because > "applied, thanks" doesn't make for a big thread. Well I know my submissions are not always 100% perfect, but I hope you're not implying that they're poor quality. Writing code and fixing things you view as bugs in code you have no prior knowledge of isn't the easiest task in the world. All I can do is attempt to fix the issues that I see, which get things off the ground or make drivers work again and submit the changes. If they're wrong they're wrong, but I don't think this should be viewed as poor quality code! I didn't say reviews in general. I personally think that reviews are a very handy way of ensuring code is as the correct level for entry into Mainline. It's also vital for the learning process, and is where most of my knowledge has been gained. It's the type of review which defines the experience. Some Maintainers say things like, "That's wrong. This is wrong. Why are you doing this?" etc without explaining what the issues are. That's not a good review, and will put people off trying again. Equally being too overzealous and nit-picky about stuff that a) really doesn't matter or b) can be changed really easily _if_ in the rare case there's an issue. I've also submitted to some Maintainers who are a pleasure to work with. They explain what's wrong and why and encourage resubmission. I know Maintainers aren't school teachers, or life coaches, but they should be encouraging more people to share their good ( after some fixup ;) ) code and not playing the role of an incredibly hard to please boss, or impenetrable brick wall. Let's just drop this now, or we'll be going round and round forever. I need to move on to this PRCMU stuff, as it's blocking driver submission. If you can lend a hand with the audioclk stubs that would be grand. If not, me might just have to wait for Ola to come back from his well earned vacation. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753039Ab2HCIaV (ORCPT ); Fri, 3 Aug 2012 04:30:21 -0400 Received: from mail-ee0-f46.google.com ([74.125.83.46]:62186 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664Ab2HCIaQ (ORCPT ); Fri, 3 Aug 2012 04:30:16 -0400 Date: Fri, 3 Aug 2012 09:30:10 +0100 From: Lee Jones To: Mark Brown Cc: ola.o.lilja@stericsson.com, alsa-devel@alsa-project.org, linus.walleij@stericsson.com, arnd@arndb.de, olalilja@yahoo.se, linux-kernel@vger.kernel.org, STEricsson_nomadik_linux@list.st.com, lrg@ti.com, linux-arm-kernel@lists.infradead.org Subject: Re: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too Message-ID: <20120803083009.GC7416@gmail.com> References: <20120731145443.GY4468@opensource.wolfsonmicro.com> <5017F68B.3060400@linaro.org> <20120731151819.GC4468@opensource.wolfsonmicro.com> <5018D880.5090306@linaro.org> <20120801132022.GS11892@opensource.wolfsonmicro.com> <50193428.5000708@linaro.org> <20120801160824.GB11892@opensource.wolfsonmicro.com> <20120801194134.GA4103@sirena.org.uk> <20120802074517.GA19231@gmail.com> <20120802175604.GF4537@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120802175604.GF4537@opensource.wolfsonmicro.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 02, 2012 at 06:56:04PM +0100, Mark Brown wrote: > On Thu, Aug 02, 2012 at 08:45:18AM +0100, Lee Jones wrote: > > > Over time, the requests for Maintainers have Snowballed (pun intended). My > > task now seems to be enabling drivers for Device Tree _and_ fix all > > associated driver bugs, including any requested restructuring and API > > One thing to bear in mind with device tree is that it's all about > defining an ABI - it's supposed to be stable and OS agnostic so it puts > a lot of pressure on to really address quality problems that become > visible in the bindings. This stuff is much less critical with platform > data, it's relatively easy to change. > > > adoption. What you fail to notice is that I am only one person, and hopping > > all over the code-base trying to do everyone's bidding is no mean feat. In > > It's fairly obvious that it's only you, or at least only you posting > stuff (I know sometimes there are bigger teams behind people) - the > pressure you're under to get something in is very clear. A big part of > what I'm saying here is that it would be really helpful if could you > slow down a bit, discuss problems more and avoid cutting corners so > much. This is likely to save you time overall, you'll have a much > higher success rate and you'll get much better feedback if it's clear > what's going on and that there's an interest in understanding the > issues. I do agree that it should be correct, but the difference between getting it 90% correct and absolutely perfect increases the effort at least x2. With so much left to do, I think it would be better to get everything in and functioning, then fix the minor issues as we come across them later. This is what I've been doing from the start and it's actually looking pretty good. I also agree that DT should be OS agnostic, but breaking up MFDs into their functions shouldn't be an issue for other OSes. Either they can choose to break them up and use the individual child compatible strings, or only use the parent node. My personal opinion is if we'd sat around discussing how it should look prior to doing any work a) the project probably wouldn't have even got off the ground yet and b) we would have most likely got it all wrong, as most of our learning and knowledge has been done/gained by actually doing the work. Instead I've been using the JFDI (Just Frickin' Do It) philosophy, and we've actually made some amazing headway. Being blocked on minor issues and easy to change, orthogonal issues such as vendor defined properties (i2c) isn't helpful to anyone. > If you need to focus on device tree enablement and there are underlying > problems in the subsystems you're looking at perhaps you need to push > back on whoever's asking you to do the work and say you need the domain > experts to pitch in and help you out. If only it were that easy. We're not bursting at the seems with resources here. I'm working in a very customer focused ecosystem. If they don't request it, or file a bug about it, there's no resource allocation to fix it. However, the future is looking up from that point of view. We've just started a new project, which I'm hoping will attract some new resources. Watch this space. > > reality I am no more obliged to fix driver bugs than you are. In fact as > > the Maintainer of some of these subsystems, perhaps you could even help out > > a bit? > > You're not telling us about the problems you see so it's very difficult > for anyone to help you. > > For example with this patch the only information you've sent is the > patch and the fact that you're seeing the error you're ignoring going > off on the system you're working with (which I had to ask to find out > about...). You've not shown the error message or provided any other > hint which would help anyone understand why the error might be occuring > and what a good solution to the problem is. Ola's guess seems very > likely but nobody's got enough information to confirm that unless > there's been some off-list ST/Linaro communication. I only went off what I knew. Some objects (which wouldn't have prevented playing audio) were failing. It seemed wrong to shut down the entire audio system because for instance, 'headset mute' or the 'vibrator' links were broken. As I said to you before, time is a big factor and I have a massive TODO list. Fixing audio links a) isn't my subject of expertise, so it would take me much longer to fix than someone with a good knowledge of the system and b) isn't really my responsibility. I've tested the DT stuff and it works well. Now I should move onto something else, like providing the PRCMU with a IRQ Domain, which is currently blocking the mainlining of other (i.e. thermal) drivers. > Obviously with the stuff that's device specific you also have to contend > with the fact that you're working on hardware which just isn't all that > widely available and quite possibly has closed datasheets. > > > We are all trying to do good things here. Please try not to be too over- > > critical. We all know Mainlining is a good thing. Perhaps less people > > would be so frightened of it, thus more people would do it if the reviews > > weren't such a ball-ache ( for want of a better expression :) ). > > This is a two way thing - one of the tools that maintainers have to try > to drive up the quality of the code is to push back on poor quality > submissions and devote less bandwith to sources of those submissions. > > It is true that there's a bunch of people who seem to view review as > being just an annoying obstacle to be dealt with with the minimum > possible effort but in practice all that does is make things more > painful for everyone, they do tend to be more noticable because > "applied, thanks" doesn't make for a big thread. Well I know my submissions are not always 100% perfect, but I hope you're not implying that they're poor quality. Writing code and fixing things you view as bugs in code you have no prior knowledge of isn't the easiest task in the world. All I can do is attempt to fix the issues that I see, which get things off the ground or make drivers work again and submit the changes. If they're wrong they're wrong, but I don't think this should be viewed as poor quality code! I didn't say reviews in general. I personally think that reviews are a very handy way of ensuring code is as the correct level for entry into Mainline. It's also vital for the learning process, and is where most of my knowledge has been gained. It's the type of review which defines the experience. Some Maintainers say things like, "That's wrong. This is wrong. Why are you doing this?" etc without explaining what the issues are. That's not a good review, and will put people off trying again. Equally being too overzealous and nit-picky about stuff that a) really doesn't matter or b) can be changed really easily _if_ in the rare case there's an issue. I've also submitted to some Maintainers who are a pleasure to work with. They explain what's wrong and why and encourage resubmission. I know Maintainers aren't school teachers, or life coaches, but they should be encouraging more people to share their good ( after some fixup ;) ) code and not playing the role of an incredibly hard to please boss, or impenetrable brick wall. Let's just drop this now, or we'll be going round and round forever. I need to move on to this PRCMU stuff, as it's blocking driver submission. If you can lend a hand with the audioclk stubs that would be grand. If not, me might just have to wait for Ola to come back from his well earned vacation. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog