Hi Linus,
Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
fancy, minor cleanups.
The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723:
Merge tag 'trace-sh-3.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
(2015-01-22 06:26:07 +1200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-3.20
for you to fetch changes up to 817bd7253291fc69d83d4340a7e186f3e6933169:
dma-buf: cleanup dma_buf_export() to make it easily extensible
(2015-02-18 20:16:20 +0530)
----------------------------------------------------------------
dma-buf pull request for 3.20
- minor timeout & other cleanups on reservation/fence
- cleanup of dma_buf_export()
----------------------------------------------------------------
Jammy Zhou (2):
reservation: wait only with non-zero timeout specified (v3)
dma-buf/fence: don't wait when specified timeout is zero
Michel Dänzer (1):
reservation: Remove shadowing local variable 'ret'
Sumit Semwal (1):
dma-buf: cleanup dma_buf_export() to make it easily extensible
Documentation/dma-buf-sharing.txt | 23 +++++++------
drivers/dma-buf/dma-buf.c | 47 ++++++++++++--------------
drivers/dma-buf/fence.c | 3 ++
drivers/dma-buf/reservation.c | 5 +--
drivers/gpu/drm/armada/armada_gem.c | 10 ++++--
drivers/gpu/drm/drm_prime.c | 12 ++++---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++++--
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 ++++-
drivers/gpu/drm/tegra/gem.c | 10 ++++--
drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
drivers/gpu/drm/udl/udl_dmabuf.c | 9 ++++-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 ++++-
drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 ++++-
drivers/media/v4l2-core/videobuf2-vmalloc.c | 8 ++++-
drivers/staging/android/ion/ion.c | 9 +++--
include/linux/dma-buf.h | 34 +++++++++++++++----
17 files changed, 158 insertions(+), 65 deletions(-)
Thanks, and best regards,
Sumit.
Hello Dave,
Those patches improve audio info frame management, add pixel formats
support and fix minor issues.
The following changes since commit e4bf44b3b558742fb7c58b4d34e206c8942f07e6:
drm/modes: Print the mode status in human readable form (2015-02-03
11:13:27 +1000)
are available in the git repository at:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
drm-sti-next-2015-02-04
for you to fetch changes up to cffe1e89dc9bf541a39d9287ced7c5addff07084:
drm: sti: HDMI add audio infoframe (2015-02-05 16:21:19 +0100)
----------------------------------------------------------------
Arnaud Pouliquen (1):
drm: sti: HDMI add audio infoframe
Benjamin Gaignard (1):
drm: sti: add support of ABGR8888 for gdp plane
Fabien Dessenne (1):
drm: sti: add support of XBGR8888 for gdp plane
Jassi Brar (1):
drm: sti: fix check for clk_pix_main
Vincent Abriou (1):
drm: sti: fix static checker warning in sti_awg_utils
drivers/gpu/drm/sti/sti_awg_utils.c | 2 -
drivers/gpu/drm/sti/sti_gdp.c | 11 +++
drivers/gpu/drm/sti/sti_hdmi.c | 179 +++++++++++++++++++++++++++---------
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
4 files changed, 149 insertions(+), 45 deletions(-)
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
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.