From: Rob Clark <robdclark(a)gmail.com>
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark <robdclark(a)gmail.com>
[sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org>
---
v3: include Robin Murphy's fix[1] for handling '0' as a value for
max_segment_count
v2: minor updates wrt comments on the first version
[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count; /* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ if (dev->dma_parms && dev->dma_parms->max_segment_count)
+ return dev->dma_parms->max_segment_count;
+ return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev->dma_parms) {
+ dev->dma_parms->max_segment_count = count;
+ return 0;
+ }
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev->dma_parms ?
--
1.9.1
Hello Everyone,
This is yet another attempt to get Exynos SYSMMU driver with integrated
with IOMMU & DMA-mapping subsystems. The main change from previous
version is a rebase onto some more pending Exynos DTS patches and minor
fixes of the reported issues.
Merge plan for this patchset:
1. All iommu related patches (with 'iommu: exynos') can be merged to
iommu tree. They don't have any direct dependencies on the DTS, DRM and
power domain initialization change - without them the driver will simply
not initialize, when no exynos,sysmmu nodes are provided in device tree.
Joerg, could you merge those patches?
2. DTS and power domain patches should go to Samsung Exynos tree. Those
patches depends on earlier DTS patches for Exynos SoCs, which make
this patchset really complete:
- 'ARM: DTS: Exynos: convert to generic power domain bindings'
(http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
- '[PATCH v4 0/7] Enable HDMI support on Exynos platforms'
(http://www.spinics.net/lists/arm-kernel/msg391148.html)
- '[PATCH 0/2] Add HDMI support for Exynos5420 platform'
(http://www.spinics.net/lists/linux-samsung-soc/msg41364.html)
Kukjin, could you merge those patches?
3. Exynos DRM fix. This patch in my opinion should go Exynos DRM tree.
Inki, could you merge it?
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v5:
- rebased onto 'Add HDMI support for Exynos5420 platform' patchset
- fixed 'const' issue in 'iommu: exynos: init from dt-specific callback
instead of initcall' patch, thanks to Tobias Jakobi for reporting it
- fixed copy-paste typo in exynos5250 dts patch
v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html
- rebased onto v3.19-rc4 and other Exynos DTS queued patches
- added DTS patch for Exynos 5250 & 5420/5422/5800
v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html
- rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA
configuration for IOMMU masters"
- added some minor fixes for iommu and dma-mapping frameworks
v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/
- rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA
configuration for IOMMU masters" patches:
http://www.spinics.net/lists/arm-kernel/msg362076.html
- changed initialization from bus notifiers to DT related callbacks
- removed support for separate IO address spaces - this will be
discussed separately after the basic support gets merged
- removed support for power domain notifier-based runtime power
management - this also will be discussed separately later
v1: https://lkml.org/lkml/2014/8/5/183
- initial version, feature complete, completely rewrote integration
approach
Patch summary:
Marek Szyprowski (18):
drm: exynos: detach from default dma-mapping domain on init
arm: exynos: pm_domains: add support for devices registered before
arch_initcall
ARM: dts: exynos4: add sysmmu nodes
ARM: dts: exynos5250: add sysmmu nodes
ARM: dts: exynos5420: add sysmmu nodes
iommu: exynos: don't read version register on every tlb operation
iommu: exynos: remove unused functions
iommu: exynos: remove useless spinlock
iommu: exynos: refactor function parameters to simplify code
iommu: exynos: remove unused functions, part 2
iommu: exynos: remove useless device_add/remove callbacks
iommu: exynos: add support for binding more than one sysmmu to master
device
iommu: exynos: add support for runtime_pm
iommu: exynos: rename variables to reflect their purpose
iommu: exynos: document internal structures
iommu: exynos: remove excessive includes and sort others
alphabetically
iommu: exynos: init from dt-specific callback instead of initcall
iommu: exynos: add callback for initializing devices from device tree
arch/arm/boot/dts/exynos4.dtsi | 118 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 23 ++
arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++
arch/arm/boot/dts/exynos5250.dtsi | 250 +++++++++++++++
arch/arm/boot/dts/exynos5420.dtsi | 181 +++++++++++
arch/arm/mach-exynos/pm_domains.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +
drivers/iommu/exynos-iommu.c | 492 ++++++++++++++----------------
8 files changed, 888 insertions(+), 270 deletions(-)
--
1.9.2
Hello Everyone,
Based on review comments received, I've split my earlier patchset on
'dma-buf constraints-enabled allocation' [1] into 2 sets:
- first one is this one, to use dma_parms and related parameters from
struct device to share constraints, and then to use these constraints in
dma-buf to help find the least common constraint set that could then be
used by exporters to decide on allocation.
This is a partial re-write of what Rob Clark proposed some while ago [2];
I've tried to take care of review comments on his patchset, but any errors
and omissions are, ofcourse, mine.
- Second part, one which I'm working on, and will post soon, aims at adding
allocator-helpers in dma-buf framework which could use this constraint
information to help choose the right allocator from a list.
While I work on the second part, I thought of sending the RFC for this one,
to get feedback on whether this mechanism seems ok to everyone.
[1] https://lkml.org/lkml/2014/10/10/340
[2] https://lkml.org/lkml/2012/7/19/285
Rob Clark (1):
device: add dma_params->max_segment_count
Sumit Semwal (1):
dma-buf: add helpers for sharing attacher constraints with dma-parms
drivers/dma-buf/dma-buf.c | 134 +++++++++++++++++++++++++++++++++++++++++++-
include/linux/device.h | 1 +
include/linux/dma-buf.h | 22 ++++++++
include/linux/dma-mapping.h | 19 +++++++
4 files changed, 175 insertions(+), 1 deletion(-)
--
1.9.1
Hi Michel,
On 22 January 2015 at 12:30, Michel Dänzer <michel(a)daenzer.net> wrote:
> From: Michel Dänzer <michel.daenzer(a)amd.com>
>
> It was causing the return value of fence_is_signaled to be ignored, making
> reservation objects signal too early.
>
Thanks; pushed to my for-next.
> Cc: stable(a)vger.kernel.org
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com>
> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com>
> ---
> drivers/dma-buf/reservation.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 3c97c8f..8a37af9 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -402,8 +402,6 @@ reservation_object_test_signaled_single(struct fence *passed_fence)
> int ret = 1;
>
> if (!test_bit(FENCE_FLAG_SIGNALED_BIT, &lfence->flags)) {
> - int ret;
> -
> fence = fence_get_rcu(lfence);
> if (!fence)
> return -1;
> --
> 2.1.4
>
--
Thanks and best regards,
Sumit.
Hi Robin!
On 22 January 2015 at 00:26, Robin Murphy <robin.murphy(a)arm.com> wrote:
> Hi Sumit,
>
>
> On 21/01/15 04:16, Sumit Semwal wrote:
>>
>> From: Rob Clark <robdclark(a)gmail.com>
>>
>> For devices which have constraints about maximum number of segments in
>> an sglist. For example, a device which could only deal with contiguous
>> buffers would set max_segment_count to 1.
>>
>> The initial motivation is for devices sharing buffers via dma-buf,
>> to allow the buffer exporter to know the constraints of other
>> devices which have attached to the buffer. The dma_mask and fields
>> in 'struct device_dma_parameters' tell the exporter everything else
>> that is needed, except whether the importer has constraints about
>> maximum number of segments.
>>
>> Signed-off-by: Rob Clark <robdclark(a)gmail.com>
>> [sumits: Minor updates wrt comments on the first version]
>> Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org>
>> ---
>> include/linux/device.h | 1 +
>> include/linux/dma-mapping.h | 19 +++++++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index fb50673..a32f9b6 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -647,6 +647,7 @@ struct device_dma_parameters {
>> * sg limitations.
>> */
>> unsigned int max_segment_size;
>> + unsigned int max_segment_count; /* INT_MAX for unlimited */
>> unsigned long segment_boundary_mask;
>> };
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index c3007cb..38e2835 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -154,6 +154,25 @@ static inline unsigned int
>> dma_set_max_seg_size(struct device *dev,
>> return -EIO;
>> }
>>
>> +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
>> +
>> +static inline unsigned int dma_get_max_seg_count(struct device *dev)
>> +{
>> + return dev->dma_parms ?
>> + dev->dma_parms->max_segment_count :
>> + DMA_SEGMENTS_MAX_SEG_COUNT;
>> +}
>
>
> I know this copies the style of the existing code, but unfortunately it also
> copies the subtle brokenness. Plenty of drivers seem to set up a dma_parms
> struct just for max_segment_size, thus chances are you'll come across a
> max_segment_count of 0 sooner or later. How badly is that going to break
> things? I posted a fix recently[1] having hit this problem with
> segment_boundary_mask in IOMMU code.
>
Thanks very much for reviewing this code; and apologies for missing
your patch that you mentioned here; sure, I will update my patch
accordingly as well.
>> +
>> +static inline int dma_set_max_seg_count(struct device *dev,
>> + unsigned int count)
>> +{
>> + if (dev->dma_parms) {
>> + dev->dma_parms->max_segment_count = count;
>> + return 0;
>> + } else
>
>
> This "else" is just as unnecessary as the other two I've taken out ;)
>
>
> Robin.
>
> [1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/
>
>
>> + return -EIO;
>> +}
>> +
>> static inline unsigned long dma_get_seg_boundary(struct device *dev)
>> {
>> return dev->dma_parms ?
>>
>
>
BR,
Sumit.
Hello Everyone,
This is yet another attempt to get Exynos SYSMMU driver with integrated
with IOMMU & DMA-mapping subsystems. The main change from previous
version is a rebase onto latest v3.19-rc4 kernel base, which includes
"automatic DMA configuration for IOMMU masters" patches developed by
Will Deacon. The other change is long avaited addition of DTS patches
for Exynos 5250 and 5420/5422/5800.
Merge plan for this patchset:
1. All iommu related patches (with 'iommu: exynos') can be merged to
iommu tree. They don't have any direct dependencies on the DTS, DRM and
power domain initialization change - without them the driver will simply
not initialize, when no exynos,sysmmu nodes are provided in device tree.
Joerg, could you merge those patches?
2. DTS and power domain patches should go to Samsung Exynos tree. Those
patches depends on my earlier DTS patches for Exynos SoCs, which make
this patchset really complete:
- 'ARM: DTS: Exynos: convert to generic power domain bindings'
(http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
- '[PATCH v3 0/7] Enable HDMI support on Exynos platforms'
(http://www.spinics.net/lists/arm-kernel/msg391148.html)
Kukjin, could you merge those patches?
3. Exynos DRM fix. This patch in my opinion should go Exynos DRM tree.
Inki, could you merge it?
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v4:
- rebased onto v3.19-rc4 and other Exynos DTS queued patches
- added DTS patch for Exynos 5250 & 5420/5422/5800
v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html
- rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA
configuration for IOMMU masters"
- added some minor fixes for iommu and dma-mapping frameworks
v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/
- rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA
configuration for IOMMU masters" patches:
http://www.spinics.net/lists/arm-kernel/msg362076.html
- changed initialization from bus notifiers to DT related callbacks
- removed support for separate IO address spaces - this will be
discussed separately after the basic support gets merged
- removed support for power domain notifier-based runtime power
management - this also will be discussed separately later
v1: https://lkml.org/lkml/2014/8/5/183
- initial version, feature complete, completely rewrote integration
approach
Patch summary:
Marek Szyprowski (18):
drm: exynos: detach from default dma-mapping domain on init
arm: exynos: pm_domains: add support for devices registered before
arch_initcall
ARM: dts: exynos4: add sysmmu nodes
ARM: dts: exynos5250: add sysmmu nodes
ARM: dts: exynos5420: add sysmmu nodes
iommu: exynos: don't read version register on every tlb operation
iommu: exynos: remove unused functions
iommu: exynos: remove useless spinlock
iommu: exynos: refactor function parameters to simplify code
iommu: exynos: remove unused functions, part 2
iommu: exynos: remove useless device_add/remove callbacks
iommu: exynos: add support for binding more than one sysmmu to master
device
iommu: exynos: add support for runtime_pm
iommu: exynos: rename variables to reflect their purpose
iommu: exynos: document internal structures
iommu: exynos: remove excessive includes and sort others
alphabetically
iommu: exynos: init from dt-specific callback instead of initcall
iommu: exynos: add callback for initializing devices from device tree
arch/arm/boot/dts/exynos4.dtsi | 118 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 23 ++
arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++
arch/arm/boot/dts/exynos5250.dtsi | 250 +++++++++++++++
arch/arm/boot/dts/exynos5420.dtsi | 178 +++++++++++
arch/arm/mach-exynos/pm_domains.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +
drivers/iommu/exynos-iommu.c | 490 ++++++++++++++----------------
8 files changed, 884 insertions(+), 269 deletions(-)
--
1.9.2