Convert dma-buf documentation over to sphinx.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
v2: Address review comments from Jonathan Corbet and Markus Heiser.
Sumit Semwal (2):
Documentation: move dma-buf documentation to rst
Documentation/sphinx: link dma-buf rsts
Documentation/DocBook/device-drivers.tmpl | 41 ---
Documentation/dma-buf-sharing.txt | 482 ----------------------------
Documentation/dma-buf/guide.rst | 507 ++++++++++++++++++++++++++++++
Documentation/dma-buf/intro.rst | 82 +++++
Documentation/index.rst | 2 +
MAINTAINERS | 2 +-
6 files changed, 592 insertions(+), 524 deletions(-)
delete mode 100644 Documentation/dma-buf-sharing.txt
create mode 100644 Documentation/dma-buf/guide.rst
create mode 100644 Documentation/dma-buf/intro.rst
--
2.7.4
From: Randy Dunlap <rdunlap(a)infradead.org>
Fix dma-buf kernel-doc warning and 2 minor typos in
fence_array_create().
Fixes this warning:
..//drivers/dma-buf/fence-array.c:124: warning: No description found for parameter 'signal_on_any'
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: linux-media(a)vger.kernel.org
Cc: dri-devel(a)lists.freedesktop.org
Cc: linaro-mm-sig(a)lists.linaro.org
---
drivers/dma-buf/fence-array.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c
+++ lnx-48-rc2/drivers/dma-buf/fence-array.c
@@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops =
* @fences: [in] array containing the fences
* @context: [in] fence context to use
* @seqno: [in] sequence number to use
- * @signal_on_any [in] signal on any fence in the array
+ * @signal_on_any: [in] signal on any fence in the array
*
* Allocate a fence_array object and initialize the base fence with fence_init().
* In case of error it returns NULL.
*
- * The caller should allocte the fences array with num_fences size
+ * The caller should allocate the fences array with num_fences size
* and fill it with the fences it wants to add to the object. Ownership of this
- * array is take and fence_put() is used on each fence on release.
+ * array is taken and fence_put() is used on each fence on release.
*
* If @signal_on_any is true the fence array signals if any fence in the array
* signals, otherwise it signals when all fences in the array signal.
Hi,
This is v2 on the attempt to remove misuse of the cache APIs from Ion. The
previous version[1] attempted to pull the cache APIs into Ion. This was
indicated as the wrong approach and real APIs should be created instead.
The APIs created are kernel_force_cache_clean and kernel_force_cache_invalidate.
They force a clean and invalidate of the cache, respectively. The aim was to
take the semantics of dma_sync and turn them into something that isn't
dma_sync. This series includes a nominal implementation for arm/arm64, mostly
for demonstration purposes.
I did review before writing this of whether Ion could just use the DMA mapping
APIs to acheive the necessary coherency. The conclusion I came to was that
trying to force the Ion code into the DMA model would create more problem than
it solved since there wasn't anything like DMA going on. Similarly, none of
the existing cache APIs did exactly what was needed either. The closest matches
were designed for file cache pages and not drivers.
The series includes conversion of Ion to the new APIs. There are a few other
drivers which are calling either arch specific APIs or flush_dcache_page
that could be converted as well. The i915 driver could potentially be converted
with the addition of an x86 implementation.
Feedback appreciated as always.
Thanks,
Laura
[1] https://lkml.kernel.org/g/<1464205684-5587-1-git-send-email-labbott(a)redhat.com>
Laura Abbott (5):
Documentation: Introduce kernel_force_cache_* APIs
arm: Implement ARCH_HAS_FORCE_CACHE
arm64: Implement ARCH_HAS_FORCE_CACHE
staging: android: ion: Convert to the kernel_force_cache APIs
staging: ion: Add support for syncing with DMA_BUF_IOCTL_SYNC
Documentation/cachetlb.txt | 18 +++-
arch/arm/include/asm/cacheflush.h | 4 +
arch/arm/mm/dma-mapping.c | 119 ------------------------
arch/arm/mm/flush.c | 115 +++++++++++++++++++++++
arch/arm/mm/mm.h | 8 ++
arch/arm64/include/asm/cacheflush.h | 5 +
arch/arm64/mm/flush.c | 11 +++
drivers/staging/android/ion/ion.c | 53 +++++++----
drivers/staging/android/ion/ion_carveout_heap.c | 8 +-
drivers/staging/android/ion/ion_chunk_heap.c | 12 ++-
drivers/staging/android/ion/ion_page_pool.c | 6 +-
drivers/staging/android/ion/ion_priv.h | 11 ---
drivers/staging/android/ion/ion_system_heap.c | 6 +-
include/linux/cacheflush.h | 11 +++
14 files changed, 225 insertions(+), 162 deletions(-)
create mode 100644 include/linux/cacheflush.h
--
2.7.4
I never saw any feedback or action on these patches so this is a resend.
Probably hit the window when everyone was busy/traveling.
---
Hi,
This is some clean up of old Ion interfaces and APIs. These are interfaces that
mostly existed before dma_buf was well integrated into the kernel along with
reservations for board files.
If there are objections to deletion I expect it to turn into a discussion about
what other APIs need to be extended.
Thanks,
Laura
Laura Abbott (5):
staging: android: ion: Get rid of ion_sg_table
staging: android: ion: Drop ion_phys interface
staging: android: ion: Get rid of map_dma/unmap_dma
staging: android: ion: Drop ion_carveout_allocate definitions
staging: android: ion: Get rid of ion_reserve
drivers/staging/android/ion/ion.c | 103 ++----------------------
drivers/staging/android/ion/ion.h | 41 ----------
drivers/staging/android/ion/ion_carveout_heap.c | 33 +-------
drivers/staging/android/ion/ion_chunk_heap.c | 17 +---
drivers/staging/android/ion/ion_cma_heap.c | 34 +-------
drivers/staging/android/ion/ion_priv.h | 30 +------
drivers/staging/android/ion/ion_system_heap.c | 44 +---------
7 files changed, 19 insertions(+), 283 deletions(-)
--
2.5.5
Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
Sumit Semwal (4):
dma-buf/fence: kerneldoc: remove unused struct members
dma-buf/fence: kerneldoc: remove spurious section header
Documentation: move dma-buf documentation to rst
Documentation/sphinx: link dma-buf rsts
Documentation/DocBook/device-drivers.tmpl | 37 ---
Documentation/dma-buf/guide.rst | 503 ++++++++++++++++++++++++++++++
Documentation/dma-buf/intro.rst | 76 +++++
Documentation/index.rst | 2 +
MAINTAINERS | 2 +-
include/linux/fence.h | 4 +-
6 files changed, 583 insertions(+), 41 deletions(-)
create mode 100644 Documentation/dma-buf/guide.rst
create mode 100644 Documentation/dma-buf/intro.rst
--
2.7.4
Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
Sumit Semwal (4):
dma-buf/fence: kerneldoc: remove unused struct members
dma-buf/fence: kerneldoc: remove spurious section header
Documentation: move dma-buf documentation to rst
Documentation/sphinx: link dma-buf rsts
Documentation/DocBook/device-drivers.tmpl | 37 ---
Documentation/dma-buf/guide.rst | 503 ++++++++++++++++++++++++++++++
Documentation/dma-buf/intro.rst | 76 +++++
Documentation/index.rst | 2 +
MAINTAINERS | 2 +-
include/linux/fence.h | 4 +-
6 files changed, 583 insertions(+), 41 deletions(-)
create mode 100644 Documentation/dma-buf/guide.rst
create mode 100644 Documentation/dma-buf/intro.rst
--
2.7.4
On 08/09/2016 02:56 PM, Florian Fainelli wrote:
> On 08/08/2016 10:49 AM, Laura Abbott wrote:
>> arm may need the kernel_force_cache APIs to guarantee data consistency.
>> Implement versions of these APIs based on the DMA APIs.
>>
>> Signed-off-by: Laura Abbott <labbott(a)redhat.com>
>> ---
>> arch/arm/include/asm/cacheflush.h | 4 ++
>> arch/arm/mm/dma-mapping.c | 119 --------------------------------------
>> arch/arm/mm/flush.c | 115 ++++++++++++++++++++++++++++++++++++
>
> Why is the code moved between dma-mapping.c and flush.c? It was not
> obvious while looking at these patches why this is needed.
>
I wanted to use the cache flushing routines from dma-mapping.c and
it seemed better to pull them out vs. trying to put more generic
cache flushing code in dma-mapping.c. flush.c seemed like an
appropriate place although I forgot about the dependency on CONFIG_MMU.
It can certainly remain in dma-mapping.c if deemed appropriate.
Thanks,
Laura
