* [PATCHv6 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:43 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:43 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Hi,
This series tries to solve the problem with DMA with device registers
(MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
recent patch '9575632 (dmaengine: make slave address physical)'
clarifies that DMA slave address provided by clients is the physical
address. This puts the task of mapping the DMA slave address from a
phys_addr_t to a dma_addr_t on the DMA engine.
Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
the same and no special care is needed. However if you have a IOMMU you
need to map the DMA slave phys_addr_t to a dma_addr_t using something
like this.
This series is based on top of and requires the patches from Robin
Murphy in the tag 'arm/io-pgtable' from the iommu repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
/dev/mmcblk1 and the serial console which both are devices behind the
iommu.
Furthermore I have audited to the best of my ability all call paths
involved to make sure that the dma_addr_t obtained from
dma_map_resource() to is not used in a way where it would be expected
for the mapping to be RAM (have a struct page). Many thanks to Christoph
Hellwig and Laurent Pinchart for there input in this effort.
* drivers/dma/sh/rcar-dmac.c
Once the phys_addr_t is mapped to a dma_addr_t using
dma_map_resource() it is only used to check that the transferee do not
cross 4GB boundaries and then only directly written to HW registers.
* drivers/iommu/iommu.c
- iommu_map()
Check that it's align to min page size or return -EINVAL then calls
domain->ops->map()
* drivers/iommu/ipmmu-vmsa.c
- ipmmu_map()
No logic only calls domain->ops->map()
* drivers/iommu/io-pgtable-arm.c
- arm_lpae_map()
No logic only calls __arm_lpae_map()
- __arm_lpae_map()
No logic only calls arm_lpae_init_pte()
- arm_lpae_init_pte()
Used to get a pte:
pte |= pfn_to_iopte(paddr >> data->pg_shift, data);
* drivers/iommu/io-pgtable-arm-v7s.c
- arm_v7s_map()
No logic only calls __arm_v7s_map()
- __arm_v7s_map()
No logic only calls arm_v7s_init_pte()
- arm_v7s_init_pte
Used to get a pte:
pte |= paddr & ARM_V7S_LVL_MASK(lvl);
* ARM dma-mapping
- dma_unmap_*
Only valid unmap is dma_unmap_resource() all others are an invalid
use case.
- dma_sync_single_*
Invalid use case, memory that is mapped is device memory
- dma_common_mmap() and dma_mmap_attrs()
Invalid use case
- dma_common_get_sgtable() and dma_get_sgtable_attrs()
Invalid use case, only for dma_alloc_* allocated memory,
- dma_mapping_error()
OK
While working on the dma-debug parts of this series I found an unrelated
issue with drivers/iommu/io-pgtable-arm.c and CONFIG_DMA_API_DEBUG on
the Koelsch. I tried to address this in the thread
https://lkml.org/lkml/2016/5/8/33 , however it turned out my solution
was not the correct one. I have not tried to address this further so
running this series with CONFIG_DMA_API_DEBUG will trigger this warning
but is unrelated to this work.
* Changes since v5
- Add dma-debug work which adds a new mapping type for the resource
mapping which correctly can be translated to a physical address.
- Drop patches from Robin Murphy since they now are accepted in the
iommu repository and base the series on that tree instead.
- Add a review tag from Laurent.
* Changes since v4
- Move the mapping from phys_addr_t to dma_addr_t from slave_config to the
prepare calls. This way we know the direction of the mapping and don't have
to use DMA_BIDIRECTIONAL. Thanks Vinod for suggesting this.
- To be clear that the data type for slave addresses are changed add a patch
that only changes the data type to phys_addr_t.
- Fixed up commit messages.
* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
method but I saw no other good way since DMA_ERROR_CODE might not be defined
on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
(?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.
* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
point can't be sure what direction the mapping is going to be used.
* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
using attributes DMA_ATTR_NO_KERNEL_MAPPING and
DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
not availability on some configurations.
- Add DT information for r8a7791.
* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
iommu api.
- Dropped the patch showing how I tested the RFC.
Niklas Söderlund (8):
dma-mapping: add {map,unmap}_resource to dma_map_ops
dma-debug: add support for resource mappings
dma-mapping: add dma_{map,unmap}_resource
arm: dma-mapping: add {map,unmap}_resource for iommu ops
dmaengine: rcar-dmac: group slave configuration
dmaengine: rcar-dmac: add iommu support for slave transfers
ARM: dts: r8a7790: add iommus to dmac0 and dmac1
ARM: dts: r8a7791: add iommus to dmac0 and dmac1
Documentation/DMA-API.txt | 22 ++++++--
arch/arm/boot/dts/r8a7790.dtsi | 30 +++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 30 +++++++++++
arch/arm/mm/dma-mapping.c | 63 ++++++++++++++++++++++
drivers/dma/sh/rcar-dmac.c | 116 +++++++++++++++++++++++++++++++++--------
include/linux/dma-debug.h | 19 +++++++
include/linux/dma-mapping.h | 42 +++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++-
8 files changed, 345 insertions(+), 29 deletions(-)
--
2.8.2
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:43 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:43 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
Hi,
This series tries to solve the problem with DMA with device registers
(MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
recent patch '9575632 (dmaengine: make slave address physical)'
clarifies that DMA slave address provided by clients is the physical
address. This puts the task of mapping the DMA slave address from a
phys_addr_t to a dma_addr_t on the DMA engine.
Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
the same and no special care is needed. However if you have a IOMMU you
need to map the DMA slave phys_addr_t to a dma_addr_t using something
like this.
This series is based on top of and requires the patches from Robin
Murphy in the tag 'arm/io-pgtable' from the iommu repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
/dev/mmcblk1 and the serial console which both are devices behind the
iommu.
Furthermore I have audited to the best of my ability all call paths
involved to make sure that the dma_addr_t obtained from
dma_map_resource() to is not used in a way where it would be expected
for the mapping to be RAM (have a struct page). Many thanks to Christoph
Hellwig and Laurent Pinchart for there input in this effort.
* drivers/dma/sh/rcar-dmac.c
Once the phys_addr_t is mapped to a dma_addr_t using
dma_map_resource() it is only used to check that the transferee do not
cross 4GB boundaries and then only directly written to HW registers.
* drivers/iommu/iommu.c
- iommu_map()
Check that it's align to min page size or return -EINVAL then calls
domain->ops->map()
* drivers/iommu/ipmmu-vmsa.c
- ipmmu_map()
No logic only calls domain->ops->map()
* drivers/iommu/io-pgtable-arm.c
- arm_lpae_map()
No logic only calls __arm_lpae_map()
- __arm_lpae_map()
No logic only calls arm_lpae_init_pte()
- arm_lpae_init_pte()
Used to get a pte:
pte |= pfn_to_iopte(paddr >> data->pg_shift, data);
* drivers/iommu/io-pgtable-arm-v7s.c
- arm_v7s_map()
No logic only calls __arm_v7s_map()
- __arm_v7s_map()
No logic only calls arm_v7s_init_pte()
- arm_v7s_init_pte
Used to get a pte:
pte |= paddr & ARM_V7S_LVL_MASK(lvl);
* ARM dma-mapping
- dma_unmap_*
Only valid unmap is dma_unmap_resource() all others are an invalid
use case.
- dma_sync_single_*
Invalid use case, memory that is mapped is device memory
- dma_common_mmap() and dma_mmap_attrs()
Invalid use case
- dma_common_get_sgtable() and dma_get_sgtable_attrs()
Invalid use case, only for dma_alloc_* allocated memory,
- dma_mapping_error()
OK
While working on the dma-debug parts of this series I found an unrelated
issue with drivers/iommu/io-pgtable-arm.c and CONFIG_DMA_API_DEBUG on
the Koelsch. I tried to address this in the thread
https://lkml.org/lkml/2016/5/8/33 , however it turned out my solution
was not the correct one. I have not tried to address this further so
running this series with CONFIG_DMA_API_DEBUG will trigger this warning
but is unrelated to this work.
* Changes since v5
- Add dma-debug work which adds a new mapping type for the resource
mapping which correctly can be translated to a physical address.
- Drop patches from Robin Murphy since they now are accepted in the
iommu repository and base the series on that tree instead.
- Add a review tag from Laurent.
* Changes since v4
- Move the mapping from phys_addr_t to dma_addr_t from slave_config to the
prepare calls. This way we know the direction of the mapping and don't have
to use DMA_BIDIRECTIONAL. Thanks Vinod for suggesting this.
- To be clear that the data type for slave addresses are changed add a patch
that only changes the data type to phys_addr_t.
- Fixed up commit messages.
* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
method but I saw no other good way since DMA_ERROR_CODE might not be defined
on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
(?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.
* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
point can't be sure what direction the mapping is going to be used.
* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
using attributes DMA_ATTR_NO_KERNEL_MAPPING and
DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
not availability on some configurations.
- Add DT information for r8a7791.
* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
iommu api.
- Dropped the patch showing how I tested the RFC.
Niklas Söderlund (8):
dma-mapping: add {map,unmap}_resource to dma_map_ops
dma-debug: add support for resource mappings
dma-mapping: add dma_{map,unmap}_resource
arm: dma-mapping: add {map,unmap}_resource for iommu ops
dmaengine: rcar-dmac: group slave configuration
dmaengine: rcar-dmac: add iommu support for slave transfers
ARM: dts: r8a7790: add iommus to dmac0 and dmac1
ARM: dts: r8a7791: add iommus to dmac0 and dmac1
Documentation/DMA-API.txt | 22 ++++++--
arch/arm/boot/dts/r8a7790.dtsi | 30 +++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 30 +++++++++++
arch/arm/mm/dma-mapping.c | 63 ++++++++++++++++++++++
drivers/dma/sh/rcar-dmac.c | 116 +++++++++++++++++++++++++++++++++--------
include/linux/dma-debug.h | 19 +++++++
include/linux/dma-mapping.h | 42 +++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++-
8 files changed, 345 insertions(+), 29 deletions(-)
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:43 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series tries to solve the problem with DMA with device registers
(MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
recent patch '9575632 (dmaengine: make slave address physical)'
clarifies that DMA slave address provided by clients is the physical
address. This puts the task of mapping the DMA slave address from a
phys_addr_t to a dma_addr_t on the DMA engine.
Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
the same and no special care is needed. However if you have a IOMMU you
need to map the DMA slave phys_addr_t to a dma_addr_t using something
like this.
This series is based on top of and requires the patches from Robin
Murphy in the tag 'arm/io-pgtable' from the iommu repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
/dev/mmcblk1 and the serial console which both are devices behind the
iommu.
Furthermore I have audited to the best of my ability all call paths
involved to make sure that the dma_addr_t obtained from
dma_map_resource() to is not used in a way where it would be expected
for the mapping to be RAM (have a struct page). Many thanks to Christoph
Hellwig and Laurent Pinchart for there input in this effort.
* drivers/dma/sh/rcar-dmac.c
Once the phys_addr_t is mapped to a dma_addr_t using
dma_map_resource() it is only used to check that the transferee do not
cross 4GB boundaries and then only directly written to HW registers.
* drivers/iommu/iommu.c
- iommu_map()
Check that it's align to min page size or return -EINVAL then calls
domain->ops->map()
* drivers/iommu/ipmmu-vmsa.c
- ipmmu_map()
No logic only calls domain->ops->map()
* drivers/iommu/io-pgtable-arm.c
- arm_lpae_map()
No logic only calls __arm_lpae_map()
- __arm_lpae_map()
No logic only calls arm_lpae_init_pte()
- arm_lpae_init_pte()
Used to get a pte:
pte |= pfn_to_iopte(paddr >> data->pg_shift, data);
* drivers/iommu/io-pgtable-arm-v7s.c
- arm_v7s_map()
No logic only calls __arm_v7s_map()
- __arm_v7s_map()
No logic only calls arm_v7s_init_pte()
- arm_v7s_init_pte
Used to get a pte:
pte |= paddr & ARM_V7S_LVL_MASK(lvl);
* ARM dma-mapping
- dma_unmap_*
Only valid unmap is dma_unmap_resource() all others are an invalid
use case.
- dma_sync_single_*
Invalid use case, memory that is mapped is device memory
- dma_common_mmap() and dma_mmap_attrs()
Invalid use case
- dma_common_get_sgtable() and dma_get_sgtable_attrs()
Invalid use case, only for dma_alloc_* allocated memory,
- dma_mapping_error()
OK
While working on the dma-debug parts of this series I found an unrelated
issue with drivers/iommu/io-pgtable-arm.c and CONFIG_DMA_API_DEBUG on
the Koelsch. I tried to address this in the thread
https://lkml.org/lkml/2016/5/8/33 , however it turned out my solution
was not the correct one. I have not tried to address this further so
running this series with CONFIG_DMA_API_DEBUG will trigger this warning
but is unrelated to this work.
* Changes since v5
- Add dma-debug work which adds a new mapping type for the resource
mapping which correctly can be translated to a physical address.
- Drop patches from Robin Murphy since they now are accepted in the
iommu repository and base the series on that tree instead.
- Add a review tag from Laurent.
* Changes since v4
- Move the mapping from phys_addr_t to dma_addr_t from slave_config to the
prepare calls. This way we know the direction of the mapping and don't have
to use DMA_BIDIRECTIONAL. Thanks Vinod for suggesting this.
- To be clear that the data type for slave addresses are changed add a patch
that only changes the data type to phys_addr_t.
- Fixed up commit messages.
* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
method but I saw no other good way since DMA_ERROR_CODE might not be defined
on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
(?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.
* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
point can't be sure what direction the mapping is going to be used.
* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
using attributes DMA_ATTR_NO_KERNEL_MAPPING and
DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
not availability on some configurations.
- Add DT information for r8a7791.
* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
iommu api.
- Dropped the patch showing how I tested the RFC.
Niklas S?derlund (8):
dma-mapping: add {map,unmap}_resource to dma_map_ops
dma-debug: add support for resource mappings
dma-mapping: add dma_{map,unmap}_resource
arm: dma-mapping: add {map,unmap}_resource for iommu ops
dmaengine: rcar-dmac: group slave configuration
dmaengine: rcar-dmac: add iommu support for slave transfers
ARM: dts: r8a7790: add iommus to dmac0 and dmac1
ARM: dts: r8a7791: add iommus to dmac0 and dmac1
Documentation/DMA-API.txt | 22 ++++++--
arch/arm/boot/dts/r8a7790.dtsi | 30 +++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 30 +++++++++++
arch/arm/mm/dma-mapping.c | 63 ++++++++++++++++++++++
drivers/dma/sh/rcar-dmac.c | 116 +++++++++++++++++++++++++++++++++--------
include/linux/dma-debug.h | 19 +++++++
include/linux/dma-mapping.h | 42 +++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++-
8 files changed, 345 insertions(+), 29 deletions(-)
--
2.8.2
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 1/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
include/linux/dma-mapping.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0e4d3a6..8617fa1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
struct dma_attrs *attrs);
+ dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
+ void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 1/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
include/linux/dma-mapping.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0e4d3a6..8617fa1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
struct dma_attrs *attrs);
+ dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
+ void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 1/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
include/linux/dma-mapping.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0e4d3a6..8617fa1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
struct dma_attrs *attrs);
+ dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
+ void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
A MMIO mapped resource can not be represented by a struct page so a new
debug type is needed to handle this. This patch add such type and
functionality to add/remove entries and how to translate them to a
physical address.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-debug.h | 19 +++++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-debug.h b/include/linux/dma-debug.h
index fe8cb61..c7d844f 100644
--- a/include/linux/dma-debug.h
+++ b/include/linux/dma-debug.h
@@ -56,6 +56,13 @@ extern void debug_dma_alloc_coherent(struct device *dev, size_t size,
extern void debug_dma_free_coherent(struct device *dev, size_t size,
void *virt, dma_addr_t addr);
+extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr);
+
+extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction);
+
extern void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
int direction);
@@ -141,6 +148,18 @@ static inline void debug_dma_free_coherent(struct device *dev, size_t size,
{
}
+static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr)
+{
+}
+
+static inline void debug_dma_unmap_resource(struct device *dev,
+ dma_addr_t dma_addr, size_t size,
+ int direction)
+{
+}
+
static inline void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle,
size_t size, int direction)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 4a1515f..fb12d5c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -43,6 +43,7 @@ enum {
dma_debug_page,
dma_debug_sg,
dma_debug_coherent,
+ dma_debug_resource,
};
enum map_err_types {
@@ -150,8 +151,9 @@ static const char *const maperr2str[] = {
[MAP_ERR_CHECKED] = "dma map error checked",
};
-static const char *type2name[4] = { "single", "page",
- "scather-gather", "coherent" };
+static const char *type2name[5] = { "single", "page",
+ "scather-gather", "coherent",
+ "resource" };
static const char *dir2name[4] = { "DMA_BIDIRECTIONAL", "DMA_TO_DEVICE",
"DMA_FROM_DEVICE", "DMA_NONE" };
@@ -397,6 +399,9 @@ static void hash_bucket_del(struct dma_debug_entry *entry)
static unsigned long long phys_addr(struct dma_debug_entry *entry)
{
+ if (entry->type == dma_debug_resource)
+ return PHYS_PFN(entry->pfn) + entry->offset;
+
return page_to_phys(pfn_to_page(entry->pfn)) + entry->offset;
}
@@ -1493,6 +1498,49 @@ void debug_dma_free_coherent(struct device *dev, size_t size,
}
EXPORT_SYMBOL(debug_dma_free_coherent);
+void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
+ int direction, dma_addr_t dma_addr)
+{
+ struct dma_debug_entry *entry;
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ entry = dma_entry_alloc();
+ if (!entry)
+ return;
+
+ entry->type = dma_debug_resource;
+ entry->dev = dev;
+ entry->pfn = __phys_to_pfn(addr);
+ entry->offset = addr - PHYS_PFN(entry->pfn);
+ entry->size = size;
+ entry->dev_addr = dma_addr;
+ entry->direction = direction;
+ entry->map_err_type = MAP_ERR_NOT_CHECKED;
+
+ add_dma_entry(entry);
+}
+EXPORT_SYMBOL(debug_dma_map_resource);
+
+void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction)
+{
+ struct dma_debug_entry ref = {
+ .type = dma_debug_resource,
+ .dev = dev,
+ .dev_addr = dma_addr,
+ .size = size,
+ .direction = direction,
+ };
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ check_unmap(&ref);
+}
+EXPORT_SYMBOL(debug_dma_unmap_resource);
+
void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
size_t size, int direction)
{
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
A MMIO mapped resource can not be represented by a struct page so a new
debug type is needed to handle this. This patch add such type and
functionality to add/remove entries and how to translate them to a
physical address.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-debug.h | 19 +++++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-debug.h b/include/linux/dma-debug.h
index fe8cb61..c7d844f 100644
--- a/include/linux/dma-debug.h
+++ b/include/linux/dma-debug.h
@@ -56,6 +56,13 @@ extern void debug_dma_alloc_coherent(struct device *dev, size_t size,
extern void debug_dma_free_coherent(struct device *dev, size_t size,
void *virt, dma_addr_t addr);
+extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr);
+
+extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction);
+
extern void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
int direction);
@@ -141,6 +148,18 @@ static inline void debug_dma_free_coherent(struct device *dev, size_t size,
{
}
+static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr)
+{
+}
+
+static inline void debug_dma_unmap_resource(struct device *dev,
+ dma_addr_t dma_addr, size_t size,
+ int direction)
+{
+}
+
static inline void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle,
size_t size, int direction)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 4a1515f..fb12d5c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -43,6 +43,7 @@ enum {
dma_debug_page,
dma_debug_sg,
dma_debug_coherent,
+ dma_debug_resource,
};
enum map_err_types {
@@ -150,8 +151,9 @@ static const char *const maperr2str[] = {
[MAP_ERR_CHECKED] = "dma map error checked",
};
-static const char *type2name[4] = { "single", "page",
- "scather-gather", "coherent" };
+static const char *type2name[5] = { "single", "page",
+ "scather-gather", "coherent",
+ "resource" };
static const char *dir2name[4] = { "DMA_BIDIRECTIONAL", "DMA_TO_DEVICE",
"DMA_FROM_DEVICE", "DMA_NONE" };
@@ -397,6 +399,9 @@ static void hash_bucket_del(struct dma_debug_entry *entry)
static unsigned long long phys_addr(struct dma_debug_entry *entry)
{
+ if (entry->type == dma_debug_resource)
+ return PHYS_PFN(entry->pfn) + entry->offset;
+
return page_to_phys(pfn_to_page(entry->pfn)) + entry->offset;
}
@@ -1493,6 +1498,49 @@ void debug_dma_free_coherent(struct device *dev, size_t size,
}
EXPORT_SYMBOL(debug_dma_free_coherent);
+void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
+ int direction, dma_addr_t dma_addr)
+{
+ struct dma_debug_entry *entry;
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ entry = dma_entry_alloc();
+ if (!entry)
+ return;
+
+ entry->type = dma_debug_resource;
+ entry->dev = dev;
+ entry->pfn = __phys_to_pfn(addr);
+ entry->offset = addr - PHYS_PFN(entry->pfn);
+ entry->size = size;
+ entry->dev_addr = dma_addr;
+ entry->direction = direction;
+ entry->map_err_type = MAP_ERR_NOT_CHECKED;
+
+ add_dma_entry(entry);
+}
+EXPORT_SYMBOL(debug_dma_map_resource);
+
+void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction)
+{
+ struct dma_debug_entry ref = {
+ .type = dma_debug_resource,
+ .dev = dev,
+ .dev_addr = dma_addr,
+ .size = size,
+ .direction = direction,
+ };
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ check_unmap(&ref);
+}
+EXPORT_SYMBOL(debug_dma_unmap_resource);
+
void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
size_t size, int direction)
{
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
A MMIO mapped resource can not be represented by a struct page so a new
debug type is needed to handle this. This patch add such type and
functionality to add/remove entries and how to translate them to a
physical address.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-debug.h | 19 +++++++++++++++++
lib/dma-debug.c | 52 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-debug.h b/include/linux/dma-debug.h
index fe8cb61..c7d844f 100644
--- a/include/linux/dma-debug.h
+++ b/include/linux/dma-debug.h
@@ -56,6 +56,13 @@ extern void debug_dma_alloc_coherent(struct device *dev, size_t size,
extern void debug_dma_free_coherent(struct device *dev, size_t size,
void *virt, dma_addr_t addr);
+extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr);
+
+extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction);
+
extern void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
int direction);
@@ -141,6 +148,18 @@ static inline void debug_dma_free_coherent(struct device *dev, size_t size,
{
}
+static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
+ size_t size, int direction,
+ dma_addr_t dma_addr)
+{
+}
+
+static inline void debug_dma_unmap_resource(struct device *dev,
+ dma_addr_t dma_addr, size_t size,
+ int direction)
+{
+}
+
static inline void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle,
size_t size, int direction)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 4a1515f..fb12d5c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -43,6 +43,7 @@ enum {
dma_debug_page,
dma_debug_sg,
dma_debug_coherent,
+ dma_debug_resource,
};
enum map_err_types {
@@ -150,8 +151,9 @@ static const char *const maperr2str[] = {
[MAP_ERR_CHECKED] = "dma map error checked",
};
-static const char *type2name[4] = { "single", "page",
- "scather-gather", "coherent" };
+static const char *type2name[5] = { "single", "page",
+ "scather-gather", "coherent",
+ "resource" };
static const char *dir2name[4] = { "DMA_BIDIRECTIONAL", "DMA_TO_DEVICE",
"DMA_FROM_DEVICE", "DMA_NONE" };
@@ -397,6 +399,9 @@ static void hash_bucket_del(struct dma_debug_entry *entry)
static unsigned long long phys_addr(struct dma_debug_entry *entry)
{
+ if (entry->type == dma_debug_resource)
+ return PHYS_PFN(entry->pfn) + entry->offset;
+
return page_to_phys(pfn_to_page(entry->pfn)) + entry->offset;
}
@@ -1493,6 +1498,49 @@ void debug_dma_free_coherent(struct device *dev, size_t size,
}
EXPORT_SYMBOL(debug_dma_free_coherent);
+void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
+ int direction, dma_addr_t dma_addr)
+{
+ struct dma_debug_entry *entry;
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ entry = dma_entry_alloc();
+ if (!entry)
+ return;
+
+ entry->type = dma_debug_resource;
+ entry->dev = dev;
+ entry->pfn = __phys_to_pfn(addr);
+ entry->offset = addr - PHYS_PFN(entry->pfn);
+ entry->size = size;
+ entry->dev_addr = dma_addr;
+ entry->direction = direction;
+ entry->map_err_type = MAP_ERR_NOT_CHECKED;
+
+ add_dma_entry(entry);
+}
+EXPORT_SYMBOL(debug_dma_map_resource);
+
+void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
+ size_t size, int direction)
+{
+ struct dma_debug_entry ref = {
+ .type = dma_debug_resource,
+ .dev = dev,
+ .dev_addr = dma_addr,
+ .size = size,
+ .direction = direction,
+ };
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ check_unmap(&ref);
+}
+EXPORT_SYMBOL(debug_dma_unmap_resource);
+
void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
size_t size, int direction)
{
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
2016-05-09 16:43 ` Niklas Söderlund
@ 2016-05-09 16:44 ` Niklas Söderlund
-1 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
Documentation/DMA-API.txt | 22 +++++++++++++++++-----
include/linux/dma-mapping.h | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 45ef3f2..c7e5f99 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -277,14 +277,26 @@ and <size> parameters are provided to do partial page mapping, it is
recommended that you never use these unless you really know what the
cache width is.
+dma_addr_t
+dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+
+void
+dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+
+API for mapping and unmapping for MMIO resources. All the notes and
+warnings for the other mapping APIs apply here. The API should only be
+used to map device MMIO resources, mapping of RAM is not permitted.
+
int
dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
-In some circumstances dma_map_single() and dma_map_page() will fail to create
-a mapping. A driver can check for these errors by testing the returned
-DMA address with dma_mapping_error(). A non-zero return value means the mapping
-could not be created and the driver should take appropriate action (e.g.
-reduce current DMA mapping usage or delay and try again later).
+In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
+will fail to create a mapping. A driver can check for these errors by testing
+the returned DMA address with dma_mapping_error(). A non-zero return value
+means the mapping could not be created and the driver should take appropriate
+action (e.g. reduce current DMA mapping usage or delay and try again later).
int
dma_map_sg(struct device *dev, struct scatterlist *sg,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 8617fa1..dd228ce 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -218,6 +218,42 @@ static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
debug_dma_unmap_page(dev, addr, size, dir, false);
}
+static inline dma_addr_t dma_map_resource(struct device *dev,
+ phys_addr_t phys_addr,
+ size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ unsigned long pfn = __phys_to_pfn(phys_addr);
+ dma_addr_t addr;
+
+ BUG_ON(!valid_dma_direction(dir));
+
+ /* Don't allow RAM to be mapped */
+ BUG_ON(pfn_valid(pfn));
+
+ addr = phys_addr;
+ if (ops->map_resource)
+ addr = ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+ debug_dma_map_resource(dev, phys_addr, size, dir, addr);
+
+ return addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ BUG_ON(!valid_dma_direction(dir));
+ if (ops->unmap_resource)
+ ops->unmap_resource(dev, addr, size, dir, attrs);
+ debug_dma_unmap_resource(dev, addr, size, dir);
+}
+
static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
size_t size,
enum dma_data_direction dir)
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
Documentation/DMA-API.txt | 22 +++++++++++++++++-----
include/linux/dma-mapping.h | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 45ef3f2..c7e5f99 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -277,14 +277,26 @@ and <size> parameters are provided to do partial page mapping, it is
recommended that you never use these unless you really know what the
cache width is.
+dma_addr_t
+dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+
+void
+dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+
+API for mapping and unmapping for MMIO resources. All the notes and
+warnings for the other mapping APIs apply here. The API should only be
+used to map device MMIO resources, mapping of RAM is not permitted.
+
int
dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
-In some circumstances dma_map_single() and dma_map_page() will fail to create
-a mapping. A driver can check for these errors by testing the returned
-DMA address with dma_mapping_error(). A non-zero return value means the mapping
-could not be created and the driver should take appropriate action (e.g.
-reduce current DMA mapping usage or delay and try again later).
+In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
+will fail to create a mapping. A driver can check for these errors by testing
+the returned DMA address with dma_mapping_error(). A non-zero return value
+means the mapping could not be created and the driver should take appropriate
+action (e.g. reduce current DMA mapping usage or delay and try again later).
int
dma_map_sg(struct device *dev, struct scatterlist *sg,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 8617fa1..dd228ce 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -218,6 +218,42 @@ static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
debug_dma_unmap_page(dev, addr, size, dir, false);
}
+static inline dma_addr_t dma_map_resource(struct device *dev,
+ phys_addr_t phys_addr,
+ size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ unsigned long pfn = __phys_to_pfn(phys_addr);
+ dma_addr_t addr;
+
+ BUG_ON(!valid_dma_direction(dir));
+
+ /* Don't allow RAM to be mapped */
+ BUG_ON(pfn_valid(pfn));
+
+ addr = phys_addr;
+ if (ops->map_resource)
+ addr = ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+ debug_dma_map_resource(dev, phys_addr, size, dir, addr);
+
+ return addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ BUG_ON(!valid_dma_direction(dir));
+ if (ops->unmap_resource)
+ ops->unmap_resource(dev, addr, size, dir, attrs);
+ debug_dma_unmap_resource(dev, addr, size, dir);
+}
+
static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
size_t size,
enum dma_data_direction dir)
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 4/8] arm: dma-mapping: add {map,unmap}_resource for iommu ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index deac58d..d5fe32b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1962,6 +1962,63 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
__free_iova(mapping, iova, len);
}
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t dma_addr;
+ int ret, prot;
+ phys_addr_t addr = phys_addr & PAGE_MASK;
+ int offset = phys_addr & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ dma_addr = __alloc_iova(mapping, size);
+ if (dma_addr == DMA_ERROR_CODE)
+ return dma_addr;
+
+ prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+ ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+ if (ret < 0)
+ goto fail;
+
+ return dma_addr + offset;
+fail:
+ __free_iova(mapping, dma_addr, size);
+ return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t iova = dma_handle & PAGE_MASK;
+ int offset = dma_handle & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ if (!iova)
+ return;
+
+ iommu_unmap(mapping->domain, iova, len);
+ __free_iova(mapping, iova, len);
+}
+
static void arm_iommu_sync_single_for_cpu(struct device *dev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
@@ -2006,6 +2063,9 @@ struct dma_map_ops iommu_ops = {
.sync_sg_for_cpu = arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
@@ -2021,6 +2081,9 @@ struct dma_map_ops iommu_coherent_ops = {
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg = arm_coherent_iommu_unmap_sg,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 4/8] arm: dma-mapping: add {map, unmap}_resource for iommu ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index deac58d..d5fe32b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1962,6 +1962,63 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
__free_iova(mapping, iova, len);
}
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t dma_addr;
+ int ret, prot;
+ phys_addr_t addr = phys_addr & PAGE_MASK;
+ int offset = phys_addr & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ dma_addr = __alloc_iova(mapping, size);
+ if (dma_addr == DMA_ERROR_CODE)
+ return dma_addr;
+
+ prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+ ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+ if (ret < 0)
+ goto fail;
+
+ return dma_addr + offset;
+fail:
+ __free_iova(mapping, dma_addr, size);
+ return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t iova = dma_handle & PAGE_MASK;
+ int offset = dma_handle & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ if (!iova)
+ return;
+
+ iommu_unmap(mapping->domain, iova, len);
+ __free_iova(mapping, iova, len);
+}
+
static void arm_iommu_sync_single_for_cpu(struct device *dev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
@@ -2006,6 +2063,9 @@ struct dma_map_ops iommu_ops = {
.sync_sg_for_cpu = arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
@@ -2021,6 +2081,9 @@ struct dma_map_ops iommu_coherent_ops = {
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg = arm_coherent_iommu_unmap_sg,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 4/8] arm: dma-mapping: add {map, unmap}_resource for iommu ops
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index deac58d..d5fe32b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1962,6 +1962,63 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
__free_iova(mapping, iova, len);
}
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t dma_addr;
+ int ret, prot;
+ phys_addr_t addr = phys_addr & PAGE_MASK;
+ int offset = phys_addr & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ dma_addr = __alloc_iova(mapping, size);
+ if (dma_addr == DMA_ERROR_CODE)
+ return dma_addr;
+
+ prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+ ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+ if (ret < 0)
+ goto fail;
+
+ return dma_addr + offset;
+fail:
+ __free_iova(mapping, dma_addr, size);
+ return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t iova = dma_handle & PAGE_MASK;
+ int offset = dma_handle & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ if (!iova)
+ return;
+
+ iommu_unmap(mapping->domain, iova, len);
+ __free_iova(mapping, iova, len);
+}
+
static void arm_iommu_sync_single_for_cpu(struct device *dev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
@@ -2006,6 +2063,9 @@ struct dma_map_ops iommu_ops = {
.sync_sg_for_cpu = arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
@@ -2021,6 +2081,9 @@ struct dma_map_ops iommu_coherent_ops = {
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg = arm_coherent_iommu_unmap_sg,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 5/8] dmaengine: rcar-dmac: group slave configuration
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/dma/sh/rcar-dmac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index dfb1792..b0c3bb2 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,22 @@ struct rcar_dmac_desc_page {
sizeof(struct rcar_dmac_xfer_chunk))
/*
+ * struct rcar_dmac_chan_slave - Slave configuration
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+ phys_addr_t slave_addr;
+ unsigned int xfer_size;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
* @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
* @mid_rid: hardware MID/RID for the DMA client using this channel
* @lock: protects the channel CHCR register and the desc members
* @desc.free: list of free descriptors
@@ -142,10 +150,8 @@ struct rcar_dmac_chan {
void __iomem *iomem;
unsigned int index;
- unsigned int src_xfer_size;
- unsigned int dst_xfer_size;
- dma_addr_t src_slave_addr;
- dma_addr_t dst_slave_addr;
+ struct rcar_dmac_chan_slave src;
+ struct rcar_dmac_chan_slave dst;
int mid_rid;
spinlock_t lock;
@@ -793,13 +799,13 @@ static void rcar_dmac_chan_configure_desc(struct rcar_dmac_chan *chan,
case DMA_DEV_TO_MEM:
chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->src_xfer_size;
+ xfer_size = chan->src.xfer_size;
break;
case DMA_MEM_TO_DEV:
chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->dst_xfer_size;
+ xfer_size = chan->dst.xfer_size;
break;
case DMA_MEM_TO_MEM:
@@ -1038,7 +1044,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, false);
}
@@ -1093,7 +1099,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, true);
@@ -1110,10 +1116,10 @@ static int rcar_dmac_device_config(struct dma_chan *chan,
* We could lock this, but you shouldn't be configuring the
* channel, while using it...
*/
- rchan->src_slave_addr = cfg->src_addr;
- rchan->dst_slave_addr = cfg->dst_addr;
- rchan->src_xfer_size = cfg->src_addr_width;
- rchan->dst_xfer_size = cfg->dst_addr_width;
+ rchan->src.slave_addr = cfg->src_addr;
+ rchan->dst.slave_addr = cfg->dst_addr;
+ rchan->src.xfer_size = cfg->src_addr_width;
+ rchan->dst.xfer_size = cfg->dst_addr_width;
return 0;
}
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 5/8] dmaengine: rcar-dmac: group slave configuration
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/dma/sh/rcar-dmac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index dfb1792..b0c3bb2 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,22 @@ struct rcar_dmac_desc_page {
sizeof(struct rcar_dmac_xfer_chunk))
/*
+ * struct rcar_dmac_chan_slave - Slave configuration
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+ phys_addr_t slave_addr;
+ unsigned int xfer_size;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
* @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
* @mid_rid: hardware MID/RID for the DMA client using this channel
* @lock: protects the channel CHCR register and the desc members
* @desc.free: list of free descriptors
@@ -142,10 +150,8 @@ struct rcar_dmac_chan {
void __iomem *iomem;
unsigned int index;
- unsigned int src_xfer_size;
- unsigned int dst_xfer_size;
- dma_addr_t src_slave_addr;
- dma_addr_t dst_slave_addr;
+ struct rcar_dmac_chan_slave src;
+ struct rcar_dmac_chan_slave dst;
int mid_rid;
spinlock_t lock;
@@ -793,13 +799,13 @@ static void rcar_dmac_chan_configure_desc(struct rcar_dmac_chan *chan,
case DMA_DEV_TO_MEM:
chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->src_xfer_size;
+ xfer_size = chan->src.xfer_size;
break;
case DMA_MEM_TO_DEV:
chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->dst_xfer_size;
+ xfer_size = chan->dst.xfer_size;
break;
case DMA_MEM_TO_MEM:
@@ -1038,7 +1044,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, false);
}
@@ -1093,7 +1099,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, true);
@@ -1110,10 +1116,10 @@ static int rcar_dmac_device_config(struct dma_chan *chan,
* We could lock this, but you shouldn't be configuring the
* channel, while using it...
*/
- rchan->src_slave_addr = cfg->src_addr;
- rchan->dst_slave_addr = cfg->dst_addr;
- rchan->src_xfer_size = cfg->src_addr_width;
- rchan->dst_xfer_size = cfg->dst_addr_width;
+ rchan->src.slave_addr = cfg->src_addr;
+ rchan->dst.slave_addr = cfg->dst_addr;
+ rchan->src.xfer_size = cfg->src_addr_width;
+ rchan->dst.xfer_size = cfg->dst_addr_width;
return 0;
}
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 5/8] dmaengine: rcar-dmac: group slave configuration
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/dma/sh/rcar-dmac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index dfb1792..b0c3bb2 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,22 @@ struct rcar_dmac_desc_page {
sizeof(struct rcar_dmac_xfer_chunk))
/*
+ * struct rcar_dmac_chan_slave - Slave configuration
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+ phys_addr_t slave_addr;
+ unsigned int xfer_size;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
* @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
* @mid_rid: hardware MID/RID for the DMA client using this channel
* @lock: protects the channel CHCR register and the desc members
* @desc.free: list of free descriptors
@@ -142,10 +150,8 @@ struct rcar_dmac_chan {
void __iomem *iomem;
unsigned int index;
- unsigned int src_xfer_size;
- unsigned int dst_xfer_size;
- dma_addr_t src_slave_addr;
- dma_addr_t dst_slave_addr;
+ struct rcar_dmac_chan_slave src;
+ struct rcar_dmac_chan_slave dst;
int mid_rid;
spinlock_t lock;
@@ -793,13 +799,13 @@ static void rcar_dmac_chan_configure_desc(struct rcar_dmac_chan *chan,
case DMA_DEV_TO_MEM:
chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->src_xfer_size;
+ xfer_size = chan->src.xfer_size;
break;
case DMA_MEM_TO_DEV:
chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->dst_xfer_size;
+ xfer_size = chan->dst.xfer_size;
break;
case DMA_MEM_TO_MEM:
@@ -1038,7 +1044,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, false);
}
@@ -1093,7 +1099,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
}
dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src_slave_addr : rchan->dst_slave_addr;
+ ? rchan->src.slave_addr : rchan->dst.slave_addr;
desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, true);
@@ -1110,10 +1116,10 @@ static int rcar_dmac_device_config(struct dma_chan *chan,
* We could lock this, but you shouldn't be configuring the
* channel, while using it...
*/
- rchan->src_slave_addr = cfg->src_addr;
- rchan->dst_slave_addr = cfg->dst_addr;
- rchan->src_xfer_size = cfg->src_addr_width;
- rchan->dst_xfer_size = cfg->dst_addr_width;
+ rchan->src.slave_addr = cfg->src_addr;
+ rchan->dst.slave_addr = cfg->dst_addr;
+ rchan->src.xfer_size = cfg->src_addr_width;
+ rchan->dst.xfer_size = cfg->dst_addr_width;
return 0;
}
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
Enable slave transfers to a device behind a IPMMU by mapping the slave
addresses using the dma-mapping API.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/dma/sh/rcar-dmac.c | 82 +++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index b0c3bb2..8592598 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -128,6 +128,18 @@ struct rcar_dmac_chan_slave {
};
/*
+ * struct rcar_dmac_chan_map - Map of slave device phys to dma address
+ * @addr: slave dma address
+ * @dir: direction of mapping
+ * @slave: slave configuration that is mapped
+ */
+struct rcar_dmac_chan_map {
+ dma_addr_t addr;
+ enum dma_data_direction dir;
+ struct rcar_dmac_chan_slave slave;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
@@ -152,6 +164,7 @@ struct rcar_dmac_chan {
struct rcar_dmac_chan_slave src;
struct rcar_dmac_chan_slave dst;
+ struct rcar_dmac_chan_map map;
int mid_rid;
spinlock_t lock;
@@ -1027,13 +1040,65 @@ rcar_dmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
DMA_MEM_TO_MEM, flags, false);
}
+static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
+ enum dma_transfer_direction dir)
+{
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+ struct rcar_dmac_chan_map *map = &rchan->map;
+ phys_addr_t dev_addr;
+ size_t dev_size;
+ enum dma_data_direction dev_dir;
+
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = rchan->src.slave_addr;
+ dev_size = rchan->src.xfer_size;
+ dev_dir = DMA_TO_DEVICE;
+ } else {
+ dev_addr = rchan->dst.slave_addr;
+ dev_size = rchan->dst.xfer_size;
+ dev_dir = DMA_FROM_DEVICE;
+ }
+
+ /* Reuse current map if possible. */
+ if (dev_addr == map->slave.slave_addr &&
+ dev_size == map->slave.xfer_size &&
+ dev_dir == map->dir)
+ return 0;
+
+ /* Remove old mapping if present. */
+ if (map->slave.xfer_size)
+ dma_unmap_resource(chan->device->dev, map->addr,
+ map->slave.xfer_size, map->dir, NULL);
+ map->slave.xfer_size = 0;
+
+ /* Create new slave address map. */
+ map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
+ dev_dir, NULL);
+
+ if (dma_mapping_error(chan->device->dev, map->addr)) {
+ dev_err(chan->device->dev,
+ "chan%u: failed to map %zx@%pap", rchan->index,
+ dev_size, &dev_addr);
+ return -EIO;
+ }
+
+ dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
+ rchan->index, dev_size, &dev_addr, &map->addr,
+ dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
+
+ map->slave.slave_addr = dev_addr;
+ map->slave.xfer_size = dev_size;
+ map->dir = dev_dir;
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *
rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction dir,
unsigned long flags, void *context)
{
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
- dma_addr_t dev_addr;
/* Someone calling slave DMA on a generic channel? */
if (rchan->mid_rid < 0 || !sg_len) {
@@ -1043,9 +1108,10 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
return NULL;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
+ return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, false);
}
@@ -1059,7 +1125,6 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
struct dma_async_tx_descriptor *desc;
struct scatterlist *sgl;
- dma_addr_t dev_addr;
unsigned int sg_len;
unsigned int i;
@@ -1071,6 +1136,9 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
return NULL;
}
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
sg_len = buf_len / period_len;
if (sg_len > RCAR_DMAC_MAX_SG_LEN) {
dev_err(chan->device->dev,
@@ -1098,9 +1166,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
sg_dma_len(&sgl[i]) = period_len;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, true);
kfree(sgl);
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
Enable slave transfers to a device behind a IPMMU by mapping the slave
addresses using the dma-mapping API.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/dma/sh/rcar-dmac.c | 82 +++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index b0c3bb2..8592598 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -128,6 +128,18 @@ struct rcar_dmac_chan_slave {
};
/*
+ * struct rcar_dmac_chan_map - Map of slave device phys to dma address
+ * @addr: slave dma address
+ * @dir: direction of mapping
+ * @slave: slave configuration that is mapped
+ */
+struct rcar_dmac_chan_map {
+ dma_addr_t addr;
+ enum dma_data_direction dir;
+ struct rcar_dmac_chan_slave slave;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
@@ -152,6 +164,7 @@ struct rcar_dmac_chan {
struct rcar_dmac_chan_slave src;
struct rcar_dmac_chan_slave dst;
+ struct rcar_dmac_chan_map map;
int mid_rid;
spinlock_t lock;
@@ -1027,13 +1040,65 @@ rcar_dmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
DMA_MEM_TO_MEM, flags, false);
}
+static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
+ enum dma_transfer_direction dir)
+{
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+ struct rcar_dmac_chan_map *map = &rchan->map;
+ phys_addr_t dev_addr;
+ size_t dev_size;
+ enum dma_data_direction dev_dir;
+
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = rchan->src.slave_addr;
+ dev_size = rchan->src.xfer_size;
+ dev_dir = DMA_TO_DEVICE;
+ } else {
+ dev_addr = rchan->dst.slave_addr;
+ dev_size = rchan->dst.xfer_size;
+ dev_dir = DMA_FROM_DEVICE;
+ }
+
+ /* Reuse current map if possible. */
+ if (dev_addr == map->slave.slave_addr &&
+ dev_size == map->slave.xfer_size &&
+ dev_dir == map->dir)
+ return 0;
+
+ /* Remove old mapping if present. */
+ if (map->slave.xfer_size)
+ dma_unmap_resource(chan->device->dev, map->addr,
+ map->slave.xfer_size, map->dir, NULL);
+ map->slave.xfer_size = 0;
+
+ /* Create new slave address map. */
+ map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
+ dev_dir, NULL);
+
+ if (dma_mapping_error(chan->device->dev, map->addr)) {
+ dev_err(chan->device->dev,
+ "chan%u: failed to map %zx@%pap", rchan->index,
+ dev_size, &dev_addr);
+ return -EIO;
+ }
+
+ dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
+ rchan->index, dev_size, &dev_addr, &map->addr,
+ dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
+
+ map->slave.slave_addr = dev_addr;
+ map->slave.xfer_size = dev_size;
+ map->dir = dev_dir;
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *
rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction dir,
unsigned long flags, void *context)
{
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
- dma_addr_t dev_addr;
/* Someone calling slave DMA on a generic channel? */
if (rchan->mid_rid < 0 || !sg_len) {
@@ -1043,9 +1108,10 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
return NULL;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
+ return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, false);
}
@@ -1059,7 +1125,6 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
struct dma_async_tx_descriptor *desc;
struct scatterlist *sgl;
- dma_addr_t dev_addr;
unsigned int sg_len;
unsigned int i;
@@ -1071,6 +1136,9 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
return NULL;
}
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
sg_len = buf_len / period_len;
if (sg_len > RCAR_DMAC_MAX_SG_LEN) {
dev_err(chan->device->dev,
@@ -1098,9 +1166,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
sg_dma_len(&sgl[i]) = period_len;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, true);
kfree(sgl);
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Enable slave transfers to a device behind a IPMMU by mapping the slave
addresses using the dma-mapping API.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/dma/sh/rcar-dmac.c | 82 +++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index b0c3bb2..8592598 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -128,6 +128,18 @@ struct rcar_dmac_chan_slave {
};
/*
+ * struct rcar_dmac_chan_map - Map of slave device phys to dma address
+ * @addr: slave dma address
+ * @dir: direction of mapping
+ * @slave: slave configuration that is mapped
+ */
+struct rcar_dmac_chan_map {
+ dma_addr_t addr;
+ enum dma_data_direction dir;
+ struct rcar_dmac_chan_slave slave;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
@@ -152,6 +164,7 @@ struct rcar_dmac_chan {
struct rcar_dmac_chan_slave src;
struct rcar_dmac_chan_slave dst;
+ struct rcar_dmac_chan_map map;
int mid_rid;
spinlock_t lock;
@@ -1027,13 +1040,65 @@ rcar_dmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
DMA_MEM_TO_MEM, flags, false);
}
+static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
+ enum dma_transfer_direction dir)
+{
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+ struct rcar_dmac_chan_map *map = &rchan->map;
+ phys_addr_t dev_addr;
+ size_t dev_size;
+ enum dma_data_direction dev_dir;
+
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = rchan->src.slave_addr;
+ dev_size = rchan->src.xfer_size;
+ dev_dir = DMA_TO_DEVICE;
+ } else {
+ dev_addr = rchan->dst.slave_addr;
+ dev_size = rchan->dst.xfer_size;
+ dev_dir = DMA_FROM_DEVICE;
+ }
+
+ /* Reuse current map if possible. */
+ if (dev_addr == map->slave.slave_addr &&
+ dev_size == map->slave.xfer_size &&
+ dev_dir == map->dir)
+ return 0;
+
+ /* Remove old mapping if present. */
+ if (map->slave.xfer_size)
+ dma_unmap_resource(chan->device->dev, map->addr,
+ map->slave.xfer_size, map->dir, NULL);
+ map->slave.xfer_size = 0;
+
+ /* Create new slave address map. */
+ map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
+ dev_dir, NULL);
+
+ if (dma_mapping_error(chan->device->dev, map->addr)) {
+ dev_err(chan->device->dev,
+ "chan%u: failed to map %zx@%pap", rchan->index,
+ dev_size, &dev_addr);
+ return -EIO;
+ }
+
+ dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
+ rchan->index, dev_size, &dev_addr, &map->addr,
+ dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
+
+ map->slave.slave_addr = dev_addr;
+ map->slave.xfer_size = dev_size;
+ map->dir = dev_dir;
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *
rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction dir,
unsigned long flags, void *context)
{
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
- dma_addr_t dev_addr;
/* Someone calling slave DMA on a generic channel? */
if (rchan->mid_rid < 0 || !sg_len) {
@@ -1043,9 +1108,10 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
return NULL;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
+ return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, false);
}
@@ -1059,7 +1125,6 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
struct dma_async_tx_descriptor *desc;
struct scatterlist *sgl;
- dma_addr_t dev_addr;
unsigned int sg_len;
unsigned int i;
@@ -1071,6 +1136,9 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
return NULL;
}
+ if (rcar_dmac_map_slave_addr(chan, dir))
+ return NULL;
+
sg_len = buf_len / period_len;
if (sg_len > RCAR_DMAC_MAX_SG_LEN) {
dev_err(chan->device->dev,
@@ -1098,9 +1166,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
sg_dma_len(&sgl[i]) = period_len;
}
- dev_addr = dir == DMA_DEV_TO_MEM
- ? rchan->src.slave_addr : rchan->dst.slave_addr;
- desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
+ desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, rchan->map.addr,
dir, flags, true);
kfree(sgl);
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 404ef2b..2912320 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -336,6 +336,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller@e6720000 {
@@ -367,6 +382,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller@ec700000 {
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 404ef2b..2912320 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -336,6 +336,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller@e6720000 {
@@ -367,6 +382,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller@ec700000 {
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 404ef2b..2912320 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -336,6 +336,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller at e6720000 {
@@ -367,6 +382,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller at ec700000 {
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch
Cc: robin.murphy, laurent.pinchart, geert+renesas, linus.walleij,
dan.j.williams, arnd, linux-arch, Niklas Söderlund
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4f01b64..dc81c90 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -313,6 +313,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller@e6720000 {
@@ -344,6 +359,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller@ec700000 {
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
hch-wEGCiKHe2LqWVfeAwA7xHQ
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Niklas Söderlund,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4f01b64..dc81c90 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -313,6 +313,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller@e6720000 {
@@ -344,6 +359,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller@ec700000 {
--
2.8.2
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCHv6 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
@ 2016-05-09 16:44 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4f01b64..dc81c90 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -313,6 +313,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+ <&ipmmu_ds 1>,
+ <&ipmmu_ds 2>,
+ <&ipmmu_ds 3>,
+ <&ipmmu_ds 4>,
+ <&ipmmu_ds 5>,
+ <&ipmmu_ds 6>,
+ <&ipmmu_ds 7>,
+ <&ipmmu_ds 8>,
+ <&ipmmu_ds 9>,
+ <&ipmmu_ds 10>,
+ <&ipmmu_ds 11>,
+ <&ipmmu_ds 12>,
+ <&ipmmu_ds 13>,
+ <&ipmmu_ds 14>;
};
dmac1: dma-controller at e6720000 {
@@ -344,6 +359,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+ <&ipmmu_ds 16>,
+ <&ipmmu_ds 17>,
+ <&ipmmu_ds 18>,
+ <&ipmmu_ds 19>,
+ <&ipmmu_ds 20>,
+ <&ipmmu_ds 21>,
+ <&ipmmu_ds 22>,
+ <&ipmmu_ds 23>,
+ <&ipmmu_ds 24>,
+ <&ipmmu_ds 25>,
+ <&ipmmu_ds 26>,
+ <&ipmmu_ds 27>,
+ <&ipmmu_ds 28>,
+ <&ipmmu_ds 29>;
};
audma0: dma-controller at ec700000 {
--
2.8.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-17 14:50 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:50 UTC (permalink / raw)
To: Niklas Söderlund
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> + int direction, dma_addr_t dma_addr)
> +{
> + struct dma_debug_entry *entry;
> +
> + if (unlikely(dma_debug_disabled()))
> + return;
> +
> + entry = dma_entry_alloc();
> + if (!entry)
> + return;
> +
> + entry->type = dma_debug_resource;
> + entry->dev = dev;
> + entry->pfn = __phys_to_pfn(addr);
> + entry->offset = addr - PHYS_PFN(entry->pfn);
Is that right?
__phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
addr - PHYS_PFN(PHYS_PFN(addr)) ?
> + entry->size = size;
> + entry->dev_addr = dma_addr;
> + entry->direction = direction;
> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> +
> + add_dma_entry(entry);
> +}
> +EXPORT_SYMBOL(debug_dma_map_resource);
> +
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-17 14:50 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:50 UTC (permalink / raw)
To: Niklas Söderlund
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, hch-wEGCiKHe2LqWVfeAwA7xHQ,
arnd-r2nGTMty4D4, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> + int direction, dma_addr_t dma_addr)
> +{
> + struct dma_debug_entry *entry;
> +
> + if (unlikely(dma_debug_disabled()))
> + return;
> +
> + entry = dma_entry_alloc();
> + if (!entry)
> + return;
> +
> + entry->type = dma_debug_resource;
> + entry->dev = dev;
> + entry->pfn = __phys_to_pfn(addr);
> + entry->offset = addr - PHYS_PFN(entry->pfn);
Is that right?
__phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
addr - PHYS_PFN(PHYS_PFN(addr)) ?
> + entry->size = size;
> + entry->dev_addr = dma_addr;
> + entry->direction = direction;
> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> +
> + add_dma_entry(entry);
> +}
> +EXPORT_SYMBOL(debug_dma_map_resource);
> +
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-17 14:50 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:50 UTC (permalink / raw)
To: linux-arm-kernel
> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> + int direction, dma_addr_t dma_addr)
> +{
> + struct dma_debug_entry *entry;
> +
> + if (unlikely(dma_debug_disabled()))
> + return;
> +
> + entry = dma_entry_alloc();
> + if (!entry)
> + return;
> +
> + entry->type = dma_debug_resource;
> + entry->dev = dev;
> + entry->pfn = __phys_to_pfn(addr);
> + entry->offset = addr - PHYS_PFN(entry->pfn);
Is that right?
__phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
addr - PHYS_PFN(PHYS_PFN(addr)) ?
> + entry->size = size;
> + entry->dev_addr = dma_addr;
> + entry->direction = direction;
> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> +
> + add_dma_entry(entry);
> +}
> +EXPORT_SYMBOL(debug_dma_map_resource);
> +
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-17 14:54 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:54 UTC (permalink / raw)
To: Niklas Söderlund
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
>
> -In some circumstances dma_map_single() and dma_map_page() will fail to create
> -a mapping. A driver can check for these errors by testing the returned
> -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> -could not be created and the driver should take appropriate action (e.g.
> -reduce current DMA mapping usage or delay and try again later).
> +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> +will fail to create a mapping. A driver can check for these errors by testing
> +the returned DMA address with dma_mapping_error(). A non-zero return value
> +means the mapping could not be created and the driver should take appropriate
> +action (e.g. reduce current DMA mapping usage or delay and try again later).
This looks like it belongs to another patch?
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-17 14:54 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:54 UTC (permalink / raw)
To: Niklas Söderlund
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, hch-wEGCiKHe2LqWVfeAwA7xHQ,
arnd-r2nGTMty4D4, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
>
> -In some circumstances dma_map_single() and dma_map_page() will fail to create
> -a mapping. A driver can check for these errors by testing the returned
> -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> -could not be created and the driver should take appropriate action (e.g.
> -reduce current DMA mapping usage or delay and try again later).
> +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> +will fail to create a mapping. A driver can check for these errors by testing
> +the returned DMA address with dma_mapping_error(). A non-zero return value
> +means the mapping could not be created and the driver should take appropriate
> +action (e.g. reduce current DMA mapping usage or delay and try again later).
This looks like it belongs to another patch?
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-17 14:54 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-17 14:54 UTC (permalink / raw)
To: linux-arm-kernel
>
> -In some circumstances dma_map_single() and dma_map_page() will fail to create
> -a mapping. A driver can check for these errors by testing the returned
> -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> -could not be created and the driver should take appropriate action (e.g.
> -reduce current DMA mapping usage or delay and try again later).
> +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> +will fail to create a mapping. A driver can check for these errors by testing
> +the returned DMA address with dma_mapping_error(). A non-zero return value
> +means the mapping could not be created and the driver should take appropriate
> +action (e.g. reduce current DMA mapping usage or delay and try again later).
This looks like it belongs to another patch?
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
2016-05-17 14:50 ` Konrad Rzeszutek Wilk
(?)
@ 2016-05-19 11:21 ` Niklas Söderlund
-1 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
> > +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> > + int direction, dma_addr_t dma_addr)
> > +{
> > + struct dma_debug_entry *entry;
> > +
> > + if (unlikely(dma_debug_disabled()))
> > + return;
> > +
> > + entry = dma_entry_alloc();
> > + if (!entry)
> > + return;
> > +
> > + entry->type = dma_debug_resource;
> > + entry->dev = dev;
> > + entry->pfn = __phys_to_pfn(addr);
> > + entry->offset = addr - PHYS_PFN(entry->pfn);
>
> Is that right?
You are correct that should be:
entry->offset = addr - PFN_PHYS(entry->pfn);
Or even better:
entry->offset = addr - __pfn_to_phys(entry->pfn);
I will address this and resend late next week, still hoping for some
more feedback.
>
> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>
> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>
>
> > + entry->size = size;
> > + entry->dev_addr = dma_addr;
> > + entry->direction = direction;
> > + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> > +
> > + add_dma_entry(entry);
> > +}
> > +EXPORT_SYMBOL(debug_dma_map_resource);
> > +
--
Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-19 11:21 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
> > +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> > + int direction, dma_addr_t dma_addr)
> > +{
> > + struct dma_debug_entry *entry;
> > +
> > + if (unlikely(dma_debug_disabled()))
> > + return;
> > +
> > + entry = dma_entry_alloc();
> > + if (!entry)
> > + return;
> > +
> > + entry->type = dma_debug_resource;
> > + entry->dev = dev;
> > + entry->pfn = __phys_to_pfn(addr);
> > + entry->offset = addr - PHYS_PFN(entry->pfn);
>
> Is that right?
You are correct that should be:
entry->offset = addr - PFN_PHYS(entry->pfn);
Or even better:
entry->offset = addr - __pfn_to_phys(entry->pfn);
I will address this and resend late next week, still hoping for some
more feedback.
>
> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>
> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>
>
> > + entry->size = size;
> > + entry->dev_addr = dma_addr;
> > + entry->direction = direction;
> > + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> > +
> > + add_dma_entry(entry);
> > +}
> > +EXPORT_SYMBOL(debug_dma_map_resource);
> > +
--
Regards,
Niklas S�derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-19 11:21 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
> > +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
> > + int direction, dma_addr_t dma_addr)
> > +{
> > + struct dma_debug_entry *entry;
> > +
> > + if (unlikely(dma_debug_disabled()))
> > + return;
> > +
> > + entry = dma_entry_alloc();
> > + if (!entry)
> > + return;
> > +
> > + entry->type = dma_debug_resource;
> > + entry->dev = dev;
> > + entry->pfn = __phys_to_pfn(addr);
> > + entry->offset = addr - PHYS_PFN(entry->pfn);
>
> Is that right?
You are correct that should be:
entry->offset = addr - PFN_PHYS(entry->pfn);
Or even better:
entry->offset = addr - __pfn_to_phys(entry->pfn);
I will address this and resend late next week, still hoping for some
more feedback.
>
> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>
> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>
>
> > + entry->size = size;
> > + entry->dev_addr = dma_addr;
> > + entry->direction = direction;
> > + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> > +
> > + add_dma_entry(entry);
> > +}
> > +EXPORT_SYMBOL(debug_dma_map_resource);
> > +
--
Regards,
Niklas S?derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
2016-05-17 14:54 ` Konrad Rzeszutek Wilk
(?)
@ 2016-05-19 11:29 ` Niklas Söderlund
-1 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > -a mapping. A driver can check for these errors by testing the returned
> > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > -could not be created and the driver should take appropriate action (e.g.
> > -reduce current DMA mapping usage or delay and try again later).
> > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > +will fail to create a mapping. A driver can check for these errors by testing
> > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > +means the mapping could not be created and the driver should take appropriate
> > +action (e.g. reduce current DMA mapping usage or delay and try again later).
>
> This looks like it belongs to another patch?
No it is correct (at least intended to be in this patch). All it really
do is inject dma_map_resource() (which is added in this patch) as one of
the calls which return dma_addr_t should be checked for error using
dma_mapping_error(). But yes the change effect all lines in the
paragraph due to line wrapping.
Hum or maybe I'm misunderstanding your question.
--
Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-19 11:29 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > -a mapping. A driver can check for these errors by testing the returned
> > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > -could not be created and the driver should take appropriate action (e.g.
> > -reduce current DMA mapping usage or delay and try again later).
> > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > +will fail to create a mapping. A driver can check for these errors by testing
> > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > +means the mapping could not be created and the driver should take appropriate
> > +action (e.g. reduce current DMA mapping usage or delay and try again later).
>
> This looks like it belongs to another patch?
No it is correct (at least intended to be in this patch). All it really
do is inject dma_map_resource() (which is added in this patch) as one of
the calls which return dma_addr_t should be checked for error using
dma_mapping_error(). But yes the change effect all lines in the
paragraph due to line wrapping.
Hum or maybe I'm misunderstanding your question.
--
Regards,
Niklas S�derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-19 11:29 ` Niklas Söderlund
0 siblings, 0 replies; 44+ messages in thread
From: Niklas Söderlund @ 2016-05-19 11:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > -a mapping. A driver can check for these errors by testing the returned
> > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > -could not be created and the driver should take appropriate action (e.g.
> > -reduce current DMA mapping usage or delay and try again later).
> > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > +will fail to create a mapping. A driver can check for these errors by testing
> > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > +means the mapping could not be created and the driver should take appropriate
> > +action (e.g. reduce current DMA mapping usage or delay and try again later).
>
> This looks like it belongs to another patch?
No it is correct (at least intended to be in this patch). All it really
do is inject dma_map_resource() (which is added in this patch) as one of
the calls which return dma_addr_t should be checked for error using
dma_mapping_error(). But yes the change effect all lines in the
paragraph due to line wrapping.
Hum or maybe I'm misunderstanding your question.
--
Regards,
Niklas S?derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
2016-05-19 11:21 ` Niklas Söderlund
(?)
@ 2016-05-19 11:42 ` Robin Murphy
-1 siblings, 0 replies; 44+ messages in thread
From: Robin Murphy @ 2016-05-19 11:42 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, vinod.koul, linux-renesas-soc,
linux-arm-kernel, linux-kernel, dmaengine, iommu, hch,
linux-arch, geert+renesas, arnd, linus.walleij, laurent.pinchart,
dan.j.williams
On 19/05/16 12:21, Niklas Söderlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
>>> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
>>> + int direction, dma_addr_t dma_addr)
>>> +{
>>> + struct dma_debug_entry *entry;
>>> +
>>> + if (unlikely(dma_debug_disabled()))
>>> + return;
>>> +
>>> + entry = dma_entry_alloc();
>>> + if (!entry)
>>> + return;
>>> +
>>> + entry->type = dma_debug_resource;
>>> + entry->dev = dev;
>>> + entry->pfn = __phys_to_pfn(addr);
>>> + entry->offset = addr - PHYS_PFN(entry->pfn);
>>
>> Is that right?
>
> You are correct that should be:
>
> entry->offset = addr - PFN_PHYS(entry->pfn);
>
> Or even better:
>
> entry->offset = addr - __pfn_to_phys(entry->pfn);
Better still, simply offset_in_page(addr) (as per dma_map_single()).
Robin.
> I will address this and resend late next week, still hoping for some
> more feedback.
>
>>
>> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>>
>> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>>
>>
>>> + entry->size = size;
>>> + entry->dev_addr = dma_addr;
>>> + entry->direction = direction;
>>> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
>>> +
>>> + add_dma_entry(entry);
>>> +}
>>> +EXPORT_SYMBOL(debug_dma_map_resource);
>>> +
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-19 11:42 ` Robin Murphy
0 siblings, 0 replies; 44+ messages in thread
From: Robin Murphy @ 2016-05-19 11:42 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, vinod.koul, linux-renesas-soc,
linux-arm-kernel, linux-kernel, dmaengine, iommu, hch,
linux-arch, geert+renesas, arnd, linus.walleij, laurent.pinchart,
dan.j.williams
On 19/05/16 12:21, Niklas S�derlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
>>> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
>>> + int direction, dma_addr_t dma_addr)
>>> +{
>>> + struct dma_debug_entry *entry;
>>> +
>>> + if (unlikely(dma_debug_disabled()))
>>> + return;
>>> +
>>> + entry = dma_entry_alloc();
>>> + if (!entry)
>>> + return;
>>> +
>>> + entry->type = dma_debug_resource;
>>> + entry->dev = dev;
>>> + entry->pfn = __phys_to_pfn(addr);
>>> + entry->offset = addr - PHYS_PFN(entry->pfn);
>>
>> Is that right?
>
> You are correct that should be:
>
> entry->offset = addr - PFN_PHYS(entry->pfn);
>
> Or even better:
>
> entry->offset = addr - __pfn_to_phys(entry->pfn);
Better still, simply offset_in_page(addr) (as per dma_map_single()).
Robin.
> I will address this and resend late next week, still hoping for some
> more feedback.
>
>>
>> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>>
>> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>>
>>
>>> + entry->size = size;
>>> + entry->dev_addr = dma_addr;
>>> + entry->direction = direction;
>>> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
>>> +
>>> + add_dma_entry(entry);
>>> +}
>>> +EXPORT_SYMBOL(debug_dma_map_resource);
>>> +
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 2/8] dma-debug: add support for resource mappings
@ 2016-05-19 11:42 ` Robin Murphy
0 siblings, 0 replies; 44+ messages in thread
From: Robin Murphy @ 2016-05-19 11:42 UTC (permalink / raw)
To: linux-arm-kernel
On 19/05/16 12:21, Niklas S?derlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
>>> +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
>>> + int direction, dma_addr_t dma_addr)
>>> +{
>>> + struct dma_debug_entry *entry;
>>> +
>>> + if (unlikely(dma_debug_disabled()))
>>> + return;
>>> +
>>> + entry = dma_entry_alloc();
>>> + if (!entry)
>>> + return;
>>> +
>>> + entry->type = dma_debug_resource;
>>> + entry->dev = dev;
>>> + entry->pfn = __phys_to_pfn(addr);
>>> + entry->offset = addr - PHYS_PFN(entry->pfn);
>>
>> Is that right?
>
> You are correct that should be:
>
> entry->offset = addr - PFN_PHYS(entry->pfn);
>
> Or even better:
>
> entry->offset = addr - __pfn_to_phys(entry->pfn);
Better still, simply offset_in_page(addr) (as per dma_map_single()).
Robin.
> I will address this and resend late next week, still hoping for some
> more feedback.
>
>>
>> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>>
>> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>>
>>
>>> + entry->size = size;
>>> + entry->dev_addr = dma_addr;
>>> + entry->direction = direction;
>>> + entry->map_err_type = MAP_ERR_NOT_CHECKED;
>>> +
>>> + add_dma_entry(entry);
>>> +}
>>> +EXPORT_SYMBOL(debug_dma_map_resource);
>>> +
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
2016-05-19 11:29 ` Niklas Söderlund
(?)
@ 2016-05-19 14:22 ` Konrad Rzeszutek Wilk
-1 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-19 14:22 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas Söderlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> > >
> > > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > > -a mapping. A driver can check for these errors by testing the returned
> > > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > > -could not be created and the driver should take appropriate action (e.g.
> > > -reduce current DMA mapping usage or delay and try again later).
> > > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > > +will fail to create a mapping. A driver can check for these errors by testing
> > > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > > +means the mapping could not be created and the driver should take appropriate
> > > +action (e.g. reduce current DMA mapping usage or delay and try again later).
> >
> > This looks like it belongs to another patch?
>
> No it is correct (at least intended to be in this patch). All it really
> do is inject dma_map_resource() (which is added in this patch) as one of
> the calls which return dma_addr_t should be checked for error using
> dma_mapping_error(). But yes the change effect all lines in the
> paragraph due to line wrapping.
>
> Hum or maybe I'm misunderstanding your question.
I totally missed the 'dma_map_resource' in there and just read
'dma_mapping_error'!
<sigh> Thanks.
>
> --
> Regards,
> Niklas Söderlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-19 14:22 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-19 14:22 UTC (permalink / raw)
To: vinod.koul, linux-renesas-soc, linux-arm-kernel, linux-kernel,
dmaengine, iommu, hch, linux-arch, geert+renesas, arnd,
linus.walleij, laurent.pinchart, dan.j.williams
On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas S�derlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> > >
> > > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > > -a mapping. A driver can check for these errors by testing the returned
> > > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > > -could not be created and the driver should take appropriate action (e.g.
> > > -reduce current DMA mapping usage or delay and try again later).
> > > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > > +will fail to create a mapping. A driver can check for these errors by testing
> > > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > > +means the mapping could not be created and the driver should take appropriate
> > > +action (e.g. reduce current DMA mapping usage or delay and try again later).
> >
> > This looks like it belongs to another patch?
>
> No it is correct (at least intended to be in this patch). All it really
> do is inject dma_map_resource() (which is added in this patch) as one of
> the calls which return dma_addr_t should be checked for error using
> dma_mapping_error(). But yes the change effect all lines in the
> paragraph due to line wrapping.
>
> Hum or maybe I'm misunderstanding your question.
I totally missed the 'dma_map_resource' in there and just read
'dma_mapping_error'!
<sigh> Thanks.
>
> --
> Regards,
> Niklas S�derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
@ 2016-05-19 14:22 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 44+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-19 14:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas S?derlund wrote:
> Hi Konrad,
>
> Thanks for your feedback.
>
> On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote:
> > >
> > > -In some circumstances dma_map_single() and dma_map_page() will fail to create
> > > -a mapping. A driver can check for these errors by testing the returned
> > > -DMA address with dma_mapping_error(). A non-zero return value means the mapping
> > > -could not be created and the driver should take appropriate action (e.g.
> > > -reduce current DMA mapping usage or delay and try again later).
> > > +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> > > +will fail to create a mapping. A driver can check for these errors by testing
> > > +the returned DMA address with dma_mapping_error(). A non-zero return value
> > > +means the mapping could not be created and the driver should take appropriate
> > > +action (e.g. reduce current DMA mapping usage or delay and try again later).
> >
> > This looks like it belongs to another patch?
>
> No it is correct (at least intended to be in this patch). All it really
> do is inject dma_map_resource() (which is added in this patch) as one of
> the calls which return dma_addr_t should be checked for error using
> dma_mapping_error(). But yes the change effect all lines in the
> paragraph due to line wrapping.
>
> Hum or maybe I'm misunderstanding your question.
I totally missed the 'dma_map_resource' in there and just read
'dma_mapping_error'!
<sigh> Thanks.
>
> --
> Regards,
> Niklas S?derlund
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2016-05-19 14:24 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-09 16:43 [PATCHv6 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-05-09 16:43 ` Niklas Söderlund
2016-05-09 16:43 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 1/8] dma-mapping: add {map,unmap}_resource to dma_map_ops Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 2/8] dma-debug: add support for resource mappings Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-17 14:50 ` Konrad Rzeszutek Wilk
2016-05-17 14:50 ` Konrad Rzeszutek Wilk
2016-05-17 14:50 ` Konrad Rzeszutek Wilk
2016-05-19 11:21 ` Niklas Söderlund
2016-05-19 11:21 ` Niklas Söderlund
2016-05-19 11:21 ` Niklas Söderlund
2016-05-19 11:42 ` Robin Murphy
2016-05-19 11:42 ` Robin Murphy
2016-05-19 11:42 ` Robin Murphy
2016-05-09 16:44 ` [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-17 14:54 ` Konrad Rzeszutek Wilk
2016-05-17 14:54 ` Konrad Rzeszutek Wilk
2016-05-17 14:54 ` Konrad Rzeszutek Wilk
2016-05-19 11:29 ` Niklas Söderlund
2016-05-19 11:29 ` Niklas Söderlund
2016-05-19 11:29 ` Niklas Söderlund
2016-05-19 14:22 ` Konrad Rzeszutek Wilk
2016-05-19 14:22 ` Konrad Rzeszutek Wilk
2016-05-19 14:22 ` Konrad Rzeszutek Wilk
2016-05-09 16:44 ` [PATCHv6 4/8] arm: dma-mapping: add {map,unmap}_resource for iommu ops Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 4/8] arm: dma-mapping: add {map, unmap}_resource " Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 5/8] dmaengine: rcar-dmac: group slave configuration Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1 Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` [PATCHv6 8/8] ARM: dts: r8a7791: " Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
2016-05-09 16:44 ` Niklas Söderlund
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.