[git pull] drm fixes for v4.12-rc1
Hi Linus, Some fixes that it would be good to have in rc1. It contains the i915 quiet fix that you reported. It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 which is new in this kernel and is preliminary support so may have a fair bit of movement. Otherwise a few non-Vega10 AMD fixes, one EDID fix and some nouveau regression fixers. Dave. The following changes since commit 09d79d103371b1b7ea70ea7f9c05ac207ef22f5d: Merge tag 'docs-4.12-2' of git://git.lwn.net/linux (2017-05-11 11:29:52 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc1 for you to fetch changes up to 7b8cd3363e8a0e6b90a7067f75aaeaae61a7d612: drm/i915: Make vblank evade warnings optional (2017-05-12 14:28:02 +1000) amd, nouveau, one i915 and one EDID fix for v4.12-rc1 Alex Deucher (12): drm/amdgpu: fix spelling in header comment drm/amdgpu: bump version number to note race fix and new fence functionality Revert "drm/amd/amdgpu: Set VCE/UVD off during late init" drm/amdgpu: update revision id settings for BR/ST drm/amdgpu/gfx9: use actual gpu num se setting for ngg allocation drm/amdgpu/gfx9: fix typo in mpd init drm/amdgpu/gfx9: add additional MQD initialization drm/amdgpu/gfx: drop max_gs_waves_per_vgt drm/amdgpu/gfx9: derive tile pipes from golden settings drm/amdgpu/atomfirmware: add function to update engine hang status drm/amdgpu/soc15: use atomfirmware for setting bios scratch for reset drm/amdgpu: add some additional vega10 pci ids Alex Xie (8): drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Real return value can be over-written when clean up drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting Ben Skeggs (10): drm/nouveau/kms/nv50: remove pointless argument to window atomic_check_acquire() drm/nouveau/kms/nv50: fix source-rect-only plane updates drm/nouveau/kms/nv50: skip core channel cursor update on position-only changes drm/nouveau/fb/ram/gf100-: remove 0x10f200 read drm/nouveau/core: fix static checker warning drm/nouveau/tmr: ack interrupt before processing alarms drm/nouveau/tmr: handle races with hw when updating the next alarm time drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm drm/nouveau/tmr: avoid processing completed alarms when adding a new one drm/nouveau/therm: remove ineffective workarounds for alarm bugs Christian König (14): drm/amdgpu: add VMHUB to ring association drm/amdgpu: drop VMID per ring tracking drm/amdgpu: split VMID management by VMHUB drm/amdgpu: invalidate only the currently needed VMHUB v2 drm/amdgpu: assign VM invalidation engine manually v2 drm/amdgpu: allow concurrent VM flushes drm/amdgpu: trace the vmhub in grab_id as well drm/amdgpu: trace vm hub during flush as well v2 drm/radeon: force the UVD DPB into VRAM as well drm/amdgpu: fix coding style and printing in amdgpu_doorbell_init drm/amdgpu: fix amdgpu_vm_clear_freed v2 drm/amdgpu: fix amdgpu_ttm_bo_eviction_valuable drm/amdgpu: fix VM clearing in amdgpu_gem_object_close drm/amdgpu: remove unused and mostly unimplemented CGS functions v2 Chunming Zhou (8): drm/amdgpu: add gtt print like vram when dump mm table V2 drm/amdgpu: increase gtt size to 3GB by default v2 drm/amdgpu: fix no-vmid job drm/amdgpu: fix gpu reset crash drm/amdgpu: fix NULL pointer error drm/amdgpu: fix deadlock of reservation between cs and gpu reset v2 drm/amd: fix init order of sched job drm/amdgpu: fix dependency issue Daniel Wang (2): drm/amdgpu/psp: skip loading SDMA/RLCG under SRIOV VF drm/amdgpu/vce4: fix a PSP loading VCE issue Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2017-05-05' of git://anongit.freedesktop.org/git/drm-misc into drm-next Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next Evan Quan (1): drm/amdgpu: update smu9 driver interface Frank Min (7): drm/amdgpu/vce4: update VCE initialization sequence for SRIOV drm/amdgpu/vce4: enable ring & ib test for sriov drm/amdgpu/vce4: move mm table constructions functions into mmsch header file drm/amdgpu/uvd7: add sriov uvd initialization sequences drm/amdgpu/uvd7: add uvd doorbell initialization for sriov drm/am
Re: [PATCH] vt_buffer: drop console buffer copying optimisations
On 30 January 2015 at 10:03, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: I can take this through the tty tree, but can I put it in linux-next and wait for the 3.20 merge window to give people who might notice a slow-down a chance to object? Yes. The problem only affects one (or a couple of) truly outrageously bad graphics cards that are only used in servers (because they are such crap that they wouldn't be acceptable anywhere else anyway), and they have afaik never worked with 64-bit kernels, so it's not even a regression. So it's worth fixing because it's a real - albeit very rare - problem (especially since the enhanched rep instruction model of memcpy could easily be *worse* than the 16-bit-at-a-time manual version), but I wouldn't consider it anywhere near high priority. Totally not a priority, it just finally got tested for RHEL so I wanted to make sure I posted it upstream before I forgot about it for months, I also filed: https://bugzilla.kernel.org/show_bug.cgi?id=92311 since the RH bug is private and full of crap, that bug contains a screenshot of the remote console to see what sort of crap it produces. Dave. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vt_buffer: drop console buffer copying optimisations
These two copy to/from VGA memory, however on the Silicon Motion SMI750 VGA card on a 64-bit system cause console corruption. This is due to the hw being buggy and not handling a 64-bit transaction correctly. We could try and create a 32-bit version of these routines, but I'm not sure the optimisation is worth much today. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1132826 Tested-by: Huawei engineering. Signed-off-by: Dave Airlie airl...@redhat.com --- Linus, this came up a while back I finally got some confirmation that it fixes those servers. include/linux/vt_buffer.h | 4 1 file changed, 4 deletions(-) diff --git a/include/linux/vt_buffer.h b/include/linux/vt_buffer.h index 057db7d..f38c10b 100644 --- a/include/linux/vt_buffer.h +++ b/include/linux/vt_buffer.h @@ -21,10 +21,6 @@ #ifndef VT_BUF_HAVE_RW #define scr_writew(val, addr) (*(addr) = (val)) #define scr_readw(addr) (*(addr)) -#define scr_memcpyw(d, s, c) memcpy(d, s, c) -#define scr_memmovew(d, s, c) memmove(d, s, c) -#define VT_BUF_HAVE_MEMCPYW -#define VT_BUF_HAVE_MEMMOVEW #endif #ifndef VT_BUF_HAVE_MEMSETW -- 1.9.3 -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fbcon: fix locking harder
Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.
In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,
this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.
This should fix the efifb regression seen by Maarten.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/vga/vga_switcheroo.c | 3 +++
drivers/video/console/fbcon.c| 11 ---
drivers/video/fbmem.c| 2 ++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index fa60add..cf787e1 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -25,6 +25,7 @@
#include linux/fb.h
#include linux/pci.h
+#include linux/console.h
#include linux/vga_switcheroo.h
#include linux/vgaarb.h
@@ -337,8 +338,10 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
if (new_client-fb_info) {
struct fb_event event;
+ console_lock();
event.info = new_client-fb_info;
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, event);
+ console_unlock();
}
ret = vgasr_priv.handler-switchto(new_client-id);
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 2aef9ca..2e2d959 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -842,6 +842,8 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
*
* Maps a virtual console @unit to a frame buffer device
* @newidx.
+ *
+ * This should be called with the console lock held.
*/
static int set_con2fb_map(int unit, int newidx, int user)
{
@@ -859,7 +861,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
if (!search_for_mapped_con() || !con_is_bound(fb_con)) {
info_idx = newidx;
- return fbcon_takeover(0);
+ return do_fbcon_takeover(0);
}
if (oldidx != -1)
@@ -867,7 +869,6 @@ static int set_con2fb_map(int unit, int newidx, int user)
found = search_fb_in_map(newidx);
- console_lock();
con2fb_map[unit] = newidx;
if (!err !found)
err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
@@ -894,7 +895,6 @@ static int set_con2fb_map(int unit, int newidx, int user)
if (!search_fb_in_map(info_idx))
info_idx = newidx;
- console_unlock();
return err;
}
@@ -3019,6 +3019,7 @@ static inline int fbcon_unbind(void)
}
#endif /* CONFIG_VT_HW_CONSOLE_BINDING */
+/* called with console_lock held */
static int fbcon_fb_unbind(int idx)
{
int i, new_idx = -1, ret = 0;
@@ -3045,6 +3046,7 @@ static int fbcon_fb_unbind(int idx)
return ret;
}
+/* called with console_lock held */
static int fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
@@ -3082,6 +3084,7 @@ static int fbcon_fb_unregistered(struct fb_info *info)
return 0;
}
+/* called with console_lock held */
static void fbcon_remap_all(int idx)
{
int i;
@@ -3126,6 +3129,7 @@ static inline void fbcon_select_primary(struct fb_info
*info)
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+/* called with console_lock held */
static int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
@@ -3278,6 +3282,7 @@ static int fbcon_event_notify(struct notifier_block *self,
ret = fbcon_fb_unregistered(info);
break;
case FB_EVENT_SET_CONSOLE_MAP:
+ /* called with console lock held */
con2fb = event-data;
ret = set_con2fb_map(con2fb-console - 1,
con2fb-framebuffer, 1);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 070b9a1..dc61c12 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1177,8 +1177,10 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
event.data = con2fb;
if (!lock_fb_info(info))
return -ENODEV;
+ console_lock();
event.info = info;
ret = fb_notifier_call_chain(FB_EVENT_SET_CONSOLE_MAP, event);
+ console_unlock();
unlock_fb_info(info);
break;
case FBIOBLANK:
--
1.8.1
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http
[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font (v2)
From: Dave Airlie airl...@redhat.com
When we switch from 256-512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.
A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.
v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.
Signed-off-by: Dave Airlie airl...@redhat.com
f
---
drivers/tty/vt/vt.c| 2 +-
drivers/video/console/vgacon.c | 22 +++---
include/linux/vt_kern.h| 1 +
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..c8067ae 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -638,7 +638,7 @@ static inline void save_screen(struct vc_data *vc)
* Redrawing of screen
*/
-static void clear_buffer_attributes(struct vc_data *vc)
+void clear_buffer_attributes(struct vc_data *vc)
{
unsigned short *p = (unsigned short *)vc-vc_origin;
int count = vc-vc_screenbuf_size / 2;
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index d449a74..5855d17 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1064,7 +1064,7 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
unsigned short video_port_status = vga_video_port_reg + 6;
int font_select = 0x00, beg, i;
char *charmap;
-
+ bool clear_attribs = false;
if (vga_video_type != VIDEO_TYPE_EGAM) {
charmap = (char *) VGA_MAP_MEM(colourmap, 0);
beg = 0x0e;
@@ -1169,12 +1169,6 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
/* if 512 char mode is already enabled don't re-enable it. */
if ((set) (ch512 != vga_512_chars)) {
- /* attribute controller */
- for (i = 0; i MAX_NR_CONSOLES; i++) {
- struct vc_data *c = vc_cons[i].d;
- if (c c-vc_sw == vga_con)
- c-vc_hi_font_mask = ch512 ? 0x0800 : 0;
- }
vga_512_chars = ch512;
/* 256-char: enable intensity bit
512-char: disable intensity bit */
@@ -1185,8 +1179,22 @@ static int vgacon_do_font_op(struct vgastate *state,char
*arg,int set,int ch512)
it means, but it works, and it appears necessary */
inb_p(video_port_status);
vga_wattr(state-vgabase, VGA_AR_ENABLE_DISPLAY, 0);
+ clear_attribs = true;
}
raw_spin_unlock_irq(vga_lock);
+
+ if (clear_attribs) {
+ for (i = 0; i MAX_NR_CONSOLES; i++) {
+ struct vc_data *c = vc_cons[i].d;
+ if (c c-vc_sw == vga_con) {
+ /* force hi font mask to 0, so we always clear
+ the bit on either transition */
+ c-vc_hi_font_mask = 0x00;
+ clear_buffer_attributes(c);
+ c-vc_hi_font_mask = ch512 ? 0x0800 : 0;
+ }
+ }
+ }
return 0;
}
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 50ae7d0..1f55665 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -47,6 +47,7 @@ int con_set_cmap(unsigned char __user *cmap);
int con_get_cmap(unsigned char __user *cmap);
void scrollback(struct vc_data *vc, int lines);
void scrollfront(struct vc_data *vc, int lines);
+void clear_buffer_attributes(struct vc_data *vc);
void update_region(struct vc_data *vc, unsigned long start, int count);
void redraw_screen(struct vc_data *vc, int is_switch);
#define update_screen(x) redraw_screen(x, 0)
--
1.8.1
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm i915 hangs on heavy io load
(please Cc) I am running 3.7-rc2 and got recently hit a few times (under rc1, too) by hanging drm i915 while doing large io operations. Does booting with i915.i915_enable_rc6=0 help? (Daniel, looks like an ironlake). Dave. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fbcon: fix race condition between console lock and cursor timer
So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load)Thread B (timer thread) unbind_con_driver - | bind_con_driver -| vc-vc_sw-con_deinit - | fbcon_deinit - | console_lock()| | | | fbcon_flashcursor timer fires | console_lock() - blocked for A | | fbcon_del_cursor_timer - del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb-kms driver handoff. Signed-off-by: David Airlie airl...@redhat.com --- drivers/video/console/fbcon.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 2e471c2..f8a79fc 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work) struct vc_data *vc = NULL; int c; int mode; + int ret; + + ret = console_trylock(); + if (ret == 0) + return; - console_lock(); if (ops ops-currcon != -1) vc = vc_cons[ops-currcon].d; -- 1.7.10.2 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Direct netconsole write would be a useful patch to have mainline I think 8) Well I used a one line wrapper around the netconsole write_msg, which just passed NULL as the first arg, then sprinkled netconsole_write_msg around the place, not having printf stuff could be an annoyance for some people, for this it didn't matter. Peter I wish I had a serial port to work with :-) Not really the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ Done, and cc stable, I'll send this to Linus via my tree as its fairly urgent from my pov. Dave. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: regression(?) 3.3-rc4 - 3.3-rc5: drm intel hangs
On Tue, Feb 28, 2012 at 4:03 AM, Norbert Preining prein...@logic.at wrote: Dear all, (please Cc) And you haven't changed userspace in any way? Dave. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] vt: fix issue when fbcon wants to takeover a second time.
From: Dave Airlie airl...@redhat.com With framebuffer handover and multiple GPUs, we get into a position where the fbcon unbinds the vesafb framebuffer for GPU 1, but we still have a radeon framebuffer bound from GPU 0, so we don't unregister the console driver. Then when we tried to bind the new radeon framebuffer for GPU1 we never get to the bind call as we fail due to the console being registered already. This changes the return value to -EBUSY when the driver is already registered and continues to bind for -EBUSY. Signed-off-by: Dave Airlie airl...@redhat.com Cc: Alan Cox a...@lxorguk.ukuu.org.uk Cc: Greg KH g...@suse.de --- drivers/tty/vt/vt.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index a8ec48e..d781496 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -3524,7 +3524,7 @@ int register_con_driver(const struct consw *csw, int first, int last) /* already registered */ if (con_driver-con == csw) - retval = -EINVAL; + retval = -EBUSY; } if (retval) @@ -3635,7 +3635,12 @@ int take_over_console(const struct consw *csw, int first, int last, int deflt) int err; err = register_con_driver(csw, first, last); - + /* if we get an busy error we still want to bind the console driver +* and return success, as we may have unbound the console driver +* but not unregistered it. +*/ + if (err == -EBUSY) + err = 0; if (!err) bind_con_driver(csw, first, last, deflt); -- 1.7.1 -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
vt/fbcon binding and handover fixes
I've been working on some issues with the fb handoff between vesafb and KMS on my machine with a dual-gpu card. These 3 patches are the primary result of this, to fix a number of issues where the VT layer and fbcon layers got themselves into a place that they couldn't get out off, having the second card complicates things nicely where we have an fbdev registered but fbcon gets unbound to the dummy console and can't get back. Also a fix to the overlap tests which had an off-by-one. Dave. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] fbcon: fix situation where fbcon gets deinitialised and can't reinit.
From: Dave Airlie airl...@redhat.com
Situation as follow:
2 GPUs + vesafb + kms.
GPU 1 is primary, vesafb binds to it as fb0
radeon loads
GPU 0 loads as fb1
GPU 1 loads, vesafb gets kicked off which causes fb0 to unbind
console, which causes the dummy console to rebind.
this means fbcon_deinit gets called, which calls fbcon_exit
since the console isn't bound anymore and we set fbcon_has_exited.
GPU 1 creates a new fb0 which is primary and we want to be console.
fbcon_fb_registered gets called sets the primary up and calls set_con2fb_map,
however as fbcon_has_exited is set nothing further ever happens.
This patch bypasses the fbcon_has_exited and checks if the console is unbound,
if its unbound it calls the fbcon_takeover which calls the vt layer to
call the fbcon_startup method and everthing works.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/video/console/fbcon.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 7ccc967..6662687 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -823,10 +823,10 @@ static int set_con2fb_map(int unit, int newidx, int user)
if (oldidx == newidx)
return 0;
- if (!info || fbcon_has_exited)
+ if (!info)
return -EINVAL;
- if (!err !search_for_mapped_con()) {
+ if (!search_for_mapped_con() || !con_is_bound(fb_con)) {
info_idx = newidx;
return fbcon_takeover(0);
}
--
1.7.1
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] fb: fix overlapping test off-by-one.
From: Dave Airlie airl...@redhat.com On my system with a radeon x2, the first GPU was not overlapping vesa but the test decided it was. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/video/fbmem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 0e6aa3d..4ac1201 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1458,7 +1458,7 @@ static bool apertures_overlap(struct aperture *gen, struct aperture *hw) if (gen-base == hw-base) return true; /* is the generic aperture base inside the hw base-hw base+size */ - if (gen-base hw-base gen-base = hw-base + hw-size) + if (gen-base hw-base gen-base hw-base + hw-size) return true; return false; } -- 1.7.1 -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vgaarb: use bridges to control VGA routing where possible.
From: Dave Airlie airl...@redhat.com
So in a lot of modern systems, a GPU will always be below a parent bridge that
won't share with any other GPUs. This means VGA arbitration on those GPUs can
be controlled by using the bridge routing instead of io/mem decodes.
The problem is locating which GPUs share which upstream bridges. This patch
attempts to identify all the GPUs which can be controlled via bridges, and ones
that can't. This patch endeavours to work out the bridge sharing semantics.
When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the
io/mem decodes for the gpu.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/vga/vgaarb.c | 113 --
drivers/pci/pci.c| 25 ++-
include/linux/pci.h |7 ++-
3 files changed, 118 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index c380c65..aab5c59 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -61,7 +61,7 @@ struct vga_device {
unsigned int mem_lock_cnt; /* legacy MEM lock count */
unsigned int io_norm_cnt; /* normal IO count */
unsigned int mem_norm_cnt; /* normal MEM count */
-
+ bool bridge_has_one_vga;
/* allow IRQ enable/disable hook */
void *cookie;
void (*irq_set_state)(void *cookie, bool enable);
@@ -165,6 +165,8 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
unsigned int pci_bits;
+ u32 flags = 0;
+
/* Account for normal resources to lock. If we decode the legacy,
* counterpart, we need to request it as well
*/
@@ -237,16 +239,23 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
/* looks like he doesn't have a lock, we can steal
* them from him
*/
- vga_irq_set_state(conflict, false);
+ flags = 0;
pci_bits = 0;
- if (lwants (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
- pci_bits |= PCI_COMMAND_MEMORY;
- if (lwants (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
- pci_bits |= PCI_COMMAND_IO;
- pci_set_vga_state(conflict-pdev, false, pci_bits,
- change_bridge);
+ if (!conflict-bridge_has_one_vga) {
+ vga_irq_set_state(conflict, false);
+ flags |= PCI_VGA_STATE_CHANGE_DECODES;
+ if (lwants (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+ pci_bits |= PCI_COMMAND_MEMORY;
+ if (lwants (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+ pci_bits |= PCI_COMMAND_IO;
+ }
+
+ if (change_bridge)
+ flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+ pci_set_vga_state(conflict-pdev, false, pci_bits, flags);
conflict-owns = ~lwants;
/* If he also owned non-legacy, that is no longer the case */
if (lwants VGA_RSRC_LEGACY_MEM)
@@ -261,14 +270,24 @@ enable_them:
* also have in decodes. We can lock resources we don't decode but
* not own them.
*/
+ flags = 0;
pci_bits = 0;
- if (wants (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
- pci_bits |= PCI_COMMAND_MEMORY;
- if (wants (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
- pci_bits |= PCI_COMMAND_IO;
- pci_set_vga_state(vgadev-pdev, true, pci_bits, !!(wants
VGA_RSRC_LEGACY_MASK));
- vga_irq_set_state(vgadev, true);
+ if (!vgadev-bridge_has_one_vga) {
+ flags |= PCI_VGA_STATE_CHANGE_DECODES;
+ if (wants (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+ pci_bits |= PCI_COMMAND_MEMORY;
+ if (wants (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+ pci_bits |= PCI_COMMAND_IO;
+ }
+ if (!!(wants VGA_RSRC_LEGACY_MASK))
+ flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+ pci_set_vga_state(vgadev-pdev, true, pci_bits, flags);
+
+ if (!vgadev-bridge_has_one_vga) {
+ vga_irq_set_state(vgadev, true);
+ }
vgadev-owns |= (wants vgadev-decodes);
lock_them:
vgadev-locks |= (rsrc VGA_RSRC_LEGACY_MASK);
@@ -421,6 +440,62 @@ bail:
}
EXPORT_SYMBOL(vga_put);
+/* Rules for using a bridge to control a VGA descendant decoding:
+ if a bridge has only one VGA descendant then it can be used
+ to control the VGA routing for that device.
+ It should always use the bridge closest to the device to control it.
+ If a bridge has a direct VGA descendant, but also have a sub-bridge
+ VGA descendant then we cannot use that bridge
Re: [PATCH] drm: Fix support for PCI domains
On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
(For some reason I thought that went in ages ago ...)
This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.
When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 18 +-
include/drm/drm_core.h | 2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..6d4bad5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1071,11 +1071,19 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
return ((dev-driver-driver_features feature) ? 1 : 0);
}
-#ifdef __alpha__
-#define drm_get_pci_domain(dev) dev-hose-index
-#else
-#define drm_get_pci_domain(dev) 0
-#endif
+static inline int drm_get_pci_domain(struct drm_device *dev)
+{
+#ifndef __alpha__
+ /* For historical reasons, drm_get_pci_domain() is busticated
+ * on most archs and has to remain so for userspace interface
+ * 1.4, except on alpha which was right from the beginning
+ */
+ if (dev-if_version 0x10004)
+ return 0;
+#endif /* __alpha__ */
+
+ return pci_domain_nr(dev-pdev-bus);
error: implicit declaration of function ‘pci_domain_nr’
on m68k without PCI.
I don't think I want to add an ifdef CONFIG_PCI into the drm layer for
this, since we seem to be okay everywhere else,
lets ask jbarnes, not sure if its safe to just add this to the
!CONFIG_PCI section of the linux/pci.h
Dave.
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Fix support for PCI domains
On Fri, Aug 13, 2010 at 9:45 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 13 Aug 2010 09:33:35 +1000
Dave Airlie airl...@gmail.com wrote:
On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
(For some reason I thought that went in ages ago ...)
This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.
When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 18 +-
include/drm/drm_core.h | 2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..6d4bad5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1071,11 +1071,19 @@ static __inline__ int
drm_core_check_feature(struct drm_device *dev,
return ((dev-driver-driver_features feature) ? 1 : 0);
}
-#ifdef __alpha__
-#define drm_get_pci_domain(dev) dev-hose-index
-#else
-#define drm_get_pci_domain(dev) 0
-#endif
+static inline int drm_get_pci_domain(struct drm_device *dev)
+{
+#ifndef __alpha__
+ /* For historical reasons, drm_get_pci_domain() is busticated
+ * on most archs and has to remain so for userspace interface
+ * 1.4, except on alpha which was right from the beginning
+ */
+ if (dev-if_version 0x10004)
+ return 0;
+#endif /* __alpha__ */
+
+ return pci_domain_nr(dev-pdev-bus);
error: implicit declaration of function ‘pci_domain_nr’
on m68k without PCI.
I don't think I want to add an ifdef CONFIG_PCI into the drm layer for
this, since we seem to be okay everywhere else,
lets ask jbarnes, not sure if its safe to just add this to the
!CONFIG_PCI section of the linux/pci.h
Hm, so pci_domain_nr should just return 0 on platforms where
CONFIG_PCI_DOMAINS isn't set. I'd expect that to be the case when
CONFIG_PCI=n... Maybe we just need to shuffle the definition around?
I suspect something like the attached would suffice.
Or maybe moving the CONFIG_PCI_DOMAINS checkout outside CONFIG_PCI.
Dave.
mydiff
Description: Binary data
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [DRM] BUG: sleeping function called from invalid context, drm_lastclose
On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti kronos...@gmail.com wrote: Hi Arnd, this commit: commit 58374713c9dfb4d231f8c56cac089f6fbdedc2ec Author: Arnd Bergmann a...@arndb.de Date: Sat Jul 10 23:51:39 2010 +0200 drm: kill BKL from common code moved the call to (inside drm_release) drm_lastclose inside dev-count_lock spinlock. drm_lastclose however takes dev-struct_mutex (now inside an atomic context): I have a patch from Chris Wilson that I need to push to fix this, basically reducing the spin lock coverage, and relying on the global mutex to handle the open race. Dave. BUG: sleeping function called from invalid context at /home/kronos/src/linux-2.6.git/kernel/mutex.c:94 in_atomic(): 1, irqs_disabled(): 0, pid: 3331, name: Xorg Pid: 3331, comm: Xorg Not tainted 2.6.35-06113-gf6cec0a #272 Call Trace: [8102770e] __might_sleep+0xf8/0xfa [8127cf18] mutex_lock+0x1f/0x3e [a052d1c1] drm_lastclose+0x92/0x2ad [drm] [a052dbc7] drm_release+0x5ca/0x60d [drm] [810b118f] fput+0x130/0x1f7 [810ae77d] filp_close+0x63/0x6d [810ae82f] sys_close+0xa8/0xe2 [8100296b] system_call_fastpath+0x16/0x1b Luca -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org: Just a quick status in case others are interested and want to help as I have -very- little time. I'm currently testing on a rv350 based aluminium powerbooks. The basic stuff works provided you stay away from AGP. Here's things in no special order I noticed: - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. wierd offb-nouveau worked on my G5, handoff doesn't do anything technically other than just remove offb from the system, and start the driver, so it should be like setting an initial mode. Unless the newer early handover messed it up. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). I've started to port this on the M7 in a thinkpad on my desk, in theory it should save battery life as it appears currently the GPU doesn't go into D3 properly, however I haven't figured out exactly which bits are required, or proven its saving battery (the battery is a little old so I can't be sure). Dave. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes - some more
Looks like I didn't build on IA64 (who knew), fix from Tony and a few more radeon fixes one for a regression since the output probing. The following changes since commit c42750b0261274107ae85c894c088e618a3e38b9: drm/r600: fix possible NULL pointer derefernce (2010-07-21 10:29:32 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (3): drm/radeon/kms: fix legacy LVDS dpms sequence drm/radeon/kms: fix RADEON_INFO_CRTC_FROM_ID info ioctl drm/radeon/kms: add quirk to make HP DV5000 laptop resume Dave Airlie (1): drm/radeon/kms: drop taking lock around crtc lookup. Tony Luck (1): Fix ttm_page_alloc.c build breakage drivers/gpu/drm/radeon/evergreen_cs.c |2 -- drivers/gpu/drm/radeon/r100.c |2 -- drivers/gpu/drm/radeon/r600_cs.c|3 +-- drivers/gpu/drm/radeon/radeon_combios.c |8 drivers/gpu/drm/radeon/radeon_kms.c |3 ++- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + drivers/gpu/drm/ttm/ttm_page_alloc.c|6 +++--- 7 files changed, 15 insertions(+), 10 deletions(-) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes + agp + one fb patch
On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with some updates to the evergreen command stream checker introduced in -rc1. agp: fix issue with warning on memory allocation + fallback to vmalloc. ttm: fix regression introduced in -rc1 in memory allocation paths. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) I've tested these patches and they break my setup (RS780). On reboot, the monitor goes straight to powersaving mode and no framebuffer is shown. Can you bisect which one does it? 2.6.35-rc3 works okay? Dave. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes + agp + one fb patch
On Wed, Jun 30, 2010 at 5:57 PM, Dave Airlie airl...@gmail.com wrote: On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with some updates to the evergreen command stream checker introduced in -rc1. agp: fix issue with warning on memory allocation + fallback to vmalloc. ttm: fix regression introduced in -rc1 in memory allocation paths. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) I've tested these patches and they break my setup (RS780). On reboot, the monitor goes straight to powersaving mode and no framebuffer is shown. Can you bisect which one does it? 2.6.35-rc3 works okay? first guess is 6d35ce0a468b8098c22ca54b4e222c27e364f9bb then 8ed219f50c943a21a0b4f545876b58a344a28f45 then d2c1736971e3cc3b5315d034424a872dc5f44f4a Dave. Dave. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes + agp + one fb patch (bisected)
On Wed, Jun 30, 2010 at 5:31 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with some updates to the evergreen command stream checker introduced in -rc1. agp: fix issue with warning on memory allocation + fallback to vmalloc. ttm: fix regression introduced in -rc1 in memory allocation paths. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) I've tested these patches and they break my setup (RS780). On reboot, the monitor goes straight to powersaving mode and no framebuffer is shown. This is the result of the bisection: 07d4190327b02ab3aaad25a2d168f79d92e8f8c2 is the first bad commit commit 07d4190327b02ab3aaad25a2d168f79d92e8f8c2 Author: Alex Deucher alexdeuc...@gmail.com Date: Sat Jun 12 11:50:13 2010 -0400 drm/radeon/kms: fix bandwidth calculation when sideport is present Fixes fdo bug 27529: https://bugs.freedesktop.org/show_bug.cgi?id=27529 Reported-by: steckde...@yahoo.fr Signed-off-by: Alex Deucher alexdeuc...@gmail.com Cc: stable sta...@kernel.org Signed-off-by: Dave Airlie airl...@redhat.com Okay Linus, hold off on pulling this, and I'll revert it in the morning when I get back to my tree and resend the pull. Maybe Alex will have time to figure out whats gone wrong overnight. Dave. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes + agp + one fb patch
Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with some updates to the evergreen command stream checker introduced in -rc1. agp: fix issue with warning on memory allocation + fallback to vmalloc. ttm: fix regression introduced in -rc1 in memory allocation paths. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Adam Jackson (1): drm/fb: Fix video= mode computation Alex Deucher (7): drm/radeon/kms: fix bandwidth calculation when sideport is present drm/radeon/kms: fix DP after DPMS cycle drm/radeon/kms: fix typo in evergreen_gpu_init drm/radeon/kms: disable frac fb dividers for rs6xx drm/radeon/kms: avoid oops on mac r4xx cards drm/radeon/kms: fix typos in evergreen command checker drm/radeon/kms: add some missing regs to evergreen gpu init Cedric Godin (1): drm/radeon/kms: fix dpms state on resume Dave Airlie (7): drm/radeon: fix dual-head on rv250 radeon/kms: fix powerpc/rn50 untiled behaviour. agp: drop vmalloc flag. agp: add no warn since we have a fallback to vmalloc paths drm/radeon: add fake RN50 table for powerpc drm/radeon/kms: don't read attempt to read bios from VRAM on unposted GPU. fb: fix colliding defines for fb flags. Jerome Glisse (2): drm/ttm: non pooled page allocation should have GFP_USER set drm/radeon/kms: Force HDP_NONSURF to maximum size Matt Turner (1): drm/radeon/kms: return ret in cursor_set failure path Roland Scheidegger (3): drm/radeon/kms: CS checker texture fixes for r1xx/r2xx/r3xx drm/radeon/r200: handle more hw tex coord types drm/radeon/r100/r200: fix calculation of compressed cube maps drivers/char/agp/generic.c |6 +- drivers/gpu/drm/drm_fb_helper.c | 19 -- drivers/gpu/drm/radeon/atombios_crtc.c |2 +- drivers/gpu/drm/radeon/evergreen.c | 35 -- drivers/gpu/drm/radeon/evergreen_cs.c |4 +- drivers/gpu/drm/radeon/evergreend.h |3 + drivers/gpu/drm/radeon/r100.c | 81 +- drivers/gpu/drm/radeon/r200.c |5 ++ drivers/gpu/drm/radeon/r300.c |5 ++ drivers/gpu/drm/radeon/r600.c |2 +- drivers/gpu/drm/radeon/radeon_asic.c|7 ++ drivers/gpu/drm/radeon/radeon_bios.c|4 + drivers/gpu/drm/radeon/radeon_combios.c | 32 + drivers/gpu/drm/radeon/radeon_cursor.c |2 +- drivers/gpu/drm/radeon/radeon_device.c |7 ++ drivers/gpu/drm/radeon/radeon_encoders.c|4 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 22 +++ drivers/gpu/drm/radeon/radeon_mode.h|1 + drivers/gpu/drm/radeon/reg_srcs/evergreen | 10 ++-- drivers/gpu/drm/radeon/rs690.c |6 +-- drivers/gpu/drm/radeon/rv770.c |2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c|2 +- include/linux/agp_backend.h |1 - include/linux/fb.h |4 +- 24 files changed, 182 insertions(+), 84 deletions(-) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fb: fix colliding defines for fb flags.
From: Dave Airlie airl...@redhat.com
When I added the flags I must have been using a 25 line terminal and missed the
following flags.
The collided with flag has one user in staging despite being in-tree for 5
years.
I'm happy to push this via my drm tree unless someone really wants to do it.
Signed-off-by: Dave Airlie airl...@redhat.com
Cc: sta...@kernel.org
---
include/linux/fb.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3..8e5a9df 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -786,8 +786,6 @@ struct fb_tile_ops {
#define FBINFO_MISC_USEREVENT 0x1 /* event request
from userspace */
#define FBINFO_MISC_TILEBLITTING 0x2 /* use tile blitting */
-#define FBINFO_MISC_FIRMWARE 0x4 /* a replaceable firmware
- inited framebuffer */
/* A driver may set this flag to indicate that it does want a set_par to be
* called every time when fbcon_switch is executed. The advantage is that with
@@ -801,6 +799,8 @@ struct fb_tile_ops {
*/
#define FBINFO_MISC_ALWAYS_SETPAR 0x4
+/* where the fb is a firmware driver, and can be replaced with a proper one */
+#define FBINFO_MISC_FIRMWARE0x8
/*
* Host and GPU endianness differ.
*/
--
1.7.1
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vt/console: try harder to print output when panicing
From: Jesse Barnes jbar...@virtuousgeek.org
Jesse's initial patch commit said:
At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context.
I've enhanced this to add a flag to the vc that console layer can set
to indicate they want this behaviour to occur. This also adds support
to fbcon for that flag and adds an fb flag for drivers to indicate
they want to use the support. It enables this for KMS drivers.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/char/vt.c | 13 +
drivers/gpu/drm/i915/intel_fb.c |4 +---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 +
drivers/gpu/drm/radeon/radeon_fb.c |2 +-
drivers/video/console/fbcon.c |4 +++-
include/linux/console_struct.h |1 +
include/linux/fb.h |4
include/linux/vt_kern.h |7 +++
8 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 7cdb6ee..6e04c9e 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -698,7 +698,10 @@ void redraw_screen(struct vc_data *vc, int is_switch)
update_attr(vc);
clear_buffer_attributes(vc);
}
- if (update vc-vc_mode != KD_GRAPHICS)
+
+ /* Forcibly update if we're panicing */
+ if ((update vc-vc_mode != KD_GRAPHICS) ||
+ vt_force_oops_output(vc))
do_update_region(vc, vc-vc_origin,
vc-vc_screenbuf_size / 2);
}
set_cursor(vc);
@@ -736,6 +739,7 @@ static void visual_init(struct vc_data *vc, int num, int
init)
vc-vc_hi_font_mask = 0;
vc-vc_complement_mask = 0;
vc-vc_can_do_color = 0;
+ vc-vc_panic_force_write = false;
vc-vc_sw-con_init(vc, init);
if (!vc-vc_complement_mask)
vc-vc_complement_mask = vc-vc_can_do_color ? 0x7700 : 0x0800;
@@ -2498,7 +2502,7 @@ static void vt_console_print(struct console *co, const
char *b, unsigned count)
goto quit;
}
- if (vc-vc_mode != KD_TEXT)
+ if (vc-vc_mode != KD_TEXT !vt_force_oops_output(vc))
goto quit;
/* undraw cursor first */
@@ -3703,7 +3707,8 @@ void do_unblank_screen(int leaving_gfx)
return;
}
vc = vc_cons[fg_console].d;
- if (vc-vc_mode != KD_TEXT)
+ /* Try to unblank in oops case too */
+ if (vc-vc_mode != KD_TEXT !vt_force_oops_output(vc))
return; /* but leave console_blanked != 0 */
if (blankinterval) {
@@ -3712,7 +3717,7 @@ void do_unblank_screen(int leaving_gfx)
}
console_blanked = 0;
- if (vc-vc_sw-con_blank(vc, 0, leaving_gfx))
+ if (vc-vc_sw-con_blank(vc, 0, leaving_gfx) ||
vt_force_oops_output(vc))
/* Low-level driver cannot restore - do it ourselves */
update_screen(vc);
if (console_blank_hook)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index c3c5052..bd5d87a 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -128,7 +128,7 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
strcpy(info-fix.id, inteldrmfb);
- info-flags = FBINFO_DEFAULT;
+ info-flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info-fbops = intelfb_ops;
/* setup aperture base/size for vesafb takeover */
@@ -146,8 +146,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
info-fix.smem_start = dev-mode_config.fb_base + obj_priv-gtt_offset;
info-fix.smem_len = size;
- info-flags = FBINFO_DEFAULT;
-
info-screen_base = ioremap_wc(dev-agp-base + obj_priv-gtt_offset,
size);
if (!info-screen_base) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index c9a4a0d..9b2d3b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -250,6 +250,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info-flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_IMAGEBLIT;
+ info-flags |= FBINFO_CAN_FORCE_OUTPUT;
info-fbops = nouveau_fbcon_ops;
info-fix.smem_start = dev-mode_config.fb_base + nvbo-bo.offset -
dev_priv-vm_vram_base;
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index dc1634b..dbf8696 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
[PATCH] radeon/kms: fix powerpc/rn50 untiled behaviour.
From: Dave Airlie airl...@redhat.com
Installing 2.6.34 on a Power5/rn50 combo machine, X showed buggy sw rendering,
enabling tiling in the DDX fixed it. Investigation showed that a further /16
was needed in the untiled case on this chipset. Need further investigations
on what other chips this could affect, possibly rv100-rv280.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index cf89aa2..1930db6 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2604,12 +2604,6 @@ int r100_set_surface_reg(struct radeon_device *rdev, int
reg,
int surf_index = reg * 16;
int flags = 0;
- /* r100/r200 divide by 16 */
- if (rdev-family CHIP_R300)
- flags = pitch / 16;
- else
- flags = pitch / 8;
-
if (rdev-family = CHIP_RS200) {
if ((tiling_flags (RADEON_TILING_MACRO|RADEON_TILING_MICRO))
== (RADEON_TILING_MACRO|RADEON_TILING_MICRO))
@@ -2633,6 +2627,20 @@ int r100_set_surface_reg(struct radeon_device *rdev, int
reg,
if (tiling_flags RADEON_TILING_SWAP_32BIT)
flags |= RADEON_SURF_AP0_SWP_32BPP | RADEON_SURF_AP1_SWP_32BPP;
+ /* when we aren't tiling the pitch seems to needs to be furtherdivided
down. - tested on power5 + rn50 server */
+ if (tiling_flags (RADEON_TILING_SWAP_16BIT |
RADEON_TILING_SWAP_32BIT)) {
+ if (!(tiling_flags (RADEON_TILING_MACRO |
RADEON_TILING_MICRO)))
+ if (ASIC_IS_RN50(rdev))
+ pitch /= 16;
+ }
+
+ /* r100/r200 divide by 16 */
+ if (rdev-family CHIP_R300)
+ flags |= pitch / 16;
+ else
+ flags |= pitch / 8;
+
+
DRM_DEBUG(writing surface %d %d %x %x\n, reg, flags, offset,
offset+obj_size-1);
WREG32(RADEON_SURFACE0_INFO + surf_index, flags);
WREG32(RADEON_SURFACE0_LOWER_BOUND + surf_index, offset);
--
1.6.5.2
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: add fake RN50 table for powerpc
From: root r...@ibm-js21-01.lab.bos.redhat.com
This needs more work, esp testing on later servers like js22.
on the js21 I tested on I can't find any answer on any DDC lines.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_combios.c | 32 +++
drivers/gpu/drm/radeon/radeon_mode.h|1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 102c744..1aaa0b5 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1411,6 +1411,11 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
rdev-mode_info.connector_table = CT_IMAC_G5_ISIGHT;
} else
#endif /* CONFIG_PPC_PMAC */
+#ifdef CONFIG_PPC64
+ if (ASIC_IS_RN50(rdev))
+ rdev-mode_info.connector_table = CT_RN50_POWER;
+ else
+#endif
rdev-mode_info.connector_table = CT_GENERIC;
}
@@ -1853,6 +1858,33 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
CONNECTOR_OBJECT_ID_SVIDEO,
hpd);
break;
+ case CT_RN50_POWER:
+ DRM_INFO(Connector Table: %d (rn50-power)\n,
+rdev-mode_info.connector_table);
+ /* VGA - primary dac */
+ ddc_i2c = combios_setup_i2c_bus(rdev, RADEON_GPIO_VGA_DDC);
+ hpd.hpd = RADEON_HPD_NONE;
+ radeon_add_legacy_encoder(dev,
+ radeon_get_encoder_id(dev,
+
ATOM_DEVICE_CRT1_SUPPORT,
+ 1),
+ ATOM_DEVICE_CRT1_SUPPORT);
+ radeon_add_legacy_connector(dev, 0, ATOM_DEVICE_CRT1_SUPPORT,
+ DRM_MODE_CONNECTOR_VGA, ddc_i2c,
+ CONNECTOR_OBJECT_ID_VGA,
+ hpd);
+ ddc_i2c = combios_setup_i2c_bus(rdev, RADEON_GPIO_CRT2_DDC);
+ hpd.hpd = RADEON_HPD_NONE;
+ radeon_add_legacy_encoder(dev,
+ radeon_get_encoder_id(dev,
+
ATOM_DEVICE_CRT2_SUPPORT,
+ 2),
+ ATOM_DEVICE_CRT2_SUPPORT);
+ radeon_add_legacy_connector(dev, 1, ATOM_DEVICE_CRT2_SUPPORT,
+ DRM_MODE_CONNECTOR_VGA, ddc_i2c,
+ CONNECTOR_OBJECT_ID_VGA,
+ hpd);
+ break;
default:
DRM_INFO(Connector table: %d (invalid)\n,
rdev-mode_info.connector_table);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 67358ba..95696aa 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -206,6 +206,7 @@ enum radeon_connector_table {
CT_MINI_INTERNAL,
CT_IMAC_G5_ISIGHT,
CT_EMAC,
+ CT_RN50_POWER,
};
enum radeon_dvo_chip {
--
1.5.5.6
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: fix dual-head on rv250
From: Dave Airlie airl...@redhat.com
Plugged in FireMV with the rv250 on it, and the second crtc/dac didn't work,
we were reading/writing different registers than we were modifying in the code.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 9b5f62b..23ea127 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -931,16 +931,14 @@ static void radeon_legacy_tv_dac_mode_set(struct
drm_encoder *encoder,
if (ASIC_IS_R300(rdev)) {
gpiopad_a = RREG32(RADEON_GPIOPAD_A) | 1;
disp_output_cntl = RREG32(RADEON_DISP_OUTPUT_CNTL);
- }
-
- if (rdev-family == CHIP_R200 || ASIC_IS_R300(rdev))
- disp_tv_out_cntl = RREG32(RADEON_DISP_TV_OUT_CNTL);
- else
+ } else if (rdev-family != CHIP_R200)
disp_hw_debug = RREG32(RADEON_DISP_HW_DEBUG);
-
- if (rdev-family == CHIP_R200)
+ else if (rdev-family == CHIP_R200)
fp2_gen_cntl = RREG32(RADEON_FP2_GEN_CNTL);
+ if (rdev-family = CHIP_R200)
+ disp_tv_out_cntl = RREG32(RADEON_DISP_TV_OUT_CNTL);
+
if (is_tv) {
uint32_t dac_cntl;
@@ -1005,15 +1003,13 @@ static void radeon_legacy_tv_dac_mode_set(struct
drm_encoder *encoder,
if (ASIC_IS_R300(rdev)) {
WREG32_P(RADEON_GPIOPAD_A, gpiopad_a, ~1);
WREG32(RADEON_DISP_OUTPUT_CNTL, disp_output_cntl);
- }
+ } else if (rdev-family != CHIP_R200)
+ WREG32(RADEON_DISP_HW_DEBUG, disp_hw_debug);
+ else if (rdev-family == CHIP_R200)
+ WREG32(RADEON_FP2_GEN_CNTL, fp2_gen_cntl);
if (rdev-family = CHIP_R200)
WREG32(RADEON_DISP_TV_OUT_CNTL, disp_tv_out_cntl);
- else
- WREG32(RADEON_DISP_HW_DEBUG, disp_hw_debug);
-
- if (rdev-family == CHIP_R200)
- WREG32(RADEON_FP2_GEN_CNTL, fp2_gen_cntl);
if (is_tv)
radeon_legacy_tv_mode_set(encoder, mode, adjusted_mode);
--
1.6.5.2
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Regression, post-rc1] Multiple issues after enabling SetVoltage on rs780m
On Mon, Jun 7, 2010 at 7:29 PM, Rafael J. Wysocki r...@sisk.pl wrote: Hi Alex, Your commit 9349d5cc920c10845693f906ebd67f394f1d0d04 (drm/radeon/kms/pm: enable SetVoltage on r7xx/evergreen) has caused my test-bed Acer Ferrari One to behave quite unreliably. The symptoms are: - the system hangs hard (~ 50% of the time) when starting Xorg - the system hangs hard (~ 50% of the time) when stopping Xorg during system reboot - the system sometimes hangs hard during suspend to RAM These problems are not reproducible with the commit above reverted. Below is the information about the graphics adapter from lspci. Reverting that commit on master fixes it? that commit touches code paths in rv770 and evergreen that in no way should affect that chipset which is an rs780, so takes the r600 paths. are you sure its not 7ac9aa5a1f1b87adb69bcbec2b89e228f074103a? Dave. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Regression, post-rc1] Multiple issues after enabling SetVoltage on rs780m
On Mon, 2010-06-07 at 23:37 +0200, Rafael J. Wysocki wrote: On Monday 07 June 2010, Alex Deucher wrote: On Mon, Jun 7, 2010 at 6:15 AM, Dave Airlie airl...@gmail.com wrote: On Mon, Jun 7, 2010 at 7:29 PM, Rafael J. Wysocki r...@sisk.pl wrote: Hi Alex, Your commit 9349d5cc920c10845693f906ebd67f394f1d0d04 (drm/radeon/kms/pm: enable SetVoltage on r7xx/evergreen) has caused my test-bed Acer Ferrari One to behave quite unreliably. The symptoms are: - the system hangs hard (~ 50% of the time) when starting Xorg - the system hangs hard (~ 50% of the time) when stopping Xorg during system reboot - the system sometimes hangs hard during suspend to RAM These problems are not reproducible with the commit above reverted. Below is the information about the graphics adapter from lspci. Reverting that commit on master fixes it? that commit touches code paths in rv770 and evergreen that in no way should affect that chipset which is an rs780, so takes the r600 paths. are you sure its not 7ac9aa5a1f1b87adb69bcbec2b89e228f074103a? It should be that commit if it is indeed the voltage adjust. That said, I just took a closer look at the voltage adjust on newer IGPs and unfortunately, it doesn't work the same as the discrete cards, so for now we should disable it. The attached patch should do the trick. There weren't any problems on my IGP chips, but they don't have a SetVoltage table, so nothing is touching the hw. I'm not sure if the adapter is a discrete one. Anyway, my testing was done before commit 386f40c86d6c8d5b717ef20620af1a750d0dacb4 and I'm unable to reproduce the problems with current -git, so they might be a fallout of the bug fixed by that commit. Yeah the sounded a lot more like the vt.c crapfest, since it was when starting/stopping X. Dave. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/nouveau: attempt to get bios from ACPI v3
From: Dave Airlie airl...@redhat.com
Some of the laptops with the switchable graphics, seem to not post the
secondary GPU at all, and we can't find a copy of the BIOS anywhere except in
the ACPI rom retrieval.
This adds support for ACPI ROM retrieval to nouveau.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 59 +++-
drivers/gpu/drm/nouveau/nouveau_bios.c | 20 +++
drivers/gpu/drm/nouveau/nouveau_drv.h |5 +++
3 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 0e0730a..6e7627d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -34,6 +34,7 @@ static struct nouveau_dsm_priv {
bool dsm_detected;
acpi_handle dhandle;
acpi_handle dsm_handle;
+ acpi_handle rom_handle;
} nouveau_dsm_priv;
static const char nouveau_dsm_muid[] = {
@@ -150,12 +151,13 @@ static bool nouveau_dsm_pci_probe(struct pci_dev *pdev)
dhandle = DEVICE_ACPI_HANDLE(pdev-dev);
if (!dhandle)
return false;
+
status = acpi_get_handle(dhandle, _DSM, nvidia_handle);
if (ACPI_FAILURE(status)) {
return false;
}
- ret= nouveau_dsm(nvidia_handle, NOUVEAU_DSM_SUPPORTED,
+ ret = nouveau_dsm(nvidia_handle, NOUVEAU_DSM_SUPPORTED,
NOUVEAU_DSM_SUPPORTED_FUNCTIONS, result);
if (ret 0)
return false;
@@ -172,6 +174,7 @@ static bool nouveau_dsm_detect(void)
struct pci_dev *pdev = NULL;
int has_dsm = 0;
int vga_count = 0;
+
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA 8, pdev)) !=
NULL) {
vga_count++;
@@ -203,3 +206,57 @@ void nouveau_unregister_dsm_handler(void)
{
vga_switcheroo_unregister_handler();
}
+
+/* retrieve the ROM in 4k blocks */
+static int nouveau_rom_call(acpi_handle rom_handle, uint8_t *bios,
+ int offset, int len)
+{
+ acpi_status status;
+ union acpi_object rom_arg_elements[2], *obj;
+ struct acpi_object_list rom_arg;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
+
+ rom_arg.count = 2;
+ rom_arg.pointer = rom_arg_elements[0];
+
+ rom_arg_elements[0].type = ACPI_TYPE_INTEGER;
+ rom_arg_elements[0].integer.value = offset;
+
+ rom_arg_elements[1].type = ACPI_TYPE_INTEGER;
+ rom_arg_elements[1].integer.value = len;
+
+ status = acpi_evaluate_object(rom_handle, NULL, rom_arg, buffer);
+ if (ACPI_FAILURE(status)) {
+ printk(KERN_INFO failed to evaluate ROM got %s\n,
acpi_format_exception(status));
+ return -ENODEV;
+ }
+ obj = (union acpi_object *)buffer.pointer;
+ memcpy(bios+offset, obj-buffer.pointer, len);
+ kfree(buffer.pointer);
+ return len;
+}
+
+bool nouveau_acpi_rom_supported(struct pci_dev *pdev)
+{
+ acpi_status status;
+ acpi_handle dhandle, rom_handle;
+
+ if (!nouveau_dsm_priv.dsm_detected)
+ return false;
+
+ dhandle = DEVICE_ACPI_HANDLE(pdev-dev);
+ if (!dhandle)
+ return false;
+
+ status = acpi_get_handle(dhandle, _ROM, rom_handle);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ nouveau_dsm_priv.rom_handle = rom_handle;
+ return true;
+}
+
+int nouveau_acpi_get_bios_chunk(uint8_t *bios, int offset, int len)
+{
+ return nouveau_rom_call(nouveau_dsm_priv.rom_handle, bios, offset, len);
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index b5a9336..fe271ec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -177,6 +177,25 @@ out:
pci_disable_rom(dev-pdev);
}
+static void load_vbios_acpi(struct drm_device *dev, uint8_t *data)
+{
+ int i;
+ int ret;
+ int size = 64 * 1024;
+
+ if (!nouveau_acpi_rom_supported(dev-pdev))
+ return;
+
+ for (i = 0; i (size / ROM_BIOS_PAGE); i++) {
+ ret = nouveau_acpi_get_bios_chunk(data,
+ (i * ROM_BIOS_PAGE),
+ ROM_BIOS_PAGE);
+ if (ret = 0)
+ break;
+ }
+ return;
+}
+
struct methods {
const char desc[8];
void (*loadbios)(struct drm_device *, uint8_t *);
@@ -190,6 +209,7 @@ static struct methods nv04_methods[] = {
};
static struct methods nv50_methods[] = {
+ { ACPI, load_vbios_acpi, true },
{ PRAMIN, load_vbios_pramin, true },
{ PROM, load_vbios_prom, false },
{ PCIROM, load_vbios_pci, true },
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index d8b5590..26914cb
[git pull] drm regression fix
Just one patch from Jean to fix some regressions in the buffer code rework. Thanks to Jean for tracking this down. The following changes since commit 8cfe92d683a0041ac8e016a0b0a487c99a78f6c1: Thomas Hellstrom (1): drm/ttm: Remove the ttm_bo_block_reservation() function. are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Jean Delvare (1): drm/radeon: Fix 3 regressions - since buffer rework drivers/gpu/drm/radeon/radeon_state.c | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/fbdev: rework output polling to be back in the core. (v4)
From: Dave Airlie airl...@redhat.com
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd
settings.
v3: add config lock take inside polling, add intel/nouveau poll init/fini calls
v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/drm_crtc_helper.c | 93
drivers/gpu/drm/drm_fb_helper.c | 123 ---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_irq.c |3 +-
drivers/gpu/drm/i915/intel_crt.c|5 +
drivers/gpu/drm/i915/intel_display.c|2 +
drivers/gpu/drm/i915/intel_dp.c |2 +
drivers/gpu/drm/i915/intel_drv.h|2 +-
drivers/gpu/drm/i915/intel_fb.c | 14 ++--
drivers/gpu/drm/i915/intel_hdmi.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c |2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_display.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 14 +--
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +-
drivers/gpu/drm/nouveau/nouveau_state.c |5 +-
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++
drivers/gpu/drm/radeon/radeon_display.c | 10 ++
drivers/gpu/drm/radeon/radeon_fb.c | 15 +---
drivers/gpu/drm/radeon/radeon_irq_kms.c |5 +-
drivers/gpu/drm/radeon/radeon_mode.h|3 +-
include/drm/drm_crtc.h | 17
include/drm/drm_crtc_helper.h |3 +
include/drm/drm_fb_helper.h | 13 +---
26 files changed, 209 insertions(+), 157 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index be5aa7d..2583ddf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
select I2C
select I2C_ALGOBIT
+ select SLOW_WORK
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
@@ -23,7 +24,6 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
- select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b142ac2..fcb1ae8 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -807,3 +807,96 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+static struct slow_work_ops output_poll_ops;
+
+#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = false, changed = false;
+ int ret;
+
+ mutex_lock(dev-mode_config.mutex);
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled)
+ continue;
+
+ else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ old_status = connector-status;
+ /* if we are connected and don't want to poll for disconnect
+ skip it */
+ if (old_status == connector_status_connected
+ !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
+ !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ continue;
+
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
+
+ mutex_unlock(dev-mode_config.mutex);
+
+ if (changed) {
+ /* send a uevent + call fbdev */
+ drm_sysfs_hotplug_event(dev);
+ if (dev-mode_config.funcs-output_poll_changed)
+ dev-mode_config.funcs-output_poll_changed(dev);
+ }
+
+ if (repoll
[PATCH] drm/fbdev: rework output polling to be back in the core. (v3)
From: Dave Airlie airl...@redhat.com
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd
settings.
v3: add config lock take inside polling, add intel/nouveau poll init/fini calls
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/drm_crtc_helper.c | 93
drivers/gpu/drm/drm_fb_helper.c | 123 ---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_irq.c |3 +-
drivers/gpu/drm/i915/intel_crt.c|5 +
drivers/gpu/drm/i915/intel_display.c|2 +
drivers/gpu/drm/i915/intel_dp.c |2 +
drivers/gpu/drm/i915/intel_drv.h|2 +-
drivers/gpu/drm/i915/intel_fb.c | 14 ++--
drivers/gpu/drm/i915/intel_hdmi.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c |2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_display.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 14 +--
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +-
drivers/gpu/drm/nouveau/nouveau_state.c |5 +-
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++
drivers/gpu/drm/radeon/radeon_display.c | 10 ++
drivers/gpu/drm/radeon/radeon_fb.c | 15 +---
drivers/gpu/drm/radeon/radeon_irq_kms.c |5 +-
drivers/gpu/drm/radeon/radeon_mode.h|3 +-
include/drm/drm_crtc.h | 17
include/drm/drm_crtc_helper.h |3 +
include/drm/drm_fb_helper.h | 13 +---
26 files changed, 209 insertions(+), 157 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index be5aa7d..2583ddf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
select I2C
select I2C_ALGOBIT
+ select SLOW_WORK
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
@@ -23,7 +24,6 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
- select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b142ac2..13574b1 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -807,3 +807,96 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+static struct slow_work_ops output_poll_ops;
+
+#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = false, changed = false;
+ int ret;
+
+ mutex_lock(dev-mode_config.mutex);
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled)
+ continue;
+
+ else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ old_status = connector-status;
+ /* if we are connected and don't want to poll for disconnect
+ skip it */
+ if (old_status == connector_status_connected
+ !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
+ !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ continue;
+
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
+
+ if (changed) {
+ /* send a uevent + call fbdev */
+ drm_sysfs_hotplug_event(dev);
+ if (dev-mode_config.funcs-output_poll_changed)
+ dev-mode_config.funcs-output_poll_changed(dev);
+ }
+
+ mutex_unlock(dev-mode_config.mutex);
+
+ if (repoll) {
+ ret = delayed_slow_work_enqueue(delayed_work,
DRM_OUTPUT_POLL_PERIOD);
+ if (ret
[PATCH] drm/fbdev: fix cloning on fbcon
From: Dave Airlie airl...@redhat.com
Simple cloning rules compared to server:
(a) single crtc
(b) 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 17 ---
drivers/gpu/drm/drm_fb_helper.c | 90 --
include/drm/drm_crtc.h |2 +
3 files changed, 96 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..fe68915 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -658,8 +658,8 @@ static struct drm_display_mode drm_dmt_modes[] = {
static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
-static struct drm_display_mode *drm_find_dmt(struct drm_device *dev,
- int hsize, int vsize, int fresh)
+struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
+ int hsize, int vsize, int fresh)
{
int i;
struct drm_display_mode *ptr, *mode;
@@ -677,6 +677,7 @@ static struct drm_display_mode *drm_find_dmt(struct
drm_device *dev,
}
return mode;
}
+EXPORT_SYMBOL(drm_mode_find_dmt);
typedef void detailed_cb(struct detailed_timing *timing, void *closure);
@@ -866,7 +867,7 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
}
/* check whether it can be found in default mode table */
- mode = drm_find_dmt(dev, hsize, vsize, vrefresh_rate);
+ mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
if (mode)
return mode;
@@ -1386,11 +1387,11 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
if (m num_est3_modes)
break;
if (est[i] (1 j)) {
- mode = drm_find_dmt(connector-dev,
- est3_modes[m].w,
- est3_modes[m].h,
- est3_modes[m].r
- /*, est3_modes[m].rb */);
+ mode = drm_mode_find_dmt(connector-dev,
+est3_modes[m].w,
+est3_modes[m].h,
+est3_modes[m].r
+/*, est3_modes[m].rb
*/);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d198b82..38728c4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1070,6 +1070,79 @@ static void drm_enable_connectors(struct drm_fb_helper
*fb_helper,
}
}
+static bool drm_target_cloned(struct drm_fb_helper *fb_helper,
+ struct drm_display_mode **modes,
+ bool *enabled, int width, int height)
+{
+ int count, i, j;
+ bool can_clone = false;
+ struct drm_fb_helper_connector *fb_helper_conn;
+ struct drm_display_mode *dmt_mode, *mode;
+
+ /* only contemplate cloning in the single crtc case */
+ if (fb_helper-crtc_count 1)
+ return false;
+
+ count = 0;
+ for (i = 0; i fb_helper-connector_count; i++) {
+ if (enabled[i])
+ count++;
+ }
+
+ /* only contemplate cloning if more than one connector is enabled */
+ if (count = 1)
+ return false;
+
+ /* check the command line or if nothing common pick 1024x768 */
+ can_clone = true;
+ for (i = 0; i fb_helper-connector_count; i++) {
+ if (!enabled[i])
+ continue;
+ fb_helper_conn = fb_helper-connector_info[i];
+ modes[i] = drm_pick_cmdline_mode(fb_helper_conn, width, height);
+ if (!modes[i]) {
+ can_clone = false;
+ break;
+ }
+ for (j = 0; j i; j++) {
+ if (!enabled[j])
+ continue;
+ if (!drm_mode_equal(modes[j], modes[i]))
+ can_clone = false;
+ }
+ }
+
+ if (can_clone) {
+ DRM_DEBUG_KMS(can clone using command line\n);
+ return true;
+ }
+
+ /* try and find a 1024x768 mode on each connector */
+ can_clone = true;
+ dmt_mode = drm_mode_find_dmt(fb_helper-dev, 1024, 768, 60
Re: RFC: output polling + disconnected operation
2010/5/5 Michel Dänzer mic...@daenzer.net: On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. The thing is current UMS drivers already do bad faking of stuff, have a look at the info-first_load_no_devices flags in -ati. So if nobody ever thought this was worth doing properly in the first place or anytime since, I'd like that KMS drivers can just follow what UMS drivers have done. Granted I could probably do the faking in the KMS X.org drivers, but since UMS drivers never had hotplug or any useful uevent mechanism they'd never see the problem, so I've fixed the drivers to work. My worry with changing X/GNOME is that it'll break some random corner case assumptions somewhere else in userspace, there are many randr clients and I don't want to hunt them all down, I'd like to advertise the protocol we have now if I can. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/fbdev: rework output polling to be back in the core. (v2)
From: Dave Airlie airl...@redhat.com
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd
settings.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/drm_crtc_helper.c | 90 +++
drivers/gpu/drm/drm_fb_helper.c | 123 ---
drivers/gpu/drm/i915/i915_irq.c |3 +-
drivers/gpu/drm/i915/intel_crt.c|5 +
drivers/gpu/drm/i915/intel_display.c|1 +
drivers/gpu/drm/i915/intel_dp.c |2 +
drivers/gpu/drm/i915/intel_drv.h|2 +-
drivers/gpu/drm/i915/intel_fb.c | 14 ++--
drivers/gpu/drm/i915/intel_hdmi.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c |2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_display.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 14 +--
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +-
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++
drivers/gpu/drm/radeon/radeon_display.c |9 ++
drivers/gpu/drm/radeon/radeon_fb.c | 14 +---
drivers/gpu/drm/radeon/radeon_irq_kms.c |5 +-
drivers/gpu/drm/radeon/radeon_mode.h|3 +-
include/drm/drm_crtc.h | 17
include/drm/drm_crtc_helper.h |3 +
include/drm/drm_fb_helper.h | 13 +---
24 files changed, 199 insertions(+), 154 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index be5aa7d..2583ddf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
select I2C
select I2C_ALGOBIT
+ select SLOW_WORK
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
@@ -23,7 +24,6 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
- select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b142ac2..a14848d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -807,3 +807,93 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+static struct slow_work_ops output_poll_ops;
+
+#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = false, changed = false;
+ int ret;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled)
+ continue;
+
+ else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ old_status = connector-status;
+ /* if we are connected and don't want to poll for disconnect
+ skip it */
+ if (old_status == connector_status_connected
+ !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
+ !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ continue;
+
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
+
+ if (changed) {
+ /* send a uevent + call fbdev */
+ drm_sysfs_hotplug_event(dev);
+ if (dev-mode_config.funcs-output_poll_changed)
+ dev-mode_config.funcs-output_poll_changed(dev);
+ }
+
+ if (repoll) {
+ ret = delayed_slow_work_enqueue(delayed_work,
DRM_OUTPUT_POLL_PERIOD);
+ if (ret)
+ DRM_ERROR(delayed enqueue failed %d\n, ret);
+ }
+}
+
+void drm_kms_helper_poll_init(struct drm_device *dev)
+{
+ struct drm_connector *connector;
+ bool poll = false;
+ int ret;
+
+ list_for_each_entry(connector, dev
[PATCH 1/3] drm/radeon/kms: avoid executing dac detection table on r4xx + rv515.
From: Dave Airlie airl...@redhat.com
The DAC Load detection table is meant to take a parameter selecting the DAC
to do load detection on. However on certain BIOS revisions it accept no
parameters and load detects both DACs, with the result that load detecting on
the second DAC causes flicker on the first, which isn't really acceptable.
This also makes us report disconnected instead of unknown for the case where
we have no DAC detection.
We should code up a workaround function for these chips to workaround this
case.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atom.c| 15 +--
drivers/gpu/drm/radeon/atom.h|2 ++
drivers/gpu/drm/radeon/radeon_encoders.c | 15 +++
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 1d56983..c1c669a 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1330,12 +1330,13 @@ bool atom_parse_data_header(struct atom_context *ctx,
int index,
return true;
}
-bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t * frev,
- uint8_t * crev)
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*frev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size)
{
int offset = index * 2 + 4;
int idx = CU16(ctx-cmd_table + offset);
u16 *mct = (u16 *)(ctx-bios + ctx-cmd_table + 4);
+ u16 table_attrib = CU16(idx + 4);
if (!mct[index])
return false;
@@ -1344,9 +1345,19 @@ bool atom_parse_cmd_header(struct atom_context *ctx, int
index, uint8_t * frev,
*frev = CU8(idx + 2);
if (crev)
*crev = CU8(idx + 3);
+ if (ps_size)
+ *ps_size = (table_attrib 0xe00) 8;
+ if (ws_size)
+ *ws_size = (table_attrib 0xff);
return true;
}
+bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t *rev,
+ uint8_t *crev)
+{
+ return atom_parse_cmd_header_stack(ctx, index, rev, crev, NULL, NULL);
+}
+
int atom_allocate_fb_scratch(struct atom_context *ctx)
{
int index = GetIndexIntoMasterTable(DATA, VRAM_UsageByFirmware);
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index cd1b64a..ca21357 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -147,6 +147,8 @@ bool atom_parse_data_header(struct atom_context *ctx, int
index, uint16_t *size,
uint8_t *frev, uint8_t *crev, uint16_t *data_start);
bool atom_parse_cmd_header(struct atom_context *ctx, int index,
uint8_t *frev, uint8_t *crev);
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*rev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size);
int atom_allocate_fb_scratch(struct atom_context *ctx);
#include atom-types.h
#include atombios.h
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 30293be..f2ea756 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1406,13 +1406,20 @@ atombios_dac_load_detect(struct drm_encoder *encoder,
struct drm_connector *conn
ATOM_DEVICE_CRT_SUPPORT)) {
DAC_LOAD_DETECTION_PS_ALLOCATION args;
int index = GetIndexIntoMasterTable(COMMAND, DAC_LoadDetection);
- uint8_t frev, crev;
+ uint8_t frev, crev, ps_size;
memset(args, 0, sizeof(args));
- if (!atom_parse_cmd_header(rdev-mode_info.atom_context, index,
frev, crev))
+ if (!atom_parse_cmd_header_stack(rdev-mode_info.atom_context,
index, frev, crev, ps_size, NULL))
return false;
+ /* r4xx and some early rv5xx probe all DACs, this can cause
distrubances in the force,
+ also on other DACs. - we can detect these tables as they
have a 0 sized param stack */
+ if (ps_size == 0) {
+ DRM_DEBUG(DAC load detection isn't properly supported
on this GPU\n);
+ return false;
+ }
+
args.sDacload.ucMisc = 0;
if ((radeon_encoder-encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_DAC1) ||
@@ -1452,8 +1459,8 @@ radeon_atom_dac_detect(struct drm_encoder *encoder,
struct drm_connector *connec
uint32_t bios_0_scratch;
if (!atombios_dac_load_detect(encoder, connector)) {
- DRM_DEBUG(detect returned false \n);
- return connector_status_unknown;
+ DRM_DEBUG(dac detect returned false\n);
+ return connector_status_disconnected;
}
if (rdev-family
RFC: output polling + disconnected operation
So one of the problems I want to solve for KMS it the what to do when nothing is plugged in at startup, I've fixed this for fbcon in the current tree, but when looking at X + randr clients I realised it needed a bit more work. I've pulled the polling code back into the core, and it nows can send uevents to userspace when something changes. The drivers can specify flags for each output as to whether it is hotplug capable, needs connection polling and can handle disconnection polling. A lot of outputs can't handle disconnection polling due to DAC polling causing flicker on the current output. Also things like s-video shouldn't be polled for connect or disconnect esp if sharing a dac with a VGA output. So with patch one, we can boot, start X all without anything connected, however it runs into an issue which patch 2 is an attempt to fix. So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm: create fake disconnected connector for use when nothing is plugged in.
From: Dave Airlie airl...@redhat.com
The problem with using a real connector with a fake status is we have no way to
tell userspace it got disconnected if something gets plugged into it, i.e. you
use DVI-0 as the connector with an unknown or connected status, and it puts a
1024x768 mode on it. However when a monitor appears on that connector when we
send the uevent and userspace repolls the modes it won't reset the mode on that
output because the status hasn't changed sufficenetly. Unknown-connected
status changes don't cause gnome to set the mode again.
Idea from Ben Skeggs to just create a fake disconnected connector, this seems
to work well, xrandr gets a bit more info that needed, but gnome seems to work
fine.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c| 40 +
drivers/gpu/drm/drm_crtc_helper.c | 25 --
drivers/gpu/drm/drm_fb_helper.c |2 +
include/drm/drm_crtc.h|4 +++
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 994d23b..3b880ca 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -499,6 +499,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
mutex_unlock(dev-mode_config.mutex);
+ connector-dev = NULL;
}
EXPORT_SYMBOL(drm_connector_cleanup);
@@ -1560,6 +1561,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
+ if (out_id ==
dev-mode_config.disconnected_connector.base.id) {
+ ret = 0;
+ goto out;
+ }
+
obj = drm_mode_object_find(dev, out_id,
DRM_MODE_OBJECT_CONNECTOR);
if (!obj) {
@@ -2655,3 +2661,37 @@ out:
mutex_unlock(dev-mode_config.mutex);
return ret;
}
+
+static void drm_connector_disconnected_dpms(struct drm_connector *connector,
int mode)
+{
+ return;
+}
+
+static enum drm_connector_status drm_connector_disconnected_detect(struct
drm_connector *connector)
+{
+ return connector_status_disconnected;
+}
+
+static int drm_connector_disconnected_fill_modes(struct drm_connector
*connector, u32 max_width, u32 max_height)
+{
+ return 0;
+}
+
+static struct drm_connector_funcs drm_disconnected_funcs = {
+ .dpms = drm_connector_disconnected_dpms,
+ .detect = drm_connector_disconnected_detect,
+ .fill_modes = drm_connector_disconnected_fill_modes,
+ .destroy = drm_connector_cleanup,
+};
+
+int drm_mode_add_disconnected_connector(struct drm_device *dev)
+{
+ if (dev-mode_config.disconnected_connector.dev == NULL) {
+ drm_connector_init(dev,
dev-mode_config.disconnected_connector,
+ drm_disconnected_funcs,
+ DRM_MODE_CONNECTOR_Unknown);
+ dev-mode_config.disconnected_connector.status =
connector_status_disconnected;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_add_disconnected_connector);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ebb7a0c..665febb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -819,11 +819,20 @@ static void output_poll_execute(struct slow_work *work)
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
int ret;
+ bool connected = false;
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- /* if this is HPD or polled don't check it - TV out for
instance */
- if (!connector-polled)
+
+ /* skip the special disconnected connector */
+ if (dev-mode_config.disconnected_connector == connector)
+ continue;
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled) {
+ if (connector-status == connector_status_connected)
+ connected = true;
continue;
+ }
else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
repoll = true;
@@ -832,8 +841,10 @@ static void output_poll_execute(struct slow_work *work)
skip it */
if (old_status == connector_status_connected
!(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
- !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ !(connector-polled DRM_CONNECTOR_POLL_HPD
[PATCH 1/2] drm/fbdev: rework output polling to be back in the core.
From: Dave Airlie airl...@redhat.com
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig|2 +-
drivers/gpu/drm/drm_crtc_helper.c | 90
drivers/gpu/drm/drm_fb_helper.c| 123
drivers/gpu/drm/i915/i915_irq.c|3 +-
drivers/gpu/drm/i915/intel_display.c |1 +
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c| 14 ++--
drivers/gpu/drm/nouveau/nouveau_display.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c| 14 +--
drivers/gpu/drm/nouveau/nouveau_fbcon.h|2 +-
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++
drivers/gpu/drm/radeon/radeon_display.c|9 ++
drivers/gpu/drm/radeon/radeon_fb.c | 14 +---
drivers/gpu/drm/radeon/radeon_irq_kms.c|5 +-
drivers/gpu/drm/radeon/radeon_mode.h |3 +-
include/drm/drm_crtc.h | 17
include/drm/drm_crtc_helper.h |3 +
include/drm/drm_fb_helper.h| 13 +---
19 files changed, 177 insertions(+), 154 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index be5aa7d..2583ddf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
select I2C
select I2C_ALGOBIT
+ select SLOW_WORK
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
@@ -23,7 +24,6 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
- select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b142ac2..ebb7a0c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -807,3 +807,93 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+static struct slow_work_ops output_poll_ops;
+
+#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = false, changed = false;
+ int ret;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ /* if this is HPD or polled don't check it - TV out for
instance */
+ if (!connector-polled)
+ continue;
+ else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ old_status = connector-status;
+ /* if we are connected and don't want to poll for disconnect
+ skip it */
+ if (old_status == connector_status_connected
+ !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
+ !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ continue;
+
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+
+ if (status == connector_status_connected)
+ connected = true;
+ }
+
+ if (changed) {
+ /* send a uevent + call fbdev */
+ drm_sysfs_hotplug_event(dev);
+ if (dev-mode_config.funcs-output_poll_changed)
+ dev-mode_config.funcs-output_poll_changed(dev);
+ }
+
+ if (repoll) {
+ ret = delayed_slow_work_enqueue(delayed_work,
DRM_OUTPUT_POLL_PERIOD);
+ if (ret)
+ DRM_ERROR(delayed enqueue failed %d\n, ret);
+ }
+}
+
+void drm_kms_helper_poll_init(struct drm_device *dev)
+{
+ struct drm_connector *connector;
+ bool poll = false;
+ int ret;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ if (connector-polled)
+ poll = true;
+ }
+ slow_work_register_user(THIS_MODULE);
+ delayed_slow_work_init(dev-mode_config.output_poll_slow_work,
+ output_poll_ops);
+
+ if (poll) {
+ ret =
delayed_slow_work_enqueue(dev
Re: RFC: output polling + disconnected operation
On Wed, May 5, 2010 at 11:37 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. It's an ugly problem... When the hotplug event is received, wouldn't you re-probe and find a digital monitor attached? If so, that would mean a mode set sent in by the X server should end up being a full one since the current config is incompatible. Which means X just has to know it forced a mode, so when any event comes in it should re-set the mode unconditionally... Userspace (as in gnome/kde/xrandr) doesn't know what is attached, digital or analog, it just sees a connected status, notices it was connected before, it still connected and doesn't do anything. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/bo: add some fallback placements for VRAM only objects. (v2)
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
v2:
fixes issue identified by Michel when pinning could happen in a busy placement
domain.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|4 +++-
drivers/gpu/drm/radeon/radeon_object.c | 22 +-
drivers/gpu/drm/radeon/radeon_ttm.c|6 +++---
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e912098..a23a6ab 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -240,7 +240,9 @@ struct radeon_bo {
struct list_headlist;
/* Protected by tbo.reserved */
u32 placements[3];
+ u32 busy_placements[3];
struct ttm_placementplacement;
+ struct ttm_placementbusy_placement;
struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
unsignedpin_count;
@@ -1227,7 +1229,7 @@ extern void radeon_surface_init(struct radeon_device
*rdev);
extern int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data);
extern void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
-extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
+extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain, bool pinned);
extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
extern void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc
*mc, u64 base);
extern void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc
*mc);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 6a8617b..ab3bc7b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -64,17 +64,21 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object
*bo)
return false;
}
-void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
+void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain, bool
pinned)
{
- u32 c = 0;
+ u32 c = 0, b = 0;
rbo-placement.fpfn = 0;
rbo-placement.lpfn = 0;
rbo-placement.placement = rbo-placements;
- rbo-placement.busy_placement = rbo-placements;
+ rbo-placement.busy_placement = rbo-busy_placements;
if (domain RADEON_GEM_DOMAIN_VRAM)
rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_VRAM;
+ /* add busy placement to TTM if VRAM is only option */
+ if (domain == RADEON_GEM_DOMAIN_VRAM pinned == false) {
+ rbo-busy_placements[b++] = TTM_PL_MASK_CACHING |
TTM_PL_FLAG_TT;
+ }
if (domain RADEON_GEM_DOMAIN_GTT)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
if (domain RADEON_GEM_DOMAIN_CPU)
@@ -82,7 +86,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo,
u32 domain)
if (!c)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo-placement.num_placement = c;
- rbo-placement.num_busy_placement = c;
+ rbo-placement.num_busy_placement = b;
}
int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
@@ -110,7 +114,7 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
bo-surface_reg = -1;
INIT_LIST_HEAD(bo-list);
- radeon_ttm_placement_from_domain(bo, domain);
+ radeon_ttm_placement_from_domain(bo, domain, false);
/* Kernel allocation are uninterruptible */
r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type,
bo-placement, 0, 0, !kernel, NULL, size,
@@ -185,7 +189,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64
*gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
return 0;
}
- radeon_ttm_placement_from_domain(bo, domain);
+ radeon_ttm_placement_from_domain(bo, domain, true);
if (domain == RADEON_GEM_DOMAIN_VRAM) {
/* force to pin into visible video ram */
bo-placement.lpfn = bo-rdev-mc.visible_vram_size
PAGE_SHIFT;
@@ -325,10 +329,10 @@ int radeon_bo_list_validate(struct list_head *head)
if (!bo-pin_count) {
if (lobj-wdomain) {
radeon_ttm_placement_from_domain(bo,
- lobj-wdomain
[PATCH] drm/radeon/kms: avoid executing dac detection table on r4xx + rv515.
From: Dave Airlie airl...@redhat.com
The DAC Load detection table is meant to take a parameter selecting the DAC
to do load detection on. However on certain BIOS revisions it accept no
parameters and load detects both DACs, with the result that load detecting on
the second DAC causes flicker on the first, which isn't really acceptable.
We should code up a workaround function for these chips to workaround this
case.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atom.c| 15 +--
drivers/gpu/drm/radeon/atom.h|2 ++
drivers/gpu/drm/radeon/radeon_encoders.c | 11 +--
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index bcec2d7..6477ac5 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1320,12 +1320,13 @@ bool atom_parse_data_header(struct atom_context *ctx,
int index,
return true;
}
-bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t * frev,
- uint8_t * crev)
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*frev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size)
{
int offset = index * 2 + 4;
int idx = CU16(ctx-cmd_table + offset);
u16 *mct = (u16 *)(ctx-bios + ctx-cmd_table + 4);
+ u16 table_attrib = CU16(idx + 4);
if (!mct[index])
return false;
@@ -1334,9 +1335,19 @@ bool atom_parse_cmd_header(struct atom_context *ctx, int
index, uint8_t * frev,
*frev = CU8(idx + 2);
if (crev)
*crev = CU8(idx + 3);
+ if (ps_size)
+ *ps_size = (table_attrib 0xe00) 8;
+ if (ws_size)
+ *ws_size = (table_attrib 0xff);
return true;
}
+bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t *rev,
+ uint8_t *crev)
+{
+ return atom_parse_cmd_header_stack(ctx, index, rev, crev, NULL, NULL);
+}
+
int atom_allocate_fb_scratch(struct atom_context *ctx)
{
int index = GetIndexIntoMasterTable(DATA, VRAM_UsageByFirmware);
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index cd1b64a..ca21357 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -147,6 +147,8 @@ bool atom_parse_data_header(struct atom_context *ctx, int
index, uint16_t *size,
uint8_t *frev, uint8_t *crev, uint16_t *data_start);
bool atom_parse_cmd_header(struct atom_context *ctx, int index,
uint8_t *frev, uint8_t *crev);
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*rev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size);
int atom_allocate_fb_scratch(struct atom_context *ctx);
#include atom-types.h
#include atombios.h
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index c52fc30..36bcabd 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1398,12 +1398,19 @@ atombios_dac_load_detect(struct drm_encoder *encoder,
struct drm_connector *conn
ATOM_DEVICE_CRT_SUPPORT)) {
DAC_LOAD_DETECTION_PS_ALLOCATION args;
int index = GetIndexIntoMasterTable(COMMAND, DAC_LoadDetection);
- uint8_t frev, crev;
+ uint8_t frev, crev, ps_size;
memset(args, 0, sizeof(args));
- if (!atom_parse_cmd_header(rdev-mode_info.atom_context, index,
frev, crev))
+ if (!atom_parse_cmd_header_stack(rdev-mode_info.atom_context,
index, frev, crev, ps_size, NULL))
return false;
+
+ /* r4xx and some early rv5xx probe all DACs, this can cause
distrubances in the force,
+ also on other DACs. - we can detect these tables as they
have a 0 sized param stack */
+ if (ps_size == 0) {
+ DRM_DEBUG(not executing dac load detection table due
to buggy atom table\n);
+ return false;
+ }
args.sDacload.ucMisc = 0;
--
1.7.0.1
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't print error for legal crtcs.
From: Dave Airlie airl...@redhat.com
With evergreen this is bounded by num_crtc not by 0,1.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 3c5002e..99d2fb3 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -161,7 +161,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
int crtc)
{
struct radeon_device *rdev = dev-dev_private;
- if (crtc 0 || crtc 1) {
+ if (crtc 0 || crtc = rdev-num_crtc) {
DRM_ERROR(Invalid crtc %d\n, crtc);
return -EINVAL;
}
@@ -173,7 +173,7 @@ int radeon_enable_vblank_kms(struct drm_device *dev, int
crtc)
{
struct radeon_device *rdev = dev-dev_private;
- if (crtc 0 || crtc 1) {
+ if (crtc 0 || crtc = rdev-num_crtc) {
DRM_ERROR(Invalid crtc %d\n, crtc);
return -EINVAL;
}
@@ -187,7 +187,7 @@ void radeon_disable_vblank_kms(struct drm_device *dev, int
crtc)
{
struct radeon_device *rdev = dev-dev_private;
- if (crtc 0 || crtc 1) {
+ if (crtc 0 || crtc = rdev-num_crtc) {
DRM_ERROR(Invalid crtc %d\n, crtc);
return;
}
--
1.6.5.2
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [radeon] Hardcoded DRIVER_DATE?
On Mon, 2010-04-19 at 11:30 +0200, Sedat Dilek wrote: Hi, today I pulled drm-linus GIT branch into Linus-tree (2.6.34-rc4-git6). Again, I was seeing a version-bump of the radeon-kms wrapper/driver, but not in the driver-date: [dmesg] ... [ 71.347298] [drm] Initialized radeon 2.3.0 20080528 for :01:00.0 on minor 0 ... While inspecting where the driver-date is defined, I found: $ grep DRIVER_DATE -r drivers/gpu/drm/radeon/ drivers/gpu/drm/radeon/radeon_drv.h:#define DRIVER_DATE 20080528 drivers/gpu/drm/radeon/radeon_drv.c: .date = DRIVER_DATE, drivers/gpu/drm/radeon/radeon_drv.c: .date = DRIVER_DATE, Looking closer into both files ([1] and [2]) reveals: [drivers/gpu/drm/radeon/radeon_drv.h] ... #define DRIVER_NAME radeon #define DRIVER_DESC ATI Radeon #define DRIVER_DATE 20080528 ... * 1.32- fixes for rv740 setup * 1.33- Add r6xx/r7xx const buffer support */ #define DRIVER_MAJOR 1 #define DRIVER_MINOR 33 #define DRIVER_PATCHLEVEL 0 ... [drivers/gpu/drm/radeon/radeon_drv.c] ... /* * KMS wrapper. * - 2.0.0 - initial interface * - 2.1.0 - add square tiling interface * - 2.2.0 - add r6xx/r7xx const buffer support * - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs */ #define KMS_DRIVER_MAJOR 2 #define KMS_DRIVER_MINOR 3 #define KMS_DRIVER_PATCHLEVEL 0 ... .name = DRIVER_NAME, .desc = DRIVER_DESC, .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, ... My first thoughts on this was, if you manage two files with version informations, it is human to forget to bump it in both. Dave apologized to be lazy for the changes on IRC. The second thought was, why the hell are there two version-strings? 1.33.0 (H-file) and 2.3.0 (C-file). OK, the second one is for the KMS-wrapper, the first one is for radeon kernel-module in general. The version-infos from the H-file/C-file can be read in dmesg: ... [9.861334] [drm] Initialized radeon 1.33.0 20080528 for :01:00.0 on minor 0 ... [ 71.347298] [drm] Initialized radeon 2.3.0 20080528 for :01:00.0 on minor 0 ... Do changes in radeon_drv.c (KMS-wrapper) require also a version-bump in the header-file? I think yes. No they don't. KMS and UMS drivers are separate. I referred to bumping the date as lazy, we rarely bothered doing it in the past. Dave. IIRC this is missing and version should be bumped: [drivers/gpu/drm/radeon/radeon_drv.h] ... * 1.33- Add r6xx/r7xx const buffer support + * 1.34- add MSPOS + 3D texture + r500 VAP regs */ #define DRIVER_MAJOR 1 -#define DRIVER_MINOR 33 +#define DRIVER_MINOR 34 #define DRIVER_PATCHLEVEL 0 ... My third thought was, when there is a version-string for radeon kernel-module why don't I see them via modinfo? $ sudo modinfo radeon | grep -i ver filename: /lib/modules/2.6.34-rc4-iniza-686-kms/kernel/drivers/gpu/drm/radeon/radeon.ko srcversion: 27576A7F4ADA88E07720FD4 vermagic: 2.6.34-rc4-iniza-686-kms SMP preempt mod_unload modversions 686 Unfortunately, NO. Is there something speaking against to have it in the module-description? How does other kernel-module handle such things? Usual - unusual? Guideline? By reading this report one could think it is only cosmetics (and not writing so much text), but why use a driver-date that is simply wrong or unused? Kind Regards, - Sedat - References: === [1] http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob_plain;f=drivers/gpu/drm/radeon/radeon_drv.h;hb=cae94b0ad9d147152af77b971a7234faf20027a9 [2] http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob_plain;f=drivers/gpu/drm/radeon/radeon_drv.c;hb=cae94b0ad9d147152af77b971a7234faf20027a9 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] make gem_object embedable and convert i915 driver
On Tue, Apr 13, 2010 at 5:19 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Apr 12, 2010 at 10:51:20AM -0700, Eric Anholt wrote: On Fri, 9 Apr 2010 21:05:03 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Daniel Vetter (6): drm: extract drm_gem_object_init drm: free core gem object from driver callbacks drm/i915: introduce i915_gem_alloc_object drm/i915: embed the gem object into drm_i915_gem_object drm/i915: don't use -driver_private anymore drm/i915: drop pointer to drm_gem_object I like this series. Dave, should I pull this one? Cool. wrt merging I'd prefer if Dave could take the first two via drm-core. That way round I could start working on the radeon/nouveau stuff independently of the i915 stuff. That'd stall i915 slightly but i915 is the easiest conversion (that's why I did it first) so I can quickly rebase in case of conflicts I'll take these via my tree, Eric just let me know if I can assume your ack on the i915 ones and even the main one. I'll try and review them over the next couple of days. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 05/13] drm/ttm: ttm_fault callback to allow driver to handle bo placement V5
On Wed, Apr 7, 2010 at 8:21 PM, Jerome Glisse jgli...@redhat.com wrote:
On fault the driver is given the opportunity to perform any operation
it sees fit in order to place the buffer into a CPU visible area of
memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
should keep working properly. Future patch will take advantage of this
infrastructure and remove the old path from TTM once driver are
converted.
V2 return VM_FAULT_NOPAGE if callback return -EBUSY or -ERESTARTSYS
V3 balance io_mem_reserve and io_mem_free call, fault_reserve_notify
is responsible to perform any necessary task for mapping to succeed
V4 minor cleanup, atomic_t - bool as member is protected by reserve
mecanism from concurent access
V5 the callback is now responsible for iomapping the bo and providing
a virtual address this simplify TTM and will allow to get rid of
TTM_MEMTYPE_FLAG_NEEDS_IOREMAP
Okay I've applied all these to drm-next and it fails to run X for longer than
5 mins on my 32-bit machine.
The whole IO reserve thing looks like a bad idea for anything but kmap,
since it ioremap's the pages, but we have limited ioremap space on 32-bit,
and you hit that and vmallocs all start failing soon after.
- ret = ttm_bo_pci_offset(bdev, bo-mem, bus_base, bus_offset,
- bus_size);
- if (unlikely(ret != 0)) {
+ ret = ttm_mem_io_reserve(bdev, bo-mem);
+ if (ret) {
retval = VM_FAULT_SIGBUS;
goto out_unlock;
}
This is the start of the insanity, since ever bo that takes a
userspace pagefault
ends up using ioremap space for *no* reason whatsoever at all. You only need
to use ioremap space if the *kernel* is accessing the bo not if userspace is,
so really only in the kmap space.
I've dropped it all from drm-next until you can resolve this.
Dave.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Nothing major, Mostly nouveau changes, some radeon tv output fixes, and a couple of quirks. The following changes since commit d668046c13024d74af7d04a124ba55f406380fe7: Dave Airlie (1): drm/radeon/kms: enable ACPI powermanagement mode on radeon gpus. are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Adam Jackson (1): drm/edid/quirks: Envision EN2028 Alex Deucher (5): drm/radeon/kms/atom: fix gpio i2c table overrun (v2) drm/radeon/kms: fix washed out image on legacy tv dac drm/radeon/kms: legacy tv dac cleanup drm/radeon/kms: clean up atom dac handling drm/radeon/kms/combios: verify dac_adj values are valid Ben Skeggs (16): drm/nv50: fix fbcon when framebuffer above 4GiB mark drm/nv50: add more 0x100c80 flushy magic drm/nouveau: remove some unused members from drm_nouveau_private drm/nouveau: detect vram amount once, and save the value drm/nv40: rework lvds table parsing drm/nv40: add LVDS table quirk for Dell Latitude D620 drm/nv50: fix instmem init on IGPs if stolen mem crosses 4GiB mark drm/nouveau: fixup the init failure paths some more drm/nv50: cleanup properly if PDISPLAY init fails drm/nv50: preserve an unknown SOR_MODECTRL value for DP encoders drm/nv50: punt hotplug irq handling out to workqueue drm/nv50: another dodgy DP hack drm/nouveau: store raw gpio table entry in bios gpio structs drm/nv50: parse/use some more de-magiced parts of gpio table entries drm/nv50: implement gpio set/get routines drm/nouveau: bail out of auxch transaction if we repeatedly recieve defers Dan Carpenter (1): drm/radeon/kms: small memory leak in atom exit code Dave Airlie (1): Merge remote branch 'nouveau/for-airlied' of ../drm-nouveau-next into drm-linus Francisco Jerez (2): drm/nouveau: Make use of TTM busy_placements. drm/nv40: Init some tiling-related PGRAPH state. Marcin Kościelnicki (3): drm/nv50: Fix NEWCTX_DONE flag number drm/nv50: Allow using the NVA3 new compute class. drm/nv50: Add NVA3 support in ctxprog/ctxvals generator. Michel Dänzer (1): drm/radeon: R300 AD only has one quad pipe. drivers/gpu/drm/drm_edid.c |2 + drivers/gpu/drm/nouveau/Makefile|2 +- drivers/gpu/drm/nouveau/nouveau_bios.c | 127 +++ drivers/gpu/drm/nouveau/nouveau_bios.h |4 +- drivers/gpu/drm/nouveau/nouveau_bo.c| 67 +++-- drivers/gpu/drm/nouveau/nouveau_channel.c |2 - drivers/gpu/drm/nouveau/nouveau_debugfs.c |5 +- drivers/gpu/drm/nouveau/nouveau_dp.c|8 ++- drivers/gpu/drm/nouveau/nouveau_drv.h | 40 drivers/gpu/drm/nouveau/nouveau_encoder.h |1 + drivers/gpu/drm/nouveau/nouveau_gem.c | 55 +-- drivers/gpu/drm/nouveau/nouveau_irq.c |1 + drivers/gpu/drm/nouveau/nouveau_mem.c | 124 ++- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 18 +++ drivers/gpu/drm/nouveau/nouveau_state.c | 14 ++- drivers/gpu/drm/nouveau/nv40_fifo.c |2 +- drivers/gpu/drm/nouveau/nv40_graph.c| 21 drivers/gpu/drm/nouveau/nv50_display.c | 22 +++-- drivers/gpu/drm/nouveau/nv50_display.h |1 + drivers/gpu/drm/nouveau/nv50_fbcon.c| 13 ++- drivers/gpu/drm/nouveau/nv50_gpio.c | 76 ++ drivers/gpu/drm/nouveau/nv50_graph.c|7 +- drivers/gpu/drm/nouveau/nv50_grctx.c| 19 +++- drivers/gpu/drm/nouveau/nv50_instmem.c | 16 +-- drivers/gpu/drm/nouveau/nv50_sor.c | 25 +- drivers/gpu/drm/radeon/atom.c |7 +- drivers/gpu/drm/radeon/r300.c |5 +- drivers/gpu/drm/radeon/radeon_atombios.c| 11 ++- drivers/gpu/drm/radeon/radeon_combios.c | 20 +++- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_cp.c | 10 +- drivers/gpu/drm/radeon/radeon_encoders.c| 21 ++--- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 58 ++- 33 files changed, 508 insertions(+), 298 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nv50_gpio.c-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] typdef uintptr_t drm_handle_t; unsigned int is wrong on 64-bit.
On Sat, Apr 3, 2010 at 11:09 PM, Matthew W. S. Bell matt...@bells23.org.uk wrote: On Sat, 2010-04-03 at 08:49 +0100, Dave Airlie wrote: No, its designed as is. We can't change it now as its ABI. We make sure we only use 32-bit handles anyways. The thing is unsigned int is correct for the handles, they are defined to be 32-bit numbers no matter what system they are on, its the use of the void * that is actually the problem. Its probably not documented well anywhere, though I think the handles are 32-bit is written down somewhere. Dave. OK, is this documented anywhere, as I'd like to pull some of that into a comment? (It appears, on a casual glance, that this type is not used in the kernel ABI, but only in the libdrm, and associates?, ABI, so could be changed if the SONAME got bumped and anyone cared.) Matthew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] typdef uintptr_t drm_handle_t; unsigned int is wrong on 64-bit.
drm_handle_t appears to be assigned values from void*. As such unsigned int is certainly not the same size on 64-bit. Convert to uintptr_t in all cases as it is defined for this purpose. No, its designed as is. We can't change it now as its ABI. We make sure we only use 32-bit handles anyways. Dave. I fear this patch changes ABI, but I am not sure. Matthew W.S. Bell --- include/drm/drm.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drm.h b/include/drm/drm.h index 4822159..95141a2 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -40,7 +40,7 @@ #include linux/types.h #include asm/ioctl.h -typedef unsigned int drm_handle_t; +typedef uintptr_t drm_handle_t; #else /* One of the BSDs */ @@ -54,7 +54,7 @@ typedef int32_t __s32; typedef uint32_t __u32; typedef int64_t __s64; typedef uint64_t __u64; -typedef unsigned long drm_handle_t; +typedef uintptr_t drm_handle_t; #endif -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm tree
a pull from nouveau + minor drm core fixes, Lots of radeon fixes from a...@amd, main thing is turning off the use of the hw i2c engine by default again, it was causing problems for some people, we now have a module option. Lots of misc radeon fixes from Alex also, along with RV7xx HDMI audio enabling fixes. No GPU reset or placement patches. Hopefully this doesn't contain either an April Fools joke or an Easter Egg. The following changes since commit 220bf991b0366cc50a94feede3d7341fa5710ee4: Linus Torvalds (1): Linux 2.6.34-rc2 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (36): drm/radeon: add new RS880 pci id drm/radeon/kms/atom: spread spectrum fix drm/radeon/kms: use lcd pll limits when available drm/radeon/kms: further spread spectrum fixes drm/radeon/kms: fix pal tv-out support on legacy IGP chips drm/radeon/kms: fix for hw i2c drm/radeon/kms: fix i2c prescale calc on older radeons drm/radeon/kms/r1xx: enable hw i2c drm/radeon/kms/rs4xx: make sure crtcs are enabled when setting timing drm/radeon/r600: add missing license and comments to r600_blit_shaders.c drm/radeon/kms: expose thermal/fan i2c buses drm/radeon/kms/pm: fix segfault in clock code drm/radeon/kms: gfx init fixes for r6xx/r7xx drm/radeon/kms/pm: fix typo in power table parsing drm/radeon/kms: init rdev-num_crtc at asic init drm/radeon/kms: display watermark fixes drm/radeon/kms: never treat rs4xx as AGP drm/radeon/kms: fix display bandwidth setup on rs4xx drm/radeon/kms: remove lvds quirks drm/radeon/kms/atom: make sure tables are valid (v2) drm/radeon/r600: remove some regs are not safe regs for command buffers drm/radeon/kms: fix some typos in r6xx/r7xx hpd setup drm/radeon/r6xx/r7xx: CS parser fixes drm/radeon/kms: bump the version for r6xx/r7xx const buffer support drm/radeon: bump the UMS driver version for r6xx/r7xx const buffer support drm/radeon/r6xx/r7xx: further safe reg clean up drm/radeon/kms: fix macbookpro connector quirk drm/radeon/kms/atom: minor fixes to transmitter setup drm/radeon/kms/dp: remove extraneous training complete call drm/radeon/kms: minor fixes for eDP with LCD* device tags (v2) drm/radeon/kms/dp: disable training pattern on the sink at the end of link training drm/radeon/kms: display watermark updates (v2) drm/radeon/kms: disable MSI on IGP chips drm/radeon/kms: use new pre/post_xfer i2c bit algo hooks drm/radeon/kms: add hw_i2c module option drm/radeon/kms/evergreen: get DP working Ben Skeggs (5): drm/nouveau: add option to allow override of dcb connector table types drm/nouveau: Gigabyte NX85T connector table lies, it has DVI-I not HDMI drm/nv50: fix connector table parsing for some cards drm/nouveau: add module option to disable TV detection drm/edid: allow certain bogus edids to hit a fixup path rather than fail Chris Wilson (1): drm: Return ENODEV if the inode mapping changes Daniel Vetter (5): drm/radeon: create radeon_asic.c drm/radeon: move asic structs to radeon_asic.c drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg drm/radeon: include radeon_asic.h in the asic specific files drm/radeon: collect r100 asic related declarations in radeon_asic.h Dave Airlie (8): drm/ttm: use drm calloc large and free large Merge remote branch 'nouveau/for-airlied' into drm-linus Merge branch 'radeon-for-airlied' of ../linux-2.6 into drm-linus drm/radeon/kms: don't print error on -ERESTARTSYS. Merge branch 'v2.6.34-rc2' into drm-linus drm/radeon/kms: add sanity check to wptr. drm/radeon/kms: rs400/480 should set common registers. drm/radeon/kms: enable ACPI powermanagement mode on radeon gpus. Francisco Jerez (2): drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay. drm/nouveau: Never evict VRAM buffers to system. Jerome Glisse (2): drm/radeon/kms: catch atombios infinite loop and break out of it drm/radeon/kms: avoid possible oops (call gart_fini before gart_disable) Maarten Maathuis (2): drm/nouveau: print a message very early during suspend drm/nv50: add a memory barrier to pushbuf submission Marcin Kościelnicki (4): drm/nv50: Remove redundant/incorrect ctxvals initialisation. drm/nouveau: Fix fbcon corruption with font width not divisible by 8 drm/nv50: Make ctxprog wait until interrupt handler is done. drm/nv50: Improve PGRAPH interrupt handling. Michel Dänzer (1): drm/radeon/kms: Only restrict BO to visible VRAM size when pinning to VRAM. Pauli Nieminen (1): drm/radeon/kms: Fix NULL pointer dereference if memory allocation failed. Rafał Miłecki (8): drm
Re: [git pull] drm fixes
2010/4/1 Rafał Miłecki zaj...@gmail.com: W dniu 30 marca 2010 09:07 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of the tree at this point, Ping? Are you waiting for Jerome or something? Please do not stop pulling whole stuff because Jerome is preparing some patch for last moment. I believe I'll be much better to pull most stuff ASAP to let ppl test it, and later eventually ask Linus to get some one-two additional small patches. Rebasing out Jerome's patches and reverifying stuff works isn't something that takes 5 minutes. Since the rebase pretty much negates all the testing I'd done. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
2010/3/30 Michel Dänzer mic...@daenzer.net: On Tue, 2010-03-30 at 05:34 +0100, Dave Airlie wrote: Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), [...] While I was able to work around the lockups by making the AGP driver never unbind a GTT entry, I think it's rather a radeon issue - how is the AGP driver supposed to know when it's safe to unbind an entry? This issue has been a problem with AGP before, the Intel AGP docs claim you should always use scratch pages on AGP, and never complete remove bound entries. I've no idea why this is, as you'd expect AGP cards to only generate cycles to entries they've been asked to. There may be some memory controller prefetching going on that could lead to prefetching into an unbound AGP page and the resulting machine check that may cause I suppose. We need to track this separately anyways and fix it for 2.6.35 hopefully, at least we have a patch that can handle it. That change had lots of other issues anyway, thanks for reverting it. [...] and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. Unfortunately, that's not true in all cases. The change itself mentions that the new reset code is unreliable for R3xx generation GPUs, and indeed with my RV350 it now turns my box into a brick immediately on a GPU lockup most of the time whereas previously it was usually able to recover at least in some cases, e.g. falling back to PCI mode after trying to use a non-working AGP transfer mode. Okay so it makes it worse, hopefully Jerome can track it down, or else we can lock down the gpu reset to only trying on the r600s where it definitely makes life a lot better for everyone. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of the tree at this point, but I realised I was falling back to the old ways, of putting things with badness in, even if they helped a few people. Jerome, GPU reset will have to wait until 2.6.35 now. Dave. Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), adds some further fixes from Alex for radeon. Also in case you are wondering why this has a v2.6.34-rc2 merge in the middle of it, one of the radeon changes needed an i2c change before I could test it. original pull text: Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. This also finally fixes HDMI audio on rv7xx cards. The following changes since commit 220bf991b0366cc50a94feede3d7341fa5710ee4: Linus Torvalds (1): Linux 2.6.34-rc2 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (32): drm/radeon: add new RS880 pci id drm/radeon/kms/atom: spread spectrum fix drm/radeon/kms: use lcd pll limits when available drm/radeon/kms: further spread spectrum fixes drm/radeon/kms: fix pal tv-out support on legacy IGP chips drm/radeon/kms: fix for hw i2c drm/radeon/kms: fix i2c prescale calc on older radeons drm/radeon/kms/r1xx: enable hw i2c drm/radeon/kms/rs4xx: make sure crtcs are enabled when setting timing drm/radeon/r600: add missing license and comments to r600_blit_shaders.c drm/radeon/kms: expose thermal/fan i2c buses drm/radeon/kms/pm: fix segfault in clock code drm/radeon/kms: gfx init fixes for r6xx/r7xx drm/radeon/kms/pm: fix typo in power table parsing drm/radeon/kms: init rdev-num_crtc at asic init drm/radeon/kms: display watermark fixes drm/radeon/kms: never treat rs4xx as AGP drm/radeon/kms: fix display bandwidth setup on rs4xx drm/radeon/kms: remove lvds quirks drm/radeon/kms/atom: make sure tables are valid (v2) drm/radeon/kms: use new pre/post_xfer i2c bit algo hooks drm/radeon/kms: add hw_i2c module option drm/radeon/r600: remove some regs are not safe regs for command buffers drm/radeon/kms: fix some typos in r6xx/r7xx hpd setup drm/radeon/r6xx/r7xx: CS parser fixes drm/radeon/kms: bump the version for r6xx/r7xx const buffer support drm/radeon: bump the UMS driver version for r6xx/r7xx const buffer support drm/radeon/r6xx/r7xx: further safe reg clean up drm/radeon/kms: fix macbookpro connector quirk drm/radeon/kms/atom: minor fixes to transmitter setup drm/radeon/kms/dp: remove extraneous training complete call drm/radeon/kms: minor fixes for eDP with LCD* device tags (v2) Ben Skeggs (5): drm/nouveau: add option to allow override of dcb connector table types drm/nouveau: Gigabyte NX85T connector table lies, it has DVI-I not HDMI drm/nv50: fix connector table parsing for some cards drm/nouveau: add module option to disable TV detection drm/edid: allow certain bogus edids to hit a fixup path rather than fail Chris Wilson (1): drm: Return ENODEV if the inode mapping changes Daniel Vetter (5): drm/radeon: create radeon_asic.c drm/radeon: move asic structs to radeon_asic.c drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg drm/radeon: include radeon_asic.h in the asic specific files drm/radeon: collect r100 asic related declarations in radeon_asic.h Dave Airlie (8): drm/ttm: use drm calloc large and free large Merge remote branch 'nouveau/for-airlied' into drm-linus Merge branch 'radeon-for-airlied' of ../linux-2.6 into drm-linus drm/radeon/bo: add some fallback placements for VRAM only objects. drm/radeon/kms: don't print error on -ERESTARTSYS. Merge branch 'v2.6.34-rc2' into HEAD Merge branch 'drm-radeon-fixes' into HEAD Revert drm/radeon/bo: add some fallback placements for VRAM only objects. Francisco Jerez (2): drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay. drm/nouveau: Never evict VRAM buffers to system. Jerome Glisse (6): drm/radeon/kms: catch atombios infinite loop and break out of it drm/radeon/kms: fence cleanup + more
[PATCH 1/3] drm/radeon/kms: add sanity check to wptr.
From: Dave Airlie airl...@redhat.com If we resume in a bad way, we'll get 0x in wptr, and then oops with no console. This just adds a sanity check so that we can avoid the oops and hopefully get more details out of people's systems. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/r100.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 9d01ad9..817821f 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -741,6 +741,8 @@ int r100_cp_init(struct radeon_device *rdev, unsigned ring_size) udelay(10); rdev-cp.rptr = RREG32(RADEON_CP_RB_RPTR); rdev-cp.wptr = RREG32(RADEON_CP_RB_WPTR); + /* protect against crazy HW on resume */ + rdev-cp.wptr = rdev-cp.ptr_mask; /* Set cp mode to bus mastering enable cp*/ WREG32(RADEON_CP_CSQ_MODE, REG_SET(RADEON_INDIRECT2_START, indirect2_start) | -- 1.6.6 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] drm/radeon/kms: enable ACPI powermanagement mode on radeon gpus.
From: Dave Airlie airl...@redhat.com
Some GPUs have an APM/ACPI PM mode selection switch and some BIOSes
set this to APM. We really want this in ACPI mode for Linux.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c |7 +++
drivers/gpu/drm/radeon/radeon_reg.h |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 817821f..ed58bd3 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1806,6 +1806,7 @@ void r100_set_common_regs(struct radeon_device *rdev)
{
struct drm_device *dev = rdev-ddev;
bool force_dac2 = false;
+ u32 tmp;
/* set these so they don't interfere with anything */
WREG32(RADEON_OV0_SCALE_CNTL, 0);
@@ -1877,6 +1878,12 @@ void r100_set_common_regs(struct radeon_device *rdev)
WREG32(RADEON_DISP_HW_DEBUG, disp_hw_debug);
WREG32(RADEON_DAC_CNTL2, dac2_cntl);
}
+
+ /* switch PM block to ACPI mode */
+ tmp = RREG32_PLL(RADEON_PLL_PWRMGT_CNTL);
+ tmp = ~RADEON_PM_MODE_SEL;
+ WREG32_PLL(RADEON_PLL_PWRMGT_CNTL, tmp);
+
}
/*
diff --git a/drivers/gpu/drm/radeon/radeon_reg.h
b/drivers/gpu/drm/radeon/radeon_reg.h
index 5c0dc08..eabbc9c 100644
--- a/drivers/gpu/drm/radeon/radeon_reg.h
+++ b/drivers/gpu/drm/radeon/radeon_reg.h
@@ -346,6 +346,7 @@
# define RADEON_TVPLL_PWRMGT_OFF (1 30)
# define RADEON_TVCLK_TURNOFF (1 31)
#define RADEON_PLL_PWRMGT_CNTL 0x0015 /* PLL */
+# define RADEON_PM_MODE_SEL (1 13)
# define RADEON_TCL_BYPASS_DISABLE(1 20)
#define RADEON_CLR_CMP_CLR_3D 0x1a24
#define RADEON_CLR_CMP_CLR_DST 0x15c8
--
1.6.6
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] drm/radeon/kms: rs400/480 should set common registers.
From: Dave Airlie airl...@redhat.com
These GPUs should be setting these registers up also.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/rs400.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index d7f554f..fca2294 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -388,6 +388,8 @@ static int rs400_startup(struct radeon_device *rdev)
{
int r;
+ r100_set_common_regs(rdev);
+
rs400_mc_program(rdev);
/* Resume clock */
r300_clock_startup(rdev);
--
1.6.6
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
[re-pull request] Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), adds some further fixes from Alex for radeon. Also in case you are wondering why this has a v2.6.34-rc2 merge in the middle of it, one of the radeon changes needed an i2c change before I could test it. original pull text: Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. This also finally fixes HDMI audio on rv7xx cards. The following changes since commit 220bf991b0366cc50a94feede3d7341fa5710ee4: Linus Torvalds (1): Linux 2.6.34-rc2 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (32): drm/radeon: add new RS880 pci id drm/radeon/kms/atom: spread spectrum fix drm/radeon/kms: use lcd pll limits when available drm/radeon/kms: further spread spectrum fixes drm/radeon/kms: fix pal tv-out support on legacy IGP chips drm/radeon/kms: fix for hw i2c drm/radeon/kms: fix i2c prescale calc on older radeons drm/radeon/kms/r1xx: enable hw i2c drm/radeon/kms/rs4xx: make sure crtcs are enabled when setting timing drm/radeon/r600: add missing license and comments to r600_blit_shaders.c drm/radeon/kms: expose thermal/fan i2c buses drm/radeon/kms/pm: fix segfault in clock code drm/radeon/kms: gfx init fixes for r6xx/r7xx drm/radeon/kms/pm: fix typo in power table parsing drm/radeon/kms: init rdev-num_crtc at asic init drm/radeon/kms: display watermark fixes drm/radeon/kms: never treat rs4xx as AGP drm/radeon/kms: fix display bandwidth setup on rs4xx drm/radeon/kms: remove lvds quirks drm/radeon/kms/atom: make sure tables are valid (v2) drm/radeon/kms: use new pre/post_xfer i2c bit algo hooks drm/radeon/kms: add hw_i2c module option drm/radeon/r600: remove some regs are not safe regs for command buffers drm/radeon/kms: fix some typos in r6xx/r7xx hpd setup drm/radeon/r6xx/r7xx: CS parser fixes drm/radeon/kms: bump the version for r6xx/r7xx const buffer support drm/radeon: bump the UMS driver version for r6xx/r7xx const buffer support drm/radeon/r6xx/r7xx: further safe reg clean up drm/radeon/kms: fix macbookpro connector quirk drm/radeon/kms/atom: minor fixes to transmitter setup drm/radeon/kms/dp: remove extraneous training complete call drm/radeon/kms: minor fixes for eDP with LCD* device tags (v2) Ben Skeggs (5): drm/nouveau: add option to allow override of dcb connector table types drm/nouveau: Gigabyte NX85T connector table lies, it has DVI-I not HDMI drm/nv50: fix connector table parsing for some cards drm/nouveau: add module option to disable TV detection drm/edid: allow certain bogus edids to hit a fixup path rather than fail Chris Wilson (1): drm: Return ENODEV if the inode mapping changes Daniel Vetter (5): drm/radeon: create radeon_asic.c drm/radeon: move asic structs to radeon_asic.c drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg drm/radeon: include radeon_asic.h in the asic specific files drm/radeon: collect r100 asic related declarations in radeon_asic.h Dave Airlie (8): drm/ttm: use drm calloc large and free large Merge remote branch 'nouveau/for-airlied' into drm-linus Merge branch 'radeon-for-airlied' of ../linux-2.6 into drm-linus drm/radeon/bo: add some fallback placements for VRAM only objects. drm/radeon/kms: don't print error on -ERESTARTSYS. Merge branch 'v2.6.34-rc2' into HEAD Merge branch 'drm-radeon-fixes' into HEAD Revert drm/radeon/bo: add some fallback placements for VRAM only objects. Francisco Jerez (2): drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay. drm/nouveau: Never evict VRAM buffers to system. Jerome Glisse (6): drm/radeon/kms: catch atombios infinite loop and break out of it drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4 drm/radeon/kms: rename gpu_reset to asic_reset drm/radeon/kms: simplify improve GPU reset V2 drm/radeon/kms: fix typo in r520 asic functions drm/radeon/kms: avoid possible oops (call gart_fini before gart_disable) Maarten Maathuis (2): drm/nouveau: print a message very early during suspend drm/nv50: add a memory barrier to pushbuf submission Marcin
drm/kms/fb: clean up fbdev integration + add fbcon polling/hotplug
This series of 6 patches attempts to clean up the KMS fbdev helper layer, and add support for two features I'd like to see for some use cases. The first 3 patches are mainly cleanup and moving code around, the main idea being to better abstract the fbdev helper layer from the main kms core. This is done by trying to make fbdev into a kms user not reliant on any information stored in kms especially for it, it also makes the fbdev layer own the initial crtc/mode programming. The second set of 3 patches add the features: a) default to making 1024x768 framebuffer if we detect nothing plugged in b) if nothing is plugged in and the driver wants it, poll ever 5 seconds for something, until you find something plugged in, stop polling then. c) fbcon hotplug, if you have hot plug detect on irqs and you are at the console, it will redetect when you hotplug something. It also deals properly when X or something else is running and delays reprobing until next set_par. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/6] drm/kms/fb: separate fbdev connector list from core drm connectors
From: Dave Airlie airl...@redhat.com
This breaks the connection between the core drm connector list
and the fbdev connector usage, and allows them to become disjoint
in the future. It also removes the untype void* that was in the
connector struct to support this.
All connectors are added to the fbdev now but this could be
changed in the future.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c |1 -
drivers/gpu/drm/drm_fb_helper.c| 196 +++-
drivers/gpu/drm/i915/intel_fb.c|1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c|2 +
drivers/gpu/drm/radeon/radeon_connectors.c | 50 ++--
drivers/gpu/drm/radeon/radeon_fb.c |5 +-
include/drm/drm_crtc.h |1 -
include/drm/drm_crtc_helper.h |5 +-
include/drm/drm_fb_helper.h|6 +-
9 files changed, 126 insertions(+), 141 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6a472d5..e8cd683 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -493,7 +493,6 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, connector-user_modes, head)
drm_mode_remove(connector, mode);
- kfree(connector-fb_helper_private);
mutex_lock(dev-mode_config.mutex);
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3d6f417..a1724af 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,15 +41,33 @@ MODULE_LICENSE(GPL and additional rights);
static LIST_HEAD(kernel_fb_helper_list);
-int drm_fb_helper_add_connector(struct drm_connector *connector)
+/* simple single crtc case helper function */
+int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
{
- connector-fb_helper_private = kzalloc(sizeof(struct
drm_fb_helper_connector), GFP_KERNEL);
- if (!connector-fb_helper_private)
- return -ENOMEM;
+ struct drm_device *dev = fb_helper-dev;
+ struct drm_connector *connector;
+ int i;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ struct drm_fb_helper_connector *fb_helper_connector;
+
+ fb_helper_connector = kzalloc(sizeof(struct
drm_fb_helper_connector), GFP_KERNEL);
+ if (!fb_helper_connector)
+ goto fail;
+ fb_helper_connector-connector = connector;
+ fb_helper-connector_info[fb_helper-connector_count++] =
fb_helper_connector;
+ }
return 0;
+fail:
+ for (i = 0; i fb_helper-connector_count; i++) {
+ kfree(fb_helper-connector_info[i]);
+ fb_helper-connector_info[i] = NULL;
+ }
+ fb_helper-connector_count = 0;
+ return -ENOMEM;
}
-EXPORT_SYMBOL(drm_fb_helper_add_connector);
+EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
/**
* drm_fb_helper_connector_parse_command_line - parse command line for
connector
@@ -64,7 +82,7 @@ EXPORT_SYMBOL(drm_fb_helper_add_connector);
*
* enable/enable Digital/disable bit at the end
*/
-static bool drm_fb_helper_connector_parse_command_line(struct drm_connector
*connector,
+static bool drm_fb_helper_connector_parse_command_line(struct
drm_fb_helper_connector *fb_helper_conn,
const char *mode_option)
{
const char *name;
@@ -74,13 +92,13 @@ static bool
drm_fb_helper_connector_parse_command_line(struct drm_connector *con
int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
int i;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
- struct drm_fb_helper_connector *fb_help_conn =
connector-fb_helper_private;
struct drm_fb_helper_cmdline_mode *cmdline_mode;
+ struct drm_connector *connector = fb_helper_conn-connector;
- if (!fb_help_conn)
+ if (!fb_helper_conn)
return false;
- cmdline_mode = fb_help_conn-cmdline_mode;
+ cmdline_mode = fb_helper_conn-cmdline_mode;
if (!mode_option)
mode_option = fb_mode_option;
@@ -203,18 +221,21 @@ done:
return true;
}
-int drm_fb_helper_parse_command_line(struct drm_device *dev)
+static int drm_fb_helper_parse_command_line(struct drm_fb_helper *fb_helper)
{
- struct drm_connector *connector;
+ struct drm_fb_helper_connector *fb_helper_conn;
+ int i;
- list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ for (i = 0; i fb_helper-connector_count; i++) {
char *option = NULL;
+ fb_helper_conn = fb_helper-connector_info[i];
+
/* do something on return - turn off connector maybe
[PATCH 2/6] drm/kms/fb: move to using fb helper crtc grouping instead of core crtc list
From: Dave Airlie airl...@redhat.com
This move to using the list of crtcs in the fb helper and cleans up the
whole picking code, now we store the crtc/connectors we want directly
into the modeset and we use the modeset directly to set the mode.
Fixes from James Simmons and Ben Skeggs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c |4 -
drivers/gpu/drm/drm_fb_helper.c | 329 +--
drivers/gpu/drm/i915/i915_drv.h |5 +-
drivers/gpu/drm/i915/intel_fb.c | 93 -
drivers/gpu/drm/nouveau/nouveau_drv.h |4 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 121 ++--
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +-
drivers/gpu/drm/nouveau/nv04_fbcon.c| 16 +-
drivers/gpu/drm/nouveau/nv50_fbcon.c| 16 +-
drivers/gpu/drm/radeon/radeon_fb.c | 240 --
drivers/gpu/drm/radeon/radeon_mode.h|4 +-
include/drm/drm_crtc.h |5 -
include/drm/drm_fb_helper.h | 21 ++-
13 files changed, 411 insertions(+), 449 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9d23f54..b142ac2 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -625,10 +625,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
ret = -EINVAL;
goto fail;
}
- /* TODO are these needed? */
- set-crtc-desired_x = set-x;
- set-crtc-desired_y = set-y;
- set-crtc-desired_mode = set-mode;
}
drm_helper_disable_unused_functions(dev);
} else if (fb_changed) {
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d6f9f94..3d6f417 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -290,6 +290,7 @@ static void drm_fb_helper_on(struct fb_info *info)
struct drm_fb_helper *fb_helper = info-par;
struct drm_device *dev = fb_helper-dev;
struct drm_crtc *crtc;
+ struct drm_crtc_helper_funcs *crtc_funcs;
struct drm_encoder *encoder;
int i;
@@ -297,33 +298,28 @@ static void drm_fb_helper_on(struct fb_info *info)
* For each CRTC in this fb, turn the crtc on then,
* find all associated encoders and turn them on.
*/
+ mutex_lock(dev-mode_config.mutex);
for (i = 0; i fb_helper-crtc_count; i++) {
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
- struct drm_crtc_helper_funcs *crtc_funcs =
- crtc-helper_private;
+ crtc = fb_helper-crtc_info[i].mode_set.crtc;
+ crtc_funcs = crtc-helper_private;
- /* Only mess with CRTCs in this fb */
- if (crtc-base.id != fb_helper-crtc_info[i].crtc_id ||
- !crtc-enabled)
- continue;
+ if (!crtc-enabled)
+ continue;
+
+ crtc_funcs-dpms(crtc, DRM_MODE_DPMS_ON);
- mutex_lock(dev-mode_config.mutex);
- crtc_funcs-dpms(crtc, DRM_MODE_DPMS_ON);
- mutex_unlock(dev-mode_config.mutex);
- /* Found a CRTC on this fb, now find encoders */
- list_for_each_entry(encoder,
dev-mode_config.encoder_list, head) {
- if (encoder-crtc == crtc) {
- struct drm_encoder_helper_funcs
*encoder_funcs;
+ /* Found a CRTC on this fb, now find encoders */
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
head) {
+ if (encoder-crtc == crtc) {
+ struct drm_encoder_helper_funcs *encoder_funcs;
- encoder_funcs = encoder-helper_private;
- mutex_lock(dev-mode_config.mutex);
- encoder_funcs-dpms(encoder,
DRM_MODE_DPMS_ON);
- mutex_unlock(dev-mode_config.mutex);
- }
+ encoder_funcs = encoder-helper_private;
+ encoder_funcs-dpms(encoder, DRM_MODE_DPMS_ON);
}
}
}
+ mutex_unlock(dev-mode_config.mutex);
}
static void drm_fb_helper_off(struct fb_info *info, int dpms_mode)
@@ -331,6 +327,7 @@ static void drm_fb_helper_off(struct fb_info *info, int
dpms_mode)
struct drm_fb_helper *fb_helper = info-par;
struct drm_device *dev = fb_helper-dev;
struct drm_crtc *crtc;
+ struct
[PATCH 4/6] drm/kms/fb: provide a 1024x768 fbcon if no outputs found.
From: Dave Airlie airl...@redhat.com
If we get no outputs setup provide a 1024x768 fbcon, with
this + radeon hotplug stuff I can plug a monitor in after startup
and get to see stuff.
Last thing is to add some sort of timer for non-hpd outputs like
VGA etc.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a1724af..8192a56 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -819,7 +819,9 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
/* hmm everyone went away - assume VGA cable just fell out
and will come back later. */
- return 0;
+ DRM_ERROR(Cannot find any crtc or sizes - going 1024x768\n);
+ sizes.fb_width = sizes.surface_width = 1024;
+ sizes.fb_height = sizes.surface_height = 768;
}
/* push down into drivers */
--
1.6.5.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5/6] drm/kms/fb: add polling support for when nothing is connected.
From: Dave Airlie airl...@redhat.com
When we are running in a headless environment we have no idea what
output the user might plug in later, we only have hotplug detect
from the digital outputs. So if we detect no connected outputs at
initialisation, start a slow work operation to poll every 5 seconds
for an output.
this is only hooked up for radeon so far, on hw where we have full
hotplug detection there is no need for this.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig |1 +
drivers/gpu/drm/drm_fb_helper.c | 82 --
drivers/gpu/drm/radeon/radeon_fb.c | 14 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c |2 +-
drivers/gpu/drm/radeon/radeon_mode.h|2 +-
include/drm/drm_fb_helper.h | 12 -
6 files changed, 101 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 305c590..be5aa7d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -23,6 +23,7 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
+ select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8192a56..f879b3a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1306,9 +1306,14 @@ bool drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper)
/*
* we shouldn't end up with no modes here.
*/
- if (count == 0)
- printk(KERN_INFO No connectors reported connected with
modes\n);
-
+ if (count == 0) {
+ if (fb_helper-poll_enabled) {
+
delayed_slow_work_enqueue(fb_helper-output_poll_slow_work,
+ 5*HZ);
+ printk(KERN_INFO No connectors reported connected with
modes - started polling\n);
+ } else
+ printk(KERN_INFO No connectors reported connected with
modes\n);
+ }
drm_setup_crtcs(fb_helper);
return 0;
@@ -1316,15 +1321,80 @@ bool drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper)
EXPORT_SYMBOL(drm_fb_helper_initial_config);
bool drm_helper_fb_hotplug_event(struct drm_fb_helper *fb_helper,
-u32 max_width, u32 max_height)
+u32 max_width, u32 max_height, bool polled)
{
+ int count = 0;
+ int ret;
DRM_DEBUG_KMS(\n);
- drm_fb_helper_probe_connector_modes(fb_helper, max_width,
+ count = drm_fb_helper_probe_connector_modes(fb_helper, max_width,
max_height);
-
+ if (fb_helper-poll_enabled !polled) {
+ if (count) {
+
delayed_slow_work_cancel(fb_helper-output_poll_slow_work);
+ } else {
+ ret =
delayed_slow_work_enqueue(fb_helper-output_poll_slow_work, 5*HZ);
+ }
+ }
drm_setup_crtcs(fb_helper);
return true;
}
EXPORT_SYMBOL(drm_helper_fb_hotplug_event);
+
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_fb_helper *fb_helper = container_of(delayed_work, struct
drm_fb_helper, output_poll_slow_work);
+ struct drm_device *dev = fb_helper-dev;
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = true, changed = false;
+ int ret;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ old_status = connector-status;
+ status = connector-funcs-detect(connector);
+ if (old_status != status) {
+ changed = true;
+ /* something changed */
+ }
+ if (status == connector_status_connected) {
+ DRM_DEBUG(%s is connected - stop polling\n,
drm_get_connector_name(connector));
+ repoll = false;
+ }
+ }
+
+ if (repoll) {
+ ret = delayed_slow_work_enqueue(delayed_work, 5*HZ);
+ if (ret)
+ DRM_ERROR(delayed enqueue failed %d\n, ret);
+ }
+
+ if (changed) {
+ if (fb_helper-fb_poll_changed)
+ fb_helper-fb_poll_changed(fb_helper);
+ }
+}
+
+struct slow_work_ops output_poll_ops = {
+ .execute = output_poll_execute,
+};
+
+void drm_fb_helper_poll_init(struct drm_fb_helper *fb_helper)
+{
+ int ret;
+
+ ret = slow_work_register_user(THIS_MODULE);
+
+ delayed_slow_work_init(fb_helper-output_poll_slow_work,
output_poll_ops);
+ fb_helper-poll_enabled = true
[PATCH 6/6] drm/kms/fb: use slow work mechanism for normal hotplug also.
From: Dave Airlie airl...@redhat.com
a) slow work is always used now for any fbcon hotplug, as its not
a fast task and is more suited to being ran under slow work.
b) attempt to not do any fbdev changes when X is running as we'll
just mess it up. This hooks set_par to hopefully do the changes
once X hands control to fbdev.
This also adds the nouveau/intel hotplug support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c | 209 ++
drivers/gpu/drm/i915/i915_irq.c |1 +
drivers/gpu/drm/i915/intel_drv.h|2 +
drivers/gpu/drm/i915/intel_fb.c | 42 ---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 47 +---
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +
drivers/gpu/drm/nouveau/nv50_display.c |3 +
drivers/gpu/drm/radeon/radeon_fb.c | 74 +--
include/drm/drm_fb_helper.h | 47 ---
9 files changed, 243 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f879b3a..3757a25 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,8 @@ MODULE_LICENSE(GPL and additional rights);
static LIST_HEAD(kernel_fb_helper_list);
+static struct slow_work_ops output_status_change_ops;
+
/* simple single crtc case helper function */
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
{
@@ -418,54 +420,81 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
*helper)
kfree(helper-crtc_info);
}
-int drm_fb_helper_init_crtc_count(struct drm_device *dev,
- struct drm_fb_helper *helper,
- int crtc_count, int max_conn_count)
+int drm_fb_helper_init(struct drm_device *dev,
+ struct drm_fb_helper *fb_helper,
+ int crtc_count, int max_conn_count,
+ bool polled)
{
struct drm_crtc *crtc;
int ret = 0;
int i;
- INIT_LIST_HEAD(helper-kernel_fb_list);
- helper-dev = dev;
- helper-crtc_info = kcalloc(crtc_count, sizeof(struct
drm_fb_helper_crtc), GFP_KERNEL);
- if (!helper-crtc_info)
+ fb_helper-dev = dev;
+ fb_helper-poll_enabled = polled;
+
+ slow_work_register_user(THIS_MODULE);
+ delayed_slow_work_init(fb_helper-output_status_change_slow_work,
+ output_status_change_ops);
+
+ INIT_LIST_HEAD(fb_helper-kernel_fb_list);
+
+ fb_helper-crtc_info = kcalloc(crtc_count, sizeof(struct
drm_fb_helper_crtc), GFP_KERNEL);
+ if (!fb_helper-crtc_info)
return -ENOMEM;
- helper-crtc_count = crtc_count;
- helper-connector_info = kcalloc(dev-mode_config.num_connector,
sizeof(struct drm_fb_helper_connector *), GFP_KERNEL);
- if (!helper-connector_info) {
- kfree(helper-crtc_info);
+ fb_helper-crtc_count = crtc_count;
+ fb_helper-connector_info = kcalloc(dev-mode_config.num_connector,
sizeof(struct drm_fb_helper_connector *), GFP_KERNEL);
+ if (!fb_helper-connector_info) {
+ kfree(fb_helper-crtc_info);
return -ENOMEM;
}
- helper-connector_count = 0;
+ fb_helper-connector_count = 0;
for (i = 0; i crtc_count; i++) {
- helper-crtc_info[i].mode_set.connectors =
+ fb_helper-crtc_info[i].mode_set.connectors =
kcalloc(max_conn_count,
sizeof(struct drm_connector *),
GFP_KERNEL);
- if (!helper-crtc_info[i].mode_set.connectors) {
+ if (!fb_helper-crtc_info[i].mode_set.connectors) {
ret = -ENOMEM;
goto out_free;
}
- helper-crtc_info[i].mode_set.num_connectors = 0;
+ fb_helper-crtc_info[i].mode_set.num_connectors = 0;
}
i = 0;
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
- helper-crtc_info[i].crtc_id = crtc-base.id;
- helper-crtc_info[i].mode_set.crtc = crtc;
+ fb_helper-crtc_info[i].crtc_id = crtc-base.id;
+ fb_helper-crtc_info[i].mode_set.crtc = crtc;
i++;
}
- helper-conn_limit = max_conn_count;
+ fb_helper-conn_limit = max_conn_count;
return 0;
out_free:
- drm_fb_helper_crtc_free(helper);
+ drm_fb_helper_crtc_free(fb_helper);
return -ENOMEM;
}
-EXPORT_SYMBOL(drm_fb_helper_init_crtc_count);
+EXPORT_SYMBOL(drm_fb_helper_init);
+
+void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
+{
+ if (!list_empty(fb_helper-kernel_fb_list)) {
+ list_del(fb_helper-kernel_fb_list);
+ if (list_empty(kernel_fb_helper_list)) {
+ printk(KERN_INFO
Re: [Intel-gfx] [PATCH 2/7] drm: delay vblank cleanup until after driver unload
2010/3/29 Kristian Høgsberg k...@bitplanet.net: On Fri, Mar 26, 2010 at 7:07 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload paths, so don't clean up the vblank related structures until after driver unload. I haven't tested this specific patch on a recent DRM, but I made the same patch a while ago, and it fixed module unload for me. I sent it to the list and it fell through the cracks, because vblank is hard or something. Reviewed-by: Kristian Høgsberg k...@bitplanet.net I didn't apply it because from what I can see non-kms drivers need to free the vbl stuff on lastclose not unload. I'm nearly sure I said that at the time to. This patch seems to suffer from the same problem from what I can see. And really someone should already have cleaned up the insanity that is vbl struct allocations, vblank might not be hard, but it sure has some ugly. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/7] drm: delay vblank cleanup until after driver unload
2010/3/29 Dave Airlie airl...@gmail.com: 2010/3/29 Kristian Høgsberg k...@bitplanet.net: On Fri, Mar 26, 2010 at 7:07 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload paths, so don't clean up the vblank related structures until after driver unload. I haven't tested this specific patch on a recent DRM, but I made the same patch a while ago, and it fixed module unload for me. I sent it to the list and it fell through the cracks, because vblank is hard or something. Reviewed-by: Kristian Høgsberg k...@bitplanet.net I didn't apply it because from what I can see non-kms drivers need to free the vbl stuff on lastclose not unload. I'm nearly sure I said that at the time to. This patch seems to suffer from the same problem from what I can see. And really someone should already have cleaned up the insanity that is vbl struct allocations, vblank might not be hard, but it sure has some ugly. Oops on reading it makes more sense, I thought we were moving it from lastclose, my bad, too little sleep. Okay I'll push it in next push. Dave. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
On Thu, Mar 25, 2010 at 4:52 PM, Pekka Enberg penb...@cs.helsinki.fi wrote: Hi Dave, 2010/3/25 Dave Airlie airl...@linux.ie: Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. This also finally fixes HDMI audio on rv7xx cards. Are there any i915 fixes pending? I tried 2.6.34-rc2 few days ago and all I got was a blank screen at start up. The driver is pretty busted for 2.6.33 also, I'm getting random screen corruption and the occasional blank screen (which is fixed by suspend/resume). I'm unfortunately busy with working on something else so I don't have time right now to debug the thing. Just wanted to know if you're aware of the quality problems with i915 and if there are any fixes pending. I leave i915 up to Eric after -rc1, we found it hard to sync our schedules before, I'm sure he has some stuff in his tree. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
2010/3/25 Michel Dänzer mic...@daenzer.net: On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. Care to try in pci mode? see if helps, it might be just straining AGP a bit more, maybe try 1x as well if you aren't already in it. I don't know why that is - maybe something doesn't properly deal with BOs getting placed differently in some cases now - but anyway I suspect the implications of this change haven't been fully thought through: The log message sounds as though the change was mainly written with radeon_bo_create() / radeon_bo_list_validate() in mind, but radeon_ttm_placement_from_domain() is also called from other places: * radeon_bo_pin(): The change could lead to a BO being pinned to GTT instead of VRAM, which would probably be bad. * radeon_evict_flags(): The change might have undesirable consequences here as well, not sure. The first might be bad, but the second should be okay, I'll take a closer look in the morning. I don't think the way we currently use the same arrays for normal and busy placement makes a lot of sense, but we probably need a better mechanism to specify which placements are desirable / acceptable in each case. Well its not really a huge matrix of choices, I'm guessing we need more info from userspace, or use the info better. Though in theory everything should work in GTT or VRAM equally well just slower. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. This also finally fixes HDMI audio on rv7xx cards. The following changes since commit 220bf991b0366cc50a94feede3d7341fa5710ee4: Linus Torvalds (1): Linux 2.6.34-rc2 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (24): drm/radeon: add new RS880 pci id drm/radeon/kms/atom: spread spectrum fix drm/radeon/kms: use lcd pll limits when available drm/radeon/kms: further spread spectrum fixes drm/radeon/kms: fix pal tv-out support on legacy IGP chips drm/radeon/kms: fix for hw i2c drm/radeon/kms: fix i2c prescale calc on older radeons drm/radeon/kms/r1xx: enable hw i2c drm/radeon/kms/rs4xx: make sure crtcs are enabled when setting timing drm/radeon/r600: add missing license and comments to r600_blit_shaders.c drm/radeon/kms: expose thermal/fan i2c buses drm/radeon/kms/pm: fix segfault in clock code drm/radeon/kms: gfx init fixes for r6xx/r7xx drm/radeon/kms/pm: fix typo in power table parsing drm/radeon/kms: init rdev-num_crtc at asic init drm/radeon/kms: display watermark fixes drm/radeon/kms: never treat rs4xx as AGP drm/radeon/kms: fix display bandwidth setup on rs4xx drm/radeon/kms: remove lvds quirks drm/radeon/kms/atom: make sure tables are valid (v2) drm/radeon/kms: use new pre/post_xfer i2c bit algo hooks drm/radeon/kms: add hw_i2c module option drm/radeon/r600: remove some regs are not safe regs for command buffers drm/radeon/kms: fix some typos in r6xx/r7xx hpd setup Ben Skeggs (5): drm/nouveau: add option to allow override of dcb connector table types drm/nouveau: Gigabyte NX85T connector table lies, it has DVI-I not HDMI drm/nv50: fix connector table parsing for some cards drm/nouveau: add module option to disable TV detection drm/edid: allow certain bogus edids to hit a fixup path rather than fail Chris Wilson (1): drm: Return ENODEV if the inode mapping changes Daniel Vetter (5): drm/radeon: create radeon_asic.c drm/radeon: move asic structs to radeon_asic.c drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg drm/radeon: include radeon_asic.h in the asic specific files drm/radeon: collect r100 asic related declarations in radeon_asic.h Dave Airlie (7): drm/ttm: use drm calloc large and free large Merge remote branch 'nouveau/for-airlied' into drm-linus Merge branch 'radeon-for-airlied' of ../linux-2.6 into drm-linus drm/radeon/bo: add some fallback placements for VRAM only objects. drm/radeon/kms: don't print error on -ERESTARTSYS. Merge branch 'v2.6.34-rc2' into HEAD Merge branch 'drm-radeon-fixes' into HEAD Francisco Jerez (2): drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay. drm/nouveau: Never evict VRAM buffers to system. Jerome Glisse (6): drm/radeon/kms: catch atombios infinite loop and break out of it drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4 drm/radeon/kms: rename gpu_reset to asic_reset drm/radeon/kms: simplify improve GPU reset V2 drm/radeon/kms: fix typo in r520 asic functions drm/radeon/kms: avoid possible oops (call gart_fini before gart_disable) Maarten Maathuis (2): drm/nouveau: print a message very early during suspend drm/nv50: add a memory barrier to pushbuf submission Marcin Kościelnicki (4): drm/nv50: Remove redundant/incorrect ctxvals initialisation. drm/nouveau: Fix fbcon corruption with font width not divisible by 8 drm/nv50: Make ctxprog wait until interrupt handler is done. drm/nv50: Improve PGRAPH interrupt handling. Pauli Nieminen (1): drm/radeon/kms: Fix NULL pointer dereference if memory allocation failed. Rafał Miłecki (8): drm/radeon/kms: clean HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drm/radeon/kms: switch to condition waiting for reclocking drm/radeon/kms: prepare for more reclocking operations Randy Dunlap (1): drm/vmwgfx: depends on FB Robert P. J. Day (1): drm: kobject_init/kobject_add - kobject_init_and_add. Zhao Yakui (1): drm: remove the EDID blob
Re: Resume problem with radeon+KMS (2.6.34-rc2 and before)
2010/3/22 Rafael J. Wysocki r...@sisk.pl: Hi, Some time ago I reported a problem with resuming from suspend to RAM on HP nx6325 with radeon+KMS. Can you post the X.org log file? if you are really using 6.12.4 and not a backport then the userspace driver has no KMS support and it is trashing the system. Dave. The problem was that the first resume always failed if the suspend was started from under X. Moreover, the resume went correctly until the last switch from the framebuffer console (which was now controlled by the radeon driver as well) to X that made the box hang hard. However, if the first resume was started from the (radeon-controlled) framebuffer console, the subsequent resume succeeded and all of the next attempts to suspend/resume succeeded, _regardless_ of the way the suspend was started. At that time Dave thought it might be a problem with the nx6325's graphics adapter that apparently was a crappy one, but today I found that _exactly_ the same behavior was observable on Acer Ferrari One, which was quite different, hardware-wise, from the old HP box. For this reason I think the problem is related to the driver itself rather than to the hardware or firmware. The problem is reproducible on both machines with the latest git kernel and the user space radeon_drv.so from openSUSE 11.2 (it says module version = 6.12.4 in the X log). The kernel and user space are 64-bit on both machines. [For completness, the Acer box suspends and resumes correctly with radeon.modeset=0 and s2ram -f -p -m.] Should I try a newer user space X driver? Or may the problem be related to the 64-bitness somehow? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Resume problem with radeon+KMS (2.6.34-rc2 and before)
On Mon, Mar 22, 2010 at 9:07 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Sunday 21 March 2010, Dave Airlie wrote: 2010/3/22 Rafael J. Wysocki r...@sisk.pl: Hi, Some time ago I reported a problem with resuming from suspend to RAM on HP nx6325 with radeon+KMS. Can you post the X.org log file? if you are really using 6.12.4 and not a backport then the userspace driver has no KMS support and it is trashing the system. Appended below. So your userspace is incompatible with KMS, so I'd suggest trying to get 6.12.191 or -ati git master, Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek sedat.di...@googlemail.com wrote: Hi Marek - you are nominated for the next DRIgeller (Uri Geller) :-) concerning my problems r300g dri/st with mesa master GIT: THE BAD: commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19 Author: Dave Airlie airl...@redhat.com r300g: rebuild screen/winsys interface Please retest with master, I've just pushed some fixes for piglit regressions hopefully will fix other issues. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|2 ++
drivers/gpu/drm/radeon/radeon_object.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 72ed251..69585bb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -238,7 +238,9 @@ struct radeon_bo {
struct list_headlist;
/* Protected by tbo.reserved */
u32 placements[3];
+ u32 busy_placements[3];
struct ttm_placementplacement;
+ struct ttm_placementbusy_placement;
struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
unsignedpin_count;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index fc9d00a..3580c75 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -65,15 +65,19 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object
*bo)
void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
{
- u32 c = 0;
+ u32 c = 0, b = 0;
rbo-placement.fpfn = 0;
rbo-placement.lpfn = 0;
rbo-placement.placement = rbo-placements;
- rbo-placement.busy_placement = rbo-placements;
+ rbo-placement.busy_placement = rbo-busy_placements;
if (domain RADEON_GEM_DOMAIN_VRAM)
rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_VRAM;
+ /* add busy placement to TTM if VRAM is only option */
+ if (domain == RADEON_GEM_DOMAIN_VRAM) {
+ rbo-busy_placements[b++] = TTM_PL_MASK_CACHING |
TTM_PL_FLAG_TT;
+ }
if (domain RADEON_GEM_DOMAIN_GTT)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
if (domain RADEON_GEM_DOMAIN_CPU)
@@ -81,7 +85,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo,
u32 domain)
if (!c)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo-placement.num_placement = c;
- rbo-placement.num_busy_placement = c;
+ rbo-placement.num_busy_placement = b;
}
int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: don't print error on -ERESTARTSYS.
From: Dave Airlie airl...@redhat.com
We can get this if the user moves the mouse when we are waiting to move
some stuff around in the validate. Don't fail.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_cs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8d99f70..3346d9e 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -239,7 +239,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
}
r = radeon_cs_parser_relocs(parser);
if (r) {
- DRM_ERROR(Failed to parse relocation !\n);
+ if (r != -ERESTARTSYS)
+ DRM_ERROR(Failed to parse relocation %d!\n, r);
radeon_cs_parser_fini(parser, r);
mutex_unlock(rdev-cs_mutex);
return r;
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] HDMI clean DCE32 support
On Fri, Mar 19, 2010 at 10:14 AM, Mike Lothian m...@fireburn.co.uk wrote: 2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Is there any chance we could get these updates included in the drm-radeon-testing branch? Should all be in there for a week or so. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] arch/x86: Add array variants for setting memory to wc caching.
On Thu, Mar 18, 2010 at 6:50 AM, Pauli Nieminen suok...@gmail.com wrote:
Setting single memory pages at a time to wc takes a lot time in cache flush.
To
reduce number of cache flush set_pages_array_wc and set_memory_array_wc can be
used to set multiple pages to WC with single cache flush.
I don't think this is correct, I've cc'ed Suresh and Venki who looked
at this before,
but I think there is an array in the x86 code that stores the state
and it only has a
single bit in it, it needs to be expanded in order to at WC support.
Dave.
This improves allocation performance for wc cached pages in drm/ttm.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
arch/x86/include/asm/cacheflush.h | 2 +
arch/x86/mm/pageattr.c | 53 +++-
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/cacheflush.h
b/arch/x86/include/asm/cacheflush.h
index 634c40a..d92d63a 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -139,9 +139,11 @@ int set_memory_np(unsigned long addr, int numpages);
int set_memory_4k(unsigned long addr, int numpages);
int set_memory_array_uc(unsigned long *addr, int addrinarray);
+int set_memory_array_wc(unsigned long *addr, int addrinarray);
int set_memory_array_wb(unsigned long *addr, int addrinarray);
int set_pages_array_uc(struct page **pages, int addrinarray);
+int set_pages_array_wc(struct page **pages, int addrinarray);
int set_pages_array_wb(struct page **pages, int addrinarray);
/*
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index cf07c26..0c98a75 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -997,7 +997,8 @@ out_err:
}
EXPORT_SYMBOL(set_memory_uc);
-int set_memory_array_uc(unsigned long *addr, int addrinarray)
+int _set_memory_array(unsigned long *addr, int addrinarray,
+ unsigned long new_type)
{
int i, j;
int ret;
@@ -1007,13 +1008,19 @@ int set_memory_array_uc(unsigned long *addr, int
addrinarray)
*/
for (i = 0; i addrinarray; i++) {
ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
- _PAGE_CACHE_UC_MINUS, NULL);
+ new_type, NULL);
if (ret)
goto out_free;
}
ret = change_page_attr_set(addr, addrinarray,
__pgprot(_PAGE_CACHE_UC_MINUS), 1);
+
+ if (!ret new_type == _PAGE_CACHE_WC)
+ ret = change_page_attr_set_clr(addr, addrinarray,
+ __pgprot(_PAGE_CACHE_WC),
+ __pgprot(_PAGE_CACHE_MASK),
+ 0, CPA_ARRAY, NULL);
if (ret)
goto out_free;
@@ -1025,8 +1032,19 @@ out_free:
return ret;
}
+
+int set_memory_array_uc(unsigned long *addr, int addrinarray)
+{
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_UC_MINUS);
+}
EXPORT_SYMBOL(set_memory_array_uc);
+int set_memory_array_wc(unsigned long *addr, int addrinarray)
+{
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_WC);
+}
+EXPORT_SYMBOL(set_memory_array_wc);
+
int _set_memory_wc(unsigned long addr, int numpages)
{
int ret;
@@ -1153,26 +1171,34 @@ int set_pages_uc(struct page *page, int numpages)
}
EXPORT_SYMBOL(set_pages_uc);
-int set_pages_array_uc(struct page **pages, int addrinarray)
+static int _set_pages_array(struct page **pages, int addrinarray,
+ unsigned long new_type)
{
unsigned long start;
unsigned long end;
int i;
int free_idx;
+ int ret;
for (i = 0; i addrinarray; i++) {
if (PageHighMem(pages[i]))
continue;
start = page_to_pfn(pages[i]) PAGE_SHIFT;
end = start + PAGE_SIZE;
- if (reserve_memtype(start, end, _PAGE_CACHE_UC_MINUS, NULL))
+ if (reserve_memtype(start, end, new_type, NULL))
goto err_out;
}
- if (cpa_set_pages_array(pages, addrinarray,
- __pgprot(_PAGE_CACHE_UC_MINUS)) == 0) {
- return 0; /* Success */
- }
+ ret = cpa_set_pages_array(pages, addrinarray,
+ __pgprot(_PAGE_CACHE_UC_MINUS));
+ if (!ret new_type == _PAGE_CACHE_WC)
+ ret = change_page_attr_set_clr(NULL, addrinarray,
+ __pgprot(_PAGE_CACHE_WC),
+ __pgprot(_PAGE_CACHE_MASK),
+ 0, CPA_PAGES_ARRAY, pages);
+ if (ret)
+ goto err_out;
+ return 0; /* Success */
err_out:
free_idx = i;
Re: My goal
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons jsimm...@infradead.org wrote: Okay all the discussion about multiple display brings me to why I'm doing this. I'm attempting to revive the linux console project. I'm in a position to again work on this project. About 4 years ago the eproject managed to get multi-seat working. My goal is to get there again. My first goal is to get my netbook to act has a multiseat system for two. With a plugged in external montior and a USB keyboard run two concurrent X sessions both running OpenGL applications at the same time. I set out to do this 10 years ago and I want to finally accomplish this. Okay I took an afternoon to flesh out my design and got something working here, I'll try and setup a videod demo later (if I can find a camera). But I can now run two *separate* X servers on different outputs of the same GPU. http://people.freedesktop.org/~airlied/multiseat/ has the kernel + libdrm patch, this is hacked for *my* X1900 (the radeon driver hardcodes a seat - crtc/connector/encoder mapping that should be dynamically setup from userspace via the drm control node. The libdrm patches adds an env var to pick device node (probably needs to be secured). With this I can and some proper xorg.conf to pick the correct input devices DRM_DEVICE_PATH=/dev/dri/renderD128 /opt/xorg/bin/Xorg -retro DRM_DEVICE_PATH=/dev/dri/renderD129 /opt/xorg/bin/Xorg :1 -sharevts -novtswitch -retro I can run two independent X servers on the same GPU. Hopefully this gives you some idea of where I was planning on heading with this. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Allow platform devices to register as DRM devices
I guess technically we could also drop the AGP requirement, but since it worked on my box with AGP=n it seemed to me like a NOP. Its not a NOP, otherwise we'd remove it, AGP || AGP=n means if AGP is enabled DRM must be enabled similiarly, it stops AGP=m + DRM=y basically. EXPORT_SYMBOL(drm_init); diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index ab6c973..48a14a0 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1220,6 +1220,9 @@ struct edid *drm_get_edid(struct drm_connector *connector, int ret; struct edid *edid; + if (drm_core_check_feature(connector-dev, DRIVER_USE_PLATFORM_DEVICE)) + return NULL; + This makes no sense, having the ability to probe EDID or not is most definitely not a platform vs PCI problem. Yeah, that was my poor man's Don't probe EDID hack. I'm not sure if there is a smart way to implicitly check to see if EDID should be probed, but I'm worried about abusing the features flag too badly, though if a DRIVER_USE_EDID is needed then we shouldn't be shy about using it. The generic code never calls this only the driver, so there should be no need for flags at all. Not 100% sure about this, but if you only intend on KMS and don't need to inform userspace of irq support this should be okay. Again, a don't do this hack. I'll look at this more carefully and see if there is a good way to evaluate this based on the hooks that the platform has defined. Its mostly used in UMS to inform userspace for some strange reason its pretty legacy at this point, new driver should probably not hit it. @@ -60,7 +60,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct This also doesn't address noueau/vmwgfx entry points. Yep, thats my bad. I'll refresh and push better patches without whitespace stupidity. Thanks, Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Allow platform devices to register as DRM devices
On Tue, Mar 2, 2010 at 2:00 AM, Jordan Crouse jcro...@codeaurora.org wrote:
Allow platform devices without PCI resources to be DRM devices.
Signed-off-by: Jordan Crouse jcro...@codeaurora.org
This patch has a bunch of whitespace damage at least in my inbox and
also in patchwork
Please also be careful with the places you add copyrights, you moved a
bunch of code
from drm_drv.c to drm_pci.c and added a copyright for Code Aurora in
drm_pci.c? You can
only assert copyright if you actually wrote the code, otherwise the patch
contains your authorship details and who contributed the code. I'm
guessing you might have
copyright over one file in this that being drm_platform.c, the rest
I'm less sure about.
I also wonder if we could/should separate the arm drm support out from
this patch (i.e.
the __arm__ changes).
Some other misc comments below:
#
menuconfig DRM
tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)
- depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
From what I can see the AGP || AGP==n is still required, you just want
to drop the PCI
dependancy??
+ depends on !EMULATED_CMPXCHG MMU
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 8417cc4..4177f60 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -11,6 +11,7 @@
*
* Copyright 1999, 2000 Precision Insight, Inc., Cedar Park, Texas.
* Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Copyright (c) 2009, Code Aurora Forum.
* All Rights Reserved.
There have been much bigger changes to these files without copyright
additions, I'm not sure how big something needs to be but I'm not 100% sure
this comes close.
resource_size_t drm_get_resource_start(struct drm_device *dev, unsigned int
resource)
{
+ if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
+ struct resource *r;
+ r = platform_get_resource(dev-platformdev, IORESOURCE_MEM,
+ resource);
+
+ return r ? r-start : 0;
+ }
+
+#ifdef CONFIG_PCI
return pci_resource_start(dev-pdev, resource);
+#endif
+
+ return 0;
}
EXPORT_SYMBOL(drm_get_resource_start);
resource_size_t drm_get_resource_len(struct drm_device *dev, unsigned int
resource)
{
+ if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
+ struct resource *r;
+ r = platform_get_resource(dev-platformdev, IORESOURCE_MEM,
+ resource);
+
+ return r ? (r-end - r-start) : 0;
+ }
+
+#ifdef CONFIG_PCI
return pci_resource_len(dev-pdev, resource);
+#endif
+
+ return 0;
}
EXPORT_SYMBOL(drm_get_resource_len);
@@ -188,7 +213,7 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
switch (map-type) {
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
-#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
!defined(__powerpc64__) !defined(__x86_64__)
+#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
!defined(__powerpc64__) !defined(__x86_64__) !defined(__arm__)
if (map-offset + (map-size-1) map-offset ||
map-offset virt_to_phys(high_memory)) {
kfree(map);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 766c468..b5171ed 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -24,6 +24,7 @@
*
* Copyright 1999, 2000 Precision Insight, Inc., Cedar Park, Texas.
* Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Copyright (c) 2009, Code Aurora Forum.
* All Rights Reserved.
again similiar, but even less code since you mostly remove code.
*
* Permission is hereby granted, free of charge, to any person obtaining a
@@ -242,47 +243,20 @@ int drm_lastclose(struct drm_device * dev)
*
* Initializes an array of drm_device structures, and attempts to
* initialize all available devices, using consecutive minors, registering
the
- * stubs and initializing the AGP device.
+ * stubs and initializing the device.
*
* Expands the \c DRIVER_PREINIT and \c DRIVER_POST_INIT macros before and
* after the initialization for driver customization.
*/
int drm_init(struct drm_driver *driver)
{
- struct pci_dev *pdev = NULL;
- const struct pci_device_id *pid;
- int i;
-
DRM_DEBUG(\n);
-
INIT_LIST_HEAD(driver-device_list);
- if (driver-driver_features DRIVER_MODESET)
- return pci_register_driver(driver-pci_driver);
-
- /* If not using KMS, fall back to stealth mode manual scanning. */
- for (i = 0; driver-pci_driver.id_table[i].vendor != 0; i++) {
- pid = driver-pci_driver.id_table[i];
-
- /* Loop around setting up a DRM device for each PCI device
Re: [PATCH 0/5] clean up radeon_asic.h v2
On Fri, Mar 12, 2010 at 7:48 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Mar 12, 2010 at 10:25:56AM +0100, Jerome Glisse wrote: I would merge patch 1 2 into a single patch, I've split this up to make patch-reading easier. And it's fully bisectable. I quite like where this is going compared to what was there before, so I've applied the work so far to drm-radeon-testing, its probably 2.6.35 material at this point anyways. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Searching the TTM code I couldn't find the handle code so easily. I see that the vmwgfx driver provides a example of using ttm. So handles are purely a userspace interface, in-kernel we don't use handles for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle to do the bo lookups. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done. I'm not sure either of these makes sense, can you clearly state the goal and maybe we can work out what you need. Sorry I should of stated what I was planing to do. I like to see drmfb have the ablitiy to change the resolution via fbset. To do that we need to be able to create and destory the framebuffer memory if the memory doesn't fit the size of the new resolution. Plus it gives us the bonus of being able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem is that the functions like fb_create are tied to a handle which is not present for the internal framebuffer used by fbdev. Sorry for the junk above. It just took me awhile to figure out the code. Their is steep learning curve. I have patches that should address this coming soon. Okay first up, there are two sets of codepaths, please ignore vmwgfx for now, its _fb implementation is not yet using the drm_fb_helper.c code and it needs to be converted if possible. Originally all the drivers had their own fb code, but its was mostly pointless, the helper allows for drivers to optionally use the shared code, ideally we'd like all drivers to use that code so we get consistent operation across drivers, so user experience isn't driver dependent unless unavoidable. The big issue we have with resizing the buffer is userspace mmaps of the fbdev device, and invalidation. Previous thread of unresolvedness is here. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html If you look at the current fb code, when we get a hotplug event in theory, we try and reuse the current framebuffer. I suppose initially it would be worth trying the resize downwards and keep the current fbdev, but the whole mmap area was the cause of most of the problems and it seemed like a real pain to fix. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. Can't it print the oops on whatever is currently displayed? It need not be a dedicated buffer as long as there is always some buffer. But perhaps this is more complex than that. Yes it is very complex. Reading the code and drm specs you come to realize buffer handling is done with GEM, TTM, or for older drivers drm_maps. Drivers often handle a combine of those, meaning no real wrapper from one api to another :-( From the code it appears GEM is the main userland interface when using KMS. Some how TTM is also usable from userland but I never found a clear example of how that is done. So to the average userland app writer it is a mystery. As for hardware that has a static front buffer I can see how to use drm_maps or TTM but I don't see a easy way to map it to the GEM api. Also their exist ioctl for gem but it appears no one actually uses them but instead write their own :-( So you can see the confusion here. Userspace buffer management interfaces are pre-driver, the only requirement if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers don't exist for the purposes of fb interaction, so drm_maps are ignorable from that pov. Outside of what I described above the drm_framebuffer handling is a mess. From what I can see with the code you can only create a drm_framebuffer with the GEM api. With this case the two most important functions to provide are This isn't correct. You get a drm_file and a handle, the driver then uses these to do whatever it wants to do. This means lookup a GEM object or whatever but there is no reliance on GEM or any other memory manager outside the driver. Again a handle a file priv are in no way GEM specific. dev-mode_config.funcs-fb_create(dev, file_priv, r) and fb-funcs-create_handle(fb, file_priv, r-handle); As you can see if the functions they depend on a handle and a drm_file. To make it possible to create a framebuffer internally using a common code we would remove those requirements. We already have an internal framebuffer creation for fbdev, there is an fb_create callback that does this, its not up to dynamic fbdev creation. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done. I'm not sure either of these makes sense, can you clearly state the goal and maybe we can work out what you need. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 00/14] cleanup radeon_asic.h
2010/3/12 Jerome Glisse gli...@freedesktop.org: On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote: 2010/3/11 Alex Deucher alexdeuc...@gmail.com: I like keeping all the asic definitions in one file as you tend to need to update them all at one time and having them spread across all the asic files increases the likelihood of one or more of them getting missed. But I can live with it if other folks think it's a good idea. Same here. One file means easier editing. Maybe we could use some other of proposed tricks? -- Rafał I don't have strong feeling but Alex has a point, right now we often update them, maybe we should add radeon_asic.c and move asic init (function now in radeon_device.c) along structure there. I've seen it sugggested earlier, Just don't use declarations in the C file, that isn't acceptable coding. If we add radeon_asic.h make sure to include that in places that define the functions as well. Last thing we want is declarations to diverge by accident. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My goal
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons jsimm...@infradead.org wrote: Okay all the discussion about multiple display brings me to why I'm doing this. I'm attempting to revive the linux console project. I'm in a position to again work on this project. About 4 years ago the eproject managed to get multi-seat working. My goal is to get there again. My first goal is to get my netbook to act has a multiseat system for two. With a plugged in external montior and a USB keyboard run two concurrent X sessions both running OpenGL applications at the same time. I set out to do this 10 years ago and I want to finally accomplish this. Hi James, I had a plan (with a picture) but we lost the picture in a disk crash. But it basically sounded like this. Currently we have two device nodes per drm device, a control node and a legacy card node. The control node is there in theory to support multi-seat. The plan was some sort of userspace multi-seat manager (in gdm or otherwise), would use the control node to divide up the modesetting resources and create a number of seat nodes. These seat nodes would operate like the current legacy node except they would only show the user the modesetting resources assigned to them. The control node could also be used to create a node with no mode resources for GPGPU work. You can see the start of this in the drm, look for mode_group. Once the kernel was generating the seat nodes, it would be a matter of giving that path to the X server KMS driver and it would open that instead of the legacy device node, and same for the second X server. This would require of course starting X servers with -sharevts and -novtswitch most likely. Dave. , -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: use drm calloc large and free large
From: Dave Airlie airl...@redhat.com
Now that the drm core can do this, lets just use it, split the code out
so TTM doesn't have to drag all of drmP.h in.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_tt.c| 23 ++
include/drm/drmP.h | 34 +
include/drm/drm_mem_util.h | 65 +++
include/drm/ttm/ttm_bo_driver.h |1 -
4 files changed, 69 insertions(+), 54 deletions(-)
create mode 100644 include/drm/drm_mem_util.h
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index a759170..bab6cd8 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -28,13 +28,13 @@
* Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
*/
-#include linux/vmalloc.h
#include linux/sched.h
#include linux/highmem.h
#include linux/pagemap.h
#include linux/file.h
#include linux/swap.h
#include drm_cache.h
+#include drm_mem_util.h
#include ttm/ttm_module.h
#include ttm/ttm_bo_driver.h
#include ttm/ttm_placement.h
@@ -43,32 +43,15 @@ static int ttm_tt_swapin(struct ttm_tt *ttm);
/**
* Allocates storage for pointers to the pages that back the ttm.
- *
- * Uses kmalloc if possible. Otherwise falls back to vmalloc.
*/
static void ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
{
- unsigned long size = ttm-num_pages * sizeof(*ttm-pages);
- ttm-pages = NULL;
-
- if (size = PAGE_SIZE)
- ttm-pages = kzalloc(size, GFP_KERNEL);
-
- if (!ttm-pages) {
- ttm-pages = vmalloc_user(size);
- if (ttm-pages)
- ttm-page_flags |= TTM_PAGE_FLAG_VMALLOC;
- }
+ ttm-pages = drm_calloc_large(ttm-num_pages, sizeof(*ttm-pages));
}
static void ttm_tt_free_page_directory(struct ttm_tt *ttm)
{
- if (ttm-page_flags TTM_PAGE_FLAG_VMALLOC) {
- vfree(ttm-pages);
- ttm-page_flags = ~TTM_PAGE_FLAG_VMALLOC;
- } else {
- kfree(ttm-pages);
- }
+ drm_free_large(ttm-pages);
ttm-pages = NULL;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 829e524..22e60af 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1595,39 +1595,7 @@ static __inline__ void drm_core_dropmap(struct
drm_local_map *map)
{
}
-
-static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
-{
- if (size != 0 nmemb ULONG_MAX / size)
- return NULL;
-
- if (size * nmemb = PAGE_SIZE)
- return kcalloc(nmemb, size, GFP_KERNEL);
-
- return __vmalloc(size * nmemb,
-GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
-}
-
-/* Modeled after cairo's malloc_ab, it's like calloc but without the zeroing.
*/
-static __inline__ void *drm_malloc_ab(size_t nmemb, size_t size)
-{
- if (size != 0 nmemb ULONG_MAX / size)
- return NULL;
-
- if (size * nmemb = PAGE_SIZE)
- return kmalloc(nmemb * size, GFP_KERNEL);
-
- return __vmalloc(size * nmemb,
-GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
-}
-
-static __inline void drm_free_large(void *ptr)
-{
- if (!is_vmalloc_addr(ptr))
- return kfree(ptr);
-
- vfree(ptr);
-}
+#include drm_mem_util.h
/*...@}*/
#endif /* __KERNEL__ */
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
new file mode 100644
index 000..6bd325f
--- /dev/null
+++ b/include/drm/drm_mem_util.h
@@ -0,0 +1,65 @@
+/*
+ * Copyright © 2008 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Jesse Barnes jbar...@virtuousgeek.org
+ *
+ */
+#ifndef _DRM_MEM_UTIL_H_
+#define _DRM_MEM_UTIL_H_
+
+#include linux/vmalloc.h
+
+static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
+{
+ if (size
[PATCH] [RFC] drm: dumb scanout create/mmap for intel/radeon
From: Dave Airlie airl...@redhat.com
This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.
It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.
Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
---
drivers/gpu/drm/drm_crtc.c | 23 +
drivers/gpu/drm/drm_drv.c|4 +-
drivers/gpu/drm/i915/i915_drv.c |2 +
drivers/gpu/drm/i915/i915_drv.h |5 ++
drivers/gpu/drm/i915/i915_gem.c | 86 +-
drivers/gpu/drm/radeon/radeon_drv.c |8 +++
drivers/gpu/drm/radeon/radeon_gem.c | 48 --
drivers/gpu/drm/radeon/radeon_mode.h |2 +
include/drm/drm.h|3 +
include/drm/drmP.h |8 +++
include/drm/drm_crtc.h |6 ++
include/drm/drm_mode.h | 20
12 files changed, 176 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d91fb8c..8d2e997 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2653,3 +2653,26 @@ out:
mutex_unlock(dev-mode_config.mutex);
return ret;
}
+
+int drm_mode_create_dumb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_create_dumb *args = data;
+
+ if (!dev-driver-dumb_create)
+ return -ENOSYS;
+
+ return dev-driver-dumb_create(file_priv, dev, args-size,
args-handle);
+}
+
+int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_map_dumb *args = data;
+
+ /* call driver ioctl to get mmap offset */
+ if (!dev-driver-dumb_map_offset)
+ return -ENOSYS;
+
+ return dev-driver-dumb_map_offset(file_priv, dev, args-handle,
args-offset);
+}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f3c58e2..4a3b007 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -146,7 +146,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1b2e954..3a07392 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -526,6 +526,8 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
+ .dumb_create = i915_gem_dumb_create,
+ .dumb_map_offset = i915_gem_mmap_gtt,
.ioctls = i915_ioctls,
.fops = {
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 979439c..5bf054c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -930,6 +930,11 @@ void i915_gem_object_flush_write_domain(struct
drm_gem_object *obj);
void i915_gem_shrinker_init(void);
void i915_gem_shrinker_exit(void);
+int i915_gem_dumb_create(struct drm_file *file_priv,
+struct drm_device *dev, uint64_t size,
+uint32_t *handle_p);
+int i915_gem_mmap_gtt(struct drm_file *file_priv, struct drm_device *dev,
+ uint32_t handle, uint64_t *offset);
/* i915_gem_tiling.c */
void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fba37e9..1f1e8c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -107,23 +107,23 @@ i915_gem_get_aperture_ioctl
Re: [git pull] drm request 3
If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? All of these are always possible to do. We've been _very_ good at doing them in general. I'm complaining, because let's face it, what else can I do? And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. So practically speaking: what _do_ you suggest we do about all the regressions this will cause? At the moment in Fedora we deal with this for our users, we have dependencies between userspace and kernel space and we upgrade the bits when they upgrade the kernels, its a pain in the ass, but its what we accepted we needed to do to get nouveau in front of people. We are currently maintain 3 nouveau APIs across F11, F12 and F13. The main reason the API was gutted was because it supported lots of things that weren't supportable going forward. User modesetting support was completely removed and this meant lots of the API was pointless. Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface which justs ifdefs around this for now, and in another release or two we rip all that out. Of course I can't ask him either of these until normal people who live in Australia wake up in 2-3 hrs, as opposed to me who is sitting in the dark trying not to wake the baby. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Can we try to make it less of a pain in the ass at some other level? For example, I realize that it's a real pain - both for the kernel _and_ for the user space library - to dynamically have to support multiple versions of some interface. And doing it _statically_ (with a compile option) isn't much better, because you end up not only with source code from hell, you still end up with the problem of having to compile the libraries and the kernel for the same interface, and not being able to mix. So let's say that we live with an API that changes, where none of the binaries (and no single version of the source code either) really support anything but _their_ version of the interface. Why does it then have to be such an effing pain for the _user_? (And by being such an effing pain for the user, it also becomes indirectly a pain for the distribution too - now you have all those nasty dependencies where you really cannot mix things up at all, and you can't upgrade one piece without upgrading the other). Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. Quite frankly, I really don't think that's a wonderful option either. Havign dynamic conditionals in code not only makes things worse to maintain, they slow things down too, and make code bigger. So what I'd look for is a sane technical solution to the technical problem of that ABI screwed up. And it's not like this is a new issue. We've had this several times before. It's called versioning, and the solution tends to pretty much _always_ boil down to two cases: - don't _ever_ change the ABI in backwards-incompatible ways, and have feature flags to say what level of support ther is. This is quite common, but it really does require that backwards compatibility. You can add features, but every time you add a feature, you still maintain the old ones _and_ new users need to check the feature flag first (and fall back on the old way of doing things if the new feature isn't there) Clearly this one doesn't seem to work for DRM. And quite frankly, I suspect it's at least partly because some DRM people aren't even _trying_ - possibly because they aren't even thinking about these kinds of issues. We've done this exactly like this since the drm went upstream, I think there has been one interface incompatible change in the kernel drm since it was upstream, in i810 back in the XFree86 days. KMS required new config options since moving the card init into the kernel, was going to break or be broken by a userspace driver reiniting that card, and we've retained compatiblity with older drivers fine. So you are tarring the whole drm with the interface to one driver which is clearly marked as having an unstable ABI. Nouveau is different, they have had no reason to version or make a stable interface until they could design an interface that would expose the features of the hw that they are trying to build a driver for. They've also used the timing to drop all support for legacy user modesetting drivers while they could, before it was deployed on a lot of people's machines in a lot of places. I really don't understand why this wouldn't solve all your distro problems, _and_ solve my kind of user problems too. It's simply not acceptable to just say ok, X doesn't work. Why aren't the libdrm libraries simply _versioned_? This would require redesigning the whole way distros build and distribute packages. Having to build 4-5 versions of nouveau for each version of Fedora would be a major increase in overheads for a minimal amount of return. IOW, why can't we just have /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so living happily side-by-side? Why can't we just switch between Fedora 11, 12 and 13 kernels, and automatically get the right library? The glibc people do it based on hardware features. It's just a dlopen() away. This isn't rocket science. I shouldn't need to complain. I think it would make the life of even the _developers_ much easier. Who was the less-than-rocket-scientist that decided that the right thing to do was to check the kernel DRM version support, and exit with an error if it doesn't match? See what I'm saying? What I care about is that right now, it's impossible to switch kernels on a particular setup. That makes it effectively impossible to test new kernels sanely. And that really is a _technical_ problem. Btw, I'm sure there are other approaches too. But I really suspect that it should be pretty trivial to change nouveau (and I suspect this has nothing nouveau-specific in it - it migth even be the X server itself that does the DRM version test) to instead of dying,
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Stephane Marchesin wrote: In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. Stop aligning DRM versioning with nouveau versioning. This isn't a generic problem with DRM, we've supported versioning interfaces for years and have broken them maybe once. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? Its nouveau project not X not DRM, stop generalising the situation. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Its nouveau project not X not DRM, stop generalising the situation. Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. I certainly seem to remember some similar issues with the intel driver long long ago. What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Would it try to handle it gracefully? Or are we in the same situation that the intel driver guys can never fix anything fundamental without doing a whole flag day? Patchlevel never changed in intel, but if you changed the MINOR back to 1 then shit would break, exactly like any userspace shared library. It'll fall over in userspace, because userspace has minimum versioning requirements same as if you change all the udev interfaces back 6 years nothing boots anymore, or you remove the wireless interfaces or xattrs from ext3. I thin The standard DRM versioning interface is MAJOR - don't change this ever except for second coming. Radeon KMS is the only driver to have bumped this interface version, and we still support the 1.0.0 if you turn off modesetting. Mach64 bumped it once but we never upstreamed either version. MINOR - optionally bump this when you add a new API, new feature, new chipset, now we generally just add a new GETPARAM, which the userspace can check for and do the correct thing. PATCHLEVEL - ideally bump this for small non-user visible changes, in practice nobody touches this ever. Nouveau have abused this to provide pre 1.0.0 version number, when they release version 1.0.0 they are expected to follow standard drm versioning rules. Now just like in userspace, if you add features to the minor number, userspace driver will come to depend on these features being there. If you dropped the intel minor to 1.1 it would crap itself all over the place, same as if you starting trying to ship glibc2.0 on a glibc2.1 distro. We have never worried about new userspaces running on really old kernels, because generally 3-4 years has been good enough for distros. This is a nouveau problem not a drm problem. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Linus Torvalds wrote: Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. Ok, I cloned the drm tree just to see, and it does seem like it's just nouveau that does that whole thing. At least from a quick grep of drmGetVersion() calls. I certainly seem to remember some similar issues with the intel driver long long ago. .. but Jesse tells me that it's using feature masks etc, so maybe my recollection is about unrelated issues. So yeah, nouveau seems to special. Although somebody already said that if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon driver just doesn't check the version number, and fails in different ways. As I mentioned earlier we had one issue with i810 about 7-8 years ago, before I was here, someone changed the i810_drm.h api incompatibly in XFree86. This was one of the things that led to having a proper policy. For radeon while we were developing the KMS feature in staging we changed the API once or twice, while we were developing KMS in Fedora we changed it at least 4 times, we shipped Intel KMS in F9 with a completly different API and just dealt with it, since upstreaming changed the API completely. The staging API changes were mostly to fix things that userspace did that made it possible to trample over other X users memory. This meant you had to bump the userspace that was doing the evil thing by mistake. Once we removed KMS from staging, we stabilised all APIs and behaviour (its not just the API, internal command stream checking for security issues). Since then we made one change to the CS behaviour in a backwards compatible manner so that old userspaces wouldn't die, but you couldn't abuse the hole they had relied on. I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Anyway, since I had looked at the libdrm sources, I had most of this on my machine anyway, so I've compiled it all, and am going to reboot and see if I can make a few symlinks work. IOW, right now I have this: [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ [r...@nehalem drivers]# ll nouveau_drv.so* lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so - nouveau_drv.so-0.0.16 -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 Naah, I just end up with a really screwed up screen with that. I probably did something wrong in the configuration phase or something. I'll look for the precompiled ones, and hope they don't have some other odd dependencies. Looks like libdrm_nouveau didn't get updated along with nouveau. We don't have mesa in F12 so that won't matter. wget http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.18/1.fc13/src/libdrm-2.4.18-1.fc13.src.rpm rpmbuild --rebuild libdrm-2.4.18-1.fc13.src.rpm rpm -Uvh ~/rpmbuild/RPMS/libdrm-2.4.18-1.fc13.x86_64.rpm ~/rpmbuild/RPMS/libdrm-devel-2.4.18-1.fc13.x86_64.rpm wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. This one doesn't work on F12. It wants xorg-x11-server-devel 1.7.99.3-3. Is there some limited set of rpm's I can get from the f13 archive? If by limited you mean the whole X server + udev updates that would work, if not then: http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm That src rpm should be rebuildable on F12, I just removed the requires on F13 stuff. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 5:44 PM, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful ?- limits the developer base ?- limits the tester base ?- wastes time and effort. (fewer developers/testers means that while _this_ ? feature was easier to add, all your _future_ features will be a bit harder ? to do. It compounds up.) ?- so it hurts even the very developer who is most convinced that this was the ? right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. The other option that we used to have was out-of-tree kernel modules, that shipped in X.org along with Mesa all in one big tree. This wasn't satisfactory and we were pretty much told to put the drm modules into the kernel at that point, Other suggestion from Luc has been to stablise drm/mesa/X.org APIs a lot more and ship driver sources for all 3 bit separately, but that doesn't seem workable either, since the Mesa API is infinitely broad (its effectively OpenGL), and changes way too often, as does the kernel API, though the drm component is probably okay. You'll find groups like Intel are releasing things at fairly similiar times every quarter and recommending those groupings for distros to take as tested together. You also have the BSD options where they just create a base OS system and screw the whole pick-n-mix decisions. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon - fbdev - kms - hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev drivers do, and then a new fbset could tkae advantage of these. I'm not sure how much different to the current kms interface or how powerful we really need to make tihs interface though, and I feel kinda bad implementing it without some idea what users would want from it. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go Ok, there's always the next merge window, maybe it will have gotten some testing by then. Linux next didn't pick up this build failure, wierdly neither did the powerpc build I did with this turned off, because ACPI was also off on ppc, it was in linux-next for at least 2 days, and from what I can see that found the ppc problems, it never found the x86 option since it was on by default. I'm going to just rip the nouveau bits out of the patch, btw nouveau is in staging, so you are being a bit OTT, calm down. Dave.-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
x86 after PPC (I think I just validated Ingo). Why is VGA_SWITCHEROO enabled by default? because it does nothing on anything except the laptops in question and on those it does nothing except add a control file in debugfs? So how am I supposed to indicate to distro vendors that something should be turned on? If you think that distro kernel maintainers really understand every config option that goes past, I've got a bridge. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Wed, Mar 3, 2010 at 9:40 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, 3 Mar 2010, Dave Airlie wrote: Did I mention that driver is in STAGING? Staging is for _improving_ the quality of the drivers, not for making it worse. We still very much have quality standards. The staging tree is for things to get in that don't quite _reach_ the standards we expect, but it's not a blanket excuse for not testing things. And yes, I expect that stuff can be a bit rough during the merge window, after all, the whole point is that we can fix things up. But quite frankly, if _I_ find problems on the few machines I personally build and test on, then what does that say about the bigger picture? IOW, I refuse to pull code that doesn't even work for me. If I did, where would we end up? What do you think should be my minimal quality requirements, if Oh, it doesn't even build for me is too much to ask for? So if I find code that doesn't work, I'm not going to just say whatever. I'm going to reject it. So can we get linux-next builds to build with *your* Kconfig? This should cut down the amount of crap you see considerably. I'm not saying we have too many configuration options and testing them all is insane, granted I admit I should have found this one since I do generally try and build with nouveau on here. I've sent a new pull, take it or not it builds here at least under staging/acpi/vga_switcheroo off Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
0/3/3 Dave Airlie airl...@linux.ie: Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go Ok, there's always the next merge window, maybe it will have gotten some testing by then. Linux next didn't pick up this build failure, wierdly neither did the powerpc build I did with this turned off, because ACPI was also off on ppc, it was in linux-next for at least 2 days, and from what I can see that found the ppc problems, it never found the x86 option since it was on by default. I'm going to just rip the nouveau bits out of the patch, btw nouveau is in staging, so you are being a bit OTT, calm down.\ Anyways sfr just confirmed linux-next doesn't build CONFIG_STAGING drivers so again that wouldn't have helped. So you made us pull nouveau into staging, now you are giving out because staging drivers have issues? In any case I've fixed the default y and the STAGING build in my tree. Did I mention that driver is in STAGING? Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
