From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751853AbdGMLNg (ORCPT ); Thu, 13 Jul 2017 07:13:36 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:22163 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751165AbdGMLNe (ORCPT ); Thu, 13 Jul 2017 07:13:34 -0400 X-AuditID: cbfec7f1-f796e6d00000116b-67-596755daf08b Subject: Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP To: Christoph Hellwig Cc: Thierry Escande , Mauro Carvalho Chehab , Sakari Ailus , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Pawel Osciak , Kyungmin Park , Hans Verkuil , Shuah Khan , Russell King From: Marek Szyprowski Message-id: <7505cb31-6bd1-7f76-f975-aa5e61e567f0@samsung.com> Date: Thu, 13 Jul 2017 13:13:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-version: 1.0 In-reply-to: <20170705173327.GD5417@lst.de> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit Content-language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTYRzHfXa3u3O1uqbZj94bFJTZGxaHlRQUHBQVRZBR2MprRpvZTi0j aOgWblbL8o1VoGBWKzO2ZWZBtZXmzOXb1AItLBWtlbasVim5ncH++/z4fp6X78NDYbJW8Uzq SEoap0lRqOSEBK+q9b+OebtbmbCitCuGuXX7hYhxXe4TMY1Zn0mmteYqwZy7d1/MlFv/iph8 r59kbEMDBPPqyS2CKfg+hDMmTwuxYRKryz5HsNVdZYh1jpTirNViINhHb7QE++H3AMHaTV0k e8FuQazPOpd1jfjIHZK9knVJnOpIBqdZHn9Aknzl6aLU4oiTbs8zTIt8U42IooCOhSf3ThhR +DhGQVN3JWFEEkpGX0dgG83HhcE3PpjcmGDFwqfiWlIIyhEUPu6YsPoR6D25QSuC3gnnex4S AY6k5dA72IgCEkYbMBh1/hUHAoJeCUavMShJ6Xiw+OzBxTi9EJptjUFnOr0PrpXoSMGZBr8u d+MBDqejoa2zN8gYHQd9Y3qxwPPAdseLCTwDsvVvgrcD2k/Cgz8NpFB6DlifTtTZBAXOdiRw BAzW2UmBZ4Mh55lIYBOCLH20wMUI3F6pwGvBWdc8ce4UuFRVhAnbSyHnrExAFj5a0gTcCO9b NgpP9ROB/4oOu4jmm0OKmUPKmEPKmEPKlCDcgiK5dF6t5PhVy3iFmk9PUS47dExtReNfrWGs brgafX0Z50A0heSTpdTiwwkysSKDz1Q7EFCYPFK6f5syQSZNUmSe4jTHEjXpKo53oFkULp8h lbja98hopSKNO8pxqZzmfyqiwmdq0dL4+pya80UPjR1b5KYst0P8WKtfnon3qyq6SV3qzYNN Hen10/Nsa5IGALtx/0u2ZbgHywsj1pcl3nS0t5V7d7GuGxVUQ42C35w5qupEfJTzTGv53aO6 d6sX/PZEGaK35Xs7y2S51POT3yqP206HNf1Mg6lbtz//kVdV2GaOleN8smLlEkzDK/4BN/1t W2YDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsVy+t/xq7q3QtMjDZ7eFrJYufook8Wpyc+Y LM42vWG3uLxrDptFz4atrBbLNv1hspjy9ie7xeYPL9kszuxfyWYx9csHFov+q5fYHLg9Wpp7 2Dx23F3C6HH460IWj02rOtk8dt9sYPN4/Oslm8eW/rvsHn1bVjF6fN4k53Hq62f2AK4oN5uM 1MSU1CKF1Lzk/JTMvHRbpdAQN10LJYW8xNxUW6UIXd+QICWFssScUiDPyAANODgHuAcr6dsl uGXMPqBWMEO44tzVg8wNjJ/5uxg5OSQETCRezzjGDmGLSVy4t56ti5GLQ0hgCaPEk7WPWEES QgLPGSXWb5AEsYUFAiQerj7CAmKLCChJPH11lhGkgVmgm1li5aRuFoiGn4wSJ1ozQWw2AUOJ rrddbCA2r4CdxKrPW5hBbBYBVYmLm8+CLRAViJG4NvMOK0SNoMSPyffA5nAKaEtcufEUzGYW MJP48vIwK4QtL7F5zVtmCFtcorn1JssERsFZSNpnIWmZhaRlFpKWBYwsqxhFUkuLc9Nziw31 ihNzi0vz0vWS83M3MQKjfNuxn5t3MF7aGHyIUYCDUYmHl0MzLVKINbGsuDL3EKMEB7OSCG+s X3qkEG9KYmVValF+fFFpTmrxIUZToOcmMkuJJucDE1BeSbyhiaG5paGRsYWFuZGRkjhvyYcr 4UIC6YklqdmpqQWpRTB9TBycUg2MlQyO1zaJq+0oLnU/lHR7x6Qr5esnGPAFHitvaOjuK5s5 7eF3+XPFme+2fJjaPpXNwu3gkbdLK0R3s4p6Cxa/3Xuh9m/WnHhWhVcfPJ3jX+7aZCOyTyJS S8BgcmuwxIOTGluPeNZ9bz6RuEN//uKjvkXShntvKMuqODxN/uHmxGLfpBehr+ilxFKckWio xVxUnAgAgPSOQwgDAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170713111330eucas1p23a22e5c0fdb6ece67b82af01994429ac X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161026085228epcas3p3895ea279d5538750a3b1c59715ad3761 X-RootMTR: 20161026085228epcas3p3895ea279d5538750a3b1c59715ad3761 References: <1477471926-15796-1-git-send-email-thierry.escande@collabora.com> <20170705173327.GD5417@lst.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, On 2017-07-05 19:33, Christoph Hellwig wrote: > On Mon, Jul 03, 2017 at 11:27:32AM +0200, Marek Szyprowski wrote: >> The main question here if we want to merge incomplete solution or not. As >> for now, there is no support in ARM/ARM64 for NON_CONSISTENT attribute. >> Also none of the v4l2 drivers use it. Sadly support for NON_CONSISTENT >> attribute is not fully implemented nor even defined in mainline. >> > DMA_ATTR_NON_CONSISTENT is the way to get the dma_alloc_noncoherent > semantics through the dma_alloc_attr API, and as such I think it is > pretty well defined, although the documentation in > Documentation/DMA-attributes.txt is really bad and we need to improve > it, by merging it with the dma_alloc_noncoherent description in > Documentation/DMA-API.txt. My series to remove dma_alloc_noncoherent > updates the latter to mention DMA_ATTR_NON_CONSISTENT, but > we should probably merge Documentation/DMA-API.txt, > Documentation/DMA-attributes.txt and Documentation/DMA-API-HOWTO.txt > into a single coherent document. Right. I started conversion of dma_alloc_noncoherent to NON_CONSISTENT DMA attribute, but later I got stuck at the details of cache synchronization. >> I know that it works fine for some vendor kernel trees, but supporting it in >> mainline was a bit controversial. There is no proper way to sync cache for >> such >> buffers. Calling dma_sync_sg worked so far, but it has to be first agreed as >> a proper DMA API. > As documented in Documentation/DMA-API.txt the proper way to sync > noncoherent/nonconsistent regions is to call dma_cache_sync. It seems > like it generally is the same as dma_sync_range/sg so if we could > eventually merge these APIs that should reduce the confusion further. Original dma_alloc_noncoherent utilized dma_cache_sync() function, which had some flaws, which prevented me to continue that task and introduce it to ARM architecture. The dma_alloc_noncoherent() and dma_cache_sync() API lacks buffer ownership and imprecisely defines how and when the caches has to be synchronized. dma_cache_sync() also lacks DMA address argument, what also complicates potential lightweight implementation. IMHO it would make sense to change it to work similar to the other dma_sync_*_for_{cpu,device} functions, but I didn't find enough time to finally take a try. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland