From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751713AbcGROPa (ORCPT ); Mon, 18 Jul 2016 10:15:30 -0400 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49]:46886 "EHLO s-opensource.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbcGROP2 (ORCPT ); Mon, 18 Jul 2016 10:15:28 -0400 Subject: Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf To: Hans Verkuil , linux-kernel@vger.kernel.org References: <1468599966-31988-1-git-send-email-javier@osg.samsung.com> From: Javier Martinez Canillas Cc: Marek Szyprowski , Mauro Carvalho Chehab , Kyungmin Park , Pawel Osciak , linux-media@vger.kernel.org, Shuah Khan , Nicolas Dufresne , Luis de Bethencourt , m.olbrich@pengutronix.de Message-ID: Date: Mon, 18 Jul 2016 10:15:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Hans, Michael and Marek, Thanks a lot for your feedback. On 07/18/2016 04:34 AM, Hans Verkuil wrote: > On 07/15/2016 06:26 PM, Javier Martinez Canillas wrote: >> The buffer planes' dma-buf are currently mapped when buffers are queued >> from userspace but it's more appropriate to do the mapping when buffers >> are queued in the driver since that's when the actual DMA operation are >> going to happen. > > Does this solve anything? Once the DMA has started the behavior is the same > as before (QBUF maps the dmabuf), only while the DMA engine hasn't started > yet are the QBUF calls just accepted and the mapping takes place when the > DMA is kickstarted. This makes QBUF behave inconsistently. > > You don't describe here WHY this change is needed. > Nicolas pointed me to the TODO and suggested me the patch for the reasons he explained in his latest email. And yes, this should had been tagged as a RFC and just to know what you think about it. Sorry for missing that. > I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree > with this solution. Since queuing the buffer to the driver is not the same > as 'just before the DMA', since there may be many buffers queued up in the > driver and you don't know in vb2 when the buffer is at the 'just before the DMA' > stage. > Right, I meant "as closer as possible to when the actual DMA is going to happen" rather than "just before the DMA". > Regards, > > Hans > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America