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
Hello David,
This series of patches fix various issues in STI drm driver.
Now HDMI i2c adapter could be selected in device tree
and plug detection doesn't use gpio anymore.
I also had fix some signal timing problems after testing the driver
on more hardware.
The remaining patches attemps to simplify the code and prepare
the next evolutions like DVO and auxiliary CRTC support
The changes could be fetch here:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
on drm-sti-fixes-2014-12-04 branch
I have tested this branch on top of commit:
"Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes" 00d6a9b6be5885ad38234cd171f6fb18a87faa7c
on drm-fixes branch.
Benjamin Gaignard (9):
drm: sti: allow to change hdmi ddc i2c adapter
drm: sti: remove gpio for HDMI hot plug detection
drm: sti: clear all mixer control
drm: sti: simplify gdp code
drm: sti: remove event lock while disabling vblank
drm: sti: fix hdmi avi infoframe
drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}
drm: sti: prepare sti_tvout to support auxiliary crtc
drm: sti: fix delay in VTG programming
.../devicetree/bindings/gpu/st,stih4xx.txt | 3 +-
drivers/gpu/drm/sti/sti_drm_crtc.c | 10 +--
drivers/gpu/drm/sti/sti_gdp.c | 39 ++++-----
drivers/gpu/drm/sti/sti_hdmi.c | 84 +++++++++++---------
drivers/gpu/drm/sti/sti_hdmi.h | 6 +-
drivers/gpu/drm/sti/sti_mixer.c | 9 +++
drivers/gpu/drm/sti/sti_mixer.h | 1 +
drivers/gpu/drm/sti/sti_tvout.c | 92 ++++++++++++----------
drivers/gpu/drm/sti/sti_vtg.c | 31 +++++++-
9 files changed, 166 insertions(+), 109 deletions(-)
--
1.9.1
Hello Everyone,
This is another attempt to finally make Exynos SYSMMU driver fully
integrated with DMA-mapping subsystem. The main change from previous
version is a rebase onto latest "automatic DMA configuration for IOMMU
masters" patches from Will Deacon.
This patchset demonstrates that Will's proposal works fine and
significantly simplifies the driver code.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v3:
- 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 (19):
iommu: fix const qualifier in of_iommu_set_ops
iommu: fix initialization without 'add_device' callback
arm: dma-mapping: add missing check for iommu
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
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 | 117 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 23 ++
arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++
arch/arm/mach-exynos/pm_domains.c | 9 +-
arch/arm/mm/dma-mapping.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +
drivers/iommu/exynos-iommu.c | 490 ++++++++++++++----------------
drivers/iommu/iommu.c | 2 +-
include/linux/of_iommu.h | 4 +-
9 files changed, 459 insertions(+), 273 deletions(-)
--
1.9.2
Hello Dave,
This patch enable the last big hardware feature of my driver: the
connector for panel.
Like for HMDI and HDA, Digital Video Out (DVO) create brige, encoder
and connector
drm objects.
The following changes since commit 4e0cd68115620bc3236ff4e58e4c073948629b41:
drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000)
are available in the git repository at:
http://git.linaro.org/people/benjamin.gaignard/kernel.git drm-sti-next-add-dvo
for you to fetch changes up to f32c4c506f9b197f24d4be4ee7283bd549e3a30f:
drm: sti: add DVO output connector (2014-12-30 15:08:16 +0100)
----------------------------------------------------------------
Benjamin Gaignard (1):
drm: sti: add DVO output connector
.../devicetree/bindings/gpu/st,stih4xx.txt | 29 ++
drivers/gpu/drm/sti/Makefile | 4 +
drivers/gpu/drm/sti/sti_awg_utils.c | 184 +++++++
drivers/gpu/drm/sti/sti_awg_utils.h | 34 ++
drivers/gpu/drm/sti/sti_dvo.c | 551 +++++++++++++++++++++
drivers/gpu/drm/sti/sti_tvout.c | 118 +++++
6 files changed, 920 insertions(+)
create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.c
create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.h
create mode 100644 drivers/gpu/drm/sti/sti_dvo.c
Hi,
Why:
====
While sharing buffers using dma-buf, currently there's no mechanism to let
devices share their memory access constraints with each other to allow for
delayed allocation of backing storage.
This RFC attempts to introduce the idea of memory constraints of a device,
and how these constraints can be shared and used to help allocate buffers that
can satisfy requirements of all devices attached to a particular dma-buf.
How:
====
A constraints_mask is added to dma_parms of the device, and at the time of
each device attachment to a dma-buf, the dma-buf uses this constraints_mask
to calculate the access_mask for the dma-buf.
Allocators can be defined for each of these constraints_masks, and then helper
functions can be used to allocate the backing storage from the matching
allocator satisfying the constraints of all devices interested.
A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf
exporter to make this transparent to the devices.
More details in the patch description of "cenalloc: Constraint-Enabled
Allocation helpers for dma-buf".
At present, the constraint_mask is only a bitmask, but it should be possible to
change it to a struct and adapt the constraint_mask calculation accordingly,
based on discussion.
Important requirement:
======================
Of course, delayed allocation can only work if all participating devices
will wait for other devices to have 'attached' before mapping the buffer
for the first time.
As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and then
map_attachment() almost immediately after it. This would need to be changed if
they were to benefit from constraints.
What 'cenalloc' is not:
=======================
- not 'general' allocator helpers - useful only for constraints-enabled
devices that share buffers with others using dma-buf.
- not a replacement for existing allocation mechanisms inside various
subsystems; merely a possible alternative.
- no page-migration - it would be very complementary to the delayed allocation
suggested here.
TODOs:
======
- demonstration test cases
- vma helpers for allocators
- more sample allocators
- userspace ioctl (It should be a simple one, and we have one ready, but wanted
to agree on the kernel side of things first)
May the brickbats begin, please! :)
Best regards,
~Sumit.
[1]: 'C'onstraints 'EN'abled 'ALLOC'ation helpers = cenalloc: it might not be a
very appealing name, so suggestions are very welcome!
Benjamin Gaignard (1):
cenalloc: a sample allocator for contiguous page allocation
Sumit Semwal (3):
dma-buf: Add constraints sharing information
cenalloc: Constraint-Enabled Allocation helpers for dma-buf
cenalloc: Build files for constraint-enabled allocation helpers
MAINTAINERS | 1 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/cenalloc/Kconfig | 8 +
drivers/cenalloc/Makefile | 3 +
drivers/cenalloc/cenalloc.c | 597 ++++++++++++++++++++++++++++++
drivers/cenalloc/cenalloc.h | 99 +++++
drivers/cenalloc/cenalloc_priv.h | 188 ++++++++++
drivers/cenalloc/cenalloc_system_contig.c | 225 +++++++++++
drivers/dma-buf/dma-buf.c | 50 ++-
include/linux/device.h | 7 +-
include/linux/dma-buf.h | 14 +
12 files changed, 1189 insertions(+), 6 deletions(-)
create mode 100644 drivers/cenalloc/Kconfig
create mode 100644 drivers/cenalloc/Makefile
create mode 100644 drivers/cenalloc/cenalloc.c
create mode 100644 drivers/cenalloc/cenalloc.h
create mode 100644 drivers/cenalloc/cenalloc_priv.h
create mode 100644 drivers/cenalloc/cenalloc_system_contig.c
--
1.9.1
Hi,
I need some some pointers on how to write a IOMMU driver on arm64 for a new SoC.
The iommu interface is currently not being provided in dma-mappings.c (the DMA API is SWIOTLB-based)
what is the alternative?
thanks
Jorge