From mboxrd@z Thu Jan 1 00:00:00 1970 From: daeinki Date: Fri, 07 Jan 2011 04:19:54 +0000 Subject: Re: Memory sharing issue by application on V4L2 based device driver Message-Id: <4D26946A.60704@samsung.com> List-Id: References: <4D25BC22.6080803@samsung.com> <002201cbadfd$6d59e490$480dadb0$%han@samsung.com> <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> In-Reply-To: <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 To: linux-arm-kernel@lists.infradead.org SGVsbG8sIE1yLiBKb25naHVuLgoKcGxlYXNlLCBub3RlIHRoYXQgdXNlciBwcm9jZXNzJ3MgcGdk IGFuZCBkZXZpY2UncyBwZ2Qgd2l0aCBzeXN0ZW0gbW11CmFyZSBkaWZmZXJuZW50LiBmaXJzdCwg dGhlIG1lbW9yeSBhbGxvY2F0ZWQgYnkgdXNlciBtYWxsb2Mgc2hvdWxkIGJlCm1hcHBlZCB0byBw aHlzaWNhbCBtZW1vcnkgaW4gcGFnZSB1bml0IGJlY2F1c2UgdXNlciBhcHAgYWxzbyBzaG91bGQg YmUKYWNjZXNzZWQgdG8gb3duIG1lbW9yeSByZWdpb24uIGFuZCB3aGVuIG1hcHBpbmcgdGhlIHBo eXNpY2FsIG1lbW9yeSB0bwpkZXZpY2UgdmlydHVhbCBhZGRyZXNzLCBpdCBjcmVhdGVzIHBhZ2Ug dGFibGUgZW50cnkgZm9yIDY0ayBvciAxTSBhbmQKdGhlbiBjb3VsZCBtYXAgcGh5c2ljYWwgYWRk cmVzcyB0byB0aG9zZSBlbnRyaWVzLiB0aGVyZWZvcmUgd2hhdCB5b3UKbWVudGlvbiBoYXMgbm8g cHJvYmxlbS4KCmFjdHVhbCBpc3N1ZSBpcyBub3QgdG8gbmVlZCBkZW1lbmQgcGFnaW5nLCBzb21l IGlzc3VlcyB3ZSBkb24ndAp1bmRlcnN0YW5kIG1heSBleGlzdCBhcyBzaWRlIGVmZmVjdHMuCgp0 aGFuayB5b3UuCgpKb25naHVuIEhhbiC+tCCx2zoKPiBIZWxsbywKPiAKPiBUaGF0J3Mgbm90IGEg dHJhbnNsYXRpb24gaXNzdWUuIFdoYXQgSSBtZW50aW9uIGlzIHRoZSBzaXplIG9mIGFsbG9jYXRp b24uCj4gVGhlIG1hbGxvYyB1c2VzIDRLQiBwYWdlIGFsbG9jYXRpb24gYW5kIFNZUy5NTVUgY2Fu IGhhbmRsZSBpdC4KPiBCdXQgNjRLQiBvciAxTUIgcGh5c2ljYWxseSBjb250aWd1b3VzIG1lbW9y eSBpcyBiZXR0ZXIgdGhhbiA0S0IgcGFnZSBpbiB0aGUKPiBwb2ludCBvZiBwZXJmb3JtYW5jZS4K PiAKPiBCZXN0IHJlZ2FyZHMsCj4gCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZy b206IGxpbnV4LW1lZGlhLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LW1lZGlh LQo+PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBJbktpIERhZQo+PiBTZW50 OiBGcmlkYXksIEphbnVhcnkgMDcsIDIwMTEgMTE6MTcgQU0KPj4gVG86IEpvbmdodW4gSGFuCj4+ IENjOiBsaW51eC1tZWRpYUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMu aW5mcmFkZWFkLm9yZzsKPiBsaW51eC1mYmRldjsKPj4ga3l1bmdtaW4ucGFya0BzYW1zdW5nLmNv bQo+PiBTdWJqZWN0OiBSZTogTWVtb3J5IHNoYXJpbmcgaXNzdWUgYnkgYXBwbGljYXRpb24gb24g VjRMMiBiYXNlZCBkZXZpY2UKPiBkcml2ZXIKPj4gd2l0aCBzeXN0ZW0gbW11Lgo+Pgo+PiB0aGFu ayB5b3UgZm9yIHlvdXIgY29tbWVudHMuCj4+Cj4+IHlvdXIgc2Vjb25kIGNvbW1lbnQgaGFzIG5v IGFueSBwcm9ibGVtIGFzIEkgc2FpZCBiZWZvcmUsIHVzZXIgdmlydHVhbAo+IGFkZGVzcwo+PiBj b3VsZCBiZSB0cmFuc2xhdGVkIGluIHBhZ2UgdW5pdC4gYnV0IHRoZSBwcm9ibGVtLCBhcyB5b3Ug c2FpZCwgaXMgdGhhdAo+IHdoZW4gY3B1Cj4+IGFjY2VzcyB0byB0aGUgbWVtb3J5IGluIHVzZXIg bW9kZSwgdGhlIG1lbW9yeSBhbGxvY2F0ZWQgYnkgbWFsbG9jLCBwYWdlCj4gZmF1bHQKPj4gb2Nj dXJzIHNvIHdlIGNhbid0IGZpbmQgcGZuIHRvIHVzZXIgdmlydHVhbCBhZGRyZXNzLiBJIG1pc3Nl ZCB0aGF0LiBidXQgSQo+IHRoaW5rIHdlCj4+IGNvdWxkIHJlc29sdmUgdGhpcyBvbmUuCj4+Cj4+ IGFzIGJlZm9yZSwgdXNlciBhcHBsaWNhdGlvbiBhbGxvY2F0ZXMgbWVtb3J5IHRocm91Z2ggbWFs bG9jIGZ1bmN0aW9uIGFuZAo+IHRoZW4KPj4gc2VuZCBpdCB0byBkZXZpY2UgZHJpdmVyKHVzaW5n IHVzZXJwdHIgZmVhdHVyZSkuIGlmIHRoZSBwZm4gaXMgbnVsbCB3aGVuCj4gZGV2aWNlIGRyaXZl cgo+PiB0cmFuc2xhdGVkIHVzZXIgdmlydHVhbCBhZGRyZXNzIGluIHBhZ2UgdW5pdCB0aGVuIGl0 IGFsbG9jYXRlcyBwaHNpY2FsCj4gbWVtb3J5IGluCj4+IHBhZ2UgdW5pdCB1c2luZyBzb21lIGlu dGVyZmFjZSBzdWNoIGFzIGFsbG9jX3BhZ2UoKSBhbmQgdGhlbiBtYXBwaW5nCj4gdGhlbS4gd2hl bgo+PiBwZm4gaXMgbnVsbCwgdG8gY2hlY2sgaXQgYW5kIGFsbG9jYXRlIHBoeXNpY2FsIG1lbW9y eSBpbiBwYWdlIHVuaXQgY291bGQKPiBiZQo+PiBwcm9jZXNzZWQgYnkgdmlkZW9idWYyLgo+Pgo+ PiBvZiBjb3Vyc2UsIHZpZGVvYnVmMiBoYXMgbm8gYW55IGR1dHkgY29uc2lkZXJlZCBmb3Igc3lz dGVtIG1tdS4gc28KPj4gdmlkZW9idWYyIGp1c3QgcHJvdmlkZXMgY2FsbGJhY2sgZm9yIDNyZCBw YXJ0eSBhbmQgYW55IHBsYXRmb3JtIHdpdGgKPiBzeXN0ZW0gbW11Cj4+IHN1Y2ggYXMgU2Ftc3Vu ZyBTb0MgQzIxMCBpbXBsZW1lbnRzIHRoZSBmdW5jdGlvbihhbGxvY2F0aW5nIHBoeXNpY2FsCj4g bWVtb3J5Cj4+IGFuZCBtYXBwaW5nIGl0KSBhbmQgcmVnaXN0ZXJzIGl0IHRvIGNhbGxiYWNrIG9m IHZpZGVvYnVmMi4gYnkgZG9pbmcgc28sIEkKPiB0aGluayB5b3VyCj4+IGZpcnN0IGNvbW1lbnQg Y291bGQgYmUgY2xlYXJlZC4KPj4KPj4gcGxlYXNlLCBmZWVsIGZyZWUgdG8gZ2l2ZSBtZSB5b3Vy IG9waW5pb24gYW5kIHBvaW50aW5nIG91dC4KPj4KPj4gdGhhbmsgeW91Lgo+Pgo+PiAyMDExs+Ig Mb/5IDfAzyC/wMD8IDg6NTcsIEpvbmdodW4gSGFuIDxqb25naHVuLmhhbkBzYW1zdW5nLmNvbT60 1MDHILi7Ogo+Pj4gSGVsbG8sCj4+Pgo+Pj4gVGhlcmUgYXJlIHR3byByZWFzb25zIHdoeSBtYWxs b2MgaXNuJ3Qgc3VpdGFibGUgZm9yIGl0Lgo+Pj4KPj4+IFRoZSBmaXJzdCBpcyB0aGF0IG1hbGxv YyBkb2Vzbid0IGFsbG9jYXRlIG1lbW9yeSB3aGVuIG1hbGxvYyBpcyBjYWxsZWQuCj4+PiBTbyBk cml2ZXIgb3IgdmIyIGNhbm5vdCBmaW5kIFBGTiBmb3IgaXQgaW4gdGhlIFZJRElPQ19RQlVGLgo+ Pj4KPj4+IFRoZSBzZWNvbmQgaXMgdGhhdCBtYWxsb2MgdXNlcyA0S0IgcGFnZSBhbGxvY2F0aW9u Lgo+Pj4gU1lTLk1NVShJTy1NTVUpIGNhbiBoYW5kbGUgc2NhdHRlcmVkIG1lbW9yeS4gQnV0IGl0 IGhhcyBhIHBlbmFsdHkgd2hlbgo+Pj4gVExCIG1pc3MgaXMgb2NjdXJyZWQuCj4+PiBTbyBhcyBw b3NzaWJsZSBhcyBwaHlzaWNhbGx5IGNvbnRpZ3VvdXMgcGFnZXMgYXJlIG5lZWRlZCBmb3IKPj4+ IHBlcmZvcm1hbmNlIGVuaGFuY2VtZW50Lgo+Pj4KPj4+IFNvIG5ldyBhbGxvY2F0b3Igd2hpY2gg Y2FuIGNsZWFyIHR3byBtYWluIGlzc3VlcyBpcyBuZWVkZWQuCj4+Pgo+Pj4gQmVzdCByZWdhcmRz LAo+Pj4KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4+IEZyb206IGxpbnV4LW1l ZGlhLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LW1lZGlhLQo+Pj4+IG93bmVy QHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEluS2kgRGFlCj4+Pj4gU2VudDogVGh1cnNk YXksIEphbnVhcnkgMDYsIDIwMTEgMTA6MjUgUE0KPj4+PiBUbzogbGludXgtbWVkaWFAdmdlci5r ZXJuZWwub3JnCj4+Pj4gU3ViamVjdDogTWVtb3J5IHNoYXJpbmcgaXNzdWUgYnkgYXBwbGljYXRp b24gb24gVjRMMiBiYXNlZCBkZXZpY2UKPj4+PiBkcml2ZXIKPj4+IHdpdGgKPj4+PiBzeXN0ZW0g bW11Lgo+Pj4+Cj4+Pj4gSGVsbG8sIGFsbC4KPj4+Pgo+Pj4+IEknZCBsaWtlIHRvIGRpc2N1c3Mg bWVtb3J5IHNoYXJpbmcgaXNzdWUgYnkgYXBwbGljYXRpb24gb24gdjRsMiBiYXNlZAo+Pj4gZGV2 aWNlIGRyaXZlcgo+Pj4+IHdpdGggc3lzdGVtIG1tdSBhbmQgZ2V0IHNvbWUgYWR2aWNlcyBhYm91 dCB0aGF0Lgo+Pj4+Cj4+Pj4gTm93IEkgYW0gd29ya2luZyBvbiBTYW1zdW5nIFNvQyBDMjEwIHBs YXRmb3JtIGFuZCB0aGlzIHBsYXRmb3JtIGhhcwo+Pj4+IHNvbWUgbXVsdGltZWRpYSBkZXZpY2Vz IHdpdGggc3lzdGVtIG1tdSBzdWNoIGFzIGZpbWMsIGFuZCBtZmMgYWxzbyB3ZQo+Pj4+IGhhdmUg aW1wbGVtZW50ZWQgZGV2aWNlIGRyaXZlcnMgZm9yIHRoZW0uIHRob3NlIGRyaXZlcnMgYXJlIGJh c2VkIG9uCj4+Pj4gVjRMMgo+Pj4gZnJhbWV3b3JrCj4+Pj4gd2l0aCB2aWRlb2J1ZjIuIGZvciBz eXN0ZW0gbW11IG9mIGVhY2ggZGV2aWNlLCB3ZSB1c2VkIFZDTShWaXJ0dWFsCj4+PiBDb250aWd1 b3VzCj4+Pj4gTWVtb3J5KSBmcmFtZXdvcmsuCj4+Pj4KPj4+PiBTaW1wbHksIFZDTSBmcmFtZXdv cmsgcHJvdmlkZXMgIHBoeXNpY2FsIG1lbW9yeSwgZGV2aWNlIHZpcnR1YWwKPj4+PiBtZW1vcnkg YWxsb2NhdGlvbiBhbmQgbWVtb3J5IG1hcHBpbmcgYmV0d2VlbiB0aGVtLiB3aGVuIGRldmljZSBk cml2ZXIKPj4+PiBpcwo+Pj4gaW5pdGlhbGl6ZWQgb3IKPj4+PiBvcGVyYXRlZCBieSB1c2VyIGFw cGxpY2F0aW9uLCBlYWNoIGRyaXZlciBhbGxvY2F0ZXMgcGh5c2ljYWwgbWVtb3J5Cj4+Pj4gYW5k Cj4+PiBkZXZpY2UKPj4+PiB2aXJ0dWFsIG1lbW9yeSBhbmQgdGhlbiBtYXBwaW5nIHVzaW5nIFZD TSBpbnRlcmZhY2UuCj4+Pj4KPj4+PiByZWZlciB0byBiZWxvdyBsaW5rIGZvciBtb3JlIGRldGFp bC4KPj4+PiBodHRwOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2xpbnV4LW1lZGlhL21zZzI2NTQ4 Lmh0bWwKPj4+Pgo+Pj4+IFBoeXNpY2FsIG1lbW9yeSBhY2Nlc3MgcHJvY2VzcyBpcyBhcyB0aGUg Zm9sbG93aW5nLgo+Pj4+ICAgICAgICAgICAgRFZBICAgICAgICAgICAgICAgICAgICAgICAgICBQ QQo+Pj4+IGRldmljZSAtLS0tLS0tLS0tLS0tLT4gc3lzdGVtIG1tdSAtLS0tLS0tLS0tLS0tLS0t LS0+IHBoeXNpY2FsIG1lbW9yeQo+Pj4+Cj4+Pj4gRFZBIDogZGV2aWNlIHZpcnR1YWwgYWRkcmVz cy4KPj4+PiBQQSA6IHBoeXNpY2FsIGFkZHJlc3MuCj4+Pj4KPj4+PiBsaWtlIHRoaXMsIGRldmlj ZSB2aXJ0dWFsIGFkZHJlc3Mgc2hvdWxkIGJlIHNldCB0byBidWZmZXIoc291cmNlIG9yCj4+Pj4g ZGVzdGluYXRpb24pIHJlZ2lzdGVyIG9mIG11bHRpbWVkaWEgZGV2aWNlLgo+Pj4+Cj4+Pj4gdGhl IHByb2JsZW0gaXMgdGhhdCBhcHBsaWNhdGlvbiB3YW50IHRvIHNoYXJlIG93biBtZW1vcnkgd2l0 aCBhbnkKPj4+PiBkZXZpY2UKPj4+IGRyaXZlciB0bwo+Pj4+IGF2b2lkIG1lbW9yeSBjb3B5LiBp biBvdGhlciB3b3JkcywgdXNlci1hbGxvY2F0ZWQgbWVtb3J5IGNvdWxkIGJlCj4+Pj4gc291cmNl Cj4+PiBvcgo+Pj4+IGRlc3RpbmF0aW9uIG1lbW9yeSBvZiBtdWx0aW1lZGlhIGRldmljZSBkcml2 ZXIuCj4+Pj4KPj4+Pgo+Pj4+IGxldCdzIHNlZSB0aGUgZGlhZ3JhbSBiZWxvdy4KPj4+Pgo+Pj4+ ICAgICAgICAgICAgICAgIHVzZXIgYXBwbGljYXRpb24KPj4+Pgo+Pj4+ICAgICAgICAgICAgICAg ICAgICAgIHwKPj4+PiAgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgfAo+Pj4+ICAgICAgICAgICAgICAgICAgICAgIHwKPj4+PiAgICAgICAgICAgICAgICAg ICAgICB8ICAxLiBVVkEoYWxsb2NhdGVkIGJ5IG1hbGxvYykKPj4+PiAgICAgICAgICAgICAgICAg ICAgICB8Cj4+Pj4gICAgICAgICAgICAgICAgICAgICAgfAo+Pj4+ICAgICAgICAgICAgICAgICAg ICChrHwvICAgICAgICAgICAgICAgICAgIDIuIFVWQShpbiBwYWdlIHVuaXQpCj4+Pj4KPj4+PiAg ICAgICAgLS0tLS0+IG11bHRpbWVkaWEgZGV2aWNlIGRyaXZlciAtLS0tLS0tLS0tLS0tLS0tLS0t PiB2aWRlb2J1ZjIKPj4+PiAgICAgICAgfAo+Pj4+ICAgICAgICB8ICAgICAgICB8ICAgICBeICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4gICAgICAgIHwgICAg ICAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPj4+ PiAgICAgICAgfCAgICAgICAgfCAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+Pj4+ICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAzLiBQ QShpbiBwYWdlIHVuaXQpCj4+Pj4gICAgICAgIHwgICAgICAgIHwKPj4+PiAgICAgICAgfCAgICAg ICAgfCA0LiBQQShpbiBwYWdlIHVuaXQpCj4+Pj4gNi4gRFZBICB8ICAgICAgICB8Cj4+Pj4gICAg ICAgIHwgICAgICAgIHwKPj4+PiAgICAgICAgfCAgICAgICAgfAo+Pj4+ICAgICAgICB8ICAgICAg oax8Lwo+Pj4+ICAgICAgICB8Cj4+Pj4gICAgICAgIHwgICAgICAgVmlydHVhbCBDb250aWd1b3Vz IE1lbW9yeSAtLS0tLS0tLS0KPj4+PiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAo+Pj4+ICAgICAgICB8ICAgICAgICAgICB8ICAgICBeICAgICAgICAg ICAgICAgICAgICAgICB8Cj4+Pj4gICAgICAgIHwgICAgICAgICAgIHwgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgIHwgNS4gbWFwIFBBIHRvIERWQQo+Pj4+ICAgICAgICB8ICAgICAgICAgICB8 ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4gICAgICAgIHwgICAgICAgICAgIHwg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwKPj4+PiAgICAgICAgLS0tLS0tLS0tLS0tLSAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4+Cj4+Pj4gUEEgOiBwaHlzaWNhbCBhZGRy ZXNzLgo+Pj4+IFVWQSA6IHVzZXIgdmlydHVhbCBhZGRyZXNzLgo+Pj4+IERWQSA6IGRldmljZSB2 aXJ0dWFsIGFkZHJlc3MuCj4+Pj4KPj4+PiAxLiB1c2VyIGFwcGxpY2F0aW9uIGFsbG9jYXRlcyB1 c2VyIHNwYWNlIG1lbW9yeSB0aHJvdWdoIG1hbGxvYwo+Pj4+IGZ1bmN0aW9uCj4+PiBhbmQKPj4+ PiBzZW5kaW5nIGl0IHRvIG11bHRpbWVkaWEgZGV2aWNlIGRyaXZlciBiYXNlZCBvbiB2NGwyIGZy YW1ld29yawo+Pj4+IHRocm91Z2gKPj4+IHVzZXJwdHIKPj4+PiBmZWF0dXJlLgo+Pj4+Cj4+Pj4g MiwgMy4gbXVsdGltZWRpYSBkZXZpY2UgZHJpdmVyIGdldHMgdHJhbnNsYXRlZCBwaHlzaWNhbCBh ZGRyZXNzIGZyb20KPj4+PiB2aWRlb2J1ZjIgZnJhbWV3b3JrIGluIHBhZ2UgdW5pdC4KPj4+Pgo+ Pj4+IDQsIDUuIG11bHRpbWVkaWEgZGV2aWNlIGRyaXZlciBnZXRzIGFsbG9jYXRlZCBkZXZpY2Ug dmlydHVhbCBhZGRyZXNzCj4+Pj4gYW5kCj4+PiBtYXBwaW5nIGl0Cj4+Pj4gdG8gcGh5c2ljYWwg YWRkcmVzcyBhbmQgdGhlbiBtYXBwaW5nIHRoZW0gdGhyb3VnaCBWQ00gaW50ZXJmYWNlLgo+Pj4+ Cj4+Pj4gNi4gbXVsdGltZWRpYSBkZXZpY2UgZHJpdmVyIHNldHMgZGV2aWNlIHZpcnR1YWwgYWRk cmVzcyBmcm9tIFZDTSB0bwo+Pj4gYnVmZmVyIHJlZ2lzdGVyLgo+Pj4+IHRoZSBkaWFncmFtIGFi b3ZlIGlzIGZ1bGx5IHRoZW9yZXRpY2FsIHNvIEkgd29uZGVyIHRoYXQgdGhpcyB3YXkgaXMKPj4+ IHJlYXNvbmFibGUgYW5kCj4+Pj4gaGFzIHNvbWUgcHJvYmxlbXMgYWxzbyB3aGF0IHNob3VsZCBi ZSBjb25zaWRlcmVkLgo+Pj4+Cj4+Pj4gdGhhbmsgeW91IGZvciB5b3VyIGludGVyZXN0aW5nLgo+ Pj4+Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4+PiBsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdAo+Pj4+IGxpbnV4LWFybS1rZXJuZWxA bGlzdHMuaW5mcmFkZWFkLm9yZwo+Pj4+IGh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxt YW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo+Pj4+IC0tCj4+Pj4gVG8gdW5zdWJzY3JpYmUg ZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlCj4+Pj4gbGludXgtbWVk aWEiIGluCj4+PiB0aGUgYm9keQo+Pj4+IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5r ZXJuZWwub3JnIE1vcmUgbWFqb3Jkb21vIGluZm8gYXQKPj4+PiBodHRwOi8vdmdlci5rZXJuZWwu b3JnL21ham9yZG9tby1pbmZvLmh0bWwKPj4+Cj4+IC0tCj4+IFRvIHVuc3Vic2NyaWJlIGZyb20g dGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1tZWRpYSIgaW4KPiB0 aGUgYm9keQo+PiBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyBNb3Jl IG1ham9yZG9tbyBpbmZvIGF0Cj4+IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWlu Zm8uaHRtbAo+IAo+IC0tCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhl IGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWZiZGV2IiBpbgo+IHRoZSBib2R5IG9mIGEgbWVzc2Fn ZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAg aHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCj4gCgotLQpUbyB1bnN1 YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgt ZmJkZXYiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwu b3JnCk1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jk b21vLWluZm8uaHRtbA== From mboxrd@z Thu Jan 1 00:00:00 1970 From: inki.dae@samsung.com (daeinki) Date: Fri, 07 Jan 2011 13:19:54 +0900 Subject: Memory sharing issue by application on V4L2 based device driver with system mmu. In-Reply-To: <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> References: <4D25BC22.6080803@samsung.com> <002201cbadfd$6d59e490$480dadb0$%han@samsung.com> <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> Message-ID: <4D26946A.60704@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, Mr. Jonghun. please, note that user process's pgd and device's pgd with system mmu are differnent. first, the memory allocated by user malloc should be mapped to physical memory in page unit because user app also should be accessed to own memory region. and when mapping the physical memory to device virtual address, it creates page table entry for 64k or 1M and then could map physical address to those entries. therefore what you mention has no problem. actual issue is not to need demend paging, some issues we don't understand may exist as side effects. thank you. Jonghun Han ? ?: > Hello, > > That's not a translation issue. What I mention is the size of allocation. > The malloc uses 4KB page allocation and SYS.MMU can handle it. > But 64KB or 1MB physically contiguous memory is better than 4KB page in the > point of performance. > > Best regards, > >> -----Original Message----- >> From: linux-media-owner at vger.kernel.org [mailto:linux-media- >> owner at vger.kernel.org] On Behalf Of InKi Dae >> Sent: Friday, January 07, 2011 11:17 AM >> To: Jonghun Han >> Cc: linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org; > linux-fbdev; >> kyungmin.park at samsung.com >> Subject: Re: Memory sharing issue by application on V4L2 based device > driver >> with system mmu. >> >> thank you for your comments. >> >> your second comment has no any problem as I said before, user virtual > addess >> could be translated in page unit. but the problem, as you said, is that > when cpu >> access to the memory in user mode, the memory allocated by malloc, page > fault >> occurs so we can't find pfn to user virtual address. I missed that. but I > think we >> could resolve this one. >> >> as before, user application allocates memory through malloc function and > then >> send it to device driver(using userptr feature). if the pfn is null when > device driver >> translated user virtual address in page unit then it allocates phsical > memory in >> page unit using some interface such as alloc_page() and then mapping > them. when >> pfn is null, to check it and allocate physical memory in page unit could > be >> processed by videobuf2. >> >> of course, videobuf2 has no any duty considered for system mmu. so >> videobuf2 just provides callback for 3rd party and any platform with > system mmu >> such as Samsung SoC C210 implements the function(allocating physical > memory >> and mapping it) and registers it to callback of videobuf2. by doing so, I > think your >> first comment could be cleared. >> >> please, feel free to give me your opinion and pointing out. >> >> thank you. >> >> 2011? 1? 7? ?? 8:57, Jonghun Han ?? ?: >>> Hello, >>> >>> There are two reasons why malloc isn't suitable for it. >>> >>> The first is that malloc doesn't allocate memory when malloc is called. >>> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF. >>> >>> The second is that malloc uses 4KB page allocation. >>> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when >>> TLB miss is occurred. >>> So as possible as physically contiguous pages are needed for >>> performance enhancement. >>> >>> So new allocator which can clear two main issues is needed. >>> >>> Best regards, >>> >>>> -----Original Message----- >>>> From: linux-media-owner at vger.kernel.org [mailto:linux-media- >>>> owner at vger.kernel.org] On Behalf Of InKi Dae >>>> Sent: Thursday, January 06, 2011 10:25 PM >>>> To: linux-media at vger.kernel.org >>>> Subject: Memory sharing issue by application on V4L2 based device >>>> driver >>> with >>>> system mmu. >>>> >>>> Hello, all. >>>> >>>> I'd like to discuss memory sharing issue by application on v4l2 based >>> device driver >>>> with system mmu and get some advices about that. >>>> >>>> Now I am working on Samsung SoC C210 platform and this platform has >>>> some multimedia devices with system mmu such as fimc, and mfc also we >>>> have implemented device drivers for them. those drivers are based on >>>> V4L2 >>> framework >>>> with videobuf2. for system mmu of each device, we used VCM(Virtual >>> Contiguous >>>> Memory) framework. >>>> >>>> Simply, VCM framework provides physical memory, device virtual >>>> memory allocation and memory mapping between them. when device driver >>>> is >>> initialized or >>>> operated by user application, each driver allocates physical memory >>>> and >>> device >>>> virtual memory and then mapping using VCM interface. >>>> >>>> refer to below link for more detail. >>>> http://www.spinics.net/lists/linux-media/msg26548.html >>>> >>>> Physical memory access process is as the following. >>>> DVA PA >>>> device --------------> system mmu ------------------> physical memory >>>> >>>> DVA : device virtual address. >>>> PA : physical address. >>>> >>>> like this, device virtual address should be set to buffer(source or >>>> destination) register of multimedia device. >>>> >>>> the problem is that application want to share own memory with any >>>> device >>> driver to >>>> avoid memory copy. in other words, user-allocated memory could be >>>> source >>> or >>>> destination memory of multimedia device driver. >>>> >>>> >>>> let's see the diagram below. >>>> >>>> user application >>>> >>>> | >>>> | >>>> | >>>> | >>>> | 1. UVA(allocated by malloc) >>>> | >>>> | >>>> ?|/ 2. UVA(in page unit) >>>> >>>> -----> multimedia device driver -------------------> videobuf2 >>>> | >>>> | | ^ | >>>> | | | | >>>> | | ------------------------------------------- >>>> | | 3. PA(in page unit) >>>> | | >>>> | | 4. PA(in page unit) >>>> 6. DVA | | >>>> | | >>>> | | >>>> | ?|/ >>>> | >>>> | Virtual Contiguous Memory --------- >>>> | | >>>> | | ^ | >>>> | | | | 5. map PA to DVA >>>> | | | | >>>> | | | | >>>> ------------- ------------------------- >>>> >>>> PA : physical address. >>>> UVA : user virtual address. >>>> DVA : device virtual address. >>>> >>>> 1. user application allocates user space memory through malloc >>>> function >>> and >>>> sending it to multimedia device driver based on v4l2 framework >>>> through >>> userptr >>>> feature. >>>> >>>> 2, 3. multimedia device driver gets translated physical address from >>>> videobuf2 framework in page unit. >>>> >>>> 4, 5. multimedia device driver gets allocated device virtual address >>>> and >>> mapping it >>>> to physical address and then mapping them through VCM interface. >>>> >>>> 6. multimedia device driver sets device virtual address from VCM to >>> buffer register. >>>> the diagram above is fully theoretical so I wonder that this way is >>> reasonable and >>>> has some problems also what should be considered. >>>> >>>> thank you for your interesting. >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel at lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>>> linux-media" in >>> the body >>>> of a message to majordomo at vger.kernel.org More majordomo info at >>>> http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body >> of a message to majordomo at vger.kernel.org More majordomo info at >> http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mailout2.samsung.com ([203.254.224.25]:34992 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752957Ab1AGET6 (ORCPT ); Thu, 6 Jan 2011 23:19:58 -0500 MIME-version: 1.0 Content-type: text/plain; charset=EUC-KR Date: Fri, 07 Jan 2011 13:19:54 +0900 From: daeinki Subject: Re: Memory sharing issue by application on V4L2 based device driver with system mmu. In-reply-to: <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> To: Jonghun Han Cc: 'InKi Dae' , linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 'linux-fbdev' , kyungmin.park@samsung.com Message-id: <4D26946A.60704@samsung.com> Content-transfer-encoding: 8BIT References: <4D25BC22.6080803@samsung.com> <002201cbadfd$6d59e490$480dadb0$%han@samsung.com> <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com> List-ID: Sender: Hello, Mr. Jonghun. please, note that user process's pgd and device's pgd with system mmu are differnent. first, the memory allocated by user malloc should be mapped to physical memory in page unit because user app also should be accessed to own memory region. and when mapping the physical memory to device virtual address, it creates page table entry for 64k or 1M and then could map physical address to those entries. therefore what you mention has no problem. actual issue is not to need demend paging, some issues we don't understand may exist as side effects. thank you. Jonghun Han 쓴 글: > Hello, > > That's not a translation issue. What I mention is the size of allocation. > The malloc uses 4KB page allocation and SYS.MMU can handle it. > But 64KB or 1MB physically contiguous memory is better than 4KB page in the > point of performance. > > Best regards, > >> -----Original Message----- >> From: linux-media-owner@vger.kernel.org [mailto:linux-media- >> owner@vger.kernel.org] On Behalf Of InKi Dae >> Sent: Friday, January 07, 2011 11:17 AM >> To: Jonghun Han >> Cc: linux-media@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > linux-fbdev; >> kyungmin.park@samsung.com >> Subject: Re: Memory sharing issue by application on V4L2 based device > driver >> with system mmu. >> >> thank you for your comments. >> >> your second comment has no any problem as I said before, user virtual > addess >> could be translated in page unit. but the problem, as you said, is that > when cpu >> access to the memory in user mode, the memory allocated by malloc, page > fault >> occurs so we can't find pfn to user virtual address. I missed that. but I > think we >> could resolve this one. >> >> as before, user application allocates memory through malloc function and > then >> send it to device driver(using userptr feature). if the pfn is null when > device driver >> translated user virtual address in page unit then it allocates phsical > memory in >> page unit using some interface such as alloc_page() and then mapping > them. when >> pfn is null, to check it and allocate physical memory in page unit could > be >> processed by videobuf2. >> >> of course, videobuf2 has no any duty considered for system mmu. so >> videobuf2 just provides callback for 3rd party and any platform with > system mmu >> such as Samsung SoC C210 implements the function(allocating physical > memory >> and mapping it) and registers it to callback of videobuf2. by doing so, I > think your >> first comment could be cleared. >> >> please, feel free to give me your opinion and pointing out. >> >> thank you. >> >> 2011년 1월 7일 오전 8:57, Jonghun Han 님의 말: >>> Hello, >>> >>> There are two reasons why malloc isn't suitable for it. >>> >>> The first is that malloc doesn't allocate memory when malloc is called. >>> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF. >>> >>> The second is that malloc uses 4KB page allocation. >>> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when >>> TLB miss is occurred. >>> So as possible as physically contiguous pages are needed for >>> performance enhancement. >>> >>> So new allocator which can clear two main issues is needed. >>> >>> Best regards, >>> >>>> -----Original Message----- >>>> From: linux-media-owner@vger.kernel.org [mailto:linux-media- >>>> owner@vger.kernel.org] On Behalf Of InKi Dae >>>> Sent: Thursday, January 06, 2011 10:25 PM >>>> To: linux-media@vger.kernel.org >>>> Subject: Memory sharing issue by application on V4L2 based device >>>> driver >>> with >>>> system mmu. >>>> >>>> Hello, all. >>>> >>>> I'd like to discuss memory sharing issue by application on v4l2 based >>> device driver >>>> with system mmu and get some advices about that. >>>> >>>> Now I am working on Samsung SoC C210 platform and this platform has >>>> some multimedia devices with system mmu such as fimc, and mfc also we >>>> have implemented device drivers for them. those drivers are based on >>>> V4L2 >>> framework >>>> with videobuf2. for system mmu of each device, we used VCM(Virtual >>> Contiguous >>>> Memory) framework. >>>> >>>> Simply, VCM framework provides physical memory, device virtual >>>> memory allocation and memory mapping between them. when device driver >>>> is >>> initialized or >>>> operated by user application, each driver allocates physical memory >>>> and >>> device >>>> virtual memory and then mapping using VCM interface. >>>> >>>> refer to below link for more detail. >>>> http://www.spinics.net/lists/linux-media/msg26548.html >>>> >>>> Physical memory access process is as the following. >>>> DVA PA >>>> device --------------> system mmu ------------------> physical memory >>>> >>>> DVA : device virtual address. >>>> PA : physical address. >>>> >>>> like this, device virtual address should be set to buffer(source or >>>> destination) register of multimedia device. >>>> >>>> the problem is that application want to share own memory with any >>>> device >>> driver to >>>> avoid memory copy. in other words, user-allocated memory could be >>>> source >>> or >>>> destination memory of multimedia device driver. >>>> >>>> >>>> let's see the diagram below. >>>> >>>> user application >>>> >>>> | >>>> | >>>> | >>>> | >>>> | 1. UVA(allocated by malloc) >>>> | >>>> | >>>> ＼|/ 2. UVA(in page unit) >>>> >>>> -----> multimedia device driver -------------------> videobuf2 >>>> | >>>> | | ^ | >>>> | | | | >>>> | | ------------------------------------------- >>>> | | 3. PA(in page unit) >>>> | | >>>> | | 4. PA(in page unit) >>>> 6. DVA | | >>>> | | >>>> | | >>>> | ＼|/ >>>> | >>>> | Virtual Contiguous Memory --------- >>>> | | >>>> | | ^ | >>>> | | | | 5. map PA to DVA >>>> | | | | >>>> | | | | >>>> ------------- ------------------------- >>>> >>>> PA : physical address. >>>> UVA : user virtual address. >>>> DVA : device virtual address. >>>> >>>> 1. user application allocates user space memory through malloc >>>> function >>> and >>>> sending it to multimedia device driver based on v4l2 framework >>>> through >>> userptr >>>> feature. >>>> >>>> 2, 3. multimedia device driver gets translated physical address from >>>> videobuf2 framework in page unit. >>>> >>>> 4, 5. multimedia device driver gets allocated device virtual address >>>> and >>> mapping it >>>> to physical address and then mapping them through VCM interface. >>>> >>>> 6. multimedia device driver sets device virtual address from VCM to >>> buffer register. >>>> the diagram above is fully theoretical so I wonder that this way is >>> reasonable and >>>> has some problems also what should be considered. >>>> >>>> thank you for your interesting. >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>>> linux-media" in >>> the body >>>> of a message to majordomo@vger.kernel.org More majordomo info at >>>> http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body >> of a message to majordomo@vger.kernel.org More majordomo info at >> http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >