Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 12:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie airl...@linux.ie wrote: i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, Hmm. The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the Xorg.0.log nor the dmesg contained anything interesting. I was about to try to bisect it, but decided to see how repeatable it was, and it didn't happen again. But it also hasn't ever happened before, so I'm a bit worried. This is with the DP cable, which has made my other Haswell issues go away. I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Linus, Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. I am running that on my MacBook Air 2013 and HSW based Asus quad core i7 desktop. A quick way to exercise the decoders once you install libva/intel-driver is to use VLC enabling GPU acceleration in preferences. Sean Because my shiny new 65W haswell is really nice and does a make allmodconfig in half the time of my old machine, but the GPU side has been something of a step backwards... Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean V. Kelley sean.v.kel...@intel.com Open Source Technology Center / SSG Intel Corp. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: do not move buffers when not needed
On Wed, Sep 4, 2013 at 11:25 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 04-09-13 03:24, Ben Skeggs schreef:
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec
clock to
get real-time 1080p decoding. It prevents a lot of VRAM - VRAM buffer
moves.
It's not bogus, and is required for pre-GF8 boards with VRAM BAR size.
What configuration does the buffer that's getting moved here have
exactly? The placement restriction isn't necessary on GF8, the rest
of the restrictions may currently be required still however.
= vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo.
This is ok because
the vm hides all the tiling translations, and the engines will read the raw
bitstream correctly.
Why would you be doing such a thing in the first place? It seems
pointless, and quite possibly counter-productive to use a tiled layout
for a linear data structure...
Initially I just allocated everything I didn't need to access directly tiled,
and it seems I did the same for
the bitstream bo. I only found out later about the bug with excessive moves
causing a major slowdown.
8---
This prevents buffer moves from being done on NV50+, where remapping is not
needed because
the bar has its own VM, instead of only having the first BAR1-size chunk of
VRAM accessible.
nouveau_bo_tile_layout is always 0 on NV_50.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index d506da5..762bfcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
struct nouveau_device *device = nv_device(drm-device);
u32 mappable = pci_resource_len(device-pdev, 1) PAGE_SHIFT;
- /* as long as the bo isn't in vram, and isn't tiled, we've got
-* nothing to do here.
+ /*
+* if the bo is not in vram, or remapping can be done (nv50+)
+* do not worry about placement, any location is valid
*/
- if (bo-mem.mem_type != TTM_PL_VRAM) {
- if (nv_device(drm-device)-card_type NV_50 ||
- !nouveau_bo_tile_layout(nvbo))
- return 0;
- }
+ if (nv_device(drm-device)-card_type = NV_50 ||
+ bo-mem.mem_type != TTM_PL_VRAM)
+ return 0;
I get what you're trying to do here, and we should definitely avoid
the mappable vram check on GF8, but I suspect this condition is too
broad. I'll think about it more after I finish reviewing the rest of
the patches on the list..
I think this relaxed check is fine. If it's !VRAM, the host can always access
it because it has direct access to the
pages without needing anything from the gpu. On = NV50 the move can always
be skipped too because the
memory is mapped to the vm, and always accessible.
Yeah, I think the check is sane, after thinking it through. We shall
find out :)
But first, if you're going to not move tiled system memory to vram
first, you're going to need to deal with mapping it into bar1 so the
vm deals with some of the reordering. See what's done in
io_mem_reserve() for TTM_PL_VRAM.
Ben.
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 6 September 2013 19:21, Sean Paul seanp...@chromium.org wrote:
On Thu, Sep 5, 2013 at 11:37 PM, Rahul Sharma r.sh.o...@gmail.com wrote:
On 5 September 2013 19:20, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided
by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch
Re: drm/radeon: ring test failed on PA-RISC Linux
Alex,
09.09.2013, в 21:43, Alex Deucher alexdeuc...@gmail.com написал(а):
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
native video options of the latest PA-RISC servers and workstations
(these are ATIs, most of which are based on R100/R300/R420 chips) work
correctly on this platform (big endian pa-risc).
However, we hadn't much success. DRM fails every time with
ring test failed for both AGP PCI.
Maybe you would give us some suggestions that we could check?
Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html
Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds
our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside
of the connected LBA
Things planned for a check:
The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether
this makes a difference and how it is connected to the overall picture.
I don't think that will any difference. radeon kms works fine on
other big endian platforms such as powerpc.
Good! I'll opt it out then.
The Rage128 product revealed a weakness in some motherboard
chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable
state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this
problem, weve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer
for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to
memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
In the radeon DRM codebase I didn't found anyone using/setting
those registers. Maybe PA-RISC has some problem here?...
I doubt it. If you are using AGP, I'd suggest disabling it and first
try to get things working using the on chip gart rather than AGP.
Load radeon with agpmode=-1.
Already tried this without any luck. Anyway, a radeon driver fallbacks
to the PCI mode in our case, so does it really matter?
In addition, people with PCI cards experiencing the same issue...
The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent.
On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
system ram. On PCIE asics, the gart table is stored in vram. The
gart page table maps system pages to a contiguous aperture in the
GPU's address space. The ring lives in gart memory. The GPU sees a
contiguous buffer and the gart mechanism handles the access to the
backing pages via the page table. I'd suggest verifying that the
entries written to the gart page table are valid and then the
information written to the ring buffer is valid before updating the
ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
causes the CP to start fetching data from the ring.
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
--- radeon_device.c.orig2013-09-10 08:55:05.0 +
+++ radeon_device.c 2013-09-10 09:12:17.0 +
@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
{
if (rdev-dummy_page.page)
return 0;
- rdev-dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
- if (rdev-dummy_page.page == NULL)
+ rdev-dummy_page.page = dma_alloc_coherent(rdev-pdev-dev, PAGE_SIZE,
+ rdev-dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+ if (!rdev-dummy_page.page)
return -ENOMEM;
- rdev-dummy_page.addr = pci_map_page(rdev-pdev, rdev-dummy_page.page,
- 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(rdev-pdev, rdev-dummy_page.addr)) {
dev_err(rdev-pdev-dev, Failed to DMA MAP the dummy page\n);
- __free_page(rdev-dummy_page.page);
- rdev-dummy_page.page = NULL;
+ radeon_dummy_page_fini(rdev);
return -ENOMEM;
}
return 0;
@@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
{
if (rdev-dummy_page.page == NULL)
return;
- pci_unmap_page(rdev-pdev, rdev-dummy_page.addr,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- __free_page(rdev-dummy_page.page);
+
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
Op 04-09-13 05:41, Ben Skeggs schreef:
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 22-08-13 02:10, Ilia Mirkin schreef:
The code expects non-VRAM mem nodes to have a pages list. If that's not
set, it will do a null deref down the line. Warn on that condition and
return an error.
See https://bugs.freedesktop.org/show_bug.cgi?id=64774
Reported-by: Pasi Kärkkäinen pa...@iki.fi
Tested-by: Pasi Kärkkäinen pa...@iki.fi
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: sta...@vger.kernel.org # 3.8+
---
I don't exactly understand what's going on, but this is just a
straightforward way to avoid a null deref that you see happens in the
bug. I haven't figured out the root cause of this, but it's getting
well into the I have no idea how TTM works space. However this seems
like a bit of defensive programming -- nouveau_vm_map_sg will pass
node-pages as a list down, which will be dereferenced by
nvc0_vm_map_sg. Perhaps the other arguments should make that
dereferencing not happen, but it definitely was happening here, as you
can see in the bug.
Ben/Maarten, I'll let you judge whether this check is appropriate,
since like I hope I was able to convey above, I'm just not really sure :)
Not it really isn't appropriate..
You'd have to call call nouveau_vm_map_sg_table instead, the only place
that doesn't handle that correctly
is where it's not expected to be called.
Here, have a completely untested patch to fix things...
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device
*dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd-handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouveau_gem_object(gem);
+ if (!(nvbo-valid_domains NOUVEAU_GEM_DOMAIN_VRAM)) {
+ nv_warn(nouveau_drm(dev), Trying to create a fb in vram
with
+valid_domains=%08x\n, nvbo-valid_domains);
+ ret = -EINVAL;
+ goto err_unref;
+ }
+
Definitely the right idea, we can't handle this case right now.
However, we may someday want/need to be able to scan out of system
memory, so this is the wrong place.
I suspect the correct thing to do (which'll also handle the
defensive part) is to bail in nouveau_bo_move() on attempts to move
a DMA-BUF backed object into VRAM.
Sound OK?
If it has a WARN_ON or something that would be ok, I didn't find any other
places that attempt to move buffers to VRAM though, so it's probably harmless.
So hmm.. I guess another patch is needed for the original issue in this thread.
Is someone going to submit that?
When looking into this bug I noticed that nouveau_bo_vma_add needs to have a
check for nvbo-page_shift == vma-vm-vmm-spg_shift,
and only if the check is true it should map the page in TTM_PL_TT. Patch
below.
Should probably also be cc'd to stable.
Thanks! Is this patch ready to be merged?
-- Pasi
~Maarten
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 89b992e..355a1b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
if (nvbo-bo.mem.mem_type == TTM_PL_VRAM)
nouveau_vm_map(vma, nvbo-bo.mem.mm_node);
- else if (nvbo-bo.mem.mem_type == TTM_PL_TT) {
+ else if (nvbo-bo.mem.mem_type == TTM_PL_TT
+ nvbo-page_shift == vma-vm-vmm-spg_shift) {
if (node-sg)
nouveau_vm_map_sg_table(vma, 0, size, node);
else
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 Johannes Obermayr johannesoberm...@gmx.de changed: What|Removed |Added Attachment #84756|0 |1 is obsolete|| Attachment #84840|0 |1 is obsolete|| --- Comment #19 from Johannes Obermayr johannesoberm...@gmx.de --- Created attachment 85550 -- https://bugs.freedesktop.org/attachment.cgi?id=85550action=edit link libradeon only once Please try this patch. libradeon will be linked in egl_gallium.so only once. -- 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/radeon: ring test failed on PA-RISC Linux
On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Alex,
09.09.2013, в 21:43, Alex Deucher alexdeuc...@gmail.com написал(а):
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
native video options of the latest PA-RISC servers and workstations
(these are ATIs, most of which are based on R100/R300/R420 chips) work
correctly on this platform (big endian pa-risc).
However, we hadn't much success. DRM fails every time with
ring test failed for both AGP PCI.
Maybe you would give us some suggestions that we could check?
Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html
Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds
our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside
of the connected LBA
Things planned for a check:
The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether
this makes a difference and how it is connected to the overall picture.
I don't think that will any difference. radeon kms works fine on
other big endian platforms such as powerpc.
Good! I'll opt it out then.
The Rage128 product revealed a weakness in some motherboard
chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable
state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this
problem, weve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer
for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to
memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
In the radeon DRM codebase I didn't found anyone using/setting
those registers. Maybe PA-RISC has some problem here?...
I doubt it. If you are using AGP, I'd suggest disabling it and first
try to get things working using the on chip gart rather than AGP.
Load radeon with agpmode=-1.
Already tried this without any luck. Anyway, a radeon driver fallbacks
to the PCI mode in our case, so does it really matter?
In addition, people with PCI cards experiencing the same issue...
The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent.
On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
system ram. On PCIE asics, the gart table is stored in vram. The
gart page table maps system pages to a contiguous aperture in the
GPU's address space. The ring lives in gart memory. The GPU sees a
contiguous buffer and the gart mechanism handles the access to the
backing pages via the page table. I'd suggest verifying that the
entries written to the gart page table are valid and then the
information written to the ring buffer is valid before updating the
ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
causes the CP to start fetching data from the ring.
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
The dummy page isn't really going to help much. That page is just
used as a safety placeholder for gart entries that aren't mapped on
the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of
the backing pages for the gart. You may want to look there.
Alex
--- radeon_device.c.orig2013-09-10 08:55:05.0 +
+++ radeon_device.c 2013-09-10 09:12:17.0 +
@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
{
if (rdev-dummy_page.page)
return 0;
- rdev-dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL |
__GFP_ZERO);
- if (rdev-dummy_page.page == NULL)
+ rdev-dummy_page.page = dma_alloc_coherent(rdev-pdev-dev,
PAGE_SIZE,
+ rdev-dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+ if (!rdev-dummy_page.page)
return -ENOMEM;
- rdev-dummy_page.addr = pci_map_page(rdev-pdev,
rdev-dummy_page.page,
- 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(rdev-pdev, rdev-dummy_page.addr)) {
dev_err(rdev-pdev-dev, Failed to DMA MAP the dummy
page\n);
- __free_page(rdev-dummy_page.page);
- rdev-dummy_page.page = NULL;
+ radeon_dummy_page_fini(rdev);
Re: drm/radeon: ring test failed on PA-RISC Linux
On 09/10/2013 02:37 PM, Alex Deucher wrote:
On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Alex,
09.09.2013, в 21:43, Alex Deucher alexdeuc...@gmail.com написал(а):
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
native video options of the latest PA-RISC servers and workstations
(these are ATIs, most of which are based on R100/R300/R420 chips) work
correctly on this platform (big endian pa-risc).
However, we hadn't much success. DRM fails every time with
ring test failed for both AGP PCI.
Maybe you would give us some suggestions that we could check?
Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html
Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds
our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside
of the connected LBA
Things planned for a check:
The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether
this makes a difference and how it is connected to the overall picture.
I don't think that will any difference. radeon kms works fine on
other big endian platforms such as powerpc.
Good! I'll opt it out then.
Actually, I am experiencing exactly the same problem on a Sam460ex ppc
system, at least as of 3.9 (the last time I tried it).
Very rarely the ringtest would pass, but then it would fail somewhere else.
I never could figure it out since as far as I could tell all the addresses
and logic was correct. It wasn't important enough for me to work more on it,
but I'd be happy to test code. I'm travelling for the next week and a half,
so I can't do anything right now.
One bug I found when working on drm/kms support for the ppc was that in
struct ttm_bus_placement the base address type was wrong: it should be
phys_addr_t, not unsigned long. The PPC460 is in 32-bit mode but physical
addresses are 32 bits.
The patch below fixes that. I always wanted to post this fix, but never got
around to it...
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/powerpc/sysdev/ppc4xx_msi.c |6 +++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
include/drm/ttm/ttm_bo_api.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b0659..fa33568 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1066,7 +1066,7 @@ int radeon_device_init(struct radeon_device *rdev,
if (rdev-rmmio == NULL) {
return -ENOMEM;
}
- DRM_INFO(register mmio base: 0x%08X\n, (uint32_t)rdev-rmmio_base);
+ DRM_INFO(register mmio base: 0x%llx\n, (uint64_t)rdev-rmmio_base);
DRM_INFO(register mmio size: %u\n, (unsigned)rdev-rmmio_size);
/* io port mapping */
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3cb5d84..fcdb208 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -81,7 +81,7 @@ struct ttm_placement {
*/
struct ttm_bus_placement {
void*addr;
- unsigned long base;
+ phys_addr_t base;
unsigned long size;
unsigned long offset;
boolis_iomem;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: ring test failed on PA-RISC Linux
On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
Alex,
09.09.2013, в 21:43, Alex Deucher alexdeuc...@gmail.com написал(а):
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
native video options of the latest PA-RISC servers and workstations
(these are ATIs, most of which are based on R100/R300/R420 chips) work
correctly on this platform (big endian pa-risc).
However, we hadn't much success. DRM fails every time with
ring test failed for both AGP PCI.
Maybe you would give us some suggestions that we could check?
Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html
Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds
our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside
of the connected LBA
Things planned for a check:
The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether
this makes a difference and how it is connected to the overall picture.
I don't think that will any difference. radeon kms works fine on
other big endian platforms such as powerpc.
Good! I'll opt it out then.
The Rage128 product revealed a weakness in some motherboard
chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable
state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this
problem, weve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer
for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to
memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
In the radeon DRM codebase I didn't found anyone using/setting
those registers. Maybe PA-RISC has some problem here?...
I doubt it. If you are using AGP, I'd suggest disabling it and first
try to get things working using the on chip gart rather than AGP.
Load radeon with agpmode=-1.
Already tried this without any luck. Anyway, a radeon driver fallbacks
to the PCI mode in our case, so does it really matter?
In addition, people with PCI cards experiencing the same issue...
The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent.
On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
system ram. On PCIE asics, the gart table is stored in vram. The
gart page table maps system pages to a contiguous aperture in the
GPU's address space. The ring lives in gart memory. The GPU sees a
contiguous buffer and the gart mechanism handles the access to the
backing pages via the page table. I'd suggest verifying that the
entries written to the gart page table are valid and then the
information written to the ring buffer is valid before updating the
ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what
causes the CP to start fetching data from the ring.
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
Is this platform enabling the SWIOTLB layer? The reason I am asking is
b/c if you do indeed enable it you end up using the TTM DMA pool
which allocates pages using the dma_alloc_coherent - which means that
all of the pages that come out of TTM are already 'DMA' mapped.
And that means the radeon_gart_bind and all its friends
use the DMA addresses that have been constructed by SWIOTLB IOMMU.
Perhaps the PA-RISC IOMMU creates the DMA addresses differently?
When the card gets programmed, you do end up using ttm_agp_bind right?
I am wondering if something like this:
https://lkml.org/lkml/2010/12/6/512
is needed to pass in the right DMA address?
--- radeon_device.c.orig 2013-09-10 08:55:05.0 +
+++ radeon_device.c 2013-09-10 09:12:17.0 +
@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
{
if (rdev-dummy_page.page)
return 0;
- rdev-dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
- if (rdev-dummy_page.page == NULL)
+ rdev-dummy_page.page = dma_alloc_coherent(rdev-pdev-dev, PAGE_SIZE,
+ rdev-dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+ if (!rdev-dummy_page.page)
return -ENOMEM;
-
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #10 from Alex Deucher ag...@yahoo.com --- Created attachment 85563 -- https://bugs.freedesktop.org/attachment.cgi?id=85563action=edit possible fix The attached patch should fix the issue. -- 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 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, 09 Sep 2013, Rafael J. Wysocki r...@sisk.pl wrote: On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: Hi, On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: Hi Aaaron, Have we grown any clue meanwhile about which Intel boxes need this and for which we still need to keep the acpi backlight around? First of all, there is a bunch of boxes where ACPI backlight works incorrectly because of the Win8 compatibility issue. [In short, if we say we are compatible with Win8, the backlight AML goes into a special code path that is broken on those machines. Presumably Win8 uses native backlight control on them and that AML code path is never executed there.] The collection of machines with this problem appears to be kind of random (various models from various vendors), but I *think* they are machines that originally shipped with Win7 with a Win8 upgrade option (which in practice requires the BIOS to be updated anyway). Because of that, last time we tried to switch all of the systems using i915 and telling the BIOS that they are compatible with Win8 over to native backlight control, but that didn't work for two reasons. The first reason is that some user space doesn't know how to use intel_backlight and needs to be taught about that (so some systems are just not ready for that switch). The second and more fundamental reason is that the native backlight control simply doesn't work on some machines and we don't seem to have any idea why and how to debug this particular problem (mostly because we don't have enough information and we don't know what to ask for). I've grown _very_ reluctant to just adding tons of quirks to our driver for the backlight. Almost all the quirks we have added recently (or that have been proposed to be added) are for the backlight. Imo that indicates we get something fundamentally wrong ... This thing isn't really a quirk. It rather is an option for the users of the systems where ACPI backlight doesn't work to switch over to the native backlight control using a command line switch. This way they can at least *see* if the native backlight control works for them and (hopefully) report problems if that's not the case. This gives us a chance to get more information about what the problem is and possibly to make some progress without making changes for everyone, reverting those changes when they don't work etc. An alternative for them is to pass acpi_osi=!Windows 2012 which will probably make the ACPI backlight work for them again, but this rather is a step back, because we can't possibly learn anything new from that. If Win8 is as broken as we are I'm ok with the module option. It just sounded to me like right now we don't know of a way to make all machines somewhat happy, combined with the other pile of random backlight issues the assumption that we do something (maybe something a bit racy) that windows doesn't do isn't too far-fetched. So I'm not wary of the machines where the aml is busted for acpi_os=win8, but for the others where this broke stuff. Or do I miss something here? The ACPI video driver doesn't do anything new now. It only does things that did work before we started to tell BIOSes we're compatible with Win8. The reason why they don't work on some machines now is not related to whether or not Win8 is broken, but to what is there in the ACPI tables on those machines. That *is* pure garbage, but Win8 users don't see that (presumably, because Win8 does't execute the AML in question). We don't see that either with acpi_osi=!Windows 2012 (because then we don't execute that AML either). Whether or not Win8 is broken doesn't matter here. What matters is that we have to deal with broken AML somehow. One way may be to tell everyone affected by this to pass acpi_osi=!Windows 2012 in the kernel command line or possibly create a blacklist of those machines in the kernel (which Felipe has been pushing for recently) and wash our hands clean of this, but that leaves some exceptionally bad taste in my mouth. The alternative is to try to use native backlight in i915, which we did, but that didn't work on some machines. I don't think we will know why it didn't work there before we collect some more information and that's not possible without user testing. So, the idea is to make that testing possible without hacking the kernel and that's why we're introducing the new command line switch. And we're going to ask users to try it and report back. The thing that slightly bugs me with the proposed patches is that they're adding a module parameter to i915 to tell ACPI video driver whether to quirk the backlight or not. Before you know, we *will* have requests to add quirks to i915 to tell ACPI video
Re: Stereo 3D v3
On Sun, Sep 08, 2013 at 04:03:52PM +0100, Damien Lespiau wrote: On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote: The series implements SET_CAP as a per _file_ capability set, not per master. I like it this way. Note that with SET_VERSION, we already have a per _master_ capability set. Compared to SET_CAP it only allows incremental capability changes, but that's fine I think. However, the problem with per-master capabilities (SET_VERSION) is that we currently have no way to control which master a graphics-server gets assigned to. If it's started in background, it will get the same master as the foreground compositor. Therefore, we don't want per-master client-capabilities. It's wrong and breaks existing setups (same as SET_VERSION, and everyone knows that). I also don't see a reason to bind capabilities to a master object. SET_CAP describes what the *calling client* understands and can work with. And this is logically bound to drm_file (as it represents a client). On the other hand, GET_CAP describes what the *device* understands and provides. This is obviously bound to a drm_device. A drm_master object allows to split GET_CAP capabilities and resources across multiple logical master objects. But these resemble a drm_device much more than a drm_file. So no, this capability is not dropped with a change in master. It's independent of the active/bound master. It just describes what a client sees or not sees. Right, that sums it up. Note that while I've made stereo_allowed a per fd thing (which is what I wanted in that case, alter the reality viewed by the process opening the file), SET_CAP itself it marked as master only. This can be changed in the future to provide per-cap access restrictions if needed. This could be renamed to SET_CLIENT_CAP and also drop the master requirement. (That some capabilities only affect master ioctls is irrelevant I think, as the client will be master at that time.) That would reduce the confusion between the device caps and the session caps. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 10 Sep 2013, Matthew Garrett matthew.garr...@nebula.com wrote: On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote: I think the parameter Does the ACPI backlight interface work or not belongs to the ACPI video driver. That depends on how Windows 8 works. If Windows 8 policy is handled by the GPU drivers then it belongs in i915. If it's handled by the ACPI code then it belongs in the ACPI code. I fail to see the logic. Windows 8 policy dictates whether we can use the AML code or not. IMHO, ACPI code is in the best position to figure this out and quirk as necessary. It's the part that knows about Windows 8, not i915. But I have no way of determining that, whereas you work for a company that produces a Windows 8 video driver… Here I do see the logic. However see signature; I'm not in the best of positions to figure out things about Windows 8 video drivers. ;) But I'll see what I can do. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added Attachment #107911|0 |1 is obsolete|| --- Comment #29 from Alex Deucher alexdeuc...@gmail.com --- Created attachment 108011 -- https://bugzilla.kernel.org/attachment.cgi?id=108011action=edit possible fix Sorry, I had the wrong chip check in the last version. This patch should be correct. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #11 from John john.etted...@gmail.com --- Hi Alex, Thanks for the quick turn around. Looking at the patch it seems to be for RV770 and RV780 will it still work for our older cards? I am not home right now so I cannot test it to get the answer. -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #12 from Alex Deucher ag...@yahoo.com --- (In reply to comment #11) Hi Alex, Thanks for the quick turn around. Looking at the patch it seems to be for RV770 and RV780 will it still work for our older cards? Yes. It covers the entire 7xx family of cards. -- 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 #14 from Alex Deucher ag...@yahoo.com --- Created attachment 85578 -- https://bugs.freedesktop.org/attachment.cgi?id=85578action=edit disable various dpm features I would suggest disabling various dpm features and see if you can narrow down which, if any, help. This patch disables just about everything. ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what actually sets the dynamic performance switching into motion. Prior to that the hw is locked into the low performance level. I sounds like there is some bad parameter that is causing a lock up when the smc enables state switching. Separate from the patch can you also try changing the ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a lock up. -- 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 #15 from Alex Deucher ag...@yahoo.com --- Another thing worth checking, what is the value of module_index passed to radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c on your system? -- 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 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 Erdem U. Altınyurt spamjunkea...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #47 from Erdem U. Altınyurt spamjunkea...@gmail.com --- Hi Aaron, Well, without the patch, I can verify that bfgminer started to work on my HD6850, using mesa/llvm/libclc trunk. Thanks. -- 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 64225] bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 --- Comment #5 from Erdem U. Altınyurt spamjunkea...@gmail.com --- Since bfgminer --benchmark --scrypt command produces the error message of: Cannot use benchmark mode with scrypt I cannot report if scrypt is start to work or not. -- 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 69196] New: gpu lockup and full crash when starting some games in wine
https://bugs.freedesktop.org/show_bug.cgi?id=69196 Priority: medium Bug ID: 69196 Assignee: dri-devel@lists.freedesktop.org Summary: gpu lockup and full crash when starting some games in wine Severity: normal Classification: Unclassified OS: Linux (All) Reporter: maxmust...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 85587 -- https://bugs.freedesktop.org/attachment.cgi?id=85587action=edit kernel log from the crash First of I searched the bugs and found some similar looking bugs but none which stroke me as the same bug. lspci tells me my graphics card is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770 GHz Edition] I always use everything mesa and kernel vanilla from git. My kernel has the version 3.11.0-1-08716-g26b0332-dirty.The mesa checkout is 4 days old. glxinfo tells me Mesa 9.3.0-devel (git-0f6fce1) (if this is relevant) I tested it with hyperz enabled and disabled both time it failed the same way. First the display turns dark (no signal) and then after being responsive for a few seconds the pc crashes completly. If I kill the process in time it doesn't die completly on me. I don't know if this is of any relevance but the firmware for the card was missing and I grabbed the file from here: http://people.freedesktop.org/~agd5f/radeon_ucode/VERDE_smc.bin I'll refrain from parsin anything specific from the kernel log since I don't know which lines are relevant -- 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: [git pull] drm tree for 3.12-rc1
[ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley sean.v.kel...@intel.com wrote: I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Non-HD content seems to be fine even full-screen. Either just because it's so much easier to do, or because some level of scaling is hw-accelerated. It may well be that I'm using chrome (and chrome seems to tend to use its own library versions), and firefox indeed seems to be a bit better. But by a bit better I mean closer to full frame rate in full-screen, but lots of tearing - and it was stil using 70% CPU when displaying in a window. So I think firefox is also still doing everything in software but may be better about using threads for it. My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tuesday, September 10, 2013 04:53:40 PM Jani Nikula wrote: On Mon, 09 Sep 2013, Rafael J. Wysocki r...@sisk.pl wrote: On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: Hi, On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: Hi Aaaron, Have we grown any clue meanwhile about which Intel boxes need this and for which we still need to keep the acpi backlight around? First of all, there is a bunch of boxes where ACPI backlight works incorrectly because of the Win8 compatibility issue. [In short, if we say we are compatible with Win8, the backlight AML goes into a special code path that is broken on those machines. Presumably Win8 uses native backlight control on them and that AML code path is never executed there.] The collection of machines with this problem appears to be kind of random (various models from various vendors), but I *think* they are machines that originally shipped with Win7 with a Win8 upgrade option (which in practice requires the BIOS to be updated anyway). Because of that, last time we tried to switch all of the systems using i915 and telling the BIOS that they are compatible with Win8 over to native backlight control, but that didn't work for two reasons. The first reason is that some user space doesn't know how to use intel_backlight and needs to be taught about that (so some systems are just not ready for that switch). The second and more fundamental reason is that the native backlight control simply doesn't work on some machines and we don't seem to have any idea why and how to debug this particular problem (mostly because we don't have enough information and we don't know what to ask for). I've grown _very_ reluctant to just adding tons of quirks to our driver for the backlight. Almost all the quirks we have added recently (or that have been proposed to be added) are for the backlight. Imo that indicates we get something fundamentally wrong ... This thing isn't really a quirk. It rather is an option for the users of the systems where ACPI backlight doesn't work to switch over to the native backlight control using a command line switch. This way they can at least *see* if the native backlight control works for them and (hopefully) report problems if that's not the case. This gives us a chance to get more information about what the problem is and possibly to make some progress without making changes for everyone, reverting those changes when they don't work etc. An alternative for them is to pass acpi_osi=!Windows 2012 which will probably make the ACPI backlight work for them again, but this rather is a step back, because we can't possibly learn anything new from that. If Win8 is as broken as we are I'm ok with the module option. It just sounded to me like right now we don't know of a way to make all machines somewhat happy, combined with the other pile of random backlight issues the assumption that we do something (maybe something a bit racy) that windows doesn't do isn't too far-fetched. So I'm not wary of the machines where the aml is busted for acpi_os=win8, but for the others where this broke stuff. Or do I miss something here? The ACPI video driver doesn't do anything new now. It only does things that did work before we started to tell BIOSes we're compatible with Win8. The reason why they don't work on some machines now is not related to whether or not Win8 is broken, but to what is there in the ACPI tables on those machines. That *is* pure garbage, but Win8 users don't see that (presumably, because Win8 does't execute the AML in question). We don't see that either with acpi_osi=!Windows 2012 (because then we don't execute that AML either). Whether or not Win8 is broken doesn't matter here. What matters is that we have to deal with broken AML somehow. One way may be to tell everyone affected by this to pass acpi_osi=!Windows 2012 in the kernel command line or possibly create a blacklist of those machines in the kernel (which Felipe has been pushing for recently) and wash our hands clean of this, but that leaves some exceptionally bad taste in my mouth. The alternative is to try to use native backlight in i915, which we did, but that didn't work on some machines. I don't think we will know why it didn't work there before we collect some more information and that's not possible without user testing. So, the idea is to make that testing possible without hacking the kernel and that's why we're introducing the new command line switch. And we're going to ask users to try it and report back. The thing that slightly bugs me with the proposed patches
[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 #18 from Alex Deucher ag...@yahoo.com --- (In reply to comment #17) (In reply to comment #15) Another thing worth checking, what is the value of module_index passed to radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c on your system? How can I get it? Should I print it in dmesg? yes, that would be great. -- 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: [git pull] drm tree for 3.12-rc1
Hi The regular flash plugin 10.2 doesn't have vaapi (Intel) support The Chrome flash plugin (10.7?) doesn't have any vaapi or vdpau support You best option is to install the vdpau to vaapi wrapper and disable the Chrome flash plugin https://github.com/i-rinat/libvdpau-va-gl This will revert you back to the older 10.2 flash version which should work I think I also had to override a few settings in the flash dot file to get it to skip GPU validation along with following the instruction for the above project Its quite convoluted but least it makes YouTube work Cheers Mike [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley sean.v.kel...@intel.com wrote: I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Non-HD content seems to be fine even full-screen. Either just because it's so much easier to do, or because some level of scaling is hw-accelerated. It may well be that I'm using chrome (and chrome seems to tend to use its own library versions), and firefox indeed seems to be a bit better. But by a bit better I mean closer to full frame rate in full-screen, but lots of tearing - and it was stil using 70% CPU when displaying in a window. So I think firefox is also still doing everything in software but may be better about using threads for it. My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus ___ 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
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #22 from Alex Deucher ag...@yahoo.com --- Can you try a vanilla xf86-video-ati rather than the ubuntu version? This looks like it may be specific to their version. -- 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: [git pull] drm tree for 3.12-rc1
On Tue, Sep 10, 2013 at 08:49:58AM -0700, Linus Torvalds writes : [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley sean.v.kel...@intel.com wrote: I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Yep. I see the same. Chrome is brain dead and appears to simply rely on Flash + FFmpeg software codecs. At least with Firefox you know it will suck and not be hw accelerated. Unless that has changed... Non-HD content seems to be fine even full-screen. Either just because it's so much easier to do, or because some level of scaling is hw-accelerated. SD content should be relatively fine with software codecs. Ideally, full-screen would disable composition and use hw-overlay in addition to an actual hw accel codec, h.264 or vp8 for html5 video. But that is not the case. That being said HSW does not support vp8 hw decode. It may well be that I'm using chrome (and chrome seems to tend to use its own library versions), and firefox indeed seems to be a bit better. But by a bit better I mean closer to full frame rate in full-screen, but lots of tearing - and it was stil using 70% CPU when displaying in a window. So I think firefox is also still doing everything in software but may be better about using threads for it. Sadly none of those would be hw accel without some specific flavor of flash plugin that favors hw accel over FFmpeg software accel (i.e., has older flash + wrapper for vdpau or vaapi). As someone else in this thread mentioned, it is quite a pain in the arse. Ironically, it is relatively trivial for me to do a chromium browser build form source myself and enable libva/intel-driver HW accel, h.264. And say screw you to flash et al, and leave that out. And that will work fine for html5 video on youtube with fallback to SW accel for VP8 based content. Why it is a chore for Google is not clear to me... Sean My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus pgpPtT56X6tii.pgp Description: PGP signature ___ 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 #16 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #14) Created attachment 85578 [details] [review] disable various dpm features I would suggest disabling various dpm features and see if you can narrow down which, if any, help. This patch disables just about everything. ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what actually sets the dynamic performance switching into motion. Prior to that the hw is locked into the low performance level. I sounds like there is some bad parameter that is causing a lock up when the smc enables state switching. Separate from the patch can you also try changing the ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a lock up. I'll try it later today. -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #30 from Quallenauge hams...@freenet.de --- The last patch works for me :) Thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #21 from Weber K. weber...@yahoo.com.br ---
Hello!
I think I found a workaround!
At this file:
https://github.com/RAOF/xf86-video-ati/blob/master/src/radeon_dri2.c
At line 608:
Changed from:
xorg_list_for_each_entry(ref, pClientEventsPriv-reference_list,
link) {
ref-valid = FALSE;
radeon_dri2_unref_buffer(ref-front);
radeon_dri2_unref_buffer(ref-back);
}
Replaced by:
xorg_list_for_each_entry(ref, pClientEventsPriv-reference_list,
link) {
if (ref-valid) {
ref-valid = FALSE;
radeon_dri2_unref_buffer(ref-front);
radeon_dri2_unref_buffer(ref-back);
}
}
I just checked valid before the calls, but I still cannot find what is making
double calls...
Maybe its because I have two boards? Onboard HD4250 e PCIE HD6850?
Thanks!
Weber Kai
bash-4.2# lspci
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880
[Radeon HD 4250]
01:05.1 Audio device: Advanced Micro Devices [AMD] nee ATI RS880 HDMI Audio
[Radeon HD 4200 Series]
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts
PRO [ATI Radeon HD 6800 Series]
02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Barts HDMI Audio
[Radeon HD 6800 Series]
--
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 0/3] drm/radeon kexec fixes
On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman ebied...@xmission.com wrote: Alex Deucher alexdeuc...@gmail.com writes: On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: IIRC Alex said the sanity checks are expensive and boot-time could be improved by dropping them. Maybe he can chime in? They shouldn't be necessary with a proper shutdown, but in this particular case, they are not very expensive. What is expensive is having a separate sanity check functions for all the various hw blocks to teardown everything on startup prior to starting it up in case kexec, etc. left the system in a bad state. It ends up amounting to a full tear down sequence followed by a full start up sequence every time you load the driver. I can't really comment on the first patch, but the rest seem fine. Let me reask the question just a little bit. Is it the sanity checks that are expensive? Or is it the reinitialization that is triggered by the sanity checks that is expensive? From what Christian said in the other reply it sounds like this is a game we will never completely win, but it would be nice to have half a chance in the kexec on panic case to have video. So I am curious to know if the checks are expensive when we are coming at hardware in a clean state. The particular sanity checks from this patch set are not expensive, but we had previously discussed more extensive sanity checks for other aspects of the chips in prior conversations. Prior to this patch set, the hw is not torn down properly (might have been in the middle of DMA for example) when kexec happens. That's why the sanity checks were added in the first place. With this patch set, the sanity checks shouldn't be necessary. Alex ___ 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 #17 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #15) Another thing worth checking, what is the value of module_index passed to radeon_atom_init_mc_reg_table() in ni_initialize_mc_reg_table() in ni_dpm.c on your system? How can I get it? Should I print it in dmesg? -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #24 from Weber K. weber...@yahoo.com.br --- Looking at neuromancer Xorg log, I found out: [ 7.278] (--) RADEON(0): Chipset: SUMO (ChipID = 0x9641) [ 7.548] (--) RADEON(G0): Chipset: TURKS (ChipID = 0x6741) I think its a problem only with two devices with radeon driver... After closing client, the destroy buffer is called twice, and causes the error... I can workaround, but I cant fix it the right way... I have no experience with Xorg or radeon driver... I dont know either how to edit the subject of the bug... Please... Help us... Thanks in advance! Weber Kai -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #23 from Weber K. weber...@yahoo.com.br --- Hi! Ive found that (for me) this layout is causing the error: Section ServerLayout Identifier My X Server Screen 0 LeftScreen 0 0 Screen 1 RightScreen RightOf LeftScreen InputDevice Mouse1 CorePointer InputDevice Keyboard1 CoreKeyboard EndSection If I remove Screen 1 then the error dont occur... Both devices are using radeon driver... I cannot test if the error occur only when both devices are radeon, or if having two Screens of any type... I think the destroy buffer is called twice because of two screens... Anyway, the workaround of checking valid value fixes this issue for me... Sorry, I cant test vanilla, I am using Slackware64... Ive downloaded the source DVD and changed x11.SlackBuild... Only changed CFLAGS to -O0 -g3 and removed strip symbols... Thanks... Weber Kai -- 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: [git pull] drm tree for 3.12-rc1
On Tue, Sep 10, 2013 at 1:50 PM, Sean V Kelley sean.v.kel...@intel.com wrote: On Tue, Sep 10, 2013 at 08:49:58AM -0700, Linus Torvalds writes : [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley sean.v.kel...@intel.com wrote: I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. Yep. I see the same. Chrome is brain dead and appears to simply rely on Flash + FFmpeg software codecs. At least with Firefox you know it will suck and not be hw accelerated. Unless that has changed... Ironically, it is relatively trivial for me to do a chromium browser build form source myself and enable libva/intel-driver HW accel, h.264. And say screw you to flash et al, and leave that out. And that will work fine for html5 video on youtube with fallback to SW accel for VP8 based content. Why it is a chore for Google is not clear to me... Google actually blacklists hardware video acceleration for Linux x86 in Chromium. My builds are based on ChromeOS' browser. That's how I get around it. For more details... https://codereview.chromium.org/16430003/ Sean Sean My previous i5-670 which was inferior in almost every other way didn't have these problems.. It had the same 2560x1440 display. Linus -- Sean V. Kelley sean.v.kel...@intel.com Open Source Technology Center / SSG Intel Corp. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Wed, Sep 11, 2013 at 1:49 AM, Linus Torvalds torva...@linux-foundation.org wrote: [ Dave - your linux.ie email generates bounces for me, trying redhat instead ] Uggh no worries, I read my list mail from gmail mostly anyways, so if its on a list I'll probably see it. Can you give a little more detail about video not working? Video accel should work fine with the current versions of libva/intel-driver available in Fedora 19 - assuming that's what you're using. It is indeed F19. Easy test: go to youtube, and watch things that are in 1080p HD. They play fine in a window (using about 70% CPU), but full-screened to 2560x1440 they play at about one or two frames per second. It doesn't sound like you are using hw accelerated video at all and its just sw renderered flash, In which case it could be a CPU issue, is the cpu freq scaling working correctly? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #25 from lbdkm...@sharklasers.com --- Yes, this, aparently, only happens in dual AMD graphics laptops (with llano)... and I found a workaround: you have to disable the second (discrete) GPU: echo OFF /sys/kernel/debug/vgaswitcheroo/switch and it will not crash anymore... Sadly, vgaswitcheroo throws a big warning in dmesg: http://pastebin.com/rXj8rrZa (I'm using kernel 3.11.0-6 from ubuntu's proposed repos) , after which /sys/kernel/debug/vgaswitcheroo/ disappears completely and I'm not able to use the dGPU until the next boot. I will have to report this.. dunno where though. (and also, I always get a black screen after resume from suspend to RAM). as I said before, the patch helped, i.e., made it harder to crash, but apps (glxgears, vlc, mplayer + gl) will crash nonetheless. I hope this helps. And I want to thank the devs for their great job with the radeon FOSS driver! -- 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/msm: fix return value check in ERR_PTR()
On Tue, Sep 10, 2013 at 6:56 PM, Wei Yongjun weiyj...@gmail.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
good catch, thanks
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6b5a6c8..3462def 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -40,9 +40,9 @@ static struct page **get_pages(struct drm_gem_object *obj)
}
msm_obj-sgt = drm_prime_pages_to_sg(p, npages);
- if (!msm_obj-sgt) {
+ if (IS_ERR(msm_obj-sgt)) {
dev_err(dev-dev, failed to allocate sgt\n);
- return ERR_PTR(-ENOMEM);
+ return ERR_CAST(msm_obj-sgt);
}
msm_obj-pages = p;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #13 from Dieter Nützel die...@nuetzel-hh.de --- Hurray Alex, your possible fix from Comment 10 solve it halfway or maybe fully even on my slow Duron 1800, RV730 AGP (4650), if we separate the mosaic into a new bug entry. The SPEED is there, now. I can play 2 H.264 VDPAU accelerated videos (854x480 and 1280x720) simultaneously with ~35% idle rest on this little system. Have a look at 2-times-mplayer-konsole.png attachment. I've tested it with AGP and PCIE mode, both with same results. The mosaic problem IS mouse cursor (hardware cursor?) related! If the (big/fullscreen) video window coming up 'under' (over?) the mouse cursor position I get immediately mosaic. When a smaller video window starts from mouse cursor postion away UVD is excellent. Mosaic starts then not until mouse cursor move over the video window. With mplayer this could be faster reached if one seek into the video window. See 2-times-mplayer-mosaic.png attachment. Tested with AGP and PCIE mode. Very nice! -Dieter -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #14 from Dieter Nützel die...@nuetzel-hh.de --- Created attachment 85591 -- https://bugs.freedesktop.org/attachment.cgi?id=85591action=edit 2-times-mplayer-konsole.png -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #15 from Dieter Nützel die...@nuetzel-hh.de --- Created attachment 85592 -- https://bugs.freedesktop.org/attachment.cgi?id=85592action=edit 2-times-mplayer-mosaic.png -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #16 from Dieter Nützel die...@nuetzel-hh.de --- Created attachment 85593 -- https://bugs.freedesktop.org/attachment.cgi?id=85593action=edit dmesg-drm-next-3.12-AGP-dpm-1-fix-fallback-for-empty-UVD-clocks.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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #17 from Dieter Nützel die...@nuetzel-hh.de --- Created attachment 85594 -- https://bugs.freedesktop.org/attachment.cgi?id=85594action=edit dmesg-drm-next-3.12-PCIE-dpm-1-fix-fallback-for-empty-UVD-clocks.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 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 #19 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #16) (In reply to comment #14) Created attachment 85578 [details] [review] [review] disable various dpm features I would suggest disabling various dpm features and see if you can narrow down which, if any, help. This patch disables just about everything. ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) is what actually sets the dynamic performance switching into motion. Prior to that the hw is locked into the low performance level. I sounds like there is some bad parameter that is causing a lock up when the smc enables state switching. Separate from the patch can you also try changing the ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO) call in ni_dpm_set_power_state() to low (RADEON_DPM_FORCED_LEVEL_LOW) or high (RADEON_DPM_FORCED_LEVEL_HIGH) rather than auto? See if you still get a lock up. I'll try it later today. I had time for now to play with forcing RADEON_DPM_FORCED_LEVEL_LOW and RADEON_DPM_FORCED_LEVEL_HIGH. The first one works fine, the second triggers the problem. I'm about to play with the suggested patch. -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #18 from Dieter Nützel die...@nuetzel-hh.de --- (In reply to comment #10) Created attachment 85563 [details] [review] possible fix The attached patch should fix the issue. Candidate for stable? -Dieter -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #26 from Weber K. weber...@yahoo.com.br --- During a test, I needed to issue 2 cont commands at gdb to advance just one frame at one breakpoint I trapped. And when closing the player, I issued twice cont at gdb, and only after the segfault occured. I suspect the function radeon_dri2_screen_init at radeon_dri2.c is called twice, one for each Screen, and then this routine is scheduling the radeon_dri2_client_state_changed routine twice with AddCallBack. This way, when the client state is changed to gone, the destroy buffers routine is called twice either, and the error occur. I also want to thank the devs for the radeon driver! Thank you! -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #27 from Weber K. weber...@yahoo.com.br ---
I think Ive got it! :)
Changed this file:
https://github.com/RAOF/xf86-video-ati/blob/master/src/radeon_dri2.c
Line 1404 from:
AddCallback(ClientStateCallback, radeon_dri2_client_state_changed, 0);
Replaced by:
if (pScrn-scrnIndex == 0) {
AddCallback(ClientStateCallback, radeon_dri2_client_state_changed, 0);
}
The callback is called only once, even if multiple screens! And the error is
gone!
Please, can someone check if it need to be repeated in other parts as well?
If correct, can someone commit it?
Thank you very much! :)
Weber Kai
--
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 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Shawn Starr shawn.st...@rogers.com --- Multiple issues... GPU reset issue was fixed, this is GLSL error, reopening with new bug, not SB related -- 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
