[PATCH] drm/radeon/kms: fix formatting of vram and gtt info
print the full 64 bit values. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 4985bfa..1b6d1c3 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -291,7 +291,7 @@ void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc, u64 mc->mc_vram_size = mc->aper_size; } mc->vram_end = mc->vram_start + mc->mc_vram_size - 1; - dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM used)\n", + dev_info(rdev->dev, "VRAM: %lluM 0x%016llX - 0x%016llX (%lluM used)\n", mc->mc_vram_size >> 20, mc->vram_start, mc->vram_end, mc->real_vram_size >> 20); } @@ -328,7 +328,7 @@ void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc) mc->gtt_start = (mc->vram_end + 1 + mc->gtt_base_align) & ~mc->gtt_base_align; } mc->gtt_end = mc->gtt_start + mc->gtt_size - 1; - dev_info(rdev->dev, "GTT: %lluM 0x%08llX - 0x%08llX\n", + dev_info(rdev->dev, "GTT: %lluM 0x%016llX - 0x%016llX\n", mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end); } -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix vram base calculation on rs780/rs880
Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/r600.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 53bfe3a..c6a37e0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1198,8 +1198,10 @@ static void r600_vram_gtt_location(struct radeon_device
*rdev, struct radeon_mc
mc->vram_end, mc->real_vram_size >> 20);
} else {
u64 base = 0;
- if (rdev->flags & RADEON_IS_IGP)
- base = (RREG32(MC_VM_FB_LOCATION) & 0x) << 24;
+ if (rdev->flags & RADEON_IS_IGP) {
+ base = RREG32(MC_VM_FB_LOCATION) & 0x;
+ base <<= 24;
+ }
radeon_vram_location(rdev, &rdev->mc, base);
rdev->mc.gtt_base_align = 0;
radeon_gtt_location(rdev, mc);
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix vram start calculation on ontario
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |6 ++
drivers/gpu/drm/radeon/evergreend.h |1 +
drivers/gpu/drm/radeon/rv770.c | 11 +++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 534953c..f8781f9 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1146,6 +1146,12 @@ static void evergreen_mc_program(struct radeon_device
*rdev)
rdev->mc.vram_end >> 12);
}
WREG32(MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR, 0);
+ if (rdev->flags & RADEON_IS_IGP) {
+ tmp = RREG32(MC_FUS_VM_FB_OFFSET) & 0x000F;
+ tmp |= ((rdev->mc.vram_end >> 20) & 0xF) << 24;
+ tmp |= ((rdev->mc.vram_start >> 20) & 0xF) << 20;
+ WREG32(MC_FUS_VM_FB_OFFSET, tmp);
+ }
tmp = ((rdev->mc.vram_end >> 24) & 0x) << 16;
tmp |= ((rdev->mc.vram_start >> 24) & 0x);
WREG32(MC_VM_FB_LOCATION, tmp);
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index 87fcaba..5b869ce 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -202,6 +202,7 @@
#defineMC_VM_AGP_BOT 0x202C
#defineMC_VM_AGP_BASE 0x2030
#defineMC_VM_FB_LOCATION 0x2024
+#defineMC_FUS_VM_FB_OFFSET 0x2898
#defineMC_VM_MB_L1_TLB0_CNTL 0x2234
#defineMC_VM_MB_L1_TLB1_CNTL 0x2238
#defineMC_VM_MB_L1_TLB2_CNTL 0x223C
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 7c2e0b1..e414a14 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -271,12 +271,6 @@ static void rv770_mc_program(struct radeon_device *rdev)
rdev->mc.vram_end >> 12);
}
WREG32(MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR, 0);
- if (rdev->flags & RADEON_IS_IGP) {
- tmp = RREG32(MC_FUS_VM_FB_OFFSET) & 0x000F;
- tmp |= ((rdev->mc.vram_end >> 20) & 0xF) << 24;
- tmp |= ((rdev->mc.vram_start >> 20) & 0xF) << 20;
- WREG32(MC_FUS_VM_FB_OFFSET, tmp);
- }
tmp = ((rdev->mc.vram_end >> 24) & 0x) << 16;
tmp |= ((rdev->mc.vram_start >> 24) & 0x);
WREG32(MC_VM_FB_LOCATION, tmp);
@@ -1076,8 +1070,9 @@ void r700_vram_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
} else {
u64 base = 0;
if (rdev->flags & RADEON_IS_IGP) {
- base = (RREG32(MC_VM_FB_LOCATION) & 0x) << 24;
- base |= RREG32(MC_FUS_VM_FB_OFFSET) & 0x00F0;
+ base = RREG32(MC_VM_FB_LOCATION) & 0x;
+ base <<= 24;
+ base |= (u64)(RREG32(MC_FUS_VM_FB_OFFSET) & 0x00F0);
}
radeon_vram_location(rdev, &rdev->mc, base);
rdev->mc.gtt_base_align = 0;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: properly print ontario chip id
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_device.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 1b6d1c3..2774b89 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -81,6 +81,7 @@ static const char radeon_family_name[][16] = {
"JUNIPER",
"CYPRESS",
"HEMLOCK",
+ "PALM",
"LAST",
};
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #19 from Álmos 2010-12-03 13:27:04 PST --- I don't know if this information helps, but this corruption also appears on the water in google earth, if there is a semi-transparent icon over it (like the one for a shipwreck). If I set the view so that only one such icon is visible, and move the cursor over it, the icon becomes solid, and the glitch disappears. The viewport change indicator cursor (appearing while holding down the right or middle mouse button) also triggers this glitch, if the cursor is over an area, where water is drawn. Checking/unchecking the texture compression option doesn't change anything, maybe it's a no-op if s3tc is available... To Chris: I believe it was already known that this glitch is only present with pre-r500 cards (maybe due to vram sizes), but now that I checked the other bugreports about it, I discovered that all reporters have rv350. Coincidence? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31827] r300g fails to link a GL program (Mesa 7.9)
https://bugs.freedesktop.org/show_bug.cgi?id=31827 --- Comment #18 from Hicham HAOUARI 2010-12-03 13:37:10 PST --- (In reply to comment #17) > Fixed in Mesa master. The fix will eventually make its way to 7.9. Closing.. What commit fixed this bug ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708) v3
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 1d06774..a598d00 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -69,7 +69,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo,
u32 domain)
u32 c = 0;
rbo->placement.fpfn = 0;
- rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT;
+ rbo->placement.lpfn = 0;
rbo->placement.placement = rbo->placements;
rbo->placement.busy_placement = rbo->placements;
if (domain & RADEON_GEM_DOMAIN_VRAM)
@@ -91,7 +91,8 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
{
struct radeon_bo *bo;
enum ttm_bo_type type;
- int page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
+ unsigned long page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
+ unsigned long max_size = 0;
int r;
if (unlikely(rdev->mman.bdev.dev_mapping == NULL)) {
@@ -104,6 +105,14 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
}
*bo_ptr = NULL;
+ /* maximun bo size is the minimun btw visible vram and gtt size */
+ max_size = min(rdev->mc.visible_vram_size, rdev->mc.gtt_size);
+ if ((page_align << PAGE_SHIFT) >= max_size) {
+ printk(KERN_WARNING "%s:%d alloc size %ldM bigger than %ldMb
limit\n",
+ __func__, __LINE__, page_align >> (20 - PAGE_SHIFT),
max_size >> 20);
+ return -ENOMEM;
+ }
+
retry:
bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL);
if (bo == NULL)
--
1.7.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31827] r300g fails to link a GL program (Mesa 7.9)
https://bugs.freedesktop.org/show_bug.cgi?id=31827 --- Comment #19 from Marek Olšák 2010-12-03 14:02:33 PST --- This set of patches: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ead2ea89f42b40edc56ddf8c6ce1df4efdcefe2a http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a1d063c6d679c2155f5eb80f1cb94368d36bf2c http://cgit.freedesktop.org/mesa/mesa/commit/?id=940df10100d740ef27fa39026fd51c3199ed3d62 http://cgit.freedesktop.org/mesa/mesa/commit/?id=1802cb9bafc4125300870be51e8b22ddd795d61e -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31943] [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID
https://bugs.freedesktop.org/show_bug.cgi?id=31943 Alban Browaeys changed: What|Removed |Added Attachment #40595|0 |1 is obsolete|| --- Comment #5 from Alban Browaeys 2010-12-03 20:06:47 PST --- Created an attachment (id=40792) View: https://bugs.freedesktop.org/attachment.cgi?id=40792 Review: https://bugs.freedesktop.org/review?bug=31943&attachment=40792 Fix the version in the edid (v2.3 makes no sense) checksum is correct with v1.3 This patch is not good for upstream , ie if we had this fix why not add the hundreds of other one for each broken edid kind. Still it showcase the issue of this bug report. First discarding the checksum would not help as here the reported incorrect version is 2 and we only support 1 (thus the valid check would still fail). The checksum is in fact correct if one replace this v2.3 by v1.3. It looks like the version was mangled a posteriori. One option is to completely discard the validity check via an option for the drm module . Still it would move the issue to other layers if those expect a valid edid or do a check of validity (they would also require a bypass option). Another option is to load valid edid (from disk or initramfs,) like we do for firmwares. One of the main issue of this approach is how to identify if and which edid to load : phase out an id for the monitor or one for the invalid edid (the latter via sum). There are gaps to fill for this option though : will distro need to ship hundreds of fixed edid in initramfs and such. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] MCDE: Add build files and bus
> >> > Having the kms/fb/v4l2 drivers on top definitely makes sense, so >> > these should all be able to be standalone loadable modules. >> > I do not understand why you have a v4l2 driver at all, or why >> > you need both fb and kms drivers, but that is probably because >> > of my ignorance of display device drivers. >> >> All APIs have to be provided, these are user space API requirements. >> KMS has a generic FB implementation. But most of KMS is modeled by >> desktop/PC graphics cards. And while we might squeeze MCDE in to look >> like a PC card, it might also just make things more complex and >> restrict us to do things not possible in PC architecture. > > Ok, so you have identified a flaw with the existing KMS code. You should > most certainly not try to make your driver fit into the flawed model by > making it look like a PC. Instead, you are encouraged to fix the problems > with KMS to make sure it can also meet your requirements. The reason > why it doesn't do that today is that all the existing users are PC > hardware and we don't build infrastructure that we expect to be used > in the future but don't need yet. It would be incorrect anyway. > > Can you describe the shortcomings of the KSM code? I've added the dri-devel > list to Cc, to get the attention of the right people. I'm not sure I've a full understanding of what this bus is all about, but I can't see why it can't fit inside KMS, with maybe a V4L bolted on. The whole point of KMS is to provide a consistent userspace interface for describing the graphics hardware in enough detail that userspace can use it, but without giving it all the gorey details. So we've reduced the interface to crtc/encoder/connectors as the base level objects at the interface, internally drivers can and do have extra layers, but usually no need to show this to userspace. KMS at the moment doesn't really handle dynamic hotplug of new crtcs connectors etc, but I'm not sure that is needed here. It sounds like you just have some embedded building blocks you want to put together on a design by design basis, please correct me if I'm wrong. Dave. > >> Alex Deucher noted in a previous post that we also have the option of >> implementing the KMS ioctls. We are looking at both options. And having >> our own framebuffer driver might make sense since it is a very basic >> driver, and it will allow us to easily extend support for things like >> partial updates for display panels with on board memory. These panels >> with memory (like DSI command mode displays) is one of the reasons why >> KMS is not the perfect match. Since we want to expose features available >> for these types of displays. > > Ok. > >> > > > From what I understood so far, you have a single multi-channel >> > display >> > > > controller (mcde_hw.c) that drives the hardware. >> > > > Each controller can have multiple frame buffers attached to it, >> > which >> > > > in turn can have multiple displays attached to each of them, but >> > your >> > > > current configuration only has one of each, right? >> > > >> > > Correct, channels A/B (crtcs) can have two blended "framebuffers" >> > plus >> > > background color, channels C0/C1 can have one framebuffer. >> > >> > We might still be talking about different things here, not sure. >> >> In short, >> KMS connector = MCDE port >> KMS encoder = MCDE channel >> KMS crtc = MCDE overlay > > Any chance you could change the identifiers in the code for this > without confusing other people? > >> > Looking at the representation in sysfs, you should probably aim >> > for something like >> > >> > /sys/devices/axi/axi0/mcde_controller >> > /chnlA >> > /dspl_crtc0 >> > /fb0 >> > /fb1 >> > /v4l_0 >> > /dspl_dbi0 >> > /fb2 >> > /v4l_1 >> > /chnlB >> > /dspl_ctrc1 >> > /fb3 >> > /chnlC >> > /dspl_lcd0 >> > /fb4 >> > /v4l_2 >> > >> > Not sure if that is close to what your hardware would really >> > look like. My point is that all the objects that you are >> > dealing with as a device driver should be represented hierarchically >> > according to how you probe them. >> >> Yes, mcde_bus should be connected to mcde, this is a bug. The display >> drivers will placed in this bus, since this is where they are probed >> like platform devices, by name (unless driver can do MIPI standard >> probing or something). Framebuffers/V4L2 overlay devices can't be >> put in same hierarchy, since the
@tungstengraphics.com email addresses all over bugzilla
We should update everyone's email addresses, now that tungstengraphics.com is owned by squatters. Who let that happen, by the way? :\ Matt
2.6.37-rc4-git1: Reported regressions from 2.6.36
This message contains a list of some regressions from 2.6.36, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.36, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2010-12-03 55 25 19 2010-11-19 39 29 25 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24142 Subject : No more bt848 driver in 2.6.37-rc* Submitter : Christian Casteyde Date: 2010-11-30 20:50 (3 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23902 Subject : [BUG] 2.6.37-rc3 massive interactivity regression on ARM Submitter : Mikael Pettersson Date: 2010-11-27 15:16 (6 days old) Message-ID : <19697.8378.717761.236202 at pilspetsen.it.uu.se> References : http://marc.info/?l=linux-kernel&m=129087098911837&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23762 Subject : kernel 2.6.37-rc2 breaks i915 graphics Submitter : Chris Vine Date: 2010-11-21 10:23 (12 days old) Message-ID : <20101121102344.7c590b99 at laptop.homenet> References : http://marc.info/?l=linux-kernel&m=129033505414671&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23542 Subject : HP 2530p accelerated graphics causes spontaneous power off/on Submitter : Bjorn Helgaas Date: 2010-11-22 17:12 (11 days old) References : https://patchwork.kernel.org/patch/365092/ Handled-By : Bjorn Helgaas Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23462 Subject : DVI/EDID broken with Intel i945 graphics and 2.6.37-rc2 Submitter : Tino Keitel Date: 2010-11-16 18:49 (17 days old) Message-ID : <20101116184914.GA15794 at mac.home> References : http://marc.info/?l=linux-kernel&m=128993389113001&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23432 Subject : resume from suspend hangs on everex stepnote sa2053 Submitter : tomas m Date: 2010-11-21 13:32 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23332 Subject : Boot failure on HP nx6325 Submitter : Rafael J. Wysocki Date: 2010-11-20 00:57 (13 days old) First-Bad-Commit: http://git.kernel.org/linus/1af3c2e45e7a641e774bbb84fa428f2f0bf2d9c9 Handled-By : Bjorn Helgaas Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23142 Subject : autofs4 hang in 2.6.37-rc1 Submitter : Avi Kivity Date: 2010-11-14 12:55 (19 days old) Message-ID : <4CDFDC2B.6040205 at redhat.com> References : http://marc.info/?l=linux-kernel&m=128973936026185&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23102 Subject : [bisected] i915 regression in post 2.6.36 kernels Submitter : Johannes Hirte Date: 2010-11-10 7:02 (23 days old) Message-ID : <201011100802.20332.johannes.hirte at fem.tu-ilmenau.de> References : http://marc.info/?l=linux-kernel&m=128937310017057&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942 Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request() Submitter : Dave Chinner Date: 2010-11-05 1:30 (28 days old) Message-ID : <20101105013003.GE13830 at dastard> References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912 Subject : spi_lm70llp module crash on unload (2.6.37-rc1) Submitter : Randy Dunlap Date: 2010-11-05 0:16 (28 days old) Message-ID : <20101104171620.00d8c95d.randy.dunlap at oracle.com> References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882 Subject : (2.6.37-rc1) amd64-agp module crashed on second load Submitter : Randy Dunlap Date: 2010-11-05 0:13 (28 days old) Message-ID : <20101104171333.fea1f498.randy.dunlap at oracle.com> References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22812 Subject : kernel oops on 2.6.37-rc1 Submitter : Andrew Date: 2010-11-12 16:05 (21 days old) First-Bad-Commit: http://git.kernel.org/linus/a68c439b1966c91f0ef474e2bf275d6792312726 Bug-Entry : http://bugzilla.kernel.o
[PATCH] drm/radeon/kms: fix formatting of vram and gtt info
print the full 64 bit values. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 4985bfa..1b6d1c3 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -291,7 +291,7 @@ void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc, u64 mc->mc_vram_size = mc->aper_size; } mc->vram_end = mc->vram_start + mc->mc_vram_size - 1; - dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM used)\n", + dev_info(rdev->dev, "VRAM: %lluM 0x%016llX - 0x%016llX (%lluM used)\n", mc->mc_vram_size >> 20, mc->vram_start, mc->vram_end, mc->real_vram_size >> 20); } @@ -328,7 +328,7 @@ void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc) mc->gtt_start = (mc->vram_end + 1 + mc->gtt_base_align) & ~mc->gtt_base_align; } mc->gtt_end = mc->gtt_start + mc->gtt_size - 1; - dev_info(rdev->dev, "GTT: %lluM 0x%08llX - 0x%08llX\n", + dev_info(rdev->dev, "GTT: %lluM 0x%016llX - 0x%016llX\n", mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end); } -- 1.7.1.1
[PATCH] drm/radeon/kms: fix vram base calculation on rs780/rs880
Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/r600.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 53bfe3a..c6a37e0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1198,8 +1198,10 @@ static void r600_vram_gtt_location(struct radeon_device
*rdev, struct radeon_mc
mc->vram_end, mc->real_vram_size >> 20);
} else {
u64 base = 0;
- if (rdev->flags & RADEON_IS_IGP)
- base = (RREG32(MC_VM_FB_LOCATION) & 0x) << 24;
+ if (rdev->flags & RADEON_IS_IGP) {
+ base = RREG32(MC_VM_FB_LOCATION) & 0x;
+ base <<= 24;
+ }
radeon_vram_location(rdev, &rdev->mc, base);
rdev->mc.gtt_base_align = 0;
radeon_gtt_location(rdev, mc);
--
1.7.1.1
[PATCH] drm/radeon/kms: fix vram start calculation on ontario
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |6 ++
drivers/gpu/drm/radeon/evergreend.h |1 +
drivers/gpu/drm/radeon/rv770.c | 11 +++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 534953c..f8781f9 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1146,6 +1146,12 @@ static void evergreen_mc_program(struct radeon_device
*rdev)
rdev->mc.vram_end >> 12);
}
WREG32(MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR, 0);
+ if (rdev->flags & RADEON_IS_IGP) {
+ tmp = RREG32(MC_FUS_VM_FB_OFFSET) & 0x000F;
+ tmp |= ((rdev->mc.vram_end >> 20) & 0xF) << 24;
+ tmp |= ((rdev->mc.vram_start >> 20) & 0xF) << 20;
+ WREG32(MC_FUS_VM_FB_OFFSET, tmp);
+ }
tmp = ((rdev->mc.vram_end >> 24) & 0x) << 16;
tmp |= ((rdev->mc.vram_start >> 24) & 0x);
WREG32(MC_VM_FB_LOCATION, tmp);
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index 87fcaba..5b869ce 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -202,6 +202,7 @@
#defineMC_VM_AGP_BOT 0x202C
#defineMC_VM_AGP_BASE 0x2030
#defineMC_VM_FB_LOCATION 0x2024
+#defineMC_FUS_VM_FB_OFFSET 0x2898
#defineMC_VM_MB_L1_TLB0_CNTL 0x2234
#defineMC_VM_MB_L1_TLB1_CNTL 0x2238
#defineMC_VM_MB_L1_TLB2_CNTL 0x223C
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 7c2e0b1..e414a14 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -271,12 +271,6 @@ static void rv770_mc_program(struct radeon_device *rdev)
rdev->mc.vram_end >> 12);
}
WREG32(MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR, 0);
- if (rdev->flags & RADEON_IS_IGP) {
- tmp = RREG32(MC_FUS_VM_FB_OFFSET) & 0x000F;
- tmp |= ((rdev->mc.vram_end >> 20) & 0xF) << 24;
- tmp |= ((rdev->mc.vram_start >> 20) & 0xF) << 20;
- WREG32(MC_FUS_VM_FB_OFFSET, tmp);
- }
tmp = ((rdev->mc.vram_end >> 24) & 0x) << 16;
tmp |= ((rdev->mc.vram_start >> 24) & 0x);
WREG32(MC_VM_FB_LOCATION, tmp);
@@ -1076,8 +1070,9 @@ void r700_vram_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
} else {
u64 base = 0;
if (rdev->flags & RADEON_IS_IGP) {
- base = (RREG32(MC_VM_FB_LOCATION) & 0x) << 24;
- base |= RREG32(MC_FUS_VM_FB_OFFSET) & 0x00F0;
+ base = RREG32(MC_VM_FB_LOCATION) & 0x;
+ base <<= 24;
+ base |= (u64)(RREG32(MC_FUS_VM_FB_OFFSET) & 0x00F0);
}
radeon_vram_location(rdev, &rdev->mc, base);
rdev->mc.gtt_base_align = 0;
--
1.7.1.1
[PATCH] drm/radeon/kms: properly print ontario chip id
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_device.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 1b6d1c3..2774b89 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -81,6 +81,7 @@ static const char radeon_family_name[][16] = {
"JUNIPER",
"CYPRESS",
"HEMLOCK",
+ "PALM",
"LAST",
};
--
1.7.1.1
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #19 from ?lmos 2010-12-03 13:27:04 PST --- I don't know if this information helps, but this corruption also appears on the water in google earth, if there is a semi-transparent icon over it (like the one for a shipwreck). If I set the view so that only one such icon is visible, and move the cursor over it, the icon becomes solid, and the glitch disappears. The viewport change indicator cursor (appearing while holding down the right or middle mouse button) also triggers this glitch, if the cursor is over an area, where water is drawn. Checking/unchecking the texture compression option doesn't change anything, maybe it's a no-op if s3tc is available... To Chris: I believe it was already known that this glitch is only present with pre-r500 cards (maybe due to vram sizes), but now that I checked the other bugreports about it, I discovered that all reporters have rv350. Coincidence? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31827] r300g fails to link a GL program (Mesa 7.9)
https://bugs.freedesktop.org/show_bug.cgi?id=31827 --- Comment #18 from Hicham HAOUARI 2010-12-03 13:37:10 PST --- (In reply to comment #17) > Fixed in Mesa master. The fix will eventually make its way to 7.9. Closing.. What commit fixed this bug ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708) v3
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 1d06774..a598d00 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -69,7 +69,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo,
u32 domain)
u32 c = 0;
rbo->placement.fpfn = 0;
- rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT;
+ rbo->placement.lpfn = 0;
rbo->placement.placement = rbo->placements;
rbo->placement.busy_placement = rbo->placements;
if (domain & RADEON_GEM_DOMAIN_VRAM)
@@ -91,7 +91,8 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
{
struct radeon_bo *bo;
enum ttm_bo_type type;
- int page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
+ unsigned long page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
+ unsigned long max_size = 0;
int r;
if (unlikely(rdev->mman.bdev.dev_mapping == NULL)) {
@@ -104,6 +105,14 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
}
*bo_ptr = NULL;
+ /* maximun bo size is the minimun btw visible vram and gtt size */
+ max_size = min(rdev->mc.visible_vram_size, rdev->mc.gtt_size);
+ if ((page_align << PAGE_SHIFT) >= max_size) {
+ printk(KERN_WARNING "%s:%d alloc size %ldM bigger than %ldMb
limit\n",
+ __func__, __LINE__, page_align >> (20 - PAGE_SHIFT),
max_size >> 20);
+ return -ENOMEM;
+ }
+
retry:
bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL);
if (bo == NULL)
--
1.7.3.2
[Bug 31827] r300g fails to link a GL program (Mesa 7.9)
https://bugs.freedesktop.org/show_bug.cgi?id=31827 --- Comment #19 from Marek Ol??k 2010-12-03 14:02:33 PST --- This set of patches: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ead2ea89f42b40edc56ddf8c6ce1df4efdcefe2a http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a1d063c6d679c2155f5eb80f1cb94368d36bf2c http://cgit.freedesktop.org/mesa/mesa/commit/?id=940df10100d740ef27fa39026fd51c3199ed3d62 http://cgit.freedesktop.org/mesa/mesa/commit/?id=1802cb9bafc4125300870be51e8b22ddd795d61e -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31943] [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID
https://bugs.freedesktop.org/show_bug.cgi?id=31943 Alban Browaeys changed: What|Removed |Added Attachment #40595|0 |1 is obsolete|| --- Comment #5 from Alban Browaeys 2010-12-03 20:06:47 PST --- Created an attachment (id=40792) View: https://bugs.freedesktop.org/attachment.cgi?id=40792 Review: https://bugs.freedesktop.org/review?bug=31943&attachment=40792 Fix the version in the edid (v2.3 makes no sense) checksum is correct with v1.3 This patch is not good for upstream , ie if we had this fix why not add the hundreds of other one for each broken edid kind. Still it showcase the issue of this bug report. First discarding the checksum would not help as here the reported incorrect version is 2 and we only support 1 (thus the valid check would still fail). The checksum is in fact correct if one replace this v2.3 by v1.3. It looks like the version was mangled a posteriori. One option is to completely discard the validity check via an option for the drm module . Still it would move the issue to other layers if those expect a valid edid or do a check of validity (they would also require a bypass option). Another option is to load valid edid (from disk or initramfs,) like we do for firmwares. One of the main issue of this approach is how to identify if and which edid to load : phase out an id for the monitor or one for the invalid edid (the latter via sum). There are gaps to fill for this option though : will distro need to ship hundreds of fixed edid in initramfs and such. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
