From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756909AbcC2LR3 (ORCPT ); Tue, 29 Mar 2016 07:17:29 -0400 Received: from lucky1.263xmail.com ([211.157.147.130]:35020 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbcC2LR0 (ORCPT ); Tue, 29 Mar 2016 07:17:26 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: ykk@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: <15e2e6d8b39320dbd56acf16aae8dd88> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [RFC PATCH v1 0/4] Add Rockchip RGA support To: Emil Velikov , =?UTF-8?Q?Heiko_St=c3=bcbner?= References: <1458552518-25527-1-git-send-email-ykk@rock-chips.com> <1867694.1mDULrSexE@phil> <13797722.SiyveTZ1bB@diego> Cc: David Airlie , Mark Yao , Joonyoung Shim , Kumar Gala , Ian Campbell , Rob Herring , Pawel Moll , Russell King , devicetree , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-rockchip , LAKML From: Yakir Yang Message-ID: <56FA6438.7060508@rock-chips.com> Date: Tue, 29 Mar 2016 19:17:12 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Emil & Heiko, On 03/29/2016 05:35 AM, Emil Velikov wrote: > On 28 March 2016 at 19:44, Heiko Stübner wrote: >> Am Montag, 28. März 2016, 13:21:02 schrieb Emil Velikov: >>> On 22 March 2016 at 00:42, Heiko Stuebner wrote: >>>> Hi Yakir, >>>> >>>> Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang: >>>>> On 03/21/2016 07:29 PM, Heiko Stübner wrote: >>>>>> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang: >>>>>>> This patch set would add the RGA direct rendering based 2d graphics >>>>>>> acceleration module. >>>>>> very cool to see that. >>>>> ;) >>>>> >>>>>>> This patch set is based on git repository below: >>>>>>> git://people.freedesktop.org/~airlied/linux drm-next >>>>>>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7 >>>>>>> >>>>>>> And the RGA driver is based on Exynos G2D driver, it only manages the >>>>>>> command lists received from user, so user should make the command list >>>>>>> to data and registers needed by operation to use. >>>>>>> >>>>>>> I have prepared an userspace demo application for testing: >>>>>>> https://github.com/yakir-Yang/libdrm-rockchip >>>>>>> >>>>>>> That is a rockchip libdrm library, and I have write a simple test case >>>>>>> "rockchip_rga_test" that would test the below RGA features: >>>>>>> - solid >>>>>>> - copy >>>>>>> - rotation >>>>>>> - flip >>>>>>> - window clip >>>>>>> - dithering >>>>>> Did you submit your libdrm changes as well? >>>>>> >>>>>> Userspace-interfaces need to be stable so the other side must also get >>>>>> accepted - even before the kernel change if I remember correctly. >>>>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm. >>>>> But I don't find the way to submit patches to libdrm, would you like >>>>> share some helps here ;) >>>> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any >>>> specific manual on submitting patches. >>>> >>>> But looking at the dri-list archive, dri-devel@lists.freedesktop.org is >>>> the >>>> right list and looking at the libdrm history it looks like Emil Velikov >>>> seems to be doing maintenance-stuff in libdrm. >>>> And as a 3rd recipient, please also include the linux-rockchip list. >>>> >>>> @Emil, please shout if I read that wrong :-) >>> You got it spot on Heiko. There are a few notes though... >>> >>> As one reuses the existing hardware/IP block, it would be better to >>> avoid copy/pasting code around. >>> Namely: >>> - (if possible) factor out the exynos g2d kernel functionality to a >>> separate kernel module and wire up the rockhip (via dt ?) to use it >>> - factor out the g2d specifics out of exynos_drm.h (into >>> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the >>> new header >> I think the IP blocks themself are quite different between Rockchip's RGA and >> Samsung's g2d and I guess the similarities are more along the lines on how >> that gets integrated into the respective drm driver and userspace. >> Yes, the hardware IP blocks is quite different. I just reference two things from Exynos g2d code: 1. UAPI side: let userspace pass the detail mode tranform register setting to kernel directly, so we don't need to pass the rendering parameters to kernel, just simplify the ioctl parameters. 2. Kernel side: reference the cmdlist manager method. Two simply task: one for collecting the userspace register setting, another start rendering process. > In this case, the exynos_g2d_drm.h seems like a good idea. As I'm > obviously biased, it's better to check how others feel on the topic. Do you mean that just create an exynos_g2d_drm.h, so both exynos_drm.h and rockchip_drm.h could include them ? It's good to reuse code, but in this case I thought it's better to keep both exist. I have try to do that, split the common 'exynos_g2d_drm.h'. But I thought it may caused some name confusion. For example, the drm rockchip code need call the EXYNOS_G2D_SET_CMDLIST ioctl to send command list. This may like drm rockchip is calling the Exynos G2D hardware, but actually it just the name conflict. Actually the head file is much simple, just contained 60 lines. So, is it okay not to split the head file, just keep the data structure define both rockchip_drm.h and exynos_drm.h >>> - if neither of these are possible, then please ensure that the new >>> header uses correct types (see the docs [1]), use MIT/X11 license (if >>> possible) and link where upstream userspace is happy with the >>> interface (ideally more than a simple test app like libdrm) >>> These might sound like an overkill, although getting UAPI right and >>> maintaining it forever forces us to do so. >> As for a real-world usecase, maybe the armsoc xserver might be somewhat easy >> to use. While the core changes I did are in the core project already, I'm >> still keeping the actual Rockchip support separate [0] due to the not-yet- >> resolved create_gem ioctl. >> >> Anyway, the armsoc xserver has some exa implementation hooks were I guess it >> might be relatively easy to hook up soc-specific things. >> > Ouch the armsoc ddx... Last time I've checked it felt like a place > where everyone is doing his own thing, with no actual reviews and/or > maintainer. Iirc most/all of it's functionality was achievable with > modesetting ddx (with or without glamor) ? I take it that things have > changed and/or I misunderstood something ? Yeah, previously I plan to add RGA support to Rockchip armsoc DDX, but seems Mark start to work on modetestting, so I may need to switch to follow him. Anyway, for now I just use libdrm to package the RGA interfaces. - Yakir > Note: The above is not meant as bashing although it hell sure looks like one. > > Cheers > Emil > >> [0] https://github.com/mmind/xf86-video-armsoc/tree/devel/rockchip >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yakir Yang Subject: Re: [RFC PATCH v1 0/4] Add Rockchip RGA support Date: Tue, 29 Mar 2016 19:17:12 +0800 Message-ID: <56FA6438.7060508@rock-chips.com> References: <1458552518-25527-1-git-send-email-ykk@rock-chips.com> <1867694.1mDULrSexE@phil> <13797722.SiyveTZ1bB@diego> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Emil Velikov , =?UTF-8?Q?Heiko_St=c3=bcbner?= Cc: devicetree , Russell King , Pawel Moll , Ian Campbell , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-rockchip , Rob Herring , Kumar Gala , LAKML List-Id: devicetree@vger.kernel.org SGkgRW1pbCAmIEhlaWtvLAoKCk9uIDAzLzI5LzIwMTYgMDU6MzUgQU0sIEVtaWwgVmVsaWtvdiB3 cm90ZToKPiBPbiAyOCBNYXJjaCAyMDE2IGF0IDE5OjQ0LCBIZWlrbyBTdMO8Ym5lciA8aGVpa29A c250ZWNoLmRlPiB3cm90ZToKPj4gQW0gTW9udGFnLCAyOC4gTcOkcnogMjAxNiwgMTM6MjE6MDIg c2NocmllYiBFbWlsIFZlbGlrb3Y6Cj4+PiBPbiAyMiBNYXJjaCAyMDE2IGF0IDAwOjQyLCBIZWlr byBTdHVlYm5lciA8aGVpa29Ac250ZWNoLmRlPiB3cm90ZToKPj4+PiBIaSBZYWtpciwKPj4+Pgo+ Pj4+IEFtIE1vbnRhZywgMjEuIE3DpHJ6IDIwMTYsIDIwOjE3OjQ2IHNjaHJpZWIgWWFraXIgWWFu ZzoKPj4+Pj4gT24gMDMvMjEvMjAxNiAwNzoyOSBQTSwgSGVpa28gU3TDvGJuZXIgd3JvdGU6Cj4+ Pj4+PiBBbSBNb250YWcsIDIxLiBNw6RyeiAyMDE2LCAxNzoyODozOCBzY2hyaWViIFlha2lyIFlh bmc6Cj4+Pj4+Pj4gVGhpcyBwYXRjaCBzZXQgd291bGQgYWRkIHRoZSBSR0EgZGlyZWN0IHJlbmRl cmluZyBiYXNlZCAyZCBncmFwaGljcwo+Pj4+Pj4+IGFjY2VsZXJhdGlvbiBtb2R1bGUuCj4+Pj4+ PiB2ZXJ5IGNvb2wgdG8gc2VlIHRoYXQuCj4+Pj4+IDspCj4+Pj4+Cj4+Pj4+Pj4gVGhpcyBwYXRj aCBzZXQgaXMgYmFzZWQgb24gZ2l0IHJlcG9zaXRvcnkgYmVsb3c6Cj4+Pj4+Pj4gZ2l0Oi8vcGVv cGxlLmZyZWVkZXNrdG9wLm9yZy9+YWlybGllZC9saW51eCBkcm0tbmV4dAo+Pj4+Pj4+IGNvbW1p dCBpZDogNTY4ZDdjNzY0YWUwMWYzNzA2MDg1YWM4ZjBkOGE4YWM3ZTgyNmJkNwo+Pj4+Pj4+Cj4+ Pj4+Pj4gQW5kIHRoZSBSR0EgZHJpdmVyIGlzIGJhc2VkIG9uIEV4eW5vcyBHMkQgZHJpdmVyLCBp dCBvbmx5IG1hbmFnZXMgdGhlCj4+Pj4+Pj4gY29tbWFuZCBsaXN0cyByZWNlaXZlZCBmcm9tIHVz ZXIsIHNvIHVzZXIgc2hvdWxkIG1ha2UgdGhlIGNvbW1hbmQgbGlzdAo+Pj4+Pj4+IHRvIGRhdGEg YW5kIHJlZ2lzdGVycyBuZWVkZWQgYnkgb3BlcmF0aW9uIHRvIHVzZS4KPj4+Pj4+Pgo+Pj4+Pj4+ IEkgaGF2ZSBwcmVwYXJlZCBhbiB1c2Vyc3BhY2UgZGVtbyBhcHBsaWNhdGlvbiBmb3IgdGVzdGlu ZzoKPj4+Pj4+PiAgICAgaHR0cHM6Ly9naXRodWIuY29tL3lha2lyLVlhbmcvbGliZHJtLXJvY2tj aGlwCj4+Pj4+Pj4KPj4+Pj4+PiBUaGF0IGlzIGEgcm9ja2NoaXAgbGliZHJtIGxpYnJhcnksIGFu ZCBJIGhhdmUgd3JpdGUgYSBzaW1wbGUgdGVzdCBjYXNlCj4+Pj4+Pj4gInJvY2tjaGlwX3JnYV90 ZXN0IiB0aGF0IHdvdWxkIHRlc3QgdGhlIGJlbG93IFJHQSBmZWF0dXJlczoKPj4+Pj4+PiAtIHNv bGlkCj4+Pj4+Pj4gLSBjb3B5Cj4+Pj4+Pj4gLSByb3RhdGlvbgo+Pj4+Pj4+IC0gZmxpcAo+Pj4+ Pj4+IC0gd2luZG93IGNsaXAKPj4+Pj4+PiAtIGRpdGhlcmluZwo+Pj4+Pj4gRGlkIHlvdSBzdWJt aXQgeW91ciBsaWJkcm0gY2hhbmdlcyBhcyB3ZWxsPwo+Pj4+Pj4KPj4+Pj4+IFVzZXJzcGFjZS1p bnRlcmZhY2VzIG5lZWQgdG8gYmUgc3RhYmxlIHNvIHRoZSBvdGhlciBzaWRlIG11c3QgYWxzbyBn ZXQKPj4+Pj4+IGFjY2VwdGVkIC0gZXZlbiBiZWZvcmUgdGhlIGtlcm5lbCBjaGFuZ2UgaWYgSSBy ZW1lbWJlciBjb3JyZWN0bHkuCj4+Pj4+IEdvdCBpdCwgYW5kIEkganVzdCBzYXcgZXh5bm9zX2Zp bWcyZCBhbHJlYWR5IGxhbmRlZCBhdCBtYWlubGluZSBsaWJkcm0uCj4+Pj4+IEJ1dCBJIGRvbid0 IGZpbmQgdGhlIHdheSB0byBzdWJtaXQgcGF0Y2hlcyB0byBsaWJkcm0sIHdvdWxkIHlvdSBsaWtl Cj4+Pj4+IHNoYXJlIHNvbWUgaGVscHMgaGVyZSA7KQo+Pj4+IExvb2tpbmcgYXQgdGhlIGxpYmRy bSBzb3VyY2VzIG9uIGNnaXQuZnJlZWRlc2t0b3Aub3JnLCBJIGRpZCBub3QgZmluZCBhbnkKPj4+ PiBzcGVjaWZpYyBtYW51YWwgb24gc3VibWl0dGluZyBwYXRjaGVzLgo+Pj4+Cj4+Pj4gQnV0IGxv b2tpbmcgYXQgdGhlIGRyaS1saXN0IGFyY2hpdmUsIGRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3Rv cC5vcmcgaXMKPj4+PiB0aGUKPj4+PiByaWdodCBsaXN0IGFuZCBsb29raW5nIGF0IHRoZSBsaWJk cm0gaGlzdG9yeSBpdCBsb29rcyBsaWtlIEVtaWwgVmVsaWtvdgo+Pj4+IDxlbWlsLmwudmVsaWtv dkBnbWFpbC5jb20+IHNlZW1zIHRvIGJlIGRvaW5nIG1haW50ZW5hbmNlLXN0dWZmIGluIGxpYmRy bS4KPj4+PiBBbmQgYXMgYSAzcmQgcmVjaXBpZW50LCBwbGVhc2UgYWxzbyBpbmNsdWRlIHRoZSBs aW51eC1yb2NrY2hpcCBsaXN0Lgo+Pj4+Cj4+Pj4gQEVtaWwsIHBsZWFzZSBzaG91dCBpZiBJIHJl YWQgdGhhdCB3cm9uZyA6LSkKPj4+IFlvdSBnb3QgaXQgc3BvdCBvbiBIZWlrby4gVGhlcmUgYXJl IGEgZmV3IG5vdGVzIHRob3VnaC4uLgo+Pj4KPj4+IEFzIG9uZSByZXVzZXMgdGhlIGV4aXN0aW5n IGhhcmR3YXJlL0lQIGJsb2NrLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8KPj4+IGF2b2lkIGNvcHkv cGFzdGluZyBjb2RlIGFyb3VuZC4KPj4+IE5hbWVseToKPj4+ICAgLSAoaWYgcG9zc2libGUpIGZh Y3RvciBvdXQgdGhlIGV4eW5vcyBnMmQga2VybmVsIGZ1bmN0aW9uYWxpdHkgdG8gYQo+Pj4gc2Vw YXJhdGUga2VybmVsIG1vZHVsZSBhbmQgd2lyZSB1cCB0aGUgcm9ja2hpcCAodmlhIGR0ID8pIHRv IHVzZSBpdAo+Pj4gICAtIGZhY3RvciBvdXQgdGhlIGcyZCBzcGVjaWZpY3Mgb3V0IG9mIGV4eW5v c19kcm0uaCAoaW50bwo+Pj4gZXh5bm9zX2cyZF9kcm0uaCBwZXJoYXBzID8pIGFuZCBtYWtlIHN1 cmUgZXh5bm9zX2RybS5oIGluY2x1ZGVzIHRoZQo+Pj4gbmV3IGhlYWRlcgo+PiBJIHRoaW5rIHRo ZSBJUCBibG9ja3MgdGhlbXNlbGYgYXJlIHF1aXRlIGRpZmZlcmVudCBiZXR3ZWVuIFJvY2tjaGlw J3MgUkdBIGFuZAo+PiBTYW1zdW5nJ3MgZzJkIGFuZCBJIGd1ZXNzIHRoZSBzaW1pbGFyaXRpZXMg YXJlIG1vcmUgYWxvbmcgdGhlIGxpbmVzIG9uIGhvdwo+PiB0aGF0IGdldHMgaW50ZWdyYXRlZCBp bnRvIHRoZSByZXNwZWN0aXZlIGRybSBkcml2ZXIgYW5kIHVzZXJzcGFjZS4KPj4KClllcywgdGhl IGhhcmR3YXJlIElQIGJsb2NrcyBpcyBxdWl0ZSBkaWZmZXJlbnQuIEkganVzdCByZWZlcmVuY2Ug dHdvIHRoaW5ncwpmcm9tIEV4eW5vcyBnMmQgY29kZToKMS4gVUFQSSBzaWRlOiBsZXQgdXNlcnNw YWNlIHBhc3MgdGhlIGRldGFpbCBtb2RlIHRyYW5mb3JtIHJlZ2lzdGVyIHNldHRpbmcKICAgICB0 byBrZXJuZWwgZGlyZWN0bHksIHNvIHdlIGRvbid0IG5lZWQgdG8gcGFzcyB0aGUgcmVuZGVyaW5n IApwYXJhbWV0ZXJzIHRvCiAgICAga2VybmVsLCBqdXN0IHNpbXBsaWZ5IHRoZSBpb2N0bCBwYXJh bWV0ZXJzLgoKMi4gS2VybmVsIHNpZGU6IHJlZmVyZW5jZSB0aGUgY21kbGlzdCBtYW5hZ2VyIG1l dGhvZC4gVHdvIHNpbXBseSB0YXNrOiBvbmUKICAgICBmb3IgY29sbGVjdGluZyB0aGUgdXNlcnNw YWNlIHJlZ2lzdGVyIHNldHRpbmcsIGFub3RoZXIgc3RhcnQgCnJlbmRlcmluZyBwcm9jZXNzLgoK PiBJbiB0aGlzIGNhc2UsIHRoZSBleHlub3NfZzJkX2RybS5oIHNlZW1zIGxpa2UgYSBnb29kIGlk ZWEuIEFzIEknbQo+IG9idmlvdXNseSBiaWFzZWQsIGl0J3MgYmV0dGVyIHRvIGNoZWNrIGhvdyBv dGhlcnMgZmVlbCBvbiB0aGUgdG9waWMuCgpEbyB5b3UgbWVhbiB0aGF0IGp1c3QgY3JlYXRlIGFu IGV4eW5vc19nMmRfZHJtLmgsIHNvIGJvdGggZXh5bm9zX2RybS5oCmFuZCByb2NrY2hpcF9kcm0u aCBjb3VsZCBpbmNsdWRlIHRoZW0gPyBJdCdzIGdvb2QgdG8gcmV1c2UgY29kZSwgYnV0IGluIHRo aXMKY2FzZSBJIHRob3VnaHQgaXQncyBiZXR0ZXIgdG8ga2VlcCBib3RoIGV4aXN0LgoKSSBoYXZl IHRyeSB0byBkbyB0aGF0LCBzcGxpdCB0aGUgY29tbW9uICdleHlub3NfZzJkX2RybS5oJy4gQnV0 IEkgCnRob3VnaHQgaXQgbWF5CmNhdXNlZCBzb21lIG5hbWUgY29uZnVzaW9uLiBGb3IgZXhhbXBs ZSwgdGhlIGRybSByb2NrY2hpcCBjb2RlIG5lZWQgY2FsbCB0aGUKRVhZTk9TX0cyRF9TRVRfQ01E TElTVCBpb2N0bCB0byBzZW5kIGNvbW1hbmQgbGlzdC4gVGhpcyBtYXkgbGlrZSBkcm0gCnJvY2tj aGlwCmlzIGNhbGxpbmcgdGhlIEV4eW5vcyBHMkQgaGFyZHdhcmUsIGJ1dCBhY3R1YWxseSBpdCBq dXN0IHRoZSBuYW1lIGNvbmZsaWN0LgoKQWN0dWFsbHkgdGhlIGhlYWQgZmlsZSBpcyBtdWNoIHNp bXBsZSwganVzdCBjb250YWluZWQgNjAgbGluZXMuCgpTbywgaXMgaXQgb2theSBub3QgdG8gc3Bs aXQgdGhlIGhlYWQgZmlsZSwganVzdCBrZWVwIHRoZSBkYXRhIHN0cnVjdHVyZSAKZGVmaW5lIGJv dGgKcm9ja2NoaXBfZHJtLmggYW5kIGV4eW5vc19kcm0uaAoKPj4+ICAgLSBpZiBuZWl0aGVyIG9m IHRoZXNlIGFyZSBwb3NzaWJsZSwgdGhlbiBwbGVhc2UgZW5zdXJlIHRoYXQgdGhlIG5ldwo+Pj4g aGVhZGVyIHVzZXMgY29ycmVjdCB0eXBlcyAoc2VlIHRoZSBkb2NzIFsxXSksIHVzZSBNSVQvWDEx IGxpY2Vuc2UgKGlmCj4+PiBwb3NzaWJsZSkgYW5kIGxpbmsgd2hlcmUgdXBzdHJlYW0gdXNlcnNw YWNlIGlzIGhhcHB5IHdpdGggdGhlCj4+PiBpbnRlcmZhY2UgKGlkZWFsbHkgbW9yZSB0aGFuIGEg c2ltcGxlIHRlc3QgYXBwIGxpa2UgbGliZHJtKQo+Pj4gVGhlc2UgbWlnaHQgc291bmQgbGlrZSBh biBvdmVya2lsbCwgYWx0aG91Z2ggZ2V0dGluZyBVQVBJIHJpZ2h0IGFuZAo+Pj4gbWFpbnRhaW5p bmcgaXQgZm9yZXZlciBmb3JjZXMgdXMgdG8gZG8gc28uCj4+IEFzIGZvciBhIHJlYWwtd29ybGQg dXNlY2FzZSwgbWF5YmUgdGhlIGFybXNvYyB4c2VydmVyIG1pZ2h0IGJlIHNvbWV3aGF0IGVhc3kK Pj4gdG8gdXNlLiBXaGlsZSB0aGUgY29yZSBjaGFuZ2VzIEkgZGlkIGFyZSBpbiB0aGUgY29yZSBw cm9qZWN0IGFscmVhZHksIEknbQo+PiBzdGlsbCBrZWVwaW5nIHRoZSBhY3R1YWwgUm9ja2NoaXAg c3VwcG9ydCBzZXBhcmF0ZSBbMF0gZHVlIHRvIHRoZSBub3QteWV0LQo+PiByZXNvbHZlZCBjcmVh dGVfZ2VtIGlvY3RsLgo+Pgo+PiBBbnl3YXksIHRoZSBhcm1zb2MgeHNlcnZlciBoYXMgc29tZSBl eGEgaW1wbGVtZW50YXRpb24gaG9va3Mgd2VyZSBJIGd1ZXNzIGl0Cj4+IG1pZ2h0IGJlIHJlbGF0 aXZlbHkgZWFzeSB0byBob29rIHVwIHNvYy1zcGVjaWZpYyB0aGluZ3MuCj4+Cj4gT3VjaCB0aGUg YXJtc29jIGRkeC4uLiBMYXN0IHRpbWUgSSd2ZSBjaGVja2VkIGl0IGZlbHQgbGlrZSBhIHBsYWNl Cj4gd2hlcmUgZXZlcnlvbmUgaXMgZG9pbmcgaGlzIG93biB0aGluZywgd2l0aCBubyBhY3R1YWwg cmV2aWV3cyBhbmQvb3IKPiBtYWludGFpbmVyLiBJaXJjIG1vc3QvYWxsIG9mIGl0J3MgZnVuY3Rp b25hbGl0eSB3YXMgYWNoaWV2YWJsZSB3aXRoCj4gbW9kZXNldHRpbmcgZGR4ICh3aXRoIG9yIHdp dGhvdXQgZ2xhbW9yKSA/IEkgdGFrZSBpdCB0aGF0IHRoaW5ncyBoYXZlCj4gY2hhbmdlZCBhbmQv b3IgSSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZyA/CgpZZWFoLCBwcmV2aW91c2x5IEkgcGxhbiB0 byBhZGQgUkdBIHN1cHBvcnQgdG8gUm9ja2NoaXAgYXJtc29jIEREWCwgYnV0CnNlZW1zIE1hcmsg c3RhcnQgdG8gd29yayBvbiBtb2RldGVzdHRpbmcsIHNvIEkgbWF5IG5lZWQgdG8gc3dpdGNoIHRv CmZvbGxvdyBoaW0uCgpBbnl3YXksIGZvciBub3cgSSBqdXN0IHVzZSBsaWJkcm0gdG8gcGFja2Fn ZSB0aGUgUkdBIGludGVyZmFjZXMuCgotIFlha2lyCgo+IE5vdGU6IFRoZSBhYm92ZSBpcyBub3Qg bWVhbnQgYXMgYmFzaGluZyBhbHRob3VnaCBpdCBoZWxsIHN1cmUgbG9va3MgbGlrZSBvbmUuCj4K PiBDaGVlcnMKPiBFbWlsCj4KPj4gWzBdIGh0dHBzOi8vZ2l0aHViLmNvbS9tbWluZC94Zjg2LXZp ZGVvLWFybXNvYy90cmVlL2RldmVsL3JvY2tjaGlwCj4+Cj4KPgoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: ykk@rock-chips.com (Yakir Yang) Date: Tue, 29 Mar 2016 19:17:12 +0800 Subject: [RFC PATCH v1 0/4] Add Rockchip RGA support In-Reply-To: References: <1458552518-25527-1-git-send-email-ykk@rock-chips.com> <1867694.1mDULrSexE@phil> <13797722.SiyveTZ1bB@diego> Message-ID: <56FA6438.7060508@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Emil & Heiko, On 03/29/2016 05:35 AM, Emil Velikov wrote: > On 28 March 2016 at 19:44, Heiko St?bner wrote: >> Am Montag, 28. M?rz 2016, 13:21:02 schrieb Emil Velikov: >>> On 22 March 2016 at 00:42, Heiko Stuebner wrote: >>>> Hi Yakir, >>>> >>>> Am Montag, 21. M?rz 2016, 20:17:46 schrieb Yakir Yang: >>>>> On 03/21/2016 07:29 PM, Heiko St?bner wrote: >>>>>> Am Montag, 21. M?rz 2016, 17:28:38 schrieb Yakir Yang: >>>>>>> This patch set would add the RGA direct rendering based 2d graphics >>>>>>> acceleration module. >>>>>> very cool to see that. >>>>> ;) >>>>> >>>>>>> This patch set is based on git repository below: >>>>>>> git://people.freedesktop.org/~airlied/linux drm-next >>>>>>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7 >>>>>>> >>>>>>> And the RGA driver is based on Exynos G2D driver, it only manages the >>>>>>> command lists received from user, so user should make the command list >>>>>>> to data and registers needed by operation to use. >>>>>>> >>>>>>> I have prepared an userspace demo application for testing: >>>>>>> https://github.com/yakir-Yang/libdrm-rockchip >>>>>>> >>>>>>> That is a rockchip libdrm library, and I have write a simple test case >>>>>>> "rockchip_rga_test" that would test the below RGA features: >>>>>>> - solid >>>>>>> - copy >>>>>>> - rotation >>>>>>> - flip >>>>>>> - window clip >>>>>>> - dithering >>>>>> Did you submit your libdrm changes as well? >>>>>> >>>>>> Userspace-interfaces need to be stable so the other side must also get >>>>>> accepted - even before the kernel change if I remember correctly. >>>>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm. >>>>> But I don't find the way to submit patches to libdrm, would you like >>>>> share some helps here ;) >>>> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any >>>> specific manual on submitting patches. >>>> >>>> But looking at the dri-list archive, dri-devel at lists.freedesktop.org is >>>> the >>>> right list and looking at the libdrm history it looks like Emil Velikov >>>> seems to be doing maintenance-stuff in libdrm. >>>> And as a 3rd recipient, please also include the linux-rockchip list. >>>> >>>> @Emil, please shout if I read that wrong :-) >>> You got it spot on Heiko. There are a few notes though... >>> >>> As one reuses the existing hardware/IP block, it would be better to >>> avoid copy/pasting code around. >>> Namely: >>> - (if possible) factor out the exynos g2d kernel functionality to a >>> separate kernel module and wire up the rockhip (via dt ?) to use it >>> - factor out the g2d specifics out of exynos_drm.h (into >>> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the >>> new header >> I think the IP blocks themself are quite different between Rockchip's RGA and >> Samsung's g2d and I guess the similarities are more along the lines on how >> that gets integrated into the respective drm driver and userspace. >> Yes, the hardware IP blocks is quite different. I just reference two things from Exynos g2d code: 1. UAPI side: let userspace pass the detail mode tranform register setting to kernel directly, so we don't need to pass the rendering parameters to kernel, just simplify the ioctl parameters. 2. Kernel side: reference the cmdlist manager method. Two simply task: one for collecting the userspace register setting, another start rendering process. > In this case, the exynos_g2d_drm.h seems like a good idea. As I'm > obviously biased, it's better to check how others feel on the topic. Do you mean that just create an exynos_g2d_drm.h, so both exynos_drm.h and rockchip_drm.h could include them ? It's good to reuse code, but in this case I thought it's better to keep both exist. I have try to do that, split the common 'exynos_g2d_drm.h'. But I thought it may caused some name confusion. For example, the drm rockchip code need call the EXYNOS_G2D_SET_CMDLIST ioctl to send command list. This may like drm rockchip is calling the Exynos G2D hardware, but actually it just the name conflict. Actually the head file is much simple, just contained 60 lines. So, is it okay not to split the head file, just keep the data structure define both rockchip_drm.h and exynos_drm.h >>> - if neither of these are possible, then please ensure that the new >>> header uses correct types (see the docs [1]), use MIT/X11 license (if >>> possible) and link where upstream userspace is happy with the >>> interface (ideally more than a simple test app like libdrm) >>> These might sound like an overkill, although getting UAPI right and >>> maintaining it forever forces us to do so. >> As for a real-world usecase, maybe the armsoc xserver might be somewhat easy >> to use. While the core changes I did are in the core project already, I'm >> still keeping the actual Rockchip support separate [0] due to the not-yet- >> resolved create_gem ioctl. >> >> Anyway, the armsoc xserver has some exa implementation hooks were I guess it >> might be relatively easy to hook up soc-specific things. >> > Ouch the armsoc ddx... Last time I've checked it felt like a place > where everyone is doing his own thing, with no actual reviews and/or > maintainer. Iirc most/all of it's functionality was achievable with > modesetting ddx (with or without glamor) ? I take it that things have > changed and/or I misunderstood something ? Yeah, previously I plan to add RGA support to Rockchip armsoc DDX, but seems Mark start to work on modetestting, so I may need to switch to follow him. Anyway, for now I just use libdrm to package the RGA interfaces. - Yakir > Note: The above is not meant as bashing although it hell sure looks like one. > > Cheers > Emil > >> [0] https://github.com/mmind/xf86-video-armsoc/tree/devel/rockchip >> > >