[PATCH] drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
From: Christian König
Starting with UVD3 message and feedback buffers have their
own 256MB segment, so no need to force them into VRAM any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 3 ++-
drivers/gpu/drm/radeon/radeon_uvd.c | 3 +--
drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index ac6ece6..1806f4d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -85,8 +85,9 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
VRAM, also but everything into VRAM on AGP cards to avoid
image corruptions */
if (p->ring == R600_RING_TYPE_UVD_INDEX &&
+ p->rdev->family < CHIP_PALM &&
(i == 0 || p->rdev->flags & RADEON_IS_AGP)) {
- /* TODO: is this still needed for NI+ ? */
+
p->relocs[i].lobj.domain =
RADEON_GEM_DOMAIN_VRAM;
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 1a01bbf..a0f1185 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -476,8 +476,7 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
return -EINVAL;
}
- /* TODO: is this still necessary on NI+ ? */
- if ((cmd == 0 || cmd == 0x3) &&
+ if (p->rdev->family < CHIP_PALM && (cmd == 0 || cmd == 0x3) &&
(start >> 28) != (p->rdev->uvd.gpu_addr >> 28)) {
DRM_ERROR("msg/fb buffer %LX-%LX out of 256MB segment!\n",
start, end);
diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
b/drivers/gpu/drm/radeon/uvd_v1_0.c
index 7266805..3100fa9 100644
--- a/drivers/gpu/drm/radeon/uvd_v1_0.c
+++ b/drivers/gpu/drm/radeon/uvd_v1_0.c
@@ -212,8 +212,8 @@ int uvd_v1_0_start(struct radeon_device *rdev)
/* enable VCPU clock */
WREG32(UVD_VCPU_CNTL, 1 << 9);
- /* enable UMC */
- WREG32_P(UVD_LMI_CTRL2, 0, ~(1 << 8));
+ /* enable UMC and NC0 */
+ WREG32_P(UVD_LMI_CTRL2, 1 << 13, ~((1 << 8) | (1 << 13)));
/* boot up the VCPU */
WREG32(UVD_SOFT_RESET, 0);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"
Hi,
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Monday, September 23, 2013 6:29 AM
> To: YoungJun Cho
> Cc: dri-devel@lists.freedesktop.org; Inki Dae
> Subject: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm
> close"
>
> You have drm_dev->struct_mutex grabbed before ->mmap_sem in
> exynos_drm_gem_mmap_ioctl() and after - in exynos_drm_gem_fault()
> (since ->fault() is always called with ->mmap_sem held). Looks like
> a garden-variety AB-BA deadlock...
>
Right, if mmap system call is requested by another process between ->f_op
pointer changing and restoring, the deadlock can be incurred.
For this, I think we can resolve this issue like below,
At exynos_drm_gem_mmap_ioctl()
down_write(&mm->mmap_sem);
mutex_lock(&dev->struct_mutex);
...
addr = security_mmap_file(...);
if (!addr) {
unsigned long populate;
addr = do_mmap_pgoff(...);
if (populate)
mm_populater(...);
}
...
mutex_unlock(&dev->struct_mutex);
up_write(&mm->mmap_sem);
The point above is to call down_write(&mm->mmap_sem) before do_mmap_pgoff,
and then to call up_write(...) after do_mmap_pg_off so that when another
process called mmap system call, the process can wait for up_write(...)
until the ->f_op pointer is restored.
I will post this patch soon. other opinions?
Thanks,
Inki Dae
> Incidentally, what should happen if another process shares the
> same opened file (e.g. inherited over fork()) and does mmap() just
> as we have ->f_op switched?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69694] New: Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 Priority: medium Bug ID: 69694 Assignee: dri-devel@lists.freedesktop.org Summary: Xorg doesn't start on KABINi with radeonsi Severity: normal Classification: Unclassified OS: All Reporter: mpia...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 86336 --> https://bugs.freedesktop.org/attachment.cgi?id=86336&action=edit gdb trace on segfault I bougth a brand new laptop with AMD APU A4-5000 (KABINI) which have two amd gpu (8330 integrated + 8550M dedicated). I just tried to recompile everithing to make Xorg work with radeonsi. At then end I have: 1)kernel 3.12-rc1 (with latest Alex Deucher 6 patches, the first is https://patchwork.kernel.org/patch/2922981/ dealing with clocks on SI); 2) libdrm git; 3) mesa git; 4) xf86-video-ati git; 5) glamor git; 6) Xserver git; I cannot start Xorg (the screen goes black), but I can ssh into it a trace the segfault with gdb. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #1 from Marco --- Created attachment 86337 --> https://bugs.freedesktop.org/attachment.cgi?id=86337&action=edit xorg.conf -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #2 from Marco --- Created attachment 86338 --> https://bugs.freedesktop.org/attachment.cgi?id=86338&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #3 from Marco --- Created attachment 86339 --> https://bugs.freedesktop.org/attachment.cgi?id=86339&action=edit dmesg log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/exynos-fimd] Display regression in v3.12-rc1
Hi, On 18 September 2013 14:01, Andrzej Hajda wrote: > Hi, > > You can just set this property to zero. > of_parse_display_timing will not complain and > you will have default settings. Yes, that works fine. Thanks. -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
On 19/09/13 11:49, Archit Taneja wrote:
> omapdrm established connections for omap_dss_device devices when probed. It
> should also be responsible to disconnect the devices. Keeping the devices
> connected can prevent the panel driver modules from unloading, it can also
> cause problems when omapdrm is re-inserted.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 45fbb1c..44a1203 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
> omap_channel channel)
>
> return false;
> }
> +static void omap_disconnect_dssdevs(void)
> +{
> + struct omap_dss_device *dssdev = NULL;
> +
> + for_each_dss_dev(dssdev)
> + dssdev->driver->disconnect(dssdev);
> +}
With a quick test, it looks like omapdrm leaves the displays enabled
when exiting. This can be fixed by adding to the above loop:
if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED)
dssdev->driver->disable(dssdev);
However... omapdrm still crashes when unloading, and it could be somehow
related to leaving something un-removed. Disabling a CRTC should disable
the display, and maybe omapdrm should disable (and clean-up) all CRTCs
on exit, and maybe that would remove the crash, and also fix the issue
of leaving displays enabled.
But I'm just guessing there, I have no idea how the process of unloading
a drm driver goes.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.12-rc1 regression] [BISECTED] X fails to start on Latitude E6510 w/ NOUVEAU DRM driver
I wrote:
> Dell Latitude E6510, CONFIG_DRM_NOUVEAU, 64-bit Fedora 17 user-space, Xorg
> drivers, and
>
> 01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
> a2).
>
> With 3.11 X starts fine, with 3.12-rc1 it fails with the following in
> Xorg.0.log:
>
> ...
> [56.819] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
> [56.842] (II) Module nouveau: vendor="X.Org Foundation"
> [56.842]compiled for 1.12.2, module version = 0.0.16
> [56.842]Module class: X.Org Video Driver
> [56.842]ABI class: X.Org Video Driver, version 12.0
> [56.842] (II) NOUVEAU driver
> [56.842] (II) NOUVEAU driver for NVIDIA chipset families :
> [56.842]RIVA TNT(NV04)
> [56.842]RIVA TNT2 (NV05)
> [56.842]GeForce 256 (NV10)
> [56.842]GeForce 2 (NV11, NV15)
> [56.842]GeForce 4MX (NV17, NV18)
> [56.842]GeForce 3 (NV20)
> [56.842]GeForce 4Ti (NV25, NV28)
> [56.842]GeForce FX (NV3x)
> [56.842]GeForce 6 (NV4x)
> [56.842]GeForce 7 (G7x)
> [56.842]GeForce 8 (G8x)
> [56.842]GeForce GTX 200 (NVA0)
> [56.842]GeForce GTX 400 (NVC0)
> [56.842] (--) using VT number 7
>
> [56.845] drmOpenDevice: node name is /dev/dri/card0
> [56.845] drmOpenDevice: open result is 9, (OK)
> [56.845] drmOpenByBusid: Searching for BusID pci::01:00.0
> [56.845] drmOpenDevice: node name is /dev/dri/card0
> [56.845] drmOpenDevice: open result is 9, (OK)
> [56.845] drmOpenByBusid: drmOpenMinor returns 9
> [56.845] drmOpenByBusid: drmGetBusid reports pci::01:00.0
> [56.845] (EE) [drm] failed to open device
> [56.845] (EE) No devices detected.
>
> With 3.11 one instead sees:
>
> ...
> [33.879] drmOpenByBusid: drmOpenMinor returns 9
> [33.879] drmOpenByBusid: drmGetBusid reports pci::01:00.0
> [33.879] (II) [drm] nouveau interface version: 1.1.1
> [33.879] (II) Loading sub module "dri"
> ...
>
> There are no messages in the kernel's log that indicate any problem.
>
> stracing xinit shows:
>
> 964 open("/dev/dri/card0", O_RDWR)= 9
> 964 write(0, "[ 1120.365] ", 13) = 13
> 964 write(0, "drmOpenDevice: open result is 9,"..., 38) = 38
> 964 write(0, "[ 1120.365] ", 13) = 13
> 964 write(0, "drmOpenByBusid: drmOpenMinor ret"..., 39) = 39
> 964 ioctl(9, 0xc0106407, 0x7fffda0d4800) = 0
> 964 ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
> 964 ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
> 964 write(0, "[ 1120.365] ", 13) = 13
> 964 write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53
> 964 ioctl(9, 0xc0086420, 0x7fffda0d4870) = -1 EINVAL (Invalid argument)
> 964 fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660,
> st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0,
> st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35,
> st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
> 964 fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660,
> st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0,
> st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35,
> st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
> 964 close(9) = 0
> 964 write(0, "[ 1120.366] ", 13) = 13
> 964 write(0, "(EE) [drm] failed to open device"..., 33) = 33
>
> So it looks like that ioctl 0xc0086420 is the culprit.
>
> Any ideas? I may have time to try a bisection tomorrow.
The bisection identified:
>From 7c510133d93dd6f15ca040733ba7b2891ed61fd1 Mon Sep 17 00:00:00 2001
>From: Daniel Vetter
>Date: Thu, 08 Aug 2013 13:41:21 +
>Subject: drm: mark context support as a legacy subsystem
>
>So after a lot of digging around in git histories it looks like this
>has only ever be used by dri1 render clients. Hence we can fully
>disable the entire thing for modesetting drivers and so greatly reduce
>the attack surface for potential exploits (or at least tools like
>trinity ...).
>
>Also add the drm_legacy prefix for functions which are called from
>common code. To further reduce the impact on common code also extract
>all the ctx release handling into a function (instead of only
>releasing individual handles) and make ctxbitmap_cleanup return void -
>it can never fail.
>
>Reviewed-by: Eric Anholt
>Signed-off-by: Daniel Vetter
>Signed-off-by: Dave Airlie
as the culprit. Reverting it from 3.12-rc1 allows X to start on this machine.
The issue seems driver dependent, as another Fedora 17 machine of mine
with Radeon graphics works fine with vanilla 3.12-rc1.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] configure: add AC_LANG_SOURCE call within AC_COMPILE_IFELSE
Documentation states that AC_*_IFELSE has to use AC_LANG_SOURCE or friends in order to generate the source code to compile. AC_LINK_IFELSE already handles this, thus convert AC_COMPILE_IFELSE to silence the final autoconf warnings. Signed-off-by: Emil Velikov --- While this patch is not strictly speaking necessary for the full/correct build of libdrm, it cuts down the configure'n'compile warnings to five. With the remaining being caused due to type conversion within exynos(4) and freedreno/kgsl(1). I planning to leave those to someone more aware of the respective codebase :) Cheers, Emil P.S. Keep me CC'd as I'm not subscribed to the list --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index d2e232b..43e6954 100644 --- a/configure.ac +++ b/configure.ac @@ -111,7 +111,7 @@ AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ libdrm_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $1" - AC_COMPILE_IFELSE([ ], [libdrm_cc_flag=yes], [libdrm_cc_flag=no]) + AC_COMPILE_IFELSE([AC_LANG_SOURCE([ ])], [libdrm_cc_flag=yes], [libdrm_cc_flag=no]) CFLAGS="$libdrm_save_CFLAGS" if test "x$libdrm_cc_flag" = "xyes"; then -- 1.8.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
pr_err("No usable DMA configuration,
aborting\n");
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err("No usable DMA configuration,
aborting\n");
- goto err_dma_mask;
- }
+ pr_err("No usable DMA configuration, aborting\n");
+ goto err_dma_mask;
}
}
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King
---
Documentation/DMA-API-HOWTO.txt | 37 ++---
Documentation/DMA-API.txt |8
include/linux/dma-mapping.h | 14 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default
setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent
allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API
for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static inline int dma_set_coheren
[PATCH 17/51] DMA-API: block: nvme-core: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King --- drivers/block/nvme-core.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c index da52092..26d03fa 100644 --- a/drivers/block/nvme-core.c +++ b/drivers/block/nvme-core.c @@ -1949,12 +1949,9 @@ static int nvme_dev_map(struct nvme_dev *dev) if (pci_request_selected_regions(pdev, bars, "nvme")) goto disable_pci; - if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) - dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64)); - else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) - dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); - else - goto disable_pci; + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) && + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) + goto disable; pci_set_drvdata(pdev, dev); dev->bar = ioremap(pci_resource_start(pdev, 0), 8192); @@ -2168,6 +2165,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id) INIT_LIST_HEAD(&dev->namespaces); dev->pci_dev = pdev; + result = nvme_set_instance(dev); if (result) goto free; -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 35/51] DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent()
The code sequence:
dev->coherent_dma_mask = DMA_BIT_MASK(24);
dev->dma_mask = &dev->coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/parport/parport_pc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 903e128..9637615 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2004,6 +2004,7 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
struct resource *ECR_res = NULL;
struct resource *EPP_res = NULL;
struct platform_device *pdev = NULL;
+ int ret;
if (!dev) {
/* We need a physical device to attach to, but none was
@@ -2014,8 +2015,11 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
return NULL;
dev = &pdev->dev;
- dev->coherent_dma_mask = DMA_BIT_MASK(24);
- dev->dma_mask = &dev->coherent_dma_mask;
+ ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(24));
+ if (ret) {
+ dev_err(dev, "Unable to set coherent dma mask:
disabling DMA\n");
+ dma = PARPORT_DMA_NONE;
+ }
}
ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 51/51] ARM: 7805/1: mm: change max*pfn to include the physical offset of memory
From: Santosh Shilimkar
Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.
Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/include/asm/dma-mapping.h |8
arch/arm/mm/init.c | 10 --
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..863cd84 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -64,6 +64,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void
*addr)
{
return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
}
+
#else
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
void *addr)
}
#endif
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
/*
* DMA errors are defined by all-bits-set in the DMA address.
*/
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8aab24f..d50533c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -426,12 +426,10 @@ void __init bootmem_init(void)
* This doesn't seem to be used by the Linux memory manager any
* more, but is used by ll_rw_block. If we can get rid of it, we
* also get rid of some of the stuff above as well.
-*
-* Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-* the system, not the maximum PFN.
*/
- max_low_pfn = max_low - PHYS_PFN_OFFSET;
- max_pfn = max_high - PHYS_PFN_OFFSET;
+ min_low_pfn = min;
+ max_low_pfn = max_low;
+ max_pfn = max_high;
}
/*
@@ -537,7 +535,7 @@ static inline void free_area_high(unsigned long pfn,
unsigned long end)
static void __init free_highpages(void)
{
#ifdef CONFIG_HIGHMEM
- unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+ unsigned long max_low = max_low_pfn;
struct memblock_region *mem, *res;
/* set highmem page free */
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 50/51] ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations
From: Santosh Shilimkar DMA bounce limit is the maximum direct DMA'able memory beyond which bounce buffers has to be used to perform dma operations. MMC queue layr relies on dma_mask but its calculation is based on max_*pfn which don't have uniform meaning across architectures. So make use of dma_max_pfn() which is expected to return the DMAable maximum pfn value across architectures. Signed-off-by: Santosh Shilimkar Signed-off-by: Russell King --- drivers/mmc/card/queue.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c index fa9632e..357bbc5 100644 --- a/drivers/mmc/card/queue.c +++ b/drivers/mmc/card/queue.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, struct mmc_queue_req *mqrq_prev = &mq->mqrq[1]; if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) - limit = *mmc_dev(host)->dma_mask; + limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; mq->card = card; mq->queue = blk_init_queue(mmc_request_fn, lock); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 48/51] ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function
From: Santosh Shilimkar
Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.
To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just "dev->dma_mask >> PAGE_SHIFT" and hence default behavior
is maintained as is.
Subsequent patches will make use of the helper. No functional change.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Russell King
---
include/linux/dma-mapping.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 27d1421..fd4aee2 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -153,6 +153,13 @@ static inline int dma_set_seg_boundary(struct device *dev,
unsigned long mask)
return -EIO;
}
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return *dev->dma_mask >> PAGE_SHIFT;
+}
+#endif
+
static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 45/51] DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks
This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.
Signed-off-by: Russell King
---
drivers/firmware/google/gsmi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 6eb535f..e5a67b2 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -764,6 +764,13 @@ static __init int gsmi_system_valid(void)
static struct kobject *gsmi_kobj;
static struct efivars efivars;
+static const struct platform_device_info gsmi_dev_info = {
+ .name = "gsmi",
+ .id = -1,
+ /* SMI callbacks require 32bit addresses */
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static __init int gsmi_init(void)
{
unsigned long flags;
@@ -776,7 +783,7 @@ static __init int gsmi_init(void)
gsmi_dev.smi_cmd = acpi_gbl_FADT.smi_command;
/* register device */
- gsmi_dev.pdev = platform_device_register_simple("gsmi", -1, NULL, 0);
+ gsmi_dev.pdev = platform_device_register_full(&gsmi_dev_info);
if (IS_ERR(gsmi_dev.pdev)) {
printk(KERN_ERR "gsmi: unable to register platform device\n");
return PTR_ERR(gsmi_dev.pdev);
@@ -785,10 +792,6 @@ static __init int gsmi_init(void)
/* SMI access needs to be serialized */
spin_lock_init(&gsmi_dev.lock);
- /* SMI callbacks require 32bit addresses */
- gsmi_dev.pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- gsmi_dev.pdev->dev.dma_mask =
- &gsmi_dev.pdev->dev.coherent_dma_mask;
ret = -ENOMEM;
gsmi_dev.dma_pool = dma_pool_create("gsmi", &gsmi_dev.pdev->dev,
GSMI_BUF_SIZE, GSMI_BUF_ALIGN, 0);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 44/51] DMA-API: dcdbas: update DMA mask handing
dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
which bypasses the architecture check. Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.
Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.
Signed-off-by: Russell King
---
drivers/firmware/dcdbas.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ff080ee..a85fda2 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -549,8 +549,9 @@ static int dcdbas_probe(struct platform_device *dev)
* BIOS SMI calls require buffer addresses be in 32-bit address space.
* This is done by setting the DMA mask below.
*/
- dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
+ error = dma_set_coherent_mask(&dcdbas_pdev->dev, DMA_BIT_MASK(32));
+ if (error)
+ return error;
error = sysfs_create_group(&dev->dev.kobj, &dcdbas_attr_group);
if (error)
@@ -581,6 +582,12 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
};
+static const struct platform_device_info dcdbas_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
/**
* dcdbas_init: initialize driver
*/
@@ -592,20 +599,14 @@ static int __init dcdbas_init(void)
if (error)
return error;
- dcdbas_pdev = platform_device_alloc(DRIVER_NAME, -1);
- if (!dcdbas_pdev) {
- error = -ENOMEM;
+ dcdbas_pdev = platform_device_register_full(&dcdbas_dev_info);
+ if (IS_ERR(dcdbas_pdev)) {
+ error = PTR_ERR(dcdbas_pdev);
goto err_unregister_driver;
}
- error = platform_device_add(dcdbas_pdev);
- if (error)
- goto err_free_device;
-
return 0;
- err_free_device:
- platform_device_put(dcdbas_pdev);
err_unregister_driver:
platform_driver_unregister(&dcdbas_driver);
return error;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 46/51] ARM: DMA-API: better handing of DMA masks for coherent allocations
We need to start treating DMA masks as something which is specific to
the bus that the device resides on, otherwise we're going to hit all
sorts of nasty issues with LPAE and 32-bit DMA controllers in >32-bit
systems, where memory is offset from PFN 0.
In order to start doing this, we convert the DMA mask to a PFN using
the device specific dma_to_pfn() macro. This is the reverse of the
pfn_to_dma() macro which is used to get the DMA address for the device.
This gives us a PFN mask, which we can then check against the PFN
limit of the DMA zone.
Signed-off-by: Russell King
---
arch/arm/mm/dma-mapping.c | 49
arch/arm/mm/init.c|2 +
arch/arm/mm/mm.h |2 +
3 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f5e1a84..13d55e1 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -173,10 +173,30 @@ static u64 get_coherent_dma_mask(struct device *dev)
return 0;
}
- if ((~mask) & (u64)arm_dma_limit) {
- dev_warn(dev, "coherent DMA mask %#llx is smaller "
-"than system GFP_DMA mask %#llx\n",
-mask, (u64)arm_dma_limit);
+ /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then fail the
+* allocation.
+*/
+ if (sizeof(mask) != sizeof(dma_addr_t) &&
+ mask > (dma_addr_t)~0 &&
+ dma_to_pfn(dev, ~0) > arm_dma_pfn_limit) {
+ dev_warn(dev, "Coherent DMA mask %#llx is larger than
dma_addr_t allows\n",
+mask);
+ dev_warn(dev, "Driver did not use or check the return
value from dma_set_coherent_mask()?\n");
+ return 0;
+ }
+
+ /*
+* Now check that the mask, when translated to a PFN,
+* fits within the allowable addresses which we can
+* allocate.
+*/
+ if (dma_to_pfn(dev, mask) < arm_dma_pfn_limit) {
+ dev_warn(dev, "Coherent DMA mask %#llx (pfn %#lx-%#lx)
covers a smaller range of system memory than the DMA zone pfn 0x0-%#lx\n",
+mask,
+dma_to_pfn(dev, 0), dma_to_pfn(dev, mask) + 1,
+arm_dma_pfn_limit + 1);
return 0;
}
}
@@ -1007,8 +1027,27 @@ void arm_dma_sync_sg_for_device(struct device *dev,
struct scatterlist *sg,
*/
int dma_supported(struct device *dev, u64 mask)
{
- if (mask < (u64)arm_dma_limit)
+ unsigned long limit;
+
+ /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then we must
+* indicate that DMA to this device is not supported.
+*/
+ if (sizeof(mask) != sizeof(dma_addr_t) &&
+ mask > (dma_addr_t)~0 &&
+ dma_to_pfn(dev, ~0) > arm_dma_pfn_limit)
+ return 0;
+
+ /*
+* Translate the device's DMA mask to a PFN limit. This
+* PFN number includes the page which we can DMA to.
+*/
+ limit = dma_to_pfn(dev, mask);
+
+ if (limit < arm_dma_pfn_limit)
return 0;
+
return 1;
}
EXPORT_SYMBOL(dma_supported);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index febaee7..8aab24f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -218,6 +218,7 @@ EXPORT_SYMBOL(arm_dma_zone_size);
* so a successful GFP_DMA allocation will always satisfy this.
*/
phys_addr_t arm_dma_limit;
+unsigned long arm_dma_pfn_limit;
static void __init arm_adjust_dma_zone(unsigned long *size, unsigned long
*hole,
unsigned long dma_size)
@@ -240,6 +241,7 @@ void __init setup_dma_zone(const struct machine_desc *mdesc)
arm_dma_limit = PHYS_OFFSET + arm_dma_zone_size - 1;
} else
arm_dma_limit = 0x;
+ arm_dma_pfn_limit = arm_dma_limit >> PAGE_SHIFT;
#endif
}
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index d5a4e9a..d5a982d 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -81,8 +81,10 @@ extern __init void add_static_vm_early(struct static_vm
*svm);
#ifdef CONFIG_ZONE_DMA
extern phys_addr_t arm_dma_limit;
+extern unsigned long arm_dma_pfn_limit;
#else
#define arm_dma_limit ((phys_addr_t)~0)
+#define arm_dma_pfn_limit (~0ul >> PAGE_SHIFT)
#endif
extern phys_addr_t arm_lowmem_limit;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
Signed-off-by: Russell King
---
drivers/dma/edma.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..7f9fe30 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = "edma-dma-engine",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = "edma-dma-engine",
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +722,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
- pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +731,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
- pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need to access the allocated musb platform device
from within its callbacks, which may be called during the musb
device probing.
Signed-off-by: Russell King
---
drivers/usb/musb/am35x.c| 50 ++
drivers/usb/musb/da8xx.c| 49 ++---
drivers/usb/musb/davinci.c | 48 ++--
drivers/usb/musb/tusb6010.c | 49 ++---
4 files changed, 68 insertions(+), 128 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 5c310c6..790b22b 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -89,7 +89,6 @@ struct am35x_glue {
struct clk *phy_clk;
struct clk *clk;
};
-#define glue_to_musb(g)platform_get_drvdata(g->musb)
/*
* am35x_musb_enable - enable interrupts
@@ -452,14 +451,18 @@ static const struct musb_platform_ops am35x_ops = {
.set_vbus = am35x_musb_set_vbus,
};
-static u64 am35x_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info am35x_dev_info = {
+ .name = "musb-hdrc",
+ .id = PLATFORM_DEVID_AUTO,
+ .dma_mask = DMA_BIT_MASK(32),
+};
static int am35x_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct platform_device *musb;
struct am35x_glue *glue;
-
+ struct platform_device_info pinfo;
struct clk *phy_clk;
struct clk *clk;
@@ -471,12 +474,6 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}
- musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
- if (!musb) {
- dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err1;
- }
-
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
@@ -503,12 +500,7 @@ static int am35x_probe(struct platform_device *pdev)
goto err6;
}
- musb->dev.parent= &pdev->dev;
- musb->dev.dma_mask = &am35x_dmamask;
- musb->dev.coherent_dma_mask = am35x_dmamask;
-
glue->dev = &pdev->dev;
- glue->musb = musb;
glue->phy_clk = phy_clk;
glue->clk = clk;
@@ -516,22 +508,17 @@ static int am35x_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- ret = platform_device_add_resources(musb, pdev->resource,
- pdev->num_resources);
- if (ret) {
- dev_err(&pdev->dev, "failed to add resources\n");
- goto err7;
- }
-
- ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
- if (ret) {
- dev_err(&pdev->dev, "failed to add platform_data\n");
- goto err7;
- }
-
- ret = platform_device_add(musb);
- if (ret) {
- dev_err(&pdev->dev, "failed to register musb device\n");
+ pinfo = am35x_dev_info;
+ pinfo.parent = &pdev->dev;
+ pinfo.res = pdev->resource;
+ pinfo.num_res = pdev->num_resources;
+ pinfo.data = pdata;
+ pinfo.size_data = sizeof(*pdata);
+
+ glue->musb = musb = platform_device_register_full(&pinfo);
+ if (IS_ERR(musb)) {
+ ret = PTR_ERR(musb);
+ dev_err(&pdev->dev, "failed to register musb device: %d\n",
ret);
goto err7;
}
@@ -550,9 +537,6 @@ static int am35x_probe(struct platform_device *pdev)
clk_put(phy_clk);
err3:
- platform_device_put(musb);
-
-err1:
kfree(glue);
err0:
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d9ddf41..2f2c1cb 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -472,7 +472,11 @@ static const struct musb_platform_ops da8xx_ops = {
.set_vbus = da8xx_musb_set_vbus,
};
-static u64 da8xx_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info da8xx_dev_info = {
+ .name = "musb-hdrc",
+ .id = PLATFORM_DEVID_AUTO,
+ .dma_mask = DMA_BIT_MASK(32),
+};
static int da8xx_probe(struct platform_device *pdev)
{
@@ -480,7 +484,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct musb_hdrc_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct platform_device *musb;
struct da8xx_glue *glue;
-
+ struct platform_device_info pinfo;
[PATCH 41/51] DMA-API: crypto: remove last references to 'static struct device *dev'
Signed-off-by: Russell King
---
drivers/crypto/ixp4xx_crypto.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 8306185..214357e 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -221,7 +221,6 @@ static int support_aes = 1;
#define DRIVER_NAME "ixp4xx_crypto"
static struct platform_device *pdev;
-static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -250,6 +249,7 @@ static inline const struct ix_hash_algo *ix_hash(struct
crypto_tfm *tfm)
static int setup_crypt_desc(void)
{
+ struct device *dev = &pdev->dev;
BUILD_BUG_ON(sizeof(struct crypt_ctl) != 64);
crypt_virt = dma_alloc_coherent(dev,
NPE_QLEN * sizeof(struct crypt_ctl),
@@ -350,6 +350,7 @@ static void finish_scattered_hmac(struct crypt_ctl *crypt)
static void one_packet(dma_addr_t phys)
{
+ struct device *dev = &pdev->dev;
struct crypt_ctl *crypt;
struct ixp_ctx *ctx;
int failed;
@@ -419,7 +420,7 @@ static void crypto_done_action(unsigned long arg)
tasklet_schedule(&crypto_done_tasklet);
}
-static int init_ixp_crypto(void)
+static int init_ixp_crypto(struct device *dev)
{
int ret = -ENODEV;
u32 msg[2] = { 0, 0 };
@@ -506,7 +507,7 @@ static int init_ixp_crypto(void)
return ret;
}
-static void release_ixp_crypto(void)
+static void release_ixp_crypto(struct device *dev)
{
qmgr_disable_irq(RECV_QID);
tasklet_kill(&crypto_done_tasklet);
@@ -873,6 +874,7 @@ static int ablk_perform(struct ablkcipher_request *req, int
encrypt)
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = ablkcipher_request_ctx(req);
struct buffer_desc src_hook;
+ struct device *dev = &pdev->dev;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -997,6 +999,7 @@ static int aead_perform(struct aead_request *req, int
encrypt,
unsigned int cryptlen;
struct buffer_desc *buf, src_hook;
struct aead_ctx *req_ctx = aead_request_ctx(req);
+ struct device *dev = &pdev->dev;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -1426,7 +1429,7 @@ static int __init ixp_module_init(void)
spin_lock_init(&desc_lock);
spin_lock_init(&emerg_lock);
- err = init_ixp_crypto();
+ err = init_ixp_crypto(&pdev->dev);
if (err) {
platform_device_unregister(pdev);
return err;
@@ -1492,7 +1495,7 @@ static void __exit ixp_module_exit(void)
if (ixp4xx_algos[i].registered)
crypto_unregister_alg(&ixp4xx_algos[i].crypto);
}
- release_ixp_crypto();
+ release_ixp_crypto(&pdev->dev);
platform_device_unregister(pdev);
}
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(&exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
omap_dmm->dummy_pa = page_to_phys(omap_dmm->dummy_page);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
AMBA Primecell devices always treat streaming and coherent DMA exactly
the same, so there's no point in having the masks separated.
Signed-off-by: Russell King
---
drivers/amba/bus.c |6 +-
drivers/of/platform.c|3 ---
include/linux/amba/bus.h |2 --
3 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c670727..c4876ac 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -552,7 +552,6 @@ amba_aphb_device_add(struct device *parent, const char
*name,
if (!dev)
return ERR_PTR(-ENOMEM);
- dev->dma_mask = dma_mask;
dev->dev.coherent_dma_mask = dma_mask;
dev->irq[0] = irq1;
dev->irq[1] = irq2;
@@ -619,7 +618,7 @@ static void amba_device_initialize(struct amba_device *dev,
const char *name)
dev_set_name(&dev->dev, "%s", name);
dev->dev.release = amba_device_release;
dev->dev.bus = &amba_bustype;
- dev->dev.dma_mask = &dev->dma_mask;
+ dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
dev->res.name = dev_name(&dev->dev);
}
@@ -663,9 +662,6 @@ int amba_device_register(struct amba_device *dev, struct
resource *parent)
amba_device_initialize(dev, dev->dev.init_name);
dev->dev.init_name = NULL;
- if (!dev->dev.coherent_dma_mask && dev->dma_mask)
- dev_warn(&dev->dev, "coherent dma mask is unset\n");
-
return amba_device_add(dev, parent);
}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..54382ba 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -284,9 +284,6 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
else
of_device_make_bus_id(&dev->dev);
- /* setup amba-specific device info */
- dev->dma_mask = ~0;
-
/* Allow the HW Peripheral ID to be overridden */
prop = of_get_property(node, "arm,primecell-periphid", NULL);
if (prop)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 43ec7e2..682df0e 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -30,7 +30,6 @@ struct amba_device {
struct device dev;
struct resource res;
struct clk *pclk;
- u64 dma_mask;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
};
@@ -131,7 +130,6 @@ struct amba_device name##_device = {
\
struct amba_device name##_device = { \
.dev = __AMBA_DEV(busid, data, ~0ULL), \
.res = DEFINE_RES_MEM(base, SZ_4K), \
- .dma_mask = ~0ULL, \
.irq = irqs,\
.periphid = id, \
}
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King
---
drivers/dma/pl330.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..df8b10f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pdat = dev_get_platdata(&adev->dev);
+ ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
/* Allocate a new DMAC and its Channels */
pdmac = devm_kzalloc(&adev->dev, sizeof(*pdmac), GFP_KERNEL);
if (!pdmac) {
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/51] DMA-API: net: emulex/benet: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/ethernet/emulex/benet/be_main.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 3224d28..2084151 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4335,19 +4335,11 @@ static int be_probe(struct pci_dev *pdev, const struct
pci_device_id *pdev_id)
adapter->netdev = netdev;
SET_NETDEV_DEV(netdev, &pdev->dev);
- status = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ status = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!status) {
- status = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (status < 0) {
- dev_err(&pdev->dev, "dma_set_coherent_mask failed\n");
- goto free_netdev;
- }
netdev->features |= NETIF_F_HIGHDMA;
} else {
- status = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (!status)
- status = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
+ status = dma_set_mask_and_coherent(&pdev->dev,
DMA_BIT_MASK(32));
if (status) {
dev_err(&pdev->dev, "Could not set PCI DMA Mask\n");
goto free_netdev;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/51] DMA-API: net: sfc/efx.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/ethernet/sfc/efx.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 07c9bc4..2e27837 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1121,7 +1121,7 @@ static int efx_init_io(struct efx_nic *efx)
*/
while (dma_mask > 0x7fffUL) {
if (dma_supported(&pci_dev->dev, dma_mask)) {
- rc = dma_set_mask(&pci_dev->dev, dma_mask);
+ rc = dma_set_mask_and_coherent(&pci_dev->dev, dma_mask);
if (rc == 0)
break;
}
@@ -1134,16 +1134,6 @@ static int efx_init_io(struct efx_nic *efx)
}
netif_dbg(efx, probe, efx->net_dev,
"using DMA mask %llx\n", (unsigned long long) dma_mask);
- rc = dma_set_coherent_mask(&pci_dev->dev, dma_mask);
- if (rc) {
- /* dma_set_coherent_mask() is not *allowed* to
-* fail with a mask that dma_set_mask() accepted,
-* but just in case...
-*/
- netif_err(efx, probe, efx->net_dev,
- "failed to set consistent DMA mask\n");
- goto fail2;
- }
efx->membase_phys = pci_resource_start(efx->pci_dev, EFX_MEM_BAR);
rc = pci_request_region(pci_dev, EFX_MEM_BAR, "sfc");
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/51] DMA-API: staging: et131x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/staging/et131x/et131x.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index f73e58f..98edfa8 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -4797,21 +4797,8 @@ static int et131x_pci_setup(struct pci_dev *pdev,
pci_set_master(pdev);
/* Check the DMA addressing support of this device */
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
- rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (rc < 0) {
- dev_err(&pdev->dev,
- "Unable to obtain 64 bit DMA for consistent
allocations\n");
- goto err_release_res;
- }
- } else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
- rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (rc < 0) {
- dev_err(&pdev->dev,
- "Unable to obtain 32 bit DMA for consistent
allocations\n");
- goto err_release_res;
- }
- } else {
+ if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
+ dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) {
dev_err(&pdev->dev, "No usable DMA addressing method\n");
rc = -EIO;
goto err_release_res;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/51] DMA-API: net: intel/e1000: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/e1000/e1000_main.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..34672f8 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1018,19 +1018,14 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
*/
pci_using_dac = 0;
if ((hw->bus_type == e1000_bus_type_pcix) &&
- !dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
- /* according to DMA-API-HOWTO, coherent calls will always
-* succeed if the set call did
-*/
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
+ !dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
pr_err("No usable DMA config, aborting\n");
goto err_dma;
}
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
}
netdev->netdev_ops = &e1000_netdev_ops;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King --- drivers/staging/media/dt3155v4l/dt3155v4l.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c index 90d6ac4..081407b 100644 --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id) int err; struct dt3155_priv *pd; - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; pd = kzalloc(sizeof(*pd), GFP_KERNEL); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/51] DMA-API: net: broadcom/bnx2x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2f8dbbb..e6c3e66 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12072,13 +12072,9 @@ static int bnx2x_set_coherency_mask(struct bnx2x *bp)
{
struct device *dev = &bp->pdev->dev;
- if (dma_set_mask(dev, DMA_BIT_MASK(64)) == 0) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)) == 0) {
bp->flags |= USING_DAC_FLAG;
- if (dma_set_coherent_mask(dev, DMA_BIT_MASK(64)) != 0) {
- dev_err(dev, "dma_set_coherent_mask failed,
aborting\n");
- return -EIO;
- }
- } else if (dma_set_mask(dev, DMA_BIT_MASK(32)) != 0) {
+ } else if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) != 0) {
dev_err(dev, "System does not support DMA, aborting\n");
return -EIO;
}
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/51] DMA-API: net: b43legacy: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/wireless/b43legacy/dma.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/b43legacy/dma.c
b/drivers/net/wireless/b43legacy/dma.c
index 42eb26c..b2ed179 100644
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -806,12 +806,9 @@ static int b43legacy_dma_set_mask(struct b43legacy_wldev
*dev, u64 mask)
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = dma_set_mask(dev->dev->dma_dev, mask);
- if (!err) {
- err = dma_set_coherent_mask(dev->dev->dma_dev, mask);
- if (!err)
- break;
- }
+ err = dma_set_mask_and_coherent(dev->dev->dma_dev, mask);
+ if (!err)
+ break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/51] DMA-API: usb: bcma: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King --- drivers/usb/host/bcma-hcd.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c index df13d42..205f4a3 100644 --- a/drivers/usb/host/bcma-hcd.c +++ b/drivers/usb/host/bcma-hcd.c @@ -227,8 +227,7 @@ static int bcma_hcd_probe(struct bcma_device *dev) /* TODO: Probably need checks here; is the core connected? */ - if (dma_set_mask(dev->dma_dev, DMA_BIT_MASK(32)) || - dma_set_coherent_mask(dev->dma_dev, DMA_BIT_MASK(32))) + if (dma_set_mask_and_coherent(dev->dma_dev, DMA_BIT_MASK(32))) return -EOPNOTSUPP; usb_dev = kzalloc(sizeof(struct bcma_hcd_device), GFP_KERNEL); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 25/51] DMA-API: video: clcd: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King
---
drivers/video/amba-clcd.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..afe4702 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -10,6 +10,7 @@
*
* ARM PrimeCell PL110 Color LCD Controller
*/
+#include
#include
#include
#include
@@ -551,6 +552,10 @@ static int clcdfb_probe(struct amba_device *dev, const
struct amba_id *id)
if (!board)
return -EINVAL;
+ ret = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out;
+
ret = amba_request_regions(dev, NULL);
if (ret) {
printk(KERN_ERR "CLCD: unable to reserve regs region\n");
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 21/51] DMA-API: usb: ssb-hcd: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King --- drivers/usb/host/ssb-hcd.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ssb-hcd.c b/drivers/usb/host/ssb-hcd.c index 74af2c6..0196f76 100644 --- a/drivers/usb/host/ssb-hcd.c +++ b/drivers/usb/host/ssb-hcd.c @@ -163,8 +163,7 @@ static int ssb_hcd_probe(struct ssb_device *dev, /* TODO: Probably need checks here; is the core connected? */ - if (dma_set_mask(dev->dma_dev, DMA_BIT_MASK(32)) || - dma_set_coherent_mask(dev->dma_dev, DMA_BIT_MASK(32))) + if (dma_set_mask_and_coherent(dev->dma_dev, DMA_BIT_MASK(32))) return -EOPNOTSUPP; usb_dev = kzalloc(sizeof(struct ssb_hcd_device), GFP_KERNEL); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 26/51] DMA-API: usb: ohci-sa1111: add a note about DMA masks
Add a comment to explain why this driver doesn't call any of the DMA API dma_set_mask() functions. Signed-off-by: Russell King --- drivers/usb/host/ohci-sa.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ohci-sa.c b/drivers/usb/host/ohci-sa.c index 17b2a7d..aa9e127 100644 --- a/drivers/usb/host/ohci-sa.c +++ b/drivers/usb/host/ohci-sa.c @@ -185,6 +185,12 @@ static int ohci_hcd_sa_probe(struct sa_dev *dev) if (usb_disabled()) return -ENODEV; + /* +* We don't call dma_set_mask_and_coherent() here because the +* DMA mask has already been appropraitely setup by the core +* SA- bus code (which includes bug workarounds.) +*/ + hcd = usb_create_hcd(&ohci_sa_hc_driver, &dev->dev, "sa"); if (!hcd) return -ENOMEM; -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 27/51] DMA-API: provide a helper to setup DMA masks
Many drivers contain code such as:
dev->dma_mask = &dev->coherent_dma_mask;
dev->coherent_dma_mask = MASK;
Let's move this pattern out of drivers and have the DMA API provide a
helper for it. This helper uses dma_set_mask_and_coherent() to allow
platform issues to be properly dealt with via dma_set_mask()/
dma_is_supported().
Signed-off-by: Russell King
---
include/linux/dma-mapping.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index ec951f9..27d1421 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -111,6 +111,16 @@ static inline int dma_set_mask_and_coherent(struct device
*dev, u64 mask)
return rc;
}
+/*
+ * Similar to the above, except it deals with the case where the device
+ * does not have dev->dma_mask appropriately setup.
+ */
+static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
+{
+ dev->dma_mask = &dev->coherent_dma_mask;
+ return dma_set_mask_and_coherent(dev, mask);
+}
+
extern u64 dma_get_required_mask(struct device *dev);
static inline unsigned int dma_get_max_seg_size(struct device *dev)
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
This code sequence is unsafe in modules:
static u64 mask = DMA_BIT_MASK(something);
...
if (!dev->dma_mask)
dev->dma_mask = &mask;
as if a module is reloaded, the mask will be pointing at the original
module's mask address, and this can lead to oopses. Moreover, they
all follow this with:
if (!dev->coherent_dma_mask)
dev->coherent_dma_mask = mask;
where 'mask' is the same value as the statically defined mask, and this
bypasses the architecture's check on whether the DMA mask is possible.
Fix these issues by using the new dma_coerce_coherent_and_mask()
function.
Signed-off-by: Russell King
---
sound/arm/pxa2xx-pcm.c |9 +++--
sound/soc/atmel/atmel-pcm.c | 11 ---
sound/soc/blackfin/bf5xx-ac97-pcm.c | 11 ---
sound/soc/blackfin/bf5xx-i2s-pcm.c | 10 --
sound/soc/davinci/davinci-pcm.c |9 +++--
sound/soc/fsl/fsl_dma.c |9 +++--
sound/soc/fsl/mpc5200_dma.c | 10 --
sound/soc/jz4740/jz4740-pcm.c | 12
sound/soc/kirkwood/kirkwood-dma.c |9 +++--
sound/soc/nuc900/nuc900-pcm.c |9 -
sound/soc/omap/omap-pcm.c | 11 ---
sound/soc/pxa/pxa2xx-pcm.c | 11 ---
sound/soc/s6000/s6000-pcm.c |9 +++--
sound/soc/samsung/dma.c | 11 ---
sound/soc/samsung/idma.c| 11 ---
15 files changed, 55 insertions(+), 97 deletions(-)
diff --git a/sound/arm/pxa2xx-pcm.c b/sound/arm/pxa2xx-pcm.c
index 69a2455..fb3b76f 100644
--- a/sound/arm/pxa2xx-pcm.c
+++ b/sound/arm/pxa2xx-pcm.c
@@ -83,8 +83,6 @@ static struct snd_pcm_ops pxa2xx_pcm_ops = {
.mmap = pxa2xx_pcm_mmap,
};
-static u64 pxa2xx_pcm_dmamask = 0x;
-
int pxa2xx_pcm_new(struct snd_card *card, struct pxa2xx_pcm_client *client,
struct snd_pcm **rpcm)
{
@@ -100,10 +98,9 @@ int pxa2xx_pcm_new(struct snd_card *card, struct
pxa2xx_pcm_client *client,
pcm->private_data = client;
pcm->private_free = pxa2xx_pcm_free_dma_buffers;
- if (!card->dev->dma_mask)
- card->dev->dma_mask = &pxa2xx_pcm_dmamask;
- if (!card->dev->coherent_dma_mask)
- card->dev->coherent_dma_mask = 0x;
+ ret = dma_coerce_mask_and_coherent_mask(card->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out;
if (play) {
int stream = SNDRV_PCM_STREAM_PLAYBACK;
diff --git a/sound/soc/atmel/atmel-pcm.c b/sound/soc/atmel/atmel-pcm.c
index 3109db7..fbb87e3 100644
--- a/sound/soc/atmel/atmel-pcm.c
+++ b/sound/soc/atmel/atmel-pcm.c
@@ -68,18 +68,15 @@ int atmel_pcm_mmap(struct snd_pcm_substream *substream,
}
EXPORT_SYMBOL_GPL(atmel_pcm_mmap);
-static u64 atmel_pcm_dmamask = DMA_BIT_MASK(32);
-
int atmel_pcm_new(struct snd_soc_pcm_runtime *rtd)
{
struct snd_card *card = rtd->card->snd_card;
struct snd_pcm *pcm = rtd->pcm;
- int ret = 0;
+ int ret;
- if (!card->dev->dma_mask)
- card->dev->dma_mask = &atmel_pcm_dmamask;
- if (!card->dev->coherent_dma_mask)
- card->dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
if (pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
pr_debug("atmel-pcm: allocating PCM playback DMA buffer\n");
diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c
b/sound/soc/blackfin/bf5xx-ac97-pcm.c
index 53f8408..1d4c676 100644
--- a/sound/soc/blackfin/bf5xx-ac97-pcm.c
+++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c
@@ -415,19 +415,16 @@ static void bf5xx_pcm_free_dma_buffers(struct snd_pcm
*pcm)
}
}
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
static int bf5xx_pcm_ac97_new(struct snd_soc_pcm_runtime *rtd)
{
struct snd_card *card = rtd->card->snd_card;
struct snd_pcm *pcm = rtd->pcm;
- int ret = 0;
+ int ret;
pr_debug("%s enter\n", __func__);
- if (!card->dev->dma_mask)
- card->dev->dma_mask = &bf5xx_pcm_dmamask;
- if (!card->dev->coherent_dma_mask)
- card->dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
if (pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
ret = bf5xx_pcm_preallocate_dma_buffer(pcm,
diff --git a/sound/soc/blackfin/bf5xx-i2s-pcm.c
b/sound/soc/blackfin/bf5xx-i2s-pcm.c
index 9cb4a80..2a5b434 100644
--- a/sound/soc/blackfin/bf5xx-i2s-pcm.c
+++ b/sound/soc/blackfin/bf5xx-i2s-pcm.c
@@ -323,18 +323,16 @@ static struct snd_pcm_ops bf5xx_pcm_i2s_ops = {
.silence= bf5xx_pcm_silence,
};
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
static int bf5xx_pcm_i2s_new(struct snd_soc_pcm
[PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()
Convert this code sequence: pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64); pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; to use dma_coerce_mask_and_coherent() to avoid bypassing the architecture check on the DMA mask. Signed-off-by: Russell King --- drivers/ata/pata_octeon_cf.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c index c51bbb9..6231d43 100644 --- a/drivers/ata/pata_octeon_cf.c +++ b/drivers/ata/pata_octeon_cf.c @@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev) } cf_port->c0 = ap->ioaddr.ctl_addr; - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64); - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; + rv = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); + if (rv) + return ret; ata_port_desc(ap, "cmd %p ctl %p", base, ap->ioaddr.ctl_addr); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 30/51] DMA-API: dma: dw_dmac.c: convert to use dma_coerce_mask_and_coherent()
This code sequence:
if (!pdev->dev.dma_mask) {
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/dma/dw/platform.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index e35d975..453822c 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -191,11 +191,9 @@ static int dw_probe(struct platform_device *pdev)
if (IS_ERR(chip->regs))
return PTR_ERR(chip->regs);
- /* Apply default dma_mask if needed */
- if (!dev->dma_mask) {
- dev->dma_mask = &dev->coherent_dma_mask;
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
- }
+ err = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (err)
+ return err;
pdata = dev_get_platdata(dev);
if (!pdata)
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
The code sequence:
isp->raw_dmamask = DMA_BIT_MASK(32);
isp->dev->dma_mask = &isp->raw_dmamask;
isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/media/platform/omap3isp/isp.c |6 +++---
drivers/media/platform/omap3isp/isp.h |3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index df3a0ec..1c36080 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
isp->pdata = pdata;
isp->ref_count = 0;
- isp->raw_dmamask = DMA_BIT_MASK(32);
- isp->dev->dma_mask = &isp->raw_dmamask;
- isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
platform_set_drvdata(pdev, isp);
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index cd3eff4..ce65d3a 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -152,7 +152,6 @@ struct isp_xclk {
* @mmio_base_phys: Array with physical L4 bus addresses for ISP register
* regions.
* @mmio_size: Array with ISP register regions size in bytes.
- * @raw_dmamask: Raw DMA mask
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
* @crashed: Bitmask of crashed entities (indexed by entity ID)
@@ -190,8 +189,6 @@ struct isp_device {
unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
- u64 raw_dmamask;
-
/* ISP Obj */
spinlock_t stat_lock; /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > The correct way for a driver to specify the coherent DMA mask is > not to directly access the field in the struct device, but to use > dma_set_coherent_mask(). Only arch and bus code should access this > member directly. > > Convert all direct write accesses to using the correct API. > > Signed-off-by: Russell King Acked-by: Tejun Heo The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: > On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > > The correct way for a driver to specify the coherent DMA mask is > > not to directly access the field in the struct device, but to use > > dma_set_coherent_mask(). Only arch and bus code should access this > > member directly. > > > > Convert all direct write accesses to using the correct API. > > > > Signed-off-by: Russell King > > Acked-by: Tejun Heo > > The patch is pretty widely spread. I don't mind how it gets routed > but what's the plan? Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one which updates pata_octeon_cf.c? Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 32/51] DMA-API: mmc: sdhci-acpi: use dma_coerce_mask_and_coherent()
The code sequence:
dev->dma_mask = &dev->coherent_dma_mask;
dev->coherent_dma_mask = dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/mmc/host/sdhci-acpi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index cdd4ce0..ef19874 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -310,8 +310,9 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
dma_mask = DMA_BIT_MASK(32);
}
- dev->dma_mask = &dev->coherent_dma_mask;
- dev->coherent_dma_mask = dma_mask;
+ err = dma_coerce_mask_and_coherent(dev, dma_mask);
+ if (err)
+ goto err_free;
}
if (c->slot) {
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 33/51] DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent()
The code sequence:
pldat->pdev->dev.coherent_dma_mask = 0x;
pldat->pdev->dev.dma_mask = &pldat->pdev->dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/net/ethernet/nxp/lpc_eth.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c
b/drivers/net/ethernet/nxp/lpc_eth.c
index a061b93..ba3ca18 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1399,8 +1399,10 @@ static int lpc_eth_drv_probe(struct platform_device
*pdev)
}
if (pldat->dma_buff_base_v == 0) {
- pldat->pdev->dev.coherent_dma_mask = 0x;
- pldat->pdev->dev.dma_mask = &pldat->pdev->dev.coherent_dma_mask;
+ ret = dma_coerce_mask_and_coherent(&pdev->dev,
DMA_BIT_MASK(32));
+ if (ret)
+ goto err_out_free_irq;
+
pldat->dma_buff_size = PAGE_ALIGN(pldat->dma_buff_size);
/* Allocate a chunk of memory for the DMA ethernet buffers
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 34/51] DMA-API: net: octeon: use dma_coerce_mask_and_coherent()
The code sequence: pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64); pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; bypasses the architectures check on the DMA mask. It can be replaced with dma_coerce_mask_and_coherent(), avoiding the direct initialization of this mask. Signed-off-by: Russell King --- drivers/net/ethernet/octeon/octeon_mgmt.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c index 622aa75..2006a07 100644 --- a/drivers/net/ethernet/octeon/octeon_mgmt.c +++ b/drivers/net/ethernet/octeon/octeon_mgmt.c @@ -1552,8 +1552,9 @@ static int octeon_mgmt_probe(struct platform_device *pdev) p->phy_np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0); - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64); - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; + result = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); + if (result) + goto err; netif_carrier_off(netdev); result = register_netdev(netdev); -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King
---
drivers/usb/chipidea/ci_hdrc_imx.c |5 +++--
drivers/usb/dwc3/dwc3-exynos.c |5 +++--
drivers/usb/gadget/lpc32xx_udc.c |4 +++-
drivers/usb/host/ehci-atmel.c |5 +++--
drivers/usb/host/ehci-octeon.c |4 +++-
drivers/usb/host/ehci-omap.c |8 +---
drivers/usb/host/ehci-orion.c |5 +++--
drivers/usb/host/ehci-platform.c |7 ---
drivers/usb/host/ehci-s5p.c|5 +++--
drivers/usb/host/ehci-spear.c |5 +++--
drivers/usb/host/ehci-tegra.c |5 +++--
drivers/usb/host/ohci-at91.c |7 ---
drivers/usb/host/ohci-exynos.c |5 +++--
drivers/usb/host/ohci-nxp.c|4 +++-
drivers/usb/host/ohci-octeon.c |4 +++-
drivers/usb/host/ohci-omap3.c |8 +---
drivers/usb/host/ohci-pxa27x.c |6 --
drivers/usb/host/ohci-spear.c |5 +++--
drivers/usb/host/uhci-platform.c |5 +++--
19 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 74d998d..bf33bd3 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -123,8 +123,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (!pdev->dev.dma_mask)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
- if (!pdev->dev.coherent_dma_mask)
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto err_clk;
if (data->usbmisc_data) {
ret = imx_usbmisc_init(data->usbmisc_data);
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 2f2e88a..c10b324 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
*/
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto err1;
platform_set_drvdata(pdev, exynos);
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index 67128be..6a2a65a 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct
platform_device *pdev)
udc->isp1301_i2c_client->addr);
pdev->dev.dma_mask = &lpc32xx_usbd_dmamask;
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto resource_fail;
udc->board = &lpc32xx_usbddata;
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..5831a88 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
*/
if (!pdev->dev.dma_mask)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
- if (!pdev->dev.coherent_dma_mask)
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto fail_create_hcd;
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
if (!hcd) {
diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c
index ab0397e..4c528b2 100644
--- a/drivers/usb/host/ehci-octeon.c
+++ b/drivers/usb/host/ehci-octeon.c
@@ -116,8 +116,10 @@ static int ehci_octeon_drv_probe(struct platform_device
*pdev)
* We can DMA from anywhere. But the descriptors must be in
* the lower 4GB.
*/
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = &ehci_octeon_dma_mask;
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
hcd = usb_create_hcd(&ehci_octeon_hc_driver, &pdev->dev, "octeon");
if (!hcd)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 78b01fa..d0759c5 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -104,7 +104,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
struct resource *res;
struct usb_hcd *hcd;
void __iomem *regs;
- int ret = -ENODEV;
+ int ret;
int irq;
[PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
Signed-off-by: Russell King --- drivers/usb/chipidea/ci_hdrc_imx.c |4 +--- drivers/usb/dwc3/dwc3-exynos.c |4 +--- drivers/usb/host/ehci-atmel.c |4 +--- drivers/usb/host/ehci-omap.c |4 +--- drivers/usb/host/ehci-orion.c |4 +--- drivers/usb/host/ehci-platform.c |5 ++--- drivers/usb/host/ehci-s5p.c|4 +--- drivers/usb/host/ehci-spear.c |4 +--- drivers/usb/host/ehci-tegra.c |4 +--- drivers/usb/host/ohci-at91.c |4 +--- drivers/usb/host/ohci-exynos.c |4 +--- drivers/usb/host/ohci-nxp.c|3 +-- drivers/usb/host/ohci-octeon.c |3 +-- drivers/usb/host/ohci-omap3.c |4 +--- drivers/usb/host/ohci-pxa27x.c |4 +--- drivers/usb/host/ohci-spear.c |4 +--- drivers/usb/host/uhci-platform.c |4 +--- 17 files changed, 18 insertions(+), 49 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index bf33bd3..af731db 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -121,9 +121,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) pdata.phy = data->phy; - if (!pdev->dev.dma_mask) - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; - ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); if (ret) goto err_clk; diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index c10b324..8b20c70 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we move to full device tree support this will vanish off. */ - if (!dev->dma_mask) - dev->dma_mask = &dev->coherent_dma_mask; - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); if (ret) goto err1; diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c index 5831a88..8e7323e 100644 --- a/drivers/usb/host/ehci-atmel.c +++ b/drivers/usb/host/ehci-atmel.c @@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!pdev->dev.dma_mask) - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; - retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); if (retval) goto fail_create_hcd; diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index d0759c5..6fa82d6 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!dev->dma_mask) - dev->dma_mask = &dev->coherent_dma_mask; - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); if (ret) return ret; diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c index 5870206..2ba7673 100644 --- a/drivers/usb/host/ehci-orion.c +++ b/drivers/usb/host/ehci-orion.c @@ -180,9 +180,7 @@ static int ehci_orion_drv_probe(struct platform_device *pdev) * set. Since shared usb code relies on it, set it here for * now. Once we have dma capability bindings this can go away. */ - if (!pdev->dev.dma_mask) - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + err = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); if (err) goto err1; diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 5b0cd2d..7f30b71 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -89,9 +89,8 @@ static int ehci_platform_probe(struct platform_device *dev) */ if (!dev_get_platdata(&dev->dev)) dev->dev.platform_data = &ehci_platform_defaults; - if (!dev->dev.dma_mask) - dev->dev.dma_mask = &dev->dev.coherent_dma_mask; - err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32)); + + err = dma_coerce_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32)); if (err) return err; diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index 10d6a2e
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote: > v1 has the subject of "Rework ACPI video driver" and is posted here: > http://lkml.org/lkml/2013/9/9/74 > Since the objective is really to fix Win8 backlight issues, I changed > the subject in this version, sorry about that. > > This patchset has three patches, the first introduced a new API named > backlight_device_registered in backlight layer that can be used for > backlight interface provider module to check if a specific type > backlight > interface has been registered, see changelog for patch 1/3 for > details. > Then patch 2/3 does the cleanup to sepeate the backlight control and > event delivery functionality in the ACPI video module and patch 3/3 > solves some Win8 backlight control problems by avoiding register ACPI > video's backlight interface if: > 1 Kernel cmdline option acpi_backlight=video is not given; > 2 This is a Win8 system; > 3 Native backlight control interface exists. I've tested this on my x230 (using pure UEFI with CSM disabled). As far as I can tell, it works as I would expect: - brightness keys work in initramfs, in console after boot, in lightdm prompt and in Xfce (wether or not xfce4-power-manager is running). I don't have brightness notifications (from xfce4-power-manager) but I don't usually need them so I'm fine with that. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] backlight: introduce backlight_device_registered
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote: > Introduce a new API for modules to query if a specific type of > backlight > device has been registered. This is useful for some backlight device > provider module(e.g. ACPI video) to know if a native control > interface(e.g. the interface created by i915) is available and then do > things accordingly(e.g. avoid register its own on Win8 systems). > > Signed-off-by: Aaron Lu Tested-by: Yves-Alexis Perez -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] ACPI / video: seperate backlight control and event interface
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote: > The backlight control and event delivery functionality provided by > ACPI > video module is mixed together and registered all during video device > enumeration time. As a result, the two functionality are also removed > together on module unload time or by the acpi_video_unregister > function. > The two functionalities are actually independent and one may be useful > while the other one may be broken, so it is desirable to seperate the > two functionalities such that it is clear and easy to disable one > functionality without affecting the other one. > > APIs to selectively remove backlight control interface and/or event > delivery functionality can be easily added once needed. > > Signed-off-by: Aaron Lu Tested-by: Yves-Alexis Perez -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 38/51] DMA-API: staging: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King
---
drivers/staging/dwc2/platform.c|5 +++--
drivers/staging/imx-drm/imx-drm-core.c |8 ++--
drivers/staging/imx-drm/ipuv3-crtc.c |4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 44cce2f..1d68c49 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -100,8 +100,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
*/
if (!dev->dev.dma_mask)
dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
- if (!dev->dev.coherent_dma_mask)
- dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
+ if (retval)
+ return retval;
irq = platform_get_irq(dev, 0);
if (irq < 0) {
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..847f430 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -805,6 +805,12 @@ static struct drm_driver imx_drm_driver = {
static int imx_drm_platform_probe(struct platform_device *pdev)
{
+ int ret;
+
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
imx_drm_device->dev = &pdev->dev;
return drm_platform_init(&imx_drm_driver, pdev);
@@ -847,8 +853,6 @@ static int __init imx_drm_init(void)
goto err_pdev;
}
- imx_drm_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32),
-
ret = platform_driver_register(&imx_drm_pdrv);
if (ret)
goto err_pdrv;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 6fd37a7..9e73e8d 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -523,7 +523,9 @@ static int ipu_drm_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
ipu_crtc = devm_kzalloc(&pdev->dev, sizeof(*ipu_crtc), GFP_KERNEL);
if (!ipu_crtc)
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ACPI / video: Do not register backlight if win8 and native interface exists
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote: > According to Matthew Garrett, "Windows 8 leaves backlight control up > to individual graphics drivers rather than making ACPI calls itself. > There's plenty of evidence to suggest that the Intel driver for > Windows 8 doesn't use the ACPI interface, including the fact that > it's broken on a bunch of machines when the OS claims to support > Windows 8. The simplest thing to do appears to be to disable the > ACPI backlight interface on these systems". > > So for Win8 systems, if there is native backlight control interface > registered by GPU driver, ACPI video will not register its own. For > users who prefer to keep ACPI video's backlight interface, the > existing > kernel cmdline option acpi_backlight=video can be used. > > This patch is an evolution from previous work done by Matthew Garrett, > Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki. > > Signed-off-by: Aaron Lu Tested-by: Yves-Alexis Perez -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/51] DMA-API: net: broadcom/b44: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/ethernet/broadcom/b44.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.c
b/drivers/net/ethernet/broadcom/b44.c
index 9b017d9..b4d2018 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -2183,8 +2183,7 @@ static int b44_init_one(struct ssb_device *sdev,
goto err_out_free_dev;
}
- if (dma_set_mask(sdev->dma_dev, DMA_BIT_MASK(30)) ||
- dma_set_coherent_mask(sdev->dma_dev, DMA_BIT_MASK(30))) {
+ if (dma_set_mask_and_coherent(sdev->dma_dev, DMA_BIT_MASK(30))) {
dev_err(sdev->dev,
"Required 30BIT DMA mask unsupported by the system\n");
goto err_out_powerdown;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
Hi, On Thu, Sep 19, 2013 at 11:01:03PM +0100, Russell King wrote: > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c > index 2f2e88a..c10b324 100644 > --- a/drivers/usb/dwc3/dwc3-exynos.c > +++ b/drivers/usb/dwc3/dwc3-exynos.c > @@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev) >*/ > if (!dev->dma_mask) > dev->dma_mask = &dev->coherent_dma_mask; > - if (!dev->coherent_dma_mask) > - dev->coherent_dma_mask = DMA_BIT_MASK(32); > + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); > + if (ret) > + goto err1; > > platform_set_drvdata(pdev, exynos); > > diff --git a/drivers/usb/gadget/lpc32xx_udc.c > b/drivers/usb/gadget/lpc32xx_udc.c > index 67128be..6a2a65a 100644 > --- a/drivers/usb/gadget/lpc32xx_udc.c > +++ b/drivers/usb/gadget/lpc32xx_udc.c > @@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct > platform_device *pdev) >udc->isp1301_i2c_client->addr); > > pdev->dev.dma_mask = &lpc32xx_usbd_dmamask; > - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); > + if (retval) > + goto resource_fail; > > udc->board = &lpc32xx_usbddata; > for dwc3 and drivers/usb/gadget: Acked-by: Felipe Balbi pretty cool work :-) -- balbi signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
Hi, On Thu, Sep 19, 2013 at 11:02:03PM +0100, Russell King wrote: > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c > index c10b324..8b20c70 100644 > --- a/drivers/usb/dwc3/dwc3-exynos.c > +++ b/drivers/usb/dwc3/dwc3-exynos.c > @@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) >* Since shared usb code relies on it, set it here for now. >* Once we move to full device tree support this will vanish off. >*/ > - if (!dev->dma_mask) > - dev->dma_mask = &dev->coherent_dma_mask; > - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); > + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > if (ret) > goto err1; > > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index d0759c5..6fa82d6 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device > *pdev) >* Since shared usb code relies on it, set it here for now. >* Once we have dma capability bindings this can go away. >*/ > - if (!dev->dma_mask) > - dev->dma_mask = &dev->coherent_dma_mask; > - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); > + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > if (ret) > return ret; for dwc3 and ehci-omap: Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: > Use platform_device_register_full() for those drivers which can, to > avoid messing directly with DMA masks. This can only be done when > the driver does not need to access the allocated musb platform device > from within its callbacks, which may be called during the musb > device probing. > > Signed-off-by: Russell King you want me to carry this one through my tree or you prefer getting my Acked-by ? Either way works for me: Acked-by: Felipe Balbi there's also the third option of me setting up a branch with only this patch and we both merge it, that'd also work. cheers -- balbi signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: > Hi, > > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: > > Use platform_device_register_full() for those drivers which can, to > > avoid messing directly with DMA masks. This can only be done when > > the driver does not need to access the allocated musb platform device > > from within its callbacks, which may be called during the musb > > device probing. > > > > Signed-off-by: Russell King > > you want me to carry this one through my tree or you prefer getting my > Acked-by ? Either way works for me: > > Acked-by: Felipe Balbi > > there's also the third option of me setting up a branch with only this > patch and we both merge it, that'd also work. I think this patch is sufficiently stand-alone that it should be fine if you want to take it through your tree. That may be better in the long run to avoid conflicts with this patch and any future work in this area during this cycle. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: > On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: > > The correct way for a driver to specify the coherent DMA mask is > > not to directly access the field in the struct device, but to use > > dma_set_coherent_mask(). Only arch and bus code should access this > > member directly. > > > > Convert all direct write accesses to using the correct API. > > > > Signed-off-by: Russell King > > Acked-by: Tejun Heo > > The patch is pretty widely spread. I don't mind how it gets routed > but what's the plan? The plan is... I'm going to try and avoid going through the hell of re-posting this patch series to all the recipients another time... (It's taken some 17 hours and lots of hand holding to get this patch set out without exim jumping off a cliff into deep OOM - soo deep that even the OOM killer doesn't run and the CPU is 100% idle because every single process stuck in an uninterruptible sleep waiting for every other process to free some memory - ouch!) I know that dealing with this patch set will be a problem due to how widespread this is, but much of the driver level changes come down to depending on a couple of patches. One solution would be if I published a branch with just the dependencies in, which subsystem maintainers could pull, and then apply the appropriate patches on top. Another would be if subsystem maintainers are happy that I carry them, I can add the acks, and then later on towards the end of the cycle, provide a branch subsystem maintainers could pull. Or... if you can think of something easier... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote: > On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: > [...] > > -dma_set_coherent_mask() will always be able to set the same or a > > -smaller mask as dma_set_mask(). However for the rare case that a > > +The coherent coherent mask will always be able to set the same or a > > +smaller mask as the streaming mask. However for the rare case that a > [...] > > The new wording doesn't make sense; a mask doesn't set itself. I would > suggest: > > "The coherent mask can always be set to the same or a smaller mask than > the streaming mask." Yes, the original sentence is not particularly good, but I think even your modified version can be interpreted as "a mask setting itself" for all the same reasons that the original can be (which mask does "same" refer to?) Even so, I prefer your version. Thanks. :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 40/51] DMA-API: crypto: fix ixp4xx crypto platform device support
Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function. There's a reason that
warning is there and that's not for people to hide in this way. It's
there to persuade people to use the correct APIs to allocate platform
devices.
Signed-off-by: Russell King
---
drivers/crypto/ixp4xx_crypto.c | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 21180d6..8306185 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -218,23 +218,10 @@ static dma_addr_t crypt_phys;
static int support_aes = 1;
-static void dev_release(struct device *dev)
-{
- return;
-}
-
#define DRIVER_NAME "ixp4xx_crypto"
-static struct platform_device pseudo_dev = {
- .name = DRIVER_NAME,
- .id = 0,
- .num_resources = 0,
- .dev = {
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .release = dev_release,
- }
-};
-static struct device *dev = &pseudo_dev.dev;
+static struct platform_device *pdev;
+static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -1418,20 +1405,30 @@ static struct ixp_alg ixp4xx_algos[] = {
} };
#define IXP_POSTFIX "-ixp4xx"
+
+static const struct platform_device_info ixp_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static int __init ixp_module_init(void)
{
int num = ARRAY_SIZE(ixp4xx_algos);
- int i,err ;
+ int i, err ;
- if (platform_device_register(&pseudo_dev))
- return -ENODEV;
+ pdev = platform_device_register_full(&ixp_dev_info);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ dev = &pdev->dev;
spin_lock_init(&desc_lock);
spin_lock_init(&emerg_lock);
err = init_ixp_crypto();
if (err) {
- platform_device_unregister(&pseudo_dev);
+ platform_device_unregister(pdev);
return err;
}
for (i=0; i< num; i++) {
@@ -1496,7 +1493,7 @@ static void __exit ixp_module_exit(void)
crypto_unregister_alg(&ixp4xx_algos[i].crypto);
}
release_ixp_crypto();
- platform_device_unregister(&pseudo_dev);
+ platform_device_unregister(pdev);
}
module_init(ixp_module_init);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King
---
drivers/dma/amba-pl08x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index fce46c5..e51a983 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
if (ret)
return ret;
+ /* Ensure that we can do DMA */
+ ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out_no_pl08x;
+
/* Create the driver state holder */
pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
if (!pl08x) {
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/51] DMA-API: net: b43: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/wireless/b43/dma.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index c51d2dc..1d7982a 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1065,12 +1065,9 @@ static int b43_dma_set_mask(struct b43_wldev *dev, u64
mask)
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = dma_set_mask(dev->dev->dma_dev, mask);
- if (!err) {
- err = dma_set_coherent_mask(dev->dev->dma_dev, mask);
- if (!err)
- break;
- }
+ err = dma_set_mask_and_coherent(dev->dev->dma_dev, mask);
+ if (!err)
+ break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King --- arch/powerpc/kernel/vio.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index 78a3506..96b6c97 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask(&viodev->dev, DMA_BIT_MASK(64)); - dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64)); + dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); } /* register with generic device framework */ -- 1.7.4.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Hi, On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: > > Hi, > > > > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: > > > Use platform_device_register_full() for those drivers which can, to > > > avoid messing directly with DMA masks. This can only be done when > > > the driver does not need to access the allocated musb platform device > > > from within its callbacks, which may be called during the musb > > > device probing. > > > > > > Signed-off-by: Russell King > > > > you want me to carry this one through my tree or you prefer getting my > > Acked-by ? Either way works for me: > > > > Acked-by: Felipe Balbi > > > > there's also the third option of me setting up a branch with only this > > patch and we both merge it, that'd also work. > > I think this patch is sufficiently stand-alone that it should be fine > if you want to take it through your tree. That may be better in the > long run to avoid conflicts with this patch and any future work in > this area during this cycle. awesome, i'll take this one early next week. -- balbi signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
On Thu, Sep 19, 2013 at 10:53:02PM +0100, Russell King wrote: > This code sequence is unsafe in modules: > > static u64 mask = DMA_BIT_MASK(something); > ... > if (!dev->dma_mask) > dev->dma_mask = &mask; Acked-by: Mark Brown signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:27 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/51] DMA-API: net: intel/e1000: replace dma_set_mask()+dma_set_coherent_mask() with new helper
On Thu, 2013-09-19 at 22:37 +0100, Russell King wrote: > Replace the following sequence: > > dma_set_mask(dev, mask); > dma_set_coherent_mask(dev, mask); > > with a call to the new helper dma_set_mask_and_coherent(). > > Signed-off-by: Russell King > --- > drivers/net/ethernet/intel/e1000/e1000_main.c |9 ++--- > 1 files changed, 2 insertions(+), 7 deletions(-) Acked-by: Jeff Kirsher signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:28 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 18 ++
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:29 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev, "No usable DMA "
> "configuration, aborting\n");
> goto err_dma;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++
> 1 files changed, 6 insertions(+), 12 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:30 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> pr_err("No usable DMA configuration,
> aborting\n");
> goto err_dma_mask;
> }
> }
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
> 1 files changed, 5 insertions(+), 11 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:31 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev,
> "No usable DMA configuration,
> aborting\n");
> goto err_dma;
> }
> }
> pci_using_dac = 0;
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +--
> 1 files changed, 5 insertions(+), 10 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
On Thu, 2013-09-19 at 22:32 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> if (err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(32));
> if (err) {
> dev_err(&pdev->dev, "No usable DMA "
> "configuration, aborting\n");
> goto err_dma;
> }
> }
> pci_using_dac = 0;
> }
> This means we only set the coherent DMA mask in the fallback path if
> the DMA mask set failed, which is silly. This fixes it to set the
> coherent DMA mask only if dma_set_mask() succeeded, and to error out
> if either fails.
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15
> +--
> 1 files changed, 5 insertions(+), 10 deletions(-)
Acked-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
Hey, On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote: > Another would be if subsystem maintainers are happy that I carry them, > I can add the acks, and then later on towards the end of the cycle, > provide a branch subsystem maintainers could pull. > > Or... if you can think of something easier... I'm happy with the latter method and it's likely that you'll end up carrying at least some of the patches through your tree anyway. Please feel free to add my acks to all libata related patches and carry them through your tree. Thanks and have fun routing. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
On 09/17/2013 10:55 PM, Daniel Vetter wrote: On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote: On 09/11/2013 03:31 PM, Peter Hurley wrote: [+cc dri-devel] On 09/11/2013 11:38 AM, Steven Rostedt wrote: On Wed, 11 Sep 2013 11:16:43 -0400 Peter Hurley wrote: The funny part is, there's a comment there that shows that this was done even for "PREEMPT_RT". Unfortunately, the call to "get_scanout_position()" can call functions that use the rt-mutex "sleeping spin locks" and it breaks there. I guess we need to ask the authors of the mainline patch exactly why that preempt_disable() is needed? The drm core associates a timestamp with each vertical blank frame #. Drm drivers can optionally support a 'high resolution' hw timestamp. The vblank frame #/timestamp tuple is user-space visible. The i915 drm driver supports a hw timestamp via this drm helper function which computes the timestamp from the crtc scan position (based on the pixel clock). For mainline, the preempt_disable/_enable() isn't actually necessary because every call tree that leads here already has preemption disabled. For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? No, it should not. Note, any other lock that can be held when it is held would also need to be raw. By that, you mean "any other lock" that might be claimed "would also need to be raw"? Hopefully not "any other lock" already held? And by taking a quick audit of the code, I see this: spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); /* Reset the chip */ /* GEN6_GDRST is not in the gt power well, no need to check * for fifo space for the write or forcewake the chip for * the read */ __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); /* Spin waiting for the device to ack the reset request */ ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & GEN6_GRDOM_FULL) == 0, 500); That spin is unacceptable in RT with preemption and interrupts disabled. Yep. That would be bad. AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included in the force-wake set, so raw reads of the registers would probably be acceptable (thus obviating the need for claiming the uncore.lock). Except that _ALL_ register access is disabled with the uncore.lock during a gpu reset. Not sure if that's meant to include crtc registers or not, or what other synchronization/serialization issues are being handled/hidden by forcing all register accesses to wait during a gpu reset. Hopefully an i915 expert can weigh in here? Daniel, Can you shed some light on whether the i915+ crtc registers (specifically those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter()) read as part of the vblank counter/timestamp handling need to be prevented during gpu reset? The depency here in the locking is a recent addition: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access It's a (slightly) oversized hammer to work around a hardware issue - we could break it down to register blocks, which can be accessed concurrently, but that tends to be more fragile. But the chip really dies if you access (even just reads) the same block concurrently :( We could try break the spinlock protected section a bit in the reset handler - register access on a hung gpu tends to be ill-defined anyway. The implied wait with preemption and interrupts disabled is causing grief in -RT, but also a 4ms wait inside an irq handler seems like a bad idea. Oops, the magic code in wait_for which is just there to make the imo totally misguided kgdb support work papered over the aweful long wait in atomic context ever since we've added this in commit b6e45f866465f42b53d803b0c574da0fc508a0e9 Author: Keith Packard Date: Fri Jan 6 11:34:04 2012 -0800 drm/i915: Move reset forcewake processing to gen6_do_reset Reverting this change should be enough (code moved obviously a bit). Cheers, Daniel Regards, Peter Hurley What's the real issue here? That the vblank timestamp needs to be an accurate measurement of a realtime event. Sleeping/servicing interrupts while reading the registers necessary to compute the timestamp would be bad too. (edit: which hopefully Mario Kleiner clarified in his reply) My point earlier was three-fold: 1. Don't need the preempt_disable() for mainline: all callers are already holding interrupt-disabling spinlocks. 2. -RT still needs to prevent scheduling there. 3. the problem is i915-specific. [update: the radeon driver should also BUG like the i915 driver but probably should have mmio_idx_lock spinlock as raw] Ok, so register access must be serialized, at least within a register block, no way around it. Thanks for explaining this. That makes me a bit depressed. Is this also true for older hw generations than gen6? Daniel, could we move access to the display regist
Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote: > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King: > > The DMA API requires drivers to call the appropriate dma_set_mask() > > functions before doing any DMA mapping. Add this required call to > > the AMBA PL08x driver. > ^--- copy and paste error - should of course be PL330 Fixed, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ACPI / video: Do not register backlight if win8 and native interface exists
On 09/20/2013 04:36 PM, Jani Nikula wrote:
> On Tue, 17 Sep 2013, Aaron Lu wrote:
>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>> to individual graphics drivers rather than making ACPI calls itself.
>> There's plenty of evidence to suggest that the Intel driver for
>> Windows 8 doesn't use the ACPI interface, including the fact that
>> it's broken on a bunch of machines when the OS claims to support
>> Windows 8. The simplest thing to do appears to be to disable the
>> ACPI backlight interface on these systems".
>>
>> So for Win8 systems, if there is native backlight control interface
>> registered by GPU driver, ACPI video will not register its own. For
>> users who prefer to keep ACPI video's backlight interface, the existing
>> kernel cmdline option acpi_backlight=video can be used.
>>
>> This patch is an evolution from previous work done by Matthew Garrett,
>> Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki.
>>
>> Signed-off-by: Aaron Lu
>> ---
>> drivers/acpi/internal.h | 5 ++---
>> drivers/acpi/video.c| 27 +--
>> drivers/acpi/video_detect.c | 14 --
>> 3 files changed, 19 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
>> index 20f4233..453ae8d 100644
>> --- a/drivers/acpi/internal.h
>> +++ b/drivers/acpi/internal.h
>> @@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
>> Video
>>
>> -- */
>> #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
>> -bool acpi_video_backlight_quirks(void);
>> -#else
>> -static inline bool acpi_video_backlight_quirks(void) { return false; }
>> +bool acpi_osi_is_win8(void);
>> +bool acpi_video_verify_backlight_support(void);
>> #endif
>>
>> #endif /* _ACPI_INTERNAL_H_ */
>> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
>> index 5ad5a71..343db59 100644
>> --- a/drivers/acpi/video.c
>> +++ b/drivers/acpi/video.c
>> @@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
>> *device, int event)
>> unsigned long long level_current, level_next;
>> int result = -EINVAL;
>>
>> -/* no warning message if acpi_backlight=vendor is used */
>> -if (!acpi_video_backlight_support())
>> +/* no warning message if acpi_backlight=vendor or a quirk is used */
>> +if (!acpi_video_verify_backlight_support())
>> return 0;
>>
>> if (!device->brightness)
>> @@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus
>> *video,
>> static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
>> {
>> return acpi_video_bus_DOS(video, 0,
>> - acpi_video_backlight_quirks() ? 1 : 0);
>> + acpi_osi_is_win8() ? 1 : 0);
>> }
>>
>> static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
>> {
>> return acpi_video_bus_DOS(video, 0,
>> - acpi_video_backlight_quirks() ? 0 : 1);
>> + acpi_osi_is_win8() ? 0 : 1);
>> }
>>
>> static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
>> @@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level,
>> void *context,
>>
>> static void acpi_video_dev_register_backlight(struct acpi_video_device
>> *device)
>> {
>> -if (acpi_video_backlight_support()) {
>> +if (acpi_video_verify_backlight_support()) {
>> struct backlight_properties props;
>> struct pci_dev *pdev;
>> acpi_handle acpi_parent;
>> @@ -1677,23 +1677,6 @@ static int acpi_video_bus_unregister_backlight(struct
>> acpi_video_bus *video)
>> return error;
>> }
>>
>> -int acpi_video_unregister_backlight(void)
>> -{
>> -struct acpi_video_bus *video;
>> -int error = 0;
>> -
>> -mutex_lock(&video_list_lock);
>> -list_for_each_entry(video, &video_bus_head, entry) {
>> -error = acpi_video_bus_unregister_backlight(video);
>> -if (error)
>> -break;
>> -}
>> -mutex_unlock(&video_list_lock);
>> -
>> -return error;
>> -}
>> -EXPORT_SYMBOL(acpi_video_unregister_backlight);
>
> You add this in patch 2/3 only to remove it again in 3/3?
This is a mistake while I'm preparing the patches, I'll fix it in next
revision, thanks for pointing this out.
>
>> -
>> static void acpi_video_dev_add_notify_handler(struct acpi_video_device
>> *device)
>> {
>> acpi_status status;
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index 940edbf..23d7d26 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "internal.h"
>>
>> @@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
>>
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On 09/18/2013 08:36 PM, Igor Gnatenko wrote: > On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote: >> On 09/18/2013 02:30 PM, Igor Gnatenko wrote: >>> On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote: On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > > Aaron, how about fix indicator on ThinkPads ? Can you please describe the problem in detail, is it that when you adjust brightness level through hotkey, there is no GUI indication? Thanks. -Aaron >>> >>> Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually >>> brightnes changing, but have no indicator in GUI. >> >> Oh, that's still the problem of _BCL not getting executed once for >> Lenovo thinkpad laptops. I borrowed a Thinkpad X1 this afternoon and can >> reproduce this, I'll take a look at this issue. The thinkpad-acpi module >> already has a call to _BCL but somehow that doesn't happen. >> >> Since it's national holidays here, I'll check this issue when I got back >> to work on this Saturday. Thanks for the quick test :-) > Thanks. No problem ;-) Here is a quick fix for thinkpad-acpi.c: https://github.com/aaronlu/linux acpi_video_win8 commit thinkpad-acpi: fix handle locate for video and query of _BCL. Note that it is a separate issue specifically for thinkpad so I'll submit that patch in another thread. Thanks, Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On Sun, 2013-09-22 at 17:10 +0800, Aaron Lu wrote: > On 09/18/2013 08:36 PM, Igor Gnatenko wrote: > > On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote: > >> On 09/18/2013 02:30 PM, Igor Gnatenko wrote: > >>> On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote: > On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > > > > Aaron, how about fix indicator on ThinkPads ? > > Can you please describe the problem in detail, is it that when you > adjust brightness level through hotkey, there is no GUI indication? > Thanks. > > -Aaron > >>> > >>> Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually > >>> brightnes changing, but have no indicator in GUI. > >> > >> Oh, that's still the problem of _BCL not getting executed once for > >> Lenovo thinkpad laptops. I borrowed a Thinkpad X1 this afternoon and can > >> reproduce this, I'll take a look at this issue. The thinkpad-acpi module > >> already has a call to _BCL but somehow that doesn't happen. > >> > >> Since it's national holidays here, I'll check this issue when I got back > >> to work on this Saturday. Thanks for the quick test :-) > > Thanks. No problem ;-) > > Here is a quick fix for thinkpad-acpi.c: > https://github.com/aaronlu/linux acpi_video_win8 > commit thinkpad-acpi: fix handle locate for video and query of _BCL. > > Note that it is a separate issue specifically for thinkpad so I'll > submit that patch in another thread. > > Thanks, > Aaron Excellent! I've tested 3 patches from this patchset + 1 latest patch from you branch and it is works fine. Regulating and indicating works OK. Thank you. I think you need to make new patch-set within 4 patches. -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.12.0-0.rc1.git0.1.fc20.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King wrote: > AMBA Primecell devices always treat streaming and coherent DMA exactly > the same, so there's no point in having the masks separated. > > Signed-off-by: Russell King for the drivers/of/platform.c portion: Acked-by: Grant Likely g. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > > > > Hi, > > > > saw your posting in [1]... can you try the patches below? > > Not sure if they apply. > > Did you try v3.11-rc6(+)... or drm-intel-nightly? > > > > Regards, > > - Sedat - > > > > [1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > > Same thing observed with v3.11-rc7. I still see this with 3.11. Following this message, my VGA monitor goes blank and shows an error suggesting a wrong resolution or frequency are set. Anyone? > > > > > -- Forwarded message -- > > From: Sedat Dilek > > Date: Tue, Jul 2, 2013 at 7:31 AM > > Subject: Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several > > call-traces ] > > To: Daniel Vetter > > Cc: "Barnes, Jesse" , Stephen Rothwell > > , linux-next , Linux > > Kernel Mailing List , intel-gfx > > , DRI > > , Dave Airlie > > > > > > On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek wrote: > > > On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter > > > wrote: > > >> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek > > >> wrote: > > >>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell > > >>> wrote: > > Hi all, > > > > Changes since 20130628: > > > > The regulator tree gained a build failure so I used the version from > > next-20130628. > > > > The trivial tree gained a conflict against the fbdev tree. > > > > The arm-soc tree gained a conflict against the net-next tree. > > > > The akpm tree lost a few patches that turned up elsewhere and I > > removed 2 > > that were causing run time problems. > > > > >>> > > >>> [ CC drm and drm-intel folks ] > > >>> > > >>> [ Did not check any relevant MLs ] > > >>> > > >>> Please, see attached dmesg output. > > >> > > >> Clock mismatch, one for Jesse to figure out. Note that this patch is > > >> for 3.12, I simply haven't yet gotten around to properly split my > > >> patch queue so a few spilled into -next. I'll do that now. > > > > > > I like lightspeed-fast replies :-). > > > > > > Guess "drm/i915: get mode clock when reading the pipe config v9" [1] > > > is the cause. > > > > > > > Problem solved by applying these patches to next-20130701 from > > intel-gfx patchwork-service [0]: > > > >[1/2] drm/i915: fixup messages in pipe_config_compare > >[2/2] drm/i915: get clock config when checking CRTC state too > > > > AFAICS 2/2 was folded into updated "drm/i915: get mode clock when > > reading the pipe config v9" [3]. > > > > It would be kind to be CCed on the patches and get also some credits. > > Also a CC to the report in linux-next should IMHO be done. > > > > - Sedat - > > > > [0] https://patchwork.kernel.org/project/intel-gfx/list/ > > [1] https://patchwork.kernel.org/patch/2809031/ > > [2] https://patchwork.kernel.org/patch/2809021/ > > [3] > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly&id=f1f644dc66cbaf5a4c7dcde683361536b41885b9 > > > > > - Sedat - > > > > > > [1] > > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=d325d8b4f351f9d45e7c8baabf581fd21f343133 > > > > > >> -Daniel > > >> -- > > >> Daniel Vetter > > >> Software Engineer, Intel Corporation > > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: Fix broken TDA998x audio (was: Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration)
Ping?
On Mon, Sep 02, 2013 at 03:50:57PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > This patch adds tda998x specific parameters to allow it to be configured
> > for different boards using it. Also, this implements rudimentary audio
> > support for S/PDIF attached controllers.
> >
> > Signed-off-by: Russell King
> > Signed-off-by: Sebastian Hesselbarth
> > Tested-by: Darren Etheridge
> > ---
>
> It looks like there's been a bug introduced in this patch (which wasn't
> in my original).
>
> > @@ -445,8 +681,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int
> > mode)
> >
> > switch (mode) {
> > case DRM_MODE_DPMS_ON:
> > - /* enable audio and video ports */
> > - reg_write(encoder, REG_ENA_AP, 0xff);
> > + /* enable video ports, audio will be enabled later */
> > reg_write(encoder, REG_ENA_VP_0, 0xff);
> > reg_write(encoder, REG_ENA_VP_1, 0xff);
> > reg_write(encoder, REG_ENA_VP_2, 0xff);
>
> I also disabled the writing to REG_ENA_AP in the DPMS off path as well,
> which clears this register.
>
> That seems to be missing from this patch, and it means that when the
> display is placed into DPMS-off mode, the audio inputs are disabled,
> never to be re-enabled. There is no need to disable the audio input
> in DPMS-off mode.
>
> 8<=
> From: Russell King
> Subject: [PATCH] drm/i2c: Fix broken TDA998x audio
>
> In patch "drm/i2c: tda998x: add video and audio input configuration" in
> its original version, disabling the audio input port was removed. The
> version which was submitted for merging had this change deleted, which
> results in audio being non-functional. Fix this by removing the write.
> While here, update the comment too.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 5742cfc..59878af 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -705,8 +705,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int
> mode)
> reg_write(encoder, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
> break;
> case DRM_MODE_DPMS_OFF:
> - /* disable audio and video ports */
> - reg_write(encoder, REG_ENA_AP, 0x00);
> + /* disable video ports */
> reg_write(encoder, REG_ENA_VP_0, 0x00);
> reg_write(encoder, REG_ENA_VP_1, 0x00);
> reg_write(encoder, REG_ENA_VP_2, 0x00);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"
You have drm_dev->struct_mutex grabbed before ->mmap_sem in exynos_drm_gem_mmap_ioctl() and after - in exynos_drm_gem_fault() (since ->fault() is always called with ->mmap_sem held). Looks like a garden-variety AB-BA deadlock... Incidentally, what should happen if another process shares the same opened file (e.g. inherited over fork()) and does mmap() just as we have ->f_op switched? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote: > On 09/17/2013 10:55 PM, Daniel Vetter wrote: > > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley > > wrote: > >> On 09/11/2013 03:31 PM, Peter Hurley wrote: > >>> > >>> [+cc dri-devel] > >>> > >>> On 09/11/2013 11:38 AM, Steven Rostedt wrote: > > On Wed, 11 Sep 2013 11:16:43 -0400 > Peter Hurley wrote: > > >> The funny part is, there's a comment there that shows that this was > >> done even for "PREEMPT_RT". Unfortunately, the call to > >> "get_scanout_position()" can call functions that use the rt-mutex > >> "sleeping spin locks" and it breaks there. > >> > >> I guess we need to ask the authors of the mainline patch exactly why > >> that preempt_disable() is needed? > > > > > > The drm core associates a timestamp with each vertical blank frame #. > > Drm drivers can optionally support a 'high resolution' hw timestamp. > > The vblank frame #/timestamp tuple is user-space visible. > > > > The i915 drm driver supports a hw timestamp via this drm helper function > > which computes the timestamp from the crtc scan position (based on the > > pixel clock). > > > > For mainline, the preempt_disable/_enable() isn't actually necessary > > because every call tree that leads here already has preemption disabled. > > > > For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? > > > > No, it should not. Note, any other lock that can be held when it is > held would also need to be raw. > >>> > >>> > >>> By that, you mean "any other lock" that might be claimed "would also need > >>> to be raw"? Hopefully not "any other lock" already held? > >>> > And by taking a quick audit of the code, I see this: > > spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); > > /* Reset the chip */ > > /* GEN6_GDRST is not in the gt power well, no need to check > * for fifo space for the write or forcewake the chip for > * the read > */ > __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); > > /* Spin waiting for the device to ack the reset request */ > ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & > GEN6_GRDOM_FULL) == 0, 500); > > That spin is unacceptable in RT with preemption and interrupts disabled. > >>> > >>> > >>> Yep. That would be bad. > >>> > >>> AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included > >>> in the force-wake set, so raw reads of the registers would > >>> probably be acceptable (thus obviating the need for claiming the > >>> uncore.lock). > >>> > >>> Except that _ALL_ register access is disabled with the uncore.lock > >>> during a gpu reset. Not sure if that's meant to include crtc registers > >>> or not, or what other synchronization/serialization issues are being > >>> handled/hidden by forcing all register accesses to wait during a gpu > >>> reset. > >>> > >>> Hopefully an i915 expert can weigh in here? > >> > >> > >> > >> Daniel, > >> > >> Can you shed some light on whether the i915+ crtc registers (specifically > >> those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter()) > >> read as part of the vblank counter/timestamp handling need to > >> be prevented during gpu reset? > > > > The depency here in the locking is a recent addition: > > > > commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a > > Author: Chris Wilson > > Date: Fri Jul 19 20:36:51 2013 +0100 > > > > drm/i915: Serialize almost all register access > > > > It's a (slightly) oversized hammer to work around a hardware issue - > > we could break it down to register blocks, which can be accessed > > concurrently, but that tends to be more fragile. But the chip really > > dies if you access (even just reads) the same block concurrently :( > > > > We could try break the spinlock protected section a bit in the reset > > handler - register access on a hung gpu tends to be ill-defined > > anyway. > > > >> The implied wait with preemption and interrupts disabled is causing grief > >> in -RT, but also a 4ms wait inside an irq handler seems like a bad idea. > > > > Oops, the magic code in wait_for which is just there to make the imo > > totally misguided kgdb support work papered over the aweful long wait > > in atomic context ever since we've added this in > > > > commit b6e45f866465f42b53d803b0c574da0fc508a0e9 > > Author: Keith Packard > > Date: Fri Jan 6 11:34:04 2012 -0800 > > > > drm/i915: Move reset forcewake processing to gen6_do_reset > > > > Reverting this change should be enough (code moved obviously a bit). > > > > Cheers, Daniel > > > >> > >> Regards, > >> Peter Hurley > >> > >> > >> > What's the real issue here? > >>> > >>> > >>> That the vblank timestamp needs to be an accurate measurement of a > >>> realtime event. Sleeping/servicing interrupts
[PATCH] drm/exynos: fix deadlock issue at mmap
This patch fixes the deadlock issue when another process requested
mmap system call.
This issue can incur the deadlock if another process sharing the same
file called mmap system call between ->f_op pointer chaning and restoring.
So this patch calls down_write(&mm->mmap_sem) before do_mmap_pgoff
call and then up_write(&mm->mmap_sem) after do_mmap_pg_off call
so that when another process called mmap system call, the process
can wait for up_write() call until the ->f_op pointer is restored.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 49f9cd2..779c2d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include "exynos_drm_drv.h"
@@ -420,6 +421,7 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void
*data,
{
struct drm_exynos_gem_mmap *args = data;
struct drm_gem_object *obj;
+ struct mm_struct *mm = current->mm;
unsigned long addr;
if (!(dev->driver->driver_features & DRIVER_GEM)) {
@@ -433,6 +435,8 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ down_write(&mm->mmap_sem);
+
/*
* We have to use gem object and its fops for specific mmaper,
* but vm_mmap() can deliver only filp. So we have to change
@@ -457,8 +461,17 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void
*data,
*/
file_priv->filp->private_data = obj;
- addr = vm_mmap(file_priv->filp, 0, args->size,
- PROT_READ | PROT_WRITE, MAP_SHARED, 0);
+ addr = security_mmap_file(file_priv->filp, PROT_READ | PROT_WRITE,
+ MAP_SHARED);
+ if (!addr) {
+ unsigned long populate;
+
+ addr = do_mmap_pgoff(file_priv->filp, 0, args->size,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED, 0, &populate);
+ if (populate)
+ mm_populate(addr, populate);
+ }
drm_gem_object_unreference(obj);
@@ -469,10 +482,13 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev,
void *data,
file_priv->filp->private_data = file_priv;
}
mutex_unlock(&dev->struct_mutex);
+ up_write(&mm->mmap_sem);
+
return (int)addr;
}
mutex_unlock(&dev->struct_mutex);
+ up_write(&mm->mmap_sem);
args->mapped = addr;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon: Don't run tests when underlying memory was uninitialized
P.S.: don't run means don't allow to run, by either feeding radeon.test=X
or radeon.benchmark=1
22.09.2013, в 5:18, Alex Ivanov написал(а):
> 20.09.2013, в 22:33, Alex Deucher написал(а):
>
>> On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov wrote:
>>> Prevent NULL pointer dereference in case when radeon_ring_fini() did it's
>>> job.
>>>
>>> Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead
>>> to a KP if ring buffer was deallocated, e.g. on failed ring test.
>>> Seen on PA-RISC machine having "radeon: ring test failed
>>> (scratch(0x8504)=0xCAFEDEAD)" issue.
>>>
>>> Signed-off-by: Alex Ivanov
>>
>> Applied. thanks!
>>
>> Alex
>
> One more. Thank you!
>
> Signed-off-by: Alex Ivanov
> ---
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index e29faa7..e6d1897 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1319,6 +1319,11 @@ int radeon_device_init(struct radeon_device *rdev,
>if (r)
>return r;
>}
> + /* If ring buffer or PCI GART got uninitialized, we should't run
> tests */
> + if (!rdev->accel_working) {
> + DRM_INFO("radeon: acceleration disabled, skipping tests and
> benchmark.\n");
> + return 0;
> + }
>if ((radeon_testing & 1)) {
>radeon_test_moves(rdev);
>}
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King
Acked-by: Vinod Koul
~Vinod
> ---
> drivers/dma/amba-pl08x.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> index fce46c5..e51a983 100644
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const
> struct amba_id *id)
> if (ret)
> return ret;
>
> + /* Ensure that we can do DMA */
> + ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto out_no_pl08x;
> +
> /* Create the driver state holder */
> pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
> if (!pl08x) {
> --
> 1.7.4.4
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> Signed-off-by: Russell King
Acked-by: Vinod Koul
This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?
~Vinod
> ---
> drivers/dma/edma.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index ff50ff4..7f9fe30 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
> static const struct platform_device_info edma_dev_info0 = {
> .name = "edma-dma-engine",
> .id = 0,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static const struct platform_device_info edma_dev_info1 = {
> .name = "edma-dma-engine",
> .id = 1,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static int edma_init(void)
> @@ -720,8 +722,6 @@ static int edma_init(void)
> ret = PTR_ERR(pdev0);
> goto out;
> }
> - pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
> - pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> if (EDMA_CTLRS == 2) {
> @@ -731,8 +731,6 @@ static int edma_init(void)
> platform_device_unregister(pdev0);
> ret = PTR_ERR(pdev1);
> }
> - pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
> - pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> out:
> --
> 1.7.4.4
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote: > > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King: > > > The DMA API requires drivers to call the appropriate dma_set_mask() > > > functions before doing any DMA mapping. Add this required call to > > > the AMBA PL08x driver. > > ^--- copy and paste error - should of course be PL330 > > Fixed, thanks. with fixed changelog... Acked-by: Vinod Koul ~Vinod -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This avoids a direct reference to the DMA
> > masks by this driver.
> >
> > Signed-off-by: Russell King
> Acked-by: Vinod Koul
>
> This also brings me question that should we force the driver to use the
> dma_set_mask_and_coherent() API or they have below flexiblity too?
There's two issues here:
1. dma_set_mask_and_coherent() will only work if dev->dma_mask points at
some storage for the mask. This needs to have .dma_mask in the
platform_device_info initialised.
2. Yes, this driver should also be calling the appropriate DMA mask setting
functions in addition to having the mask initialized at device creation
time.
Here's a replacement patch, though maybe it would be better to roll all
the additions of dma_set_mask_and_coherent() in drivers/dma into one
patch? In other words, combine the addition of this with these two
patches:
dma: pl330: add dma_set_mask_and_coherent() call
dma: pl08x: add dma_set_mask_and_coherent() call
8<=
From: Russell King
Subject: [PATCH] DMA-API: dma: edma.c: no need to explicitly initialize DMA
masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
While here, add the dma_set_mask_and_coherent() call which the DMA API
requires DMA-using drivers to call.
Signed-off-by: Russell King
---
drivers/dma/edma.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..fd5e48c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -631,6 +631,10 @@ static int edma_probe(struct platform_device *pdev)
struct edma_cc *ecc;
int ret;
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
ecc = devm_kzalloc(&pdev->dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
dev_err(&pdev->dev, "Can't allocate controller\n");
@@ -702,11 +706,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = "edma-dma-engine",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = "edma-dma-engine",
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +726,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
- pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +735,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
- pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"
On Mon, Sep 23, 2013 at 04:49:30PM +0900, Inki Dae wrote: > Hi, > > > -Original Message- > > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro > > Sent: Monday, September 23, 2013 6:29 AM > > To: YoungJun Cho > > Cc: dri-devel@lists.freedesktop.org; Inki Dae > > Subject: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm > > close" > > > > You have drm_dev->struct_mutex grabbed before ->mmap_sem in > > exynos_drm_gem_mmap_ioctl() and after - in exynos_drm_gem_fault() > > (since ->fault() is always called with ->mmap_sem held). Looks like > > a garden-variety AB-BA deadlock... > > > > Right, if mmap system call is requested by another process between ->f_op > pointer changing and restoring, the deadlock can be incurred. > > For this, I think we can resolve this issue like below, > > At exynos_drm_gem_mmap_ioctl() > down_write(&mm->mmap_sem); > mutex_lock(&dev->struct_mutex); > ... Umm... If you do it that way, why bother with changing ->private_data at all? You can as well stash obj in dev->dev_private->something after you've grabbed the mutex and have ->mmap() pick it there... Said that, I really don't like that approach - both playing with ->f_op and the games with private vmas; exynos_gem_get_vma(), AFAICS, calls find_vma() (without bothering to hold ->mmap_sem, BTW - there's nothing to prevent the result of find_vma() being freed just as it's returned to caller) and clones it manually, regardless of whether that vma allows to clone itself or not. Quite a few drivers rely on that not happening... IOW, you are already digging deep inside VM guts and this only makes it deeper ;-/ And no, the deadlock doesn't depend on race between ioctl() and mmap() from another process; all it takes is 1) thread A does clone(), creating thread B that shares address space with it. 2) thread A does that ioctl, creating a mapping 3) thread A does that ioctl again, creating another mapping, while thread B dereferences an address in the first mapping and triggers a page fault. The only race is on step 3 in the above; the question about mmap() vs. ioctl() was about mmap(2) _during_ that ioctl() hitting exynos_drm_gem_mmap_buffer() instead of exynos_drm_gem_mmap() it would've called before or after ioctl(). Here the interesting case is when callers of mmap() and ioctl() do *not* share the address space, since in that case mmap(2) won't notice ->mmap_sem held by you - it's on the different mm_struct, so mmap(2) will get to calling the ->f_op->mmap() without waiting for you to restore ->f_op... For another bug in the same area, try building that driver modular and watch what happens to use count after a round of this switching ->f_op and restoring it back to original; fops_get() in there is wrong and AFAICS pointless. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix comment referring to the long gone ->probe() connector vfunc
drm_helper_probe_single_connector_modes() can be used to implement ->fill_modes(), not ->probe(). Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_crtc_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 4280e37..5fcb9d4 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -109,9 +109,9 @@ static void drm_mode_validate_flag(struct drm_connector *connector, * then culled (based on validity and the @maxX, @maxY parameters) and put into * the normal modes list. * - * Intended to be use as a generic implementation of the ->probe() @connector - * callback for drivers that use the crtc helpers for output mode filtering and - * detection. + * Intended to be use as a generic implementation of the ->fill_modes() + * @connector vfunc for drivers that use the crtc helpers for output mode + * filtering and detection. * * RETURNS: * Number of modes found on @connector. -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
Resurrecting an old thread...
> On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote:
> > From: Michel Dänzer
> > Date: Thu, 06 Sep 2012 18:55:51 +0200
> >
> >> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> >>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
> >>> Ultra 10 (clean, without my "Video RAM" hack that I talked in other
> >>> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
> >>> kernel, I compiled radeon drm driver with modesetting enabled and tried
> >>> it:
> >>>
> >>> [drm] radeon defaulting to kernel modesetting.
> >>> [drm] radeon kernel modesetting enabled.
> >>> PCI: Enabling device: (:02:02.0), cmd 82
> >>> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
> >>> [drm] register mmio base: 0x1000
> >>> [drm] register mmio size: 32768
> >>> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
> >>>
> >>> And here the machine hangs. Debugging printk-s reveal that it does not
> >>> find any active I/O port resources and then continues into initializing
> >>> the card. Down in igp_read_bios_from_vram() it successfully ioremaps
> >>> memory region 0 (vram_base=1ff0800 and size=4) and tries to read
> >>> 2 bytes from there and hangs on reading bios[0].
> >>
> >> Is the card initialized by OpenFirmware? E.g., does it display anything
> >> before the kernel boots?
> >
> > I think Meelis gave you every single detail you need to know to
> > analyze and fix this bug.
> >
> > He says it crashes on reading bios[0].
> >
> > If you look at the function he tells you the crash occurs in, you'll
> > see clearly that bios is an ioremap()'d pointer.
> >
> > You cannot dereference ioremap()'d pointers, you must use the proper
> > accessors such as readl().
>
> we should just skip the igp reading function on not-x86, since IGP on
> not x86 makes no sense.
>
> the other option is to readl out the whole bios from vram instead.
I made several changes.
1. In igp_read_bios_from_vram():
+#ifndef CONFIG_X86
+ /* IGP only exists on X86 (32- and 64-bit) */
+ return false;
+#endif
This gets me further.
2. Since "bios" is __iomem pointer, changed its dereferences to
readb(bios) and readb(bios+1). Maybe relevant, maybe not.
3. Next it got stuck in radeon_read_bios() trying to do
kmemdup(bios, size, GFP_KERNEL);
This I changed to mydup for test:
+static void *mydup(uint8_t __iomem *src, size_t len, gfp_t gfp)
+{
+ unsigned char *p;
+ int i;
+
+ p = kmalloc(len, gfp);
+ if (p) {
+ for (i=0; ihttp://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption
https://bugs.freedesktop.org/show_bug.cgi?id=69689 --- Comment #1 from Alex Deucher --- Make sure you set --enable-texture-float when configuring mesa. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #50 from Alex Deucher --- Go ahead and open new bugs for those issues. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #4 from Alex Deucher --- Can you try removing your xorg.conf? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
On Mon, Sep 23, 2013 at 3:42 AM, Christian König
wrote:
> From: Christian König
>
> Starting with UVD3 message and feedback buffers have their
> own 256MB segment, so no need to force them into VRAM any more.
>
> Signed-off-by: Christian König
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 3 ++-
> drivers/gpu/drm/radeon/radeon_uvd.c | 3 +--
> drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index ac6ece6..1806f4d 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -85,8 +85,9 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
> *p)
>VRAM, also but everything into VRAM on AGP cards to avoid
>image corruptions */
> if (p->ring == R600_RING_TYPE_UVD_INDEX &&
> + p->rdev->family < CHIP_PALM &&
> (i == 0 || p->rdev->flags & RADEON_IS_AGP)) {
> - /* TODO: is this still needed for NI+ ? */
> +
> p->relocs[i].lobj.domain =
> RADEON_GEM_DOMAIN_VRAM;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 1a01bbf..a0f1185 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -476,8 +476,7 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
> return -EINVAL;
> }
>
> - /* TODO: is this still necessary on NI+ ? */
> - if ((cmd == 0 || cmd == 0x3) &&
> + if (p->rdev->family < CHIP_PALM && (cmd == 0 || cmd == 0x3) &&
> (start >> 28) != (p->rdev->uvd.gpu_addr >> 28)) {
> DRM_ERROR("msg/fb buffer %LX-%LX out of 256MB segment!\n",
> start, end);
> diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
> b/drivers/gpu/drm/radeon/uvd_v1_0.c
> index 7266805..3100fa9 100644
> --- a/drivers/gpu/drm/radeon/uvd_v1_0.c
> +++ b/drivers/gpu/drm/radeon/uvd_v1_0.c
> @@ -212,8 +212,8 @@ int uvd_v1_0_start(struct radeon_device *rdev)
> /* enable VCPU clock */
> WREG32(UVD_VCPU_CNTL, 1 << 9);
>
> - /* enable UMC */
> - WREG32_P(UVD_LMI_CTRL2, 0, ~(1 << 8));
> + /* enable UMC and NC0 */
> + WREG32_P(UVD_LMI_CTRL2, 1 << 13, ~((1 << 8) | (1 << 13)));
>
> /* boot up the VCPU */
> WREG32(UVD_SOFT_RESET, 0);
> --
> 1.8.1.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Check the fb size against the correct CRTC viewport for stereo modes
I've sent this 2 patches separately from the main stereo series so we can have the usual rounds of review without having to resend the full 20+ patches. Once that last bit has been reviewed as well, I'll send a consolidated series that will be a serious candidate for merging. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon: Don't run tests when underlying memory was uninitialized
On Mon, Sep 23, 2013 at 7:59 AM, Alex Ivanov wrote:
> P.S.: don't run means don't allow to run, by either feeding radeon.test=X
> or radeon.benchmark=1
Good catch. I applied a slightly different variant of the same idea.
Thanks,
Alex
>
> 22.09.2013, в 5:18, Alex Ivanov написал(а):
>
>> 20.09.2013, в 22:33, Alex Deucher написал(а):
>>
>>> On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov wrote:
Prevent NULL pointer dereference in case when radeon_ring_fini() did it's
job.
Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead
to a KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed
(scratch(0x8504)=0xCAFEDEAD)" issue.
Signed-off-by: Alex Ivanov
>>>
>>> Applied. thanks!
>>>
>>> Alex
>>
>> One more. Thank you!
>>
>> Signed-off-by: Alex Ivanov
>> ---
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index e29faa7..e6d1897 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -1319,6 +1319,11 @@ int radeon_device_init(struct radeon_device *rdev,
>>if (r)
>>return r;
>>}
>> + /* If ring buffer or PCI GART got uninitialized, we should't run
>> tests */
>> + if (!rdev->accel_working) {
>> + DRM_INFO("radeon: acceleration disabled, skipping tests and
>> benchmark.\n");
>> + return 0;
>> + }
>>if ((radeon_testing & 1)) {
>>radeon_test_moves(rdev);
>>}
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
0001-drm-radeon-disable-tests-benchmarks-if-accel-is-disa.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
