[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #30 from David L.  
2012-08-03 22:54:12 UTC ---
(In reply to comment #29)
> Is the lvds console display shifted if you don't connect any external monitor 
> ?

So far I only got the LVDS to display anything by connecting the DP monitor, so
I don't really know.  I didn't try much there... I'll try some other magic
incantations/plug sequences tomorrow, maybe there's a sequence to get LVDS-only
with it actually showing something.

Starting X while the LVDS is off works fine, reenabling it.

Also, the "LVDS off" state after loading the module has the backlight off too,
maybe it's a bug in the brightness control and there is content but I just
don't see it...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53109] New: egl_gallium fails to link if both r600 and radeonsi are enabled

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53109

 Bug #: 53109
   Summary: egl_gallium fails to link if both r600 and radeonsi
are enabled
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: freedesktop at blino.org


When both r600 and radeonsi gallium drivers are enabled, egl_gallium fails to
link because of duplicate symbols in r600 and radeonsi.
See my configure command line and build errors below.

  $ ./configure --build=x86_64-mageia-linux-gnu --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/lib64 --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include
--x-libraries=/usr/lib64 --enable-dri --enable-glx
--with-dri-driverdir=/usr/lib64/dri
--with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast --enable-shared-dricore
--enable-egl --with-egl-platforms=x11,wayland,drm --enable-gbm
--enable-shared-glapi --enable-gles1 --enable-gles2 --enable-openvg
--enable-gallium-egl --enable-gallium-g3dvl --enable-osmesa --disable-xvmc
--enable-vdpau --disable-va
--with-gallium-drivers=r300,r600,radeonsi,nouveau,swrast --enable-gallium-llvm


gmake[3]: Entering directory
`/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/targets/egl-static'
/bin/sh ../../../../bin/mklib -o egl_gallium.so -noprefix -linker 'g++' \
-ldflags '-L../../../../lib64 -Wl,--no-undefined -L/usr/lib64/llvm
-Wl,--as-needed -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags
-L/usr/lib -lpthread -lffi -ldl -lm ' \
-cplusplus -install ../../../../lib64/egl \
egl.o egl_pipe.o egl_st.o -Wl,--start-group
../../../../src/egl/wayland/wayland-drm/.libs/libwayland-drm.a
../../../../src/gallium/auxiliary/libgallium.a
../../../../src/gallium/drivers/identity/libidentity.a
../../../../src/gallium/drivers/llvmpipe/libllvmpipe.a
../../../../src/gallium/drivers/nouveau/libnouveau.a
../../../../src/gallium/drivers/nv30/libnv30.a
../../../../src/gallium/drivers/nv50/libnv50.a
../../../../src/gallium/drivers/nvc0/libnvc0.a
../../../../src/gallium/drivers/r300/libr300.a
../../../../src/gallium/drivers/r600/libr600.a
../../../../src/gallium/drivers/radeonsi/libradeonsi.a
../../../../src/gallium/drivers/rbug/librbug.a
../../../../src/gallium/drivers/softpipe/libsoftpipe.a
../../../../src/gallium/drivers/trace/libtrace.a
../../../../src/gallium/state_trackers/egl/libegl.a
../../../../src/gallium/state_trackers/vega/libvega.a
../../../../src/gallium/winsys/nouveau/drm/libnouveaudrm.a
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a
../../../../src/gallium/winsys/sw/wayland/libws_wayland.a
../../../../src/gallium/winsys/sw/xlib/libws_xlib.a
../../../../src/mesa/libmesagallium.a -Wl,--end-group \
-lEGL -lOpenVG -lX11 -lXext -lXfixes -ldl -ldrm -ldrm_nouveau -ldrm_radeon
-lgbm -lglapi -lm -lpthread -lrt -ludev -lwayland-client -lwayland-server
-lLLVMMCJIT -lLLVMBitWriter -lLLVMX86AsmParser -lLLVMX86Disassembler
-lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser
-lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT
-lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget
-lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport
mklib: Making Linux shared library: egl_gallium.so
/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for
-lpthread
/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
../../../../src/gallium/drivers/radeonsi/libradeonsi.a(evergreen_hw_context.o):
In function `evergreen_flush_vgt_streamout':
/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/evergreen_hw_context.c:117:
multiple definition of `evergreen_flush_vgt_streamout'
../../../../src/gallium/drivers/r600/libr600.a(evergreen_hw_context.o):/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/r600/evergreen_hw_context.c:753:
first defined here
../../../../src/gallium/drivers/radeonsi/libradeonsi.a(evergreen_hw_context.o):
In function `evergreen_set_streamout_enable':
/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/evergreen_hw_context.c:137:
multiple definition of `evergreen_set_streamout_enable'
../../../../src/gallium/drivers/r600/libr600.a(evergreen_hw_context.o):/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/r600/evergreen_hw_context.c:773:
first defined here
../../../../src/gallium/drivers/radeonsi/libradeonsi.a(r600_buffer.o): In
function `r600_init_resource':
/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/r600_buffer.c:121:
multiple definition of `r600_init_resource'

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #29 from Jerome Glisse  2012-08-03 
22:05:53 UTC ---
Is the lvds console display shifted if you don't connect any external monitor ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #28 from David L.  
2012-08-03 21:17:10 UTC ---
(In reply to comment #27)
> > The bad news is that the LVDS panel first went backlight-off, on starting X
> > started displaying flickering pixelgarbage and at some later point the 
> > entire
> > box locked up.
> 
> You probably need this patch:
> http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html

After both patches, that indeed fixes things as soon as X is started, but the
console is still broken.  After loading the module, the panel just switches
off, though the console is still usable.  Plugging my DisplayPort screen in
also reenables the LVDS panel, although the image is wrapped around by around
100 pixels. (Left part of my prompt is on the right of the screen.)  
Wraparound might be related to the different resolution for the ext display;
the external screen only shows the nonwrapping part of the image (and is
therefore missing the first characters of the prompt).  Either way that's a
separate bug...


Apart from the above, I now have working graphics (including 3D) on an UEFI
native booted HP EliteBook.  I'll clean up my hack VFCT patch and send it to
dri-devel.


P.S.: The laptop also needs your backlight control patch, thanks a zillion for
that - you wouldn't believe how nuts that was driving me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #105 from Jerome Glisse  2012-08-03 
19:46:50 UTC ---
Well for va issue you also need the mesa patch from Christian. This patch
mostly fix kernel, it might help with lockup, thought here piglit lockup hard
with lastest mesa.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #104 from Alexandre Demers  
2012-08-03 19:44:34 UTC ---
(In reply to comment #103)
> Created attachment 65102 [details] [review]
> Properly protect virtual address v2
> 
> Against Linus master

I will test them later today. They should take care of the va issues, right?
Probably nothing to do with lockups?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #27 from Alex Deucher  2012-08-03 19:23:34 UTC 
---
(In reply to comment #26)
> Created attachment 65100 [details] [review]
> hacked-up radeon VFCT BIOS access patch
> 
> So the good news is that a VFCT ACPI table does indeed show up when I boot
> under UEFI native mode on the HP EliteBook.
> 
> I hacked up some code to get the BIOS from there and it successfully brought 
> up
> the card and drove my DisplayPort screen. (hack patch attached)
> 

Excellent.

> The bad news is that the LVDS panel first went backlight-off, on starting X
> started displaying flickering pixelgarbage and at some later point the entire
> box locked up.

You probably need this patch:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Jerome Glisse  changed:

   What|Removed |Added

  Attachment #65097|0   |1
is obsolete||

--- Comment #103 from Jerome Glisse  2012-08-03 
19:05:47 UTC ---
Created attachment 65102
  --> https://bugs.freedesktop.org/attachment.cgi?id=65102
Properly protect virtual address v2

Against Linus master

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Jerome Glisse  changed:

   What|Removed |Added

  Attachment #65098|0   |1
is obsolete||

--- Comment #102 from Jerome Glisse  2012-08-03 
19:04:54 UTC ---
Created attachment 65101
  --> https://bugs.freedesktop.org/attachment.cgi?id=65101
Properly protect virtual address kernel 3.5 v2

Updated

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #26 from David L.  
2012-08-03 18:49:14 UTC ---
Created attachment 65100
  --> https://bugs.freedesktop.org/attachment.cgi?id=65100
hacked-up radeon VFCT BIOS access patch

So the good news is that a VFCT ACPI table does indeed show up when I boot
under UEFI native mode on the HP EliteBook.

I hacked up some code to get the BIOS from there and it successfully brought up
the card and drove my DisplayPort screen. (hack patch attached)

The bad news is that the LVDS panel first went backlight-off, on starting X
started displaying flickering pixelgarbage and at some later point the entire
box locked up.

I'll go diff the BIOS images against each other, maybe the BIOS from VFCT is
corrupted...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Huacai Chen]

OK, I'll split it.

On Fri, Aug 3, 2012 at 4:01 PM, Michel D?nzer  wrote:
> On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote:
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Include swiotlb.h if SWIOTLB configured.
>>
>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_vm.c|2 +-
>>  drivers/gpu/drm/radeon/radeon_ttm.c |4 
>>  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>>  include/drm/drm_sarea.h |2 ++
>>  4 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>>   tmp = pgprot_writecombine(tmp);
>>   else
>>   tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>   tmp = pgprot_noncached(tmp);
>>  #endif
>>   return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index 5b71c71..fc3ac22 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -41,6 +41,10 @@
>>  #include "radeon_reg.h"
>>  #include "radeon.h"
>>
>> +#ifdef CONFIG_SWIOTLB
>> +#include 
>> +#endif
>> +
>>  #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)
>>
>>  static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index f8187ea..0df71ea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
>> tmp)
>>   else
>>   tmp = pgprot_noncached(tmp);
>>  #endif
>> -#if defined(__sparc__)
>> +#if defined(__sparc__) || defined(__mips__)
>>   if (!(caching_flags & TTM_PL_FLAG_CACHED))
>>   tmp = pgprot_noncached(tmp);
>>  #endif
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>>  /* SAREA area needs to be at least a page */
>>  #if defined(__alpha__)
>>  #define SAREA_MAX   0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX   0x4000U
>>  #elif defined(__ia64__)
>>  #define SAREA_MAX   0x1U /* 64kB */
>>  #else
>
> This should be four separate patches.
>
>
> --
> Earthling Michel D?nzer   |   http://www.amd.com
> Libre software enthusiast |  Debian, X and DRI developer

[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40790

--- Comment #15 from ojab  2012-08-03 17:37:58 UTC ---
Still happens with libdrm/mesa/xf86-video-ati latest git.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2

[Jerome Glisse]

On Fri, Aug 3, 2012 at 4:47 PM, Greg KH  wrote:
> On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote:
>> On Fri, Aug 3, 2012 at 4:16 PM, Greg KH  
>> wrote:
>> > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.glisse at gmail.com wrote:
>> >> From: Jerome Glisse 
>> >>
>> >> Virtual address need to be fenced to know when we can safely remove it.
>> >> This patch also properly clear the pagetable. Previously it was
>> >> serouisly broken.
>> >>
>> >> v2: For to update pagetable when unbinding bo (don't bailout if
>> >> bo_va->valid is true).
>> >>
>> >> This version is for stable 3.5 only.
>> >
>> > Why?
>>
>> Because 3.4 needs again a different patch and 3.6 needs a different
>> patch. Code around this patch changed btw 3.4-3.5 and changed again
>> btw 3.5-3.6 and in non trivial way.
>
> Then please say that in the original patch, and point to where the
> changes happened, and resend it so that I can apply it.
>
> I also need an ack from the maintainer(s) that this is acceptable.
>
> greg k-h

I resend the original patch with comment that says 3.5 need special patch.

Cheers,
Jerome

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Matthew Garrett]

On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:

> This is one of the things I wasn't so sure about. There are various
> checks in intel_lvds_init() that can cause it to bail out before we try
> to get the EDID, and I don't fully understand all of them. If non-laptop
> machines are expected to bail out before the EDID check then the
> approach I've taken seems reasonable. Otherwise adding a quirk probably
> is a good idea.

I know we've previously had problems with machines with phantom LVDS 
hardware, but I'm not sure what the current state of affairs is.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH] drm/radeon: fence virtual address and free it once idle v3

[j.gli...@gmail.com]

From: Jerome Glisse 

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.

v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_cs.c |   32 +---
 drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
 drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
 drivers/gpu/drm/radeon/radeon_object.c |6 +-
 5 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+   struct radeon_fence *fence;
boolvalid;
 };

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..995f3ab 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }

+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+   struct radeon_vm *vm = >vm;
+   struct radeon_bo_list *lobj;
+   int r;
+
+   if (parser->chunk_ib_idx == -1)
+   return;
+   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+   return;
+
+   list_for_each_entry(lobj, >validated, tv.head) {
+   struct radeon_bo_va *bo_va;
+   struct radeon_bo *rbo = lobj->bo;
+
+   bo_va = radeon_bo_va(rbo, vm);
+   radeon_fence_unref(_va->fence);
+   bo_va->fence = radeon_fence_ref(fence);
+   }
+   return 0;
+}
+
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
 {
unsigned i;

-   if (!error)
+   if (!error) {
+   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
+   radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(>validated,
parser->ib.fence);
-   else
+   } else {
ttm_eu_backoff_reservation(>validated);
+   }

if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,

if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}

-   if (bo_va->valid)
+   if (bo_va->valid && mem)
return 0;

ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
 struct radeon_bo *bo)
 {
struct radeon_bo_va *bo_va;
+   int r;

bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;

+   /* wait for va use to end */
+   while (bo_va->fence) {
+   r = radeon_fence_wait(bo_va->fence, false);
+   if (r) {
+   DRM_ERROR("error while waiting for fence: %d\n", r);
+   }
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   continue;
+   }
+   break;
+   }
+   radeon_fence_unref(_va->fence);
+
mutex_lock(>vm_manager.lock);
mutex_lock(>mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(>vm_manager.lock);

-   /* remove all bo */
+   /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence 

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #25 from Alex Deucher  2012-08-03 17:26:03 UTC 
---
(In reply to comment #24)
> Should this already work on 3.4.7 and should I file a separate report about
> ACPI VFCT being broken or is that future tense/upcoming?

Support for fetching the vbios from VFCT still needs to be implemented.

> 
> Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just
> tried acpidump | grep VFCT, that should show something shouldn't it?) Will try
> under native UEFI in a minute...

I'm not too familiar with ACPI and UEFI unfortunately.  It's part of the GOP
stuff for UEFI.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Matthew Garrett]

On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> Some Apple hybrid graphics machines do not have the LVDS panel connected
> to the integrated GPU at boot and also do not supply a VBT. The LVDS
> connector is not registered as a result, making it impossible to support
> graphics switching.
> 
> This patch changes intel_lvds_init() to register the connector even if
> we can't find any panel modes. This makes it necessary to always check
> intel_lvds->fixed_mode before use, as it could now be NULL.

This one kind of sucks. I think adding a quirk for this situation would 
be justifiable, rather than doing it for all devices.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #24 from David L.  
2012-08-03 17:12:52 UTC ---
(In reply to comment #23)
> On UEFI systems the vbios should be accessible via the ACPI VFCT.  See the
> bottom of atombios.h for struct definitions.  Macs do their own thing so I
> don't know if this will work on them or not.

Should this already work on 3.4.7 and should I file a separate report about
ACPI VFCT being broken or is that future tense/upcoming?

Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just
tried acpidump | grep VFCT, that should show something shouldn't it?) Will try
under native UEFI in a minute...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #101 from Jerome Glisse  2012-08-03 
17:05:15 UTC ---
Created attachment 65098
  --> https://bugs.freedesktop.org/attachment.cgi?id=65098
Properly protect virtual address against kernel 3.5

Same patch against 3.5

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Jerome Glisse  changed:

   What|Removed |Added

  Attachment #65096|0   |1
is obsolete||

--- Comment #100 from Jerome Glisse  2012-08-03 
16:59:41 UTC ---
Created attachment 65097
  --> https://bugs.freedesktop.org/attachment.cgi?id=65097
Properly protect virtual address

Properly protect virtual address

Patch against Linus master, gonna attach patch against 3.5 next.

Again, sorry previous one was wrong one.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Jerome Glisse  changed:

   What|Removed |Added

  Attachment #65095|0   |1
is obsolete||

--- Comment #99 from Jerome Glisse  2012-08-03 
16:56:00 UTC ---
Created attachment 65096
  --> https://bugs.freedesktop.org/attachment.cgi?id=65096
Properly protect virtual address

Properly protect virtual address

Patch against Linus master, gonna attach patch against 3.5 next.

Sorry previous one was wrong one.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #98 from Jerome Glisse  2012-08-03 
16:54:04 UTC ---
Created attachment 65095
  --> https://bugs.freedesktop.org/attachment.cgi?id=65095
Properly protect virtual address

Properly protect virtual address

Patch against Linus master, gonna attach patch against 3.5 next.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #23 from Alex Deucher  2012-08-03 16:33:04 UTC 
---
On UEFI systems the vbios should be accessible via the ACPI VFCT.  See the
bottom of atombios.h for struct definitions.  Macs do their own thing so I
don't know if this will work on them or not.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2

[Jerome Glisse]

On Fri, Aug 3, 2012 at 4:16 PM, Greg KH  wrote:
> On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.glisse at gmail.com wrote:
>> From: Jerome Glisse 
>>
>> Virtual address need to be fenced to know when we can safely remove it.
>> This patch also properly clear the pagetable. Previously it was
>> serouisly broken.
>>
>> v2: For to update pagetable when unbinding bo (don't bailout if
>> bo_va->valid is true).
>>
>> This version is for stable 3.5 only.
>
> Why?

Because 3.4 needs again a different patch and 3.6 needs a different
patch. Code around this patch changed btw 3.4-3.5 and changed again
btw 3.5-3.6 and in non trivial way.

Cheers,
Jerome

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

David L.  changed:

   What|Removed |Added

 CC||equinox-freedesktopbugs at dia
   ||c24.net
Summary|Radeon KMS on Macs with EFI |Radeon KMS fails with
   |boot|inaccessible AtomBIOS on
   ||systems with (U)EFI boot

--- Comment #22 from David L.  
2012-08-03 16:12:27 UTC ---
Exact same issue appears on an HP EliteBook 8470p if you select "native UEFI"
as boot method in setup.  Legacy and hybrid boot options work fine.

Changing bug title since this is not a Mac-specific issue, although it is more
severe on Macs without the legacy/hybrid options easily accessible.

It seems that the driver either cannot rely on the AtomBIOS being accessible,
or we need to add code to enable the mapping with some PCI hacks?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2

[j.gli...@gmail.com]

From: Jerome Glisse 

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).

This version is for stable 3.5 only.

cc: stable at vger.kernel.org
Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
 drivers/gpu/drm/radeon/radeon_gart.c   | 24 ++--
 drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
 drivers/gpu/drm/radeon/radeon_object.c |  6 +-
 5 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..01d2a87 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -323,6 +323,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+   struct radeon_fence *fence;
boolvalid;
 };

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 142f894..70f6d08 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -294,6 +294,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }

+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+   struct radeon_vm *vm = >vm;
+   struct radeon_bo_list *lobj;
+   int r;
+
+   if (parser->chunk_ib_idx == -1)
+   return;
+   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+   return;
+
+   list_for_each_entry(lobj, >validated, tv.head) {
+   struct radeon_bo_va *bo_va;
+   struct radeon_bo *rbo = lobj->bo;
+
+   bo_va = radeon_bo_va(rbo, vm);
+   radeon_fence_unref(_va->fence);
+   bo_va->fence = radeon_fence_ref(fence);
+   }
+   return 0;
+}
+
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -306,11 +330,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
 {
unsigned i;

-   if (!error)
+   if (!error) {
+   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
+   radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(>validated,
parser->ib.fence);
-   else
+   } else {
ttm_eu_backoff_reservation(>validated);
+   }

if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -407,7 +434,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,

if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 84b648a..f651f22 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -564,7 +564,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}

-   if (bo_va->valid)
+   if (bo_va->valid && mem)
return 0;

ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -597,11 +597,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
 struct radeon_bo *bo)
 {
struct radeon_bo_va *bo_va;
+   int r;

bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;

+   /* wait for va use to end */
+   while (bo_va->fence) {
+   r = radeon_fence_wait(bo_va->fence, false);
+   if (r) {
+   DRM_ERROR("error while waiting for fence: %d\n", r);
+   }
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   continue;
+   }
+   break;
+   }
+   radeon_fence_unref(_va->fence);
+
radeon_mutex_lock(>cs_mutex);
mutex_lock(>mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -661,12 +677,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(>cs_mutex);

-   /* remove all bo */
+   /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence to signal
+*/
r = 

[PATCH] drm/radeon: fix some missing parens in asic macros

[Jerome Glisse]

On Fri, Aug 3, 2012 at 11:53 AM,   wrote:
> From: Alex Deucher 
>
> Better safe than sorry.
>
> Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon.h |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 118e4b9..9f58885 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, 
> uint32_t v);
>  #define radeon_pm_finish(rdev) (rdev)->asic->pm.finish((rdev))
>  #define radeon_pm_init_profile(rdev) (rdev)->asic->pm.init_profile((rdev))
>  #define radeon_pm_get_dynpm_state(rdev) 
> (rdev)->asic->pm.get_dynpm_state((rdev))
> -#define radeon_pre_page_flip(rdev, crtc) 
> rdev->asic->pflip.pre_page_flip((rdev), (crtc))
> -#define radeon_page_flip(rdev, crtc, base) 
> rdev->asic->pflip.page_flip((rdev), (crtc), (base))
> -#define radeon_post_page_flip(rdev, crtc) 
> rdev->asic->pflip.post_page_flip((rdev), (crtc))
> -#define radeon_wait_for_vblank(rdev, crtc) 
> rdev->asic->display.wait_for_vblank((rdev), (crtc))
> -#define radeon_mc_wait_for_idle(rdev) rdev->asic->mc_wait_for_idle((rdev))
> +#define radeon_pre_page_flip(rdev, crtc) 
> (rdev)->asic->pflip.pre_page_flip((rdev), (crtc))
> +#define radeon_page_flip(rdev, crtc, base) 
> (rdev)->asic->pflip.page_flip((rdev), (crtc), (base))
> +#define radeon_post_page_flip(rdev, crtc) 
> (rdev)->asic->pflip.post_page_flip((rdev), (crtc))
> +#define radeon_wait_for_vblank(rdev, crtc) 
> (rdev)->asic->display.wait_for_vblank((rdev), (crtc))
> +#define radeon_mc_wait_for_idle(rdev) (rdev)->asic->mc_wait_for_idle((rdev))
>
>  /* Common functions */
>  /* AGP */
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fence virtual address and free it once idle v2

[j.gli...@gmail.com]

From: Jerome Glisse 

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_cs.c |   32 +---
 drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
 drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
 drivers/gpu/drm/radeon/radeon_object.c |6 +-
 5 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+   struct radeon_fence *fence;
boolvalid;
 };

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..995f3ab 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }

+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+   struct radeon_vm *vm = >vm;
+   struct radeon_bo_list *lobj;
+   int r;
+
+   if (parser->chunk_ib_idx == -1)
+   return;
+   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+   return;
+
+   list_for_each_entry(lobj, >validated, tv.head) {
+   struct radeon_bo_va *bo_va;
+   struct radeon_bo *rbo = lobj->bo;
+
+   bo_va = radeon_bo_va(rbo, vm);
+   radeon_fence_unref(_va->fence);
+   bo_va->fence = radeon_fence_ref(fence);
+   }
+   return 0;
+}
+
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
 {
unsigned i;

-   if (!error)
+   if (!error) {
+   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
+   radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(>validated,
parser->ib.fence);
-   else
+   } else {
ttm_eu_backoff_reservation(>validated);
+   }

if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,

if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}

-   if (bo_va->valid)
+   if (bo_va->valid && mem)
return 0;

ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
 struct radeon_bo *bo)
 {
struct radeon_bo_va *bo_va;
+   int r;

bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;

+   /* wait for va use to end */
+   while (bo_va->fence) {
+   r = radeon_fence_wait(bo_va->fence, false);
+   if (r) {
+   DRM_ERROR("error while waiting for fence: %d\n", r);
+   }
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   continue;
+   }
+   break;
+   }
+   radeon_fence_unref(_va->fence);
+
mutex_lock(>vm_manager.lock);
mutex_lock(>mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(>vm_manager.lock);

-   /* remove all bo */
+   /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence to signal
+*/
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (!r) {
  

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #97 from Marek Ol??k  2012-08-03 15:20:12 UTC 
---
(In reply to comment #96)
> Created attachment 65093 [details] [review]
> Possible fix.
> 
> It's hard and uneffecient to solve this problem completely in the kernel.
> 
> Since we patch the VM table synchronously, but use it asynchronously we will
> always end up needing to wait for a bo use by the GPU to end before patching 
> in
> the new VA.
> 
> Please take a look at the attached patch it should fix the issue nicely in
> userspace.

Please use the radeon_bo_is_busy function. Calling DRM_RADEON_GEM_BUSY directly
is not reliable because of the thread offloading of the CS ioctl. The same
applies to any other kernel queries and commands which depend on the CS ioctl.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Huacai Chen]

1, Handle io prot correctly for MIPS.
2, Define SAREA_MAX as the size of one page.
3, Include swiotlb.h if SWIOTLB configured.

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_vm.c|2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |4 
 drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
 include/drm/drm_sarea.h |2 ++
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
 #endif
return tmp;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5b71c71..fc3ac22 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -41,6 +41,10 @@
 #include "radeon_reg.h"
 #include "radeon.h"

+#ifdef CONFIG_SWIOTLB
+#include 
+#endif
+
 #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)

 static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
else
tmp = pgprot_noncached(tmp);
 #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
if (!(caching_flags & TTM_PL_FLAG_CACHED))
tmp = pgprot_noncached(tmp);
 #endif
diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
index ee5389d..1d1a858 100644
--- a/include/drm/drm_sarea.h
+++ b/include/drm/drm_sarea.h
@@ -37,6 +37,8 @@
 /* SAREA area needs to be at least a page */
 #if defined(__alpha__)
 #define SAREA_MAX   0x2000U
+#elif defined(__mips__)
+#define SAREA_MAX   0x4000U
 #elif defined(__ia64__)
 #define SAREA_MAX   0x1U   /* 64kB */
 #else
-- 
1.7.7.3

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Christian K?nig  changed:

   What|Removed |Added

  Attachment #65051|0   |1
is obsolete||

--- Comment #96 from Christian K?nig  2012-08-03 
15:03:52 UTC ---
Created attachment 65093
  --> https://bugs.freedesktop.org/attachment.cgi?id=65093
Possible fix.

It's hard and uneffecient to solve this problem completely in the kernel.

Since we patch the VM table synchronously, but use it asynchronously we will
always end up needing to wait for a bo use by the GPU to end before patching in
the new VA.

Please take a look at the attached patch it should fix the issue nicely in
userspace.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #95 from Alexandre Demers  
2012-08-03 14:51:56 UTC ---
(In reply to comment #90)
> (In reply to comment #89)
> > Nope, no lockup without va (I may only be lucky though if the bug is there 
> > but
> > only shown when using va).
> 
> That's indeed possible: Using virtual address space will catch out of bounds
> memory access that may otherwise go unnoticed.
> 
> So, I think in this report we should focus on the rendering regression(s), and
> track the lockups in other reports.

OK, I'll open another bug for the lockups. This one will be renamed for va
issues and rendering regression. I'll wait until tonight to make changes to see
if someone objects.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2 7/7] drm: Renesas SH Mobile DRM driver

[Sascha Hauer]

Hi Laurent,

Some minor stuff inside.

Thanks

 Sascha+

On Fri, Jul 20, 2012 at 03:04:22PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
> 
> Only flat panel outputs using the parallel interface are supported.
> Support for SYS panels, HDMI and DSI is currently not implemented.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/shmobile/Kconfig   |   10 +
>  drivers/gpu/drm/shmobile/Makefile  |7 +
>  drivers/gpu/drm/shmobile/shmob_drm_backlight.c |   90 +++
>  drivers/gpu/drm/shmobile/shmob_drm_backlight.h |   23 +
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  768 
> 
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |   60 ++
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  360 +++
>  drivers/gpu/drm/shmobile/shmob_drm_drv.h   |   52 ++
>  drivers/gpu/drm/shmobile/shmob_drm_kms.c   |  160 +
>  drivers/gpu/drm/shmobile/shmob_drm_kms.h   |   34 +
>  drivers/gpu/drm/shmobile/shmob_drm_plane.c |  263 
>  drivers/gpu/drm/shmobile/shmob_drm_plane.h |   22 +
>  drivers/gpu/drm/shmobile/shmob_drm_regs.h  |  304 ++
>  include/drm/shmob_drm.h|   99 +++
>  16 files changed, 2255 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpu/drm/shmobile/Kconfig
>  create mode 100644 drivers/gpu/drm/shmobile/Makefile
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
>  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
>  create mode 100644 include/drm/shmob_drm.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 98ba7d5..0b40bf2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -208,3 +208,5 @@ source "drivers/gpu/drm/ast/Kconfig"
>  source "drivers/gpu/drm/mgag200/Kconfig"
>  
>  source "drivers/gpu/drm/cirrus/Kconfig"
> +
> +source "drivers/gpu/drm/shmobile/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 58961b9..2ff5cef 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -47,4 +47,5 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
>  obj-$(CONFIG_DRM_GMA500) += gma500/
>  obj-$(CONFIG_DRM_UDL) += udl/
>  obj-$(CONFIG_DRM_AST) += ast/
> +obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>  obj-y+= i2c/
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c 
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> new file mode 100644
> index 000..c7be5f7
> --- /dev/null
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -0,0 +1,768 @@

[...]

> +
> +static void shmob_drm_encoder_destroy(struct drm_encoder *encoder)
> +{
> + drm_encoder_cleanup(encoder);
> +}
> +
> +static const struct drm_encoder_funcs encoder_funcs = {
> + .destroy = shmob_drm_encoder_destroy,

You could add drm_encoder_cleanup here.


[...]

> +
> +static enum drm_connector_status
> +shmob_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_unknown;
> +}

Shouldn't you return connector_status_connected here? I mean all that
you handle is a dumb display which is always connected.


[...]

> +
> +static int __devinit shmob_drm_setup_clocks(struct shmob_drm_device *sdev,
> + enum shmob_drm_clk_source clksrc)
> +{
> + struct clk *clk;
> + char *clkname;
> +
> + switch (clksrc) {
> + case SHMOB_DRM_CLK_BUS:
> + clkname = "bus_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_BUS;
> + break;
> + case SHMOB_DRM_CLK_PERIPHERAL:
> + clkname = "peripheral_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_MIPI;
> + break;
> + case SHMOB_DRM_CLK_EXTERNAL:
> + clkname = NULL;
> + sdev->lddckr = LDDCKR_ICKSEL_HDMI;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + clk = clk_get(sdev->dev, clkname);
> + if (IS_ERR(clk)) {
> + dev_err(sdev->dev, "cannot get dot clock %s\n", clkname);
> + return PTR_ERR(clk);
> + }
> +
> + sdev->clock = clk;
> + return 0;

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #94 from Jerome Glisse  2012-08-03 
14:39:59 UTC ---
(In reply to comment #88)
> (In reply to comment #86)
> > So, Anthony has put a finger on something.
> 
> Yes, I think something like Anthony's patch is needed due to asynchronous GPU
> processing: when the userspace driver assigns virtual address space for a new
> BO, the GPU may not have finished processing command streams using previous 
> BOs
> occupying that same virtual address space.
> 
> However, the userspace driver shouldn't wait synchronously for the BO to go
> idle when destroying it but should instead defer destruction (or at least the
> freeing of the virtual address space) until it notices the BO has become idle.
> 
> 
> > With Anthony's patch, I'm still able to lock the display everytime
> 
> And these lockups do not happen when not using virtual address space? Can you
> provide the dmesg output of the GPU reset for such a lockup? Ideally from a
> single piglit test reproducing it.

No, Anthony patch should not be needed. Once userspace call kernel to destroy
bo userspace should be able to reuse va right away even if kernel is delaying
bo destruction. My patch should fix the va issue, note that the patch attached
here have a bug but it should not affect the va thing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2

[Greg KH]

On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote:
> On Fri, Aug 3, 2012 at 4:16 PM, Greg KH  wrote:
> > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.glisse at gmail.com wrote:
> >> From: Jerome Glisse 
> >>
> >> Virtual address need to be fenced to know when we can safely remove it.
> >> This patch also properly clear the pagetable. Previously it was
> >> serouisly broken.
> >>
> >> v2: For to update pagetable when unbinding bo (don't bailout if
> >> bo_va->valid is true).
> >>
> >> This version is for stable 3.5 only.
> >
> > Why?
> 
> Because 3.4 needs again a different patch and 3.6 needs a different
> patch. Code around this patch changed btw 3.4-3.5 and changed again
> btw 3.5-3.6 and in non trivial way.

Then please say that in the original patch, and point to where the
changes happened, and resend it so that I can apply it.

I also need an ack from the maintainer(s) that this is acceptable.

greg k-h

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #93 from Michel D?nzer  2012-08-03 13:26:32 
UTC ---
(In reply to comment #92)
> > Do I understand it correctly that the userspace VM manager is releasing
> > allocations to early and not waiting for async buffer use to end?
> 
> That's my working theory.

Also, if it wasn't the case, I don't see how Anthony's patch could make a
difference.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #92 from Michel D?nzer  2012-08-03 13:21:22 
UTC ---
(In reply to comment #91)
> I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same
> problem now.

Ah cool, you found it already. :)

> Do I understand it correctly that the userspace VM manager is releasing
> allocations to early and not waiting for async buffer use to end?

That's my working theory.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2

[Greg KH]

On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
> 
> Virtual address need to be fenced to know when we can safely remove it.
> This patch also properly clear the pagetable. Previously it was
> serouisly broken.
> 
> v2: For to update pagetable when unbinding bo (don't bailout if
> bo_va->valid is true).
> 
> This version is for stable 3.5 only.

Why?

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Christian K?nig  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #91 from Christian K?nig  2012-08-03 
12:58:04 UTC ---
I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same
problem now.

Do I understand it correctly that the userspace VM manager is releasing
allocations to early and not waiting for async buffer use to end?

That should be easy to fix.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2] of: Add videomode helper

[Stephen Warren]

On 08/03/2012 01:38 AM, Sascha Hauer wrote:
> Hi Stephen,
> 
> On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
>> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
>>> This patch adds a helper function for parsing videomodes from the 
>>> devicetree.
>>> The videomode can be either converted to a struct drm_display_mode or a
>>> struct fb_videomode.
>>
>>> diff --git a/Documentation/devicetree/bindings/video/displaymode 
>>> b/Documentation/devicetree/bindings/video/displaymode
>>
>>> +Required properties:
>>> + - xres, yres: Display resolution
>>> + - left-margin, right-margin, hsync-len: Horizontal Display timing 
>>> parameters
>>> +   in pixels
>>> +   upper-margin, lower-margin, vsync-len: Vertical display timing 
>>> parameters in
>>> +   lines
>>
>> Perhaps bike-shedding, but...
>>
>> For the margin property names, wouldn't it be better to use terminology
>> more commonly used for video timings rather than Linux FB naming. In
>> other words naming like:
>>
>> hactive, hsync-len, hfront-porch, hback-porch?
> 
> Can do. Just to make sure:
> 
> hactive == xres
> hsync-len == hsync-len
> hfront-porch == right-margin
> hback-porch == left-margin

I believe so yes.

>> a) They're already standardized and very common.
> 
> Indeed, that's a big plus for EDID. I have no intention of removing EDID
> data from the devicetree. There are situations where EDID is handy, for
> example when you get EDID data provided by your vendor.
> 
>>
>> b) They allow other information such as a display's HDMI audio
>> capabilities to be represented, which can then feed into an ALSA driver.
>>
>> c) The few LCD panel datasheets I've seen actually quote their
>> specification as an EDID already, so deriving the EDID may actually be easy.
>>
>> d) People familiar with displays are almost certainly familiar with
>> EDID's mode representation. There are many ways of representing display
>> modes (sync position vs. porch widths, htotal specified rather than
>> specifying all the components and hence htotal being calculated etc.).
>> Not everyone will be familiar with all representations. Conversion
>> errors are less likely if the target is EDID's familiar format.
> 
> You seem to think about a different class of displays for which EDID
> indeed is a better way to handle. What I have to deal with here mostly
> are dumb displays which:
> 
> - can only handle their native resolution
> - Have no audio capabilities at all
> - come with a datasheet which specify a min/typ/max triplet for
>   xres,hsync,..., often enough they are scanned to pdf from some previously
>   printed paper.
> 
> These displays are very common on embedded devices, probably that's the
> reason I did not even think about the possibility that a single display
> might have different modes.

That's true, but as I mentioned, there are at least some dumb panels
(both I've seen recently) whose specification provides the EDID. I don't
know how common that is though, I must admit.

>> e) You'll end up with exactly the same data as if you have a DDC-based
>> external monitor rather than an internal panel, so you end up getting to
>> a common path in display handling code much more quickly.
> 
> All we have in our display driver currently is:
> 
>   edidp = of_get_property(np, "edid", >edid_len);
>   if (edidp) {
>   imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
>   } else {
>   ret = of_get_video_mode(np, >mode, NULL);
>   if (!ret)
>   imxpd->mode_valid = 1;
>   }

Presumably there's more to it though; something later checks
imxpd->mode_valid and if false, parses the EDID and sets up imxpd->mode,
etc.

[Bug 26345] [845G] CPU/GPU incoherency

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26345

Chris Wilson  changed:

   What|Removed |Added

 CC||artem.rusanov at gmail.com

--- Comment #147 from Chris Wilson  2012-08-03 
12:18:44 UTC ---
*** Bug 53065 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fix some missing parens in asic macros

[alexdeuc...@gmail.com]

From: Alex Deucher 

Better safe than sorry.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 118e4b9..9f58885 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, 
uint32_t v);
 #define radeon_pm_finish(rdev) (rdev)->asic->pm.finish((rdev))
 #define radeon_pm_init_profile(rdev) (rdev)->asic->pm.init_profile((rdev))
 #define radeon_pm_get_dynpm_state(rdev) 
(rdev)->asic->pm.get_dynpm_state((rdev))
-#define radeon_pre_page_flip(rdev, crtc) 
rdev->asic->pflip.pre_page_flip((rdev), (crtc))
-#define radeon_page_flip(rdev, crtc, base) rdev->asic->pflip.page_flip((rdev), 
(crtc), (base))
-#define radeon_post_page_flip(rdev, crtc) 
rdev->asic->pflip.post_page_flip((rdev), (crtc))
-#define radeon_wait_for_vblank(rdev, crtc) 
rdev->asic->display.wait_for_vblank((rdev), (crtc))
-#define radeon_mc_wait_for_idle(rdev) rdev->asic->mc_wait_for_idle((rdev))
+#define radeon_pre_page_flip(rdev, crtc) 
(rdev)->asic->pflip.pre_page_flip((rdev), (crtc))
+#define radeon_page_flip(rdev, crtc, base) 
(rdev)->asic->pflip.page_flip((rdev), (crtc), (base))
+#define radeon_post_page_flip(rdev, crtc) 
(rdev)->asic->pflip.post_page_flip((rdev), (crtc))
+#define radeon_wait_for_vblank(rdev, crtc) 
(rdev)->asic->display.wait_for_vblank((rdev), (crtc))
+#define radeon_mc_wait_for_idle(rdev) (rdev)->asic->mc_wait_for_idle((rdev))

 /* Common functions */
 /* AGP */
-- 
1.7.7.5

[RFC 0/3] solving omapdrm/omapdss layering issues

[Semwal, Sumit]

Hi Rob, Tomi,
On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark  wrote:
> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen  
> wrote:
>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
>>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen  
>>> wrote:
>>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> >> ti.com> wrote:
>>> >
>>> >> > I guess the fact is that DRM concepts do not really match the OMAP DSS
>>> >> > hardware, and we'll have to use whatever gives us least problems.
>>> >>
>>> >> Actually, I think it does map fairly well to the hardware.. at least
>>> >> more so than to omapdss ;-)
>>> >
>>> > Hm, I'm not sure I understand, omapdss concepts map directly to the
>>> > hardware.
>>>
>>> I think it is mainly exposing the encoder and panel as two separate
>>> entities.. which seems to be what Archit is working on
>>
>> I still don't follow =) They are separate entities. Omapdss models the
>> HW quite directly, I think. It doesn't expose everything, though, as the
>> output drivers (dsi.c, dpi.c etc) are used via the panel drivers.
>
> right.. so we just need to expose the output drivers as separate
> entities, and let omapdrm propagate information such as timings
> between them
>
>>> in case of something like DVI bridge from DPI, this seems pretty
>>> straightforward.. only the connector needs to know about DDC stuff,
>>> which i2c to use and that sort of thing.  So at kms level we would
>>> have (for example) an omap_dpi_encoder which would be the same for DPI
>>> panel (connector) or DPI->DVI bridge.  For HDMI I'm still looking
>>> through the code to see how this would work.  Honestly I've looked
>>> less at this part of code and encoder related registers in the TRM,
>>> compared to the ovl/mgr parts, but at least from the 'DSS overview'
>>> picture in the TRM it seems to make sense ;-)
>>>
>>> KMS even exposes the idea that certain crtcs can connect to only
>>> certain encoders.  Or that you could you could have certain connectors
>>> switched between encoders.  For example if you had a hw w/ DPI out,
>>> and some mux to switch that back and forth between a DPI lcd panel and
>>> a DPI->DVI bridge.  (Ok, I'm not aware of any board that actually does
>>> this, but it is in theory possible.)  So we could expose possible
>>> video chain topologies to userspace in this way.
>>
>> OMAP3 SDP board has such a setup, with manual switch to select between
>> LCD and DVI.
>
> ahh, good to know.. so I'm not crazy for wanting to expose this
> possibility to userspace
>
>>> The other thing is that we don't need to propagate timings from the
>>> panel up to the mgr at the dss level.. kms is already handling this
>>> for us.  In my latest version, which I haven't pushed, I removed the
>>> 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'.
>>
>> You're thinking only about simple DPI cases. Consider this example, with
>> a DSI-to-DP bridge chip. What we have is the following flow of data:
>>
>> DISPC -> DSI -> DSI-2-DP -> DP monitor
>>
>> The timings you are thinking about are in the DISPC, but here they are
>> only one part of the link. And here the DISPC timings are not actually
>> the timings what the user is interested about. The user wants his
>> timings to be between DSI-2-DP chip and the DP monitor.
>>
>> Timings programmed to DISPC are not the same. The timings for DISPC come
>> from the DSI driver, and they may be very different than the user's
>> timings. With DSI video mode, the DISPC timings would have some
>> resemblance to the user's timings, mainly the time to send one line
>> would be the same. With DSI cmd mode, the DISPC timings would be
>> something totally different, most likely with 0 blank times and as fast
>> pixel clock as possible.
>
> hmm, well kms already has a concept of adjusted_timings, which could
> perhaps be used here to propagate the timings between crtc->encoder..
> although the order is probably backwards from what we want (it comes
> from the crtc to the encoder.. and if I understand properly we want it
> the other way and actually possibly from the connector).  But that
> isn't to say that internally in omapdrm the crtc couldn't get the
> adjusted timings from the connector.  So I still think the parameter
> flow doesn't need to be 'under the hood' in omapdss.
>
> And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper
> fxns, so if the way the core kms handles it isn't what we want, we can
> just plug in our own fxn instead of using drm_crtc_helper_set_mode(),
> so that isn't really a big problem.
>
>> What omapdss does currently is that you set the user's timings to the
>> right side of the chain, which propagate back to DSS. This allows the
>> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and
>> DSI driver will use DISPC timings that work optimally for it.
>>
>> And it's not only about timings above, but also other settings related
>> to the busses between the components. Clock 

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Seth Forshee]

On Fri, Aug 03, 2012 at 05:14:16PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> > Some Apple hybrid graphics machines do not have the LVDS panel connected
> > to the integrated GPU at boot and also do not supply a VBT. The LVDS
> > connector is not registered as a result, making it impossible to support
> > graphics switching.
> > 
> > This patch changes intel_lvds_init() to register the connector even if
> > we can't find any panel modes. This makes it necessary to always check
> > intel_lvds->fixed_mode before use, as it could now be NULL.
> 
> This one kind of sucks. I think adding a quirk for this situation would 
> be justifiable, rather than doing it for all devices.

This is one of the things I wasn't so sure about. There are various
checks in intel_lvds_init() that can cause it to bail out before we try
to get the EDID, and I don't fully understand all of them. If non-laptop
machines are expected to bail out before the EDID check then the
approach I've taken seems reasonable. Otherwise adding a quirk probably
is a good idea.

Seth

[RFC PATCH 5/5] drm/i915: check LVDS for EDID on GPU switches

[Seth Forshee]

If the LVDS panel wasn't connected at boot then we won't have an EDID
for it. To fix this, call intel_lvds_get_edid() from the vga_switcheroo
reprobe callback.

Signed-off-by: Seth Forshee 
---
 drivers/gpu/drm/i915/i915_dma.c   |1 +
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5b5176d..c9c942e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1266,6 +1266,7 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
 static void i915_switcheroo_reprobe(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
+   intel_lvds_get_edid(dev);
intel_fb_output_poll_changed(dev);
 }

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8435355..bcc14f9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -356,6 +356,7 @@ extern void intel_dvo_init(struct drm_device *dev);
 extern void intel_tv_init(struct drm_device *dev);
 extern void intel_mark_busy(struct drm_device *dev,
struct drm_i915_gem_object *obj);
+extern bool intel_lvds_get_edid(struct drm_device *dev);
 extern bool intel_lvds_init(struct drm_device *dev);
 extern void intel_dp_init(struct drm_device *dev, int dp_reg);
 void
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 9d05a90..39dbefc 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -902,7 +902,7 @@ static bool intel_lvds_supported(struct drm_device *dev)
return IS_MOBILE(dev) && !IS_I830(dev);
 }

-static bool intel_lvds_get_edid(struct drm_device *dev)
+bool intel_lvds_get_edid(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_connector *connector = dev_priv->int_lvds_connector;
-- 
1.7.9.5

[RFC PATCH 4/5] drm/i915: make intel_lvds_get_edid() more robust

[Seth Forshee]

intel_lvds_get_edid() needs to be called when switching GPUs, but it's
currently making assumptions that it will only be called once and that
there's always an LVDS connector present when it's called. Fix these
assumptions.

Signed-off-by: Seth Forshee 
---
 drivers/gpu/drm/i915/intel_lvds.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index c1ab632..9d05a90 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -906,9 +906,18 @@ static bool intel_lvds_get_edid(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_connector *connector = dev_priv->int_lvds_connector;
-   struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
+   struct intel_lvds *intel_lvds;
struct drm_display_mode *scan; /* *modes, *bios_mode; */

+   if (!connector)
+   return false;
+
+   intel_lvds = intel_attached_lvds(connector);
+
+   /* If we already have an EDID, no need to check again */
+   if (intel_lvds->edid)
+   return true;
+
/*
 * Attempt to get the fixed panel mode from DDC.  Assume that the
 * preferred mode is the right one.
@@ -939,6 +948,12 @@ static bool intel_lvds_get_edid(struct drm_device *dev)

list_for_each_entry(scan, >probed_modes, head) {
if (scan->type & DRM_MODE_TYPE_PREFERRED) {
+   /*
+* If we already have a preferred mode from another
+* source, prefer the one from the EDID.
+*/
+   if (intel_lvds->fixed_mode)
+   drm_mode_destroy(dev, intel_lvds->fixed_mode);
intel_lvds->fixed_mode =
drm_mode_duplicate(dev, scan);
intel_find_lvds_downclock(dev,
-- 
1.7.9.5

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Seth Forshee]

Some Apple hybrid graphics machines do not have the LVDS panel connected
to the integrated GPU at boot and also do not supply a VBT. The LVDS
connector is not registered as a result, making it impossible to support
graphics switching.

This patch changes intel_lvds_init() to register the connector even if
we can't find any panel modes. This makes it necessary to always check
intel_lvds->fixed_mode before use, as it could now be NULL.

Signed-off-by: Seth Forshee 
---
 drivers/gpu/drm/i915/intel_lvds.c |   48 +++--
 1 file changed, 19 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 5069137..c1ab632 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -161,6 +161,8 @@ static int intel_lvds_mode_valid(struct drm_connector 
*connector,
struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
struct drm_display_mode *fixed_mode = intel_lvds->fixed_mode;

+   if (!fixed_mode)
+   return MODE_PANEL;
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
if (mode->vdisplay > fixed_mode->vdisplay)
@@ -262,7 +264,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
 * with the panel scaling set up to source from the H/VDisplay
 * of the original mode.
 */
-   intel_fixed_panel_mode(intel_lvds->fixed_mode, adjusted_mode);
+   if (intel_lvds->fixed_mode)
+   intel_fixed_panel_mode(intel_lvds->fixed_mode, adjusted_mode);

if (HAS_PCH_SPLIT(dev)) {
intel_pch_panel_fitting(dev, intel_lvds->fitting_mode,
@@ -461,12 +464,13 @@ static int intel_lvds_get_modes(struct drm_connector 
*connector)
 {
struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
struct drm_device *dev = connector->dev;
-   struct drm_display_mode *mode;
+   struct drm_display_mode *mode = NULL;

if (intel_lvds->edid)
return drm_add_edid_modes(connector, intel_lvds->edid);

-   mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode);
+   if (intel_lvds->fixed_mode)
+   mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode);
if (mode == NULL)
return 0;

@@ -1073,26 +1077,21 @@ bool intel_lvds_init(struct drm_device *dev)
 */

/* Ironlake: FIXME if still fail, not try pipe mode now */
-   if (HAS_PCH_SPLIT(dev))
-   goto failed;
-
-   lvds = I915_READ(LVDS);
-   pipe = (lvds & LVDS_PIPEB_SELECT) ? 1 : 0;
-   crtc = intel_get_crtc_for_pipe(dev, pipe);
-
-   if (crtc && (lvds & LVDS_PORT_EN)) {
-   intel_lvds->fixed_mode = intel_crtc_mode_get(dev, crtc);
-   if (intel_lvds->fixed_mode) {
-   intel_lvds->fixed_mode->type |=
-   DRM_MODE_TYPE_PREFERRED;
-   goto out;
+   if (!HAS_PCH_SPLIT(dev)) {
+   lvds = I915_READ(LVDS);
+   pipe = (lvds & LVDS_PIPEB_SELECT) ? 1 : 0;
+   crtc = intel_get_crtc_for_pipe(dev, pipe);
+
+   if (crtc && (lvds & LVDS_PORT_EN)) {
+   intel_lvds->fixed_mode = intel_crtc_mode_get(dev, crtc);
+   if (intel_lvds->fixed_mode) {
+   intel_lvds->fixed_mode->type |=
+   DRM_MODE_TYPE_PREFERRED;
+   goto out;
+   }
}
}

-   /* If we still don't have a mode after all that, give up. */
-   if (!intel_lvds->fixed_mode)
-   goto failed;
-
 out:
/*
 * Unlock registers and just
@@ -1116,13 +1115,4 @@ out:
intel_panel_setup_backlight(dev);

return true;
-
-failed:
-   DRM_DEBUG_KMS("No LVDS modes found, disabling.\n");
-   dev_priv->int_lvds_connector = NULL;
-   drm_connector_cleanup(connector);
-   drm_encoder_cleanup(encoder);
-   kfree(intel_lvds);
-   kfree(intel_connector);
-   return false;
 }
-- 
1.7.9.5

[RFC PATCH 2/5] drm/i915: separate out code to get EDID from LVDS panel

[Seth Forshee]

This code will be reused to support hybrid graphics on some Apple
machines that can't get a mode for the LVDS panel at boot, so move it
into a new function named intel_lvds_get_edid().

Signed-off-by: Seth Forshee 
---
 drivers/gpu/drm/i915/intel_lvds.c |   95 +
 1 file changed, 55 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index e05c0d3..5069137 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -46,6 +46,7 @@ struct intel_lvds {

struct edid *edid;

+   u8 i2c_pin;
int fitting_mode;
u32 pfit_control;
u32 pfit_pgm_ratios;
@@ -897,6 +898,54 @@ static bool intel_lvds_supported(struct drm_device *dev)
return IS_MOBILE(dev) && !IS_I830(dev);
 }

+static bool intel_lvds_get_edid(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_connector *connector = dev_priv->int_lvds_connector;
+   struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
+   struct drm_display_mode *scan; /* *modes, *bios_mode; */
+
+   /*
+* Attempt to get the fixed panel mode from DDC.  Assume that the
+* preferred mode is the right one.
+*/
+   intel_lvds->edid = drm_get_edid(connector,
+   intel_gmbus_get_adapter(dev_priv,
+   
intel_lvds->i2c_pin));
+   if (intel_lvds->edid) {
+   if (drm_add_edid_modes(connector,
+  intel_lvds->edid)) {
+   drm_mode_connector_update_edid_property(connector,
+   
intel_lvds->edid);
+   } else {
+   kfree(intel_lvds->edid);
+   intel_lvds->edid = NULL;
+   }
+   }
+   if (!intel_lvds->edid) {
+   /* Didn't get an EDID, so
+* Set wide sync ranges so we get all modes
+* handed to valid_mode for checking
+*/
+   connector->display_info.min_vfreq = 0;
+   connector->display_info.max_vfreq = 200;
+   connector->display_info.min_hfreq = 0;
+   connector->display_info.max_hfreq = 200;
+   }
+
+   list_for_each_entry(scan, >probed_modes, head) {
+   if (scan->type & DRM_MODE_TYPE_PREFERRED) {
+   intel_lvds->fixed_mode =
+   drm_mode_duplicate(dev, scan);
+   intel_find_lvds_downclock(dev,
+ intel_lvds->fixed_mode,
+ connector);
+   return true;
+   }
+   }
+   return false;
+}
+
 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device
@@ -912,7 +961,6 @@ bool intel_lvds_init(struct drm_device *dev)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_encoder *encoder;
-   struct drm_display_mode *scan; /* *modes, *bios_mode; */
struct drm_crtc *crtc;
u32 lvds;
int pipe;
@@ -955,9 +1003,11 @@ bool intel_lvds_init(struct drm_device *dev)
intel_lvds->pfit_control = I915_READ(PFIT_CONTROL);
}

+   intel_lvds->i2c_pin = pin;
intel_encoder = _lvds->base;
encoder = _encoder->base;
connector = _connector->base;
+   dev_priv->int_lvds_connector = connector;
drm_connector_init(dev, _connector->base, 
_lvds_connector_funcs,
   DRM_MODE_CONNECTOR_LVDS);

@@ -991,6 +1041,7 @@ bool intel_lvds_init(struct drm_device *dev)
  dev->mode_config.scaling_mode_property,
  DRM_MODE_SCALE_ASPECT);
intel_lvds->fitting_mode = DRM_MODE_SCALE_ASPECT;
+
/*
 * LVDS discovery:
 * 1) check for EDID on DDC
@@ -1001,44 +1052,8 @@ bool intel_lvds_init(struct drm_device *dev)
 *if closed, act like it's not there for now
 */

-   /*
-* Attempt to get the fixed panel mode from DDC.  Assume that the
-* preferred mode is the right one.
-*/
-   intel_lvds->edid = drm_get_edid(connector,
-   intel_gmbus_get_adapter(dev_priv,
-   pin));
-   if (intel_lvds->edid) {
-   if (drm_add_edid_modes(connector,
-  intel_lvds->edid)) {
-   drm_mode_connector_update_edid_property(connector,
-   
intel_lvds->edid);
-   } else {
-   

[RFC PATCH 1/5] drm/i915: Add support for vga_switcheroo reprobe

[Seth Forshee]

From: Andreas Heider 

Signed-off-by: Andreas Heider 
---
 drivers/gpu/drm/i915/i915_dma.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9cf7dfe..5b5176d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1263,6 +1263,12 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
}
 }

+static void i915_switcheroo_reprobe(struct pci_dev *pdev)
+{
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   intel_fb_output_poll_changed(dev);
+}
+
 static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -1276,7 +1282,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)

 static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
.set_gpu_state = i915_switcheroo_set_state,
-   .reprobe = NULL,
+   .reprobe = i915_switcheroo_reprobe,
.can_switch = i915_switcheroo_can_switch,
 };

-- 
1.7.9.5

[RFC PATCH 0/5] i915 changes for hybrid graphics support on Macbooks

[Seth Forshee]

The following patches are part of a larger series I've been working on
to get vga_switcheroo working on hybrid graphics Macbooks. Some of these
machines are not providing a VBT, and since the LVDS panel is connected
to the discrete GPU at boot we can't get a mode for the panel during
initialization. As a result the LVDS connector is not registered with
DRM, and graphics switching is not possible.

These patches fix this issue by registering the connector even if we
can't get a mode for the panel. If we don't have an EDID we check again
from the vga_switcheroo reprobe callback.

This is working, except for the framebuffer console which isn't
displaying when switched to the integrated GPU, which I still need to
debug. I'm not entirely sure whether or not this is the correct approach
though, so I wanted to go ahead and get some feedback on the patches now
to make sure I'm on the right track.

Thanks,
Seth


Andreas Heider (1):
  drm/i915: Add support for vga_switcheroo reprobe

Seth Forshee (4):
  drm/i915: separate out code to get EDID from LVDS panel
  drm/i915: register LVDS connector even if we can't get a panel mode
  drm/i915: make intel_lvds_get_edid() more robust
  drm/i915: check LVDS for EDID on GPU switches

 drivers/gpu/drm/i915/i915_dma.c   |9 ++-
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |  156 +
 3 files changed, 97 insertions(+), 69 deletions(-)

Optimize i2f()

[Alex Deucher]

On Mon, Jul 30, 2012 at 5:49 PM, Steven Fuerst  wrote:
> Looking through the kernel radeon drm source, it looks like the i2f()
> functions in r600_blit.c and r600_blit_ksm() can be optimized a bit.

Care to send a patch?

Thanks,

Alex

>
> The following extends the range to all unsigned 32bit integers, and avoids
> the slow loop by using the bsr instruction via __fls().  It provides an
> exact 1-1 correspondence up to 2^24.  Above that, there is the inevitable
> rounding.  This routine rounds towards zero (truncation).
>
> /* 23 bits of float fractional data */
> #define I2F_FRAC_BITS 23
> #define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)
>
> /*
>  * Converts an unsigned integer into 32-bit IEEE floating point
> representation.
>  * Will be exact from 0 to 2^24.  Above that, we round towards zero
>  * as the fractional bits will not fit in a float.  (It would be better to
>  * round towards even as the fpu does, but that is slower.)
>  * This routine depends on the mod(32) behaviour of the rotate instructions
>  * on x86.
>  */
> uint32_t i2f(uint32_t x)
> {
> uint32_t msb, exponent, fraction;
>
> /* Zero is special */
> if (!x) return 0;
>
> /* Get location of the most significant bit */
> msb = __fls(x);
>
> /*
> * Use a rotate instead of a shift because that works both leftwards
> * and rightwards due to the mod(32) beahviour.  This means we don't
> * need to check to see if we are above 2^24 or not.
> */
> fraction = ror32(x, msb - I2F_FRAC_BITS) & I2F_MASK;
> exponent = (127 + msb) << I2F_FRAC_BITS;
>
> return fraction + exponent;
> }
>
> Steven Fuerst
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

[Zhang Rui]

On ?, 2012-08-02 at 21:45 -0400, Alex Deucher wrote:
> On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui  wrote:
> > On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
> >> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> >> > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> >> > > AMD ACPI interface may overload the standard event
> >> > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> >> > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> >> > > userspace because the user did not press the mode switch key (the
> >> > > spurious keypress confuses the DE which usually changes the
> >> > > display configuration and messes up a dual-screen setup).
> >> > > This patch gives the radeon driver the chance to examine the event and
> >> > > block the keypress if the event is an "AMD event".
> >> > >
> >> > > Signed-off-by: Luca Tettamanti 
> >> > > ---
> >> > > Any comment from ACPI front?
> >> > >
> >> > it looks good to me.
> >> > But I'm wondering if we can use the following code for ACPI part, which
> >> > looks cleaner.
> >> > I know this may change the behavior of other events, but in theory, we
> >> > should not send any input event if we know something wrong in kernel.
> >> >
> >> > what do you think?
> >>
> >> I like it, it's cleaner.
> >> I've split the patch in two pieces (one for video, the other for
> >> radeon) and adopted your suggestion.
> >>
> > Great.
> > Acked-by: Zhang Rui 
> >
> > hmm, who should take these two patches?
> 
> I'm happy to take the patches.
> 
> > and which tree the second patch is based on?
> 
> I've got a tree with all the radeon ACPI patches on the acpi_patches
> branches of my git tree:
> git://people.freedesktop.org/~agd5f/linux
> 
great.

thanks,
rui

[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Michel Dänzer]

On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: 
> 1, Handle io prot correctly for MIPS.
> 2, Define SAREA_MAX as the size of one page.
> 3, Include swiotlb.h if SWIOTLB configured.
> 
> Signed-off-by: Huacai Chen 
> Signed-off-by: Hongliang Tao 
> Signed-off-by: Hua Yan 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_vm.c|2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c |4 
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>  include/drm/drm_sarea.h |2 ++
>  4 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 961ee08..3f06166 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> vm_area_struct *vma)
>   tmp = pgprot_writecombine(tmp);
>   else
>   tmp = pgprot_noncached(tmp);
> -#elif defined(__sparc__) || defined(__arm__)
> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>   tmp = pgprot_noncached(tmp);
>  #endif
>   return tmp;
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 5b71c71..fc3ac22 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -41,6 +41,10 @@
>  #include "radeon_reg.h"
>  #include "radeon.h"
>  
> +#ifdef CONFIG_SWIOTLB
> +#include 
> +#endif
> +
>  #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)
>  
>  static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f8187ea..0df71ea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>   else
>   tmp = pgprot_noncached(tmp);
>  #endif
> -#if defined(__sparc__)
> +#if defined(__sparc__) || defined(__mips__)
>   if (!(caching_flags & TTM_PL_FLAG_CACHED))
>   tmp = pgprot_noncached(tmp);
>  #endif
> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
> index ee5389d..1d1a858 100644
> --- a/include/drm/drm_sarea.h
> +++ b/include/drm/drm_sarea.h
> @@ -37,6 +37,8 @@
>  /* SAREA area needs to be at least a page */
>  #if defined(__alpha__)
>  #define SAREA_MAX   0x2000U
> +#elif defined(__mips__)
> +#define SAREA_MAX   0x4000U
>  #elif defined(__ia64__)
>  #define SAREA_MAX   0x1U /* 64kB */
>  #else

This should be four separate patches.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

[Zhang Rui]

On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> > > AMD ACPI interface may overload the standard event
> > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> > > userspace because the user did not press the mode switch key (the
> > > spurious keypress confuses the DE which usually changes the
> > > display configuration and messes up a dual-screen setup).
> > > This patch gives the radeon driver the chance to examine the event and
> > > block the keypress if the event is an "AMD event".
> > > 
> > > Signed-off-by: Luca Tettamanti 
> > > ---
> > > Any comment from ACPI front?
> > > 
> > it looks good to me.
> > But I'm wondering if we can use the following code for ACPI part, which
> > looks cleaner.
> > I know this may change the behavior of other events, but in theory, we
> > should not send any input event if we know something wrong in kernel.
> > 
> > what do you think?
> 
> I like it, it's cleaner.
> I've split the patch in two pieces (one for video, the other for
> radeon) and adopted your suggestion.
> 
Great.
Acked-by: Zhang Rui 

hmm, who should take these two patches?
and which tree the second patch is based on?

thanks,
rui

[PATCH v2] of: Add videomode helper

[Sascha Hauer]

Hi Stephen,

On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> > This patch adds a helper function for parsing videomodes from the 
> > devicetree.
> > The videomode can be either converted to a struct drm_display_mode or a
> > struct fb_videomode.
> 
> > diff --git a/Documentation/devicetree/bindings/video/displaymode 
> > b/Documentation/devicetree/bindings/video/displaymode
> 
> > +Required properties:
> > + - xres, yres: Display resolution
> > + - left-margin, right-margin, hsync-len: Horizontal Display timing 
> > parameters
> > +   in pixels
> > +   upper-margin, lower-margin, vsync-len: Vertical display timing 
> > parameters in
> > +   lines
> 
> Perhaps bike-shedding, but...
> 
> For the margin property names, wouldn't it be better to use terminology
> more commonly used for video timings rather than Linux FB naming. In
> other words naming like:
> 
> hactive, hsync-len, hfront-porch, hback-porch?

Can do. Just to make sure:

hactive == xres
hsync-len == hsync-len
hfront-porch == right-margin
hback-porch == left-margin

?

> 
> This node appears to describe a video mode, not a display, hence the
> node name seems wrong.
> 
> Many displays can support multiple different video modes. As mentioned
> elsewhere, properties like display width/height are properties of the
> display not the mode.
> 
> So, I might expect something more like the following (various overhead
> properties like reg/#address-cells etc. elided for simplicity):
> 
> disp: display {
> width-mm = <...>;
> height-mm = <...>;
> modes {
> mode at 0 {
>   /* 1920x1080p24 */
>   clock = <5200>;
>   xres = <1920>;
>   yres = <1080>;
>   left-margin = <25>;
>   right-margin = <25>;
>   hsync-len = <25>;
>   lower-margin = <2>;
>   upper-margin = <2>;
>   vsync-len = <2>;
>   hsync-active-high;
> };
> mode at 1 {
> };
> };
> };

Ok, we can do this.

> 
> display-connector {
> display = <>;
> // interface-specific properties such as pixel format here
> };
> 
> Finally, have you considered just using an EDID instead of creating
> something custom? I know that creating an EDID is harder than writing a
> few simple properties into a DT, but EDIDs have the following advantages:

I have considered using EDID and I also tried it. It's painful. There
are no (open) tools available for creating EDID. That's something we
could change of course. Then when generating a devicetree there is
always an extra step involved creating the EDID blob. Once the EDID
blob is in devicetree it is not parsable anymore by mere humans, so
to see what we've got there is another tool involved to generate a
readable form again.

> 
> a) They're already standardized and very common.

Indeed, that's a big plus for EDID. I have no intention of removing EDID
data from the devicetree. There are situations where EDID is handy, for
example when you get EDID data provided by your vendor.

> 
> b) They allow other information such as a display's HDMI audio
> capabilities to be represented, which can then feed into an ALSA driver.
> 
> c) The few LCD panel datasheets I've seen actually quote their
> specification as an EDID already, so deriving the EDID may actually be easy.
> 
> d) People familiar with displays are almost certainly familiar with
> EDID's mode representation. There are many ways of representing display
> modes (sync position vs. porch widths, htotal specified rather than
> specifying all the components and hence htotal being calculated etc.).
> Not everyone will be familiar with all representations. Conversion
> errors are less likely if the target is EDID's familiar format.

You seem to think about a different class of displays for which EDID
indeed is a better way to handle. What I have to deal with here mostly
are dumb displays which:

- can only handle their native resolution
- Have no audio capabilities at all
- come with a datasheet which specify a min/typ/max triplet for
  xres,hsync,..., often enough they are scanned to pdf from some previously
  printed paper.

These displays are very common on embedded devices, probably that's the
reason I did not even think about the possibility that a single display
might have different modes.

> 
> e) You'll end up with exactly the same data as if you have a DDC-based
> external monitor rather than an internal panel, so you end up getting to
> a common path in display handling code much more quickly.

All we have in our display driver currently is:

edidp = of_get_property(np, "edid", >edid_len);
if (edidp) {
imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
} else {
ret = of_get_video_mode(np, >mode, NULL);
if (!ret)
imxpd->mode_valid = 1;
}

Sascha

-- 

[PATCH] drm: ignore disconnected <-> unknown status changes

[Alex Deucher]

On Thu, Aug 2, 2012 at 3:21 AM, Knut Petersen  
wrote:
> On an AOpen i915GMm-hfs the hotplug events generated
> by transitions between connector_status_unknown and
> connector_status_disconnected cause screen distortions.
>
> The attached patch cures the problem by disabling the
> generation of hotplug events in those cases. That should
> be safe for everybody as the only relevant changes are
> those from / to connector_status_connected.

Seems reasonable to me.  We should just drop unknown.

Reviewed-by: Alex Deucher 

>
> cu,
>  Knut
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #90 from Michel D?nzer  2012-08-03 08:13:03 
UTC ---
(In reply to comment #89)
> Nope, no lockup without va (I may only be lucky though if the bug is there but
> only shown when using va).

That's indeed possible: Using virtual address space will catch out of bounds
memory access that may otherwise go unnoticed.

So, I think in this report we should focus on the rendering regression(s), and
track the lockups in other reports.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #89 from Alexandre Demers  
2012-08-03 08:05:07 UTC ---
(In reply to comment #88)
> (In reply to comment #86)
> > So, Anthony has put a finger on something.
> 
> Yes, I think something like Anthony's patch is needed due to asynchronous GPU
> processing: when the userspace driver assigns virtual address space for a new
> BO, the GPU may not have finished processing command streams using previous 
> BOs
> occupying that same virtual address space.
> 
> However, the userspace driver shouldn't wait synchronously for the BO to go
> idle when destroying it but should instead defer destruction (or at least the
> freeing of the virtual address space) until it notices the BO has become idle.
> 
> 
> > With Anthony's patch, I'm still able to lock the display everytime
> 
> And these lockups do not happen when not using virtual address space? Can you
> provide the dmesg output of the GPU reset for such a lockup? Ideally from a
> single piglit test reproducing it.

Nope, no lockup without va (I may only be lucky though if the bug is there but
only shown when using va). I'll try to find a way to get dmesg... It has been a
problem since the start for that part, but I may be able to use another
computer to log in remotely. May take a couple of days to do though.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52997

--- Comment #2 from Michel D?nzer  2012-08-03 07:49:18 
UTC ---
Please attach the /var/log/Xorg.0.log file.

Which version of libdrm_radeon are you using?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #88 from Michel D?nzer  2012-08-03 07:47:17 
UTC ---
(In reply to comment #86)
> So, Anthony has put a finger on something.

Yes, I think something like Anthony's patch is needed due to asynchronous GPU
processing: when the userspace driver assigns virtual address space for a new
BO, the GPU may not have finished processing command streams using previous BOs
occupying that same virtual address space.

However, the userspace driver shouldn't wait synchronously for the BO to go
idle when destroying it but should instead defer destruction (or at least the
freeing of the virtual address space) until it notices the BO has become idle.


> With Anthony's patch, I'm still able to lock the display everytime

And these lockups do not happen when not using virtual address space? Can you
provide the dmesg output of the GPU reset for such a lockup? Ideally from a
single piglit test reproducing it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFC 0/3] solving omapdrm/omapdss layering issues

[Rob Clark]

On Fri, Aug 3, 2012 at 1:01 AM, Semwal, Sumit  wrote:
> Hi Rob, Tomi,
> On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark  wrote:
>> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen  
>> wrote:
>>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
 On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen  
 wrote:
 > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
 >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> >> ti.com> wrote:
 >
 >> > I guess the fact is that DRM concepts do not really match the OMAP DSS
 >> > hardware, and we'll have to use whatever gives us least problems.
 >>
 >> Actually, I think it does map fairly well to the hardware.. at least
 >> more so than to omapdss ;-)
 >
 > Hm, I'm not sure I understand, omapdss concepts map directly to the
 > hardware.

 I think it is mainly exposing the encoder and panel as two separate
 entities.. which seems to be what Archit is working on
>>>
>>> I still don't follow =) They are separate entities. Omapdss models the
>>> HW quite directly, I think. It doesn't expose everything, though, as the
>>> output drivers (dsi.c, dpi.c etc) are used via the panel drivers.
>>
>> right.. so we just need to expose the output drivers as separate
>> entities, and let omapdrm propagate information such as timings
>> between them
>>
 in case of something like DVI bridge from DPI, this seems pretty
 straightforward.. only the connector needs to know about DDC stuff,
 which i2c to use and that sort of thing.  So at kms level we would
 have (for example) an omap_dpi_encoder which would be the same for DPI
 panel (connector) or DPI->DVI bridge.  For HDMI I'm still looking
 through the code to see how this would work.  Honestly I've looked
 less at this part of code and encoder related registers in the TRM,
 compared to the ovl/mgr parts, but at least from the 'DSS overview'
 picture in the TRM it seems to make sense ;-)

 KMS even exposes the idea that certain crtcs can connect to only
 certain encoders.  Or that you could you could have certain connectors
 switched between encoders.  For example if you had a hw w/ DPI out,
 and some mux to switch that back and forth between a DPI lcd panel and
 a DPI->DVI bridge.  (Ok, I'm not aware of any board that actually does
 this, but it is in theory possible.)  So we could expose possible
 video chain topologies to userspace in this way.
>>>
>>> OMAP3 SDP board has such a setup, with manual switch to select between
>>> LCD and DVI.
>>
>> ahh, good to know.. so I'm not crazy for wanting to expose this
>> possibility to userspace
>>
 The other thing is that we don't need to propagate timings from the
 panel up to the mgr at the dss level.. kms is already handling this
 for us.  In my latest version, which I haven't pushed, I removed the
 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'.
>>>
>>> You're thinking only about simple DPI cases. Consider this example, with
>>> a DSI-to-DP bridge chip. What we have is the following flow of data:
>>>
>>> DISPC -> DSI -> DSI-2-DP -> DP monitor
>>>
>>> The timings you are thinking about are in the DISPC, but here they are
>>> only one part of the link. And here the DISPC timings are not actually
>>> the timings what the user is interested about. The user wants his
>>> timings to be between DSI-2-DP chip and the DP monitor.
>>>
>>> Timings programmed to DISPC are not the same. The timings for DISPC come
>>> from the DSI driver, and they may be very different than the user's
>>> timings. With DSI video mode, the DISPC timings would have some
>>> resemblance to the user's timings, mainly the time to send one line
>>> would be the same. With DSI cmd mode, the DISPC timings would be
>>> something totally different, most likely with 0 blank times and as fast
>>> pixel clock as possible.
>>
>> hmm, well kms already has a concept of adjusted_timings, which could
>> perhaps be used here to propagate the timings between crtc->encoder..
>> although the order is probably backwards from what we want (it comes
>> from the crtc to the encoder.. and if I understand properly we want it
>> the other way and actually possibly from the connector).  But that
>> isn't to say that internally in omapdrm the crtc couldn't get the
>> adjusted timings from the connector.  So I still think the parameter
>> flow doesn't need to be 'under the hood' in omapdss.
>>
>> And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper
>> fxns, so if the way the core kms handles it isn't what we want, we can
>> just plug in our own fxn instead of using drm_crtc_helper_set_mode(),
>> so that isn't really a big problem.
>>
>>> What omapdss does currently is that you set the user's timings to the
>>> right side of the chain, which propagate back to DSS. This allows the
>>> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and
>>> DSI driver will use DISPC timings 

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #87 from Alexandre Demers  
2012-08-03 06:03:39 UTC ---
(In reply to comment #86)
> (In reply to comment #85)
> > I found a demo that has the issue, in the demos repository for mesa within 
> > the
> > src/demo folder the program 'reflect'.  After I start it up and press 's' to
> > see the stencil buffer the white plan blinks continuously.  Applying the 
> > patch
> > 'fixes to wait on the bo and to free the va after the kernel' removes the
> > blinking, as does disabling va through the variable
> > ws->info.r600_virtual_address.
> > 
> > The other issue with the kernel reporting a va conflict is going to be a 
> > little
> > harder to reproduce because it appears to be caused by a race condition.
> > 
> > I'll still look for other demos that have the issue.
> 
> Yes, I understand it can be hard to track for you Jerome. Well for the va
> issue, on my side, it is as simple as logging in KDE or Gnome 3. Before 
> logging
> in, there is no va error in dmesg. Once I'm in, there are usually 3 or
> sometimes 6 errors (they are written in block of 3, so I suspect it tries a
> first time and for some reason it fails and try again second time).
> 
> I also experience the issue when watching some movies. With Anthony's patch, 
> va
> issues are gone and I watched a couple of shows yesterday without any problem.
> Before the patch, it would blink and get corrupted after about 16 minutes and
> then crash. So, Anthony has put a finger on something.
> 
> However, I also run piglit tests and some other applications like
> RendererFeatTest64 (which is an application released before Amnesia went out 
> to
> test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm
> still able to lock the display everytime (if I play music at the same time, it
> will continue to play but I won't be able to change terminal even if sometimes
> my mouse pointer can still be moved). RendererFeatTest64 will always lock at
> the same test, but it is not the same for piglit tests (even if it happens
> often at the same or near the same).
> 
> I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches
> (by the way, they can't be applied on latest drm-next branch) and I'll tell 
> you
> if I'm still experiencing the lockups. I'll also try Anthony's test to see if 
> I
> get the same results (blinking without his patch, OK with it)

Well it still locks up even with the patches. I also tested the reflect demo
and I don't have any blink without Anthony's patch, but we may be experiencing
different symptoms of the same problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #86 from Alexandre Demers  
2012-08-03 03:00:00 UTC ---
(In reply to comment #85)
> I found a demo that has the issue, in the demos repository for mesa within the
> src/demo folder the program 'reflect'.  After I start it up and press 's' to
> see the stencil buffer the white plan blinks continuously.  Applying the patch
> 'fixes to wait on the bo and to free the va after the kernel' removes the
> blinking, as does disabling va through the variable
> ws->info.r600_virtual_address.
> 
> The other issue with the kernel reporting a va conflict is going to be a 
> little
> harder to reproduce because it appears to be caused by a race condition.
> 
> I'll still look for other demos that have the issue.

Yes, I understand it can be hard to track for you Jerome. Well for the va
issue, on my side, it is as simple as logging in KDE or Gnome 3. Before logging
in, there is no va error in dmesg. Once I'm in, there are usually 3 or
sometimes 6 errors (they are written in block of 3, so I suspect it tries a
first time and for some reason it fails and try again second time).

I also experience the issue when watching some movies. With Anthony's patch, va
issues are gone and I watched a couple of shows yesterday without any problem.
Before the patch, it would blink and get corrupted after about 16 minutes and
then crash. So, Anthony has put a finger on something.

However, I also run piglit tests and some other applications like
RendererFeatTest64 (which is an application released before Amnesia went out to
test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm
still able to lock the display everytime (if I play music at the same time, it
will continue to play but I won't be able to change terminal even if sometimes
my mouse pointer can still be moved). RendererFeatTest64 will always lock at
the same test, but it is not the same for piglit tests (even if it happens
often at the same or near the same).

I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches
(by the way, they can't be applied on latest drm-next branch) and I'll tell you
if I'm still experiencing the lockups. I'll also try Anthony's test to see if I
get the same results (blinking without his patch, OK with it)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #85 from Anthony Waters  2012-08-03 02:07:06 
UTC ---
I found a demo that has the issue, in the demos repository for mesa within the
src/demo folder the program 'reflect'.  After I start it up and press 's' to
see the stencil buffer the white plan blinks continuously.  Applying the patch
'fixes to wait on the bo and to free the va after the kernel' removes the
blinking, as does disabling va through the variable
ws->info.r600_virtual_address.

The other issue with the kernel reporting a va conflict is going to be a little
harder to reproduce because it appears to be caused by a race condition.

I'll still look for other demos that have the issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #84 from Anthony Waters  2012-08-03 01:28:25 
UTC ---
I randomly saw it when I was playing a game of Warcraft 3, the terrain textures
would blink.  I'll check the piglit tests and mesa demos to see if I can
reproduce the issue with them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Hans,

On Thursday 02 August 2012 09:08:18 Hans Verkuil wrote:
> On Thu August 2 2012 08:56:43 R?mi Denis-Courmont wrote:
> > Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> > > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > > runtime ?
> > > > 
> > > > Does CREATE_BUFS always work while already streaming has already
> > > > started? If it depends on the driver, it's kinda helpless.
> > > 
> > > Yes, it does. It's one of the reasons it exists in the first place. But
> > > there are currently only a handful of drivers that implement it. I hope
> > > that as more and more drivers are converted to vb2 that the availability
> > > of create_bufs will increase.
> > 
> > That's contradictory. If most drivers do not support it, then it won't
> > work during streaming.
> 
> IF create_bufs is implemented in the driver, THEN you can use it during
> streaming. I.e., it will never return EBUSY as an error due to the fact
> that streaming is in progress.
> 
> Obviously it won't work if the driver didn't implement it in the first
> place.
>
> > > > What's the guaranteed minimum buffer count? It seems in any case, MMAP
> > > > has a hard limit of 32 buffers (at least videobuf2 has), though one
> > > > might argue this should be more than enough.
> > > 
> > > Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2
> > > core. Although drivers may force a lower maximum if they want. I have no
> > > idea whether there are drivers that do that. There probably are.
> > 
> > The smallest of the maxima of all drivers.
> 
> I've no idea. Most will probably abide by the 32 maximum, but without
> analyzing all drivers I can't guarantee it.
> 
> > > The minimum is usually between 1 and 3, depending on hardware
> > > limitations.
> > 
> > And that's clearly insufficient without memory copy to userspace buffers.
> > 
> > It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for
> > REQBUFS+USERBUF then.
> 
> Just to put your mind at rest: USERPTR mode will *not* disappear or be
> deprecated in any way. It's been there for a long time, it's in heavy use,
> it's easy to use and it will not be turned into a second class citizen,
> because it isn't. Just because there is a new dmabuf mode available doesn't
> mean that everything should be done as a mmap+dmabuf thing.

I disagree with this. Not everything should obviously be done with MMAP + 
DMABUF, but for buffer sharing between devices, we should encourage 
application developers to use DMABUF instead of USERPTR.

-- 
Regards,

Laurent Pinchart

[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi R?mi,

On Thursday 02 August 2012 09:56:43 R?mi Denis-Courmont wrote:
> Le jeudi 2 ao?t 2012 09:35:58 Hans Verkuil, vous avez ?crit :
> > On Wed August 1 2012 22:49:57 R?mi Denis-Courmont wrote:
> > > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at
> > > > runtime ?
> > > 
> > > Does CREATE_BUFS always work while already streaming has already
> > > started?
> > > If it depends on the driver, it's kinda helpless.
> > 
> > Yes, it does. It's one of the reasons it exists in the first place. But
> > there are currently only a handful of drivers that implement it. I hope
> > that as more and more drivers are converted to vb2 that the availability
> > of create_bufs will increase.
> 
> That's contradictory. If most drivers do not support it, then it won't work
> during streaming.
> 
> > > What's the guaranteed minimum buffer count? It seems in any case, MMAP
> > > has a hard limit of 32 buffers (at least videobuf2 has), though one
> > > might argue this should be more than enough.
> > 
> > Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core.
> > Although drivers may force a lower maximum if they want. I have no idea
> > whether there are drivers that do that. There probably are.
> 
> The smallest of the maxima of all drivers.
> 
> > The minimum is usually between 1 and 3, depending on hardware limitations.
> 
> And that's clearly insufficient without memory copy to userspace buffers.

That's the minimum number of buffers *required* by the hardware. You can add 
up to 32 buffers, I'm not aware of any driver that would prevent that.

> It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for
> REQBUFS+USERBUF then.

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

[Zhang Rui]

On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
 On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
  On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
   AMD ACPI interface may overload the standard event
   ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
   cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
   userspace because the user did not press the mode switch key (the
   spurious keypress confuses the DE which usually changes the
   display configuration and messes up a dual-screen setup).
   This patch gives the radeon driver the chance to examine the event and
   block the keypress if the event is an AMD event.
   
   Signed-off-by: Luca Tettamanti kronos...@gmail.com
   ---
   Any comment from ACPI front?
   
  it looks good to me.
  But I'm wondering if we can use the following code for ACPI part, which
  looks cleaner.
  I know this may change the behavior of other events, but in theory, we
  should not send any input event if we know something wrong in kernel.
  
  what do you think?
 
 I like it, it's cleaner.
 I've split the patch in two pieces (one for video, the other for
 radeon) and adopted your suggestion.
 
Great.
Acked-by: Zhang Rui rui.zh...@intel.com

hmm, who should take these two patches?
and which tree the second patch is based on?

thanks,
rui

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events

[Zhang Rui]

On 四, 2012-08-02 at 21:45 -0400, Alex Deucher wrote:
 On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui rui.zh...@intel.com wrote:
  On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote:
  On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
   On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
AMD ACPI interface may overload the standard event
ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
userspace because the user did not press the mode switch key (the
spurious keypress confuses the DE which usually changes the
display configuration and messes up a dual-screen setup).
This patch gives the radeon driver the chance to examine the event and
block the keypress if the event is an AMD event.
   
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
Any comment from ACPI front?
   
   it looks good to me.
   But I'm wondering if we can use the following code for ACPI part, which
   looks cleaner.
   I know this may change the behavior of other events, but in theory, we
   should not send any input event if we know something wrong in kernel.
  
   what do you think?
 
  I like it, it's cleaner.
  I've split the patch in two pieces (one for video, the other for
  radeon) and adopted your suggestion.
 
  Great.
  Acked-by: Zhang Rui rui.zh...@intel.com
 
  hmm, who should take these two patches?
 
 I'm happy to take the patches.
 
  and which tree the second patch is based on?
 
 I've got a tree with all the radeon ACPI patches on the acpi_patches
 branches of my git tree:
 git://people.freedesktop.org/~agd5f/linux
 
great.

thanks,
rui

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/3] solving omapdrm/omapdss layering issues

[Semwal, Sumit]

Hi Rob, Tomi,
On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
 On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
  On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
  On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
 
   I guess the fact is that DRM concepts do not really match the OMAP DSS
   hardware, and we'll have to use whatever gives us least problems.
 
  Actually, I think it does map fairly well to the hardware.. at least
  more so than to omapdss ;-)
 
  Hm, I'm not sure I understand, omapdss concepts map directly to the
  hardware.

 I think it is mainly exposing the encoder and panel as two separate
 entities.. which seems to be what Archit is working on

 I still don't follow =) They are separate entities. Omapdss models the
 HW quite directly, I think. It doesn't expose everything, though, as the
 output drivers (dsi.c, dpi.c etc) are used via the panel drivers.

 right.. so we just need to expose the output drivers as separate
 entities, and let omapdrm propagate information such as timings
 between them

 in case of something like DVI bridge from DPI, this seems pretty
 straightforward.. only the connector needs to know about DDC stuff,
 which i2c to use and that sort of thing.  So at kms level we would
 have (for example) an omap_dpi_encoder which would be the same for DPI
 panel (connector) or DPI-DVI bridge.  For HDMI I'm still looking
 through the code to see how this would work.  Honestly I've looked
 less at this part of code and encoder related registers in the TRM,
 compared to the ovl/mgr parts, but at least from the 'DSS overview'
 picture in the TRM it seems to make sense ;-)

 KMS even exposes the idea that certain crtcs can connect to only
 certain encoders.  Or that you could you could have certain connectors
 switched between encoders.  For example if you had a hw w/ DPI out,
 and some mux to switch that back and forth between a DPI lcd panel and
 a DPI-DVI bridge.  (Ok, I'm not aware of any board that actually does
 this, but it is in theory possible.)  So we could expose possible
 video chain topologies to userspace in this way.

 OMAP3 SDP board has such a setup, with manual switch to select between
 LCD and DVI.

 ahh, good to know.. so I'm not crazy for wanting to expose this
 possibility to userspace

 The other thing is that we don't need to propagate timings from the
 panel up to the mgr at the dss level.. kms is already handling this
 for us.  In my latest version, which I haven't pushed, I removed the
 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'.

 You're thinking only about simple DPI cases. Consider this example, with
 a DSI-to-DP bridge chip. What we have is the following flow of data:

 DISPC - DSI - DSI-2-DP - DP monitor

 The timings you are thinking about are in the DISPC, but here they are
 only one part of the link. And here the DISPC timings are not actually
 the timings what the user is interested about. The user wants his
 timings to be between DSI-2-DP chip and the DP monitor.

 Timings programmed to DISPC are not the same. The timings for DISPC come
 from the DSI driver, and they may be very different than the user's
 timings. With DSI video mode, the DISPC timings would have some
 resemblance to the user's timings, mainly the time to send one line
 would be the same. With DSI cmd mode, the DISPC timings would be
 something totally different, most likely with 0 blank times and as fast
 pixel clock as possible.

 hmm, well kms already has a concept of adjusted_timings, which could
 perhaps be used here to propagate the timings between crtc-encoder..
 although the order is probably backwards from what we want (it comes
 from the crtc to the encoder.. and if I understand properly we want it
 the other way and actually possibly from the connector).  But that
 isn't to say that internally in omapdrm the crtc couldn't get the
 adjusted timings from the connector.  So I still think the parameter
 flow doesn't need to be 'under the hood' in omapdss.

 And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper
 fxns, so if the way the core kms handles it isn't what we want, we can
 just plug in our own fxn instead of using drm_crtc_helper_set_mode(),
 so that isn't really a big problem.

 What omapdss does currently is that you set the user's timings to the
 right side of the chain, which propagate back to DSS. This allows the
 DSI-2-DP bridge use DSI timings that work optimally for the bridge, and
 DSI driver will use DISPC timings that work optimally for it.

 And it's not only about timings above, but also other settings related
 to the busses between the components. Clock dividers, polarities, stuff
 like that.

 I expect we could handle other settings in the same way as the timings.

 I think the problem was there were some 

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #87 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-03 
06:03:39 UTC ---
(In reply to comment #86)
 (In reply to comment #85)
  I found a demo that has the issue, in the demos repository for mesa within 
  the
  src/demo folder the program 'reflect'.  After I start it up and press 's' to
  see the stencil buffer the white plan blinks continuously.  Applying the 
  patch
  'fixes to wait on the bo and to free the va after the kernel' removes the
  blinking, as does disabling va through the variable
  ws-info.r600_virtual_address.
  
  The other issue with the kernel reporting a va conflict is going to be a 
  little
  harder to reproduce because it appears to be caused by a race condition.
  
  I'll still look for other demos that have the issue.
 
 Yes, I understand it can be hard to track for you Jerome. Well for the va
 issue, on my side, it is as simple as logging in KDE or Gnome 3. Before 
 logging
 in, there is no va error in dmesg. Once I'm in, there are usually 3 or
 sometimes 6 errors (they are written in block of 3, so I suspect it tries a
 first time and for some reason it fails and try again second time).
 
 I also experience the issue when watching some movies. With Anthony's patch, 
 va
 issues are gone and I watched a couple of shows yesterday without any problem.
 Before the patch, it would blink and get corrupted after about 16 minutes and
 then crash. So, Anthony has put a finger on something.
 
 However, I also run piglit tests and some other applications like
 RendererFeatTest64 (which is an application released before Amnesia went out 
 to
 test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm
 still able to lock the display everytime (if I play music at the same time, it
 will continue to play but I won't be able to change terminal even if sometimes
 my mouse pointer can still be moved). RendererFeatTest64 will always lock at
 the same test, but it is not the same for piglit tests (even if it happens
 often at the same or near the same).
 
 I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches
 (by the way, they can't be applied on latest drm-next branch) and I'll tell 
 you
 if I'm still experiencing the lockups. I'll also try Anthony's test to see if 
 I
 get the same results (blinking without his patch, OK with it)

Well it still locks up even with the patches. I also tested the reflect demo
and I don't have any blink without Anthony's patch, but we may be experiencing
different symptoms of the same problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Huacai Chen]

1, Handle io prot correctly for MIPS.
2, Define SAREA_MAX as the size of one page.
3, Include swiotlb.h if SWIOTLB configured.

Signed-off-by: Huacai Chen che...@lemote.com
Signed-off-by: Hongliang Tao ta...@lemote.com
Signed-off-by: Hua Yan y...@lemote.com
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_vm.c|2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |4 
 drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
 include/drm/drm_sarea.h |2 ++
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
 #endif
return tmp;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5b71c71..fc3ac22 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -41,6 +41,10 @@
 #include radeon_reg.h
 #include radeon.h
 
+#ifdef CONFIG_SWIOTLB
+#include linux/swiotlb.h
+#endif
+
 #define DRM_FILE_PAGE_OFFSET (0x1ULL  PAGE_SHIFT)
 
 static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
else
tmp = pgprot_noncached(tmp);
 #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
if (!(caching_flags  TTM_PL_FLAG_CACHED))
tmp = pgprot_noncached(tmp);
 #endif
diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
index ee5389d..1d1a858 100644
--- a/include/drm/drm_sarea.h
+++ b/include/drm/drm_sarea.h
@@ -37,6 +37,8 @@
 /* SAREA area needs to be at least a page */
 #if defined(__alpha__)
 #define SAREA_MAX   0x2000U
+#elif defined(__mips__)
+#define SAREA_MAX   0x4000U
 #elif defined(__ia64__)
 #define SAREA_MAX   0x1U   /* 64kB */
 #else
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] of: Add videomode helper

[Sascha Hauer]

Hi Stephen,

On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
 On 07/04/2012 01:56 AM, Sascha Hauer wrote:
  This patch adds a helper function for parsing videomodes from the 
  devicetree.
  The videomode can be either converted to a struct drm_display_mode or a
  struct fb_videomode.
 
  diff --git a/Documentation/devicetree/bindings/video/displaymode 
  b/Documentation/devicetree/bindings/video/displaymode
 
  +Required properties:
  + - xres, yres: Display resolution
  + - left-margin, right-margin, hsync-len: Horizontal Display timing 
  parameters
  +   in pixels
  +   upper-margin, lower-margin, vsync-len: Vertical display timing 
  parameters in
  +   lines
 
 Perhaps bike-shedding, but...
 
 For the margin property names, wouldn't it be better to use terminology
 more commonly used for video timings rather than Linux FB naming. In
 other words naming like:
 
 hactive, hsync-len, hfront-porch, hback-porch?

Can do. Just to make sure:

hactive == xres
hsync-len == hsync-len
hfront-porch == right-margin
hback-porch == left-margin

?

 
 This node appears to describe a video mode, not a display, hence the
 node name seems wrong.
 
 Many displays can support multiple different video modes. As mentioned
 elsewhere, properties like display width/height are properties of the
 display not the mode.
 
 So, I might expect something more like the following (various overhead
 properties like reg/#address-cells etc. elided for simplicity):
 
 disp: display {
 width-mm = ...;
 height-mm = ...;
 modes {
 mode@0 {
   /* 1920x1080p24 */
   clock = 5200;
   xres = 1920;
   yres = 1080;
   left-margin = 25;
   right-margin = 25;
   hsync-len = 25;
   lower-margin = 2;
   upper-margin = 2;
   vsync-len = 2;
   hsync-active-high;
 };
 mode@1 {
 };
 };
 };

Ok, we can do this.

 
 display-connector {
 display = disp;
 // interface-specific properties such as pixel format here
 };
 
 Finally, have you considered just using an EDID instead of creating
 something custom? I know that creating an EDID is harder than writing a
 few simple properties into a DT, but EDIDs have the following advantages:

I have considered using EDID and I also tried it. It's painful. There
are no (open) tools available for creating EDID. That's something we
could change of course. Then when generating a devicetree there is
always an extra step involved creating the EDID blob. Once the EDID
blob is in devicetree it is not parsable anymore by mere humans, so
to see what we've got there is another tool involved to generate a
readable form again.

 
 a) They're already standardized and very common.

Indeed, that's a big plus for EDID. I have no intention of removing EDID
data from the devicetree. There are situations where EDID is handy, for
example when you get EDID data provided by your vendor.

 
 b) They allow other information such as a display's HDMI audio
 capabilities to be represented, which can then feed into an ALSA driver.
 
 c) The few LCD panel datasheets I've seen actually quote their
 specification as an EDID already, so deriving the EDID may actually be easy.
 
 d) People familiar with displays are almost certainly familiar with
 EDID's mode representation. There are many ways of representing display
 modes (sync position vs. porch widths, htotal specified rather than
 specifying all the components and hence htotal being calculated etc.).
 Not everyone will be familiar with all representations. Conversion
 errors are less likely if the target is EDID's familiar format.

You seem to think about a different class of displays for which EDID
indeed is a better way to handle. What I have to deal with here mostly
are dumb displays which:

- can only handle their native resolution
- Have no audio capabilities at all
- come with a datasheet which specify a min/typ/max triplet for
  xres,hsync,..., often enough they are scanned to pdf from some previously
  printed paper.

These displays are very common on embedded devices, probably that's the
reason I did not even think about the possibility that a single display
might have different modes.

 
 e) You'll end up with exactly the same data as if you have a DDC-based
 external monitor rather than an internal panel, so you end up getting to
 a common path in display handling code much more quickly.

All we have in our display driver currently is:

edidp = of_get_property(np, edid, imxpd-edid_len);
if (edidp) {
imxpd-edid = kmemdup(edidp, imxpd-edid_len, GFP_KERNEL);
} else {
ret = of_get_video_mode(np, imxpd-mode, NULL);
if (!ret)
imxpd-mode_valid = 1;
}

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | 

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #88 from Michel Dänzer mic...@daenzer.net 2012-08-03 07:47:17 UTC 
---
(In reply to comment #86)
 So, Anthony has put a finger on something.

Yes, I think something like Anthony's patch is needed due to asynchronous GPU
processing: when the userspace driver assigns virtual address space for a new
BO, the GPU may not have finished processing command streams using previous BOs
occupying that same virtual address space.

However, the userspace driver shouldn't wait synchronously for the BO to go
idle when destroying it but should instead defer destruction (or at least the
freeing of the virtual address space) until it notices the BO has become idle.


 With Anthony's patch, I'm still able to lock the display everytime

And these lockups do not happen when not using virtual address space? Can you
provide the dmesg output of the GPU reset for such a lockup? Ideally from a
single piglit test reproducing it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=52997

--- Comment #2 from Michel Dänzer mic...@daenzer.net 2012-08-03 07:49:18 UTC 
---
Please attach the /var/log/Xorg.0.log file.

Which version of libdrm_radeon are you using?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Michel Dänzer]

On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: 
 1, Handle io prot correctly for MIPS.
 2, Define SAREA_MAX as the size of one page.
 3, Include swiotlb.h if SWIOTLB configured.
 
 Signed-off-by: Huacai Chen che...@lemote.com
 Signed-off-by: Hongliang Tao ta...@lemote.com
 Signed-off-by: Hua Yan y...@lemote.com
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/drm_vm.c|2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c |4 
  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
  include/drm/drm_sarea.h |2 ++
  4 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
 index 961ee08..3f06166 100644
 --- a/drivers/gpu/drm/drm_vm.c
 +++ b/drivers/gpu/drm/drm_vm.c
 @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
 vm_area_struct *vma)
   tmp = pgprot_writecombine(tmp);
   else
   tmp = pgprot_noncached(tmp);
 -#elif defined(__sparc__) || defined(__arm__)
 +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
   tmp = pgprot_noncached(tmp);
  #endif
   return tmp;
 diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
 b/drivers/gpu/drm/radeon/radeon_ttm.c
 index 5b71c71..fc3ac22 100644
 --- a/drivers/gpu/drm/radeon/radeon_ttm.c
 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
 @@ -41,6 +41,10 @@
  #include radeon_reg.h
  #include radeon.h
  
 +#ifdef CONFIG_SWIOTLB
 +#include linux/swiotlb.h
 +#endif
 +
  #define DRM_FILE_PAGE_OFFSET (0x1ULL  PAGE_SHIFT)
  
  static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
 diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
 b/drivers/gpu/drm/ttm/ttm_bo_util.c
 index f8187ea..0df71ea 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
 @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
   else
   tmp = pgprot_noncached(tmp);
  #endif
 -#if defined(__sparc__)
 +#if defined(__sparc__) || defined(__mips__)
   if (!(caching_flags  TTM_PL_FLAG_CACHED))
   tmp = pgprot_noncached(tmp);
  #endif
 diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
 index ee5389d..1d1a858 100644
 --- a/include/drm/drm_sarea.h
 +++ b/include/drm/drm_sarea.h
 @@ -37,6 +37,8 @@
  /* SAREA area needs to be at least a page */
  #if defined(__alpha__)
  #define SAREA_MAX   0x2000U
 +#elif defined(__mips__)
 +#define SAREA_MAX   0x4000U
  #elif defined(__ia64__)
  #define SAREA_MAX   0x1U /* 64kB */
  #else

This should be four separate patches.


-- 
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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #89 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-03 
08:05:07 UTC ---
(In reply to comment #88)
 (In reply to comment #86)
  So, Anthony has put a finger on something.
 
 Yes, I think something like Anthony's patch is needed due to asynchronous GPU
 processing: when the userspace driver assigns virtual address space for a new
 BO, the GPU may not have finished processing command streams using previous 
 BOs
 occupying that same virtual address space.
 
 However, the userspace driver shouldn't wait synchronously for the BO to go
 idle when destroying it but should instead defer destruction (or at least the
 freeing of the virtual address space) until it notices the BO has become idle.
 
 
  With Anthony's patch, I'm still able to lock the display everytime
 
 And these lockups do not happen when not using virtual address space? Can you
 provide the dmesg output of the GPU reset for such a lockup? Ideally from a
 single piglit test reproducing it.

Nope, no lockup without va (I may only be lucky though if the bug is there but
only shown when using va). I'll try to find a way to get dmesg... It has been a
problem since the start for that part, but I may be able to use another
computer to log in remotely. May take a couple of days to do though.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #90 from Michel Dänzer mic...@daenzer.net 2012-08-03 08:13:03 UTC 
---
(In reply to comment #89)
 Nope, no lockup without va (I may only be lucky though if the bug is there but
 only shown when using va).

That's indeed possible: Using virtual address space will catch out of bounds
memory access that may otherwise go unnoticed.

So, I think in this report we should focus on the rendering regression(s), and
track the lockups in other reports.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.

[Huacai Chen]

OK, I'll split it.

On Fri, Aug 3, 2012 at 4:01 PM, Michel Dänzer mic...@daenzer.net wrote:
 On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote:
 1, Handle io prot correctly for MIPS.
 2, Define SAREA_MAX as the size of one page.
 3, Include swiotlb.h if SWIOTLB configured.

 Signed-off-by: Huacai Chen che...@lemote.com
 Signed-off-by: Hongliang Tao ta...@lemote.com
 Signed-off-by: Hua Yan y...@lemote.com
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/drm_vm.c|2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c |4 
  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
  include/drm/drm_sarea.h |2 ++
  4 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
 index 961ee08..3f06166 100644
 --- a/drivers/gpu/drm/drm_vm.c
 +++ b/drivers/gpu/drm/drm_vm.c
 @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
 vm_area_struct *vma)
   tmp = pgprot_writecombine(tmp);
   else
   tmp = pgprot_noncached(tmp);
 -#elif defined(__sparc__) || defined(__arm__)
 +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
   tmp = pgprot_noncached(tmp);
  #endif
   return tmp;
 diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
 b/drivers/gpu/drm/radeon/radeon_ttm.c
 index 5b71c71..fc3ac22 100644
 --- a/drivers/gpu/drm/radeon/radeon_ttm.c
 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
 @@ -41,6 +41,10 @@
  #include radeon_reg.h
  #include radeon.h

 +#ifdef CONFIG_SWIOTLB
 +#include linux/swiotlb.h
 +#endif
 +
  #define DRM_FILE_PAGE_OFFSET (0x1ULL  PAGE_SHIFT)

  static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
 diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
 b/drivers/gpu/drm/ttm/ttm_bo_util.c
 index f8187ea..0df71ea 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
 @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
 tmp)
   else
   tmp = pgprot_noncached(tmp);
  #endif
 -#if defined(__sparc__)
 +#if defined(__sparc__) || defined(__mips__)
   if (!(caching_flags  TTM_PL_FLAG_CACHED))
   tmp = pgprot_noncached(tmp);
  #endif
 diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
 index ee5389d..1d1a858 100644
 --- a/include/drm/drm_sarea.h
 +++ b/include/drm/drm_sarea.h
 @@ -37,6 +37,8 @@
  /* SAREA area needs to be at least a page */
  #if defined(__alpha__)
  #define SAREA_MAX   0x2000U
 +#elif defined(__mips__)
 +#define SAREA_MAX   0x4000U
  #elif defined(__ia64__)
  #define SAREA_MAX   0x1U /* 64kB */
  #else

 This should be four separate patches.


 --
 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 26345] [845G] CPU/GPU incoherency

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=26345

Chris Wilson ch...@chris-wilson.co.uk changed:

   What|Removed |Added

 CC||artem.rusa...@gmail.com

--- Comment #147 from Chris Wilson ch...@chris-wilson.co.uk 2012-08-03 
12:18:44 UTC ---
*** Bug 53065 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [RFC 0/3] solving omapdrm/omapdss layering issues

[Rob Clark]

On Fri, Aug 3, 2012 at 1:01 AM, Semwal, Sumit sumit.sem...@ti.com wrote:
 Hi Rob, Tomi,
 On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
 On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
  On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
  On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
 
   I guess the fact is that DRM concepts do not really match the OMAP DSS
   hardware, and we'll have to use whatever gives us least problems.
 
  Actually, I think it does map fairly well to the hardware.. at least
  more so than to omapdss ;-)
 
  Hm, I'm not sure I understand, omapdss concepts map directly to the
  hardware.

 I think it is mainly exposing the encoder and panel as two separate
 entities.. which seems to be what Archit is working on

 I still don't follow =) They are separate entities. Omapdss models the
 HW quite directly, I think. It doesn't expose everything, though, as the
 output drivers (dsi.c, dpi.c etc) are used via the panel drivers.

 right.. so we just need to expose the output drivers as separate
 entities, and let omapdrm propagate information such as timings
 between them

 in case of something like DVI bridge from DPI, this seems pretty
 straightforward.. only the connector needs to know about DDC stuff,
 which i2c to use and that sort of thing.  So at kms level we would
 have (for example) an omap_dpi_encoder which would be the same for DPI
 panel (connector) or DPI-DVI bridge.  For HDMI I'm still looking
 through the code to see how this would work.  Honestly I've looked
 less at this part of code and encoder related registers in the TRM,
 compared to the ovl/mgr parts, but at least from the 'DSS overview'
 picture in the TRM it seems to make sense ;-)

 KMS even exposes the idea that certain crtcs can connect to only
 certain encoders.  Or that you could you could have certain connectors
 switched between encoders.  For example if you had a hw w/ DPI out,
 and some mux to switch that back and forth between a DPI lcd panel and
 a DPI-DVI bridge.  (Ok, I'm not aware of any board that actually does
 this, but it is in theory possible.)  So we could expose possible
 video chain topologies to userspace in this way.

 OMAP3 SDP board has such a setup, with manual switch to select between
 LCD and DVI.

 ahh, good to know.. so I'm not crazy for wanting to expose this
 possibility to userspace

 The other thing is that we don't need to propagate timings from the
 panel up to the mgr at the dss level.. kms is already handling this
 for us.  In my latest version, which I haven't pushed, I removed the
 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'.

 You're thinking only about simple DPI cases. Consider this example, with
 a DSI-to-DP bridge chip. What we have is the following flow of data:

 DISPC - DSI - DSI-2-DP - DP monitor

 The timings you are thinking about are in the DISPC, but here they are
 only one part of the link. And here the DISPC timings are not actually
 the timings what the user is interested about. The user wants his
 timings to be between DSI-2-DP chip and the DP monitor.

 Timings programmed to DISPC are not the same. The timings for DISPC come
 from the DSI driver, and they may be very different than the user's
 timings. With DSI video mode, the DISPC timings would have some
 resemblance to the user's timings, mainly the time to send one line
 would be the same. With DSI cmd mode, the DISPC timings would be
 something totally different, most likely with 0 blank times and as fast
 pixel clock as possible.

 hmm, well kms already has a concept of adjusted_timings, which could
 perhaps be used here to propagate the timings between crtc-encoder..
 although the order is probably backwards from what we want (it comes
 from the crtc to the encoder.. and if I understand properly we want it
 the other way and actually possibly from the connector).  But that
 isn't to say that internally in omapdrm the crtc couldn't get the
 adjusted timings from the connector.  So I still think the parameter
 flow doesn't need to be 'under the hood' in omapdss.

 And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper
 fxns, so if the way the core kms handles it isn't what we want, we can
 just plug in our own fxn instead of using drm_crtc_helper_set_mode(),
 so that isn't really a big problem.

 What omapdss does currently is that you set the user's timings to the
 right side of the chain, which propagate back to DSS. This allows the
 DSI-2-DP bridge use DSI timings that work optimally for the bridge, and
 DSI driver will use DISPC timings that work optimally for it.

 And it's not only about timings above, but also other settings related
 to the busses between the components. Clock dividers, polarities, stuff
 like that.

 I expect we could handle other settings 

Re: [PATCH v2 7/7] drm: Renesas SH Mobile DRM driver

[Sascha Hauer]

Hi Laurent,

Some minor stuff inside.

Thanks

 Sascha+

On Fri, Jul 20, 2012 at 03:04:22PM +0200, Laurent Pinchart wrote:
 The SH Mobile LCD controller (LCDC) DRM driver supports the main
 graphics plane in RGB and YUV formats, as well as the overlay planes (in
 alpha-blending mode only).
 
 Only flat panel outputs using the parallel interface are supported.
 Support for SYS panels, HDMI and DSI is currently not implemented.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/gpu/drm/Kconfig|2 +
  drivers/gpu/drm/Makefile   |1 +
  drivers/gpu/drm/shmobile/Kconfig   |   10 +
  drivers/gpu/drm/shmobile/Makefile  |7 +
  drivers/gpu/drm/shmobile/shmob_drm_backlight.c |   90 +++
  drivers/gpu/drm/shmobile/shmob_drm_backlight.h |   23 +
  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  768 
 
  drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |   60 ++
  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  360 +++
  drivers/gpu/drm/shmobile/shmob_drm_drv.h   |   52 ++
  drivers/gpu/drm/shmobile/shmob_drm_kms.c   |  160 +
  drivers/gpu/drm/shmobile/shmob_drm_kms.h   |   34 +
  drivers/gpu/drm/shmobile/shmob_drm_plane.c |  263 
  drivers/gpu/drm/shmobile/shmob_drm_plane.h |   22 +
  drivers/gpu/drm/shmobile/shmob_drm_regs.h  |  304 ++
  include/drm/shmob_drm.h|   99 +++
  16 files changed, 2255 insertions(+), 0 deletions(-)
  create mode 100644 drivers/gpu/drm/shmobile/Kconfig
  create mode 100644 drivers/gpu/drm/shmobile/Makefile
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
  create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
  create mode 100644 include/drm/shmob_drm.h
 
 diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
 index 98ba7d5..0b40bf2 100644
 --- a/drivers/gpu/drm/Kconfig
 +++ b/drivers/gpu/drm/Kconfig
 @@ -208,3 +208,5 @@ source drivers/gpu/drm/ast/Kconfig
  source drivers/gpu/drm/mgag200/Kconfig
  
  source drivers/gpu/drm/cirrus/Kconfig
 +
 +source drivers/gpu/drm/shmobile/Kconfig
 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index 58961b9..2ff5cef 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -47,4 +47,5 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
  obj-$(CONFIG_DRM_GMA500) += gma500/
  obj-$(CONFIG_DRM_UDL) += udl/
  obj-$(CONFIG_DRM_AST) += ast/
 +obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
  obj-y+= i2c/
 diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c 
 b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
 new file mode 100644
 index 000..c7be5f7
 --- /dev/null
 +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
 @@ -0,0 +1,768 @@

[...]

 +
 +static void shmob_drm_encoder_destroy(struct drm_encoder *encoder)
 +{
 + drm_encoder_cleanup(encoder);
 +}
 +
 +static const struct drm_encoder_funcs encoder_funcs = {
 + .destroy = shmob_drm_encoder_destroy,

You could add drm_encoder_cleanup here.


[...]

 +
 +static enum drm_connector_status
 +shmob_drm_connector_detect(struct drm_connector *connector, bool force)
 +{
 + return connector_status_unknown;
 +}

Shouldn't you return connector_status_connected here? I mean all that
you handle is a dumb display which is always connected.


[...]

 +
 +static int __devinit shmob_drm_setup_clocks(struct shmob_drm_device *sdev,
 + enum shmob_drm_clk_source clksrc)
 +{
 + struct clk *clk;
 + char *clkname;
 +
 + switch (clksrc) {
 + case SHMOB_DRM_CLK_BUS:
 + clkname = bus_clk;
 + sdev-lddckr = LDDCKR_ICKSEL_BUS;
 + break;
 + case SHMOB_DRM_CLK_PERIPHERAL:
 + clkname = peripheral_clk;
 + sdev-lddckr = LDDCKR_ICKSEL_MIPI;
 + break;
 + case SHMOB_DRM_CLK_EXTERNAL:
 + clkname = NULL;
 + sdev-lddckr = LDDCKR_ICKSEL_HDMI;
 + break;
 + default:
 + return -EINVAL;
 + }
 +
 + clk = clk_get(sdev-dev, clkname);
 + if (IS_ERR(clk)) {
 + dev_err(sdev-dev, cannot get dot clock %s\n, clkname);
 + return PTR_ERR(clk);
 + }
 +
 + sdev-clock = clk;
 + return 0;
 +}
 +
 +/* 
 -
 + * DRM 

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #91 from Christian König deathsim...@vodafone.de 2012-08-03 
12:58:04 UTC ---
I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same
problem now.

Do I understand it correctly that the userspace VM manager is releasing
allocations to early and not waiting for async buffer use to end?

That should be easy to fix.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #92 from Michel Dänzer mic...@daenzer.net 2012-08-03 13:21:22 UTC 
---
(In reply to comment #91)
 I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same
 problem now.

Ah cool, you found it already. :)

 Do I understand it correctly that the userspace VM manager is releasing
 allocations to early and not waiting for async buffer use to end?

That's my working theory.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #93 from Michel Dänzer mic...@daenzer.net 2012-08-03 13:26:32 UTC 
---
(In reply to comment #92)
  Do I understand it correctly that the userspace VM manager is releasing
  allocations to early and not waiting for async buffer use to end?
 
 That's my working theory.

Also, if it wasn't the case, I don't see how Anthony's patch could make a
difference.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: ignore disconnected - unknown status changes

[Alex Deucher]

On Thu, Aug 2, 2012 at 3:21 AM, Knut Petersen knut_peter...@t-online.de wrote:
 On an AOpen i915GMm-hfs the hotplug events generated
 by transitions between connector_status_unknown and
 connector_status_disconnected cause screen distortions.

 The attached patch cures the problem by disabling the
 generation of hotplug events in those cases. That should
 be safe for everybody as the only relevant changes are
 those from / to connector_status_connected.

Seems reasonable to me.  We should just drop unknown.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 cu,
  Knut

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Optimize i2f()

[Alex Deucher]

On Mon, Jul 30, 2012 at 5:49 PM, Steven Fuerst svfue...@gmail.com wrote:
 Looking through the kernel radeon drm source, it looks like the i2f()
 functions in r600_blit.c and r600_blit_ksm() can be optimized a bit.

Care to send a patch?

Thanks,

Alex


 The following extends the range to all unsigned 32bit integers, and avoids
 the slow loop by using the bsr instruction via __fls().  It provides an
 exact 1-1 correspondence up to 2^24.  Above that, there is the inevitable
 rounding.  This routine rounds towards zero (truncation).

 /* 23 bits of float fractional data */
 #define I2F_FRAC_BITS 23
 #define I2F_MASK ((1  I2F_FRAC_BITS) - 1)

 /*
  * Converts an unsigned integer into 32-bit IEEE floating point
 representation.
  * Will be exact from 0 to 2^24.  Above that, we round towards zero
  * as the fractional bits will not fit in a float.  (It would be better to
  * round towards even as the fpu does, but that is slower.)
  * This routine depends on the mod(32) behaviour of the rotate instructions
  * on x86.
  */
 uint32_t i2f(uint32_t x)
 {
 uint32_t msb, exponent, fraction;

 /* Zero is special */
 if (!x) return 0;

 /* Get location of the most significant bit */
 msb = __fls(x);

 /*
 * Use a rotate instead of a shift because that works both leftwards
 * and rightwards due to the mod(32) beahviour.  This means we don't
 * need to check to see if we are above 2^24 or not.
 */
 fraction = ror32(x, msb - I2F_FRAC_BITS)  I2F_MASK;
 exponent = (127 + msb)  I2F_FRAC_BITS;

 return fraction + exponent;
 }

 Steven Fuerst

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #95 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-03 
14:51:56 UTC ---
(In reply to comment #90)
 (In reply to comment #89)
  Nope, no lockup without va (I may only be lucky though if the bug is there 
  but
  only shown when using va).
 
 That's indeed possible: Using virtual address space will catch out of bounds
 memory access that may otherwise go unnoticed.
 
 So, I think in this report we should focus on the rendering regression(s), and
 track the lockups in other reports.

OK, I'll open another bug for the lockups. This one will be renamed for va
issues and rendering regression. I'll wait until tonight to make changes to see
if someone objects.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

  Attachment #65051|0   |1
is obsolete||

--- Comment #96 from Christian König deathsim...@vodafone.de 2012-08-03 
15:03:52 UTC ---
Created attachment 65093
  -- https://bugs.freedesktop.org/attachment.cgi?id=65093
Possible fix.

It's hard and uneffecient to solve this problem completely in the kernel.

Since we patch the VM table synchronously, but use it asynchronously we will
always end up needing to wait for a bo use by the GPU to end before patching in
the new VA.

Please take a look at the attached patch it should fix the issue nicely in
userspace.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #97 from Marek Olšák mar...@gmail.com 2012-08-03 15:20:12 UTC ---
(In reply to comment #96)
 Created attachment 65093 [details] [review]
 Possible fix.
 
 It's hard and uneffecient to solve this problem completely in the kernel.
 
 Since we patch the VM table synchronously, but use it asynchronously we will
 always end up needing to wait for a bo use by the GPU to end before patching 
 in
 the new VA.
 
 Please take a look at the attached patch it should fix the issue nicely in
 userspace.

Please use the radeon_bo_is_busy function. Calling DRM_RADEON_GEM_BUSY directly
is not reliable because of the thread offloading of the CS ioctl. The same
applies to any other kernel queries and commands which depend on the CS ioctl.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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/radeon: fix some missing parens in asic macros

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Better safe than sorry.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 118e4b9..9f58885 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, 
uint32_t v);
 #define radeon_pm_finish(rdev) (rdev)-asic-pm.finish((rdev))
 #define radeon_pm_init_profile(rdev) (rdev)-asic-pm.init_profile((rdev))
 #define radeon_pm_get_dynpm_state(rdev) 
(rdev)-asic-pm.get_dynpm_state((rdev))
-#define radeon_pre_page_flip(rdev, crtc) 
rdev-asic-pflip.pre_page_flip((rdev), (crtc))
-#define radeon_page_flip(rdev, crtc, base) rdev-asic-pflip.page_flip((rdev), 
(crtc), (base))
-#define radeon_post_page_flip(rdev, crtc) 
rdev-asic-pflip.post_page_flip((rdev), (crtc))
-#define radeon_wait_for_vblank(rdev, crtc) 
rdev-asic-display.wait_for_vblank((rdev), (crtc))
-#define radeon_mc_wait_for_idle(rdev) rdev-asic-mc_wait_for_idle((rdev))
+#define radeon_pre_page_flip(rdev, crtc) 
(rdev)-asic-pflip.pre_page_flip((rdev), (crtc))
+#define radeon_page_flip(rdev, crtc, base) 
(rdev)-asic-pflip.page_flip((rdev), (crtc), (base))
+#define radeon_post_page_flip(rdev, crtc) 
(rdev)-asic-pflip.post_page_flip((rdev), (crtc))
+#define radeon_wait_for_vblank(rdev, crtc) 
(rdev)-asic-display.wait_for_vblank((rdev), (crtc))
+#define radeon_mc_wait_for_idle(rdev) (rdev)-asic-mc_wait_for_idle((rdev))
 
 /* Common functions */
 /* AGP */
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

David L. equinox-freedesktopb...@diac24.net changed:

   What|Removed |Added

 CC||equinox-freedesktopbugs@dia
   ||c24.net
Summary|Radeon KMS on Macs with EFI |Radeon KMS fails with
   |boot|inaccessible AtomBIOS on
   ||systems with (U)EFI boot

--- Comment #22 from David L. equinox-freedesktopb...@diac24.net 2012-08-03 
16:12:27 UTC ---
Exact same issue appears on an HP EliteBook 8470p if you select native UEFI
as boot method in setup.  Legacy and hybrid boot options work fine.

Changing bug title since this is not a Mac-specific issue, although it is more
severe on Macs without the legacy/hybrid options easily accessible.

It seems that the driver either cannot rely on the AtomBIOS being accessible,
or we need to add code to enable the mapping with some PCI hacks?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Matthew Garrett]

On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:

 This is one of the things I wasn't so sure about. There are various
 checks in intel_lvds_init() that can cause it to bail out before we try
 to get the EDID, and I don't fully understand all of them. If non-laptop
 machines are expected to bail out before the EDID check then the
 approach I've taken seems reasonable. Otherwise adding a quirk probably
 is a good idea.

I know we've previously had problems with machines with phantom LVDS 
hardware, but I'm not sure what the current state of affairs is.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

[Matthew Garrett]

On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
 Some Apple hybrid graphics machines do not have the LVDS panel connected
 to the integrated GPU at boot and also do not supply a VBT. The LVDS
 connector is not registered as a result, making it impossible to support
 graphics switching.
 
 This patch changes intel_lvds_init() to register the connector even if
 we can't find any panel modes. This makes it necessary to always check
 intel_lvds-fixed_mode before use, as it could now be NULL.

This one kind of sucks. I think adding a quirk for this situation would 
be justifiable, rather than doing it for all devices.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #23 from Alex Deucher ag...@yahoo.com 2012-08-03 16:33:04 UTC ---
On UEFI systems the vbios should be accessible via the ACPI VFCT.  See the
bottom of atombios.h for struct definitions.  Macs do their own thing so I
don't know if this will work on them or not.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #98 from Jerome Glisse gli...@freedesktop.org 2012-08-03 16:54:04 
UTC ---
Created attachment 65095
  -- https://bugs.freedesktop.org/attachment.cgi?id=65095
Properly protect virtual address

Properly protect virtual address

Patch against Linus master, gonna attach patch against 3.5 next.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

  Attachment #65096|0   |1
is obsolete||

--- Comment #100 from Jerome Glisse gli...@freedesktop.org 2012-08-03 
16:59:41 UTC ---
Created attachment 65097
  -- https://bugs.freedesktop.org/attachment.cgi?id=65097
Properly protect virtual address

Properly protect virtual address

Patch against Linus master, gonna attach patch against 3.5 next.

Again, sorry previous one was wrong one.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #101 from Jerome Glisse gli...@freedesktop.org 2012-08-03 
17:05:15 UTC ---
Created attachment 65098
  -- https://bugs.freedesktop.org/attachment.cgi?id=65098
Properly protect virtual address against kernel 3.5

Same patch against 3.5

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #24 from David L. equinox-freedesktopb...@diac24.net 2012-08-03 
17:12:52 UTC ---
(In reply to comment #23)
 On UEFI systems the vbios should be accessible via the ACPI VFCT.  See the
 bottom of atombios.h for struct definitions.  Macs do their own thing so I
 don't know if this will work on them or not.

Should this already work on 3.4.7 and should I file a separate report about
ACPI VFCT being broken or is that future tense/upcoming?

Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just
tried acpidump | grep VFCT, that should show something shouldn't it?) Will try
under native UEFI in a minute...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #25 from Alex Deucher ag...@yahoo.com 2012-08-03 17:26:03 UTC ---
(In reply to comment #24)
 Should this already work on 3.4.7 and should I file a separate report about
 ACPI VFCT being broken or is that future tense/upcoming?

Support for fetching the vbios from VFCT still needs to be implemented.

 
 Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just
 tried acpidump | grep VFCT, that should show something shouldn't it?) Will try
 under native UEFI in a minute...

I'm not too familiar with ACPI and UEFI unfortunately.  It's part of the GOP
stuff for UEFI.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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