dri-devel November 2012

dri-devel@lists.freedesktop.org

126 participants
797 discussions

[PATCH] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware
by j.glisse＠gmail.com 27 Nov '12

27 Nov '12

From: Jerome Glisse <jglisse(a)redhat.com> This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc mapping. Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++++++++++++--------------------- 1 file changed, 20 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 3bce029..7c1f080 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1696,42 +1696,28 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc) return ATOM_PPLL2; DRM_ERROR("unable to allocate a PPLL\n"); return ATOM_PPLL_INVALID; - } else if (ASIC_IS_AVIVO(rdev)) { - /* in DP mode, the DP ref clock can come from either PPLL - * depending on the asic: - * DCE3: PPLL1 or PPLL2 - */ - if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) { - /* use the same PPLL for all DP monitors */ - pll = radeon_get_shared_dp_ppll(crtc); - if (pll != ATOM_PPLL_INVALID) - return pll; - } else { - /* use the same PPLL for all monitors with the same clock */ - pll = radeon_get_shared_nondp_ppll(crtc); - if (pll != ATOM_PPLL_INVALID) - return pll; - } - /* all other cases */ - pll_in_use = radeon_get_pll_use_mask(crtc); - /* the order shouldn't matter here, but we probably - * need this until we have atomic modeset - */ - if (rdev->flags & RADEON_IS_IGP) { - if (!(pll_in_use & (1 << ATOM_PPLL1))) - return ATOM_PPLL1; - if (!(pll_in_use & (1 << ATOM_PPLL2))) - return ATOM_PPLL2; - } else { - if (!(pll_in_use & (1 << ATOM_PPLL2))) - return ATOM_PPLL2; - if (!(pll_in_use & (1 << ATOM_PPLL1))) - return ATOM_PPLL1; - } - DRM_ERROR("unable to allocate a PPLL\n"); - return ATOM_PPLL_INVALID; } else { /* on pre-R5xx asics, the crtc to pll mapping is hardcoded */ + /* some atombios (observed in some DCE2/DCE3) code have a bug, + * the matching btw pll and crtc is done through + * PCLK_CRTC[1|2]_CNTL (0x480/0x484) but atombios code use the + * pll (1 or 2) to select which register to write. ie if using + * pll1 it will use PCLK_CRTC1_CNTL (0x480) and if using pll2 + * it will use PCLK_CRTC2_CNTL (0x484), it then use crtc id to + * choose which value to write. Which is reverse order from + * register logic. So only case that works is when pllid is + * same as crtcid or when both pll and crtc are enabled and + * both use same clock. + * + * So just return crtc id as if crtc and pll were hard linked + * together even if they aren't + */ + if (radeon_crtc->crtc_id > 1) { + /* crtc other than crtc1 and crtc2 can only be use for + * DP those doesn't need a valid pll to work. + */ + return ATOM_PPLL_INVALID; + } return radeon_crtc->crtc_id; } } -- 1.7.11.7

2 1

Abstracting buffer sharing mechanism from the drm drivers
by Aaron Plattner 27 Nov '12

27 Nov '12

At the suggestion of a few drm developers, I'm looking at abstracting the buffer sharing mechanism away from the individual drm drivers and treating it as a low-level interface that kernel subsystems use to communicate, rather than as something drivers should be accessing directly. This would also mean that they wouldn't have to each implement their own set of dma_buf_ops, and the logic for things like detecting that you're importing your own dma_buf would be written once, in drm_prime.c and not in every driver's gem_prime_import function. Of course, it's slightly difficult because each driver's implementation seems to be subtly different. * i915 uses its own special locking function, i915_mutex_lock_interruptible. * nouveau and radeon pin the pages when the dma_buf is created, while i915 pins them at map time. * the vmap functions are different between i915 and radeon/nouveau, but it looks like all they use the dma_buf object for is to find the GEM object. Does it make sense to try to abstract the dma_buf parts of this? For example, a hypothetical new drm_gem_map_dma_buf would call a hook that lets i915 do its i915_gem_wait_for_error thing, takes the lock, calls a new gem_get_pages driver hook, does the dma_map_sg call, and handles the unlocking? I'll come up with a more detailed proposal or patches if this sounds like a good idea. -- Aaron

2 2

[PATCH 01/10] drm/radeon: allow move_notify to be called without reservation
by Maarten Lankhorst 27 Nov '12

27 Nov '12

The few places that care should have those checks instead. This allow destruction of bo backed memory without a reservation. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- drivers/gpu/drm/radeon/radeon_gart.c | 1 - drivers/gpu/drm/radeon/radeon_object.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 8690be7..6e24f84 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -1237,7 +1237,6 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev, { struct radeon_bo_va *bo_va; - BUG_ON(!radeon_bo_is_reserved(bo)); list_for_each_entry(bo_va, &bo->va, bo_list) { bo_va->valid = false; } diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 65c5555..50aa508 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -520,7 +520,7 @@ void radeon_bo_get_tiling_flags(struct radeon_bo *bo, int radeon_bo_check_tiling(struct radeon_bo *bo, bool has_moved, bool force_drop) { - BUG_ON(!radeon_bo_is_reserved(bo)); + BUG_ON(!radeon_bo_is_reserved(bo) && !force_drop); if (!(bo->tiling_flags & RADEON_TILING_SURFACE)) return 0; -- 1.8.0

4 32

[Bug 51421] New: sin and cos is broken
by bugzilla-daemon＠freedesktop.org 27 Nov '12

27 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=51421 Bug #: 51421 Summary: sin and cos is broken Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: cme3000(a)gmail.com sin is broken with negative values it just renders on the right side of the screen in shaders like http://glsl.heroku.com/e#2465.1 cos seems to be broken, too, just replace sin with cos on that web page. mesa: git-d105654 OS: Debian unstable, kernel 3.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 57531] New: [GEM] RS780V allocation errors with piglit
by bugzilla-daemon＠freedesktop.org 27 Nov '12

27 Nov '12

https://bugs.freedesktop.org/show_bug.cgi?id=57531 Priority: medium Bug ID: 57531 Assignee: dri-devel(a)lists.freedesktop.org Summary: [GEM] RS780V allocation errors with piglit Severity: normal Classification: Unclassified OS: All Reporter: kphillisjr(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 70558 --> https://bugs.freedesktop.org/attachment.cgi?id=70558&action=edit Dmesg log - after third pass of piglit. I was giving piglit a trial run, and noticed that there was a few errors about the radeon driver being able to allocate gem objects. Piglit package: 1.0.0~git20121122.cf47699-0edgers~quantal1 Piglit Git revision:cf47699087f74a6fd94c59a74837fc6c3c6422a8 Mesa Package: 9.1~git20121110.c6f426c0-0ubuntu0ricotz~quantal Mesa Git Revision: c6f426c02d14fcdfdbdd03473d098d4c9b81a8b2 Libdrm package: 2.4.40+git20121109.e01d68f9-0ubuntu0ricotz~quantal libdrm revision: e01d68f9f3acfc35fe164283904b5d058c2ab378 Notes: In the kernel log, the first pass errors started at: 11166.715813, second pass started at 11742.655557 and third pass had errors start 13408.932142. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h
by Sachin Kamat 27 Nov '12

27 Nov '12

nouveau_ttm.h was included twice. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 0910125..a1e3fed 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -49,8 +49,6 @@ #include "nouveau_fbcon.h" #include "nouveau_fence.h" -#include "nouveau_ttm.h" - MODULE_PARM_DESC(config, "option string to pass to driver core"); static char *nouveau_config; module_param_named(config, nouveau_config, charp, 0400); -- 1.7.4.1

2 3

[PATCH 1/1] drm/nouveau/device: Remove duplicate inclusion of core/device.h
by Sachin Kamat 27 Nov '12

27 Nov '12

core/device.h was included twice. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- drivers/gpu/drm/nouveau/core/subdev/device/base.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/device/base.c b/drivers/gpu/drm/nouveau/core/subdev/device/base.c index ca9a464..8d5e019 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/device/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/device/base.c @@ -25,7 +25,6 @@ #include <core/object.h> #include <core/device.h> #include <core/client.h> -#include <core/device.h> #include <core/option.h> #include <core/class.h> -- 1.7.4.1

1 1

[Bug 51021] New: Matrox g200 driver mgag200 doesn't work with FS PRIMERGY RX200 S4
by bugzilla-daemon＠bugzilla.kernel.org 26 Nov '12

26 Nov '12

https://bugzilla.kernel.org/show_bug.cgi?id=51021 Summary: Matrox g200 driver mgag200 doesn't work with FS PRIMERGY RX200 S4 Product: Drivers Version: 2.5 Kernel Version: 3.6.7 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: igor.sverkos+kernel(a)googlemail.com Regression: No Created an attachment (id=87311) --> (https://bugzilla.kernel.org/attachment.cgi?id=87311) This is how the display looks when the mgag200 is loaded Hi, sorry - don't know how to better phrase "doesn't work". With doesn't work I mean, that my screen will look like the attached screenshot. Relevant lspci output: rx200s4 ~ # lspci -s 1b: -nn 1b:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) [102b:0522] (rev 02) rx200s4 ~ # lspci -s 1b: -xxvv 1b:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller]) Subsystem: Fujitsu Technology Solutions Device 108e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at f6000000 (32-bit, prefetchable) [size=16M] Region 1: Memory at fc000000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at fc800000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at <unassigned> [disabled] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Kernel driver in use: mgag200 00: 2b 10 22 05 47 01 10 10 02 00 00 03 10 00 00 00 10: 08 00 00 f6 00 00 00 fc 00 00 80 fc 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 34 17 8e 10 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 00 00 -- 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 1

[PATCH 1/2] drm: add drm_mode_cea_vic
by Paulo Zanoni 26 Nov '12

26 Nov '12

From: Paulo Zanoni <paulo.r.zanoni(a)intel.com> This function returns the VIC of the mode. This value can be used when creating AVI InfoFrames. Cc: Thierry Reding <thierry.reding(a)avionic-design.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371 Signed-off-by: Paulo Zanoni <paulo.r.zanoni(a)intel.com> --- drivers/gpu/drm/drm_edid.c | 19 +++++++++++++++++++ include/drm/drm_crtc.h | 1 + 2 files changed, 20 insertions(+) Since drm-intel-next-queued is too old for this patch, I am rebasing it against drm-next and splitting into 2 patches: one drm-only and the other i915-only, so I imagine the first will be merged by Dave and the second by Daniel. New version: - Based on Dave's drm-next - Fix function name inside the comments - Remove the i915 chunk - Constification of other functions is no more required as they are already const here. diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 1648200..011bd4f 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2079,3 +2079,22 @@ int drm_add_modes_noedid(struct drm_connector *connector, return num_modes; } EXPORT_SYMBOL(drm_add_modes_noedid); + +/** + * drm_mode_cea_vic - return the CEA-861 VIC of a given mode + * @mode: mode + * + * RETURNS: + * The VIC number, 0 in case it's not a CEA-861 mode. + */ +uint8_t drm_mode_cea_vic(const struct drm_display_mode *mode) +{ + uint8_t i; + + for (i = 0; i < drm_num_cea_modes; i++) + if (drm_mode_equal(mode, &edid_cea_modes[i])) + return i + 1; + + return 0; +} +EXPORT_SYMBOL(drm_mode_cea_vic); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c0635b7..3538eda 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -1055,6 +1055,7 @@ extern struct drm_display_mode *drm_gtf_mode_complex(struct drm_device *dev, int GTF_2C, int GTF_K, int GTF_2J); extern int drm_add_modes_noedid(struct drm_connector *connector, int hdisplay, int vdisplay); +extern uint8_t drm_mode_cea_vic(const struct drm_display_mode *mode); extern int drm_edid_header_is_valid(const u8 *raw_edid); extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid); -- 1.7.10.4

3 4

[Bug 50941] Kernel does not compile
by bugzilla-daemon＠bugzilla.kernel.org 26 Nov '12

26 Nov '12

https://bugzilla.kernel.org/show_bug.cgi?id=50941 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alan(a)lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) AssignedTo|acpi_other(a)kernel-bugs.osdl |drivers_video-dri@kernel-bu |.org |gs.osdl.org Product|ACPI |Drivers --- Comment #2 from Alan <alan(a)lxorguk.ukuu.org.uk> 2012-11-26 12:12:48 --- You need ACPI_VIDEO set to yes not modular - shouldn't let you select a failing build but that is probably the workaround -- 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

← Newer
1
...
46
47
48
49
50
51
52
...
80
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2012