Set vm_pgoff to 0 after using it to look up the GEM node, before passing
it on rockchip_gem_mmap_buf() where the offset must be from the start of
the buffer.
Passing in the fake offset currently works because the
dma_mmap_attrs implementation that is used for this device,
arm_iommu_mmap_attrs, ignores the offset completely.
Signed-off-by: Ørjan Eide <orjan.eide(a)arm.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/…
[View More]gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 7ca8799e..69f01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -94,6 +94,11 @@ int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
return -EACCES;
}
+ /* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
+ * whole buffer from the start.
+ */
+ vma->vm_pgoff = 0;
+
obj = container_of(node, struct drm_gem_object, vma_node);
ret = rockchip_gem_mmap_buf(obj, vma);
--
1.9.1
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=85580
Bug ID: 85580
Summary: [RadeonSI] Bad performance in TF2.
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: aaronbottegal(a)gmail.com
I built Mesa just a few days ago with LLVM …
[View More]3.5, git mesa, 3.18-rc2 kernel.
Performance is just horrible with tons of dips when playing TF2, and probably
other Valve games. Polygon count just makes it too heavy to what it used to be,
dipping down to 20FPS or so when moving objects and such. I don't have time to
bisect, don't even know how much longer I will be using this R9 270X, so any
tests I can do without a recompile I can try. Benchmarks like glmark2 are fine,
but in-game performance is just bad.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=75357
Priority: medium
Bug ID: 75357
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Barts (HD6850): Failure in evergreen_surface_check_2d
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: oogway.droid(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
…
[View More]Product: DRI
Created attachment 94554
--> https://bugs.freedesktop.org/attachment.cgi?id=94554&action=edit
dmesg radeon 6850
I'm running Fedora 20 with the latest distro kernel (3.13.3).
I'm running Gnome shell and see very frequent hangs.
Its usually observed when the system has been inactive for a while
and the monitor goes into powersave mode. When I try to activate the
system via keyboard/mouse I get a black screen. I cannot switch to a VT as
well.
SSH still works and the system is responsive via ssh. DPM is not enabled.
However I did switch the card to "low" power profile after boot.
echo "low" > /sys/class/drm/card0/device/power_profile
cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 775000 kHz
current engine clock: 99990 kHz
default memory clock: 1000000 kHz
current memory clock: 150000 kHz
voltage: 950 mV
PCIE lanes: 16
dmesg shows the following:
[ 8443.493242] radeon 0000:01:00.0: evergreen_surface_check_2d:277 texture
pitch 1920 invalid must be aligned with 512
[ 8443.493249] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:826
texture invalid 0x1dfc3bc1 0x40000437 0x060a0000 0x00000000 0x80000000
0x800304da
[ 8443.493251] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8455.699835] radeon 0000:01:00.0: evergreen_surface_check_2d:277 texture
pitch 1920 invalid must be aligned with 512
[ 8455.699841] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:826
texture invalid 0x1dfc3bc1 0x40000437 0x060a0000 0x00000000 0x80000000
0x800304da
[ 8455.699844] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8456.748217] radeon 0000:01:00.0: evergreen_surface_check_2d:277 texture
pitch 1920 invalid must be aligned with 512
[ 8456.748223] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:826
texture invalid 0x1dfc3bc1 0x40000437 0x060a0000 0x00000000 0x80000000
0x800304da
[ 8456.748226] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 8605.668059] radeon 0000:01:00.0: evergreen_surface_check_2d:277 texture
pitch 1920 invalid must be aligned with 512
[ 8605.668066] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:826
texture invalid 0x1dfc3bc1 0x40000437 0x060a0000 0x00000000 0x80000000
0x800304da
[ 8605.668068] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=93281
Bug ID: 93281
Summary: Kernel modesetting causes the kernel to lock up during
boot on a late 2011 MacBook Pro
Product: Drivers
Version: 2.5
Kernel Version: 3.18
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: …
[View More]drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: alex(a)strugee.net
Regression: No
Created attachment 166851
--> https://bugzilla.kernel.org/attachment.cgi?id=166851&action=edit
Upper half of the screen during hang
I'm the owner of a 15-inch late 2011 MacBook Pro. If I boot the system in the
default setup, it completely hangs shortly after starting the X server (at
least, AFAICT). If I boot with "nomodeset" appended to the kernel parameters,
then the system boots fine. This has happened for a long time now, so it's not
a recent regression or anything. I'm on Debian Unstable, with an untainted
kernel installed from experimental.
I will attach all relevant logs. All logs are from a boot with "nomodeset"
appended. I'll also attach photos of the logs that appear on the screen at the
time of the hang. These photos are from a slightly different kernel, but the
symptoms are the same.
I'm comfortable applying patches and building the kernel from source.
$ uname -a
Linux caught-sigsegv 3.18.0-trunk-amd64 #1 SMP Debian 3.18.6-1~exp1
(2015-02-07) x86_64 GNU/Linux
$ cat /proc/sys/kernel/tainted
0
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=82186
Priority: medium
Bug ID: 82186
Assignee: dri-devel(a)lists.freedesktop.org
Summary: BARTS GPU lockup with minecraft shaders
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: EoD(a)xmw.de
Hardware: Other
Status: NEW
Version: 10.2
Component: Drivers/Gallium/r600
Product: Mesa
Created …
[View More]attachment 104066
--> https://bugs.freedesktop.org/attachment.cgi?id=104066&action=edit
glxinfo
When I enable the shader modpack in minecraft my computer locks up: keyboard
does not react and screen has dark/light gray stripes.
You need to install forge and those two mods in order to reproduce the bug:
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/128…http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/128…
I tried it without DPM, without HyperZ and without both, but the lockup didn't
change.
I am using Gentoo:
- with kernel 3.14.14 and mesa 10.2.4, the screen started flickering (on/off,
on+black/on) and locked up eventually.
- with kernel 3.14.15 and mesa 10.2.5 it immediately locks up and leaves me
with gray stripes.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
Hi all,
After a few days of experimentation on multi-display support on i.MX6, I
have some questions regarding the status of the imx-drm driver.
Here is description of my testing setup:
- Nitrogen6x (a SabreLite would work the same)
- Mainline kernel 4.1-rc2 + a few patches for display support (some are
pending, other are scheduled for 4.2)
https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=132811https://patchwork.kernel.org/patch/6439221/https://patchwork.kernel.org/…
[View More]patch/6439231/https://patchwork.kernel.org/patch/6212451/
- Available displays:
- 1 LVDS 10" Hannstar HSD100PXN1 display
- 1 LCD 7" Okaya display
- 1 HDMI 1080p TV
- U-boot script used to boot the mainline kernel properly:
https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/…
- Basic Buildroot filesystem with libdrm and its test binaries
First of all, using the standard imx_v6_v7_defconfig, everything runs
fine with a single-display setup, no matter if it is using LVDS, RGB or
HDMI interface.
But in multi-display setup, the first observation is that
CONFIG_DRM_IMX_FB_HELPER seems to be problematic. When this option is
set, only one display can be used either using the /dev/fb0 or 'modetest
-s' from libdrm test binaries. As soon as the option is removed, every
display can be used properly with the following commands:
# modetest -M imx-drm -s 32:800x480
# modetest -M imx-drm -s 34:1920x1080
# modetest -M imx-drm -s 36:1024x768
Is this option only meant for single-display setup? Has it been tested
in multi-display?
It seems limited to fb0 creation, would it be possible to make the
driver create as many fbs as the number of monitors?
Also, when trying to display different patterns on each and every
display at once, I have been using the example provided by David
Herrmann:
https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c
This shows a clocking issue when using both DRM_IMX_PARALLEL_DISPLAY and
DRM_IMX_LDB at the same time. Although the driver is smart enough to
connect ipu1_di0 to the RGB interface and ipu1_di1 to the LVDS
interface, the clock set by the LDB driver (65MHz) is overwritten when
the parallel interface is enabled as they both share pll5_video.
Has anyone successfully tried using both drivers, LVDS and parallel, at
the same time?
Then I've run into Steve's series that seems to address some clocking
issues.
http://lists.freedesktop.org/archives/dri-devel/2014-October/070996.html
Is there the equivalent series for the driver since it has moved from
staging?
Hope the above description is sufficient, if needed I can provide
modeprint/modetest/clk_summary outputs.
Regards,
Gary
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=90510
Bug ID: 90510
Summary: [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming
seems broken
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: …
[View More]sylvain.bertrand(a)gmail.com
QA Contact: dri-devel(a)lists.freedesktop.org
This is a follow-up of the bug #90370.
source engine games produce tons of graphical glitches, unless
R600_DEBUG='switch_on_eop' is defined.
Tested with dota2/portal2. For portal2, the amount of glitches depends on
the level you choose.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=90537
Bug ID: 90537
Summary: radeonsi bo/va conflict on RADEON_GEM_VA
(rscreen->ws->buffer_from_handle returns NULL)
Product: Mesa
Version: 10.5
Hardware: x86 (IA32)
OS: other
Status: NEW
Severity: trivial
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel(a)lists.freedesktop.org
…
[View More] Reporter: pstglia(a)gmail.com
QA Contact: dri-devel(a)lists.freedesktop.org
Created attachment 115927
--> https://bugs.freedesktop.org/attachment.cgi?id=115927&action=edit
dmesg output (drm.debug=7)
Hi, we're trying to make radeonsi work on Android-x86 (porting of AOSP to x86
architecture).
We can have graphical output, but at some circunstances (certain apps, like
Antutu Benchmark) we are receiving a "radeon bo/va conflict with bo/va" from
kernel. When this happens, graphical components crashes.
As I could check, This error occurs on "r600_texture_from_handle" (which is
being called on native_android.cpp gallium state tracker;
screen->resource_from_handle - use_drm is set )
When calling "rscreen->ws->buffer_from_handle" NULL is being returned. From
kernel dmesg (drm.debug = 7), we get this ioctl error:
...
<7>[ 244.847256] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[ 244.847269] [drm:drm_ioctl] pid=3469, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[ 244.848972] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
RADEON_GEM_CREATE
<7>[ 244.849030] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<7>[ 244.849084] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_MMAP
<7>[ 244.849150] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
RADEON_GEM_CREATE
<7>[ 244.849177] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0, RADEON_GEM_VA
<3>[ 244.849191] radeon 0000:00:01.0: bo ccf78800 va 0x0000000858 conflict
with (bo cec3a000 0x0000000869 0x000000086a)
<7>[ 244.849199] [drm:drm_ioctl] ret = -22
<7>[ 244.849251] [drm:drm_ioctl] pid=4171, dev=0xe200, auth=0,
DRM_IOCTL_GEM_CLOSE
<7>[ 244.853770] [drm:drm_release] open_count = 5
<7>[ 244.853782] [drm:drm_release] pid = 3464, device = 0xe200, open_count = 5
...
I suppose this "buffer_from_handle" in this case is mapped with
"radeon_winsys_bo_from_handle" function. If this assumption is correct, the
error is occuring during this call:
va.handle = bo->handle;
va.operation = RADEON_VA_MAP;
va.vm_id = 0;
va.offset = bo->va;
va.flags = RADEON_VM_PAGE_READABLE |
RADEON_VM_PAGE_WRITEABLE |
RADEON_VM_PAGE_SNOOPED;
va.offset = bo->va;
r = drmCommandWriteRead(ws->fd, DRM_RADEON_GEM_VA, &va, sizeof(va));
if (r && va.operation == RADEON_VA_RESULT_ERROR) {
fprintf(stderr, "radeon: Failed to assign virtual address
space\n");
radeon_bo_destroy(&bo->base);
return NULL;
I tried using kernel 4.0.3 (which contains some kernel patches apparently
related to this):
drm/radeon: fix lockup when BOs aren't part of the VM on release
drm/radeon: reset BOs address after clearing it.
drm/radeon: check new address before removing old one
But the same error happens.
I'd like some help in order to find out what's wrong (bug on Mesa/drm or wrong
config at Android side):
- I'm building for a 32 bits environment. Does this can cause the problem I
described? Maybe the driver/drm/mesa works better on a 64 bits environment?
- For graphical buffer management (alloc, map, unmap, etc) we have drm_gralloc,
which is based on xf86-video-ati. If possible, can you take a quick look an see
if there's something that needs to changed in particullar for
radeonsi?(gralloc_drm_radeon.c on
http://git.android-x86.org/?p=platform/hardware/drm_gralloc.git;a=tree;h=re…)
Any help is appreciated. Thank you!
pstglia
ps: It's working nice with r600g driver/hardware
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]