From mboxrd@z Thu Jan 1 00:00:00 1970 From: robdclark@gmail.com (Rob Clark) Date: Mon, 10 Jun 2013 19:35:23 -0400 Subject: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver In-Reply-To: References: <20130609190612.GM18614@n2100.arm.linux.org.uk> <20130610170648.GX18614@n2100.arm.linux.org.uk> <20130610200839.GY18614@n2100.arm.linux.org.uk> <20130610211516.GZ18614@n2100.arm.linux.org.uk> <20130610225607.GE18614@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote: >>> >>> That makes the driver just be a dumb scanout only driver. Sorry, >>> that *really* does not interest me one bit, because the CPU doing >>> framebuffer accesses is pig slow. >> >> Well, yes that is basically what I am saying, unless we can find a >> different way (dmabuf? if there is some way to pass it through the >> blob bits you don't have src code for?) >> >> The problem is that we really can't merge something upstream that lets >> you dma to arbitrary physical address. Maybe in staging, perhaps? Or >> otherwise if there is no other way, I hope someone will at least pick >> up the modesetting parts of it and get that merged upstream. The rest >> of the driver is looking pretty good, and I think it would be useful >> to have upstream. > > Totally what he said. > > upstream shouldn't be restricted by the bad decisions of others, and > adding security bypasses is one of them. > > I'd like to see all the ARM based drivers based on CMA if it can meet > their requirements afaiu CMA has issues w/ changing cache attributes of pages on older architectures like Russell is using. Although perhaps on older arm CMA should just be a straight carveout pool and not try to recycle the unused pages. At least then it would be the same API for the drivers. BR, -R > and using close to standard GEM/dma-buf interfaces. Otherwise it'll be > come an unmaintainable > nightmare for everyone, but mostly for me. > > Merging the base dumb KMS driver, then working out acceptable ways to > provide the extra > features is definitely the nicest way to do things. > > Dave. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Date: Mon, 10 Jun 2013 19:35:23 -0400 Message-ID: References: <20130609190612.GM18614@n2100.arm.linux.org.uk> <20130610170648.GX18614@n2100.arm.linux.org.uk> <20130610200839.GY18614@n2100.arm.linux.org.uk> <20130610211516.GZ18614@n2100.arm.linux.org.uk> <20130610225607.GE18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Dave Airlie Cc: linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux , Jason Cooper , dri-devel@lists.freedesktop.org, Sebastian Hesselbarth List-Id: dri-devel@lists.freedesktop.org On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote: >>> >>> That makes the driver just be a dumb scanout only driver. Sorry, >>> that *really* does not interest me one bit, because the CPU doing >>> framebuffer accesses is pig slow. >> >> Well, yes that is basically what I am saying, unless we can find a >> different way (dmabuf? if there is some way to pass it through the >> blob bits you don't have src code for?) >> >> The problem is that we really can't merge something upstream that lets >> you dma to arbitrary physical address. Maybe in staging, perhaps? Or >> otherwise if there is no other way, I hope someone will at least pick >> up the modesetting parts of it and get that merged upstream. The rest >> of the driver is looking pretty good, and I think it would be useful >> to have upstream. > > Totally what he said. > > upstream shouldn't be restricted by the bad decisions of others, and > adding security bypasses is one of them. > > I'd like to see all the ARM based drivers based on CMA if it can meet > their requirements afaiu CMA has issues w/ changing cache attributes of pages on older architectures like Russell is using. Although perhaps on older arm CMA should just be a straight carveout pool and not try to recycle the unused pages. At least then it would be the same API for the drivers. BR, -R > and using close to standard GEM/dma-buf interfaces. Otherwise it'll be > come an unmaintainable > nightmare for everyone, but mostly for me. > > Merging the base dumb KMS driver, then working out acceptable ways to > provide the extra > features is definitely the nicest way to do things. > > Dave.