[Bug 64850] Second screen black on Pitcairn PRO
https://bugs.freedesktop.org/show_bug.cgi?id=64850 --- Comment #24 from Jakob Nixdorf --- Update: Problem still exists on kernel 3.11-rc1. -- 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
[PATCH] drm/nouveau: do not move buffers when not needed
Op 15-07-13 08:05, Ben Skeggs schreef:
> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
> 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.
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
---
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;
/* make sure bo is in mappable vram */
if (bo->mem.start + bo->mem.num_pages < mappable)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: allow selection of alignment in the sub-allocator
Am 12.07.2013 23:51, schrieb alexdeuc...@gmail.com:
From: Alex Deucher
There are cases where we need more than 4k alignment. No
functional change with this commit.
Signed-off-by: Alex Deucher
This series is: Reviewed-by: Christian König
Out of curiosity: Where did you find that info? I looked for it quite a
bit while working on page table directories and couldn't find anything.
Christian.
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
drivers/gpu/drm/radeon/radeon_ring.c |1 +
drivers/gpu/drm/radeon/radeon_sa.c |7 ---
5 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 6fe4b1c..39d2ce6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -455,6 +455,7 @@ struct radeon_sa_manager {
uint64_tgpu_addr;
void*cpu_ptr;
uint32_tdomain;
+ uint32_talign;
};
struct radeon_sa_bo;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 43ec4a4..5ce190b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -467,6 +467,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
size *= 2;
r = radeon_sa_bo_manager_init(rdev,
&rdev->vm_manager.sa_manager,
RADEON_GPU_PAGE_ALIGN(size),
+ RADEON_GPU_PAGE_SIZE,
RADEON_GEM_DOMAIN_VRAM);
if (r) {
dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 91519a5..49c82c4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -174,7 +174,7 @@ static inline void * radeon_sa_bo_cpu_addr(struct
radeon_sa_bo *sa_bo)
extern int radeon_sa_bo_manager_init(struct radeon_device *rdev,
struct radeon_sa_manager *sa_manager,
-unsigned size, u32 domain);
+unsigned size, u32 align, u32 domain);
extern void radeon_sa_bo_manager_fini(struct radeon_device *rdev,
struct radeon_sa_manager *sa_manager);
extern int radeon_sa_bo_manager_start(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 5f1c51a..fb5ea62 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -224,6 +224,7 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
}
r = radeon_sa_bo_manager_init(rdev, &rdev->ring_tmp_bo,
RADEON_IB_POOL_SIZE*64*1024,
+ RADEON_GPU_PAGE_SIZE,
RADEON_GEM_DOMAIN_GTT);
if (r) {
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 0abe5a9..f0bac68 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -49,7 +49,7 @@ static void radeon_sa_bo_try_free(struct radeon_sa_manager
*sa_manager);
int radeon_sa_bo_manager_init(struct radeon_device *rdev,
struct radeon_sa_manager *sa_manager,
- unsigned size, u32 domain)
+ unsigned size, u32 align, u32 domain)
{
int i, r;
@@ -57,13 +57,14 @@ int radeon_sa_bo_manager_init(struct radeon_device *rdev,
sa_manager->bo = NULL;
sa_manager->size = size;
sa_manager->domain = domain;
+ sa_manager->align = align;
sa_manager->hole = &sa_manager->olist;
INIT_LIST_HEAD(&sa_manager->olist);
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
INIT_LIST_HEAD(&sa_manager->flist[i]);
}
- r = radeon_bo_create(rdev, size, RADEON_GPU_PAGE_SIZE, true,
+ r = radeon_bo_create(rdev, size, align, true,
domain, NULL, &sa_manager->bo);
if (r) {
dev_err(rdev->dev, "(%d) failed to allocate bo for manager\n",
r);
@@ -317,7 +318,7 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
unsigned tries[RADEON_NUM_RINGS];
int i, r;
- BUG_ON(align > RADEON_GPU_PAGE_SIZE);
+ BUG_ON(align > sa_manager->align);
BUG_ON(size > sa_manager->size);
*sa_bo = kmalloc(sizeof(struct radeon_sa_bo), GFP_KERNEL);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
Re: [BUG] radeon: suspend resume
[ The radeon driver is discussed on the dri-devel mailing list, moving there ] On Son, 2013-07-14 at 13:26 +0100, Sami Kerola wrote: > > Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup > CP stall for more than 1msec > Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup > (waiting for 0x0004 last fence id 0x0002) > Jul 14 12:51:31 kerolasa-home kernel: [drm:r600_uvd_ib_test] *ERROR* > radeon: fence wait failed (-35). > Jul 14 12:51:31 kerolasa-home kernel: [drm:radeon_ib_ring_tests] > *ERROR* radeon: failed testing IB on ring 5 (-35). Looks like the patch from https://bugs.freedesktop.org/show_bug.cgi?id=66425 might help. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #67 from Michel Dänzer --- (In reply to comment #66) > While I'm the one who opened this bug, on my side I'm able to run all piglit > tests without any hangs since awhile now. Even with GPU virtual memory enabled? If so, this report can be resolved as fixed? -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #68 from udo --- I still use RADEON_VA=0 to avoid GPU lockups etc. Was anything changed so there's reason to test with RADEON_VA=1? -- 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: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote:
> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > According to Matthew Garrett, "Windows 8 leaves backlight control up
> > to individual graphics drivers rather than making ACPI calls itself.
> > There's plenty of evidence to suggest that the Intel driver for
> > Windows [8] doesn't use the ACPI interface, including the fact that
> > it's broken on a bunch of machines when the OS claims to support
> > Windows 8. The simplest thing to do appears to be to disable the
> > ACPI backlight interface on these systems".
> >
> > There's a problem with that approach, however, because simply
> > avoiding to register the ACPI backlight interface if the firmware
> > calls _OSI for Windows 8 may not work in the following situations:
> > (1) The ACPI backlight interface actually works on the given system
> > and the i915 driver is not loaded (e.g. another graphics driver
> > is used).
> > (2) The ACPI backlight interface doesn't work on the given system,
> > but there is a vendor platform driver that will register its
> > own, equally broken, backlight interface if not prevented from
> > doing so by the ACPI subsystem.
> > Therefore we need to allow the ACPI backlight interface to be
> > registered until the i915 driver is loaded which then will unregister
> > it if the firmware has called _OSI for Windows 8 (or will register
> > the ACPI video driver without backlight support if not already
> > present).
> >
> > For this reason, introduce an alternative function for registering
> > ACPI video, acpi_video_register_with_quirks(), that will check
> > whether or not the ACPI video driver has already been registered
> > and whether or not the backlight Windows 8 quirk has to be applied.
> > If the quirk has to be applied, it will block the ACPI backlight
> > support and either unregister the backlight interface if the ACPI
> > video driver has already been registered, or register the ACPI
> > video driver without the backlight interface otherwise. Make
> > the i915 driver use acpi_video_register_with_quirks() instead of
> > acpi_video_register() in i915_driver_load().
> >
> > This change is based on earlier patches from Matthew Garrett,
> > Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
> >
> > Signed-off-by: Rafael J. Wysocki
>
> Reviewed-by: Aaron Lu
>
> BTW, I also tested on a Toshiba laptop Z830 where its AML code
> claims support of win8, the result is as expected: ACPI video
> interface is removed, i915 Xorg driver picks intel_backlight.
>
> Thanks for the fix.
Cool, thanks for testing this!
Can you please also ask bug reporters in the BZ entires related to this to test
it too?
Rafael
> > ---
> > drivers/acpi/internal.h | 11 ++
> > drivers/acpi/video.c| 65
> >
> > drivers/acpi/video_detect.c | 21
> > drivers/gpu/drm/i915/i915_dma.c |2 -
> > include/acpi/video.h| 11 ++
> > include/linux/acpi.h|1
> > 6 files changed, 103 insertions(+), 8 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/video.c
> > ===
> > --- linux-pm.orig/drivers/acpi/video.c
> > +++ linux-pm/drivers/acpi/video.c
> > @@ -44,6 +44,8 @@
> > #include
> > #include
> >
> > +#include "internal.h"
> > +
> > #define PREFIX "ACPI: "
> >
> > #define ACPI_VIDEO_BUS_NAME"Video Bus"
> > @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> > device->cap._DDC = 1;
> > }
> >
> > - if (acpi_video_backlight_support()) {
> > + if (acpi_video_verify_backlight_support()) {
> > struct backlight_properties props;
> > struct pci_dev *pdev;
> > acpi_handle acpi_parent;
> > @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> > return 0;
> > }
> >
> > +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> > + void *context, void **rv)
> > +{
> > + struct acpi_device *acpi_dev;
> > + struct acpi_video_bus *video;
> > + struct acpi_video_device *dev, *next;
> > +
> > + if (acpi_bus_get_device(handle, &acpi_dev))
> > + return AE_OK;
> > +
> > + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> > + return AE_OK;
> > +
> > + video = acpi_driver_data(acpi_dev);
> > + if (!video)
> > + return AE_OK;
> > +
> > + acpi_video_bus_stop_devices(video);
> > + mutex_lock(&video->device_list_lock);
> > + list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
> > + if (dev->backlight) {
> > + backlight_device_unregister(dev->backlight);
> > + dev->backlight = NULL;
> > + kfree(dev->brightness->levels);
> > + kfree(dev->brightness);
>
[PATCH 1/1] drm/cma: Replace PTR_RET with PTR_ERR_OR_ZERO
PTR_RET is now deprecated. Use PTR_ERR_OR_ZERO instead. Signed-off-by: Sachin Kamat --- Compile tested and based on the following tree: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git (PTR_RET) Dependent on [1] [1] http://lkml.indiana.edu/hypermail/linux/kernel/1306.2/00010.html --- drivers/gpu/drm/drm_gem_cma_helper.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index ece72a8..61c1d17 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -215,7 +215,7 @@ int drm_gem_cma_dumb_create(struct drm_file *file_priv, cma_obj = drm_gem_cma_create_with_handle(file_priv, dev, args->size, &args->handle); - return PTR_RET(cma_obj); + return PTR_ERR_OR_ZERO(cma_obj); } EXPORT_SYMBOL_GPL(drm_gem_cma_dumb_create); -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66920] New: [llvm backend] flashing textures, no lights in car , no water on GTA IV
https://bugs.freedesktop.org/show_bug.cgi?id=66920 Priority: medium Bug ID: 66920 Assignee: dri-devel@lists.freedesktop.org Summary: [llvm backend] flashing textures, no lights in car , no water on GTA IV Severity: normal Classification: Unclassified OS: Linux (All) Reporter: son_of_the_osi...@interia.pl Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I just tried sb backend with GTA IV on wine and must say that it works better than llvm. With llvm I have black rectangle instead of car lights and same with water. Also I seen some flashing textures.When enable R600_DEBUG-sb,nollvm game run little faster and without graphics problem. Kernel 3.10 wine 1.6rc5 mesa - git compiled with : --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r600 \ --with-dri-drivers= \ --with-llvm-shared-libs \ --enable-gallium-llvm \ --enable-r600-llvm-compiler \ --enable-xvmc \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm,wayland \ --enable-shared-glapi \ --enable-gbm \ --enable-glx-tls \ --enable-opencl \ --disable-debug \ --disable-osmesa \ --enable-gles1 \ --enable-gles2 \ --enable-texture-float \ --disable-xa \ --enable-vdpau \ -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #69 from Marek Olšák --- (In reply to comment #67) > (In reply to comment #66) > > While I'm the one who opened this bug, on my side I'm able to run all piglit > > tests without any hangs since awhile now. > > Even with GPU virtual memory enabled? If so, this report can be resolved as > fixed? This bug has been fixed by the kernel patch 466476dfdcafbb4286ffa232a3a792731b9dc852 for quite a long time as far as 3D support is concerned. Some say that OpenCL still locks up, but I think that's a different 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
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #70 from udo --- Tom Stellard advised me not to use virtual memory, first by patch and later with RADEON_VA=0 as OpenCL started to work for Cayman (ARUBA here in A10-5800K) graphics. Which bug to see for virtual memory and OpenCL? -- 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 66921] New: [r300g] Heroes of Newerth: HiZ related corruption
https://bugs.freedesktop.org/show_bug.cgi?id=66921 Priority: medium Bug ID: 66921 Keywords: regression Assignee: dri-devel@lists.freedesktop.org Summary: [r300g] Heroes of Newerth: HiZ related corruption Severity: normal Classification: Unclassified OS: All Reporter: pavel.ondra...@email.cz URL: http://www.heroesofnewerth.com/download/ Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 82440 --> https://bugs.freedesktop.org/attachment.cgi?id=82440&action=edit screenshot In Heroes of Newerth, there is massive black corruption over top half of screen anytime, when you move mouse over some game objects, like buildings. This is HiZ related and goes away when RADEON_DEBUG=nohiz is set. I also found out that it goes away completely when I revert commit 631c631cbf5b7e84e42a7cfffa1c206d63143370 Author: Marek Olšák Date: Fri May 13 02:26:08 2011 +0200 r300g: allow HiZ with a 16-bit zbuffer HoN is free to play, however I can make an apitrace if needed. GPU:RV530 (R520 also affected) Mesa: b616d0166158872a135153e27c391424fe655117 Kernel: 3.9.4-200.fc18.i686 libdrm: f8f1f6e37ae2c3eb4a9c045ba3294b3ccf926c07 -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #71 from Alexandre Demers --- (In reply to comment #67) > (In reply to comment #66) > > While I'm the one who opened this bug, on my side I'm able to run all piglit > > tests without any hangs since awhile now. > > Even with GPU virtual memory enabled? If so, this report can be resolved as > fixed? I'll have to double check, but from what I remember, yes even with VM enabled. But I'm not playing with OpenCL. It's just that I was seeing new CCers being added and this bug is still open because Udo was experiencing a problem that looked like the current bug. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #72 from udo --- I can see if the bug is still present (aside from OpenCL usage) in normal desktop usage (mail, web, youtube, etc). -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #73 from Michel Dänzer --- (In reply to comment #71) > It's just that I was seeing new CCers being added and this bug is still open > because Udo was experiencing a problem that looked like the current bug. As you said, you're the reporter of this bug. If the problem you reported here is fixed, please resolve it accordingly. If Udo is still having problems, he should file his own report. -- 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 66932] New: Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 Priority: medium Bug ID: 66932 Assignee: dri-devel@lists.freedesktop.org Summary: Screen corruption on Cayman with dpm enabled Severity: normal Classification: Unclassified OS: Linux (All) Reporter: g02ma...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 82448 --> https://bugs.freedesktop.org/attachment.cgi?id=82448&action=edit dmesg When I enable dpm with my 6950 I see major screen corruption. It works fine with dpm disabled. The computer does not get completely locked up. The screen flickers but there is always a pattern in the corruption that stays the same. Sometimes, not always, I can see and control a corrupted mouse cursor. But the screen is so corrupted that i can't login or do anything. I can ssh into the computer but it won't reboot. I first tried 3.11-rc1 but then did my tests on http://cgit.freedesktop.org/~agd5f/linux/?h=drm-fixes-3.11 with latest commit being a01c34f72e7cd2624570818f579b5ab464f93de2 I have ucode (downloaded 2013-06-15) from http://people.freedesktop.org/~agd5f/radeon_ucode/ I compiled the kernel with this. CONFIG_EXTRA_FIRMWARE="radeon/CAYMAN_mc.bin radeon/CAYMAN_me.bin radeon/CAYMAN_pfp.bin radeon/CAYMAN_rlc.bin radeon/CAYMAN_smc.bin radeon/SUMO_uvd.bin" I did a bisect and found that this commit introduced the corruption: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=7ad8d0687bb5030c3328bc7229a3183ce179ab25 -- 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 66932] Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 --- Comment #1 from Martin Andersson --- Created attachment 82449 --> https://bugs.freedesktop.org/attachment.cgi?id=82449&action=edit screenshot of corruption -- 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 64850] Second screen black on Pitcairn PRO
https://bugs.freedesktop.org/show_bug.cgi?id=64850 Alex Deucher changed: What|Removed |Added CC||m...@elemc.name --- Comment #25 from Alex Deucher --- *** Bug 66934 has been marked as a duplicate of this bug. *** -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #13 from Tom Stellard --- (In reply to comment #9) > The piglit test should work with this patch: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130624/179364. > html > > But we should still try to fix the bug in libclc. I've just pushed this patch. What is the status of this bug with your vstore/vload fixes? -- 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 66940] New: Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 Priority: medium Bug ID: 66940 Assignee: dri-devel@lists.freedesktop.org Summary: Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next) Severity: normal Classification: Unclassified OS: All Reporter: m...@3v1n0.net Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 82459 --> https://bugs.freedesktop.org/attachment.cgi?id=82459&action=edit dmesg I've tried running linux 3.11 from both linus and drm_next branches, but when using the radeon drivers it's impossible to resume from suspension. It's quite sure that the problem is in radeon module, because unloading it (and switching to my intel card with vgaswitcheroo) works fine. Also, enabling the pm_trace sys-node it highlights that the radeon device caused the freeze: from dmesg: [1.286810] Magic number: 0:660:725 [1.286815] hash matches /home/marco/Dev/debs/linux/drivers/base/power/main.c:575 [1.286829] block loop5: hash matches [1.286867] pci :01:00.0: hash matches ^ This is the PCI id of my radeon card cat /sys/power/pm_trace_dev_match: block radeon This is a regression, since linux 3.10 works well. -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #1 from Marco Trevisan (Treviño) --- Created attachment 82460 --> https://bugs.freedesktop.org/attachment.cgi?id=82460&action=edit /proc/acpi/wakeup -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #2 from Marco Trevisan (Treviño) --- Created attachment 82461 --> https://bugs.freedesktop.org/attachment.cgi?id=82461&action=edit /sys/power/pm_trace_dev_match -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 Marco Trevisan (Treviño) changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Priority|medium |high -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #74 from Alexandre Demers --- (In reply to comment #73) > (In reply to comment #71) > > It's just that I was seeing new CCers being added and this bug is still open > > because Udo was experiencing a problem that looked like the current bug. > > As you said, you're the reporter of this bug. If the problem you reported > here is fixed, please resolve it accordingly. If Udo is still having > problems, he should file his own report. Then fixed and closed it is. -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #3 from Alex Deucher --- Can you bisect? -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #4 from Marco Trevisan (Treviño) --- (In reply to comment #3) > Can you bisect? I can do that, but in few days... -- 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 66942] New: Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 Priority: medium Bug ID: 66942 Assignee: dri-devel@lists.freedesktop.org Summary: Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next Severity: major Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: All Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I just compiled and tested kernel 3.11.0-rc1. It hangs and do nothing when initializing (last thing displayed is "Loading initial ramdisk"). Setting radeon.dpm=1 or 0 gives the same result. Since I know I'm also experiencing this hang with last week drm-next branch, I'll try to bisect and see where it leads us. -- 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 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #1 from Alexandre Demers --- As a side note, it could be related to bug 66940 -- 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 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #5 from had...@gmx.de --- Any news on this one? Its really bad on radeonsi, since theres no workaround. Still happens with llvm and mesa from git. -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #14 from Aaron Watry --- I still get errors with the v8i32/v16i32 loads, but those aren't currently enabled in the R600 or SI back-ends as far as I know. If I comment out the vload8 and vload16 tests everything runs correctly for me on my 7850 with git master llvm/clang and my vload/vstore changes for libclc. -- 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 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #2 from Alex Deucher --- probably a duplicate of bug 66551. -- 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: DT binding review for Armada display subsystem
Hi, On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote: > On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote: > > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote: > >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote: > >>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it > >>> seems they're working on v4 with clock object reference counting. > >>> Presumably we need both clk_get() to be taking reference on the > >>> module and reference counted clk free, e.g. in cases where clock > >>> provider is a hot-pluggable device. It might be too paranoid > >>> though, I haven't seen hardware configurations where a clock source > >>> could be unplugged safely when whole system is running. > >> > >> I'm not going to accept refcounting being thrown into clk_get(). The > >> clkdev API already has refcounting, as much as it needs to. It just > >> needs people to use the hooks that I provided back in 2008 when I > >> created the clkdev API for doing _precisely_ this job. > >> > >> Have a read through these commits, which backup my statement above: > >> > >> 0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the > >> clkdev API d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting > >> Integrator to clkdev API > >> > >> and it will show you how to do refcounting. The common clk API just > >> needs to stop defining __clk_get() and __clk_put() to be an empty > >> function and implement them appropriately for it's clk > >> implementation, > >> like they were always meant to be. > > > > Sure, I've already seen the above commits. This is how I understood it > > as well - __clk_get(), __clk_put() need to be defined by the common > > clk > > API, since it is going to replace all the arch specific > > implementations.> > >> __clk_get() and __clk_put() are the clk-implementation specific parts > >> of the clkdev API, because the clkdev API is utterly divorsed from > >> the > >> internals of what a 'struct clk' actually is. clkdev just treats a > >> 'struct clk' as a completely opaque type and never bothers poking > >> about inside it. > > > > OK, but at the clock's implementation side we may need, e.g. to use > > kref to keep track of the clock's state, and free it only when it is > > unprepared, all its children are unregistered, etc. ? Is it not what > > you stated in your comment to patch [1] ? > > If you want to do refcounting on a clock (which you run into problems > as I highlighted earlier in this thread) then yes, you need to use a > kref, and take a reference in __clk_get() and drop it in __clk_put() > to make things safe. > > Whether you also take a reference on the module supplying the clock or > not depends whether you need to keep the code around to manipulate that > clock while there are users of it. > > As I've already said - consider the possibilities with this scenario. > Here's one: > > A clock consumer is using a clock, but the clock supplier has been > removed. The clock consumer wants to change the state of the clock > in some way - eg, system is suspending. clk_disable() doesn't fail, > but on resume, clk_enable() does... (and how many people assume that > clk_enable() never fails?) And who knows what rate the clock is now > producing or whether it's even producing anything... > > I'm not saying don't do the refcounting thing I mentioned back in June. > I'm merely pointing out the issues that there are. There isn't a one > right answer here because each has their own advantages and > disadvantages (and problems.) What about having Mike on CC for such clock-related discussion? Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.11
From: Alex Deucher Hi Dave, Bug fixes for radeon all over the place. Big one is a fix for ttm which causes hangs on boot for a number of systems. The following changes since commit 774d8e34e46506222bb5e2888e3ef42b2775715f: Merge branch 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux into drm-next (2013-07-09 10:49:39 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.11 Alex Deucher (11): drm/radeon/hdmi: make sure we have an afmt block assigned drm/radeon/dpm: disable gfx PG on PALM drm/radeon: Disable dma rings for bo moves on r6xx drm/radeon: implement bo copy callback using CP DMA (v2) drm/radeon: use CP DMA on r6xx for bo moves drm/radeon: add fault decode function for cayman/TN (v2) drm/radeon: add fault decode function for SI (v2) drm/radeon: add fault decode function for CIK drm/radeon: allow selection of alignment in the sub-allocator drm/radeon: align VM PTBs (Page Table Blocks) to 32K drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level Christian König (2): drm/radeon: fix UVD fence emit drm/radeon: never unpin UVD bo v3 Jerome Glisse (1): drm/radeon: use radeon device for request firmware Maarten Lankhorst (1): drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate Sergey Senozhatsky (1): radeon kms: do not flush uninitialized hotplug work drivers/gpu/drm/radeon/cik.c| 59 --- drivers/gpu/drm/radeon/cikd.h | 16 ++ drivers/gpu/drm/radeon/evergreen.c | 10 +- drivers/gpu/drm/radeon/evergreen_hdmi.c |6 + drivers/gpu/drm/radeon/ni.c | 182 +-- drivers/gpu/drm/radeon/nid.h| 16 ++ drivers/gpu/drm/radeon/r100.c | 11 +- drivers/gpu/drm/radeon/r600.c | 102 +-- drivers/gpu/drm/radeon/r600_hdmi.c |6 + drivers/gpu/drm/radeon/r600d.h |1 + drivers/gpu/drm/radeon/radeon.h |9 +- drivers/gpu/drm/radeon/radeon_asic.c| 12 +- drivers/gpu/drm/radeon/radeon_asic.h|3 + drivers/gpu/drm/radeon/radeon_fence.c |2 +- drivers/gpu/drm/radeon/radeon_gart.c| 11 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 11 +- drivers/gpu/drm/radeon/radeon_object.c |1 + drivers/gpu/drm/radeon/radeon_object.h |2 +- drivers/gpu/drm/radeon/radeon_ring.c|1 + drivers/gpu/drm/radeon/radeon_sa.c |7 +- drivers/gpu/drm/radeon/radeon_uvd.c | 111 +--- drivers/gpu/drm/radeon/rv770.c |2 +- drivers/gpu/drm/radeon/si.c | 295 +-- drivers/gpu/drm/radeon/sid.h| 14 ++ drivers/gpu/drm/radeon/sumo_dpm.c | 14 ++- 25 files changed, 733 insertions(+), 171 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DT binding review for Armada display subsystem
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote: > On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote: > > Based on the outcomes of the "Best practice device tree design for display > > subsystems" discussion I have drafted a DT binding. Comments much > > appreciated. > > > > At a high level, it uses a "super node" as something for the driver to bind > > to, needed because there is no clear one device that controls all the > > others, and also to distinguish between the Armada 510 possible use cases > > of having one video card with two outputs, or two independent video cards. > > It uses node-to-node linking beyond that point, V4L2 style. > > As this hasn't been shot down very far, I've started to implement the > driver side of this binding. I have already run into a couple of > little problems. > > First, interrupts. In the dt binding, each "lcd controller" node > defines which interrupt it listens to, and in the armada 510 case > there are indeed 2 interrupts (47 and 46, one for each LCD > controller). And remember that the drm driver itself binds to the > super-node. > > Looking at drm_irq_install(), it looks like DRM only supports 1 > interrupt line per drm_device. You don't have to call drm_irq_install(). Both the exynos and i.MX driver do without it and at least the i.MX driver uses multiple irqs per drm_device. > > Secondly, devm. I understand from the "best practices" thread that we > want to have exactly one platform_device which corresponds to the > "super node", and all of the individual display controller components > will be represented by DT nodes but *without* their own > platform_device. A super node approach doesn't mean that there's only one platform device. You can still have a platform device for each component. The super node should rather be seen as a node which contains phandles to the different components.. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66921] [r300g] Heroes of Newerth: HiZ related corruption
https://bugs.freedesktop.org/show_bug.cgi?id=66921 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marek Olšák --- Okay, I have reverted the commit. -- 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 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #3 from Alexandre Demers --- (In reply to comment #2) > probably a duplicate of bug 66551. Probably not, the bug happens prior to the commit identified in bug 66551. I'm bisecting as we are talking. I also noticed a small glitch that was not in kernel 3.9 but is present in 3.10 that I'll report in another bug. -- 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: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Monday, July 15, 2013 05:06:09 PM Igor Gnatenko wrote:
> On Sat, 2013-07-13 at 02:46 +0200, Rafael J. Wysocki wrote:
[...]
>
> I can't build it. Where did I go wrong?
Probably nowhere, you tried to build the ACPI video driver as a module, that's
all. And you need to apply https://patchwork.kernel.org/patch/2812951/
before.
Please try the appended version (on top of
https://patchwork.kernel.org/patch/2812951/).
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".
There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
(1) The ACPI backlight interface actually works on the given system
and the i915 driver is not loaded (e.g. another graphics driver
is used).
(2) The ACPI backlight interface doesn't work on the given system,
but there is a vendor platform driver that will register its
own, equally broken, backlight interface if not prevented from
doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).
For this reason, introduce an alternative function for registering
ACPI video, acpi_video_register_with_quirks(), that will check
whether or not the ACPI video driver has already been registered
and whether or not the backlight Windows 8 quirk has to be applied.
If the quirk has to be applied, it will block the ACPI backlight
support and either unregister the backlight interface if the ACPI
video driver has already been registered, or register the ACPI
video driver without the backlight interface otherwise. Make
the i915 driver use acpi_video_register_with_quirks() instead of
acpi_video_register() in i915_driver_load().
This change is based on earlier patches from Matthew Garrett,
Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/internal.h | 11 ++
drivers/acpi/video.c| 65
drivers/acpi/video_detect.c | 21
drivers/gpu/drm/i915/i915_dma.c |2 -
include/acpi/video.h| 11 ++
include/linux/acpi.h|1
6 files changed, 103 insertions(+), 8 deletions(-)
Index: linux-pm/drivers/acpi/video.c
===
--- linux-pm.orig/drivers/acpi/video.c
+++ linux-pm/drivers/acpi/video.c
@@ -44,6 +44,8 @@
#include
#include
+#include "internal.h"
+
#define PREFIX "ACPI: "
#define ACPI_VIDEO_BUS_NAME"Video Bus"
@@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
device->cap._DDC = 1;
}
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
return 0;
}
+static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
+ void *context, void **rv)
+{
+ struct acpi_device *acpi_dev;
+ struct acpi_video_bus *video;
+ struct acpi_video_device *dev, *next;
+
+ if (acpi_bus_get_device(handle, &acpi_dev))
+ return AE_OK;
+
+ if (acpi_match_device_ids(acpi_dev, video_device_ids))
+ return AE_OK;
+
+ video = acpi_driver_data(acpi_dev);
+ if (!video)
+ return AE_OK;
+
+ acpi_video_bus_stop_devices(video);
+ mutex_lock(&video->device_list_lock);
+ list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
+ if (dev->backlight) {
+ backlight_device_unregister(dev->backlight);
+ dev->backlight = NULL;
+ kfree(dev->brightness->levels);
+ kfree(dev->brightness);
+ }
+ if (dev->cooling_dev) {
+ sysfs_remove_link(&dev->dev->dev.kobj,
+ "thermal_cooling");
+ sysfs_remove_link(&dev->cooling_dev->device.kobj,
+
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 66945] New: Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 Priority: medium Bug ID: 66945 Assignee: dri-devel@lists.freedesktop.org Summary: Heavy artifacts and unusable graphics system with the latest DPM changes Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: t...@slackeee.de Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Using the latest drm-fixes-3.11 and drm-next-3.11 I get heavy artifacts as soon as the radeon module is loaded, leaving my system unusable. Only the graphics system stops to work, SSH connections to the system still work. Hardware: Radeon HD6870 (01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts XT [ATI Radeon HD 6800 Series]) Software: Slackware -current I got these error messages from dmesg: [ 26.514278] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 26.514291] radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id 0x0001) [ 26.649947] radeon :01:00.0: Saved 119 dwords of commands on ring 0. [ 26.649969] radeon :01:00.0: GPU softreset: 0x0008 [ 26.649977] radeon :01:00.0: GRBM_STATUS = 0xA0003828 [ 26.649983] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 26.649989] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 26.649994] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 26.64] radeon :01:00.0: SRBM_STATUS2 = 0x [ 26.650004] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 26.650010] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x4100 [ 26.650015] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00020180 [ 26.650020] radeon :01:00.0: R_008680_CP_STAT = 0x80028042 [ 26.650026] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 26.661433] radeon :01:00.0: GRBM_SOFT_RESET=0x4001 [ 26.661490] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [ 26.662652] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 26.662657] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 26.662663] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 26.662668] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 26.662673] radeon :01:00.0: SRBM_STATUS2 = 0x [ 26.662679] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 26.662684] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 26.662689] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 26.662694] radeon :01:00.0: R_008680_CP_STAT = 0x [ 26.662700] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 26.662711] radeon :01:00.0: GPU reset succeeded, trying to resume [ 26.686572] radeon :01:00.0: WB enabled [ 26.686581] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x880429b6dc00 [ 26.686588] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x880429b6dc0c [ 26.688117] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc900112b2118 [ 26.920227] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) I attach a complete dmesg output and lspci output, If anything else is needed just ask me and I will do my best to get you the info. -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #1 from t...@slackeee.de --- Created attachment 82464 --> https://bugs.freedesktop.org/attachment.cgi?id=82464&action=edit dmesg output -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #2 from t...@slackeee.de --- Created attachment 82465 --> https://bugs.freedesktop.org/attachment.cgi?id=82465&action=edit lspci output -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #3 from Alex Deucher --- Are you using radeon as a module or built into the kernel? -- 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 66932] Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 --- Comment #2 from Alex Deucher --- (In reply to comment #0) > > I did a bisect and found that this commit introduced the corruption: > > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3. > 11&id=7ad8d0687bb5030c3328bc7229a3183ce179ab25 Prior to that commit, the driver didn't actually change clock levels. Does it work any better if you build radeon as a module rather than building it into the kernel? -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #4 from t...@slackeee.de --- I use it as a module. Will test it inbuilt ASAP, needs some minutes to compile. -- 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
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commits 19b2dbde5732
("drm/i915: Restore fences after resume and GPU resets") from Linus' tree
and d18b96190342 ("drm/i915: Fix incoherence with fence updates on
Sandybridge+") from the drm-intel-fixes tree and commits f343c5f64773
("drm/i915: Getter/setter for object attributes") and db1b76ca6a79
("drm/i915: don't frob mm.suspended when not using ums") from the
drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index 97afd26,20b10a0..000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -2666,27 -2673,12 +2665,27 @@@ static void i965_write_fence_reg(struc
fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
}
+ fence_reg += reg * 8;
+
+ /* To w/a incoherency with non-atomic 64-bit register updates,
+ * we split the 64-bit update into two 32-bit writes. In order
+ * for a partial fence not to be evaluated between writes, we
+ * precede the update with write to turn off the fence register,
+ * and only enable the fence as the last step.
+ *
+ * For extra levels of paranoia, we make sure each step lands
+ * before applying the next step.
+ */
+ I915_WRITE(fence_reg, 0);
+ POSTING_READ(fence_reg);
+
if (obj) {
- u32 size = obj->gtt_space->size;
+ u32 size = i915_gem_obj_ggtt_size(obj);
+ uint64_t val;
- val = (uint64_t)((obj->gtt_offset + size - 4096) &
+ val = (uint64_t)((i915_gem_obj_ggtt_offset(obj) + size - 4096) &
0xf000) << 32;
- val |= obj->gtt_offset & 0xf000;
+ val |= i915_gem_obj_ggtt_offset(obj) & 0xf000;
val |= (uint64_t)((obj->stride / 128) - 1) << fence_pitch_shift;
if (obj->tiling_mode == I915_TILING_Y)
val |= 1 << I965_FENCE_TILING_Y_SHIFT;
@@@ -3992,11 -4008,8 +3980,6 @@@ i915_gem_idle(struct drm_device *dev
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
- /* Hack! Don't let anybody do execbuf while we don't control the chip.
-* We need to replace this with a semaphore, or something.
-* And not confound mm.suspended!
-*/
- dev_priv->mm.suspended = 1;
- i915_gem_reset_fences(dev);
-
del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
i915_kernel_lost_context(dev);
pgpdnvqntfCLa.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #5 from t...@slackeee.de --- OK, took me some time to figure out that I also need the firmware inbuilt (and which one, isn't quite obvious that I need firmware from BARTS, BTC and SUMO to boot). Anyways, problem persists, same errors in dmesg. If you want to see how it actually looks, I have made a short video (sorry for the bad quality, need a better camera): http://slackeee.de/public/drm-next-3.11.mp4 -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #6 from Alex Deucher --- (In reply to comment #4) > I use it as a module. Will test it inbuilt ASAP, needs some minutes to > compile. Sorry, no need to do that, modules should be fine. Sometimes there are problems with firmware when the driver is built in. -- 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 58731] radeon_uvd: Can't load firmware "radeon/RV710_uvd.bin"
https://bugzilla.kernel.org/show_bug.cgi?id=58731 Adam J. Richter changed: What|Removed |Added CC||a...@yggdrasil.com --- Comment #5 from Adam J. Richter --- Please try remaking your initial ramdisk. -- 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 66945] Heavy artifacts and unusable graphics system with the latest DPM changes
https://bugs.freedesktop.org/show_bug.cgi?id=66945 --- Comment #7 from queryv...@gmail.com --- I have this issue too (same card), and I made a comment about it in one of the Phoronix threads mentioning that the problem started post wip-5 patch-set. Having read most of the other related threads, I've noticed that most/all owners who try enabling DPM with a 6870 run into this problem. If any other information is needed to find a commonality from whence this issue originates (separate from OPs), let me know an I'll attach the needed logs. -- 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 66932] Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 --- Comment #3 from Martin Andersson --- (In reply to comment #2) > (In reply to comment #0) > > > > I did a bisect and found that this commit introduced the corruption: > > > > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3. > > 11&id=7ad8d0687bb5030c3328bc7229a3183ce179ab25 > > Prior to that commit, the driver didn't actually change clock levels. > > Does it work any better if you build radeon as a module rather than building > it into the kernel? Well I think I'm already building radeon as a module since I have: CONFIG_DRM=m CONFIG_DRM_RADEON=m or am I missing something? -- 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: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Sat, 2013-07-13 at 02:46 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
>
> There's a problem with that approach, however, because simply
> avoiding to register the ACPI backlight interface if the firmware
> calls _OSI for Windows 8 may not work in the following situations:
> (1) The ACPI backlight interface actually works on the given system
> and the i915 driver is not loaded (e.g. another graphics driver
> is used).
> (2) The ACPI backlight interface doesn't work on the given system,
> but there is a vendor platform driver that will register its
> own, equally broken, backlight interface if not prevented from
> doing so by the ACPI subsystem.
> Therefore we need to allow the ACPI backlight interface to be
> registered until the i915 driver is loaded which then will unregister
> it if the firmware has called _OSI for Windows 8 (or will register
> the ACPI video driver without backlight support if not already
> present).
>
> For this reason, introduce an alternative function for registering
> ACPI video, acpi_video_register_with_quirks(), that will check
> whether or not the ACPI video driver has already been registered
> and whether or not the backlight Windows 8 quirk has to be applied.
> If the quirk has to be applied, it will block the ACPI backlight
> support and either unregister the backlight interface if the ACPI
> video driver has already been registered, or register the ACPI
> video driver without the backlight interface otherwise. Make
> the i915 driver use acpi_video_register_with_quirks() instead of
> acpi_video_register() in i915_driver_load().
>
> This change is based on earlier patches from Matthew Garrett,
> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/internal.h | 11 ++
> drivers/acpi/video.c| 65
>
> drivers/acpi/video_detect.c | 21
> drivers/gpu/drm/i915/i915_dma.c |2 -
> include/acpi/video.h| 11 ++
> include/linux/acpi.h|1
> 6 files changed, 103 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/acpi/video.c
> ===
> --- linux-pm.orig/drivers/acpi/video.c
> +++ linux-pm/drivers/acpi/video.c
> @@ -44,6 +44,8 @@
> #include
> #include
>
> +#include "internal.h"
> +
> #define PREFIX "ACPI: "
>
> #define ACPI_VIDEO_BUS_NAME "Video Bus"
> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> device->cap._DDC = 1;
> }
>
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_verify_backlight_support()) {
> struct backlight_properties props;
> struct pci_dev *pdev;
> acpi_handle acpi_parent;
> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> return 0;
> }
>
> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> + void *context, void **rv)
> +{
> + struct acpi_device *acpi_dev;
> + struct acpi_video_bus *video;
> + struct acpi_video_device *dev, *next;
> +
> + if (acpi_bus_get_device(handle, &acpi_dev))
> + return AE_OK;
> +
> + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> + return AE_OK;
> +
> + video = acpi_driver_data(acpi_dev);
> + if (!video)
> + return AE_OK;
> +
> + acpi_video_bus_stop_devices(video);
> + mutex_lock(&video->device_list_lock);
> + list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
> + if (dev->backlight) {
> + backlight_device_unregister(dev->backlight);
> + dev->backlight = NULL;
> + kfree(dev->brightness->levels);
> + kfree(dev->brightness);
> + }
> + if (dev->cooling_dev) {
> + sysfs_remove_link(&dev->dev->dev.kobj,
> + "thermal_cooling");
> + sysfs_remove_link(&dev->cooling_dev->device.kobj,
> + "device");
> + thermal_cooling_device_unregister(dev->cooling_dev);
> + dev->cooling_dev = NULL;
> + }
> + }
> + mutex_unlock(&video->device_list_lock);
> + acpi_video_bus_start_devices(video);
> + return AE_OK;
>
radeon: dpm - 3.11-rc1 positive report
Hi Alex, I just tested the new 3.11-rc1 and was very happy to find out that it reduces the idle temperature of my system by about 12 degrees (C). Thank you very much for this! Cheers, Eldad P.S. Just for reference, lspci output + dmesg below. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Thames [Radeon 7500M/7600M Series] (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device fb91 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon [0.00] Command line: root=/dev/sda6 video radeon.dpm=1 [0.00] Kernel command line: root=/dev/sda6 video radeon.dpm=1 [0.347877] [drm] radeon kernel modesetting enabled. [0.348701] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [0.348787] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF [0.352677] [drm] radeon: 1024M of VRAM memory ready [0.352750] [drm] radeon: 512M of GTT memory ready. [0.352876] radeon :01:00.0: 8802448bb400 unpin not necessary [0.446478] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc900114e6118 [0.447144] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [0.458577] radeon :01:00.0: WB enabled [0.458651] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x880244b61c00 [0.458739] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x880244b61c0c [0.460768] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00174118 and cpu addr 0xc90011d32118 [0.461042] radeon :01:00.0: irq 41 for MSI/MSI-X [0.461055] radeon :01:00.0: radeon: using MSI. [0.461155] [drm] radeon: irq initialized. [0.871099] [drm] radeon atom DIG backlight initialized [0.884248] [drm] radeon: dpm initialized [1.309272] fbcon: radeondrmfb (fb0) is primary device [1.868006] radeon :01:00.0: fb0: radeondrmfb frame buffer device [1.868043] radeon :01:00.0: registered panic notifier [1.868083] [drm] Initialized radeon 2.34.0 20080528 for :01:00.0 on minor 0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DT binding review for Armada display subsystem
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote: > Based on the outcomes of the "Best practice device tree design for display > subsystems" discussion I have drafted a DT binding. Comments much appreciated. > > At a high level, it uses a "super node" as something for the driver to bind > to, needed because there is no clear one device that controls all the > others, and also to distinguish between the Armada 510 possible use cases > of having one video card with two outputs, or two independent video cards. > It uses node-to-node linking beyond that point, V4L2 style. As this hasn't been shot down very far, I've started to implement the driver side of this binding. I have already run into a couple of little problems. First, interrupts. In the dt binding, each "lcd controller" node defines which interrupt it listens to, and in the armada 510 case there are indeed 2 interrupts (47 and 46, one for each LCD controller). And remember that the drm driver itself binds to the super-node. Looking at drm_irq_install(), it looks like DRM only supports 1 interrupt line per drm_device. As we have no known users who will want these two LCD controllers represented as 2 CRTCs on 1 DRM device (which would require management of 2 interrupt lines), I figured this might be a reason to ignore that use case for now (from the coding standpoint), meaning that in all cases we are left with each DRM device having 1 CRTC, corresponding to 1 LCD controller, which has exactly 1 interrupt line. That still doesn't solve the problem though. drm_irq_install calls into drm_platform to figure out which IRQ number to use, and that code looks at the platform_device (i.e. super node). In this case we don't have the irq info there, we have it in the "lcd controller" node. Do I invent our own "DRM bus" implementation so that we can override get_irq()? Start to standardise our DT design as a generic drm_dt.c bus implementation? Any thoughts? Secondly, devm. I understand from the "best practices" thread that we want to have exactly one platform_device which corresponds to the "super node", and all of the individual display controller components will be represented by DT nodes but *without* their own platform_device. As we now put things (clocks, interrupts) into DT nodes that don't have a corresponding platform_device, we lose the ability to use devm. Russell wasn't too pleased last time I posted a patch moving away from devm, admittedly last time the patch was bad and it wasn't necessary, but this time it looks like it might be. Finally, just curious, do we still want to support non-DT platform data type setups on this driver? That adds a bit of coding effort. Not a problem, just wanted to check. Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 07/15/2013 07:42 PM, Rafael J. Wysocki wrote:
> On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote:
>> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>>> to individual graphics drivers rather than making ACPI calls itself.
>>> There's plenty of evidence to suggest that the Intel driver for
>>> Windows [8] doesn't use the ACPI interface, including the fact that
>>> it's broken on a bunch of machines when the OS claims to support
>>> Windows 8. The simplest thing to do appears to be to disable the
>>> ACPI backlight interface on these systems".
>>>
>>> There's a problem with that approach, however, because simply
>>> avoiding to register the ACPI backlight interface if the firmware
>>> calls _OSI for Windows 8 may not work in the following situations:
>>> (1) The ACPI backlight interface actually works on the given system
>>> and the i915 driver is not loaded (e.g. another graphics driver
>>> is used).
>>> (2) The ACPI backlight interface doesn't work on the given system,
>>> but there is a vendor platform driver that will register its
>>> own, equally broken, backlight interface if not prevented from
>>> doing so by the ACPI subsystem.
>>> Therefore we need to allow the ACPI backlight interface to be
>>> registered until the i915 driver is loaded which then will unregister
>>> it if the firmware has called _OSI for Windows 8 (or will register
>>> the ACPI video driver without backlight support if not already
>>> present).
>>>
>>> For this reason, introduce an alternative function for registering
>>> ACPI video, acpi_video_register_with_quirks(), that will check
>>> whether or not the ACPI video driver has already been registered
>>> and whether or not the backlight Windows 8 quirk has to be applied.
>>> If the quirk has to be applied, it will block the ACPI backlight
>>> support and either unregister the backlight interface if the ACPI
>>> video driver has already been registered, or register the ACPI
>>> video driver without the backlight interface otherwise. Make
>>> the i915 driver use acpi_video_register_with_quirks() instead of
>>> acpi_video_register() in i915_driver_load().
>>>
>>> This change is based on earlier patches from Matthew Garrett,
>>> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>>>
>>> Signed-off-by: Rafael J. Wysocki
>>
>> Reviewed-by: Aaron Lu
>>
>> BTW, I also tested on a Toshiba laptop Z830 where its AML code
>> claims support of win8, the result is as expected: ACPI video
>> interface is removed, i915 Xorg driver picks intel_backlight.
>>
>> Thanks for the fix.
>
> Cool, thanks for testing this!
>
> Can you please also ask bug reporters in the BZ entires related to this to
> test
> it too?
Sure.
To be clear, I actually tested the patch in your linux-next branch,
which turned out to be a little different in that you have fixed the
problem Igor raised here.
I'll ask reporters to test on a stable tree with the following two
patches on top:
https://patchwork.kernel.org/patch/2812951/ (expose OSI version)
https://patchwork.kernel.org/patch/2827793/ (your updated patch)
or your linux-next branch, whichever they like.
-Aaron
>
> Rafael
>
>
>>> ---
>>> drivers/acpi/internal.h | 11 ++
>>> drivers/acpi/video.c| 65
>>>
>>> drivers/acpi/video_detect.c | 21
>>> drivers/gpu/drm/i915/i915_dma.c |2 -
>>> include/acpi/video.h| 11 ++
>>> include/linux/acpi.h|1
>>> 6 files changed, 103 insertions(+), 8 deletions(-)
>>>
>>> Index: linux-pm/drivers/acpi/video.c
>>> ===
>>> --- linux-pm.orig/drivers/acpi/video.c
>>> +++ linux-pm/drivers/acpi/video.c
>>> @@ -44,6 +44,8 @@
>>> #include
>>> #include
>>>
>>> +#include "internal.h"
>>> +
>>> #define PREFIX "ACPI: "
>>>
>>> #define ACPI_VIDEO_BUS_NAME"Video Bus"
>>> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
>>> device->cap._DDC = 1;
>>> }
>>>
>>> - if (acpi_video_backlight_support()) {
>>> + if (acpi_video_verify_backlight_support()) {
>>> struct backlight_properties props;
>>> struct pci_dev *pdev;
>>> acpi_handle acpi_parent;
>>> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
>>> return 0;
>>> }
>>>
>>> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
>>> + void *context, void **rv)
>>> +{
>>> + struct acpi_device *acpi_dev;
>>> + struct acpi_video_bus *video;
>>> + struct acpi_video_device *dev, *next;
>>> +
>>> + if (acpi_bus_get_device(handle, &acpi_dev))
>>> + return AE_OK;
>>> +
>>> + if (acpi_match_device_ids(acpi_dev, video_device_ids))
>>> + return AE_OK;
>>> +
>>> + video =
Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume
On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> Daniel Vetter wrote:
> >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> > wrote:
> >>This patch fixes regression in power consumtion of sandy bridge gpu, which
> >>exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking
> >>that
> >>it's extremely busy. After that it never reaches rc6 state.
> >>
> >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> >>("drm/i915: load boot context at driver init time"). Without documentation
> >>it's not clear what is happening here, probably this breaks internal state
> >>of
> >>hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
> >>during whole initialization sequence in gen6_init_clock_gating() fixes this
> >>bug.
> >>
> >>References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> >>Signed-off-by: Konstantin Khlebnikov
> >
> >We already hold an forcewake reference while setting up the rps stuff,
> >should we maybe hold the forcewake for the entire duration, i.e. grab
> >it here in clock_gating and release it only in gen6/vlv_enable_rps?
> >Can you please test that version, too?
>
> This will be racy because rps stuff is done in separate work which might be
> canceled
> if intel_disable_gt_powersave() happens before its completion.
Can be fixed with a flush_delayed_work. And since that has the same
requirements wrt locking to prevent deadlocks as cancel_work_sync it would
be a drop-in replacement. Can I volunteer you to look into testing that
out a bit? Otherwise I could volunteer someone from our team.
In any case I think we should apply this trick to all platforms where
we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works
_very_ similar on all of those.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume
On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote:
> This patch fixes regression in power consumtion of sandy bridge gpu, which
> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
> it's extremely busy. After that it never reaches rc6 state.
>
> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> ("drm/i915: load boot context at driver init time"). Without documentation
> it's not clear what is happening here, probably this breaks internal state of
> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
> during whole initialization sequence in gen6_init_clock_gating() fixes this
> bug.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> Signed-off-by: Konstantin Khlebnikov
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=58971
Tested-by: Alexander Kaltsas
Tested-by: rocko
> ---
> drivers/gpu/drm/i915/intel_pm.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index aa01128..839a43f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device
> *dev)
> int pipe;
> uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
>
> + gen6_gt_force_wake_get(dev_priv);
> +
> I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate);
>
> I915_WRITE(ILK_DISPLAY_CHICKEN2,
> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device
> *dev)
> cpt_init_clock_gating(dev);
>
> gen6_check_mch_setup(dev);
> +
> + gen6_gt_force_wake_put(dev_priv);
> }
>
> static void gen7_setup_fixed_func_scheduler(struct drm_i915_private
> *dev_priv)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #8 from Marek Ol??k --- I have found the problem. Wine is trying to use the GL_SRGB8_ALPHA8 format, which is not supported for rendering by the driver internally, but I agree the format should be allowed in the API. The fix is on the way. Is it a big deal that ARB_framebuffer_sRGB is unsupported? In such a case, the renderbuffer format GL_SRGB8_ALPHA8 is equivalent to GL_RGBA8. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/064b418f/attachment.html>
[Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
>
> There's a problem with that approach, however, because simply
> avoiding to register the ACPI backlight interface if the firmware
> calls _OSI for Windows 8 may not work in the following situations:
> (1) The ACPI backlight interface actually works on the given system
> and the i915 driver is not loaded (e.g. another graphics driver
> is used).
> (2) The ACPI backlight interface doesn't work on the given system,
> but there is a vendor platform driver that will register its
> own, equally broken, backlight interface if not prevented from
> doing so by the ACPI subsystem.
> Therefore we need to allow the ACPI backlight interface to be
> registered until the i915 driver is loaded which then will unregister
> it if the firmware has called _OSI for Windows 8 (or will register
> the ACPI video driver without backlight support if not already
> present).
>
> For this reason, introduce an alternative function for registering
> ACPI video, acpi_video_register_with_quirks(), that will check
> whether or not the ACPI video driver has already been registered
> and whether or not the backlight Windows 8 quirk has to be applied.
> If the quirk has to be applied, it will block the ACPI backlight
> support and either unregister the backlight interface if the ACPI
> video driver has already been registered, or register the ACPI
> video driver without the backlight interface otherwise. Make
> the i915 driver use acpi_video_register_with_quirks() instead of
> acpi_video_register() in i915_driver_load().
>
> This change is based on earlier patches from Matthew Garrett,
> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
BTW, I also tested on a Toshiba laptop Z830 where its AML code
claims support of win8, the result is as expected: ACPI video
interface is removed, i915 Xorg driver picks intel_backlight.
Thanks for the fix.
-Aaron
> ---
> drivers/acpi/internal.h | 11 ++
> drivers/acpi/video.c| 65
>
> drivers/acpi/video_detect.c | 21
> drivers/gpu/drm/i915/i915_dma.c |2 -
> include/acpi/video.h| 11 ++
> include/linux/acpi.h|1
> 6 files changed, 103 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/acpi/video.c
> ===
> --- linux-pm.orig/drivers/acpi/video.c
> +++ linux-pm/drivers/acpi/video.c
> @@ -44,6 +44,8 @@
> #include
> #include
>
> +#include "internal.h"
> +
> #define PREFIX "ACPI: "
>
> #define ACPI_VIDEO_BUS_NAME "Video Bus"
> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> device->cap._DDC = 1;
> }
>
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_verify_backlight_support()) {
> struct backlight_properties props;
> struct pci_dev *pdev;
> acpi_handle acpi_parent;
> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> return 0;
> }
>
> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> + void *context, void **rv)
> +{
> + struct acpi_device *acpi_dev;
> + struct acpi_video_bus *video;
> + struct acpi_video_device *dev, *next;
> +
> + if (acpi_bus_get_device(handle, &acpi_dev))
> + return AE_OK;
> +
> + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> + return AE_OK;
> +
> + video = acpi_driver_data(acpi_dev);
> + if (!video)
> + return AE_OK;
> +
> + acpi_video_bus_stop_devices(video);
> + mutex_lock(&video->device_list_lock);
> + list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
> + if (dev->backlight) {
> + backlight_device_unregister(dev->backlight);
> + dev->backlight = NULL;
> + kfree(dev->brightness->levels);
> + kfree(dev->brightness);
> + }
> + if (dev->cooling_dev) {
> + sysfs_remove_link(&dev->dev->dev.kobj,
> + "thermal_cooling");
> + sysfs_remove_link(&dev->cooling_dev->device.kobj,
> + "device");
> + thermal_cooling_
[PATCH] drm/nouveau: kill nouveau_ttm_fault_reserve_notify handler to prevent useless buffer moves
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
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.
Ben.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index d506da5..86eb321 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1339,34 +1339,6 @@ nouveau_ttm_io_mem_free(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> }
>
> static int
> -nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
> -{
> - struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> - struct nouveau_bo *nvbo = nouveau_bo(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 (bo->mem.mem_type != TTM_PL_VRAM) {
> - if (nv_device(drm->device)->card_type < NV_50 ||
> - !nouveau_bo_tile_layout(nvbo))
> - return 0;
> - }
> -
> - /* make sure bo is in mappable vram */
> - if (bo->mem.start + bo->mem.num_pages < mappable)
> - return 0;
> -
> -
> - nvbo->placement.fpfn = 0;
> - nvbo->placement.lpfn = mappable;
> - nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0);
> - return nouveau_bo_validate(nvbo, false, false);
> -}
> -
> -static int
> nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> {
> struct ttm_dma_tt *ttm_dma = (void *)ttm;
> @@ -1524,7 +1496,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
> .sync_obj_flush = nouveau_bo_fence_flush,
> .sync_obj_unref = nouveau_bo_fence_unref,
> .sync_obj_ref = nouveau_bo_fence_ref,
> - .fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
> .io_mem_reserve = &nouveau_ttm_io_mem_reserve,
> .io_mem_free = &nouveau_ttm_io_mem_free,
> };
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64850] Second screen black on Pitcairn PRO
https://bugs.freedesktop.org/show_bug.cgi?id=64850 --- Comment #24 from Jakob Nixdorf --- Update: Problem still exists on kernel 3.11-rc1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/1cf5386d/attachment.html>
[PATCH] drm/nouveau: do not move buffers when not needed
Op 15-07-13 08:05, Ben Skeggs schreef:
> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
> 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.
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
---
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;
/* make sure bo is in mappable vram */
if (bo->mem.start + bo->mem.num_pages < mappable)
[PATCH 1/2] drm/radeon: allow selection of alignment in the sub-allocator
Am 12.07.2013 23:51, schrieb alexdeucher at gmail.com:
> From: Alex Deucher
>
> There are cases where we need more than 4k alignment. No
> functional change with this commit.
>
> Signed-off-by: Alex Deucher
This series is: Reviewed-by: Christian K?nig
Out of curiosity: Where did you find that info? I looked for it quite a
bit while working on page table directories and couldn't find anything.
Christian.
> ---
> drivers/gpu/drm/radeon/radeon.h|1 +
> drivers/gpu/drm/radeon/radeon_gart.c |1 +
> drivers/gpu/drm/radeon/radeon_object.h |2 +-
> drivers/gpu/drm/radeon/radeon_ring.c |1 +
> drivers/gpu/drm/radeon/radeon_sa.c |7 ---
> 5 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 6fe4b1c..39d2ce6 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -455,6 +455,7 @@ struct radeon_sa_manager {
> uint64_tgpu_addr;
> void*cpu_ptr;
> uint32_tdomain;
> + uint32_talign;
> };
>
> struct radeon_sa_bo;
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 43ec4a4..5ce190b 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -467,6 +467,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
> size *= 2;
> r = radeon_sa_bo_manager_init(rdev,
> &rdev->vm_manager.sa_manager,
> RADEON_GPU_PAGE_ALIGN(size),
> + RADEON_GPU_PAGE_SIZE,
> RADEON_GEM_DOMAIN_VRAM);
> if (r) {
> dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 91519a5..49c82c4 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -174,7 +174,7 @@ static inline void * radeon_sa_bo_cpu_addr(struct
> radeon_sa_bo *sa_bo)
>
> extern int radeon_sa_bo_manager_init(struct radeon_device *rdev,
>struct radeon_sa_manager *sa_manager,
> - unsigned size, u32 domain);
> + unsigned size, u32 align, u32 domain);
> extern void radeon_sa_bo_manager_fini(struct radeon_device *rdev,
> struct radeon_sa_manager *sa_manager);
> extern int radeon_sa_bo_manager_start(struct radeon_device *rdev,
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 5f1c51a..fb5ea62 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -224,6 +224,7 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
> }
> r = radeon_sa_bo_manager_init(rdev, &rdev->ring_tmp_bo,
> RADEON_IB_POOL_SIZE*64*1024,
> + RADEON_GPU_PAGE_SIZE,
> RADEON_GEM_DOMAIN_GTT);
> if (r) {
> return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
> b/drivers/gpu/drm/radeon/radeon_sa.c
> index 0abe5a9..f0bac68 100644
> --- a/drivers/gpu/drm/radeon/radeon_sa.c
> +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> @@ -49,7 +49,7 @@ static void radeon_sa_bo_try_free(struct radeon_sa_manager
> *sa_manager);
>
> int radeon_sa_bo_manager_init(struct radeon_device *rdev,
> struct radeon_sa_manager *sa_manager,
> - unsigned size, u32 domain)
> + unsigned size, u32 align, u32 domain)
> {
> int i, r;
>
> @@ -57,13 +57,14 @@ int radeon_sa_bo_manager_init(struct radeon_device *rdev,
> sa_manager->bo = NULL;
> sa_manager->size = size;
> sa_manager->domain = domain;
> + sa_manager->align = align;
> sa_manager->hole = &sa_manager->olist;
> INIT_LIST_HEAD(&sa_manager->olist);
> for (i = 0; i < RADEON_NUM_RINGS; ++i) {
> INIT_LIST_HEAD(&sa_manager->flist[i]);
> }
>
> - r = radeon_bo_create(rdev, size, RADEON_GPU_PAGE_SIZE, true,
> + r = radeon_bo_create(rdev, size, align, true,
>domain, NULL, &sa_manager->bo);
> if (r) {
> dev_err(rdev->dev, "(%d) failed to allocate bo for manager\n",
> r);
> @@ -317,7 +318,7 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
> unsigned tries[RADEON_NUM_RINGS];
> int i, r;
>
> - BUG_ON(align > RADEON_GPU_PAGE_SIZE);
> + BUG_ON(align > sa_manager->align);
> BUG_ON(size > sa_manager->size);
>
> *sa_bo = kmalloc(sizeof(struct radeon_sa_bo), GFP_KERNEL);
[BUG] radeon: suspend resume
[ The radeon driver is discussed on the dri-devel mailing list, moving there ] On Son, 2013-07-14 at 13:26 +0100, Sami Kerola wrote: > > Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup > CP stall for more than 1msec > Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup > (waiting for 0x0004 last fence id 0x0002) > Jul 14 12:51:31 kerolasa-home kernel: [drm:r600_uvd_ib_test] *ERROR* > radeon: fence wait failed (-35). > Jul 14 12:51:31 kerolasa-home kernel: [drm:radeon_ib_ring_tests] > *ERROR* radeon: failed testing IB on ring 5 (-35). Looks like the patch from https://bugs.freedesktop.org/show_bug.cgi?id=66425 might help. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #67 from Michel D?nzer --- (In reply to comment #66) > While I'm the one who opened this bug, on my side I'm able to run all piglit > tests without any hangs since awhile now. Even with GPU virtual memory enabled? If so, this report can be resolved as fixed? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/3fd68d04/attachment-0001.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #68 from udo --- I still use RADEON_VA=0 to avoid GPU lockups etc. Was anything changed so there's reason to test with RADEON_VA=1? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/0820c103/attachment.html>
[Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote:
> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > According to Matthew Garrett, "Windows 8 leaves backlight control up
> > to individual graphics drivers rather than making ACPI calls itself.
> > There's plenty of evidence to suggest that the Intel driver for
> > Windows [8] doesn't use the ACPI interface, including the fact that
> > it's broken on a bunch of machines when the OS claims to support
> > Windows 8. The simplest thing to do appears to be to disable the
> > ACPI backlight interface on these systems".
> >
> > There's a problem with that approach, however, because simply
> > avoiding to register the ACPI backlight interface if the firmware
> > calls _OSI for Windows 8 may not work in the following situations:
> > (1) The ACPI backlight interface actually works on the given system
> > and the i915 driver is not loaded (e.g. another graphics driver
> > is used).
> > (2) The ACPI backlight interface doesn't work on the given system,
> > but there is a vendor platform driver that will register its
> > own, equally broken, backlight interface if not prevented from
> > doing so by the ACPI subsystem.
> > Therefore we need to allow the ACPI backlight interface to be
> > registered until the i915 driver is loaded which then will unregister
> > it if the firmware has called _OSI for Windows 8 (or will register
> > the ACPI video driver without backlight support if not already
> > present).
> >
> > For this reason, introduce an alternative function for registering
> > ACPI video, acpi_video_register_with_quirks(), that will check
> > whether or not the ACPI video driver has already been registered
> > and whether or not the backlight Windows 8 quirk has to be applied.
> > If the quirk has to be applied, it will block the ACPI backlight
> > support and either unregister the backlight interface if the ACPI
> > video driver has already been registered, or register the ACPI
> > video driver without the backlight interface otherwise. Make
> > the i915 driver use acpi_video_register_with_quirks() instead of
> > acpi_video_register() in i915_driver_load().
> >
> > This change is based on earlier patches from Matthew Garrett,
> > Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
> >
> > Signed-off-by: Rafael J. Wysocki
>
> Reviewed-by: Aaron Lu
>
> BTW, I also tested on a Toshiba laptop Z830 where its AML code
> claims support of win8, the result is as expected: ACPI video
> interface is removed, i915 Xorg driver picks intel_backlight.
>
> Thanks for the fix.
Cool, thanks for testing this!
Can you please also ask bug reporters in the BZ entires related to this to test
it too?
Rafael
> > ---
> > drivers/acpi/internal.h | 11 ++
> > drivers/acpi/video.c| 65
> >
> > drivers/acpi/video_detect.c | 21
> > drivers/gpu/drm/i915/i915_dma.c |2 -
> > include/acpi/video.h| 11 ++
> > include/linux/acpi.h|1
> > 6 files changed, 103 insertions(+), 8 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/video.c
> > ===
> > --- linux-pm.orig/drivers/acpi/video.c
> > +++ linux-pm/drivers/acpi/video.c
> > @@ -44,6 +44,8 @@
> > #include
> > #include
> >
> > +#include "internal.h"
> > +
> > #define PREFIX "ACPI: "
> >
> > #define ACPI_VIDEO_BUS_NAME"Video Bus"
> > @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> > device->cap._DDC = 1;
> > }
> >
> > - if (acpi_video_backlight_support()) {
> > + if (acpi_video_verify_backlight_support()) {
> > struct backlight_properties props;
> > struct pci_dev *pdev;
> > acpi_handle acpi_parent;
> > @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> > return 0;
> > }
> >
> > +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> > + void *context, void **rv)
> > +{
> > + struct acpi_device *acpi_dev;
> > + struct acpi_video_bus *video;
> > + struct acpi_video_device *dev, *next;
> > +
> > + if (acpi_bus_get_device(handle, &acpi_dev))
> > + return AE_OK;
> > +
> > + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> > + return AE_OK;
> > +
> > + video = acpi_driver_data(acpi_dev);
> > + if (!video)
> > + return AE_OK;
> > +
> > + acpi_video_bus_stop_devices(video);
> > + mutex_lock(&video->device_list_lock);
> > + list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
> > + if (dev->backlight) {
> > + backlight_device_unregister(dev->backlight);
> > + dev->backlight = NULL;
> > + kfree(dev->brightness->levels);
> > + kfree(dev->brightness);
>
[PATCH 1/1] drm/cma: Replace PTR_RET with PTR_ERR_OR_ZERO
PTR_RET is now deprecated. Use PTR_ERR_OR_ZERO instead. Signed-off-by: Sachin Kamat --- Compile tested and based on the following tree: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git (PTR_RET) Dependent on [1] [1] http://lkml.indiana.edu/hypermail/linux/kernel/1306.2/00010.html --- drivers/gpu/drm/drm_gem_cma_helper.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index ece72a8..61c1d17 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -215,7 +215,7 @@ int drm_gem_cma_dumb_create(struct drm_file *file_priv, cma_obj = drm_gem_cma_create_with_handle(file_priv, dev, args->size, &args->handle); - return PTR_RET(cma_obj); + return PTR_ERR_OR_ZERO(cma_obj); } EXPORT_SYMBOL_GPL(drm_gem_cma_dumb_create); -- 1.7.9.5
[Bug 66920] New: [llvm backend] flashing textures, no lights in car , no water on GTA IV
https://bugs.freedesktop.org/show_bug.cgi?id=66920 Priority: medium Bug ID: 66920 Assignee: dri-devel at lists.freedesktop.org Summary: [llvm backend] flashing textures, no lights in car , no water on GTA IV Severity: normal Classification: Unclassified OS: Linux (All) Reporter: son_of_the_osiris at interia.pl Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I just tried sb backend with GTA IV on wine and must say that it works better than llvm. With llvm I have black rectangle instead of car lights and same with water. Also I seen some flashing textures.When enable R600_DEBUG-sb,nollvm game run little faster and without graphics problem. Kernel 3.10 wine 1.6rc5 mesa - git compiled with : --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r600 \ --with-dri-drivers= \ --with-llvm-shared-libs \ --enable-gallium-llvm \ --enable-r600-llvm-compiler \ --enable-xvmc \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm,wayland \ --enable-shared-glapi \ --enable-gbm \ --enable-glx-tls \ --enable-opencl \ --disable-debug \ --disable-osmesa \ --enable-gles1 \ --enable-gles2 \ --enable-texture-float \ --disable-xa \ --enable-vdpau \ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/ea759b2d/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #69 from Marek Ol??k --- (In reply to comment #67) > (In reply to comment #66) > > While I'm the one who opened this bug, on my side I'm able to run all piglit > > tests without any hangs since awhile now. > > Even with GPU virtual memory enabled? If so, this report can be resolved as > fixed? This bug has been fixed by the kernel patch 466476dfdcafbb4286ffa232a3a792731b9dc852 for quite a long time as far as 3D support is concerned. Some say that OpenCL still locks up, but I think that's a different issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/24f0f62d/attachment-0001.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #70 from udo --- Tom Stellard advised me not to use virtual memory, first by patch and later with RADEON_VA=0 as OpenCL started to work for Cayman (ARUBA here in A10-5800K) graphics. Which bug to see for virtual memory and OpenCL? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/a1abf665/attachment.html>
[Bug 66921] New: [r300g] Heroes of Newerth: HiZ related corruption
https://bugs.freedesktop.org/show_bug.cgi?id=66921 Priority: medium Bug ID: 66921 Keywords: regression Assignee: dri-devel at lists.freedesktop.org Summary: [r300g] Heroes of Newerth: HiZ related corruption Severity: normal Classification: Unclassified OS: All Reporter: pavel.ondracka at email.cz URL: http://www.heroesofnewerth.com/download/ Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 82440 --> https://bugs.freedesktop.org/attachment.cgi?id=82440&action=edit screenshot In Heroes of Newerth, there is massive black corruption over top half of screen anytime, when you move mouse over some game objects, like buildings. This is HiZ related and goes away when RADEON_DEBUG=nohiz is set. I also found out that it goes away completely when I revert commit 631c631cbf5b7e84e42a7cfffa1c206d63143370 Author: Marek Ol??k Date: Fri May 13 02:26:08 2011 +0200 r300g: allow HiZ with a 16-bit zbuffer HoN is free to play, however I can make an apitrace if needed. GPU:RV530 (R520 also affected) Mesa: b616d0166158872a135153e27c391424fe655117 Kernel: 3.9.4-200.fc18.i686 libdrm: f8f1f6e37ae2c3eb4a9c045ba3294b3ccf926c07 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/479db5cb/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #71 from Alexandre Demers --- (In reply to comment #67) > (In reply to comment #66) > > While I'm the one who opened this bug, on my side I'm able to run all piglit > > tests without any hangs since awhile now. > > Even with GPU virtual memory enabled? If so, this report can be resolved as > fixed? I'll have to double check, but from what I remember, yes even with VM enabled. But I'm not playing with OpenCL. It's just that I was seeing new CCers being added and this bug is still open because Udo was experiencing a problem that looked like the current bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/9a186e07/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #72 from udo --- I can see if the bug is still present (aside from OpenCL usage) in normal desktop usage (mail, web, youtube, etc). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/89bfa488/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #73 from Michel D?nzer --- (In reply to comment #71) > It's just that I was seeing new CCers being added and this bug is still open > because Udo was experiencing a problem that looked like the current bug. As you said, you're the reporter of this bug. If the problem you reported here is fixed, please resolve it accordingly. If Udo is still having problems, he should file his own report. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/73851549/attachment.html>
[Bug 66932] New: Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 Priority: medium Bug ID: 66932 Assignee: dri-devel at lists.freedesktop.org Summary: Screen corruption on Cayman with dpm enabled Severity: normal Classification: Unclassified OS: Linux (All) Reporter: g02maran at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 82448 --> https://bugs.freedesktop.org/attachment.cgi?id=82448&action=edit dmesg When I enable dpm with my 6950 I see major screen corruption. It works fine with dpm disabled. The computer does not get completely locked up. The screen flickers but there is always a pattern in the corruption that stays the same. Sometimes, not always, I can see and control a corrupted mouse cursor. But the screen is so corrupted that i can't login or do anything. I can ssh into the computer but it won't reboot. I first tried 3.11-rc1 but then did my tests on http://cgit.freedesktop.org/~agd5f/linux/?h=drm-fixes-3.11 with latest commit being a01c34f72e7cd2624570818f579b5ab464f93de2 I have ucode (downloaded 2013-06-15) from http://people.freedesktop.org/~agd5f/radeon_ucode/ I compiled the kernel with this. CONFIG_EXTRA_FIRMWARE="radeon/CAYMAN_mc.bin radeon/CAYMAN_me.bin radeon/CAYMAN_pfp.bin radeon/CAYMAN_rlc.bin radeon/CAYMAN_smc.bin radeon/SUMO_uvd.bin" I did a bisect and found that this commit introduced the corruption: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=7ad8d0687bb5030c3328bc7229a3183ce179ab25 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/a5759db4/attachment-0001.html>
[Bug 66932] Screen corruption on Cayman with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=66932 --- Comment #1 from Martin Andersson --- Created attachment 82449 --> https://bugs.freedesktop.org/attachment.cgi?id=82449&action=edit screenshot of corruption -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/2ad162d4/attachment.html>
[Bug 64850] Second screen black on Pitcairn PRO
https://bugs.freedesktop.org/show_bug.cgi?id=64850 Alex Deucher changed: What|Removed |Added CC||me at elemc.name --- Comment #25 from Alex Deucher --- *** Bug 66934 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/2b9309a1/attachment.html>
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #13 from Tom Stellard --- (In reply to comment #9) > The piglit test should work with this patch: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130624/179364. > html > > But we should still try to fix the bug in libclc. I've just pushed this patch. What is the status of this bug with your vstore/vload fixes? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/964679c6/attachment.html>
[Bug 66940] New: Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 Priority: medium Bug ID: 66940 Assignee: dri-devel at lists.freedesktop.org Summary: Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next) Severity: normal Classification: Unclassified OS: All Reporter: mail at 3v1n0.net Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 82459 --> https://bugs.freedesktop.org/attachment.cgi?id=82459&action=edit dmesg I've tried running linux 3.11 from both linus and drm_next branches, but when using the radeon drivers it's impossible to resume from suspension. It's quite sure that the problem is in radeon module, because unloading it (and switching to my intel card with vgaswitcheroo) works fine. Also, enabling the pm_trace sys-node it highlights that the radeon device caused the freeze: from dmesg: [1.286810] Magic number: 0:660:725 [1.286815] hash matches /home/marco/Dev/debs/linux/drivers/base/power/main.c:575 [1.286829] block loop5: hash matches [1.286867] pci :01:00.0: hash matches ^ This is the PCI id of my radeon card cat /sys/power/pm_trace_dev_match: block radeon This is a regression, since linux 3.10 works well. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/e20da46b/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #1 from Marco Trevisan (Trevi?o) --- Created attachment 82460 --> https://bugs.freedesktop.org/attachment.cgi?id=82460&action=edit /proc/acpi/wakeup -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/18192189/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #2 from Marco Trevisan (Trevi?o) --- Created attachment 82461 --> https://bugs.freedesktop.org/attachment.cgi?id=82461&action=edit /sys/power/pm_trace_dev_match -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/875131e2/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 Marco Trevisan (Trevi?o) changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/b143ca2e/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #74 from Alexandre Demers --- (In reply to comment #73) > (In reply to comment #71) > > It's just that I was seeing new CCers being added and this bug is still open > > because Udo was experiencing a problem that looked like the current bug. > > As you said, you're the reporter of this bug. If the problem you reported > here is fixed, please resolve it accordingly. If Udo is still having > problems, he should file his own report. Then fixed and closed it is. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/67d15f45/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #3 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/66fcda84/attachment-0001.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #4 from Marco Trevisan (Trevi?o) --- (In reply to comment #3) > Can you bisect? I can do that, but in few days... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/284cbde6/attachment.html>
[Bug 66942] New: Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 Priority: medium Bug ID: 66942 Assignee: dri-devel at lists.freedesktop.org Summary: Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next Severity: major Classification: Unclassified OS: All Reporter: alexandre.f.demers at gmail.com Hardware: All Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I just compiled and tested kernel 3.11.0-rc1. It hangs and do nothing when initializing (last thing displayed is "Loading initial ramdisk"). Setting radeon.dpm=1 or 0 gives the same result. Since I know I'm also experiencing this hang with last week drm-next branch, I'll try to bisect and see where it leads us. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/988b9740/attachment.html>
[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #1 from Alexandre Demers --- As a side note, it could be related to bug 66940 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/62d9d43d/attachment.html>
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #5 from hadack at gmx.de --- Any news on this one? Its really bad on radeonsi, since theres no workaround. Still happens with llvm and mesa from git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/22feeb4d/attachment.html>
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #14 from Aaron Watry --- I still get errors with the v8i32/v16i32 loads, but those aren't currently enabled in the R600 or SI back-ends as far as I know. If I comment out the vload8 and vload16 tests everything runs correctly for me on my 7850 with git master llvm/clang and my vload/vstore changes for libclc. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/fe1f8d45/attachment.html>
[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #2 from Alex Deucher --- probably a duplicate of bug 66551. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/07ab054b/attachment.html>
DT binding review for Armada display subsystem
Hi, On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote: > On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote: > > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote: > >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote: > >>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it > >>> seems they're working on v4 with clock object reference counting. > >>> Presumably we need both clk_get() to be taking reference on the > >>> module and reference counted clk free, e.g. in cases where clock > >>> provider is a hot-pluggable device. It might be too paranoid > >>> though, I haven't seen hardware configurations where a clock source > >>> could be unplugged safely when whole system is running. > >> > >> I'm not going to accept refcounting being thrown into clk_get(). The > >> clkdev API already has refcounting, as much as it needs to. It just > >> needs people to use the hooks that I provided back in 2008 when I > >> created the clkdev API for doing _precisely_ this job. > >> > >> Have a read through these commits, which backup my statement above: > >> > >> 0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the > >> clkdev API d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting > >> Integrator to clkdev API > >> > >> and it will show you how to do refcounting. The common clk API just > >> needs to stop defining __clk_get() and __clk_put() to be an empty > >> function and implement them appropriately for it's clk > >> implementation, > >> like they were always meant to be. > > > > Sure, I've already seen the above commits. This is how I understood it > > as well - __clk_get(), __clk_put() need to be defined by the common > > clk > > API, since it is going to replace all the arch specific > > implementations.> > >> __clk_get() and __clk_put() are the clk-implementation specific parts > >> of the clkdev API, because the clkdev API is utterly divorsed from > >> the > >> internals of what a 'struct clk' actually is. clkdev just treats a > >> 'struct clk' as a completely opaque type and never bothers poking > >> about inside it. > > > > OK, but at the clock's implementation side we may need, e.g. to use > > kref to keep track of the clock's state, and free it only when it is > > unprepared, all its children are unregistered, etc. ? Is it not what > > you stated in your comment to patch [1] ? > > If you want to do refcounting on a clock (which you run into problems > as I highlighted earlier in this thread) then yes, you need to use a > kref, and take a reference in __clk_get() and drop it in __clk_put() > to make things safe. > > Whether you also take a reference on the module supplying the clock or > not depends whether you need to keep the code around to manipulate that > clock while there are users of it. > > As I've already said - consider the possibilities with this scenario. > Here's one: > > A clock consumer is using a clock, but the clock supplier has been > removed. The clock consumer wants to change the state of the clock > in some way - eg, system is suspending. clk_disable() doesn't fail, > but on resume, clk_enable() does... (and how many people assume that > clk_enable() never fails?) And who knows what rate the clock is now > producing or whether it's even producing anything... > > I'm not saying don't do the refcounting thing I mentioned back in June. > I'm merely pointing out the issues that there are. There isn't a one > right answer here because each has their own advantages and > disadvantages (and problems.) What about having Mike on CC for such clock-related discussion? Best regards, Tomasz
[pull] radeon drm-fixes-3.11
From: Alex Deucher Hi Dave, Bug fixes for radeon all over the place. Big one is a fix for ttm which causes hangs on boot for a number of systems. The following changes since commit 774d8e34e46506222bb5e2888e3ef42b2775715f: Merge branch 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux into drm-next (2013-07-09 10:49:39 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.11 Alex Deucher (11): drm/radeon/hdmi: make sure we have an afmt block assigned drm/radeon/dpm: disable gfx PG on PALM drm/radeon: Disable dma rings for bo moves on r6xx drm/radeon: implement bo copy callback using CP DMA (v2) drm/radeon: use CP DMA on r6xx for bo moves drm/radeon: add fault decode function for cayman/TN (v2) drm/radeon: add fault decode function for SI (v2) drm/radeon: add fault decode function for CIK drm/radeon: allow selection of alignment in the sub-allocator drm/radeon: align VM PTBs (Page Table Blocks) to 32K drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level Christian K?nig (2): drm/radeon: fix UVD fence emit drm/radeon: never unpin UVD bo v3 Jerome Glisse (1): drm/radeon: use radeon device for request firmware Maarten Lankhorst (1): drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate Sergey Senozhatsky (1): radeon kms: do not flush uninitialized hotplug work drivers/gpu/drm/radeon/cik.c| 59 --- drivers/gpu/drm/radeon/cikd.h | 16 ++ drivers/gpu/drm/radeon/evergreen.c | 10 +- drivers/gpu/drm/radeon/evergreen_hdmi.c |6 + drivers/gpu/drm/radeon/ni.c | 182 +-- drivers/gpu/drm/radeon/nid.h| 16 ++ drivers/gpu/drm/radeon/r100.c | 11 +- drivers/gpu/drm/radeon/r600.c | 102 +-- drivers/gpu/drm/radeon/r600_hdmi.c |6 + drivers/gpu/drm/radeon/r600d.h |1 + drivers/gpu/drm/radeon/radeon.h |9 +- drivers/gpu/drm/radeon/radeon_asic.c| 12 +- drivers/gpu/drm/radeon/radeon_asic.h|3 + drivers/gpu/drm/radeon/radeon_fence.c |2 +- drivers/gpu/drm/radeon/radeon_gart.c| 11 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 11 +- drivers/gpu/drm/radeon/radeon_object.c |1 + drivers/gpu/drm/radeon/radeon_object.h |2 +- drivers/gpu/drm/radeon/radeon_ring.c|1 + drivers/gpu/drm/radeon/radeon_sa.c |7 +- drivers/gpu/drm/radeon/radeon_uvd.c | 111 +--- drivers/gpu/drm/radeon/rv770.c |2 +- drivers/gpu/drm/radeon/si.c | 295 +-- drivers/gpu/drm/radeon/sid.h| 14 ++ drivers/gpu/drm/radeon/sumo_dpm.c | 14 ++- 25 files changed, 733 insertions(+), 171 deletions(-)
DT binding review for Armada display subsystem
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote: > On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote: > > Based on the outcomes of the "Best practice device tree design for display > > subsystems" discussion I have drafted a DT binding. Comments much > > appreciated. > > > > At a high level, it uses a "super node" as something for the driver to bind > > to, needed because there is no clear one device that controls all the > > others, and also to distinguish between the Armada 510 possible use cases > > of having one video card with two outputs, or two independent video cards. > > It uses node-to-node linking beyond that point, V4L2 style. > > As this hasn't been shot down very far, I've started to implement the > driver side of this binding. I have already run into a couple of > little problems. > > First, interrupts. In the dt binding, each "lcd controller" node > defines which interrupt it listens to, and in the armada 510 case > there are indeed 2 interrupts (47 and 46, one for each LCD > controller). And remember that the drm driver itself binds to the > super-node. > > Looking at drm_irq_install(), it looks like DRM only supports 1 > interrupt line per drm_device. You don't have to call drm_irq_install(). Both the exynos and i.MX driver do without it and at least the i.MX driver uses multiple irqs per drm_device. > > Secondly, devm. I understand from the "best practices" thread that we > want to have exactly one platform_device which corresponds to the > "super node", and all of the individual display controller components > will be represented by DT nodes but *without* their own > platform_device. A super node approach doesn't mean that there's only one platform device. You can still have a platform device for each component. The super node should rather be seen as a node which contains phandles to the different components.. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 66921] [r300g] Heroes of Newerth: HiZ related corruption
https://bugs.freedesktop.org/show_bug.cgi?id=66921 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marek Ol??k --- Okay, I have reverted the commit. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/b5c2a76c/attachment.html>
[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #3 from Alexandre Demers --- (In reply to comment #2) > probably a duplicate of bug 66551. Probably not, the bug happens prior to the commit identified in bug 66551. I'm bisecting as we are talking. I also noticed a small glitch that was not in kernel 3.9 but is present in 3.10 that I'll report in another bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/a6afba77/attachment.html>
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130715/3ea3f35f/attachment.html>
[Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Sat, 2013-07-13 at 02:46 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
>
> There's a problem with that approach, however, because simply
> avoiding to register the ACPI backlight interface if the firmware
> calls _OSI for Windows 8 may not work in the following situations:
> (1) The ACPI backlight interface actually works on the given system
> and the i915 driver is not loaded (e.g. another graphics driver
> is used).
> (2) The ACPI backlight interface doesn't work on the given system,
> but there is a vendor platform driver that will register its
> own, equally broken, backlight interface if not prevented from
> doing so by the ACPI subsystem.
> Therefore we need to allow the ACPI backlight interface to be
> registered until the i915 driver is loaded which then will unregister
> it if the firmware has called _OSI for Windows 8 (or will register
> the ACPI video driver without backlight support if not already
> present).
>
> For this reason, introduce an alternative function for registering
> ACPI video, acpi_video_register_with_quirks(), that will check
> whether or not the ACPI video driver has already been registered
> and whether or not the backlight Windows 8 quirk has to be applied.
> If the quirk has to be applied, it will block the ACPI backlight
> support and either unregister the backlight interface if the ACPI
> video driver has already been registered, or register the ACPI
> video driver without the backlight interface otherwise. Make
> the i915 driver use acpi_video_register_with_quirks() instead of
> acpi_video_register() in i915_driver_load().
>
> This change is based on earlier patches from Matthew Garrett,
> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/internal.h | 11 ++
> drivers/acpi/video.c| 65
>
> drivers/acpi/video_detect.c | 21
> drivers/gpu/drm/i915/i915_dma.c |2 -
> include/acpi/video.h| 11 ++
> include/linux/acpi.h|1
> 6 files changed, 103 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/acpi/video.c
> ===
> --- linux-pm.orig/drivers/acpi/video.c
> +++ linux-pm/drivers/acpi/video.c
> @@ -44,6 +44,8 @@
> #include
> #include
>
> +#include "internal.h"
> +
> #define PREFIX "ACPI: "
>
> #define ACPI_VIDEO_BUS_NAME "Video Bus"
> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
> device->cap._DDC = 1;
> }
>
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_verify_backlight_support()) {
> struct backlight_properties props;
> struct pci_dev *pdev;
> acpi_handle acpi_parent;
> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
> return 0;
> }
>
> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> + void *context, void **rv)
> +{
> + struct acpi_device *acpi_dev;
> + struct acpi_video_bus *video;
> + struct acpi_video_device *dev, *next;
> +
> + if (acpi_bus_get_device(handle, &acpi_dev))
> + return AE_OK;
> +
> + if (acpi_match_device_ids(acpi_dev, video_device_ids))
> + return AE_OK;
> +
> + video = acpi_driver_data(acpi_dev);
> + if (!video)
> + return AE_OK;
> +
> + acpi_video_bus_stop_devices(video);
> + mutex_lock(&video->device_list_lock);
> + list_for_each_entry_safe(dev, next, &video->video_device_list, entry) {
> + if (dev->backlight) {
> + backlight_device_unregister(dev->backlight);
> + dev->backlight = NULL;
> + kfree(dev->brightness->levels);
> + kfree(dev->brightness);
> + }
> + if (dev->cooling_dev) {
> + sysfs_remove_link(&dev->dev->dev.kobj,
> + "thermal_cooling");
> + sysfs_remove_link(&dev->cooling_dev->device.kobj,
> + "device");
> + thermal_cooling_device_unregister(dev->cooling_dev);
> + dev->cooling_dev = NULL;
> + }
> + }
> + mutex_unlock(&video->device_list_lock);
> + acpi_video_bus_start_devices(video);
> + return AE_OK;
>
radeon: dpm - 3.11-rc1 positive report
Hi Alex, I just tested the new 3.11-rc1 and was very happy to find out that it reduces the idle temperature of my system by about 12 degrees (C). Thank you very much for this! Cheers, Eldad P.S. Just for reference, lspci output + dmesg below. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Thames [Radeon 7500M/7600M Series] (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device fb91 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon [0.00] Command line: root=/dev/sda6 video radeon.dpm=1 [0.00] Kernel command line: root=/dev/sda6 video radeon.dpm=1 [0.347877] [drm] radeon kernel modesetting enabled. [0.348701] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [0.348787] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF [0.352677] [drm] radeon: 1024M of VRAM memory ready [0.352750] [drm] radeon: 512M of GTT memory ready. [0.352876] radeon :01:00.0: 8802448bb400 unpin not necessary [0.446478] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc900114e6118 [0.447144] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [0.458577] radeon :01:00.0: WB enabled [0.458651] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x880244b61c00 [0.458739] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x880244b61c0c [0.460768] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00174118 and cpu addr 0xc90011d32118 [0.461042] radeon :01:00.0: irq 41 for MSI/MSI-X [0.461055] radeon :01:00.0: radeon: using MSI. [0.461155] [drm] radeon: irq initialized. [0.871099] [drm] radeon atom DIG backlight initialized [0.884248] [drm] radeon: dpm initialized [1.309272] fbcon: radeondrmfb (fb0) is primary device [1.868006] radeon :01:00.0: fb0: radeondrmfb frame buffer device [1.868043] radeon :01:00.0: registered panic notifier [1.868083] [drm] Initialized radeon 2.34.0 20080528 for :01:00.0 on minor 0
DT binding review for Armada display subsystem
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote: > Based on the outcomes of the "Best practice device tree design for display > subsystems" discussion I have drafted a DT binding. Comments much appreciated. > > At a high level, it uses a "super node" as something for the driver to bind > to, needed because there is no clear one device that controls all the > others, and also to distinguish between the Armada 510 possible use cases > of having one video card with two outputs, or two independent video cards. > It uses node-to-node linking beyond that point, V4L2 style. As this hasn't been shot down very far, I've started to implement the driver side of this binding. I have already run into a couple of little problems. First, interrupts. In the dt binding, each "lcd controller" node defines which interrupt it listens to, and in the armada 510 case there are indeed 2 interrupts (47 and 46, one for each LCD controller). And remember that the drm driver itself binds to the super-node. Looking at drm_irq_install(), it looks like DRM only supports 1 interrupt line per drm_device. As we have no known users who will want these two LCD controllers represented as 2 CRTCs on 1 DRM device (which would require management of 2 interrupt lines), I figured this might be a reason to ignore that use case for now (from the coding standpoint), meaning that in all cases we are left with each DRM device having 1 CRTC, corresponding to 1 LCD controller, which has exactly 1 interrupt line. That still doesn't solve the problem though. drm_irq_install calls into drm_platform to figure out which IRQ number to use, and that code looks at the platform_device (i.e. super node). In this case we don't have the irq info there, we have it in the "lcd controller" node. Do I invent our own "DRM bus" implementation so that we can override get_irq()? Start to standardise our DT design as a generic drm_dt.c bus implementation? Any thoughts? Secondly, devm. I understand from the "best practices" thread that we want to have exactly one platform_device which corresponds to the "super node", and all of the individual display controller components will be represented by DT nodes but *without* their own platform_device. As we now put things (clocks, interrupts) into DT nodes that don't have a corresponding platform_device, we lose the ability to use devm. Russell wasn't too pleased last time I posted a patch moving away from devm, admittedly last time the patch was bad and it wasn't necessary, but this time it looks like it might be. Finally, just curious, do we still want to support non-DT platform data type setups on this driver? That adds a bit of coding effort. Not a problem, just wanted to check. Daniel
