From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?VGVyamUgQmVyZ3N0csO2bQ==?= Subject: Re: [RFC v2 1/8] video: tegra: Add nvhost driver Date: Fri, 30 Nov 2012 10:56:39 +0200 Message-ID: <50B874C7.5030208@nvidia.com> References: <1353935954-13763-1-git-send-email-tbergstrom@nvidia.com> <1353935954-13763-2-git-send-email-tbergstrom@nvidia.com> <20121128212301.GA25531@avionic-0098.adnet.avionic-design.de> <50B73710.2040102@nvidia.com> <20121129114704.GB6150@avionic-0098.adnet.avionic-design.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20121129114704.GB6150@avionic-0098.adnet.avionic-design.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Thierry Reding Cc: "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" List-Id: linux-tegra@vger.kernel.org T24gMjkuMTEuMjAxMiAxMzo0NywgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4gT24gVGh1LCBOb3Yg MjksIDIwMTIgYXQgMTI6MjE6MDRQTSArMDIwMCwgVGVyamUgQmVyZ3N0csO2bSB3cm90ZToKPj4g VGVncmEyMCBhbmQgVGVncmEzMCBhcmUgY29tcGF0aWJsZSwgYnV0IGZ1dHVyZSBjaGlwcyBhcmUg bm90LiBJIHdhcwo+PiBob3Bpbmcgd2Ugd291bGQgYmUgcmVhZHkgaW4gdXBzdHJlYW0ga2VybmVs IGZvciBmdXR1cmUgY2hpcHMuCj4gCj4gSSB0aGluayB3ZSBzaG91bGQgaWdub3JlIHRoYXQgcHJv YmxlbSBmb3Igbm93LiBHZW5lcmFsbHkgcGxhbm5pbmcgZm9yCj4gYW55IHBvc3NpYmxlIGNvbWJp bmF0aW9uIG9mIGluY29tcGF0aWJpbGl0aWVzIGxlYWRzIHRvIG92ZXJnZW5lcmFsaXplZAo+IGRl c2lnbnMgdGhhdCByZXF1aXJlIHByZWNpc2VseSB0aGVzZSBraW5kcyBvZiBpbmRpcmVjdGlvbnMu Cj4gCj4gT25jZSBzb21lIGRvY3VtZW50YXRpb24gZm9yIFRlZ3JhIDQwIG1hdGVyaWFsaXplcyB3 ZSBjYW4gc3RhcnQgdGhpbmtpbmcKPiBhYm91dCBob3cgdG8gZW5jYXBzdWxhdGUgdGhlIGluY29t cGF0aWJsZSBjb2RlLgoKSSB0aGluayBoZXJlIG91ciBwZXJzcGVjdGl2ZXMgZGlmZmVyIGEgbG90 LiBUaGF0IGlzIG5hdHVyYWwgY29uc2lkZXJpbmcKdGhlIGNvbXBhbnkgSSB3b3JrIGZvciBhbmQg Y29tcGFueSB5b3Ugd29yayBmb3IsIHNvIGxldCdzIHRyeSB0byBzeW5jCnRoZSBwZXJzcGVjdGl2 ZS4KCkluIG15IHJlYWxpdHksIHdoYXRldmVyIGlzIGluIG1hcmtldCBpcyBvbGQgbmV3cyBhbmQg SSBiYXJlbHkgd29yayBvbgp0aGVtIGFueW1vcmUuIFVwc3RyZWFtaW5nIGFjdGl2aXR5IGlzIHRo ZSBleGNlcHRpb24uIDkwJSBvZiBteSB0aW1lIGlzCnNwZW50IGRlYWxpbmcgd2l0aCBmdXR1cmUg Y2hpcHMgd2hpY2ggSSBrbm93IGNhbm5vdCBiZSBoYW5kbGVkIHdpdGhvdXQKdGhpcyBzcGxpdCB0 byBsb2dpY2FsIGFuZCBwaHlzaWNhbCBkcml2ZXIgcGFydHMuCgpGb3IgeW91LCBUZWdyYTIgYW5k IFRlZ3JhMyBhcmUgdGhlIHJlYWxpdHkuCgpJZiB3ZSBtb3ZlIG52aG9zdCBpbiB1cHN0cmVhbSBh IGJpdCBpbmNvbXBhdGlibGUsIHRoYXQncyBmaW5lLCBsaWtlCnJpcHBpbmcgb3V0IGZlYXR1cmVz IG9yIGFkZGluZyBuZXcgbmV3IHN0dWZmLCBsaWtlIGEgbmV3IG1lbW9yeSB0eXBlLgpBbGwgb2Yg dGhpcyBJIGNhbiBzdXBwb3J0IHdpdGggYSBnb29kIGRpZmYgdG9vbCB0byBnZXQgYWxsIHRoZSBw YXRjaGVzCmZsb3dpbmcgYmV0d2VlbiB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbS4KCklmIHdlIGRv IGZ1bmRhbWVudGFsIGNoYW5nZXMgdGhhdCBwcmV2ZW50IGJyaW5naW5nIHRoZSBjb2RlIGJhY2sg dG8KZG93bnN0cmVhbSwgbGlrZSByZW1vdmluZyB0aGlzIGFic3RyYWN0aW9uLCB0aGUgd2hvbGUg cHJvY2VzcyBvZgp1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBjb252ZXJnaW5nIGhpdHMgYSBicmlj ayB3YWxsLiBXZSB3b3VsZG4ndCBoYXZlCnByb3BlciBjb250aW51aW5nIGNvLW9wZXJhdGlvbiwg YnV0IGp1c3QgcHVzaGluZyBjb2RlIG91dCBhbmQgYmVpbmcgZG9uZQp3aXRoIGl0LgoKPiBJIG5v dGljZWQgdGhhdCBpdCB3YXMgZmlsbGVkIHdpdGggY29udGVudCBpbiBvbmUgb2YgdGhlIHN1YnNl cXVlbnQKPiBwYXRjaGVzLiBEZXBlbmRpbmcgb24gaG93IHRoaXMgZ2V0cyBtZXJnZWQgZXZlbnR1 YWxseSB5b3UgY291bGQgcG9zdHBvbmUKPiBhZGRpbmcgdGhlIGZ1bmN0aW9uIHVudGlsIHRoZSBs YXRlciBwYXRjaC4gQnV0IHBlcmhhcHMgb25jZSB0aGUgY29kZSBoYXMKPiBiZWVuIHByb3Blcmx5 IHJldmlld2VkIHdlIGNhbiBqdXN0IHNxdWFzaCB0aGUgcGF0Y2hlcyBhZ2Fpbi4gV2UnbGwgc2Vl LgoKT2ssIHRoYW5rcy4KCj4+IFRydWUuIEkgbWlnaHQgYWxzbyBhcyB3ZWxsIGRlbGV0ZSB0aGUg Z2VuZXJhbCBpbnRlcnJ1cHQgYWx0b2dldGhlciwgYXMKPj4gd2UgZG9uJ3QgdXNlIGl0IGZvciBh bnkgcmVhbCBwdXJwb3NlLgo+IAo+IEkgdGhpbmsgaXQgbWlnaHQgc3RpbGwgYmUgdXNlZnVsIGZv ciBkaWFnbm9zdGljcy4gSXQgc2VlbXMgdG8gYmUgdXNlZAo+IHdoZW4gd3JpdGVzIHRpbWUgb3V0 LiBUaGF0IGNvdWxkIHN0aWxsIGJlIGhlbHBmdWwgaW5mb3JtYXRpb24gd2hlbgo+IGRlYnVnZ2lu ZyBwcm9ibGVtcy4KCkl0J3MgYWN0dWFsbHkgYSBzdGFsZSBjb21tZW50LiBUaGUgY2xpZW50IHVu aXRzIGFyZSBub3Qgc2lnbmFsaW5nCmFueXRoaW5nIHVzZWZ1bCB3aXRoIHRoZSBpbnRlcnJ1cHQu IFRoZXJlJ3MgdXNlIGZvciBpdCBpbiBkb3duc3RyZWFtLApidXQgdGhhdCdzIGlycmVsZXZhbnQg aGVyZS4KCj4gTWFraW5nIHRoaXMgZ2VuZXJpYyBmb3IgYWxsIG1vZHVsZXMgbWF5IG5vdCBiZSB3 aGF0IHdlIHdhbnQgYXMgaXQKPiBkb2Vzbid0IGFsbG93IGRldmljZXMgdG8gaGFuZGxlIHRoaW5n cyB0aGVtc2VsdmVzIGlmIG5lY2Vzc2FyeS4gQ2xvY2sKPiBtYW5hZ2VtZW50IGlzIGp1c3QgcGFy dCBvZiB0aGUgYm9pbGVyIHBsYXRlIHRoYXQgZXZlcnkgZHJpdmVyIGlzCj4gc3VwcG9zZWQgdG8g Y29wZSB3aXRoLiBBbHNvIHRoZSBudW1iZXIgb2YgY2xvY2tzIGlzIHVzdWFsbHkgbm90IGhpZ2hl cgo+IHRoYW4gMiBvciAzLCBzbyB0aGUgcGFpbiBpcyBtYW5hZ2VhYmxlLiA9KQo+IAo+IEZ1cnRo ZXJtb3JlIGRvaW5nIHRoaXMgaW4gbG9vcHMgbWF5IG5vdCB3b3JrIGZvciBhbGwgbW9kdWxlcy4g U29tZSBtYXkKPiByZXF1aXJlIGFkZGl0aW9uYWwgZGVsYXlzIGJldHdlZW4gZW5hYmxpbmcgdGhl IGNsb2Nrcywgb3RoZXJzIG1heSBiZQo+IGFibGUgdG8gc2VsZWN0aXZlbHkgZGlzYWJsZSBvbmUg Y2xvY2sgYnV0IG5vdCB0aGUgb3RoZXIocykuCgpZZXMsIGJ1dCBJJ2xsIGp1c3QgcmlwIHRoZSBw b3dlciBtYW5hZ2VtZW50IGNvZGUgb3V0LCBzbyB3ZSBjYW4gcG9zdHBvbmUKdGhpcyB1bnRpbCB3 ZSBoYXZlIHZhbGlkYXRlZCBhbmQgdmVyaWZpZWQgdGhlIHJ1bnRpbWUgUE0gbWVjaGFuaXNtCmRv d25zdHJlYW0uCgo+PiBJIGNvdWxkIG1vdmUgdGhpcyB0byBkZWJ1Zy5jLCBidXQgaXQncyBkZWJ1 Z2dpbmcgYWlkIHdoZW4gYSBjb21tYW5kCj4+IHN0cmVhbSBpcyBtaXNiZWhhdmluZyBhbmQgaXQg c3Bld3MgdGhpcyB0byBVQVJUIHdoZW4gc3luYyBwb2ludCB3YWl0IGlzCj4+IHRpbWluZyBvdXQu IFNvIG5vdCBkZWJ1Z2ZzIHN0dWZmLgo+IAo+IE9rYXksIGluIHRoYXQgY2FzZSBpdCBzaG91bGQg c3RheSBpbi4gUGVyaGFwcyBjb252ZXJ0IGRldl9pbmZvKCkgdG8KPiBkZXZfZGJnKCkuIFBlcmhh cHMgd3JhcHBpbmcgaXQgaW4gc29tZSAjaWZkZWYgQ09ORklHX1RFR1JBX0hPU1QxWF9ERUJVRwo+ IGd1YXJkcyB3b3VsZCBhbHNvIGJlIHVzZWZ1bC4gTWF5YmUgbm90LgoKSSBjb3VsZCBkbyB0aGF0 IGZvciB1cHN0cmVhbS4gSW4gZG93bnN0cmVhbSBpdCBjYW5ub3QgZGVwZW5kIG9uIERFQlVHCmZs YWcsIGFzIHRoZXNlIHNwZXdzIGFyZSBhbiBpbXBvcnRhbnQgcGFydCBvZiBob3cgd2UgZGVidWcg cHJvYmxlbXMgd2l0aApjdXN0b21lciBkZXZpY2VzIGFuZCB0aGUgREVCVUcgZmxhZyBpcyBuZXZl ciBvbiBpbiBjdXN0b21lciBidWlsZHMuCgo+IFRoZSBwcm9ibGVtIGlzIG5vdCB3aXRoIGF1dG9n ZW5lcmF0ZWQgZmlsZXMgaW4gZ2VuZXJhbC4gVGhlIG1lYW5zIGJ5Cj4gd2hpY2ggdGhleSBhcmUg Z2VuZXJhdGVkIGFyZSBsZXNzIGltcG9ydGFudC4gSG93ZXZlciwgYXV0b2dlbmVyYXRlZAo+IGZp bGVzIG9mdGVuIGNvbnRhaW4gYSBsb3Qgb2YgdW5uZWVkZWQgZGVmaW5pdGlvbnMgYW5kIGNvbnRh aW4gdGhpbmdzCj4gc3VjaCBhcyAiYXV0b2dlbmVyYXRlZCAtIGRvIG5vdCBlZGl0IiBsaW5lcy4K PiAKPiBTbyBnZW5lcmFsbHkgaWYgeW91IGdlbmVyYXRlIHRoZSBjb250ZW50IHVzaW5nIHNvbWUg c2NyaXB0cyB0byBtYWtlIHN1cmUKPiBpdCBjb3JyZXNwb25kcyB0byB3aGF0IGVuZ2luZWVyaW5n IGdhdmUgeW91LCB0aGF0J3Mgb2theSBhcyBsb25nIGFzIHlvdQo+IG1ha2Ugc3VyZSBpdCBoYXMg dGhlIGNvcnJlY3QgZm9ybSBhbmQgZG9lc24ndCBjb250YWluIGFueSBjcnVmdC4KCkkgY2FuIHJl bW92ZSB0aGUgYm9pbGVycGxhdGUsIHRoYXQncyBub3QgYSBwcm9ibGVtLiBJbiBnZW5lcmFsLCB3 ZSBoYXZlCnRyaWVkIHRvIGJlIHZlcnkgc2VsZWN0aXZlIGFib3V0IHdoYXQgd2UgZ2VuZXJhdGUs IHNvIHRoYXQgaXQgbWF0Y2hlcwp3aGF0IHdlJ3JlIHVzaW5nLgoKPj4gSSBsaWtlIHN0YXRpYyBp bmxpbmUgYmVjYXVzZSBJIGdldCB0aGUgYmVuZWZpdCBvZiBjb21waWxlciB0eXBlCj4+IGNoZWNr aW5nLCBhbmQgZ2NvdiBzaG93cyBtZSB3aGljaCByZWdpc3RlciBkZWZpbml0aW9ucyBoYXZlIGJl ZW4gdXNlZCBpbgo+PiBkaWZmZXJlbnQgdGVzdHMuCj4gCj4gVHlwZSBjaGVja2luZyBzaG91bGRu J3QgYmUgbmVjZXNzYXJ5IGZvciBzaW1wbGUgZGVmaW5lcy4gQW5kIEkgd2Fzbid0Cj4gYXdhcmUg dGhhdCB5b3UgY291bGQgZ2V0IHRoZSBMaW51eCBrZXJuZWwgdG8gd3JpdGUgb3V0IGRhdGEgdG8g YmUgZmVkIHRvCj4gZ2Nvdi4KPiAKPj4gI2RlZmluZXMgYXJlIGFsd2F5cyBtZXNzeSBhbmQgSSBw cmV0dHkgbXVjaCBoYXRlIHRoZW0uIEJ1dCBpZiB0aGUKPj4gZ2VuZXJhbCByZXF1ZXN0IGlzIHRv IHVzZSAjZGVmaW5lJ3MsIGV2ZW4gdGhvdWdoIEkgZG9uJ3QgYWdyZWUsIEkgY2FuCj4+IGFjY29t bW9kYXRlLiBJdCdzIHNpbXBsZSB0byB3cml0ZSBhIHNlZCBzY3JpcHQgdG8gZG8gdGhlIGNvbnZl cnNpb24uCj4gCj4gVGhlcmUgYXJlIGEgbG90IG9mIG9wcG9ydHVuaXRpZXMgdG8gYWJ1c2UgI2Rl ZmluZXMgYnV0IHRoZXkgYXJlIGhhcm1sZXNzCj4gZm9yIHJlZ2lzdGVyIGRlZmluaXRpb25zLiBU aGUgTGludXgga2VybmVsIGlzIGZ1bGwgb2YgdGhlbSBhbmQgSSBoYXZlbid0Cj4geWV0IHNlZW4g YW55IGNvZGUgdGhhdCB1c2VzIHN0YXRpYyBpbmxpbmUgZnVuY3Rpb25zIGZvciB0aGlzIHB1cnBv c2UuCgpNeSBwcm9ibGVtIGlzIGp1c3QgdGhhdCBJIGtub3cgdGhhdCB0aGUgY29kZSBnZW5lcmF0 ZWQgaXMgdGhlIHNhbWUuIFdoYXQKd2UncmUgdGFsa2luZyBhYm91dCBpcyB0aGF0IHNob3VsZCB3 ZSBsZXQgdGhlIHByZXByb2Nlc3NvciBvciBjb21waWxlcgp0YWtlIGNhcmUgb2YgdGhpcy4KCk15 IHRha2UgaXMgdGhhdCB1c2luZyBwcmVwcm9jZXNzb3IgaXMgbm90IHdpc2UgLSBpdCdzIHRoZSBs YXN0IHJlc29ydCBpZgp0aGVyZSdzIG5vIG90aGVyIHByb3BlciB3YXkgb2YgZG9pbmcgdGhpbmdz LiBQcmVwcm9jZXNzb3IgcmVxdWlyZXMgYWxsCnNvcnRzIG9mIGV4dHJhIHBhcmVudGhlc2lzIHRv IHByb3RlY3QgYWdhaW5zdCBpdHMgZGVmaWNpZW5jaWVzLCBhbmQgaXQKaXQgbWVyZWx5IGEgdG9v bCB0byBkbyBzZWFyY2gtYW5kLXJlcGxhY2UuIEV2ZW4gbXVsdGktbGluZSBuZWVkcyBzcGVjaWFs CnRyZWF0bWVudC4KCj4gV2hhdCB5b3UgbmVlZCB0byBjb25zaWRlciBhcyB3ZWxsIGlzIHRoYXQg bWFueSBwZW9wbGUgdGhhdCB3b3JrIHdpdGggdGhlCj4gTGludXgga2VybmVsIGV4cGVjdCBjb2Rl IHRvIGJlIGluIGEgY2VydGFpbiBzdHlsZS4gUmVnaXN0ZXIgYWNjZXNzZXMgb2YKPiB0aGUgZm9y bQo+IAo+ICAgICAgICAgd3JpdGVsKHZhbHVlLCBiYXNlICsgT0ZGU0VUKTsKPiAKPiBhcmUgdmVy eSBjb21tb24gYW5kIGV4cGVjdGVkIHRvIGxvb2sgYSBjZXJ0YWluIHdheSwgc28gaWYgeW91IHdy aXRlIGNvZGUKPiB0aGF0IGRvZXNuJ3QgY29tcGx5IHdpdGggdGhlc2UgZ3VpZGVsaW5lcyB5b3Ug bWFrZSBpdCBleHRyYSBoYXJkIGZvcgo+IHBlb3BsZSB0byByZWFkIHRoZSBjb2RlLiBBbmQgdGhh dCdsbCBjb3N0IGV4dHJhIHRpbWUsIHdoaWNoIHBlb3BsZSBkb24ndAo+IHVzdWFsbHkgaGF2ZSBp biBleGNlc3MuCgpCdXQgdGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHN0YXRpYyBpbmxpbmUg dnMuICNkZWZpbmUgYW55bW9yZSwgcmlnaHQ/Cgo+IE1heWJlIHlvdSBjYW4gZXhwbGFpbiB0aGUg dXNlZnVsbmVzcyBvZiB0aGlzIHNvbWUgbW9yZS4gV2h5IHdvdWxkIGl0IGJlCj4gZWFzaWVyIHRv IGxvb2sgYXQgdGhlbSBpbiBzeXNmcyB0aGFuIGluIGRlYnVnZnM/IFlvdSBjb3VsZCBiZSBwcm92 aWRpbmcKPiBhIHNpbXBsZSBsaXN0IG9mIHN5bmNwb2ludHMgYWxvbmcgd2l0aCBtaW4vbWF4LCBu YW1lLCByZXF1ZXN0ZWQgc3RhdHVzLAo+IGV0Yy4gaW4gZGVidWdmcyBhbmQgaXQgc2hvdWxkIGJl IGFzIGVhc3kgdG8gcGFyc2UgZm9yIGJvdGggaHVtYW5zIGFuZAo+IG1hY2hpbmVzIGFzIHN5c2Zz LiBJIGRvbid0IHRoaW5rIElPQ1RMcyB3b3VsZCBiZSBhbnkgZ2FpbiBhcyB0aGV5IHRlbmQKPiB0 byBoYXZlIGhpZ2hlciBBQkkgc3RhYmlsaXR5IHJlcXVpcmVtZW50cyB0aGFuIGRlYnVnZnMgKHdo aWNoIGRvZXNuJ3QKPiBoYXZlIHZlcnkgc3Ryb25nIHJlcXVpcmVtZW50cykgb3Igc3lzZnMgKHdo aWNoIGlzIG9mdGVuIGNvbnNpZGVyZWQgYXMgYQo+IHB1YmxpYyBBQkkgYXMgd2VsbCBhbmQgdGhl cmVmb3JlIG5lZWRzIHRvIGJlIHN0YWJsZSkuCgpkZWJ1Z2ZzIGlzIGp1c3QgYSBkZWJ1Z2dpbmcg dG9vbCwgYW5kIHVzZXIgc3BhY2UgY2Fubm90IHJlbHkgb24gaXQuIE9ubHkKZGV2ZWxvcGVycyBj YW4gcmVseSBvbiBleGlzdGVuY2Ugb2YgZGVidWdmcywgYXMgdGhleSBoYXZlIHRoZSBtZWFucyB0 bwplbmFibGUgaXQuCgpzeXNmcyBpcyBhIHBsYWNlIGZvciBhY3R1YWwgQVBJcyBhcyB5b3UgbWVu dGlvbiwgYW5kIHVzZXIgc3BhY2UgY2FuIHJlbHkKb24gdGhlbSBhcyBwcm9wZXIgQVBJcy4gVGhh dCdzIHdoYXQgdGhlIHZhbHVlcyB3ZXJlIGV4cG9ydGVkIGZvci4KCj4gSSd2ZSBzYWlkIHRoaXMg YmVmb3JlLCBhbmQgSSB0aGluayB0aGF0IHRoaXMgdHJpZXMgdG8gYmUgb3Zlcmx5IGdlbmVyaWMu Cj4gRGlzcGxheSBjb250cm9sbGVycyBmb3IgaW5zdGFuY2Ugd29yayBxdWl0ZSB3ZWxsIHdpdGhv dXQgYW4gYXR0YWNoZWQKPiBudmhvc3RfY2hhbm5lbC4KClllcywgdGhlc2Ugc3RydWN0dXJlcyBh cmVuJ3QgbWVhbnQgdG8gYmUgdXNlZCBieSBhbnl0aGluZyBlbHNlIHRoYW4KdW5pdHMgdGhhdCBh cmUgY29udHJvbGxlZCBieSB0aGUgaG9zdDF4IGRyaXZlci4gREMsIGZvciBleGFtcGxlLAp3b3Vs ZG4ndCBoYXZlIHRoaXMuCgpUZXJqZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756473Ab2K3Iww (ORCPT ); Fri, 30 Nov 2012 03:52:52 -0500 Received: from hqemgate04.nvidia.com ([216.228.121.35]:7733 "EHLO hqemgate04.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750929Ab2K3Iwu convert rfc822-to-8bit (ORCPT ); Fri, 30 Nov 2012 03:52:50 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Fri, 30 Nov 2012 00:52:24 -0800 Message-ID: <50B874C7.5030208@nvidia.com> Date: Fri, 30 Nov 2012 10:56:39 +0200 From: =?UTF-8?B?VGVyamUgQmVyZ3N0csO2bQ==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Thierry Reding CC: "linux-tegra@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC v2 1/8] video: tegra: Add nvhost driver References: <1353935954-13763-1-git-send-email-tbergstrom@nvidia.com> <1353935954-13763-2-git-send-email-tbergstrom@nvidia.com> <20121128212301.GA25531@avionic-0098.adnet.avionic-design.de> <50B73710.2040102@nvidia.com> <20121129114704.GB6150@avionic-0098.adnet.avionic-design.de> In-Reply-To: <20121129114704.GB6150@avionic-0098.adnet.avionic-design.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.11.2012 13:47, Thierry Reding wrote: > On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote: >> Tegra20 and Tegra30 are compatible, but future chips are not. I was >> hoping we would be ready in upstream kernel for future chips. > > I think we should ignore that problem for now. Generally planning for > any possible combination of incompatibilities leads to overgeneralized > designs that require precisely these kinds of indirections. > > Once some documentation for Tegra 40 materializes we can start thinking > about how to encapsulate the incompatible code. I think here our perspectives differ a lot. That is natural considering the company I work for and company you work for, so let's try to sync the perspective. In my reality, whatever is in market is old news and I barely work on them anymore. Upstreaming activity is the exception. 90% of my time is spent dealing with future chips which I know cannot be handled without this split to logical and physical driver parts. For you, Tegra2 and Tegra3 are the reality. If we move nvhost in upstream a bit incompatible, that's fine, like ripping out features or adding new new stuff, like a new memory type. All of this I can support with a good diff tool to get all the patches flowing between upstream and downstream. If we do fundamental changes that prevent bringing the code back to downstream, like removing this abstraction, the whole process of upstream and downstream converging hits a brick wall. We wouldn't have proper continuing co-operation, but just pushing code out and being done with it. > I noticed that it was filled with content in one of the subsequent > patches. Depending on how this gets merged eventually you could postpone > adding the function until the later patch. But perhaps once the code has > been properly reviewed we can just squash the patches again. We'll see. Ok, thanks. >> True. I might also as well delete the general interrupt altogether, as >> we don't use it for any real purpose. > > I think it might still be useful for diagnostics. It seems to be used > when writes time out. That could still be helpful information when > debugging problems. It's actually a stale comment. The client units are not signaling anything useful with the interrupt. There's use for it in downstream, but that's irrelevant here. > Making this generic for all modules may not be what we want as it > doesn't allow devices to handle things themselves if necessary. Clock > management is just part of the boiler plate that every driver is > supposed to cope with. Also the number of clocks is usually not higher > than 2 or 3, so the pain is manageable. =) > > Furthermore doing this in loops may not work for all modules. Some may > require additional delays between enabling the clocks, others may be > able to selectively disable one clock but not the other(s). Yes, but I'll just rip the power management code out, so we can postpone this until we have validated and verified the runtime PM mechanism downstream. >> I could move this to debug.c, but it's debugging aid when a command >> stream is misbehaving and it spews this to UART when sync point wait is >> timing out. So not debugfs stuff. > > Okay, in that case it should stay in. Perhaps convert dev_info() to > dev_dbg(). Perhaps wrapping it in some #ifdef CONFIG_TEGRA_HOST1X_DEBUG > guards would also be useful. Maybe not. I could do that for upstream. In downstream it cannot depend on DEBUG flag, as these spews are an important part of how we debug problems with customer devices and the DEBUG flag is never on in customer builds. > The problem is not with autogenerated files in general. The means by > which they are generated are less important. However, autogenerated > files often contain a lot of unneeded definitions and contain things > such as "autogenerated - do not edit" lines. > > So generally if you generate the content using some scripts to make sure > it corresponds to what engineering gave you, that's okay as long as you > make sure it has the correct form and doesn't contain any cruft. I can remove the boilerplate, that's not a problem. In general, we have tried to be very selective about what we generate, so that it matches what we're using. >> I like static inline because I get the benefit of compiler type >> checking, and gcov shows me which register definitions have been used in >> different tests. > > Type checking shouldn't be necessary for simple defines. And I wasn't > aware that you could get the Linux kernel to write out data to be fed to > gcov. > >> #defines are always messy and I pretty much hate them. But if the >> general request is to use #define's, even though I don't agree, I can >> accommodate. It's simple to write a sed script to do the conversion. > > There are a lot of opportunities to abuse #defines but they are harmless > for register definitions. The Linux kernel is full of them and I haven't > yet seen any code that uses static inline functions for this purpose. My problem is just that I know that the code generated is the same. What we're talking about is that should we let the preprocessor or compiler take care of this. My take is that using preprocessor is not wise - it's the last resort if there's no other proper way of doing things. Preprocessor requires all sorts of extra parenthesis to protect against its deficiencies, and it it merely a tool to do search-and-replace. Even multi-line needs special treatment. > What you need to consider as well is that many people that work with the > Linux kernel expect code to be in a certain style. Register accesses of > the form > > writel(value, base + OFFSET); > > are very common and expected to look a certain way, so if you write code > that doesn't comply with these guidelines you make it extra hard for > people to read the code. And that'll cost extra time, which people don't > usually have in excess. But this has nothing to do with static inline vs. #define anymore, right? > Maybe you can explain the usefulness of this some more. Why would it be > easier to look at them in sysfs than in debugfs? You could be providing > a simple list of syncpoints along with min/max, name, requested status, > etc. in debugfs and it should be as easy to parse for both humans and > machines as sysfs. I don't think IOCTLs would be any gain as they tend > to have higher ABI stability requirements than debugfs (which doesn't > have very strong requirements) or sysfs (which is often considered as a > public ABI as well and therefore needs to be stable). debugfs is just a debugging tool, and user space cannot rely on it. Only developers can rely on existence of debugfs, as they have the means to enable it. sysfs is a place for actual APIs as you mention, and user space can rely on them as proper APIs. That's what the values were exported for. > I've said this before, and I think that this tries to be overly generic. > Display controllers for instance work quite well without an attached > nvhost_channel. Yes, these structures aren't meant to be used by anything else than units that are controlled by the host1x driver. DC, for example, wouldn't have this. Terje