dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

[pull] radeon drm-next-3.10-2
by alexdeucher＠gmail.com 02 May '13

02 May '13

From: Alex Deucher <alexander.deucher(a)amd.com> Hi Dave, Just some fixes that have accumulated over the last couple of weeks and some new PCI ids. The following changes since commit f468400664e3ae79e6e001bb2820c79bebe6aa41: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-05-02 17:33:25 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.10-2 Alex Deucher (6): drm/radeon: fix endian bugs in atom_allocate_fb_scratch() drm/radeon: fix possible segfault when parsing pm tables drm/radeon: add some new SI PCI ids drm/radeon: add new richland pci ids drm/radeon: clarify family checks in pm table parsing drm/radeon: fix handling of v6 power tables Christian König (4): drm/radeon: allocate SA bo in the requested domain drm/radeon: fix scratch reg handling for UVD fence drm/radeon: fix UPLL_REF_DIV_MASK definition drm/radeon: consolidate UVD clock programming Jerome Glisse (1): radeon: add bo tracking debugfs drivers/gpu/drm/radeon/atom.c | 6 +- drivers/gpu/drm/radeon/evergreen.c | 103 +++-------------------- drivers/gpu/drm/radeon/evergreend.h | 2 +- drivers/gpu/drm/radeon/ni.c | 6 +- drivers/gpu/drm/radeon/r600d.h | 4 + drivers/gpu/drm/radeon/radeon.h | 16 +++- drivers/gpu/drm/radeon/radeon_atombios.c | 27 ++++-- drivers/gpu/drm/radeon/radeon_device.c | 5 + drivers/gpu/drm/radeon/radeon_fence.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 50 +++++++++++ drivers/gpu/drm/radeon/radeon_sa.c | 2 +- drivers/gpu/drm/radeon/radeon_uvd.c | 137 ++++++++++++++++++++++++++++++ drivers/gpu/drm/radeon/rv770.c | 110 ++++-------------------- drivers/gpu/drm/radeon/rv770d.h | 2 +- drivers/gpu/drm/radeon/si.c | 104 +++-------------------- drivers/gpu/drm/radeon/sid.h | 2 +- include/drm/drm_pciids.h | 5 + 17 files changed, 284 insertions(+), 299 deletions(-)

1 0

[Bug 63124] New: [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch
by bugzilla-daemon＠freedesktop.org 02 May '13

02 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=63124 Priority: medium Bug ID: 63124 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch Severity: major Classification: Unclassified OS: Linux (All) Reporter: abortretryfail(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 77426 --> https://bugs.freedesktop.org/attachment.cgi?id=77426&action=edit dmesg output from when the GPU resets. This keeps happening until the game is killed or you look away from whatever is causing the lockup. This might be related to bug #61721, as it also occurs on my machine. When playing Half Life 2 Deathmatch, the game runs great until certain scenes cause a GPU lockup. When run with R600_DEBUG=nohyperz there's no lockup, but performance is much slower. (from ~85fps vsync 1400x1050 down to ~45fps w/o HyperZ) I'll see if I can get an apitrace tonight. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[PATCH][DRM] Tweak DRM-related kernel-doc content to get rid of warnings.
by Robert P. J. Day 02 May '13

02 May '13

Fix kernel-doc content to suppress warnings. No functional change. Signed-off-by: Robert P. J. Day <rpjday(a)crashcourse.ca> --- someone is welcome to peruse this and tweak it further if they wish. this gets rid of all of the DRM-related kerneldoc warnings. diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index e2acfdb..7591e70 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -982,14 +982,15 @@ EXPORT_SYMBOL(drm_edid_is_valid); #define DDC_SEGMENT_ADDR 0x30 /** - * Get EDID information via I2C. - * - * \param adapter : i2c device adaptor - * \param buf : EDID data buffer to be filled - * \param len : EDID data buffer length - * \return 0 on success or -1 on failure. + * drm_do_probe_ddc_edid - get EDID information via I2C. + * @adapter: i2c device adaptor + * @buf: EDID data buffer to be filled + * @block: start block + * @len: EDID data buffer length * * Try to fetch EDID information by calling i2c driver function. + * + * Return: 0 on success or -1 on failure. */ static int drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, @@ -1128,10 +1129,11 @@ out: } /** - * Probe DDC presence. + * drm_probe_ddc - probe DDC presence. + * + * @adapter: i2c device adaptor * - * \param adapter : i2c device adaptor - * \return 1 on success + * Return: 1 on success */ bool drm_probe_ddc(struct i2c_adapter *adapter) @@ -1455,8 +1457,10 @@ bad_std_timing(u8 a, u8 b) /** * drm_mode_std - convert standard mode info (width, height, refresh) into mode + * @connector: DRM connector + * @edid: EDID structure * @t: standard timing params - * @timing_level: standard timing level + * @revision: revision * * Take the standard timing params (in this case width, aspect, and refresh) * and convert them into a real mode using CVT/GTF/DMT. @@ -2001,6 +2005,7 @@ do_established_modes(struct detailed_timing *timing, void *c) /** * add_established_modes - get est. modes from EDID and add them + * @connector: DRM connector * @edid: EDID block to scan * * Each EDID block contains a bitmap of the supported "established modes" list @@ -2063,6 +2068,7 @@ do_standard_modes(struct detailed_timing *timing, void *c) /** * add_standard_modes - get std. modes from EDID and add them + * @connector: DRM connector * @edid: EDID block to scan * * Standard modes can be calculated using the appropriate standard (DMT, @@ -2232,7 +2238,8 @@ add_detailed_modes(struct drm_connector *connector, struct edid *edid, #define EDID_CEA_VCDB_QS (1 << 6) /** - * Search EDID for CEA extension block. + * drm_find_cea_extension - search EDID for CEA extension block. + * @edid: EDID block to search */ u8 *drm_find_cea_extension(struct edid *edid) { @@ -2605,6 +2612,7 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor); /** * drm_detect_monitor_audio - check monitor audio capability + * @edid: EDID block to search * * Monitor should have CEA extension block. * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic @@ -2650,6 +2658,7 @@ EXPORT_SYMBOL(drm_detect_monitor_audio); /** * drm_rgb_quant_range_selectable - is RGB quantization range selectable? + * @edid: EDID block to search * * Check whether the monitor reports the RGB quantization range selection * as supported. The AVI infoframe can then be used to inform the monitor -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Re: [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
by Mel Gorman 02 May '13

02 May '13

On Tue, Apr 30, 2013 at 03:00:50PM -0700, Kent Overstreet wrote: > On Tue, Apr 30, 2013 at 10:53:55PM +0100, Mel Gorman wrote: > > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote: > > > diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c > > > index 03e44c1..8b9c1a6 100644 > > > --- a/drivers/md/bcache/btree.c > > > +++ b/drivers/md/bcache/btree.c > > > @@ -599,11 +599,12 @@ static int mca_reap(struct btree *b, struct closure *cl, unsigned min_order) > > > return 0; > > > } > > > > > > -static int bch_mca_shrink(struct shrinker *shrink, struct shrink_control *sc) > > > +static long bch_mca_scan(struct shrinker *shrink, struct shrink_control *sc) > > > { > > > struct cache_set *c = container_of(shrink, struct cache_set, shrink); > > > struct btree *b, *t; > > > unsigned long i, nr = sc->nr_to_scan; > > > + long freed = 0; > > > > > > if (c->shrinker_disabled) > > > return 0; > > > > -1 if shrinker disabled? > > > > Otherwise if the shrinker is disabled we ultimately hit this loop in > > shrink_slab_one() > > My memory is very hazy on this stuff, but I recall there being another > loop that'd just spin if we always returned -1. > > (It might've been /proc/sys/vm/drop_caches, or maybe that was another > bug..) > It might be worth chasing down what that bug was and fixing it. > But 0 should certainly be safe - if we're always returning 0, then we're > claiming we don't have anything to shrink. > It won't crash, but in Glauber's current code, it'll call you a few more times uselessly and the scanned statistics become misleading. I think Glauber/Dave's series is a big improvement over what we currently have and it would be nice to get it ironed out. -- Mel Gorman SUSE Labs

2 1

[PATCH] drm/gma500: fix backlight hotkeys behaviour on cedarview netbooks
by Anisse Astier 02 May '13

02 May '13

Backlight hotkeys weren't working before on certain cedartrail laptops. The source of this problem is that the hotkeys' ASLE opregion interrupts were simply ignored. Driver seemed to expect the interrupt to be associated with a pipe, but it wasn't. Accepting the ASLE interrupt without an associated pipe event flag fixes the issue, the backlight code is called when needed, making the brightness keys work properly. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597 Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.html Cc: stable(a)kernel.org Signed-off-by: Anisse Astier <anisse(a)astier.eu> --- drivers/gpu/drm/gma500/psb_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c index 8652cdf..029eccf 100644 --- a/drivers/gpu/drm/gma500/psb_irq.c +++ b/drivers/gpu/drm/gma500/psb_irq.c @@ -211,7 +211,7 @@ irqreturn_t psb_irq_handler(DRM_IRQ_ARGS) vdc_stat = PSB_RVDC32(PSB_INT_IDENTITY_R); - if (vdc_stat & _PSB_PIPE_EVENT_FLAG) + if (vdc_stat & (_PSB_PIPE_EVENT_FLAG|_PSB_IRQ_ASLE)) dsp_int = 1; /* FIXME: Handle Medfield -- 1.8.1.4

2 4

[GIT PULL] omap display fixes for 3.10
by Tomi Valkeinen 02 May '13

02 May '13

Hi Dave, Here are a few omapdss fixes for 3.10. These are based on top of the earlier pull request I sent. The first patch is a compilation fix, the rest implement basic support for deferred probing. Support for deferred probing is needed when booting with device tree, as the probing order with DT is not the same as with non-DT, causing display initialization to fail. Tomi The following changes since commit 3d62fe5b214fce69ae14abbdb88794a753418614: OMAPDSS: Merge omapdss topic branches (2013-04-15 12:01:02 +0300) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.10-fixes for you to fetch changes up to bca3913034ef99c9cc028d054273a3b271ed62b9: OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found (2013-05-02 12:25:44 +0300) ---------------------------------------------------------------- OMAPDSS fixes for 3.10: * Compilation fix when DSI is disabled in Kconfig * Basic deferred probe support to fix DT boot ---------------------------------------------------------------- Tomi Valkeinen (17): OMAPDSS: DPI: fix compilation if DSI not compiled in OMAPDSS: Makefile: move omapfb after panels OMAPFB: use module_platform_driver() OMAPFB: defer probe if no displays OMAPDSS: DPI: use platform_driver_register() OMAPDSS: SDI: use platform_driver_register() OMAPDSS: DSI: use platform_driver_register() OMAPDSS: RFBI: use platform_driver_register() OMAPDSS: HDMI: use platform_driver_register() OMAPDSS: VENC: use platform_driver_register() OMAPDSS: DPI: Add error handling for dpi_probe_pdata OMAPDSS: SDI: Add error handling for sdi_probe_pdata OMAPDSS: DSI: Add error handling for dsi_probe_pdata OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata OMAPDSS: VENC: Add error handling for venc_probe_pdata OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found drivers/video/omap2/Makefile | 2 +- drivers/video/omap2/displays/panel-tfp410.c | 2 +- drivers/video/omap2/dss/dpi.c | 35 ++++++++++++++++++----------- drivers/video/omap2/dss/dsi.c | 35 ++++++++++++++++++----------- drivers/video/omap2/dss/dss.h | 31 +++++++++++++++++++++---- drivers/video/omap2/dss/hdmi.c | 33 +++++++++++++++++---------- drivers/video/omap2/dss/rfbi.c | 32 ++++++++++++++++---------- drivers/video/omap2/dss/sdi.c | 33 +++++++++++++++++---------- drivers/video/omap2/dss/venc.c | 33 +++++++++++++++++---------- drivers/video/omap2/omapfb/omapfb-main.c | 30 ++++--------------------- 10 files changed, 160 insertions(+), 106 deletions(-)

1 0

is someone fixing the erroneous kerneldoc content in drivers/gpu/drm/?
by Robert P. J. Day 02 May '13

02 May '13

currently running "make htmldocs" generates warnings: DOCPROC Documentation/DocBook/drm.xml Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'adapter' Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'buf' Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'block' ... etc etc ... HTML Documentation/DocBook/drm.html because some files use "\param" which is not what kerneldoc needs to see. was someone already working to clean that up? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

[Bug 64124] New: [r600g] aruba crash with 32bit applications on 64bit kernel
by bugzilla-daemon＠freedesktop.org 02 May '13

02 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=64124 Priority: medium Bug ID: 64124 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600g] aruba crash with 32bit applications on 64bit kernel Severity: normal Classification: Unclassified OS: Linux (All) Reporter: swanson(a)ukfsn.org Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 78729 --> https://bugs.freedesktop.org/attachment.cgi?id=78729&action=edit dmesg With my A10-5700 ARUBA I have a problem running 32bit applications under 64bit kernel (not tried 32bit kernel) while 64bit applications are fine. Essentially the X server crashes with a segfault after the following messages; radeon 0000:00:01.0: bo ffff88022f44b000 va 0x00000000 conflict with (bo ffff88022ee16c00 0x01F00000 0x026F8000) radeon 0000:00:01.0: bo ffff88022f44b000 don't has a mapping in vm ffff880224c97e00 radeon 0000:00:01.0: bo ffff88022f449000 va 0x00000000 conflict with (bo ffff88022ee16c00 0x01F00000 0x026F8000) radeon 0000:00:01.0: bo ffff88022f449000 don't has a mapping in vm ffff880224c97e00 radeon 0000:00:01.0: bo ffff88022ee16000 don't has a mapping in vm ffff880224c97e00 radeon 0000:00:01.0: bo ffff88022ee16400 don't has a mapping in vm ffff880224c97e00 [...REPEAT...] radeon 0000:00:01.0: bo ffff88023527c000 don't has a mapping in vm ffff880224c97e00 [CRASH] System is running; - Linux 3.9.0 with all radeon patches from drm-next-3.10-2 (but problem occurrs with standard Linux 3.8 and 3.9 too, though unknown for earlier kernels) - Current Mesa git head for both 64 and 32 bit (definitely no old libraries). -- You are receiving this mail because: You are the assignee for the bug.

1 3

Re: [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
by Daniel Vetter 02 May '13

02 May '13

On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman <mgorman(a)suse.de> wrote: > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote: >> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c >> index 6be940e..2e44733 100644 >> --- a/drivers/gpu/drm/i915/i915_gem.c >> +++ b/drivers/gpu/drm/i915/i915_gem.c >> @@ -1729,15 +1731,20 @@ i915_gem_purge(struct drm_i915_private *dev_priv, long target) >> return __i915_gem_shrink(dev_priv, target, true); >> } >> >> -static void >> +static long >> i915_gem_shrink_all(struct drm_i915_private *dev_priv) >> { >> struct drm_i915_gem_object *obj, *next; >> + long freed = 0; >> >> - i915_gem_evict_everything(dev_priv->dev); >> + freed += i915_gem_evict_everything(dev_priv->dev); >> >> - list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list, gtt_list) >> + list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list, gtt_list) { >> + if (obj->pages_pin_count == 0) >> + freed += obj->base.size >> PAGE_SHIFT; >> i915_gem_object_put_pages(obj); >> + } >> + return freed; >> } >> > > i915_gem_shrink_all is a sledge hammer! That i915_gem_evict_everything > looks like it switches to every GPU context, waits for everything to > complete and then retire it all. I don't know the details of what it's > doing but it's sounds very heavy handed and is called from shrinker > context if it fails to shrink 128 objects. Those shrinker callsback can > be very frequently called even from kswapd. i915_gem_shrink_all is our escape hatch, we only use it as a last-ditch effort when all else fails. Imo there's no point in passing the number of freed objects around from it since it really never should get called (as long as we don't get called with more objects to shrink than our counter counted beforehand at least). Also, the above hunk is broken since i915_gem_evict_everything only unbinds object from the gpu address space and puts them onto the unbound list, i.e. those objects will be double-counted. >> static int >> @@ -4205,7 +4212,8 @@ i915_gem_load(struct drm_device *dev) >> >> dev_priv->mm.interruptible = true; >> >> - dev_priv->mm.inactive_shrinker.shrink = i915_gem_inactive_shrink; >> + dev_priv->mm.inactive_shrinker.scan_objects = i915_gem_inactive_scan; >> + dev_priv->mm.inactive_shrinker.count_objects = i915_gem_inactive_count; >> dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS; >> register_shrinker(&dev_priv->mm.inactive_shrinker); >> } >> @@ -4428,8 +4436,8 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task) >> #endif >> } >> >> -static int >> -i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc) >> +static long >> +i915_gem_inactive_count(struct shrinker *shrinker, struct shrink_control *sc) >> { >> struct drm_i915_private *dev_priv = >> container_of(shrinker, >> @@ -4437,9 +4445,8 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc) >> mm.inactive_shrinker); >> struct drm_device *dev = dev_priv->dev; >> struct drm_i915_gem_object *obj; >> - int nr_to_scan = sc->nr_to_scan; >> bool unlock = true; >> - int cnt; >> + long cnt; >> >> if (!mutex_trylock(&dev->struct_mutex)) { >> if (!mutex_is_locked_by(&dev->struct_mutex, current)) >> @@ -4451,15 +4458,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc) >> unlock = false; >> } >> >> - if (nr_to_scan) { >> - nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan); >> - if (nr_to_scan > 0) >> - nr_to_scan -= __i915_gem_shrink(dev_priv, nr_to_scan, >> - false); >> - if (nr_to_scan > 0) >> - i915_gem_shrink_all(dev_priv); >> - } >> - >> cnt = 0; >> list_for_each_entry(obj, &dev_priv->mm.unbound_list, gtt_list) >> if (obj->pages_pin_count == 0) >> @@ -4472,3 +4470,36 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc) >> mutex_unlock(&dev->struct_mutex); >> return cnt; >> } >> +static long >> +i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc) >> +{ >> + struct drm_i915_private *dev_priv = >> + container_of(shrinker, >> + struct drm_i915_private, >> + mm.inactive_shrinker); >> + struct drm_device *dev = dev_priv->dev; >> + int nr_to_scan = sc->nr_to_scan; >> + long freed; >> + bool unlock = true; >> + >> + if (!mutex_trylock(&dev->struct_mutex)) { >> + if (!mutex_is_locked_by(&dev->struct_mutex, current)) >> + return 0; >> + > > return -1 if it's about preventing potential deadlocks? > >> + if (dev_priv->mm.shrinker_no_lock_stealing) >> + return 0; >> + > > same? No idea. Aside, the aggressive shrinking with shrink_all and the lock stealing madness here are to paper our current "one lock for everything" approach we have for i915 gem stuff. We've papered over the worst offenders through lock-dropping tricks while waiting, the lock stealing above plus aggressively calling shrink_all. Still it's pretty trivial to (spuriously) OOM if you compete a gpu workload with something else. Real fix is per-object locking plus some watermark limits on how many pages are locked down this way, but that's long term (and currently stalling for the wait/wound mutexes from Maarten Lankhorst to get in). > >> + unlock = false; >> + } >> + >> + freed = i915_gem_purge(dev_priv, nr_to_scan); >> + if (freed < nr_to_scan) >> + freed += __i915_gem_shrink(dev_priv, nr_to_scan, >> + false); >> + if (freed < nr_to_scan) >> + freed += i915_gem_shrink_all(dev_priv); >> + > > Do we *really* want to call i915_gem_shrink_all from the slab shrinker? > Are there any bug reports where i915 rendering jitters in low memory > situations while shrinkers might be active? Maybe it's really fast. It's terrible for interactivity in X, but we need it :( See above for how we plan to eventually fix this mess. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

server gpus: fix race between buffer evict and fbdev updates
by Dave Airlie 02 May '13

02 May '13

This stores up dirty updates to the fbdev until the next update after the buffer has finished moving, otherwise you'd see a lot of failed to reserve bo during bootup with plymouth was starting. Dave.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2013