Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753233AbcDEBNp (ORCPT ); Mon, 4 Apr 2016 21:13:45 -0400 Received: from regular1.263xmail.com ([211.150.99.137]:52860 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752172AbcDEBNn (ORCPT ); Mon, 4 Apr 2016 21:13:43 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-KSVirus-check: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <5368e62aca0edd0cee5efc37050f38d2> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <57031138.7020408@rock-chips.com> Date: Tue, 05 Apr 2016 09:13:28 +0800 From: Mark yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Emil Velikov , =?UTF-8?B?SGVpa28gU3TDvGJuZXI=?= CC: Yakir Yang , David Airlie , Joonyoung Shim , Kumar Gala , Ian Campbell , Rob Herring , Pawel Moll , Russell King , devicetree , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-rockchip , LAKML Subject: Re: [RFC PATCH v1 0/4] Add Rockchip RGA support References: <1458552518-25527-1-git-send-email-ykk@rock-chips.com> <1571169.Hy8an0n7lM@diego> <17189219.y56YqHz6yR@diego> 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 Content-Length: 2287 Lines: 59 On 2016年03月31日 04:03, Emil Velikov wrote: > On 29 March 2016 at 14:13, Emil Velikov wrote: >> On 28 March 2016 at 23:13, Heiko Stübner wrote: >> >>> I have the feeling we're going quite a bit off-topic right now :-) . >>> The binary-driver-crazyness, hasn't really anything to do with Yakir's support >>> for the RGA (which is about raster-graphics-acceleration, so 2d stuff). >>> >>> And me mentioning the armsoc-ddx was merely a means to allow some sort of >>> different userspace user, as requested in your original mail ;-) . >>> >> Seems like I forgot to state the obvious - for all the reasons >> mentioned, the armsoc ddx seems like a bad example. >> >>> Maybe you know a better use-case on where to demonstrate the viability of the >>> userspace API for it as originally requested. >> I'm afraid that my RockChip-foo is extremely limited. Perhaps the >> actual user of these should be mentioned ? xf86-video-rockhip (is >> there one ?) or any other effort/project that lacks some (all?) of the >> criticism listed. >> >> (Sort of) the bottom line - either reuse the existing interfaces or >> provide an approved, full blown userspace (libdrm demos/programs do >> not count) that uses the new interfaces. >> >> I haven't made these rules, just a fool^Wguy that repeats them so that >> people don't abuse them much. If in doubt check with Dave and Daniel V >> - they had enough repeating these. >> > I can see how my earlier response may have been come > across/interpreted as aggressive and/or demanding. Apologies anyone > got upset/annoyed. > > Let me try in another light - if you guys are willing to have > xf86-video-rockchip or keep track of/co-maintain armsoc, pretty much > everyone will be over the moon. Personally I'd opt for the former, > taking the modesetting (the one in the xserver tree) as a base - it > has all the cool new bits ;-) > > Regards, > Emil > > > I'd like to use modesetting more than armsoc. the modesetting seems more stable and it support glamor(2d acceleration with gpu). We have some work on modesetting ddx, with some hack, both 3d dri2 and glamor 2d acceleration can works with mali gpu. So if Yakir want to support EXA on ddx, I hope he can use modesetting. Thanks. -- Ｍark Yao