Hi Linus,
May I request you to pull a few dma-buf changes for 4.1-rc1? minor
cleanup only; this could've gone in for the 4.0 merge window, but for
a copy-paste stupidity from me.
It has been in the for-next since then, and no issues reported.
Thanks and best regards,
Sumit.
The following changes since commit 646da63172f660ba84f195c1165360a9b73583ee:
Merge tag 'remoteproc-4.1-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc
(2015-04-20 15:40:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.1
for you to fetch changes up to 72449cb47b0104c32ff8fb9380ade9113375d8d1:
staging: android: ion: fix wrong init of dma_buf_export_info
(2015-04-21 14:47:16 +0530)
----------------------------------------------------------------
- cleanup of dma_buf_export()
- correction of copy-paste stupidity while doing the cleanup
----------------------------------------------------------------
Sumit Semwal (2):
dma-buf: cleanup dma_buf_export() to make it easily extensible
staging: android: ion: fix wrong init of dma_buf_export_info
Documentation/dma-buf-sharing.txt | 23 +++++++------
drivers/dma-buf/dma-buf.c | 47 ++++++++++++--------------
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 +++++++++++++++----
15 files changed, 152 insertions(+), 63 deletions(-)
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
The dmabuf fd can be shared between processes via unix domain
socket. The file of dmabuf fd is came from anon_inode. The inode
has no set and get xattr operations, so it can not be shared
between processes with smack. This patch fixes just to ignore
private inode including anon_inode for smack_file_receive.
Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com>
---
security/smack/smack_lsm.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 69fdc38..d1bb411 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1673,6 +1673,9 @@ static int smack_file_receive(struct file *file)
struct smk_audit_info ad;
struct inode *inode = file_inode(file);
+ if (unlikely(IS_PRIVATE(inode)))
+ return 0;
+
smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_PATH);
smk_ad_setfield_u_fs_path(&ad, file->f_path);
/*
--
1.7.4.1
Hello,
On 2015년 04월 17일 00:35, Casey Schaufler wrote:
> On 4/16/2015 6:40 AM, Seung-Woo Kim wrote:
>> The dma-buf fd from anon_inode can be shared across processes, but
>> there is no way to set security permission for the fd. So this
>> patch fix just to ignore private inode from security_file_receive.
>>
>> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com>
>> ---
>>
>> If security like smack is enabled, the dmabuf fd can not be shared between
>> processes via unix domain socket. I am not familiar with security, so I am
>> not sure that this kind of patch can be acceptable.
>
> If an IS_PRIVATE() check is appropriate, it should be in
> smack_file_receive(), not security_file_receive(). Why are you
> looking at file->f_path.dentry->d_inode? That's not used in the
> Smack access check. You'd want file->f_inode if anything.
>
> Naked-by: Casey Schaufler <casey(a)schaufler-ca.com>
>
Ok, I will try to do it from smack side. Also checking about file->f_inode.
Thanks and Regards,
- Seung-Woo Kim
>>
>> Is there other option to share dmabuf fd via socket with security check?
>>
>> Best Regards,
>> - Seung-Woo Kim
>>
>> ---
>> security/security.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/security/security.c b/security/security.c
>> index 730ac65..c57354c 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk,
>>
>> int security_file_receive(struct file *file)
>> {
>> +
>> + if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode)))
>> + return 0;
>> return security_ops->file_receive(file);
>> }
>>
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
Hello,
On 2015년 04월 16일 22:48, Stephen Smalley wrote:
> On 04/16/2015 09:40 AM, Seung-Woo Kim wrote:
>> The dma-buf fd from anon_inode can be shared across processes, but
>> there is no way to set security permission for the fd. So this
>> patch fix just to ignore private inode from security_file_receive.
>>
>> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com>
>> ---
>>
>> If security like smack is enabled, the dmabuf fd can not be shared between
>> processes via unix domain socket. I am not familiar with security, so I am
>> not sure that this kind of patch can be acceptable.
>>
>> Is there other option to share dmabuf fd via socket with security check?
>>
>> Best Regards,
>> - Seung-Woo Kim
>>
>> ---
>> security/security.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/security/security.c b/security/security.c
>> index 730ac65..c57354c 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk,
>>
>> int security_file_receive(struct file *file)
>> {
>> +
>> + if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode)))
>> + return 0;
>> return security_ops->file_receive(file);
>> }
>
> SELinux handles this internally; see its inode_has_perm() function.
> Doing it here would prevent any security module checking at all, even of
> the struct file, which SELinux does presently do (selinux_file_receive
> calls file_has_perm which applies the fd use check and then calls
> inode_has_perm on the inode). Unless you are saying that the
> file->f_security field is also not being set correctly.
Thanks for the suggestion. I will try to do on smack side.
Best Regards,
- Seung-Woo Kim
>
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
The dma-buf fd from anon_inode can be shared across processes, but
there is no way to set security permission for the fd. So this
patch fix just to ignore private inode from security_file_receive.
Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com>
---
If security like smack is enabled, the dmabuf fd can not be shared between
processes via unix domain socket. I am not familiar with security, so I am
not sure that this kind of patch can be acceptable.
Is there other option to share dmabuf fd via socket with security check?
Best Regards,
- Seung-Woo Kim
---
security/security.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/security/security.c b/security/security.c
index 730ac65..c57354c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk,
int security_file_receive(struct file *file)
{
+
+ if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode)))
+ return 0;
return security_ops->file_receive(file);
}
--
1.7.4.1
Hello Dave,
This patch makes STI driver use the atomic helpers.
I have fix the comments done by Daniel on the first version and get
his ack with this second version.
Regards,
Benjamin
The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:
Merge tag 'topic/drm-misc-2015-03-10' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11
12:15:06 +1000)
are available in the git repository at:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
drm-st-next-2015-03-19
for you to fetch changes up to de4b00b0937aba99b7099afc6ed17a81163faab3:
drm: sti: convert driver to atomic modeset (2015-03-19 13:35:16 +0100)
----------------------------------------------------------------
Benjamin Gaignard (1):
drm: sti: convert driver to atomic modeset
drivers/gpu/drm/sti/sti_drm_crtc.c | 175 ++++++++----------------------------
drivers/gpu/drm/sti/sti_drm_drv.c | 86 +++++++++++++++++-
drivers/gpu/drm/sti/sti_drm_drv.h | 6 ++
drivers/gpu/drm/sti/sti_drm_plane.c | 66 ++++++++++++--
drivers/gpu/drm/sti/sti_dvo.c | 6 +-
drivers/gpu/drm/sti/sti_hda.c | 6 +-
drivers/gpu/drm/sti/sti_hdmi.c | 6 +-
7 files changed, 205 insertions(+), 146 deletions(-)
Hi Linus,
May I please request you to pull a couple of fixes in dma-buf for 4.0-rc3?
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-4.0-rc3
for you to fetch changes up to 4eb2440ed60fb5793f7aa6da89b3d517cc59de43:
reservation: Remove shadowing local variable 'ret' (2015-01-22 16:29:31 +0530)
----------------------------------------------------------------
dma-buf pull request for 4.0-rc3
- minor timeout & other fixes on reservation/fence
----------------------------------------------------------------
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'
drivers/dma-buf/fence.c | 3 +++
drivers/dma-buf/reservation.c | 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
Thanks, and Best regards,
Sumit.
PS: I am not submitting the cleanup that I submitted in my earlier
pull request that you had to reject due to my stupid copy-paste error;
that one patch and it's fix is in for-next, but it's not, strictly
speaking, a "fix" to qualify for -rc3, hence I'll wait for the next
merge-window to submit it.
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.
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