From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65B56C47095 for ; Wed, 7 Oct 2020 12:01:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1219E207EA for ; Wed, 7 Oct 2020 12:01:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PyaZ/nvZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728081AbgJGMB5 (ORCPT ); Wed, 7 Oct 2020 08:01:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727861AbgJGMB4 (ORCPT ); Wed, 7 Oct 2020 08:01:56 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F2A1C061755 for ; Wed, 7 Oct 2020 05:01:56 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id e20so1457920otj.11 for ; Wed, 07 Oct 2020 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=PyaZ/nvZm2QUtaJTzV68PXra5E6nusMzfq2GtX+T4KHdWVm++EJydv/8XaGh5nYPu2 kpLCfkP523at8+kzTLYGiJF/U5HARJ4ZwyhXlTfgO1W6ZvOLzle/fawTahYRmxpmawyG M2mKVfCZhp95638KHshmfZX9XnDxeTLsbzpOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=rvan7UWo6qxnwgXKiEy/ewoatI6xJEfWfI7Zw8tE0JeoYBMgYbDV1RvgYY9TzvnV88 Ca/4WQI+0w4r5ZYMggTmxtBlOTnXFay6/F0qulAEY3tAitRGDbuyMA6w1CBxstssYiKd L3JILj35cniYqWlbR7V3aOprJTU6/vP3bm6y71Yf2cz2pc1h0c74/LVWqz1uCFQK7L+U m1IaQg8iXjj6egMby5yle5xJ1F5btHgKZTMTOLaFHtgsiHbB6vI80ICC3ft5scgsa3aA q9yhn59j1catJjD9Xn3o3CvXdiit+jCgk0c7riGYtEUIQ8r32KSELr8V7Kkql8CW70Ol srSA== X-Gm-Message-State: AOAM5325HFk6Ug/H9b2atgxSlMSMajr4UySRIp6QaOIhzuL3wse23Ti4 1mqFgdV9wTjTb1psb7lKKNnVdm0RDOMTt8EgHLwoDw== X-Google-Smtp-Source: ABdhPJwz1+Mjs5/TsMc3YtWSj3uN1hN+EFq4HjqQKny0ZO2DNmwXaAg21800jfJ4gXIzTu9U81dtoIfG8VEkup1Khs8= X-Received: by 2002:a05:6830:1c3c:: with SMTP id f28mr1747283ote.188.1602072115550; Wed, 07 Oct 2020 05:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Wed, 7 Oct 2020 14:01:44 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Marek Szyprowski Cc: Jason Gunthorpe , DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams , Linux MM , Linux ARM , Pawel Osciak , Kyungmin Park , Tomasz Figa , Inki Dae , Joonyoung Shim , Seung-Woo Kim , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Oded Gabbay Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 7, 2020 at 12:47 PM Marek Szyprowski wrote: > > Hi Daniel, > > On 03.10.2020 11:40, Daniel Vetter wrote: > >> After he three places above should use pin_user_pages_fast(), then > >> this whole broken API should be moved into videobuf2-memops.c and a > >> big fat "THIS DOESN'T WORK" stuck on it. > >> > >> videobuf2 should probably use P2P DMA buf for this instead. > > Yup this should be done with dma_buf instead, and v4l has that. > > Yes, V4L2 has dma_buf support NOW. That days, using so called V4L2 > USERPTR method was the only way to achieve zero copy buffer sharing > between devices, so this is just a historical baggage. I've been > actively involved in implementing that. I've tried to make it secure as > much as possible assuming the limitation of that approach. With a few > assumptions it works fine. Buffers are refcounted both by the > vm_ops->open or by incrementing the refcount of the vm->file. This > basically works with any sane driver, which doesn't free the mmaped > buffer until the file is released. This is true for V4L2 and FBdev devices. I'm not seeing any of that vm->file refcounting going on, so not seeing anything that prevents the mmap area from being removed. Can you pls give me some pointers about which code you're thinking of? -Daniel > This API is considered as deprecated in V4L2 world, so I think > supporting this hack can be removed one day as nowadays userspace should > use dma buf. > > > ... > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94433C4363D for ; Wed, 7 Oct 2020 12:03:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 26D4720782 for ; Wed, 7 Oct 2020 12:03:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QLBeZUKo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PyaZ/nvZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26D4720782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EuDkfCfnOP/a/VLkoJUopqdko3pEMf0SE645N78u+j4=; b=QLBeZUKoUtOReSgKOLOT7GQ6V k8RT3t0TKBL/Gean8eXZo3jTBI3StgD/7GtuW5oQ8tjlKzVm4J4UIhqB77t60voXuqBBqacLLAZfP wvtscSG2z0GpgZ7755yWZFBE0lauWSVtiJR1i/0d4JWekr6GkpRb1IDfwKYa3BkxfcbkgMmr1w30Z mcz9hZUEPBX5gSaR5Q1lSLYAV1S+pFMLaCccbQkKlrx+yek74CionAbOkyXK045hPqBU16v+PA5Vg 5YfryKWAV+p92vjRaorHrFToZd8qe/DIFXoQsJ6mgQFALeX/kvAgoYLTb5YuGV2vSWiZ1oBw5LyVl i88ny0eHQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ88w-0006Ro-Un; Wed, 07 Oct 2020 12:02:03 +0000 Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ88t-0006QE-H5 for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2020 12:02:00 +0000 Received: by mail-ot1-x343.google.com with SMTP id 60so1933169otw.3 for ; Wed, 07 Oct 2020 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=PyaZ/nvZm2QUtaJTzV68PXra5E6nusMzfq2GtX+T4KHdWVm++EJydv/8XaGh5nYPu2 kpLCfkP523at8+kzTLYGiJF/U5HARJ4ZwyhXlTfgO1W6ZvOLzle/fawTahYRmxpmawyG M2mKVfCZhp95638KHshmfZX9XnDxeTLsbzpOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=RF11/ILubry14AuOnFjwQjVZ4eQ5P1w6asOhR+ja462dWXrLu3mlpMlELQmcGLWtMf 0seBlrRPNgoE9vdsNKFc72wnTjzyjSV6pXGYGzCD/+/kDIj4HXcFS3UU2nbEWtHrfbYR BmTUw07QVQM2nsRbWHdis+aPmuAl9g1WFlD35HiJG0CPwjrl+6bs1PoXd8pXRkj6Fi+1 PuPfmFNcNUV0kT4C2TLJFC8TvPaEDYL5sXguC4lZ6+XbDKYIyk8OcLgwYyoCZuwdlHJN II1POGaU4xq9UJx/oI5dTF7d1YnpW53df4crXg1gNLk2T0m8tNzwbDG6HvqA5hs8KpU9 KefA== X-Gm-Message-State: AOAM533BZKwHTBw5VFrmqExrDqUso69gEY4ocgrOX8FwR6uZ5AMpd62S 6D7xNB/fOF2CcOSgx5nLr6+Lhn50ZD3po/RqwqkZCg== X-Google-Smtp-Source: ABdhPJwz1+Mjs5/TsMc3YtWSj3uN1hN+EFq4HjqQKny0ZO2DNmwXaAg21800jfJ4gXIzTu9U81dtoIfG8VEkup1Khs8= X-Received: by 2002:a05:6830:1c3c:: with SMTP id f28mr1747283ote.188.1602072115550; Wed, 07 Oct 2020 05:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Wed, 7 Oct 2020 14:01:44 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Marek Szyprowski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201007_080159_598138_D54037F9 X-CRM114-Status: GOOD ( 21.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Oded Gabbay , Inki Dae , linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , Linux MM , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Andrew Morton , Dan Williams , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 7, 2020 at 12:47 PM Marek Szyprowski wrote: > > Hi Daniel, > > On 03.10.2020 11:40, Daniel Vetter wrote: > >> After he three places above should use pin_user_pages_fast(), then > >> this whole broken API should be moved into videobuf2-memops.c and a > >> big fat "THIS DOESN'T WORK" stuck on it. > >> > >> videobuf2 should probably use P2P DMA buf for this instead. > > Yup this should be done with dma_buf instead, and v4l has that. > > Yes, V4L2 has dma_buf support NOW. That days, using so called V4L2 > USERPTR method was the only way to achieve zero copy buffer sharing > between devices, so this is just a historical baggage. I've been > actively involved in implementing that. I've tried to make it secure as > much as possible assuming the limitation of that approach. With a few > assumptions it works fine. Buffers are refcounted both by the > vm_ops->open or by incrementing the refcount of the vm->file. This > basically works with any sane driver, which doesn't free the mmaped > buffer until the file is released. This is true for V4L2 and FBdev devices. I'm not seeing any of that vm->file refcounting going on, so not seeing anything that prevents the mmap area from being removed. Can you pls give me some pointers about which code you're thinking of? -Daniel > This API is considered as deprecated in V4L2 world, so I think > supporting this hack can be removed one day as nowadays userspace should > use dma buf. > > > ... > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF355C4727E for ; Wed, 7 Oct 2020 12:01:59 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F30E220782 for ; Wed, 7 Oct 2020 12:01:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PyaZ/nvZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F30E220782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0AF5B6E8C8; Wed, 7 Oct 2020 12:01:58 +0000 (UTC) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4AE136E8C8 for ; Wed, 7 Oct 2020 12:01:56 +0000 (UTC) Received: by mail-ot1-x343.google.com with SMTP id m13so1883703otl.9 for ; Wed, 07 Oct 2020 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=PyaZ/nvZm2QUtaJTzV68PXra5E6nusMzfq2GtX+T4KHdWVm++EJydv/8XaGh5nYPu2 kpLCfkP523at8+kzTLYGiJF/U5HARJ4ZwyhXlTfgO1W6ZvOLzle/fawTahYRmxpmawyG M2mKVfCZhp95638KHshmfZX9XnDxeTLsbzpOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BPNKg367DCdKIY1liYpuVsKddqsM3ARJiczmrER9Tlk=; b=nAXz6ebwK4ytQi2riaxk2TIPgpdPKfUH5O53Mc8R101EleXBFsD/Weh+vHviM7Ke7P vXEqJ4hoznAONW77i8qPv8P4/qQg6I2EIF5LsoVDWCHjJPspSR84HA2kG3m99GGgNl9D xjLIdVV3aQ8PeyxsV90an5Ax31hJHL5gDhTqqZA4aeQpZHn2Zj0tsq7xd1yk/Xt1SWTK OSLrYTCyz8J91nyCtdO0g/DdVwPj8IW157WO2hn8i5FfoZcsF/1N++LIPiQQ4qjSTT5O mhChUY9PjCtQEeYIr7lMLRDW8YrnXqal5wXfCMm/19zTR6NbEy5WfzgR77RKIzwlUmm/ tWPQ== X-Gm-Message-State: AOAM5322t5ADiKcez+ZwXLUmFtmZWc/OqfkjvP/mg+a7Wzy/YfuM+B/p 0K/fJW76750TdMoLmx39ZiKZJ4VrTNr/WF4JUTcvXg== X-Google-Smtp-Source: ABdhPJwz1+Mjs5/TsMc3YtWSj3uN1hN+EFq4HjqQKny0ZO2DNmwXaAg21800jfJ4gXIzTu9U81dtoIfG8VEkup1Khs8= X-Received: by 2002:a05:6830:1c3c:: with SMTP id f28mr1747283ote.188.1602072115550; Wed, 07 Oct 2020 05:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Wed, 7 Oct 2020 14:01:44 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Marek Szyprowski X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , Linux MM , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Andrew Morton , Dan Williams , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Oct 7, 2020 at 12:47 PM Marek Szyprowski wrote: > > Hi Daniel, > > On 03.10.2020 11:40, Daniel Vetter wrote: > >> After he three places above should use pin_user_pages_fast(), then > >> this whole broken API should be moved into videobuf2-memops.c and a > >> big fat "THIS DOESN'T WORK" stuck on it. > >> > >> videobuf2 should probably use P2P DMA buf for this instead. > > Yup this should be done with dma_buf instead, and v4l has that. > > Yes, V4L2 has dma_buf support NOW. That days, using so called V4L2 > USERPTR method was the only way to achieve zero copy buffer sharing > between devices, so this is just a historical baggage. I've been > actively involved in implementing that. I've tried to make it secure as > much as possible assuming the limitation of that approach. With a few > assumptions it works fine. Buffers are refcounted both by the > vm_ops->open or by incrementing the refcount of the vm->file. This > basically works with any sane driver, which doesn't free the mmaped > buffer until the file is released. This is true for V4L2 and FBdev devices. I'm not seeing any of that vm->file refcounting going on, so not seeing anything that prevents the mmap area from being removed. Can you pls give me some pointers about which code you're thinking of? -Daniel > This API is considered as deprecated in V4L2 world, so I think > supporting this hack can be removed one day as nowadays userspace should > use dma buf. > > > ... > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel