dri-devel June 2011

dri-devel@lists.freedesktop.org

101 participants
499 discussions

[Bug 32768] VBO rendering using glDrawArrays causes program termination and "cs IB too big" message
by bugzilla-daemon＠freedesktop.org 22 Jun '11

22 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=32768 --- Comment #6 from RCX Slinger <rcxslinger(a)gmail.com> 2011-06-22 01:40:36 PDT --- Created an attachment (id=48270) --> (https://bugs.freedesktop.org/attachment.cgi?id=48270) (no) changes between patched and unpatched mesa reported by piglit No changes/regressions detected by piglit when running "r600.tests" and comparing the results between patched and unpatched mesa (from git). Both mesa builds were compiled to use "mesa classic" instead of gallium (the patch only affects mesa classic, not gallium). If anyone could merge the patch I would appreciate it. Thank you. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 36962] New: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
by bugzilla-daemon＠bugzilla.kernel.org 22 Jun '11

22 Jun '11

https://bugzilla.kernel.org/show_bug.cgi?id=36962 Summary: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Product: Drivers Version: 2.5 Kernel Version: 2.6.39 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: maciej.rutecki(a)gmail.com CC: kaffeemonster(a)googlemail.com, rjw(a)sisk.pl, maciej.rutecki(a)gmail.com Regression: Yes Subject : [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Submitter : Jan Seiffert <kaffeemonster(a)googlemail.com> Date : 2011-05-25 2:32 Message-ID : BANLkTimd6nvXTbn2hM+cKDNKFpxzsQLHog(a)mail.gmail.com References : http://marc.info/?l=linux-kernel&m=130629073407685&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

2 8

[PATCH] drm: Honour O_NONBLOCK on the device for reading events
by Chris Wilson 21 Jun '11

21 Jun '11

Otherwise drmHandleEvent will block if accidentally read too often... Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Phillip Haddad <phillip.haddad(a)gmail.com> --- drivers/gpu/drm/drm_fops.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 2ec7d48..279aa95 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -617,6 +617,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer, size_t total; ssize_t ret; + if (filp->f_flags & O_NONBLOCK && list_empty(&file_priv->event_list)) + return -EAGAIN; + ret = wait_event_interruptible(file_priv->event_wait, !list_empty(&file_priv->event_list)); if (ret < 0) -- 1.7.5.3

2 3

Re: Linux 3.0-rc4
by Melchior FRANZ 21 Jun '11

21 Jun '11

* Nick Bowler -- Tuesday 21 June 2011: > We're at -rc4 now, but it seems that the following patch (drm/i915: add > missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made > it in yet? > > http://permalink.gmane.org/gmane.linux.kernel/1148279 > > The i915 driver has been broken since 3.0-rc1 without this fix, > which has been available for 3 weeks now. Keith has suggested a better fix (https://lkml.org/lkml/2011/6/6/560), but for some reason it still hasn't made it into the kernel. m.

1 0

[Bug 37662] Upgrade to version 2.6.38, disable the laptop display back light
by bugzilla-daemon＠bugzilla.kernel.org 21 Jun '11

21 Jun '11

https://bugzilla.kernel.org/show_bug.cgi?id=37662 Len Brown <lenb(a)kernel.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lenb(a)kernel.org Component|Power-Video |Video(DRI - non Intel) AssignedTo|acpi_power-video@kernel-bug |drivers_video-dri@kernel-bu |s.osdl.org |gs.osdl.org Product|ACPI |Drivers --- Comment #2 from Len Brown <lenb(a)kernel.org> 2011-06-21 01:48:19 --- attachment is full of these: WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]() I don't see a linked launchpad report. moving this bug to DRM. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

[git pull] drm radeon + nouveau fixes.
by Dave Airlie 21 Jun '11

21 Jun '11

Hi Linus, just some nouveau and radeon fixes, nothing major, couple of fixes for rv730 since I plugged in the 30" monitor and it didn't work, one fix for the switchy GPU machines getting spammed when radeon shared an irq and some nouveau regression fixes from Ben. Dave. The following changes since commit de505e709ffb09a7382ca8e0d8c7dbb171ba5830: Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging (2011-06-18 20:33:31 -0700) 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/atom: fix duallink on some early DCE3.2 cards drm/radeon/kms: add missing param for dce3.2 DP transmitter setup drm/radeon/kms/r6xx+: voltage fixes Ben Skeggs (3): drm/nouveau: fix big-endian switch drm/nv50/disp: fix gamma with page flipping overlay turned on drm/nouveau: fix assumption that semaphore dmaobj is valid in x-chan sync Dave Airlie (3): drm/radeon: avoid warnings from r600/eg irq handlers on powered off card. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drm/nouveau: drop leftover debugging Emil Velikov (1): drm/nouveau/pm: Prevent overflow in nouveau_perf_init() drivers/gpu/drm/nouveau/nouveau_acpi.c | 1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 59 +++++++++++++----------------- drivers/gpu/drm/nouveau/nouveau_perf.c | 5 +++ drivers/gpu/drm/nouveau/nouveau_state.c | 4 +- drivers/gpu/drm/nouveau/nv50_display.c | 17 +++++++-- drivers/gpu/drm/radeon/evergreen.c | 23 +++++++----- drivers/gpu/drm/radeon/r600.c | 18 +++++---- drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++ drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++++-- drivers/gpu/drm/radeon/rv770.c | 3 ++ 10 files changed, 84 insertions(+), 61 deletions(-)

1 0

Regression in panic
by Mandeep Singh Baines 20 Jun '11

20 Jun '11

On Tue, Jun 22, 2010 at 8:12 PM, Dave Airlie <airlied(a)gmail.com> wrote: > From: Jesse Barnes <jbarnes(a)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 <airlied(a)redhat.com> Hi Dave, I think this change is causing a regression I'm seeing in panic. Before this change, I'd get a reboot on panic (we've configured as such). With this change, my machine gets wedged if the machine is running in X when the panic occurs. I traced the code flow to this: bust_spinlocks(0); ->unblank_screen(); ->do_unblank_screen(0); ->vc->vc_sw->con_blank(vc, 0, 0); ->fbcon_blank(vc, 0, 0); ->update_screen(vc); ->redraw_screen(vc, 0); ->vc->vc_sw->con_switch(vc); ->fbcon_switch(vc); ->ops->update_start(info); ->bit_update_start(info); ->fb_pan_display(info, &ops->var); ->info->fbops->fb_pan_display(var, info); ->drm_fb_helper_pan_display(var, info); ->mutex_lock(&dev->mode_config.mutex); *this blocks* With this change, there is now a lot going on in the panic path. Stuff that I'm not sure is safe when panicking. In addition to the mutex_lock, there is also a del_timer_sync() now happening in the context of panic(). I see this bug with a 2.6.38 kernel but did a quick scan of a newer kernels and did not see anything that changed in this path so I suspect its still there. Reverting this change fixes the regression. Regards, Mandeep > --- > 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 > @@ -224,7 +224,7 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev, > > drm_fb_helper_fill_fix(info, fb->pitch, fb->depth); > > - info->flags = FBINFO_DEFAULT; > + info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT; > info->fbops = &radeonfb_ops; > > tmp = radeon_bo_gpu_offset(rbo) - rdev->mc.vram_start; > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index b0a3fa0..7eadb35 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -283,7 +283,8 @@ static inline int fbcon_is_inactive(struct vc_data *vc, struct fb_info *info) > struct fbcon_ops *ops = info->fbcon_par; > > return (info->state != FBINFO_STATE_RUNNING || > - vc->vc_mode != KD_TEXT || ops->graphics); > + vc->vc_mode != KD_TEXT || ops->graphics) && > + !vt_force_oops_output(vc); > } > > static inline int get_color(struct vc_data *vc, struct fb_info *info, > @@ -1073,6 +1074,7 @@ static void fbcon_init(struct vc_data *vc, int init) > if (p->userfont) > charcnt = FNTCHARCNT(p->fontdata); > > + vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT); > vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1); > vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800; > if (charcnt == 256) { > diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h > index 38fe59d..d7d9acd 100644 > --- a/include/linux/console_struct.h > +++ b/include/linux/console_struct.h > @@ -105,6 +105,7 @@ struct vc_data { > struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */ > unsigned long vc_uni_pagedir; > unsigned long *vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */ > + bool vc_panic_force_write; /* when oops/panic this VC can accept forced output/blanking */ > /* additional information is in vt_kern.h */ > }; > > diff --git a/include/linux/fb.h b/include/linux/fb.h > index 8e5a9df..25f4950 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -812,6 +812,10 @@ struct fb_tile_ops { > */ > #define FBINFO_BE_MATH 0x100000 > > +/* report to the VT layer that this fb driver can accept forced console > + output like oopses */ > +#define FBINFO_CAN_FORCE_OUTPUT 0x200000 > + > struct fb_info { > int node; > int flags; > diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h > index 7f56db4..56cce34 100644 > --- a/include/linux/vt_kern.h > +++ b/include/linux/vt_kern.h > @@ -100,6 +100,13 @@ extern int unbind_con_driver(const struct consw *csw, int first, int last, > int deflt); > int vty_init(const struct file_operations *console_fops); > > +static inline bool vt_force_oops_output(struct vc_data *vc) > +{ > + if (oops_in_progress && vc->vc_panic_force_write) > + return true; > + return false; > +} > + > /* > * vc_screen.c shares this temporary buffer with the console write code so that > * we can easily avoid touching user space while holding the console spinlock. > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

2 2

[PATCH 3/3 REPOST] alpha, drm: Add Alpha support to Radeon DRM code
by Jay Estabrook 20 Jun '11

20 Jun '11

Alpha needs to have available the system bus address for the Radeon's local memory, so that it can be used in ttm_bo_vm_fault(), when building the PTEs for accessing that VRAM. So, we make bus.addr hold the ioremap() return, and then we can modify bus.base appropriately for use during page fault processing. Signed-off-by: Jay Estabrook <jay.estabrook(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff -Naurp a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c --- a/drivers/gpu/drm/radeon/radeon_ttm.c 2011-04-26 23:48:50.000000000 -0400 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c 2011-05-03 18:24:27.000000000 -0400 @@ -450,6 +450,29 @@ static int radeon_ttm_io_mem_reserve(str return -EINVAL; mem->bus.base = rdev->mc.aper_base; mem->bus.is_iomem = true; +#ifdef __alpha__ + /* + * Alpha: use bus.addr to hold the ioremap() return, + * so we can modify bus.base below. + */ + if (mem->placement & TTM_PL_FLAG_WC) + mem->bus.addr = + ioremap_wc(mem->bus.base + mem->bus.offset, + mem->bus.size); + else + mem->bus.addr = + ioremap_nocache(mem->bus.base + mem->bus.offset, + mem->bus.size); + + /* + * Alpha: Take just the bus offset and + * add the hose/domain memory base. + * Then, bus.base can be returned + * for use in an mmap() call. + */ + mem->bus.base = (mem->bus.base & 0x0ffffffffUL) + + rdev->ddev->hose->dense_mem_base; +#endif break; default: return -EINVAL;

1 0

[PATCH] drm/radeon/kms/r6xx+: voltage fixes
by Alex Deucher 20 Jun '11

20 Jun '11

0xff01 is not an actual voltage value, but a flag for the driver. If the power state as that value, skip setting the voltage. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/evergreen.c | 6 ++++++ drivers/gpu/drm/radeon/r600.c | 3 +++ drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++++ drivers/gpu/drm/radeon/rv770.c | 3 +++ 4 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index b06f2db..3c304f3 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -140,11 +140,17 @@ void evergreen_pm_misc(struct radeon_device *rdev) struct radeon_voltage *voltage = &ps->clock_info[req_cm_idx].voltage; if (voltage->type == VOLTAGE_SW) { + /* 0xff01 is a flag rather then an actual voltage */ + if (voltage->voltage == 0xff01) + return; if (voltage->voltage && (voltage->voltage != rdev->pm.current_vddc)) { radeon_atom_set_voltage(rdev, voltage->voltage, SET_VOLTAGE_TYPE_ASIC_VDDC); rdev->pm.current_vddc = voltage->voltage; DRM_DEBUG("Setting: vddc: %d\n", voltage->voltage); } + /* 0xff01 is a flag rather then an actual voltage */ + if (voltage->vddci == 0xff01) + return; if (voltage->vddci && (voltage->vddci != rdev->pm.current_vddci)) { radeon_atom_set_voltage(rdev, voltage->vddci, SET_VOLTAGE_TYPE_ASIC_VDDCI); rdev->pm.current_vddci = voltage->vddci; diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index b949542..4ac232e 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -590,6 +590,9 @@ void r600_pm_misc(struct radeon_device *rdev) struct radeon_voltage *voltage = &ps->clock_info[req_cm_idx].voltage; if ((voltage->type == VOLTAGE_SW) && voltage->voltage) { + /* 0xff01 is a flag rather then an actual voltage */ + if (voltage->voltage == 0xff01) + return; if (voltage->voltage != rdev->pm.current_vddc) { radeon_atom_set_voltage(rdev, voltage->voltage, SET_VOLTAGE_TYPE_ASIC_VDDC); rdev->pm.current_vddc = voltage->voltage; diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index fa62a50..1e725d9 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -2607,6 +2607,10 @@ void radeon_atom_set_voltage(struct radeon_device *rdev, u16 voltage_level, u8 v if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev, &crev)) return; + /* 0xff01 is a flag rather then an actual voltage */ + if (voltage_level == 0xff01) + return; + switch (crev) { case 1: args.v1.ucVoltageType = voltage_type; diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index 2689add..66e349d 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -105,6 +105,9 @@ void rv770_pm_misc(struct radeon_device *rdev) struct radeon_voltage *voltage = &ps->clock_info[req_cm_idx].voltage; if ((voltage->type == VOLTAGE_SW) && voltage->voltage) { + /* 0xff01 is a flag rather then an actual voltage */ + if (voltage->voltage == 0xff01) + return; if (voltage->voltage != rdev->pm.current_vddc) { radeon_atom_set_voltage(rdev, voltage->voltage, SET_VOLTAGE_TYPE_ASIC_VDDC); rdev->pm.current_vddc = voltage->voltage; -- 1.7.1.1

1 0

[PATCH] r600g: reorder LIT instructions to support src == dst
by Pierre-Eric Pelloux-Prayer 20 Jun '11

20 Jun '11

Hi, the attached patch should be an improvement over Vadim Girlin's patch fixing LIT instruction for r600g (commit 2fe39b46e73aea37152777fe11d489e0b1bc3f92). Instructions used in tgsi_lit have been reordered to always write to a dst channel after the same channel in src has been read (so if src == dst, input values are not overwritten before being used). I've sent the accompagnying test case to piglit ML. Pierre-Eric

1 0

← Newer
1
...
34
35
36
37
38
39
40
...
50
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2011