dri-devel August 2013

dri-devel@lists.freedesktop.org

154 participants
881 discussions

[PATCH] drm/cirrus: Invalidate page tables when pinning a BO
by Michal Srb 06 Aug '13

06 Aug '13

This is a cirrus version of Egbert Eich's patch for mgag200. Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked called from ttm_bo_handle_move_mem returns with no effect. If any application accessed the memory before it was moved, it will access wrong memory next time. This causes crashes when changing resolution down. Signed-off-by: Michal Srb <msrb(a)suse.com> --- diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c b/drivers/gpu/drm/cirrus/cirrus_ttm.c index 0047012..69fd8f1 100644 --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c @@ -328,6 +328,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int align, cirrusbo->gem.driver_private = NULL; cirrusbo->bo.bdev = &cirrus->ttm.bdev; + cirrusbo->bo.bdev->dev_mapping = dev->dev_mapping; cirrus_ttm_placement(cirrusbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM);

1 0

[PATCH 0/6] drm/msm: A DRM/KMS driver for snapdragon SoCs
by Rob Clark 06 Aug '13

06 Aug '13

This patchset can also be found here, for easier browsing: http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next git://people.freedesktop.org/~robclark/linux drm-next Compared to the previous patchset (RFCv2), there are a number of fixes (leaks, etc), fixed handling of some clocks (ie. don't disable PLL that feeds a clk before disabling the clk, etc), cleaned up the handling for device specific config (with placeholders for DT bindings), etc. At this point, I have gnome-shell, wayland (weston drm compositor), etc working pretty well. In userspace, I've a libdrm branch with libdrm_freedreno updated to work on top of either this driver or the downstream android kgsl+fbdev drivers: https://github.com/freedreno/libdrm/commits/msm-drm And the DDX has been updated to either use kms with this driver, or the downstream android drivers. Note that page flipping requires kms: https://github.com/freedreno/xf86-video-freedreno/commits/msm-drm And finally mesa/gallium with a few minor tweaks, mostly updates to the loader to load on either "msm" or legacy/downstream "kgsl": https://github.com/freedreno/mesa/commits/msm-drm At this point I consider the first four patches as ready to merge. The last two add debugfs files for logging cmdstream (which is hugely useful for debugging gpu lockups), and for some basic performance monitoring. They are just RFC at this point, as there are some hacks to work around the fact that drv->load() is called *after* the debugfs initialization (so I can't grab dev->dev_private). But I'm including those two to see if anyone has any comments/suggestions. NOTES from the previous RFCs: In the current snapdragon SoC's, we have (at least) 3 different display controller blocks at play: + MDP3 - ?? seems to be what is on geeksphone peak device + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410) + MDSS - snapdragon 800 (I don't have a completely clear picture on which display controller maps to which part #) Plus a handful of blocks around them for HDMI/DSI/etc output. And on gpu side of things: + zero, one, or two 2d cores (z180) + and either a2xx or a3xx 3d core. But, HDMI/DSI/etc blocks seem like they can be shared across multiple display controller blocks. And I for sure don't want to have to deal with N different kms devices from xf86-video-freedreno. Plus, it seems like we can do some clever tricks like use GPU to trigger pageflip after rendering completes (ie. have the kms/crtc code build up gpu cmdstream to update scanout and write FLUSH register after). So, the approach is one drm driver, with some modularity. Different 'struct msm_kms' implementations, depending on display controller. And one or more 'struct msm_gpu' for the various different gpu sub- modules. The kms module provides the plane, crtc, and encoder objects, and loads whatever connectors are appropriate. For MDP4, the mapping is: plane -> PIPE{RGBn,VGn} \ crtc -> OVLP{n} + DMA{P,S,E} (??) |-> MDP "device" encoder -> DTV/LCDC/DSI (within MDP4) / connector -> HDMI/DSI/etc --> other device(s) Since the irq's that drm core mostly cares about are vblank/framedone, we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions and treat the MDP4 block's irq as "the" irq. Even though the connectors may have their own irqs which they install themselves. For this reason the display controller is the "master" device. Each connector probably ends up being a separate device, just for the logistics of finding/mapping io region, irq, etc. Idealy we would have a better way than just stashing the platform device in a global (ie. like DT super-node.. but I don't have any snapdragon hw yet that is using DT). Note that so far I've not been able to get any docs on the hw, and it seems that access to such docs would prevent me from working on the freedreno gallium driver. So there may be some mistakes in register names (I had to invent a few, since no sufficient hint was given in the downstream android fbdev driver), bitfield sizes, etc. My current state of understanding the registers is given in the envytools rnndb files at: https://github.com/freedreno/envytools/tree/master/rnndb These files are used both for a parser tool (in the same tree) to parse logged register reads/writes (both from downstream android fbdev driver, and this driver with register logging enabled), as well as to generate the register level headers. Rob Clark (6): drm/msm: add register definitions drm/msm: basic KMS driver for snapdragon drm/msm: add register definitions for gpu drm/msm: add a3xx gpu support RFC: drm/msm: add rd logging debugfs RFC: drm/msm: add perf logging debugfs drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/msm/Kconfig | 34 + drivers/gpu/drm/msm/Makefile | 32 + drivers/gpu/drm/msm/NOTES | 69 + drivers/gpu/drm/msm/adreno/a2xx.xml.h | 1438 ++++++++++++++++ drivers/gpu/drm/msm/adreno/a3xx.xml.h | 2193 ++++++++++++++++++++++++ drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 511 ++++++ drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 30 + drivers/gpu/drm/msm/adreno/adreno_common.xml.h | 432 +++++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 348 ++++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 140 ++ drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h | 254 +++ drivers/gpu/drm/msm/dsi/dsi.xml.h | 262 +++ drivers/gpu/drm/msm/dsi/mmss_cc.xml.h | 156 ++ drivers/gpu/drm/msm/dsi/sfpb.xml.h | 46 + drivers/gpu/drm/msm/hdmi/hdmi.c | 246 +++ drivers/gpu/drm/msm/hdmi/hdmi.h | 112 ++ drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 508 ++++++ drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 461 +++++ drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 281 +++ drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 141 ++ drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 214 +++ drivers/gpu/drm/msm/hdmi/qfprom.xml.h | 50 + drivers/gpu/drm/msm/mdp4/mdp4.xml.h | 1053 ++++++++++++ drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 638 +++++++ drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c | 312 ++++ drivers/gpu/drm/msm/mdp4/mdp4_format.c | 56 + drivers/gpu/drm/msm/mdp4/mdp4_irq.c | 203 +++ drivers/gpu/drm/msm/mdp4/mdp4_kms.c | 374 ++++ drivers/gpu/drm/msm/mdp4/mdp4_kms.h | 193 +++ drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 243 +++ drivers/gpu/drm/msm/msm_connector.c | 34 + drivers/gpu/drm/msm/msm_connector.h | 68 + drivers/gpu/drm/msm/msm_drv.c | 775 +++++++++ drivers/gpu/drm/msm/msm_drv.h | 224 +++ drivers/gpu/drm/msm/msm_fb.c | 202 +++ drivers/gpu/drm/msm/msm_fbdev.c | 258 +++ drivers/gpu/drm/msm/msm_gem.c | 597 +++++++ drivers/gpu/drm/msm/msm_gem.h | 100 ++ drivers/gpu/drm/msm/msm_gem_submit.c | 413 +++++ drivers/gpu/drm/msm/msm_gpu.c | 531 ++++++ drivers/gpu/drm/msm/msm_gpu.h | 147 ++ drivers/gpu/drm/msm/msm_perf.c | 270 +++ drivers/gpu/drm/msm/msm_rd.c | 334 ++++ drivers/gpu/drm/msm/msm_ringbuffer.c | 61 + drivers/gpu/drm/msm/msm_ringbuffer.h | 43 + include/uapi/drm/Kbuild | 1 + include/uapi/drm/msm_drm.h | 198 +++ 49 files changed, 15289 insertions(+) create mode 100644 drivers/gpu/drm/msm/Kconfig create mode 100644 drivers/gpu/drm/msm/Makefile create mode 100644 drivers/gpu/drm/msm/NOTES create mode 100644 drivers/gpu/drm/msm/adreno/a2xx.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a3xx.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_gpu.c create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_gpu.h create mode 100644 drivers/gpu/drm/msm/adreno/adreno_common.xml.h create mode 100644 drivers/gpu/drm/msm/adreno/adreno_gpu.c create mode 100644 drivers/gpu/drm/msm/adreno/adreno_gpu.h create mode 100644 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/sfpb.xml.h create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.c create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.h create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.xml.h create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_connector.c create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_i2c.c create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c create mode 100644 drivers/gpu/drm/msm/hdmi/qfprom.xml.h create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4.xml.h create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_format.c create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_irq.c create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_kms.c create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_kms.h create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_plane.c create mode 100644 drivers/gpu/drm/msm/msm_connector.c create mode 100644 drivers/gpu/drm/msm/msm_connector.h create mode 100644 drivers/gpu/drm/msm/msm_drv.c create mode 100644 drivers/gpu/drm/msm/msm_drv.h create mode 100644 drivers/gpu/drm/msm/msm_fb.c create mode 100644 drivers/gpu/drm/msm/msm_fbdev.c create mode 100644 drivers/gpu/drm/msm/msm_gem.c create mode 100644 drivers/gpu/drm/msm/msm_gem.h create mode 100644 drivers/gpu/drm/msm/msm_gem_submit.c create mode 100644 drivers/gpu/drm/msm/msm_gpu.c create mode 100644 drivers/gpu/drm/msm/msm_gpu.h create mode 100644 drivers/gpu/drm/msm/msm_perf.c create mode 100644 drivers/gpu/drm/msm/msm_rd.c create mode 100644 drivers/gpu/drm/msm/msm_ringbuffer.c create mode 100644 drivers/gpu/drm/msm/msm_ringbuffer.h create mode 100644 include/uapi/drm/msm_drm.h -- 1.8.3.1

2 8

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
by Rob Clark 06 Aug '13

06 Aug '13

On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey <tom.cooksey(a)arm.com> wrote: > Hi Rob, > > +linux-media, +linaro-mm-sig for discussion of video/camera > buffer constraints... > > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey <tom.cooksey(a)arm.com> >> wrote: >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also >> >> > allocate buffers for the GPU. Still not sure how to resolve >> >> > this as we don't use DRM for our GPU driver. >> >> >> >> any thoughts/plans about a DRM GPU driver? Ideally long term (esp. >> >> once the dma-fence stuff is in place), we'd have gpu-specific drm >> >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver, >> >> using prime/dmabuf to share between the two. >> > >> > The "extra" buffers we were allocating from armsoc DDX were really >> > being allocated through DRM/GEM so we could get an flink name >> > for them and pass a reference to them back to our GPU driver on >> > the client side. If it weren't for our need to access those >> > extra off-screen buffers with the GPU we wouldn't need to >> > allocate them with DRM at all. So, given they are really "GPU" >> > buffers, it does absolutely make sense to allocate them in a >> > different driver to the display driver. >> > >> > However, to avoid unnecessary memcpys & related cache >> > maintenance ops, we'd also like the GPU to render into buffers >> > which are scanned out by the display controller. So let's say >> > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan >> > out buffers with the display's DRM driver but a custom ioctl >> > on the GPU's DRM driver to allocate non scanout, off-screen >> > buffers. Sounds great, but I don't think that really works >> > with DRI2. If we used two drivers to allocate buffers, which >> > of those drivers do we return in DRI2ConnectReply? Even if we >> > solve that somehow, GEM flink names are name-spaced to a >> > single device node (AFAIK). So when we do a DRI2GetBuffers, >> > how does the EGL in the client know which DRM device owns GEM >> > flink name "1234"? We'd need some pretty dirty hacks. >> >> You would return the name of the display driver allocating the >> buffers. On the client side you can use generic ioctls to go from >> flink -> handle -> dmabuf. So the client side would end up opening >> both the display drm device and the gpu, but without needing to know >> too much about the display. > > I think the bit I was missing was that a GEM bo for a buffer imported > using dma_buf/PRIME can still be flink'd. So the display controller's > DRM driver allocates scan-out buffers via the DUMB buffer allocate > ioctl. Those scan-out buffers than then be exported from the > dispaly's DRM driver and imported into the GPU's DRM driver using > PRIME. Once imported into the GPU's driver, we can use flink to get a > name for that buffer within the GPU DRM driver's name-space to return > to the DRI2 client. That same namespace is also what DRI2 back-buffers > are allocated from, so I think that could work... Except... > (and.. the general direction is that things will move more to just use dmabuf directly, ie. wayland or dri3) > >> > Anyway, that latter case also gets quite difficult. The "GPU" >> > DRM driver would need to know the constraints of the display >> > controller when allocating buffers intended to be scanned out. >> > For example, pl111 typically isn't behind an IOMMU and so >> > requires physically contiguous memory. We'd have to teach the >> > GPU's DRM driver about the constraints of the display HW. Not >> > exactly a clean driver model. :-( >> > >> > I'm still a little stuck on how to proceed, so any ideas >> > would greatly appreciated! My current train of thought is >> > having a kind of SoC-specific DRM driver which allocates >> > buffers for both display and GPU within a single GEM >> > namespace. That SoC-specific DRM driver could then know the >> > constraints of both the GPU and the display HW. We could then >> > use PRIME to export buffers allocated with the SoC DRM driver >> > and import them into the GPU and/or display DRM driver. >> >> Usually if the display drm driver is allocating the buffers that might >> be scanned out, it just needs to have minimal knowledge of the GPU >> (pitch alignment constraints). I don't think we need a 3rd device >> just to allocate buffers. > > While Mali can render to pretty much any buffer, there is a mild > performance improvement to be had if the buffer stride is aligned to > the AXI bus's max burst length when drawing to the buffer. I suspect the display controllers might frequently benefit if the pitch is aligned to AXI burst length too.. > So in some respects, there is a constraint on how buffers which will > be drawn to using the GPU are allocated. I don't really like the idea > of teaching the display controller DRM driver about the GPU buffer > constraints, even if they are fairly trivial like this. If the same > display HW IP is being used on several SoCs, it seems wrong somehow > to enforce those GPU constraints if some of those SoCs don't have a > GPU. Well, I suppose you could get min_pitch_alignment from devicetree, or something like this.. In the end, the easy solution is just to make the display allocate to the worst-case pitch alignment. In the early days of dma-buf discussions, we kicked around the idea of negotiating or programatically describing the constraints, but that didn't really seem like a bounded problem. > We may also then have additional constraints when sharing buffers > between the display HW and video decode or even camera ISP HW. > Programmatically describing buffer allocation constraints is very > difficult and I'm not sure you can actually do it - there's some > pretty complex constraints out there! E.g. I believe there's a > platform where Y and UV planes of the reference frame need to be in > separate DRAM banks for real-time 1080p decode, or something like > that? yes, this was discussed. This is different from pitch/format/size constraints.. it is really just a placement constraint (ie. where do the physical pages go). IIRC the conclusion was to use a dummy devices with it's own CMA pool for attaching the Y vs UV buffers. > Anyway, I guess my point is that even if we solve how to allocate > buffers which will be shared between the GPU and display HW such that > both sets of constraints are satisfied, that may not be the end of > the story. > that was part of the reason to punt this problem to userspace ;-) In practice, the kernel drivers doesn't usually know too much about the dimensions/format/etc.. that is really userspace level knowledge. There are a few exceptions when the kernel needs to know how to setup GTT/etc for tiled buffers, but normally this sort of information is up at the next level up (userspace, and drm_framebuffer in case of scanout). Userspace media frameworks like GStreamer already have a concept of format/caps negotiation. For non-display<->gpu sharing, I think this is probably where this sort of constraint negotiation should be handled. BR, -R > > Cheers, > > Tom > > > > >

2 1

[PATCH 0/4] DRM: Remove MM "Pre-Alloc"
by David Herrmann 06 Aug '13

06 Aug '13

Hi See patch 4/4 for a more detailed explanation of this series. I basically kill off the whole drm_mm pre-alloc code as it really doesn't make any sense with todays infrastructure. No drm_mm user runs in atomic context. We use pre-alloc only to allow allocation while holding a spin-lock. But we can easily kzalloc() the node before taking the spinlock and use the drm_mm_insert_*() helpers directly. This series converts the last pre-alloc users (ttm and i915-gem-stolen) to use the already established kzalloc()+drm_mm_insert_*() helpers. The last patch removes a bunch of old drm_mm code, so Daniel can tackle his "drm_mm documentation" TODO list. Cheers David David Herrmann (4): drm/mm: add "best_match" to drm_mm_insert_node() drm/ttm: replace drm_mm_pre_get() by direct alloc drm/i915: pre-alloc instead of drm_mm search/get_block drm/mm: remove unused API drivers/gpu/drm/drm_mm.c | 183 +++++---------------------------- drivers/gpu/drm/drm_vma_manager.c | 4 +- drivers/gpu/drm/i915/i915_gem.c | 3 +- drivers/gpu/drm/i915/i915_gem_stolen.c | 72 ++++++++----- drivers/gpu/drm/sis/sis_mm.c | 4 +- drivers/gpu/drm/ttm/ttm_bo_manager.c | 40 ++++--- drivers/gpu/drm/via/via_mm.c | 4 +- include/drm/drm_mm.h | 131 +++++------------------ 8 files changed, 123 insertions(+), 318 deletions(-) -- 1.8.3.3

3 20

[PATCH v3] drm/exynos: Add fallback option to get non physically continous memory for fb
by Vikas Sajjan 06 Aug '13

06 Aug '13

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel connected with resolution 2560x1600, following error occured even with IOMMU enabled: [0.880000] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer. [0.890000] [drm] Initialized exynos 1.0.0 20110530 on minor 0 To address the cases where physically continous memory MAY NOT be a mandatory requirement for fb, the patch adds a feature to get non physically continous memory for fb if IOMMU is supported and if CONTIG memory allocation fails. Signed-off-by: Vikas Sajjan <vikas.sajjan(a)linaro.org> Signed-off-by: Arun Kumar <arun.kk(a)samsung.com> Reviewed-by: Rob Clark <robdclark(a)gmail.com> --- changes since v2: - addressed comments given by Tomasz Figa <tomasz.figa(a)gmail.com>. changes since v1: - Modified to add the fallback patch if CONTIG alloc fails as suggested by Rob Clark robdclark(a)gmail.com and Tomasz Figa <tomasz.figa(a)gmail.com>. - changed the commit message. --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..faec77e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -16,6 +16,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_fb_helper.h> #include <drm/drm_crtc_helper.h> +#include <drm/exynos_drm.h> #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" @@ -165,8 +166,17 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height; - /* 0 means to allocate physically continuous memory */ - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size); + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size); + /* + * If IOMMU is supported then try to get buffer from non physically + * continous memory area. + */ + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) { + dev_warn(&pdev->dev, "contiguous FB allocation failed, falling back to non-contiguous\n"); + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG, + size); + } + if (IS_ERR(exynos_gem_obj)) { ret = PTR_ERR(exynos_gem_obj); goto err_release_framebuffer; -- 1.7.9.5

3 2

linux-next: manual merge of the akpm tree with the drm-intel tree
by Stephen Rothwell 06 Aug '13

06 Aug '13

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in drivers/gpu/drm/i915/i915_gem.c between commit a70a3148b0c6 ("drm/i915: Make proper functions for VMs") from the drm-intel tree and commit e6950216e0af ("drivers: convert shrinkers to new count/scan API") from the akpm tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au diff --cc drivers/gpu/drm/i915/i915_gem.c index d31e15d,49db617..0000000 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@@ -4642,10 -4626,10 +4650,9 @@@ i915_gem_inactive_count(struct shrinke struct drm_i915_private, mm.inactive_shrinker); struct drm_device *dev = dev_priv->dev; - struct i915_address_space *vm = &dev_priv->gtt.base; 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)) @@@ -4683,75 -4653,36 +4681,109 @@@ 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; + + if (dev_priv->mm.shrinker_no_lock_stealing) + return 0; + + 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); + + if (unlock) + mutex_unlock(&dev->struct_mutex); + return freed; + } ++ +/* All the new VM stuff */ +unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o, + struct i915_address_space *vm) +{ + struct drm_i915_private *dev_priv = o->base.dev->dev_private; + struct i915_vma *vma; + + if (vm == &dev_priv->mm.aliasing_ppgtt->base) + vm = &dev_priv->gtt.base; + + BUG_ON(list_empty(&o->vma_list)); + list_for_each_entry(vma, &o->vma_list, vma_link) { + if (vma->vm == vm) + return vma->node.start; + + } + return -1; +} + +bool i915_gem_obj_bound(struct drm_i915_gem_object *o, + struct i915_address_space *vm) +{ + struct i915_vma *vma; + + list_for_each_entry(vma, &o->vma_list, vma_link) + if (vma->vm == vm) + return true; + + return false; +} + +bool i915_gem_obj_bound_any(struct drm_i915_gem_object *o) +{ + struct drm_i915_private *dev_priv = o->base.dev->dev_private; + struct i915_address_space *vm; + + list_for_each_entry(vm, &dev_priv->vm_list, global_link) + if (i915_gem_obj_bound(o, vm)) + return true; + + return false; +} + +unsigned long i915_gem_obj_size(struct drm_i915_gem_object *o, + struct i915_address_space *vm) +{ + struct drm_i915_private *dev_priv = o->base.dev->dev_private; + struct i915_vma *vma; + + if (vm == &dev_priv->mm.aliasing_ppgtt->base) + vm = &dev_priv->gtt.base; + + BUG_ON(list_empty(&o->vma_list)); + + list_for_each_entry(vma, &o->vma_list, vma_link) + if (vma->vm == vm) + return vma->node.size; + + return 0; +} + +struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj, + struct i915_address_space *vm) +{ + struct i915_vma *vma; + list_for_each_entry(vma, &obj->vma_list, vma_link) + if (vma->vm == vm) + return vma; + + return NULL; +}

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 06 Aug '13

06 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=42162 Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #83689|0 |1 is obsolete| | --- Comment #22 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- Created attachment 83693 --> https://bugs.freedesktop.org/attachment.cgi?id=83693&action=edit 3.11-rc3 suspend/resume, both cards powered up before suspend Including previously missing REDWOOD_smc.bin changes the log slightly. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 06 Aug '13

06 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #21 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- Comment on attachment 83689 --> https://bugs.freedesktop.org/attachment.cgi?id=83689 3.11-rc3 suspend/resume, both cards powered up before suspend >Aug 6 00:14:53 mars kernel: [ 143.123335] PM: Syncing filesystems ... done. >Aug 6 00:15:18 mars kernel: [ 143.265460] Freezing user space processes ... (elapsed 0.001 seconds) done. >Aug 6 00:15:18 mars kernel: [ 143.267108] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. >Aug 6 00:15:18 mars kernel: [ 143.268729] Suspending console(s) (use no_console_suspend to debug) >Aug 6 00:15:18 mars kernel: [ 143.269239] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated >Aug 6 00:15:18 mars kernel: [ 143.269245] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) >Aug 6 00:15:18 mars kernel: [ 143.269247] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) >Aug 6 00:15:18 mars kernel: [ 143.297269] sd 0:0:0:0: [sda] Synchronizing SCSI cache >Aug 6 00:15:18 mars kernel: [ 143.297339] cfg80211: Calling CRDA to update world regulatory domain >Aug 6 00:15:18 mars kernel: [ 143.297341] sd 0:0:0:0: [sda] Stopping disk >Aug 6 00:15:18 mars kernel: [ 143.387143] i8042 aux 00:07: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 143.387217] i8042 kbd 00:06: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.703766] PM: suspend of devices complete after 1434.453 msecs >Aug 6 00:15:18 mars kernel: [ 144.704050] PM: late suspend of devices complete after 0.279 msecs >Aug 6 00:15:18 mars kernel: [ 144.705302] pcieport 0000:00:06.0: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.735807] ehci-pci 0000:00:16.2: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.751774] ehci-pci 0000:00:13.2: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.767674] ohci-pci 0000:00:13.0: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.767707] ehci-pci 0000:00:12.2: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.783677] ohci-pci 0000:00:12.0: System wakeup enabled by ACPI >Aug 6 00:15:18 mars kernel: [ 144.783802] PM: noirq suspend of devices complete after 79.730 msecs >Aug 6 00:15:18 mars kernel: [ 144.783866] ACPI: Preparing to enter system sleep state S3 >Aug 6 00:15:18 mars kernel: [ 144.793732] PM: Saving platform NVS memory >Aug 6 00:15:18 mars kernel: [ 144.798121] Disabling non-boot CPUs ... >Aug 6 00:15:18 mars kernel: [ 144.798530] Broke affinity for irq 19 >Aug 6 00:15:18 mars kernel: [ 144.799604] smpboot: CPU 1 is now offline >Aug 6 00:15:18 mars kernel: [ 144.903635] smpboot: CPU 2 is now offline >Aug 6 00:15:18 mars kernel: [ 144.904260] Broke affinity for irq 17 >Aug 6 00:15:18 mars kernel: [ 145.007704] smpboot: CPU 3 is now offline >Aug 6 00:15:18 mars kernel: [ 145.008505] ACPI: Low-level resume complete >Aug 6 00:15:18 mars kernel: [ 145.008555] PM: Restoring platform NVS memory >Aug 6 00:15:18 mars kernel: [ 145.010313] PCI-DMA: Resuming GART IOMMU >Aug 6 00:15:18 mars kernel: [ 145.010314] PCI-DMA: Restoring GART aperture settings >Aug 6 00:15:18 mars kernel: [ 145.010614] Enabling non-boot CPUs ... >Aug 6 00:15:18 mars kernel: [ 145.010663] smpboot: Booting Node 0 Processor 1 APIC 0x1 >Aug 6 00:15:18 mars kernel: [ 145.021636] [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu >Aug 6 00:15:18 mars kernel: [ 145.021638] perf: IBS APIC setup failed on cpu #1 >Aug 6 00:15:18 mars kernel: [ 145.023788] process: Switch to broadcast mode on CPU1 >Aug 6 00:15:18 mars kernel: [ 145.024075] CPU1 is up >Aug 6 00:15:18 mars kernel: [ 145.024094] smpboot: Booting Node 0 Processor 2 APIC 0x2 >Aug 6 00:15:18 mars kernel: [ 145.035062] [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu >Aug 6 00:15:18 mars kernel: [ 145.035064] perf: IBS APIC setup failed on cpu #2 >Aug 6 00:15:18 mars kernel: [ 145.037208] process: Switch to broadcast mode on CPU2 >Aug 6 00:15:18 mars kernel: [ 145.037422] CPU2 is up >Aug 6 00:15:18 mars kernel: [ 145.037440] smpboot: Booting Node 0 Processor 3 APIC 0x3 >Aug 6 00:15:18 mars kernel: [ 145.037956] ------------[ cut here ]------------ >Aug 6 00:15:18 mars kernel: [ 145.037967] WARNING: CPU: 2 PID: 0 at /home/apw/COD/linux/kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x18c/0x1a0() >Aug 6 00:15:18 mars kernel: [ 145.038014] Modules linked in: arc4 brcmsmac cordic brcmutil b43 mac80211 cfg80211 joydev ssb hp_wmi sparse_keymap snd_hda_codec_hdmi snd_hda_codec_idt snd_seq_midi snd_hda_intel dm_multipath snd_hda_codec snd_seq_midi_event scsi_dh snd_hwdep snd_pcm snd_rawmidi psmouse uvcvideo edac_core edac_mce_amd k10temp videobuf2_vmalloc sp5100_tco videobuf2_memops serio_raw videobuf2_core videodev snd_page_alloc i2c_piix4 snd_seq snd_seq_device snd_timer bcma snd hp_accel lis3lv02d input_polldev soundcore shpchp parport_pc bnep rfcomm ppdev mac_hid bluetooth lp parport binfmt_misc btrfs xor zlib_deflate raid6_pq libcrc32c dm_mirror dm_region_hash dm_log radeon r8169 i2c_algo_bit video ttm drm_kms_helper mii drm ahci libahci wmi >Aug 6 00:15:18 mars kernel: [ 145.038017] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-031100rc3-generic #201307290035 >Aug 6 00:15:18 mars kernel: [ 145.038018] Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/1440, BIOS F.14 09/10/2010 >Aug 6 00:15:18 mars kernel: [ 145.038022] 000000000000029b ffff880196c91da8 ffffffff8171e4fb ffffffff81c380e8 >Aug 6 00:15:18 mars kernel: [ 145.038024] 0000000000000000 ffff880196c91de8 ffffffff8106532c 0000000000000000 >Aug 6 00:15:18 mars kernel: [ 145.038026] 0000000000000002 0000000000000086 ffffffff81c25780 ffff88019fd0dcc0 >Aug 6 00:15:18 mars kernel: [ 145.038027] Call Trace: >Aug 6 00:15:18 mars kernel: [ 145.038033] [<ffffffff8171e4fb>] dump_stack+0x46/0x58 >Aug 6 00:15:18 mars kernel: [ 145.038036] [<ffffffff8106532c>] warn_slowpath_common+0x8c/0xc0 >Aug 6 00:15:18 mars kernel: [ 145.038038] [<ffffffff8106537a>] warn_slowpath_null+0x1a/0x20 >Aug 6 00:15:18 mars kernel: [ 145.038041] [<ffffffff810c4afc>] tick_broadcast_oneshot_control+0x18c/0x1a0 >Aug 6 00:15:18 mars kernel: [ 145.038044] [<ffffffff810c2fa8>] clockevents_notify+0x1c8/0x200 >Aug 6 00:15:18 mars kernel: [ 145.038047] [<ffffffff8101c905>] amd_e400_idle+0x75/0x100 >Aug 6 00:15:18 mars kernel: [ 145.038050] [<ffffffff8101d066>] arch_cpu_idle+0x26/0x30 >Aug 6 00:15:18 mars kernel: [ 145.038053] [<ffffffff810ba5fe>] cpu_idle_loop+0x7e/0x250 >Aug 6 00:15:18 mars kernel: [ 145.038055] [<ffffffff810ba83b>] cpu_startup_entry+0x6b/0x70 >Aug 6 00:15:18 mars kernel: [ 145.038059] [<ffffffff81041fb8>] start_secondary+0xc8/0xd0 >Aug 6 00:15:18 mars kernel: [ 145.038061] ---[ end trace 8e8458fd39f3bee8 ]--- >Aug 6 00:15:18 mars kernel: [ 145.048405] [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu >Aug 6 00:15:18 mars kernel: [ 145.048407] perf: IBS APIC setup failed on cpu #3 >Aug 6 00:15:18 mars kernel: [ 145.050583] process: Switch to broadcast mode on CPU3 >Aug 6 00:15:18 mars kernel: [ 145.050818] CPU3 is up >Aug 6 00:15:18 mars kernel: [ 145.052350] ACPI: Waking up from system sleep state S3 >Aug 6 00:15:18 mars kernel: [ 145.062962] ohci-pci 0000:00:12.0: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.078070] ehci-pci 0000:00:12.2: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.078102] ohci-pci 0000:00:13.0: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.094073] ehci-pci 0000:00:13.2: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.126080] ehci-pci 0000:00:16.2: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.206232] PM: noirq resume of devices complete after 143.426 msecs >Aug 6 00:15:18 mars kernel: [ 145.206454] PM: early resume of devices complete after 0.158 msecs >Aug 6 00:15:18 mars kernel: [ 145.212236] snd_hda_intel 0000:02:00.1: irq 44 for MSI/MSI-X >Aug 6 00:15:18 mars kernel: [ 145.213099] pcieport 0000:00:06.0: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.220381] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000). >Aug 6 00:15:18 mars kernel: [ 145.220535] radeon 0000:01:05.0: WB enabled >Aug 6 00:15:18 mars kernel: [ 145.220538] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff88018faabc00 >Aug 6 00:15:18 mars kernel: [ 145.220540] radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff88018faabc0c >Aug 6 00:15:18 mars kernel: [ 145.220839] radeon 0000:01:05.0: setting latency timer to 64 >Aug 6 00:15:18 mars kernel: [ 145.252689] [drm] ring test on 0 succeeded in 0 usecs >Aug 6 00:15:18 mars kernel: [ 145.252747] [drm] ring test on 3 succeeded in 1 usecs >Aug 6 00:15:18 mars kernel: [ 145.252782] [drm] ib test on ring 0 succeeded in 0 usecs >Aug 6 00:15:18 mars kernel: [ 145.252800] [drm] ib test on ring 3 succeeded in 1 usecs >Aug 6 00:15:18 mars kernel: [ 145.254635] switching from power state: >Aug 6 00:15:18 mars kernel: [ 145.254638] ui class: none >Aug 6 00:15:18 mars kernel: [ 145.254639] internal class: boot >Aug 6 00:15:18 mars kernel: [ 145.254640] caps: >Aug 6 00:15:18 mars kernel: [ 145.254642] uvd vclk: 0 dclk: 0 >Aug 6 00:15:18 mars kernel: [ 145.254643] power level 0 sclk: 50000 vddc_index: 2 >Aug 6 00:15:18 mars kernel: [ 145.254644] power level 1 sclk: 50000 vddc_index: 2 >Aug 6 00:15:18 mars kernel: [ 145.254645] status: c b >Aug 6 00:15:18 mars kernel: [ 145.254646] switching to power state: >Aug 6 00:15:18 mars kernel: [ 145.254647] ui class: battery >Aug 6 00:15:18 mars kernel: [ 145.254648] internal class: none >Aug 6 00:15:18 mars kernel: [ 145.254648] caps: single_disp >Aug 6 00:15:18 mars kernel: [ 145.254649] uvd vclk: 0 dclk: 0 >Aug 6 00:15:18 mars kernel: [ 145.254650] power level 0 sclk: 20000 vddc_index: 1 >Aug 6 00:15:18 mars kernel: [ 145.254650] power level 1 sclk: 20000 vddc_index: 1 >Aug 6 00:15:18 mars kernel: [ 145.254651] status: r >Aug 6 00:15:18 mars kernel: [ 145.274368] r8169 0000:04:00.0 eth0: link down >Aug 6 00:15:18 mars kernel: [ 145.274573] i8042 kbd 00:06: System wakeup disabled by ACPI >Aug 6 00:15:18 mars kernel: [ 145.290499] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 >Aug 6 00:15:18 mars kernel: [ 145.290516] [drm] Loading REDWOOD Microcode >Aug 6 00:15:18 mars kernel: [ 145.290527] ------------[ cut here ]------------ >Aug 6 00:15:18 mars kernel: [ 145.290536] WARNING: CPU: 1 PID: 3002 at /home/apw/COD/linux/drivers/base/firmware_class.c:1082 _request_firmware+0x194/0x1b0() >Aug 6 00:15:18 mars kernel: [ 145.290579] Modules linked in: arc4 brcmsmac cordic brcmutil b43 mac80211 cfg80211 joydev ssb hp_wmi sparse_keymap snd_hda_codec_hdmi snd_hda_codec_idt snd_seq_midi snd_hda_intel dm_multipath snd_hda_codec snd_seq_midi_event scsi_dh snd_hwdep snd_pcm snd_rawmidi psmouse uvcvideo edac_core edac_mce_amd k10temp videobuf2_vmalloc sp5100_tco videobuf2_memops serio_raw videobuf2_core videodev snd_page_alloc i2c_piix4 snd_seq snd_seq_device snd_timer bcma snd hp_accel lis3lv02d input_polldev soundcore shpchp parport_pc bnep rfcomm ppdev mac_hid bluetooth lp parport binfmt_misc btrfs xor zlib_deflate raid6_pq libcrc32c dm_mirror dm_region_hash dm_log radeon r8169 i2c_algo_bit video ttm drm_kms_helper mii drm ahci libahci wmi >Aug 6 00:15:18 mars kernel: [ 145.290583] CPU: 1 PID: 3002 Comm: kworker/u8:16 Tainted: G W 3.11.0-031100rc3-generic #201307290035 >Aug 6 00:15:18 mars kernel: [ 145.290584] Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/1440, BIOS F.14 09/10/2010 >Aug 6 00:15:18 mars kernel: [ 145.290590] Workqueue: events_unbound async_run_entry_fn >Aug 6 00:15:18 mars kernel: [ 145.290593] 000000000000043a ffff88018fb9bac8 ffffffff8171e4fb 0000000000001a2a >Aug 6 00:15:18 mars kernel: [ 145.290595] 0000000000000000 ffff88018fb9bb08 ffffffff8106532c ffff88018fb9bb18 >Aug 6 00:15:18 mars kernel: [ 145.290597] ffff88018f2dddf0 ffff880196eef098 ffff88018fb9bbe2 0000000000003a98 >Aug 6 00:15:18 mars kernel: [ 145.290598] Call Trace: >Aug 6 00:15:18 mars kernel: [ 145.290603] [<ffffffff8171e4fb>] dump_stack+0x46/0x58 >Aug 6 00:15:18 mars kernel: [ 145.290607] [<ffffffff8106532c>] warn_slowpath_common+0x8c/0xc0 >Aug 6 00:15:18 mars kernel: [ 145.290609] [<ffffffff8106537a>] warn_slowpath_null+0x1a/0x20 >Aug 6 00:15:18 mars kernel: [ 145.290611] [<ffffffff81497c44>] _request_firmware+0x194/0x1b0 >Aug 6 00:15:18 mars kernel: [ 145.290616] [<ffffffff81497cff>] request_firmware+0x3f/0x60 >Aug 6 00:15:18 mars kernel: [ 145.290662] [<ffffffffa013d17e>] r600_init_microcode+0x56e/0x620 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290696] [<ffffffffa015ca38>] evergreen_startup+0x338/0x4d0 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290726] [<ffffffffa0154711>] ? evergreen_init_golden_registers+0xe1/0x200 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290756] [<ffffffffa015cf10>] evergreen_resume+0x40/0x90 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290776] [<ffffffffa00f25f6>] radeon_resume_kms+0x76/0x1a0 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290795] [<ffffffffa00d70cd>] radeon_pci_resume+0x1d/0x20 [radeon] >Aug 6 00:15:18 mars kernel: [ 145.290799] [<ffffffff8139f8b1>] pci_legacy_resume+0x41/0x60 >Aug 6 00:15:18 mars kernel: [ 145.290802] [<ffffffff813a03b8>] pci_pm_resume+0x98/0xe0 >Aug 6 00:15:18 mars kernel: [ 145.290804] [<ffffffff813a0320>] ? pci_pm_thaw+0x80/0x80 >Aug 6 00:15:18 mars kernel: [ 145.290807] [<ffffffff8148f139>] dpm_run_callback+0x39/0x60 >Aug 6 00:15:18 mars kernel: [ 145.290810] [<ffffffff8148f429>] device_resume+0xa9/0x190 >Aug 6 00:15:18 mars kernel: [ 145.290812] [<ffffffff8148f531>] async_resume+0x21/0x50 >Aug 6 00:15:18 mars kernel: [ 145.290815] [<ffffffff81093d9b>] async_run_entry_fn+0x3b/0x140 >Aug 6 00:15:18 mars kernel: [ 145.290817] [<ffffffff810849a0>] process_one_work+0x170/0x4a0 >Aug 6 00:15:18 mars kernel: [ 145.290820] [<ffffffff81085a61>] worker_thread+0x121/0x390 >Aug 6 00:15:18 mars kernel: [ 145.290822] [<ffffffff81085940>] ? manage_workers.isra.20+0x170/0x170 >Aug 6 00:15:18 mars kernel: [ 145.290825] [<ffffffff8108c8d0>] kthread+0xc0/0xd0 >Aug 6 00:15:18 mars kernel: [ 145.290828] [<ffffffff8108c810>] ? flush_kthread_worker+0xb0/0xb0 >Aug 6 00:15:18 mars kernel: [ 145.290830] [<ffffffff81732eec>] ret_from_fork+0x7c/0xb0 >Aug 6 00:15:18 mars kernel: [ 145.290833] [<ffffffff8108c810>] ? flush_kthread_worker+0xb0/0xb0 >Aug 6 00:15:18 mars kernel: [ 145.290835] ---[ end trace 8e8458fd39f3bee9 ]--- >Aug 6 00:15:18 mars kernel: [ 145.290838] radeon 0000:02:00.0: firmware: radeon/REDWOOD_smc.bin will not be loaded >Aug 6 00:15:18 mars kernel: [ 145.290841] r600_cp: Failed to load firmware "radeon/REDWOOD_smc.bin" >Aug 6 00:15:18 mars kernel: [ 145.290843] [drm:evergreen_startup] *ERROR* Failed to load firmware! >Aug 6 00:15:18 mars kernel: [ 145.290844] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume >Aug 6 00:15:18 mars kernel: [ 145.291183] [drm:cypress_dpm_enable] *ERROR* rv770_upload_firmware failed >Aug 6 00:15:18 mars kernel: [ 145.291184] [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed >Aug 6 00:15:18 mars kernel: [ 145.434108] usb 6-1: reset full-speed USB device number 2 using ohci-pci >Aug 6 00:15:18 mars kernel: [ 145.534146] ata4: SATA link down (SStatus 0 SControl 300) >Aug 6 00:15:18 mars kernel: [ 145.706273] usb 1-3: reset high-speed USB device number 2 using ehci-pci >Aug 6 00:15:18 mars kernel: [ 145.706279] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >Aug 6 00:15:18 mars kernel: [ 145.710161] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) >Aug 6 00:15:18 mars kernel: [ 145.726931] ata1.00: configured for UDMA/133 >Aug 6 00:15:18 mars kernel: [ 145.728941] ata2.00: configured for UDMA/100 >Aug 6 00:15:18 mars kernel: [ 145.746865] sd 0:0:0:0: [sda] Starting disk >Aug 6 00:15:18 mars kernel: [ 154.646773] PM: resume of devices complete after 9438.155 msecs >Aug 6 00:15:18 mars rtkit-daemon[1849]: The canary thread is apparently starving. Taking action. >Aug 6 00:15:18 mars rtkit-daemon[1849]: Demoting known real-time threads. >Aug 6 00:15:18 mars rtkit-daemon[1849]: Successfully demoted thread 1854 of process 1846 (n/a). >Aug 6 00:15:18 mars rtkit-daemon[1849]: Successfully demoted thread 1853 of process 1846 (n/a). >Aug 6 00:15:18 mars rtkit-daemon[1849]: Successfully demoted thread 1852 of process 1846 (n/a). >Aug 6 00:15:18 mars rtkit-daemon[1849]: Successfully demoted thread 1846 of process 1846 (n/a). >Aug 6 00:15:18 mars rtkit-daemon[1849]: Demoted 4 threads. >Aug 6 00:15:18 mars acpid: client 1333[0:0] has disconnected >Aug 6 00:15:18 mars kernel: [ 154.655659] Restarting tasks ... done. >Aug 6 00:15:18 mars kernel: [ 154.677972] video LNXVIDEO:00: Restoring backlight state >Aug 6 00:15:18 mars kernel: [ 154.679920] video LNXVIDEO:01: Restoring backlight state >Aug 6 00:15:18 mars acpid: client connected from 1333[0:0] >Aug 6 00:15:18 mars acpid: 1 client rule loaded >Aug 6 00:15:18 mars anacron[3134]: Anacron 2.3 started on 2013-08-06 >Aug 6 00:15:18 mars anacron[3134]: Will run job `cron.daily' in 5 min. >Aug 6 00:15:18 mars anacron[3134]: Jobs will be executed sequentially >Aug 6 00:15:24 mars acpid: client 1333[0:0] has disconnected >Aug 6 00:15:24 mars acpid: client connected from 1333[0:0] >Aug 6 00:15:24 mars acpid: 1 client rule loaded -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 06 Aug '13

06 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #20 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- Created attachment 83689 --> https://bugs.freedesktop.org/attachment.cgi?id=83689&action=edit 3.11-rc3 suspend/resume, both cards powered up before suspend -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 06 Aug '13

06 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #19 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- I just tried 3.11-rc3, with the important difference that I kept both cards active when suspending. When resuming, the backlight now came on for a second but the screen then turned dark again. Looking at the logs, the failure now seems less catastrophic than before. Could it be that if I disable one card before suspending (using vgaswitcheroo), the resume code unsuccessfully tries to power up the previously disabled card? Also, I don't seem to get any dpm options in /sys for the discrete card (the 5650), but that's a separate bug I guess. -- You are receiving this mail because: You are the assignee for the bug.

1 0

← Newer
1
...
81
82
83
84
85
86
87
88
89
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2013