This set of patches removes psb_intel_output and replaces it with
psb_intel_encoder and psb_intel_connector. It also replaces the SDVO code with a
slightly modified version from i915. i915 SDVO needs Intel gmbus so this is
added along with a SDVO DDC bus guessing fix for Poulsbo.
Patrik Jakobsson (9):
gma500: Initial support for our encoder and connector structs
gma500: Remove psb_intel_output from ddc_probe and ddc_get_modes
gma500: Fix encoder type checking for connectors
gma500: …
[View More]Convert PSB LVDS to new output handling
gma500: Add support for Intel GMBUS
gma500: Replace SDVO code with slightly modified version from i915
gma500: Convert Cedarview to work with new output handling
gma500: Convert Moorestown to work with new output handling
gma500: SDVO DDC bus guessing isn't working so hardcode it instead
drivers/gpu/drm/gma500/Makefile | 1 +
drivers/gpu/drm/gma500/cdv_intel_crt.c | 47 +-
drivers/gpu/drm/gma500/cdv_intel_display.c | 14 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 112 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 117 +-
drivers/gpu/drm/gma500/framebuffer.c | 8 +-
drivers/gpu/drm/gma500/intel_gmbus.c | 493 +++++
drivers/gpu/drm/gma500/oaktrail_crtc.c | 18 +-
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 29 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c | 79 +-
drivers/gpu/drm/gma500/psb_device.c | 7 +
drivers/gpu/drm/gma500/psb_drv.c | 6 +-
drivers/gpu/drm/gma500/psb_drv.h | 30 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 39 +-
drivers/gpu/drm/gma500/psb_intel_drv.h | 97 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 152 +-
drivers/gpu/drm/gma500/psb_intel_modes.c | 16 +-
drivers/gpu/drm/gma500/psb_intel_reg.h | 74 +
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 3068 ++++++++++++++++++--------
drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h | 591 ++++-
20 files changed, 3733 insertions(+), 1265 deletions(-)
create mode 100644 drivers/gpu/drm/gma500/intel_gmbus.c
--
1.7.4.1
[View Less]
In theory function atombios_get_encoder_mode should report
ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
ATOM_ENCODER_MODE_DVI if card is DCE4.
Is there any reason for it? Can we just drop that DCE4 condition? This
fixme seems to be here since ever.
--
Rafał
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
…
[View More]discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
--
_______________________________________________
Dri-devel mailing list
Dri-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[View Less]
From: Chen Jie <chenj(a)lemote.com>
Sweep common_modes array should start with index 0.
Signed-off-by: Chen Jie <chenj(a)lemote.com>
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 17e1a9b..d1cea8d 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -229,21 +229,…
[View More]21 @@ void radeon_benchmark(struct radeon_device *rdev, int test_number)
break;
case 6:
/* GTT to VRAM, buffer size sweep, common modes */
- for (i = 1; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
+ for (i = 0; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
radeon_benchmark_move(rdev, common_modes[i],
RADEON_GEM_DOMAIN_GTT,
RADEON_GEM_DOMAIN_VRAM);
break;
case 7:
/* VRAM to GTT, buffer size sweep, common modes */
- for (i = 1; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
+ for (i = 0; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
radeon_benchmark_move(rdev, common_modes[i],
RADEON_GEM_DOMAIN_VRAM,
RADEON_GEM_DOMAIN_GTT);
break;
case 8:
/* VRAM to VRAM, buffer size sweep, common modes */
- for (i = 1; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
+ for (i = 0; i < RADEON_BENCHMARK_COMMON_MODES_N; i++)
radeon_benchmark_move(rdev, common_modes[i],
RADEON_GEM_DOMAIN_VRAM,
RADEON_GEM_DOMAIN_VRAM);
--
1.7.7.3
[View Less]
Hi Linus,
Okay the 2 non-kexec fixes + one of the calloc changes as by looking at
it, there was nothing stopping userspace for abusing the integer overflow
on these ioctls. The other calloc changes either were kernel internal or
had other things stopping userspace from exploiting them.
Dave.
The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4:
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800)
…
[View More]
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
Alex Deucher (1):
drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id
Daniel Vetter (1):
drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
Thomas Meyer (1):
vmwgfx: Use kcalloc instead of kzalloc to allocate array
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
drivers/gpu/drm/radeon/radeon_encoders.c | 7 +++----
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 ++--
3 files changed, 11 insertions(+), 7 deletions(-)
[View Less]
change v4
Hello Jerome Glisse,
This is a semi-automatic email about new static checker warnings.
The patch dc97b3409a79: "drm/ttm: callback move_notify any time bo
placement change v4" from Nov 18, 2011, leads to the following Smatch
complaint:
drivers/gpu/drm/nouveau/nouveau_bo.c +818 nouveau_bo_move_ntfy()
warn: variable dereferenced before check 'new_mem' (see line 813)
drivers/gpu/drm/nouveau/nouveau_bo.c
812 {
813 struct nouveau_mem *node = new_mem->mm_node;
…
[View More] ^^^^^^^^^^^^^^^^
Old dereference. new_mem can be NULL here these days.
814 struct nouveau_bo *nvbo = nouveau_bo(bo);
815 struct nouveau_vma *vma;
816
817 list_for_each_entry(vma, &nvbo->vma_list, head) {
818 if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
^^^^^^^
new check.
819 nouveau_vm_map(vma, new_mem->mm_node);
820 } else
regards,
dan carpenter
[View Less]
Hi Linus,
3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been
testing, and one kexec fix from Jerome for an issue reported on the list
where the gpu writeback engines need to be switched off, along with a
trivial fix from Alex.
Due to the size of the kexec fix I've decided to keep this pull small.
(I have some kzalloc->kcalloc fixes to check on).
Dave.
The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4:
Merge branch 'x86-urgent-for-linus' of …
[View More]git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
Alex Deucher (1):
drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id
Daniel Vetter (1):
drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
Jerome Glisse (1):
drm/radeon: disable possible GPU writeback early v3
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
drivers/gpu/drm/radeon/evergreen.c | 2 ++
drivers/gpu/drm/radeon/ni.c | 18 ++++++++++++++++++
drivers/gpu/drm/radeon/nid.h | 19 +++++++++++++++++++
drivers/gpu/drm/radeon/r100.c | 20 ++++++--------------
drivers/gpu/drm/radeon/r520.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 16 ++++++++++++++++
drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
drivers/gpu/drm/radeon/radeon_encoders.c | 7 +++----
drivers/gpu/drm/radeon/rs600.c | 20 +++++++++++++++++++-
drivers/gpu/drm/radeon/rs600d.h | 21 +++++++++++++++++++++
drivers/gpu/drm/radeon/rs690.c | 2 +-
drivers/gpu/drm/radeon/rv515.c | 2 +-
drivers/gpu/drm/radeon/rv770.c | 16 ++++++++++++++++
drivers/gpu/drm/radeon/rv770d.h | 20 ++++++++++++++++++++
15 files changed, 151 insertions(+), 23 deletions(-)
[View Less]
The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts.
Every time we go through this we need a
- active object that can be retired
- and there are no other references to that object than the one from
the active list, so that it gets unbound and freed immediately.
Otherwise the recursion stops. So the recursion is only limited by the
number of objects that fit these requirements sitting in the active list
any time retire_request is called.
Issue exercised by …
[View More]tests/gem_unref_active_buffers from i-g-t.
There's been a decent bikeshed discussion whether it wouldn't be
better to pass around a flag, but imo this is o.k. for such a limited
case that only supports a w/a.
Signed-Off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson> # we built better
bikesheds, but this keeps the rain off for now
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 036bc58..d7d5801 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2026,8 +2026,13 @@ i915_wait_request(struct intel_ring_buffer *ring,
* to handle this, the waiter on a request often wants an associated
* buffer to have made it to the inactive list, and we would need
* a separate wait queue to handle that.
+ *
+ * To avoid a recursion with the ilk VT-d workaround (that calls
+ * gpu_idle when unbinding objects with interruptible==false) don't
+ * retire requests in that case (because it might call unbind if the
+ * active list holds the last reference to the object).
*/
- if (ret == 0)
+ if (ret == 0 && dev_priv->mm.interruptible)
i915_gem_retire_requests_ring(ring);
return ret;
--
1.7.6.4
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=43000
Bug #: 43000
Summary: huge performance regression in ut2004 since 7.11
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: aaalmosss(a)gmail.com
…
[View More]With 7.11 I get 60fps during the nvidia logo and in the menu. Ingame it is e.g.
~44fps if I load ons-torlan and look at the central tower from the base.
With 7.12-dev (git-b618e78) I get <30fps during the nvidia logo, and ~6fps on
the same level.
I must add, that 7.11 isn't quite playable either, because the fps has very
high variance: it jumps between 20 and 60, which makes the game very laggy.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]