Re: drm: Changes to 'debian-experimental'
On Son, 2012-09-09 at 15:33 -0700, Jordan Justen wrote: New branch 'debian-experimental' available with the following commits: I think you pushed this to the wrong repository? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CPU and GPU cache-coherence
On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote: 3D render image on WC AGP aperture BO and then CPU fetch the image from this bo, in order to achieve performance, after 3D finished rendering, validate this bo into cached system memory and then read it from system memory. But I always get garbage from there. After check TTM bo validate codes, it has dealt with cache coherence properly, i wonder whether there is something I misunderstand or it is not allowed to move the WC bo from AGP to system memory for reading? Can you post patches showing what you've tried? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CPU and GPU cache-coherence
On Mit, 2011-06-15 at 16:58 +0200, Michel Dänzer wrote: On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote: 3D render image on WC AGP aperture BO and then CPU fetch the image from this bo, in order to achieve performance, after 3D finished rendering, validate this bo into cached system memory and then read it from system memory. But I always get garbage from there. After check TTM bo validate codes, it has dealt with cache coherence properly, i wonder whether there is something I misunderstand or it is not allowed to move the WC bo from AGP to system memory for reading? Can you post patches showing what you've tried? Moving to the new dri-devel list at freedesktop.org, please only follow up there. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] fb: fix overlapping test off-by-one.
On Die, 2010-12-21 at 11:41 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On my system with a radeon x2, the first GPU was not overlapping vesa but the test decided it was. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/video/fbmem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 0e6aa3d..4ac1201 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1458,7 +1458,7 @@ static bool apertures_overlap(struct aperture *gen, struct aperture *hw) if (gen-base == hw-base) return true; /* is the generic aperture base inside the hw base-hw base+size */ - if (gen-base hw-base gen-base = hw-base + hw-size) + if (gen-base hw-base gen-base hw-base + hw-size) Good catch. Reviewed-by: Michel Dänzer mic...@daenzer.net -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: I'm currently testing on a rv350 based aluminium powerbooks. Same here. :) - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. AGP 1x works mostly fine for me. Not sure what the problem is with higher speeds (4x used to work fine with UMS) but I guess most likely some kind of coherency issue which only matters now that we're dynamically changing GTT bindings. The reason you don't get anything useful with higher AGP speeds is that the attempt to reset the locked-up GPU kills the machine. I tried tracking this down with netconsole but the only possibly relevant info I've got out of that yet is that there seem to be some machine checks occurring. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. I only tried this once but AFAIR it was the same for me. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Might be nice, though IME the CPU seems to suck more power anyway. :) IMO the highest priority missing feature is backlight control, followed by suspend/resume. Note that there's also still outstanding KMS related endianness issues in the Mesa tree, in particular concerning r300g but also the classic driver related to the OpenGL blit functionality. I've been meaning to clean up and push my hacks for those but had little time recently. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Fix support for PCI domains
On Fre, 2010-08-06 at 13:55 +1000, Benjamin Herrenschmidt wrote: (For some reason I thought that went in ages ago ...) This fixes support for PCI domains in what should hopefully be a backward compatible way along with a change to libdrm. When the interface version is set to 1.4, we assume userspace understands domains and the world is at peace. We thus pass proper domain numbers instead of 0 to userspace. The newer libdrm will then try 1.4 first, and fallback to 1.1, along with ignoring domains in the later case (well, except on alpha of course) Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Reviewed-by: Michel Dänzer mic...@daenzer.net Thanks for tackling this, Ben! -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/fbdev: rework output polling to be back in the core. (v3)
On Don, 2010-05-06 at 16:15 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls Signed-off-by: Dave Airlie airl...@redhat.com Core and radeon parts Reviewed-by: Michel Dänzer mic...@daenzer.net Thanks Dave, looks like the X patch isn't exactly a hard sell either. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
On Mit, 2010-05-05 at 20:25 +1000, Dave Airlie wrote: 2010/5/5 Michel Dänzer mic...@daenzer.net: On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. The thing is current UMS drivers already do bad faking of stuff, have a look at the info-first_load_no_devices flags in -ati. So if nobody ever thought this was worth doing properly in the first place or anytime since, I'd like that KMS drivers can just follow what UMS drivers have done. Granted I could probably do the faking in the KMS X.org drivers, but since UMS drivers never had hotplug or any useful uevent mechanism they'd never see the problem, so I've fixed the drivers to work. Doing it in the X drivers would be less ugly IMO, at least the workaround would be in / next to the same component as one of the underlying problems. My worry with changing X/GNOME is that it'll break some random corner case assumptions somewhere else in userspace, there are many randr clients and I don't want to hunt them all down, Then how do you know none of them will trip over this change? I'd like to advertise the protocol we have now if I can. What protocol are you referring to? To me it would make more sense to address the underlying problems rather than piling up more workarounds. The KMS API should provide as accurate information as possible, not second-guess what its users might expect. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Expose backlight class device for legacy LVDS encoder.
On Die, 2009-12-08 at 12:24 +0100, Rafał Miłecki wrote:
W dniu 8 grudnia 2009 12:03 użytkownik Michel Dänzer
mic...@daenzer.net napisał:
On Tue, 2009-12-08 at 11:32 +0100, Rafał Miłecki wrote:
2009/12/8 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Allows e.g. power management daemons to control the backlight level.
Inspired
by the corresponding code in radeonfb.
Signed-off-by: Michel Dänzer daen...@vmware.com
I posted something similar but AFAIR got response we don't want this
until fixing backlight class design.
Unfortunately I'm not aware of any other available method to control the
backlight on Apple PowerPC laptops. I'm open for suggestions though how
this code could be disabled when another method is available.
It's not that we don't want solution you wrote. It's absolutely
wanted. But we need to improve backlight class because we start
register many devices that control same display which drivers us to
inconsistency.
Please, check http://marc.info/?t=12593682454r=1w=2
Hopefully I'll find some time to do that before .33 and we will able
to include our patches then.
Any news on this?
Per demand from IRC, I'm posting the patch rebased against a newer
kernel tree.
commit f380d3bc243ade263c4dc034ce0873fbe9d96f75
Author: Michel Dänzer daen...@vmware.com
Date: Thu Feb 25 16:47:00 2010 +0100
drm/radeon/kms: Expose backlight class device for legacy LVDS encoder.
Allows e.g. power management daemons to control the backlight level.
Inspired
by the corresponding code in radeonfb.
Signed-off-by: Michel Dänzer daen...@vmware.com
diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 1c02d23..9746fee 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,6 +1,7 @@
config DRM_RADEON_KMS
bool Enable modesetting on radeon by default - NEW DRIVER
depends on DRM_RADEON
+ select BACKLIGHT_CLASS_DEVICE
help
Choose this option if you want kernel modesetting enabled by default.
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index cf389ce..fbc2df3 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -29,6 +29,10 @@
#include radeon.h
#include atom.h
+#ifdef CONFIG_PMAC_BACKLIGHT
+#include asm/backlight.h
+#endif
+
static void radeon_legacy_encoder_disable(struct drm_encoder *encoder)
{
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
@@ -39,7 +43,7 @@ static void radeon_legacy_encoder_disable(struct drm_encoder
*encoder)
radeon_encoder-active_device = 0;
}
-static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+static void radeon_legacy_lvds_update(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
@@ -47,15 +51,23 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
uint32_t lvds_gen_cntl, lvds_pll_cntl, pixclks_cntl, disp_pwr_man;
int panel_pwr_delay = 2000;
bool is_mac = false;
+ uint8_t backlight_level;
DRM_DEBUG(\n);
+ lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
+ backlight_level = (lvds_gen_cntl RADEON_LVDS_BL_MOD_LEVEL_SHIFT)
0xff;
+
if (radeon_encoder-enc_priv) {
if (rdev-is_atom_bios) {
struct radeon_encoder_atom_dig *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
} else {
struct radeon_encoder_lvds *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
}
}
@@ -82,11 +94,13 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
lvds_pll_cntl = ~RADEON_LVDS_PLL_RESET;
WREG32(RADEON_LVDS_PLL_CNTL, lvds_pll_cntl);
- lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
- lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
RADEON_LVDS_DIGON | RADEON_LVDS_BLON);
+ lvds_gen_cntl = ~(RADEON_LVDS_DISPLAY_DIS |
+ RADEON_LVDS_BL_MOD_LEVEL_MASK);
+ lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
+ RADEON_LVDS_DIGON | RADEON_LVDS_BLON |
+ (backlight_level
RADEON_LVDS_BL_MOD_LEVEL_SHIFT));
if (is_mac)
lvds_gen_cntl |= RADEON_LVDS_BL_MOD_EN;
- lvds_gen_cntl
Re: [PATCH] drm/radeon/bo: add some fallback placements for VRAM only objects. (v2)
On Die, 2010-04-27 at 12:34 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
v2:
fixes issue identified by Michel when pinning could happen in a busy
placement domain.
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 6a8617b..ab3bc7b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -110,7 +114,7 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
bo-surface_reg = -1;
INIT_LIST_HEAD(bo-list);
- radeon_ttm_placement_from_domain(bo, domain);
+ radeon_ttm_placement_from_domain(bo, domain, false);
/* Kernel allocation are uninterruptible */
r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type,
bo-placement, 0, 0, !kernel, NULL, size,
Not sure it's a good idea to unconditionally allow BOs to be created in
GTT if userspace requested VRAM. E.g. this would at least defeat the
purpose of UploadToScreen if not turn it into pure overhead.
@@ -325,10 +329,10 @@ int radeon_bo_list_validate(struct list_head *head)
if (!bo-pin_count) {
if (lobj-wdomain) {
radeon_ttm_placement_from_domain(bo,
- lobj-wdomain);
+ lobj-wdomain,
false);
} else {
radeon_ttm_placement_from_domain(bo,
- lobj-rdomain);
+ lobj-rdomain,
false);
}
r = ttm_bo_validate(bo-tbo, bo-placement,
true, false, false);
How about something like the below (completely untested) instead? This
should try to respect the userspace request first and only allow falling
back from VRAM to GTT if that failed. (Maybe the new bool parameter
shouldn't be called 'pinned' then but something like
'allow_vram_fallback' and its sense inverted)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d10f246..b6f5177 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -322,17 +322,25 @@ int radeon_bo_list_validate(struct list_head *head)
list_for_each_entry(lobj, head, list) {
bo = lobj-bo;
if (!bo-pin_count) {
+ bool pinned = true;
+
+retry:
if (lobj-wdomain) {
radeon_ttm_placement_from_domain(bo,
- lobj-wdomain);
+lobj-wdomain,
pinned);
} else {
radeon_ttm_placement_from_domain(bo,
- lobj-rdomain);
+lobj-rdomain,
pinned);
}
r = ttm_bo_validate(bo-tbo, bo-placement,
true, false);
- if (unlikely(r))
+ if (unlikely(r)) {
+ if (pinned) {
+ pinned = false;
+ goto retry;
+ }
return r;
+ }
}
lobj-gpu_offset = radeon_bo_gpu_offset(bo);
lobj-tiling_flags = bo-tiling_flags;
@@ -516,7 +520,7 @@ int radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
offset = bo-mem.mm_node-start PAGE_SHIFT;
if ((offset + size) rdev-mc.visible_vram_size) {
/* hurrah the memory is not visible ! */
- radeon_ttm_placement_from_domain(rbo,
RADEON_GEM_DOMAIN_VRAM);
+ radeon_ttm_placement_from_domain(rbo,
RADEON_GEM_DOMAIN_VRAM, false);
rbo-placement.lpfn = rdev-mc.visible_vram_size
PAGE_SHIFT;
r = ttm_bo_validate(bo, rbo-placement, false, true,
false);
if (unlikely(r != 0))
This will impose rbo-placement.lpfn for GTT as well, but it's only
required for VRAM.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
Re: [PATCH] drm/radeon/bo: add some fallback placements for VRAM only objects. (v2)
[ Moving to the new list ]
On Die, 2010-04-27 at 12:34 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
v2:
fixes issue identified by Michel when pinning could happen in a busy
placement domain.
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 6a8617b..ab3bc7b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -64,17 +64,21 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object
*bo)
return false;
}
-void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
+void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain,
bool pinned)
{
- u32 c = 0;
+ u32 c = 0, b = 0;
rbo-placement.fpfn = 0;
rbo-placement.lpfn = 0;
rbo-placement.placement = rbo-placements;
- rbo-placement.busy_placement = rbo-placements;
+ rbo-placement.busy_placement = rbo-busy_placements;
if (domain RADEON_GEM_DOMAIN_VRAM)
rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_VRAM;
+ /* add busy placement to TTM if VRAM is only option */
+ if (domain == RADEON_GEM_DOMAIN_VRAM pinned == false) {
+ rbo-busy_placements[b++] = TTM_PL_MASK_CACHING |
TTM_PL_FLAG_TT;
+ }
if (domain RADEON_GEM_DOMAIN_GTT)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
if (domain RADEON_GEM_DOMAIN_CPU)
@@ -82,7 +86,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
*rbo, u32 domain)
if (!c)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo-placement.num_placement = c;
- rbo-placement.num_busy_placement = c;
+ rbo-placement.num_busy_placement = b;
}
int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
BTW, this means there won't be any busy placements if (domain !=
RADEON_GEM_DOMAIN_VRAM || pinned). Not sure if that's a problem.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: R300 AD only has one quad pipe.
From: Michel Dänzer daen...@vmware.com
Gleaned from the Mesa code.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27355 .
Signed-off-by: Michel Dänzer daen...@vmware.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/r300.c |6 +++---
drivers/gpu/drm/radeon/radeon_cp.c | 10 ++
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 219d410..3dae012 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -327,12 +327,12 @@ void r300_gpu_init(struct radeon_device *rdev)
{
uint32_t gb_tile_config, tmp;
- /* FIXME: rv380 one pipes ? */
- if ((rdev-family == CHIP_R300) || (rdev-family == CHIP_R350)) {
+ if ((rdev-family == CHIP_R300 rdev-pdev-device != 0x4144) ||
+ (rdev-family == CHIP_R350)) {
/* r300,r350 */
rdev-num_gb_pipes = 2;
} else {
- /* rv350,rv370,rv380 */
+ /* rv350,rv370,rv380,r300 AD */
rdev-num_gb_pipes = 1;
}
rdev-num_z_pipes = 1;
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index dc6eba6..419630d 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -417,8 +417,9 @@ static int radeon_do_wait_for_idle(drm_radeon_private_t *
dev_priv)
return -EBUSY;
}
-static void radeon_init_pipes(drm_radeon_private_t *dev_priv)
+static void radeon_init_pipes(struct drm_device *dev)
{
+ drm_radeon_private_t *dev_priv = dev-dev_private;
uint32_t gb_tile_config, gb_pipe_sel = 0;
if ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV530) {
@@ -436,11 +437,12 @@ static void radeon_init_pipes(drm_radeon_private_t
*dev_priv)
dev_priv-num_gb_pipes = ((gb_pipe_sel 12) 0x3) + 1;
} else {
/* R3xx */
- if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R300) ||
+ if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R300
+dev-pdev-device != 0x4144) ||
((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R350)) {
dev_priv-num_gb_pipes = 2;
} else {
- /* R3Vxx */
+ /* RV3xx/R300 AD */
dev_priv-num_gb_pipes = 1;
}
}
@@ -736,7 +738,7 @@ static int radeon_do_engine_reset(struct drm_device * dev)
/* setup the raster pipes */
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R300)
- radeon_init_pipes(dev_priv);
+ radeon_init_pipes(dev);
/* Reset the CP ring */
radeon_do_cp_reset(dev_priv);
--
1.7.0.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AGP force use of scratch page
-scratch_page_page,
AFAICT this just removes the needs_scratch_page flag but doesn't bind
all table entries to the scratch page. Am I missing something?
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index d89da4a..d54d674 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -171,7 +171,7 @@ static int uninorth_insert_memory(struct agp_memory *mem,
off_t pg_start, int ty
gp = (u32 *) agp_bridge-gatt_table[pg_start];
for (i = 0; i mem-page_count; ++i) {
- if (gp[i]) {
+ if (!PGE_EMPTY(agp_bridge, gp[i])) {
dev_info(agp_bridge-dev-dev,
uninorth_insert_memory: entry 0x%x occupied
(%x)\n,
i, gp[i]);
This won't work for pre-U3 bridges, as bound table entries are marked by
setting bit 0. (Maybe the driver just shouldn't use
agp_generic_mask_memory?)
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
On Tue, 2010-03-30 at 05:34 +0100, Dave Airlie wrote: Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), [...] While I was able to work around the lockups by making the AGP driver never unbind a GTT entry, I think it's rather a radeon issue - how is the AGP driver supposed to know when it's safe to unbind an entry? That change had lots of other issues anyway, thanks for reverting it. [...] and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. Unfortunately, that's not true in all cases. The change itself mentions that the new reset code is unreliable for R3xx generation GPUs, and indeed with my RV350 it now turns my box into a brick immediately on a GPU lockup most of the time whereas previously it was usually able to recover at least in some cases, e.g. falling back to PCI mode after trying to use a non-working AGP transfer mode. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
On Fri, 2010-03-26 at 19:20 +0100, Michel Dänzer wrote: On Thu, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: 2010/3/25 Michel Dänzer mic...@daenzer.net: On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. Care to try in pci mode? see if helps, it might be just straining AGP a bit more, maybe try 1x as well if you aren't already in it. After various more tests, the gist of it seems to be that rendering to GTT with the 3D engine tends to lock up whereas the 2D and DMA engines work fine (otherwise I probably would have run into this a long time ago at BO eviction time). Maybe some kind of synchronization issue resulting in the 3D engine trying to access GTT memory which isn't bound yet / anymore? I think I've confirmed this theory by changing the AGP driver to bind the AGP scratch page instead of really unbinding a GTT entry. That prevents the lockups from occurring. Even so though, this change hurts performance, presumably because BOs evicted from VRAM (or not going in in the first place) aren't getting (back) in. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
On Fri, 2010-03-26 at 19:56 +, Matthew Garrett wrote: As far as the lockups go, I think this is due to memory access during reclock. Nothing should be coming from the cp, but we may be getting accesses from the crtc if we miss vblank (there's a bit in the crtc control that can deal with this), but more importantly we're doing nothing to prevent unaccelerated fallbacks touching vram during reclock. I can provoke lockups more easily using x11perf which probably triggers several of those, so I lean towards that being something we need to fix before looking for other potential issues. Have you tried making RADEONPrepareAccess_CS() in the X driver always return FALSE (you may also need to prevent RADEONUploadToScreenCS() from returning FALSE if the BO isn't busy) to confirm this? That should prevent any direct CPU access to VRAM, at least as long as you don't hit any software fallbacks in the 3D driver. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
On Thu, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: 2010/3/25 Michel Dänzer mic...@daenzer.net: On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. Care to try in pci mode? see if helps, it might be just straining AGP a bit more, maybe try 1x as well if you aren't already in it. After various more tests, the gist of it seems to be that rendering to GTT with the 3D engine tends to lock up whereas the 2D and DMA engines work fine (otherwise I probably would have run into this a long time ago at BO eviction time). Maybe some kind of synchronization issue resulting in the 3D engine trying to access GTT memory which isn't bound yet / anymore? I don't know why that is - maybe something doesn't properly deal with BOs getting placed differently in some cases now - but anyway I suspect the implications of this change haven't been fully thought through: The log message sounds as though the change was mainly written with radeon_bo_create() / radeon_bo_list_validate() in mind, but radeon_ttm_placement_from_domain() is also called from other places: * radeon_bo_pin(): The change could lead to a BO being pinned to GTT instead of VRAM, which would probably be bad. * radeon_evict_flags(): The change might have undesirable consequences here as well, not sure. The first might be bad, [...] I actually saw this happen once for the scanout BO of a second X server, and it resulted in pretty spectacular cascaded failure. This confirmed my suspicion that it's a very bad idea for radeon_bo_pin(). In summary I'm afraid this isn't really a good solution for what you were trying to achieve, and it's actually breaking things that were working before, so I think it should be reverted. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Only restrict BO to visible VRAM size when pinning to VRAM.
From: Michel Dänzer daen...@vmware.com
This prevented radeon.test=1 from testing transfers from/to GTT beyond the
visible VRAM size.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_object.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index c286cda..6745689 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -189,8 +189,10 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64
*gpu_addr)
return 0;
}
radeon_ttm_placement_from_domain(bo, domain);
- /* force to pin into visible video ram */
- bo-placement.lpfn = bo-rdev-mc.visible_vram_size PAGE_SHIFT;
+ if (domain == RADEON_GEM_DOMAIN_VRAM) {
+ /* force to pin into visible video ram */
+ bo-placement.lpfn = bo-rdev-mc.visible_vram_size
PAGE_SHIFT;
+ }
for (i = 0; i bo-placement.num_placement; i++)
bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
r = ttm_bo_validate(bo-tbo, bo-placement, false, false);
--
1.7.0.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. I don't know why that is - maybe something doesn't properly deal with BOs getting placed differently in some cases now - but anyway I suspect the implications of this change haven't been fully thought through: The log message sounds as though the change was mainly written with radeon_bo_create() / radeon_bo_list_validate() in mind, but radeon_ttm_placement_from_domain() is also called from other places: * radeon_bo_pin(): The change could lead to a BO being pinned to GTT instead of VRAM, which would probably be bad. * radeon_evict_flags(): The change might have undesirable consequences here as well, not sure. I don't think the way we currently use the same arrays for normal and busy placement makes a lot of sense, but we probably need a better mechanism to specify which placements are desirable / acceptable in each case. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
On Don, 2010-03-25 at 03:35 +, Dave Airlie wrote: [...] I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. Actually, I'm not sure that's true in all cases. With Jerome's changes, a GPU lockup seems to basically turn my PowerBook into a pretty brick right away. It would be preferable to have non-working local display (actually, it should be possible to fall back to software for 2D?) but be able to log in via SSH and do post-mortem analysis and reboot cleanly. That said, I don't know if Jerome's changes actually made things any worse, as I hadn't run into GPU lockups for a while before yesterday (see my other list post). But the commit logs did mention that the GPU reset is unlikely to work with the R300 generation... (though I suspect the fact this isn't x86 may not exactly help) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: 2010/3/25 Michel Dänzer mic...@daenzer.net: On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. Care to try in pci mode? see if helps, it might be just straining AGP a bit more, Ugh, k I'll try... but that incurs such a huge performance hit that the result might not be very meaningful I'm afraid. maybe try 1x as well if you aren't already in it. I am, for some reason neither 2x nor 4x has ever worked reliably with KMS although 4x was rock solid with UMS. I don't know why that is - maybe something doesn't properly deal with BOs getting placed differently in some cases now - but anyway I suspect the implications of this change haven't been fully thought through: The log message sounds as though the change was mainly written with radeon_bo_create() / radeon_bo_list_validate() in mind, but radeon_ttm_placement_from_domain() is also called from other places: * radeon_bo_pin(): The change could lead to a BO being pinned to GTT instead of VRAM, which would probably be bad. * radeon_evict_flags(): The change might have undesirable consequences here as well, not sure. The first might be bad, but the second should be okay, I'll take a closer look in the morning. What about that there are now usually no busy placements specified, couldn't that be a problem? I don't think the way we currently use the same arrays for normal and busy placement makes a lot of sense, but we probably need a better mechanism to specify which placements are desirable / acceptable in each case. Well its not really a huge matrix of choices, I'm guessing we need more info from userspace, or use the info better. Though in theory everything should work in GTT or VRAM equally well just slower. E.g. scanout from GTT could easily exceed the available bandwidth. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
On Thu, 2010-03-25 at 11:11 +0100, Michel Dänzer wrote: On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: 2010/3/25 Michel Dänzer mic...@daenzer.net: On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On constrained r100 systems compiz would fail to start due to a lack of memory, we can just fallback place the objects rather than completely failing it works a lot better. Signed-off-by: Dave Airlie airl...@redhat.com This change seems to trigger or at least greatly expedite GPU lockups on my PowerBook. With the change applied, my normal X session locked up the GPU after just a few minutes several times. Now with it reverted it's back to the previous stability. Care to try in pci mode? see if helps, it might be just straining AGP a bit more, Ugh, k I'll try... but that incurs such a huge performance hit that the result might not be very meaningful I'm afraid. It didn't lock up in a couple of hours of suffering through PCI, so maybe it is an AGP problem, or maybe PCI is just too slow to trigger it... More likely the former though I guess. I don't know why that is - maybe something doesn't properly deal with BOs getting placed differently in some cases now - but anyway I suspect the implications of this change haven't been fully thought through: The log message sounds as though the change was mainly written with radeon_bo_create() / radeon_bo_list_validate() in mind, but radeon_ttm_placement_from_domain() is also called from other places: * radeon_bo_pin(): The change could lead to a BO being pinned to GTT instead of VRAM, which would probably be bad. * radeon_evict_flags(): The change might have undesirable consequences here as well, not sure. The first might be bad, but the second should be okay, I'll take a closer look in the morning. What about that there are now usually no busy placements specified, couldn't that be a problem? FWIW I tried re-using the normal placements for missing busy placements, didn't help. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Die, 2010-03-23 at 12:32 -0700, Jesse Barnes wrote: On Thu, 4 Mar 2010 15:20:46 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 05 Mar 2010 00:16:45 +0100 Michel Dänzer mic...@daenzer.net wrote: On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. I don't have access to create the new lists, but Daniel or Tollef should. We may as well keep you guys as admins unless someone volunteers that you're ok with; but hopefully FDO will make the admin job a little easier/faster. Brian and Michel, did you guys get what you need to move the lists? AFAIK Tollef created them, you just need to copy the subscriber lists over and announce it I think? This is the first time I've heard of new lists having been created... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Commit 96a4c8d50de20da865296a380b996f73204d6b34 breaks PowerBook LVDS
On Tue, 2010-03-16 at 10:56 -0400, Alex Deucher wrote:
2010/3/16 Michel Dänzer mic...@daenzer.net:
Commit 96a4c8d50de20da865296a380b996f73204d6b34 ('drm/radeon/kms: fix
i2c prescale calc on older radeons') breaks LVDS on my RV350 PowerBook
again. Reverting just that commit on top of drm-radeon-testing commit
589468458fa964c2020e23e4d9353be2ef8bd3be fixes it.
Do any of the suggestions on bug 26430 help?
http://bugs.freedesktop.org/show_bug.cgi?id=26430
I've tried i2c_clock = 50/10/100 and m = loop - 1, no luck. I also added
debugging output to verify that sclk seems sane the calculations seem to
take effect as expected:
[ 59.138772] [drm] sclk=44550
[ 59.138775] [drm] nm=2227
[ 59.138779] [drm] loop=48 n=47 m=46 = prescale=0x2f2e
So, did that commit actually fix anything? :} It regresses at least for
me and doesn't seem to help for the bug it claims it 'should fix'...
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Tue, 2010-03-16 at 13:56 +, James Simmons wrote: The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. Again, the issue is not userspace but that fb_ops hooks can be called from interrupt context etc. This should not happen. The VT layer is protected from calling in the interrupt context. TNor does fbcon call any fb_ops methods from a irq. E.g. printk? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Commit 96a4c8d50de20da865296a380b996f73204d6b34 breaks PowerBook LVDS
Commit 96a4c8d50de20da865296a380b996f73204d6b34 ('drm/radeon/kms: fix
i2c prescale calc on older radeons') breaks LVDS on my RV350 PowerBook
again. Reverting just that commit on top of drm-radeon-testing commit
589468458fa964c2020e23e4d9353be2ef8bd3be fixes it.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Commit 96a4c8d50de20da865296a380b996f73204d6b34 breaks PowerBook LVDS
On Tue, 2010-03-16 at 10:56 -0400, Alex Deucher wrote:
2010/3/16 Michel Dänzer mic...@daenzer.net:
Commit 96a4c8d50de20da865296a380b996f73204d6b34 ('drm/radeon/kms: fix
i2c prescale calc on older radeons') breaks LVDS on my RV350 PowerBook
again. Reverting just that commit on top of drm-radeon-testing commit
589468458fa964c2020e23e4d9353be2ef8bd3be fixes it.
Do any of the suggestions on bug 26430 help?
http://bugs.freedesktop.org/show_bug.cgi?id=26430
I can try, but it'll probably take a while...
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Sun, 2010-03-14 at 07:01 +1000, Dave Airlie wrote: The big issue we have with resizing the buffer is userspace mmaps of the fbdev device, and invalidation. Previous thread of unresolvedness is here. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html Actually AFAIR (and reading through it again seems to confirm this) userspace mappings should be fully handled by the last patch series I posted back then[0]. The problem was that the struct fb_ops hooks may be called by the kernel from pretty much any context, and neither I nor Thomas was sure how to handle the TTM locking given that. Maybe James has ideas for this given his better familiarity with fbdev internals. [0] Though that was really only about making it possible to unpin the fbcon BO while it isn't being displayed, resizing it might involve other issues I'm not aware of. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] libdrm_radeon: Optimize cs_gem_reloc to do less looping. (V2)
On Fri, 2010-03-12 at 14:50 +0200, Pauli Nieminen wrote: bo-referenced_in_cs is checked if bo is already in cs. Adding and removing reference in bo is done with atomic operations to allow parallel access to a bo from multiple contexts. cs-id generation code quarentees there is not duplicated ids which limits number of cs-ids to 32. If there is more cs objects rest will get id 0. V2: - Fix configure to check for atomics operations if libdrm_radeon is selected and libdrm_intel is not. - Make atomic operations private to libdrm_radeon. - Add warning messages if disabling automaticaly selected libdrm_(radeon|intel) This optimization decreases cs_write_reloc share of torcs profiling from 4.3% to 2.6%. Signed-off-by: Pauli Nieminen suok...@gmail.com Tested-by: Michel Dänzer mic...@daenzer.net -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. What do you think the average user will care about more? * Seeing kernel oops/panic output about once in a lifetime. * Being able to start/use X in the first place and enabling it to use all of VRAM. Personally, I've never even seen any kernel oops/panic output despite numerous opportunities for that in the couple of months I've been using KMS. But I have spent considerable time and effort trying to get rid of the pinned fbcon BO. If the oops/panic output is the only thing preventing that, maybe that should only be enabled via some module option for developers. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] libdrm_radeon: Optimize cs_gem_reloc to do less looping.
On Wed, 2010-03-10 at 20:42 +0200, Pauli Nieminen wrote: bo-referenced_in_cs is checked if bo is already in cs. Adding and removing reference in bo is done with atomic operations to allow parallel access to a bo from multiple contexts. cs-id generation code quarentees there is not duplicated ids which limits number of cs-ids to 32. If there is more cs objects rest will get id 0. This optimization decreases cs_write_reloc share of torcs profiling from 4.3% to 2.6%. Signed-off-by: Pauli Nieminen suok...@gmail.com This also needs something like the below for configure to verify that atomic ops are available. diff --git a/configure.ac b/configure.ac index fe00176..e419dd7 100644 --- a/configure.ac +++ b/configure.ac @@ -173,7 +173,7 @@ if test x$HAVE_LIBUDEV = xyes; then fi AM_CONDITIONAL(HAVE_LIBUDEV, [test x$HAVE_LIBUDEV = xyes]) -if test x$INTEL != xno; then +if test x$INTEL != xno || test x$RADEON != xno; then # Check for atomic intrinsics AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives, [ @@ -206,13 +206,23 @@ if test x$INTEL != xno; then fi if test x$drm_cv_atomic_primitives = xnone; then - if test x$INTEL != xauto; then + if test x$INTEL = xyes; then AC_MSG_ERROR([libdrm_intel depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for Intel GPUs by passing --disable-intel to ./configure]) else INTEL=no fi + if test x$RADEON = xyes; then + AC_MSG_ERROR([libdrm_radeon depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for Radeon GPUs by passing --disable-radeon to ./configure]) + else + RADEON=no + fi else - INTEL=yes + if test x$INTEL != xno; then + INTEL=yes + fi + if test x$RADEON != xno; then + RADEON=yes + fi fi fi -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] libdrm_radeon: Optimize reloc writing to do less looping.
On Wed, 2010-03-10 at 18:20 +0200, Pauli Nieminen wrote:
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already.
To quarentee that there is no other cs with same id number of CS that can have
id is limited to 32. Adding and remocing reference in bo is done with atomic
operations to allow parallel access to a bo from multiple contexts.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Signed-off-by: Pauli Nieminen suok...@gmail.com
[...]
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..83aabea 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -68,6 +69,66 @@ struct cs_gem {
struct radeon_bo_int**relocs_bo;
};
+
+#if !defined(__GNUC__) || __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__
2)
+/* no built in sync support in compiler define place holders */
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a += val;
+ return val;
+}
+
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a -= val;
+ return val;
+}
+#endif
This doesn't look like it could build... presumably the latter should be
called __sync_sub_and_fetch()?
Do these stand any chance of working properly in circumstances where
atomicity is actually important though?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
On Fri, 2010-03-05 at 16:11 -0800, Jesse Barnes wrote: On Fri, 5 Mar 2010 23:19:13 +0100 olafbuddenha...@gmx.net wrote: Hi, On Thu, Mar 04, 2010 at 12:37:23PM -0800, Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, Err, how would moving the list to fdo help with the non-subscriber aspect?... I was thinking that managing the moderation queue would be faster; sf.net is always horribly slow for me, but fdo is usually pretty quick. Can't say I've really noticed any difference, probably thanks to the awesome listadmin tool. But it certainly won't hurt. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 15:19 -0800, Linus Torvalds wrote: What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Nothing. :) Only the major version is supposed to signify outright incompatibility, the minor version signifies backwards compatibility within the same major version, and the patchlevel has no impact on the interface. All the other drivers are basically following this, only nouveau is abusing the patchlevel as a major version for reasons beyond me. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/ttm: add pool wc/uc page allocator
On Tue, 2010-03-02 at 00:32 +0200, Pauli Nieminen wrote: bo allocation is still too expensive operation for dma buffers in classic mesa. It takes quite a lot cpu time in bind memory (agp system) and ttm_mem_global functions. Would it be possible to move some parts those expensive operations into pool fill and pool free code? Maybe we need userspace BO sub-allocation and/or caching. At least for the 'DMA' buffers it should be simple for userspace to keep a round robin list of buffers. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Sat, 2010-02-27 at 10:33 +0100, Rafał Miłecki wrote: W dniu 26 lutego 2010 20:01 użytkownik Ville Syrjälä syrj...@sci.fi napisał: Disabling the condition check doesn't make sense. You could use a completion. init_completion(vbl_irq); enable_vbl_irq(); wait_for_completion(vbl_irq); disable_vbl_irq(); and call complete(vbl_irq) in the interrupt handler. The same would of course work with just some flag or counter and a wait queue. Ouch, I can see it gone bad already. Firstly I simply just wanted to avoid condition in wait_event_*. It looked unnecessary as I got interrupts (signals). So this code runs in user process context? If so, it should return to userspace ASAP on signal receipt, otherwise e.g. smoothness of X mouse movement may suffer. If that's a problem, then maybe the code should run in a different context, e.g. a tasklet or some kind of worker kernel thread. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: request for rebasing
On Thu, 2010-02-25 at 10:42 +0100, Rafał Miłecki wrote: Dave, we have some commits in drm-linus that are not present in drm-radeon-testing. Maybe this is the case with other active branches as well, don't know. Could you rebase branches to be more clear, please? Maybe rebasing agains .33 even? I think it's great to keep branches based on the last release as long as possible. It allows testing DRM changes easily without pulling in random other changes. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vmwgfx: lack of 3D acceleration
On Thu, 2010-02-18 at 16:20 +0100, Marco wrote: What Xorg says is this: II) vmwgfx(0): Using exact sizes for initial modes II) vmwgfx(0): Output LVDS1 using initial mode 800x600 II) vmwgfx(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. ==) vmwgfx(0): DPI set to (96, 96) I wonder why there isn't any mention here of loading the dri2 or at least exa and fb modules... Please provide the full Xorg.0.log file. II) vmwgfx(0): 2D Acceleration is disabled II) vmwgfx(0): Fallback debugging is enabled II) vmwgfx(0): 3D Acceleration is disabled Did you check that DRI2 was enabled for the xserver and Gallium build? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Test rdev-bios centrally in combios_get_table_offset().
From: Michel Dänzer daen...@vmware.com
It's happened time and time again (most recently with the support for EDID
hardcoded in the BIOS ROM) that new code didn't check for rdev-bios being
non-NULL before triggering dereferences of it. This would result in an
oops/panic on setups with no BIOS ROM. Hopefully this central test will be
more robust.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_combios.c | 40 +++---
1 files changed, 4 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 26fb424..9989d22 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -150,6 +150,9 @@ static uint16_t combios_get_table_offset(struct drm_device
*dev,
int rev;
uint16_t offset = 0, check_offset;
+ if (!rdev-bios)
+ return 0;
+
switch (table) {
/* absolute offset tables */
case COMBIOS_ASIC_INIT_1_TABLE:
@@ -621,9 +624,6 @@ bool radeon_combios_get_clock_info(struct drm_device *dev)
int8_t rev;
uint16_t sclk, mclk;
- if (rdev-bios == NULL)
- return false;
-
pll_info = combios_get_table_offset(dev, COMBIOS_PLL_INFO_TABLE);
if (pll_info) {
rev = RBIOS8(pll_info);
@@ -748,9 +748,6 @@ struct radeon_encoder_primary_dac
*radeon_combios_get_primary_dac_info(struct
if (!p_dac)
return NULL;
- if (rdev-bios == NULL)
- goto out;
-
/* check CRT table */
dac_info = combios_get_table_offset(dev, COMBIOS_CRT_INFO_TABLE);
if (dac_info) {
@@ -767,7 +764,6 @@ struct radeon_encoder_primary_dac
*radeon_combios_get_primary_dac_info(struct
found = 1;
}
-out:
if (!found) /* fallback to defaults */
radeon_legacy_get_primary_dac_info_from_table(rdev, p_dac);
@@ -781,9 +777,6 @@ radeon_combios_get_tv_info(struct radeon_device *rdev)
uint16_t tv_info;
enum radeon_tv_std tv_std = TV_STD_NTSC;
- if (rdev-bios == NULL)
- return tv_std;
-
tv_info = combios_get_table_offset(dev, COMBIOS_TV_INFO_TABLE);
if (tv_info) {
if (RBIOS8(tv_info + 6) == 'T') {
@@ -887,9 +880,6 @@ struct radeon_encoder_tv_dac
*radeon_combios_get_tv_dac_info(struct
if (!tv_dac)
return NULL;
- if (rdev-bios == NULL)
- goto out;
-
/* first check TV table */
dac_info = combios_get_table_offset(dev, COMBIOS_TV_INFO_TABLE);
if (dac_info) {
@@ -951,7 +941,6 @@ struct radeon_encoder_tv_dac
*radeon_combios_get_tv_dac_info(struct
}
}
-out:
if (!found) /* fallback to defaults */
radeon_legacy_get_tv_dac_info_from_table(rdev, tv_dac);
@@ -1039,11 +1028,6 @@ struct radeon_encoder_lvds
*radeon_combios_get_lvds_info(struct radeon_encoder
int tmp, i;
struct radeon_encoder_lvds *lvds = NULL;
- if (rdev-bios == NULL) {
- lvds = radeon_legacy_get_lvds_info_from_regs(rdev);
- goto out;
- }
-
lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
if (lcd_info) {
@@ -1144,7 +1128,7 @@ struct radeon_encoder_lvds
*radeon_combios_get_lvds_info(struct radeon_encoder
DRM_INFO(No panel info found in BIOS\n);
lvds = radeon_legacy_get_lvds_info_from_regs(rdev);
}
-out:
+
if (lvds)
encoder-native_mode = lvds-native_mode;
return lvds;
@@ -1196,9 +1180,6 @@ bool radeon_legacy_get_tmds_info_from_combios(struct
radeon_encoder *encoder,
int i, n;
uint8_t ver;
- if (rdev-bios == NULL)
- return false;
-
tmds_info = combios_get_table_offset(dev, COMBIOS_DFP_INFO_TABLE);
if (tmds_info) {
@@ -1278,9 +1259,6 @@ bool radeon_legacy_get_ext_tmds_info_from_combios(struct
radeon_encoder *encoder
enum radeon_combios_ddc gpio;
struct radeon_i2c_bus_rec i2c_bus;
- if (rdev-bios == NULL)
- return false;
-
tmds-i2c_bus = NULL;
if (rdev-flags RADEON_IS_IGP) {
offset = combios_get_table_offset(dev, COMBIOS_I2C_INFO_TABLE);
@@ -2006,9 +1984,6 @@ bool radeon_get_legacy_connector_info_from_bios(struct
drm_device *dev)
struct radeon_i2c_bus_rec ddc_i2c;
struct radeon_hpd hpd;
- if (rdev-bios == NULL)
- return false;
-
conn_info = combios_get_table_offset(dev, COMBIOS_CONNECTOR_INFO_TABLE);
if (conn_info) {
for (i = 0; i 4; i++) {
@@ -2385,10 +2360,6 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
rdev-pm.default_power_state = NULL;
rdev-pm.current_power_state = NULL;
- /* XXX mac/sparc cards
Re: [PATCH 1/2] drm/vmwgfx: Request SVGA version 2
On Thu, 2010-01-28 at 18:59 +, Jakob Bornecrantz wrote:
From: Peter Hanzel hanzelpe...@gmail.com
This fixes the driver not loading on older versions of VMware.
Signed-off-by: Peter Hanzel hanzelpe...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f47ff2c..8e68333 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -209,6 +209,7 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
{
struct vmw_private *dev_priv;
int ret;
+ long svga_id;
This should be uint32_t rather than long.
@@ -239,6 +240,13 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev_priv-mmio_start = pci_resource_start(dev-pdev, 2);
mutex_lock(dev_priv-hw_mutex);
+
+ vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
+ svga_id = vmw_read(dev_priv, SVGA_REG_ID);
+ if (svga_id == SVGA_ID_2) {
+ DRM_INFO(We have SVGA ID 2\n);
+ }
+
dev_priv-capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);
if (dev_priv-capabilities SVGA_CAP_GMR) {
Shouldn't this be something like:
vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
svga_id = vmw_read(dev_priv, SVGA_REG_ID);
if (svga_id != SVGA_ID_2) {
DRM_ERROR(Unsupported SVGA ID 0x%lx\n, svga_id);
/* Bail */
}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
drm-radeon-testing commit 8131660130d3dc2629a150d47e6a04c8a1a6244b breaks LVDS on my PowerBook
Hi Alex,
your commit 8131660130d3dc2629a150d47e6a04c8a1a6244b ('drm/radeon/kms:
add support for hw i2c on r1xx-r5xx') breaks LVDS on my PowerBook. It
looks kinda like blooming, though I can actually make out a higly
distorted part of what it's supposed to display, and there's a
panel/backlight blinking around every second or so.
These errors from dmesg might be relevant (nothing's connected to the
DVI connector):
[0.355445] [drm] Radeon Display Connectors
[0.355473] [drm] Connector 0:
[0.355490] [drm] LVDS
[0.355509] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[0.355533] [drm] Encoders:
[0.30] [drm] LCD1: INTERNAL_LVDS
[0.355570] [drm] Connector 1:
[0.355587] [drm] DVI-I
[0.355602] [drm] HPD2
[0.355620] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[0.355645] [drm] Encoders:
[0.355661] [drm] DFP2: INTERNAL_DVO1
[0.355681] [drm] CRT1: INTERNAL_DAC1
[0.355700] [drm] Connector 2:
[0.355716] [drm] S-video
[0.355732] [drm] Encoders:
[0.355748] [drm] TV1: INTERNAL_DAC2
[0.591623] [drm:edid_is_valid] *ERROR* Raw EDID:
[0.591652] 3a1 ff bf bf fd ff ff ff ff ff ff ff fd ff ff ff
[0.591661] 3ff ff ff ff ff ef a1 ff ff ff a1 7f ff ff a1 ff
[0.591669] 3fb ff a1 ff ff ff a1 ff ff ff a1 fe ff ff a1 ff
[0.591678] 3f7 ff ff ff ff ff ff ff ff bf bf ff ff ff ff fd
[0.591686] 3ff ff ff ff ef ff ff ff ff a1 ff ff ff a1 ff fb
[0.591695] 3ff a1 ff ff ff a1 ff ff ff a1 fe ff ff a1 ff ff
[0.591704] 3ff ff ff f7 ff ff ff ff bf bf ff ff ff ff fd ff
[0.591726] 3ff ff ff ef ff ff ff ef a1 ff ff ff a1 7f fb ff
[0.591733]
[0.634535] [drm:edid_is_valid] *ERROR* Raw EDID:
[0.634559] 3a1 ff ff ff fd ff ff ff fd ff ff ff ff ef a1 ff
[0.634568] 3ff ff a1 7f ff ff a1 ff fb ff a1 ff ff ff a1 ff
[0.634576] 3ff df a1 fe ff ff a1 ff ff ff ff ff 08 ff ff ff
[0.634585] 3ff bf bf ff ff 00 00 04 10 4e 4e 9c 00 00 00 00
.NN.
[0.634594] 310 a1 0e 0f 01 a1 83 80 20 a1 16 7c 0a a1 87 f5
..|
[0.634602] 394 a1 57 4f 8c a1 26 27 50 a1 54 00 00 00 00 01
..WO..'P.T.
[0.634611] 301 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
[0.634620] 3a1 01 01 01 a1 b8 28 a0 a1 40 51 c0 a1 10 30 40
..(@q...0@
[0.634627]
[0.676987] [drm:edid_is_valid] *ERROR* Raw EDID:
[0.677010] 3a1 89 ff a1 ff ff ff a1 7f fb ff a1 ff ff ff a1
[0.677019] 3ff ff ff a1 fe ff ff a1 ff ff ff ff ff ff ff ff
[0.677028] 3ff ff bf bf ff ff ff ff fd ff ff ff ff ef ff ff
[0.677036] 3ff ff a1 7f ff ff a1 7f fb ff a1 ff ff ff a1 ff
[0.677045] 3ff df a1 fe ff ff a1 ff ff ff ff ff f7 ff ff ff
[0.677054] 3ff bf bf ff ff ff ff fd ff ff ff ff ff ff ff ff
[0.677062] 3ef a1 ff ff ff a1 7f ff ff a1 ff fb ff a1 ff ff
[0.677071] 3ff a1 ff ff ff a1 fe ff ff a1 ff f7 ff ff ff ff
[0.677078]
[0.719430] [drm:edid_is_valid] *ERROR* Raw EDID:
[0.719453] 3a1 ff df a1 ff ff df a1 fe ff ff a1 ff ff ff ff
[0.719462] 3ff ff ff ff ff ff bf bf ff ff ff ff fd ff ff ff
[0.719471] 3ff ef ff ff ff ff a1 ff ff ff a1 ff fb ff a1 ff
[0.719479] 3ff ff a1 ff ff ff a1 fe ff ff a1 ff ff ff ff ff
[0.719488] 3f7 ff ff ff ff bf bf ff ff ff ff fd ff ff ff ff
[0.719497] 3ef ff ff ff ff a1 ff ff ff a1 7f fb ff a1 ff ff
[0.719505] 3ff a1 ff ff df a1 ff ff ff a1 fe ff ff a1 ff f7
[0.719514] 3ff ff ff ff ff ff ff ff bf bf fd ff ff ff fd ff
[0.719521]
[0.761872] [drm:edid_is_valid] *ERROR* Raw EDID:
[0.761895] 3a1 ff ff bf bf ff ff ff ff fd ff ff ff ff ef ff
[0.761904] 3ff ff ff a1 ff ff ff a1 ff ff ff a1 ff ff ff a1
[0.761912] 3ff ff df a1 fe ff ff a1 ff ff ff ff ff f7 ff ff
[0.761921] 3ff ff bf bf ff ff ff ff fd ff ff ff ff ef ff ff
[0.761930] 3ff ff a1 ff ff ff a1 7f ff ff a1 ff ff ff a1 ff
[0.761938] 3ff df a1 ff ff ff a1 fe ff ff a1 ff f7 ff ff ff
[0.761947] 3ff bf bf ff ff bf bf fd ff ff ff ff ff ff ff ff
[0.761956] 3ef a1 ff ff ff a1 7f ff ff a1 ff fb ff a1 ff ff
[0.761963]
[0.761977] radeon :00:10.0: LVDS-1: EDID invalid.
[0.762960] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
--
Earthling Michel Dänzer |http://www.vmware.com
Re: drm-radeon-testing commit 8131660130d3dc2629a150d47e6a04c8a1a6244b breaks LVDS on my PowerBook
On Wed, 2010-01-27 at 10:30 -0500, Alex Deucher wrote:
2010/1/27 Michel Dänzer mic...@daenzer.net:
your commit 8131660130d3dc2629a150d47e6a04c8a1a6244b ('drm/radeon/kms:
add support for hw i2c on r1xx-r5xx') breaks LVDS on my PowerBook. It
looks kinda like blooming, though I can actually make out a higly
distorted part of what it's supposed to display, and there's a
panel/backlight blinking around every second or so.
Hmm, maybe the mac's edid is wired up such that hw i2c doesn't work or
the prescale calculation for your system needs adjusting. Switching
back to sw i2c should fix it in the meantime. Set the hw_capable bool
in the radeon_i2c_bus_rec struct to false.
Presumably that would work, as the previous commit ('drm/radeon/kms: add
radeon i2c algo') works? [0]
For the prescale:
u32 prescale = (((rdev-clock.default_sclk * 10)/(4 * 128 * 100) + 1)
8) + 128;
does rdev-clock.default_sclk get initialized properly on the mac? If
not, you can use radeon_get_engine_clock to read back the value from
the regs.
Looks like it in /sys/kernel/debug/dri/0/radeon_pm_info:
state: PM_STATE_DISABLED
default engine clock: 445500 kHz
current engine clock: 445500 kHz
default memory clock: 240750 kHz
current memory clock: 240750 kHz
[0] Though actually I notice there's a warning in dmesg with that as
well:
[0.355965] [drm] TV1: INTERNAL_DAC2
[0.356037]
[0.356040] =
[0.356072] [ INFO: possible recursive locking detected ]
[0.356096] 2.6.32.6 #434
[0.356112] -
[0.356136] swapper/1 is trying to acquire lock:
[0.356158] (adap-bus_lock){+.+...}, at: [c0355910]
i2c_transfer+0x84/0x178
[0.356219]
[0.356221] but task is already holding lock:
[0.356249] (adap-bus_lock){+.+...}, at: [c0355910]
i2c_transfer+0x84/0x178
[0.356294]
[0.356296] other info that might help us debug this:
[0.356328] 1 lock held by swapper/1:
[0.356346] #0: (adap-bus_lock){+.+...}, at: [c0355910]
i2c_transfer+0x84/0x178
[0.356396]
[0.356397] stack backtrace:
[0.356422] Call Trace:
[0.356447] [ef871b50] [c00094fc] show_stack+0x7c/0x194 (unreliable)
[0.356485] [ef871b90] [c007ebe4] __lock_acquire+0x15c0/0x16a8
[0.356515] [ef871c20] [c007edb8] lock_acquire+0xec/0x128
[0.356549] [ef871c60] [c040bfa4] mutex_lock_nested+0x5c/0x2c8
[0.356580] [ef871cc0] [c0355910] i2c_transfer+0x84/0x178
[0.356612] [ef871cf0] [c02aa56c] radeon_i2c_xfer+0x44/0x80
[0.356643] [ef871d10] [c0355938] i2c_transfer+0xac/0x178
[0.356679] [ef871d40] [c026267c] drm_do_probe_ddc_edid+0x50/0x70
[0.356710] [ef871d70] [c02626e0] drm_ddc_read_edid+0x44/0xd8
[0.356741] [ef871d90] [c026285c] drm_get_edid+0xe8/0x1a0
[0.356770] [ef871db0] [c02a7b10] radeon_modeset_init+0x690/0x794
[0.356802] [ef871e10] [c028a964] radeon_driver_load_kms+0x150/0x1b0
[0.356841] [ef871e30] [c0257c8c] drm_get_dev+0x36c/0x45c
[0.356875] [ef871e60] [c0412180] radeon_pci_probe+0x1c/0x2c
[0.356912] [ef871e70] [c020c93c] local_pci_probe+0x24/0x34
[0.356943] [ef871e80] [c020dc78] pci_device_probe+0x70/0xb0
[0.356977] [ef871eb0] [c02f3e24] driver_probe_device+0x13c/0x2a8
[0.357008] [ef871ed0] [c02f4008] __driver_attach+0x78/0xb4
[0.357038] [ef871ef0] [c02f3218] bus_for_each_dev+0x68/0xc0
[0.357067] [ef871f20] [c02f3ad4] driver_attach+0x24/0x34
[0.357097] [ef871f30] [c02f2918] bus_add_driver+0x15c/0x324
[0.357127] [ef871f50] [c02f442c] driver_register+0xcc/0x184
[0.357158] [ef871f70] [c020df78] __pci_register_driver+0x74/0x108
[0.357190] [ef871f90] [c0252024] drm_init+0x74/0x108
[0.357224] [ef871fb0] [c05c3794] radeon_init+0xa4/0xb8
[0.357254] [ef871fc0] [c0003eec] do_one_initcall+0x70/0x210
[0.357289] [ef871fe0] [c05a21dc] kernel_init+0xbc/0x130
[0.357318] [ef871ff0] [c0014120] kernel_thread+0x4c/0x68
[0.651929] [drm] Determined LVDS native mode details from EDID
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
From: Michel Dänzer daen...@vmware.com
If radeon_cs_parser_init() fails, radeon_cs_ioctl() calls
radeon_cs_parser_fini() with the non-zero error value. The latter dereferenced
parser-ib which hasn't been initialized yet - boom. Add a test for parser-ib
being non-NULL before dereferencing it.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 65590a0..8f46467 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -189,7 +189,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (error) {
+ if (error parser-ib) {
radeon_bo_list_unvalidate(parser-validated,
parser-ib-fence);
} else {
--
1.6.6
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix up LVDS handling on macs
On Mon, 2010-01-11 at 11:10 -0500, Alex Deucher wrote:
From 16de3600adde106fbb6eb828a3fa1b935d938425 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Mon, 11 Jan 2010 10:50:18 -0500
Subject: [PATCH] drm/radeon/kms: fix up LVDS handling on macs
Based on radeonfb code and recent ddx fix.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 24 +-
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 981508f..f746560 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -85,8 +97,16 @@ static void radeon_legacy_lvds_dpms(struct
drm_encoder *encoder, int mode)
WREG32_PLL_P(RADEON_PIXCLKS_CNTL, 0,
~RADEON_PIXCLK_LVDS_ALWAYS_ONb);
lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
lvds_gen_cntl |= RADEON_LVDS_DISPLAY_DIS;
- lvds_gen_cntl = ~(RADEON_LVDS_ON | RADEON_LVDS_BLON |
RADEON_LVDS_EN | RADEON_LVDS_DIGON);
- udelay(panel_pwr_delay * 1000);
+ if (is_mac) {
+ lvds_gen_cntl = ~RADEON_LVDS_BL_MOD_EN;
+ WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
+ udelay(panel_pwr_delay * 1000);
+ lvds_gen_cntl = ~(RADEON_LVDS_ON | RADEON_LVDS_EN);
+ } else {
+ WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
+ lvds_gen_cntl = ~(RADEON_LVDS_ON | RADEON_LVDS_BLON |
RADEON_LVDS_EN | RADEON_LVDS_DIGON);
+ udelay(panel_pwr_delay * 1000);
+ }
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
WREG32_PLL(RADEON_PIXCLKS_CNTL, pixclks_cntl);
break;
Minor niggle here: You could leave a single udelay() after the if
(is_mac) blocks.
Other than that,
Reviewed-by: Michel Dänzer mic...@daenzer.net
Tested-by: Michel Dänzer mic...@daenzer.net
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH RESEND] drm/radeon/kms: Fix crash getting TV info with no BIOS.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
Looks like this simple fix got lost last time...
drivers/gpu/drm/radeon/radeon_combios.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 58f3426..fa91e42 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -673,6 +673,9 @@ radeon_combios_get_tv_info(struct radeon_device *rdev)
uint16_t tv_info;
enum radeon_tv_std tv_std = TV_STD_NTSC;
+ if (rdev-bios == NULL)
+ return tv_std;
+
tv_info = combios_get_table_offset(dev, COMBIOS_TV_INFO_TABLE);
if (tv_info) {
if (RBIOS8(tv_info + 6) == 'T') {
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Workaround RV410/R420 CP errata (V2)
On Wed, 2010-01-06 at 11:41 +0100, Jerome Glisse wrote:
From: Corbin Simpson mostawesomed...@gmail.com
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Flash on Fx3).
V2: Fix indentation and move errata_fini to suspend function so we
don't leak scratch register over suspend/resume cycle.
Signed-off-by: Corbin Simpson mostawesomed...@gmail.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
[...]
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cd650fd..b272065 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -798,6 +798,7 @@ struct radeon_device {
struct radeon_gem gem;
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
+uint32_t resync_scratch;
struct mutexcs_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
Indentation still looks wrong in this hunk.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, have you tried doing it in the interrupt handler for the vblank interrupt instead? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Fix crash getting TV info with no BIOS.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_combios.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index fd94dbc..dd481dd 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -641,6 +641,9 @@ radeon_combios_get_tv_info(struct radeon_device *rdev)
uint16_t tv_info;
enum radeon_tv_std tv_std = TV_STD_NTSC;
+ if (rdev-bios == NULL)
+ return tv_std;
+
tv_info = combios_get_table_offset(dev, COMBIOS_TV_INFO_TABLE);
if (tv_info) {
if (RBIOS8(tv_info + 6) == 'T') {
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Only flush the HDP read cache for BOs which are in VRAM.
From: Michel Dänzer daen...@vmware.com
The HDP read cache should only affect CPU reads from VRAM.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_gem.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 60df2d7..188bf9b 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -125,13 +125,15 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
return 0;
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
+ uint32_t cur_placement;
/* Asking for cpu access wait for object idle */
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, cur_placement, false);
if (r) {
printk(KERN_ERR Failed to wait for object !\n);
return r;
}
- radeon_hdp_flush(robj-rdev);
+ if (cur_placement == TTM_PL_VRAM)
+ radeon_hdp_flush(robj-rdev);
}
return 0;
}
@@ -301,6 +303,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
+ uint32_t cur_placement = 0;
int r;
gobj = drm_gem_object_lookup(dev, filp, args-handle);
@@ -308,11 +311,12 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
return -EINVAL;
}
robj = gobj-driver_private;
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, cur_placement, false);
mutex_lock(dev-struct_mutex);
drm_gem_object_unreference(gobj);
mutex_unlock(dev-struct_mutex);
- radeon_hdp_flush(robj-rdev);
+ if (cur_placement == TTM_PL_VRAM)
+ radeon_hdp_flush(robj-rdev);
return r;
}
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Thu, 2009-12-24 at 03:24 +0100, Rafał Miłecki wrote: W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/23 Rafał Miłecki zaj...@gmail.com: Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. I remove DRM_INFOs and also moved radeon_get_power_state calls from IRQ handler to line before rdev-pm.vblank_callback = true;. This didn't help. I guess you may be right with this VBLANK. We may receive that too late and don't hit vblank. Maybe with low engine we even parse IRQs slower? I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add cvt mode if we only have lvds w/h and no edid
On Tue, 2009-12-22 at 09:30 -0500, Alex Deucher wrote:
From 7c30bc1d04bd87dff00ff80c3cf7d8a0b8cf3e34 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 22 Dec 2009 09:25:22 -0500
Subject: [PATCH] drm/radeon/kms: add cvt mode if we only have lvds w/h
and no edid
This fixes LVDS on some mac laptops without a panel edid.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 8da06e1..0cbd3ef 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -208,6 +208,11 @@ static struct drm_display_mode
*radeon_fp_native_mode(struct drm_encoder *encode
drm_mode_set_name(mode);
DRM_DEBUG(Adding native panel mode %s\n, mode-name);
+ } else if (native_mode-hdisplay != 0
+native_mode-vdisplay != 0) {
+ /* mac laptops without an edid */
+ mode = drm_cvt_mode(dev, native_mode-hdisplay,
native_mode-vdisplay, 60, true, false, false);
+ DRM_DEBUG(Adding native panel mode %s\n, mode-name);
Might be worth reflecting in the message that it's not really the native
mode but a generated approximation of it.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata.
On Fri, 2009-12-18 at 11:54 +0100, Rafał Miłecki wrote: 2009/12/18 Corbin Simpson mostawesomed...@gmail.com: From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Fri, 18 Dec 2009 01:00:57 -0800 Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata. Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). Can this be issue on newer chipsets as well? I get hard lockup on RV620 from time to time, very easy reproducible with just starting JDownloader (java application). It seems to do some heavy 2D and locks up my machine in something between 1 second and few minutes. This does not happen when I use UMS (non-KMS) or when I start JDownloader on KDE's virtual desktop #2 and switch to desktop #1. It can't be the same problem: it's specific to the 2D engine, which doesn't exist anymore as of R6xx, and it would also happen with UMS. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] radeon bo/cs API cleanup
On Thu, 2009-12-17 at 14:34 +1000, Dave Airlie wrote: Hi, so Michel pointed out that the libdrm_radeon API was pretty unmaintainble. Reasons: 1. inlines in headers mean API/ABI is fixed completely. 2. All of structure internals for bo/cs are exposed. 3. RADEON_BO_TRACK changed the library API when on/off. So I a) removed bo tracking b) split the cs/bo structs into public/private parts and minimised the members, the cs_int/bo_int need to reflect the public bits. c) left some members intact for fast paths for functions that need it (write_dword) 3 patches attached, libdrm/ddx/mesa (no r300g bits yet) to clean the API of all of this. I'd like to then declare this as the stable API going forward. Thanks Dave, these look good. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing an AGPGART driver with radeon.test=1
On Tue, 2009-12-15 at 22:26 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Tue, 2009-12-15 at 13:37 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net guess there could be many possible causes for the problem, but the most likely seems some kind of coherency issue between the CPU writes and GPU reads. Well, the northbridge doesn't guarantee coherence. So I'm sure you're correct. Although I can only see the problem ATM, when the GPU writes data to system memory, which is later read by the CPU. What exactly does 'can see' mean? :) Well, I didn't verify that this happens on my machine. But I'm sure it is the case with memory allocated by the generic AGP layer functions (as far as I can see they allocate cacheable memory), as the bridge's snoop logic is buggy. As you say, it must be some sort of coherency issue. I don't think we've ever used cacheable memory with any AGP bridge in Linux. I guess the memory used for this test is allocated by the AGP layer and not by the radeon driver? No, it's allocated by radeon/TTM. And this memory is mapped uncacheable by radeon/TTM? Yes. Doesn't that limit the maximum usable memory for radeon/TTM to the vmalloc space? That could only be relevant for kernel mappings. The kernel only maps buffer object (BO) memory when/while necessary, which usually isn't the case. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing an AGPGART driver with radeon.test=1
On Tue, 2009-12-15 at 13:37 +0100, Gerhard Pircher wrote: Original-Nachricht Datum: Tue, 15 Dec 2009 00:01:50 +0100 Von: Michel Dänzer mic...@daenzer.net An: Gerhard Pircher gerhard_pirc...@gmx.net CC: dri-devel@lists.sourceforge.net Betreff: Re: Testing an AGPGART driver with radeon.test=1 On Mon, 2009-12-14 at 23:21 +0100, Gerhard Pircher wrote: Next I booted the kernel with radeon.test=1 and this test fails immediately with a message like this: [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf14a88f0, expected 0xf14a6680 (GTT map 0xf14a6000-0xf15a6000) A different aperture size doesn't make any difference. However the test works in PCIGART mode. Now I wonder what the problem could be, as I don't have a clue about the radeon/DRM code. Can somebody explain me, how the test works and what the error message means for the AGPGART driver? The test output is a little cryptic and could be improved... The failing phase of the test fills the GTT memory with the kernel virtual addresses of itself, copies it to VRAM with the GPU, reads it back again with the CPU and verifies the contents. It read back 0xf14a88f0 when it expected 0xf14a6680, so the latter is the kernel virtual address of the first word which wasn't copied correctly. Subtracting the start of the GTT map (0xf14a6000) yields that only 1664 bytes (+ 2, as the first two bytes of the incorrect word are correct) were copied correctly. Thanks, now it makes sense to me, but raises some other questions. :) When VRAM is the graphics card's onboard memory, then the CPU should get correct data, as PCI memory is usually mapped non-cacheable (I hope that is true for prefetchable PCI memory, too). Yes. There's various caches on the GPU as well, but if those were the problem here, I'd expect it to affect PCI GART as well. And as you know, the AGPGART driver does a cache flush for the allocated resp. inserted AGP memory. Right, though that won't happen between all CPU writes and GPU reads in general, though it may always be the case with this test. I don't suppose higher transfer rates work any better? :) I Well AGP 2x works, [...] 'Works' as in passes radeon.test=1? guess there could be many possible causes for the problem, but the most likely seems some kind of coherency issue between the CPU writes and GPU reads. Well, the northbridge doesn't guarantee coherence. So I'm sure you're correct. Although I can only see the problem ATM, when the GPU writes data to system memory, which is later read by the CPU. What exactly does 'can see' mean? That should fail, because the cache isn't invalidated. I'm sure I'm missing something here. I guess the memory used for this test is allocated by the AGP layer and not by the radeon driver? No, it's allocated by radeon/TTM. Does the CPU always read directly from VRAM, Not 'always' in general but for this test, yes. if it can't access the aperture [...] If by 'can't access the aperture' you're referring to the linear AGP aperture bot being available in the CPU address space, VRAM access has nothing to do with that (or AGP in general). I doubt the problem is related to that at all. radeon/TTM just map the underlying RAM pages directly in that case, uncacheable. FWIW, this is all working fine for me with the UniNorth AGP bridge in my PowerBook. (Well, for some reason KMS still only works reliably with 1x, whereas non-KMS worked with 4x, but that probably doesn't matter all that much overall) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing an AGPGART driver with radeon.test=1
On Mon, 2009-12-14 at 23:21 +0100, Gerhard Pircher wrote: Next I booted the kernel with radeon.test=1 and this test fails immediately with a message like this: [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf14a88f0, expected 0xf14a6680 (GTT map 0xf14a6000-0xf15a6000) A different aperture size doesn't make any difference. However the test works in PCIGART mode. Now I wonder what the problem could be, as I don't have a clue about the radeon/DRM code. Can somebody explain me, how the test works and what the error message means for the AGPGART driver? The test output is a little cryptic and could be improved... The failing phase of the test fills the GTT memory with the kernel virtual addresses of itself, copies it to VRAM with the GPU, reads it back again with the CPU and verifies the contents. It read back 0xf14a88f0 when it expected 0xf14a6680, so the latter is the kernel virtual address of the first word which wasn't copied correctly. Subtracting the start of the GTT map (0xf14a6000) yields that only 1664 bytes (+ 2, as the first two bytes of the incorrect word are correct) were copied correctly. The normal ring and IB tests are probably too simple to catch that kind of problem. I don't suppose higher transfer rates work any better? :) I guess there could be many possible causes for the problem, but the most likely seems some kind of coherency issue between the CPU writes and GPU reads. Hope this helps, -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Expose backlight class device for legacy LVDS encoder.
From: Michel Dänzer daen...@vmware.com
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
Does anyone have an idea if this will interact well with x86 laptop hotkeys /
ACPI / whatever?
drivers/gpu/drm/radeon/Kconfig |1 +
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 256 ++-
drivers/gpu/drm/radeon/radeon_mode.h| 10 +
3 files changed, 261 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 5982321..f3254c7 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,6 +1,7 @@
config DRM_RADEON_KMS
bool Enable modesetting on radeon by default
depends on DRM_RADEON
+ select BACKLIGHT_CLASS_DEVICE
help
Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index df00515..357c2af 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -29,6 +29,10 @@
#include radeon.h
#include atom.h
+#ifdef CONFIG_PMAC_BACKLIGHT
+#include asm/backlight.h
+#endif
+
static void radeon_legacy_encoder_disable(struct drm_encoder *encoder)
{
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
@@ -39,22 +43,30 @@ static void radeon_legacy_encoder_disable(struct
drm_encoder *encoder)
radeon_encoder-active_device = 0;
}
-static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+static void radeon_legacy_lvds_update(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t lvds_gen_cntl, lvds_pll_cntl, pixclks_cntl, disp_pwr_man;
int panel_pwr_delay = 2000;
+ uint8_t backlight_level;
DRM_DEBUG(\n);
+ lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
+ backlight_level = (lvds_gen_cntl RADEON_LVDS_BL_MOD_LEVEL_SHIFT)
0xff;
+
if (radeon_encoder-enc_priv) {
if (rdev-is_atom_bios) {
struct radeon_encoder_atom_dig *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
} else {
struct radeon_encoder_lvds *lvds =
radeon_encoder-enc_priv;
panel_pwr_delay = lvds-panel_pwr_delay;
+ if (lvds-bl_dev)
+ backlight_level = lvds-backlight_level;
}
}
@@ -72,9 +84,11 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
lvds_pll_cntl = ~RADEON_LVDS_PLL_RESET;
WREG32(RADEON_LVDS_PLL_CNTL, lvds_pll_cntl);
- lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
- lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
RADEON_LVDS_DIGON | RADEON_LVDS_BLON);
- lvds_gen_cntl = ~(RADEON_LVDS_DISPLAY_DIS);
+ lvds_gen_cntl = ~(RADEON_LVDS_DISPLAY_DIS |
+ RADEON_LVDS_BL_MOD_LEVEL_MASK);
+ lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
+ RADEON_LVDS_DIGON | RADEON_LVDS_BLON |
+ (backlight_level
RADEON_LVDS_BL_MOD_LEVEL_SHIFT));
udelay(panel_pwr_delay * 1000);
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
break;
@@ -83,7 +97,6 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_OFF:
pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
WREG32_PLL_P(RADEON_PIXCLKS_CNTL, 0,
~RADEON_PIXCLK_LVDS_ALWAYS_ONb);
- lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
lvds_gen_cntl |= RADEON_LVDS_DISPLAY_DIS;
lvds_gen_cntl = ~(RADEON_LVDS_ON | RADEON_LVDS_BLON |
RADEON_LVDS_EN | RADEON_LVDS_DIGON);
udelay(panel_pwr_delay * 1000);
@@ -98,6 +111,25 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder
*encoder, int mode)
radeon_combios_encoder_dpms_scratch_regs(encoder, (mode ==
DRM_MODE_DPMS_ON) ? true : false);
}
+static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct radeon_device *rdev = encoder-dev-dev_private;
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ DRM_DEBUG(\n);
+
+ if (radeon_encoder
Re: [PATCH] drm/radeon/kms: Expose backlight class device for legacy LVDS encoder.
On Tue, 2009-12-08 at 11:32 +0100, Rafał Miłecki wrote: 2009/12/8 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Allows e.g. power management daemons to control the backlight level. Inspired by the corresponding code in radeonfb. Signed-off-by: Michel Dänzer daen...@vmware.com I posted something similar but AFAIR got response we don't want this until fixing backlight class design. Unfortunately I'm not aware of any other available method to control the backlight on Apple PowerPC laptops. I'm open for suggestions though how this code could be disabled when another method is available. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Tue, 2009-12-01 at 09:43 +0100, Rafał Miłecki wrote: W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher alexdeuc...@gmail.com wrote: This enables the use of interrupts on r6xx/r7xx hardware. Interrupts are implemented via a ring buffer. The GPU adds interrupts vectors to the ring and the host reads them off in the interrupt handler. The interrupt controller requires firmware like the CP. This firmware must be installed and accessible to the firmware loader for interrupts to function. Updated patch. fixes some minor issues in the previous one. Same issue with updated one. modprobed radeon, not a one VBLANK. Started X and KDE, got first VBLANK on 48sec and received them cyclic until 87sec. Then it just stopped. Note that vblank interrupts are only supposed to be occur while userspace is waiting for vblank events. Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Tue, 2009-12-01 at 10:01 +0100, Rafał Miłecki wrote: W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer mic...@daenzer.net napisał: Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. Thanks you! I'll try that today later. Could you just explain what is drm_wait_vblank for? I expected it to sleep my process and wake it up interruptible on IRQ. That much is correct. But I'm not sure that anymore. Also it expected drm_file parameter which AFAIK is never passed from gpu driver, but from drm to gpu driver. As it is, it's intended for handling ioctl calls from userspace and as such may make assumptions which weren't satisfied in the context you tried using it from. It might be possible to factor out the core functionality such that it would be more usable from within the kernel, but it'll still only be appropriate for a process context which can afford to sleep for relatively long intervals. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher alexdeuc...@gmail.com wrote: This enables the use of interrupts on r6xx/r7xx hardware. Interrupts are implemented via a ring buffer. The GPU adds interrupts vectors to the ring and the host reads them off in the interrupt handler. The interrupt controller requires firmware like the CP. This firmware must be installed and accessible to the firmware loader for interrupts to function. Updated patch. fixes some minor issues in the previous one. Same issue with updated one. modprobed radeon, not a one VBLANK. Started X and KDE, got first VBLANK on 48sec and received them cyclic until 87sec. Then it just stopped. Note that vblank interrupts are only supposed to be occur while userspace is waiting for vblank events. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon modeset=1 agpmode=-1 does not work in 2.6.32-rc8
On Mon, 2009-11-23 at 14:18 +0100, Christian Hartmann wrote: Hello, I just wanted to disable agpmode and have set in the /etc/modules radeon modeset=0 agpmode=-1 running update-initramfs and rebooting. But I am wondering, cause AGP is still enabled. Is that really correct? Without KMS, the AGP mode needs to be configured in xorg.conf. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 11:43 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Oh, only radeon_drm.h is in the kernel, so only that should be in include/drm. The other radeon_*.h files live in radeon/. I guess accidentally copied over the userspace headers when I populated the include/drm directory initially. Should be cleaned up now. Thanks Kristian. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix coherency issues on AGP cards.
On Fri, 2009-10-30 at 13:32 +1000, Dave Airlie wrote:
The other question is why we don't evict VRAM-GTT in a lot of cases,
this would save us some cache transitions since a lot of objects
that are evicted from VRAM will probably end up being pulled back in
a few operations later, and evicting them to system memory involves
2 unnecessary cache transitions.
I think the patch below should allow VRAM-GTT eviction. I'm not sure
it's an overall improvement right now though, I think BOs might get
stuck in GTT after eviction there.
commit c9367db23470c5035bf52667a1daa4176d926024
Author: Michel Dänzer daen...@vmware.com
Date: Wed Nov 4 08:41:25 2009 +0100
drm/radeon: Tweak TTM eviction flags to include GTT for eviction from VRAM.
Signed-off-by: Michel Dänzer daen...@vmware.com
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index e116a15..0e76fcc 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -199,13 +199,12 @@ static int radeon_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
static uint32_t radeon_evict_flags(struct ttm_buffer_object *bo)
{
- uint32_t cur_placement = bo-mem.placement ~TTM_PL_MASK_MEMTYPE;
-
- switch (bo-mem.mem_type) {
- default:
- return (cur_placement ~TTM_PL_MASK_CACHING) |
- TTM_PL_FLAG_SYSTEM |
- TTM_PL_FLAG_CACHED;
+ if ((bo-mem.placement TTM_PL_MASK_MEMTYPE) == TTM_PL_FLAG_VRAM) {
+ return (bo-mem.placement ~TTM_PL_MASK_MEMTYPE) |
+ TTM_PL_FLAG_TT | TTM_PL_FLAG_SYSTEM |
TTM_PL_MASK_CACHING;
+ } else {
+ return (bo-mem.placement ~TTM_PL_MASK_MEMTYPE) |
+ TTM_PL_FLAG_SYSTEM | TTM_PL_MASK_CACHING;
}
}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 23693] KMS has been broken on ATI RV250 Lf (Radeon M9)
On Thu, 2009-10-08 at 20:10 +0200, Johannes Obermayr wrote: thanks for your fast answer. I did some restarts with radeon.agpmode=-1 (0, 1, 2 and 4). With my installed xorg.conf (attached) there are no differences to my bug report. With x11failsave X does not start with all modes. dmesg | grep drm and Xorg.0.log for each mode are attached. Maybe you see something. If firmware files are the problem: they are installed under /lib/firmware/radeon/ and are also from nouveau/linux-2.6 (checkout 20090909 - they have not been touched since 20090830). Indeed, see dmesg: [8.226741] [drm:r100_cp_init] *ERROR* Failed to load firmware! If you're using an initrd it might be as simple as copying the needed firmware file(s) there, otherwise if the radeon DRM is built into the kernel you may have to enable CONFIG_FIRMWARE_IN_KERNEL . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: Fix apparent typo in legacy CRTC memory bandwidth calculation.
From: Michel Dänzer daen...@vmware.com While investigating the cause of CRTC FIFO underruns, I noticed that when converting the memory bandwidth calculation from the userspac X driver code, an instance of '8.0' was apparently accidentally converted to '80'. Signed-off-by: Michel Dänzer daen...@vmware.com --- drivers/gpu/drm/radeon/r100.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 374ecac..33198dd 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -2350,7 +2350,7 @@ void r100_bandwidth_update(struct radeon_device *rdev) /* Find the total latency for the display data. */ - disp_latency_overhead.full = rfixed_const(80); + disp_latency_overhead.full = rfixed_const(8); disp_latency_overhead.full = rfixed_div(disp_latency_overhead, sclk_ff); mc_latency_mclk.full += disp_latency_overhead.full + cur_latency_mclk.full; mc_latency_sclk.full += disp_latency_overhead.full + cur_latency_sclk.full; -- 1.6.4.3 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: Update memory bandwidth requirements in mode_set_base hook.
From: Michel Dänzer daen...@vmware.com
The hook may change the number of bytes per pixel being scanned out, which
affects the CRTC memory bandwidth requirements. E.g. booting in 8bpp and then
running X in 32bpp would result in the bandwidth requirements being
underestimated for the latter and consequently in CRTC FIFO underruns causing
visible artifacts with 3D intensive workloads.
ATOM changes only compile-tested.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/atombios_crtc.c |5 -
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |7 ---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 14fa970..38a87cc 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -563,6 +563,10 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
radeon_fb = to_radeon_framebuffer(old_fb);
radeon_gem_object_unpin(radeon_fb-obj);
}
+
+ /* Bytes per pixel may have changed */
+ radeon_bandwidth_update(rdev);
+
return 0;
}
@@ -701,7 +705,6 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
}
atombios_overscan_setup(crtc, mode, adjusted_mode);
atombios_scaler_setup(crtc);
- radeon_bandwidth_update(rdev);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 36410f8..ec2df73 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -532,6 +532,10 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x, int
y,
radeon_fb = to_radeon_framebuffer(old_fb);
radeon_gem_object_unpin(radeon_fb-obj);
}
+
+ /* Bytes per pixel may have changed */
+ radeon_bandwidth_update(rdev);
+
return 0;
}
@@ -1015,14 +1019,11 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
int x, int y, struct drm_framebuffer *old_fb)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- struct drm_device *dev = crtc-dev;
- struct radeon_device *rdev = dev-dev_private;
/* TODO TV */
radeon_crtc_set_base(crtc, x, y, old_fb);
radeon_set_crtc_timing(crtc, adjusted_mode);
radeon_set_pll(crtc, adjusted_mode);
- radeon_bandwidth_update(rdev);
if (radeon_crtc-crtc_id == 0) {
radeon_legacy_rmx_mode_set(crtc, mode, adjusted_mode);
} else {
--
1.6.4.3
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: don't require up to 64k allocations. (v2)
On Thu, 2009-09-24 at 15:25 +1000, Dave Airlie wrote: On Thu, Sep 24, 2009 at 3:16 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This avoids needing to do a kmalloc PAGE_SIZE for the main indirect buffer chunk, it adds an accessor for all reads from the chunk and caches a single page at a time for subsequent reads. changes since v1: Use a two page pool which should be the most common case a single packet spanning PAGE_SIZE will be hit, but I'm having trouble seeing anywhere we currently generate anything like that. r600: untested conversion hopefully proper short page copying at end added parser_error flag to set deep errors instead of having to test every ib value fetch. I've left one bug in here see if you can see it :-) the extra pages copy starts one page too soon, but its probably not a greatly hit path as it relies on a packet 4096 also. FWIW, I've been working on merging several Composite operations into a single draw packet in RadeonCompositeTile in the X driver, to decrease the CS checking overhead. That should quite easily generate a single packet 4096 bytes (e.g. rendering more than about 40 characters in one go, if my math is right). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon/kms: don't require up to 64k allocations.
On Wed, 2009-09-23 at 16:56 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This avoids needing to do a kmalloc PAGE_SIZE for the main indirect buffer chunk, it adds an accessor for all reads from the chunk and caches a single page at a time for subsequent reads. FWIW, this works on my PowerBook but seems to drop x11perf -aa10text numbers from about 370k/s to about 315k/s. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of radeon_clocks_init().
On Fri, 2009-09-18 at 07:45 +0100, Dave Airlie wrote:
From: Michel Dänzer daen...@vmware.com
Someone on IRC reported problems after commit
95a8f1bf4f48b434c9f839ab5a0773f66b39d7c6 ('drm/radeon/kms: Move
radeon_clocks_init() call back after getting VRAM info.'). And indeed, at
least
some ASIC vram_info hooks use the clock info obtained by
radeon_get_clock_info(). So, move that call out of radeon_clocks_init(),
ahead
of the radeon_vram_info() call.
This broke r600/rv770,
Whoops, sorry I failed to notice those have separate init paths.
fixed up and applied to drm-next.
Thanks!
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: reprogram format in set base.
On Wed, 2009-09-16 at 10:16 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@linux.ie
This should in theory fix the problem with a mode set being required
for adjusting the color depth.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 29
+++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 0d29d15..040354d 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -401,11 +401,30 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
uint32_t crtc_offset, crtc_offset_cntl, crtc_tile_x0_y0 = 0;
uint32_t crtc_pitch, pitch_pixels;
uint32_t tiling_flags;
+ int format;
+ uint32_t gen_cntl_reg, gen_cntl_val;
DRM_DEBUG(\n);
radeon_fb = to_radeon_framebuffer(crtc-fb);
+ switch (crtc-fb-bits_per_pixel) {
+ case 15: /* 555 */
+ format = 3;
+ break;
+ case 16: /* 565 */
+ format = 4;
+ break;
+ case 24: /* RGB */
+ format = 5;
+ break;
+ case 32: /* xRGB */
+ format = 6;
+ break;
+ default:
+ return false;
+ }
+
obj = radeon_fb-obj;
if (radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, base)) {
return -EINVAL;
Even if depth 8 doesn't work properly yet, it would be nice not to
further proliferate these switch statements on crtc-fb-bits_per_pixel
without a case 8.
That said, it does work for me.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Move radeon_get_clock_info() call out of radeon_clocks_init().
From: Michel Dänzer daen...@vmware.com
Someone on IRC reported problems after commit
95a8f1bf4f48b434c9f839ab5a0773f66b39d7c6 ('drm/radeon/kms: Move
radeon_clocks_init() call back after getting VRAM info.'). And indeed, at least
some ASIC vram_info hooks use the clock info obtained by
radeon_get_clock_info(). So, move that call out of radeon_clocks_init(), ahead
of the radeon_vram_info() call.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
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 abfc964..ada2397 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -386,7 +386,6 @@ int radeon_clocks_init(struct radeon_device *rdev)
{
int r;
- radeon_get_clock_info(rdev-ddev);
r = radeon_static_clocks_init(rdev-ddev);
if (r) {
return r;
@@ -616,7 +615,8 @@ int radeon_device_init(struct radeon_device *rdev,
radeon_combios_asic_init(rdev-ddev);
}
}
- /* Get vram informations */
+ /* Get clock vram information */
+ radeon_get_clock_info(rdev-ddev);
radeon_vram_info(rdev);
/* Initialize clocks */
r = radeon_clocks_init(rdev);
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.
On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
2009/9/16 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 2ba61e1..341c21a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -802,11 +802,12 @@ struct drm_radeon_gem_create {
uint32_tflags;
};
-#define RADEON_TILING_MACRO 0x1
-#define RADEON_TILING_MICRO 0x2
-#define RADEON_TILING_SWAP 0x4
-#define RADEON_TILING_SURFACE 0x8 /* this object requires a surface
- * when mapped - i.e. front buffer */
+#define RADEON_TILING_MACRO 0x1
+#define RADEON_TILING_MICRO 0x2
+#define RADEON_TILING_SWAP_16BIT 0x4
+#define RADEON_TILING_SWAP_32BIT 0x8
+#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
+ * when mapped - i.e. front buffer */
I know we haven't frozen API yet but this seems a bit unnecessary
to reorder,
Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
a pending corresponding X driver patch that will fix it)
do we really need swap 16 and 32 bit? does it not depend on other info
about the buffer?
A similar argument could be made against the separate macro / micro
tiling flags?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 17:16 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:20 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? Yup exactly, so if we fix that this should be fine. Actually, how's the palette supposed to be handled if mode_set_base needs to switch from depth 16 to 24? Unless I'm missing something, the existing palette will be at least incomplete. We don't set the palette in mode set either now do we, its loaded in the dpms on function, maybe we should call it in the mode set base case as well. But where would it get the missing entries from? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.
On Wed, 2009-09-16 at 17:13 +1000, Dave Airlie wrote:
2009/9/16 Michel Dänzer mic...@daenzer.net:
On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
2009/9/16 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 2ba61e1..341c21a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -802,11 +802,12 @@ struct drm_radeon_gem_create {
uint32_tflags;
};
-#define RADEON_TILING_MACRO 0x1
-#define RADEON_TILING_MICRO 0x2
-#define RADEON_TILING_SWAP 0x4
-#define RADEON_TILING_SURFACE 0x8 /* this object requires a surface
- * when mapped - i.e. front buffer */
+#define RADEON_TILING_MACRO 0x1
+#define RADEON_TILING_MICRO 0x2
+#define RADEON_TILING_SWAP_16BIT 0x4
+#define RADEON_TILING_SWAP_32BIT 0x8
+#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
+ * when mapped - i.e. front
buffer */
I know we haven't frozen API yet but this seems a bit unnecessary
to reorder,
Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
a pending corresponding X driver patch that will fix it)
Yeah I have code that uses it just not pushed out, we should be using it
for front buffer allocs at least.
Right, below are the relevant parts of my X driver patch.
do we really need swap 16 and 32 bit? does it not depend on other info
about the buffer?
A similar argument could be made against the separate macro / micro
tiling flags?
Not really, you can't tell macro/micro without being told them, I thought
the buffer bpp for swap would tell enough, we could pass it in if we
aren't doing so, but if we aren't and we can't see any other need
then two flags are fine.
radeon_bo_open() doesn't take the bpp, so the kernel can't really know
it. Also I suspect that the bpp alone without more information such as
formats won't be useful for other things, but it's hard to tell without
knowing what those other things would be.
So, is there anything left for me to do for this?
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e6b948c..e8e14ae 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -915,6 +915,7 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int
height)
int screen_size;
int cpp = info-CurrentLayout.pixel_bytes;
struct radeon_bo *front_bo;
+ uint32_t tiling_flags = 0;
if (scrn-virtualX == width scrn-virtualY == height)
return TRUE;
@@ -948,6 +950,22 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int
height)
if (!info-front_bo)
goto fail;
+if (info-allowColorTiling)
+ tiling_flags |= RADEON_TILING_MACRO;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ switch (cpp) {
+ case 4:
+ tiling_flags |= RADEON_TILING_SWAP_32BIT;
+ break;
+ case 2:
+ tiling_flags |= RADEON_TILING_SWAP_16BIT;
+ break;
+ }
+#endif
+ if (tiling_flags)
+radeon_bo_set_tiling(info-front_bo,
+tiling_flags | RADEON_TILING_SURFACE, pitch *
cpp);
+
ret = drmModeAddFB(drmmode-fd, width, height, scrn-depth,
scrn-bitsPerPixel, pitch * cpp,
info-front_bo-handle,
diff --git a/src/radeon_drm.h b/src/radeon_drm.h
index f974e19..49a5f81 100644
--- a/src/radeon_drm.h
+++ b/src/radeon_drm.h
@@ -802,9 +802,10 @@ struct drm_radeon_gem_create {
#define RADEON_TILING_MACRO 0x1
#define RADEON_TILING_MICRO 0x2
-#define RADEON_TILING_SWAP 0x4
-#define RADEON_TILING_SURFACE 0x8 /* this object requires a surface
- * when mapped - i.e. front buffer */
+#define RADEON_TILING_SWAP_16BIT 0x4
+#define RADEON_TILING_SWAP_32BIT 0x8
+#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
+ * when mapped - i.e. front buffer */
struct drm_radeon_gem_set_tiling {
uint32_thandle;
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index faa0cfd..95247bb 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -855,6 +880,11 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)
return FALSE;
}
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ radeon_bo_set_tiling(info-cursor_bo[c],
RADEON_TILING_SWAP_32BIT |
+RADEON_TILING_SURFACE, stride);
+#endif
+
if (radeon_bo_map(info-cursor_bo[c], 1)) {
ErrorF(Failed to map cursor buffer memory\n);
}
@@ -875,6 +905,8 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)
info
[PATCH] drm/radeon/kms: Get LVDS native mode details from EDID if necessary.
From: Michel Dänzer daen...@vmware.com
Fixes RMX problems on older Apple laptops which don't have an x86 BIOS ROM.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_combios.c| 12 ++---
drivers/gpu/drm/radeon/radeon_connectors.c | 34 +++-
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 2a027e0..cb60f55 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -863,8 +863,10 @@ struct radeon_encoder_lvds
*radeon_combios_get_lvds_info(struct radeon_encoder
int tmp, i;
struct radeon_encoder_lvds *lvds = NULL;
- if (rdev-bios == NULL)
- return radeon_legacy_get_lvds_info_from_regs(rdev);
+ if (rdev-bios == NULL) {
+ lvds = radeon_legacy_get_lvds_info_from_regs(rdev);
+ goto out;
+ }
lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
@@ -965,11 +967,13 @@ struct radeon_encoder_lvds
*radeon_combios_get_lvds_info(struct radeon_encoder
lvds-native_mode.flags = 0;
}
}
- encoder-native_mode = lvds-native_mode;
} else {
DRM_INFO(No panel info found in BIOS\n);
- return radeon_legacy_get_lvds_info_from_regs(rdev);
+ lvds = radeon_legacy_get_lvds_info_from_regs(rdev);
}
+out:
+ if (lvds)
+ encoder-native_mode = lvds-native_mode;
return lvds;
}
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 04ecb11..6435861 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -225,6 +225,36 @@ int radeon_connector_set_property(struct drm_connector
*connector, struct drm_pr
return 0;
}
+static void radeon_fixup_lvds_native_mode(struct drm_encoder *encoder,
+ struct drm_connector *connector)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct radeon_native_mode *native_mode = radeon_encoder-native_mode;
+
+ /* Try to get native mode details from EDID if necessary */
+ if (!native_mode-dotclock) {
+ struct drm_display_mode *t, *mode;
+
+ list_for_each_entry_safe(mode, t, connector-probed_modes,
head) {
+ if (mode-hdisplay == native_mode-panel_xres
+ mode-vdisplay == native_mode-panel_yres) {
+ native_mode-hblank = mode-htotal -
mode-hdisplay;
+ native_mode-hoverplus = mode-hsync_start -
mode-hdisplay;
+ native_mode-hsync_width = mode-hsync_end -
mode-hsync_start;
+ native_mode-vblank = mode-vtotal -
mode-vdisplay;
+ native_mode-voverplus = mode-vsync_start -
mode-vdisplay;
+ native_mode-vsync_width = mode-vsync_end -
mode-vsync_start;
+ native_mode-dotclock = mode-clock;
+ DRM_INFO(Determined LVDS native mode details
from EDID\n);
+ break;
+ }
+ }
+ }
+ if (!native_mode-dotclock) {
+ DRM_INFO(No LVDS native mode details, disabling RMX\n);
+ radeon_encoder-rmx_type = RMX_OFF;
+ }
+}
static int radeon_lvds_get_modes(struct drm_connector *connector)
{
@@ -237,9 +267,11 @@ static int radeon_lvds_get_modes(struct drm_connector
*connector)
ret = radeon_ddc_get_modes(radeon_connector);
if (ret 0) {
encoder = radeon_best_single_encoder(connector);
- if (encoder)
+ if (encoder) {
+ radeon_fixup_lvds_native_mode(encoder,
connector);
/* add scaled modes */
radeon_add_common_modes(encoder, connector);
+ }
return ret;
}
}
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Use depth 16 for console.
From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. Signed-off-by: Michel Dänzer daen...@vmware.com --- drivers/gpu/drm/radeon/radeon_fb.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 28818eb..6ee7843 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -227,10 +227,10 @@ int radeonfb_create(struct drm_device *dev, mode_cmd.width = surface_width; mode_cmd.height = surface_height; - mode_cmd.bpp = 32; + mode_cmd.bpp = 16; /* need to align pitch with crtc limits */ mode_cmd.pitch = radeon_align_pitch(rdev, mode_cmd.width, mode_cmd.bpp, fb_tiled) * ((mode_cmd.bpp + 1) / 8); - mode_cmd.depth = 24; + mode_cmd.depth = 16; size = mode_cmd.pitch * mode_cmd.height; aligned_size = ALIGN(size, PAGE_SIZE); -- 1.6.3.3 -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Don't kzalloc memory which is immediately overwritten.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0b8d184..12f5990 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -145,7 +145,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
size = p-chunks[i].length_dw * sizeof(uint32_t);
- p-chunks[i].kdata = kzalloc(size, GFP_KERNEL);
+ p-chunks[i].kdata = kmalloc(size, GFP_KERNEL);
if (p-chunks[i].kdata == NULL) {
return -ENOMEM;
}
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/r100.c |5 ++
drivers/gpu/drm/radeon/radeon_fb.c | 121 +---
drivers/gpu/drm/radeon/radeon_object.c |2 +
include/drm/radeon_drm.h | 11 ++--
4 files changed, 31 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fa0fdc1..737970b 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2235,6 +2235,11 @@ int r100_set_surface_reg(struct radeon_device *rdev, int
reg,
flags |= R300_SURF_TILE_MICRO;
}
+ if (tiling_flags RADEON_TILING_SWAP_16BIT)
+ flags |= RADEON_SURF_AP0_SWP_16BPP | RADEON_SURF_AP1_SWP_16BPP;
+ if (tiling_flags RADEON_TILING_SWAP_32BIT)
+ flags |= RADEON_SURF_AP0_SWP_32BPP | RADEON_SURF_AP1_SWP_32BPP;
+
DRM_DEBUG(writing surface %d %d %x %x\n, reg, flags, offset,
offset+obj_size-1);
WREG32(RADEON_SURFACE0_INFO + surf_index, flags);
WREG32(RADEON_SURFACE0_LOWER_BOUND + surf_index, offset);
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index ada4169..28818eb 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -45,68 +45,6 @@ struct radeon_fb_device {
struct radeon_device*rdev;
};
-static int radeon_fb_check_var(struct fb_var_screeninfo *var,
- struct fb_info *info)
-{
- int ret;
- ret = drm_fb_helper_check_var(var, info);
- if (ret)
- return ret;
-
- /* big endian override for radeon endian workaround */
-#ifdef __BIG_ENDIAN
- {
- int depth;
- switch (var-bits_per_pixel) {
- case 16:
- depth = (var-green.length == 6) ? 16 : 15;
- break;
- case 32:
- depth = (var-transp.length 0) ? 32 : 24;
- break;
- default:
- depth = var-bits_per_pixel;
- break;
- }
- switch (depth) {
- case 8:
- var-red.offset = 0;
- var-green.offset = 0;
- var-blue.offset = 0;
- var-red.length = 8;
- var-green.length = 8;
- var-blue.length = 8;
- var-transp.length = 0;
- var-transp.offset = 0;
- break;
- case 24:
- var-red.offset = 8;
- var-green.offset = 16;
- var-blue.offset = 24;
- var-red.length = 8;
- var-green.length = 8;
- var-blue.length = 8;
- var-transp.length = 0;
- var-transp.offset = 0;
- break;
- case 32:
- var-red.offset = 8;
- var-green.offset = 16;
- var-blue.offset = 24;
- var-red.length = 8;
- var-green.length = 8;
- var-blue.length = 8;
- var-transp.length = 8;
- var-transp.offset = 0;
- break;
- default:
- return -EINVAL;
- }
- }
-#endif
- return 0;
-}
-
static int radeonfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct radeon_fb_device *rfbdev = info-par;
@@ -187,7 +125,7 @@ void radeonfb_imageblit(struct fb_info *info, const struct
fb_image *image)
static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
- .fb_check_var = radeon_fb_check_var,
+ .fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = cfb_fillrect,
@@ -285,6 +223,7 @@ int radeonfb_create(struct drm_device *dev,
int size, aligned_size, ret;
void *fbptr = NULL;
bool fb_tiled = false; /* useful for testing */
+ u32 tiling_flags = 0;
mode_cmd.width = surface_width;
mode_cmd.height = surface_height;
@@ -308,7 +247,22 @@ int radeonfb_create(struct drm_device *dev,
robj = gobj-driver_private;
if (fb_tiled)
- radeon_object_set_tiling_flags(robj,
RADEON_TILING_MACRO|RADEON_TILING_SURFACE, mode_cmd.pitch);
+ tiling_flags = RADEON_TILING_MACRO;
+
+#ifdef __BIG_ENDIAN
+ switch (mode_cmd.bpp) {
+ case 32:
+ tiling_flags |= RADEON_TILING_SWAP_32BIT;
+ break;
+ case 16:
+ tiling_flags
[PATCH] drm/kms: Force full modeset if depth/bpp changes.
From: Michel Dänzer daen...@vmware.com Signed-off-by: Michel Dänzer daen...@vmware.com --- drivers/gpu/drm/drm_crtc_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index ff447f1..eaed0f5 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -762,7 +762,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set) } else if ((set-fb-bits_per_pixel != set-crtc-fb-bits_per_pixel) || set-fb-depth != set-crtc-fb-depth) - fb_changed = true; + mode_changed = true; else fb_changed = true; } -- 1.6.3.3 -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Move radeon_clocks_init() call back after getting VRAM info.
From: Michel Dänzer daen...@vmware.com
It may indirectly call radeon_set_clock_gating() which relies on the VRAM info.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
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 18653ea..2366dc6 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -616,13 +616,13 @@ int radeon_device_init(struct radeon_device *rdev,
radeon_combios_asic_init(rdev-ddev);
}
}
+ /* Get vram informations */
+ radeon_vram_info(rdev);
/* Initialize clocks */
r = radeon_clocks_init(rdev);
if (r) {
return r;
}
- /* Get vram informations */
- radeon_vram_info(rdev);
/* Initialize memory controller (also test AGP) */
r = radeon_mc_init(rdev);
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Only add common modes which fit in both panel dimensions.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_connectors.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 6435861..5ee81b6 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -207,8 +207,10 @@ static void radeon_add_common_modes(struct drm_encoder
*encoder, struct drm_conn
for (i = 0; i 17; i++) {
if (radeon_encoder-devices (ATOM_DEVICE_LCD_SUPPORT)) {
- if (common_modes[i].w = native_mode-panel_xres
- common_modes[i].h = native_mode-panel_yres)
+ if (common_modes[i].w native_mode-panel_xres ||
+ common_modes[i].h native_mode-panel_yres ||
+ (common_modes[i].w == native_mode-panel_xres
+common_modes[i].h == native_mode-panel_yres))
continue;
}
if (common_modes[i].w 320 || common_modes[i].h 200)
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Free CS parser state tracking memory.
From: Michel Dänzer daen...@vmware.com
Fixes leak hidden in commit 9f022ddfb23793b475ff7e57ac08a766dd5d31bd
('drm/radeon/kms: convert r4xx to new init path').
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_cs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index a169067..0b8d184 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -185,6 +185,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
mutex_unlock(parser-rdev-ddev-struct_mutex);
}
}
+ kfree(parser-track);
kfree(parser-relocs);
kfree(parser-relocs_ptr);
for (i = 0; i parser-nchunks; i++) {
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: Force full modeset if depth/bpp changes.
On Wed, 2009-09-16 at 08:02 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com This one confuses me, the bit depth and stuff should all be setup in the set base function, I wonder is there a bug somewhere that we aren't dealing with. There's definitely a bug somewhere. Without this, with fbcon at depth 16 the X server visibly stays in 16 bpp mode with 32 bpp data - funky effect. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote: 2009/9/16 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer daen...@vmware.com Now that we can handle 16 bpp on big endian as well, we can save VRAM like this and probably also improve console output speed. The console only uses a limited number of colours anyway. (8 bpp might be even better, but that doesn't seem to work properly yet) This will require changes to the X driver code which tries to preserve the console contents, but that never worked for me anyway. It will also cause flicker at boot which is sort of what we want to avoid esp when you cause a full modeset to happen. If the mode_set_base hook is supposed to handle depth changes, there should be no flicker, should there? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.
On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
2009/9/16 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
@@ -200,6 +201,7 @@ void radeon_object_kunmap(struct radeon_object *robj)
}
robj-kptr = NULL;
spin_unlock(robj-tobj.lock);
+ radeon_object_check_tiling(robj, 0, 0);
ttm_bo_kunmap(robj-kmap);
}
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 2ba61e1..341c21a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -802,11 +802,12 @@ struct drm_radeon_gem_create {
uint32_tflags;
};
-#define RADEON_TILING_MACRO 0x1
-#define RADEON_TILING_MICRO 0x2
-#define RADEON_TILING_SWAP 0x4
-#define RADEON_TILING_SURFACE 0x8 /* this object requires a surface
- * when mapped - i.e. front buffer */
+#define RADEON_TILING_MACRO 0x1
+#define RADEON_TILING_MICRO 0x2
+#define RADEON_TILING_SWAP_16BIT 0x4
+#define RADEON_TILING_SWAP_32BIT 0x8
+#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
+ * when mapped - i.e. front buffer */
I know we haven't frozen API yet but this seems a bit unnecessary
to reorder, do we really need swap 16 and 32 bit? does it not
depend on other info about the buffer?
The bytes per element of the buffer contents mostly, but I don't think
we have that information in the kernel for userspace objects. Maybe I'm
missing something.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add initial connector properties
On Wed, 2009-09-09 at 17:40 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This adds:
coherent mode: TMDS coherent mode for atom cards.
scaling mode: LVDS scaler mode
load detect: DAC load detection, DVI-I, VGA, TV
tmds pll: legacy TMDS pll selection
tv standard: TV standard selection.
TODO: other TV ones? dvi subconnector selection using std prop
I haven't tried the patch nor looked at it in detail, but I stumbled
over two places where ATOM vs. COM BIOS calls seem reversed:
+ if (property == rdev-mode_info.tmds_pll_property) {
+ struct radeon_encoder_int_tmds *tmds = NULL;
+ bool ret = false;
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ tmds = radeon_encoder-enc_priv;
+ if (!tmds)
+ return 0;
+
+ if (val == 0) {
+ if (rdev-is_atom_bios)
+ ret =
radeon_legacy_get_tmds_info_from_combios(radeon_encoder, tmds);
+ else
+ ret =
radeon_atombios_get_tmds_info(radeon_encoder, tmds);
+ }
+ if (val == 1 || ret == false) {
+ radeon_legacy_get_tmds_info_from_table(radeon_encoder,
tmds);
+ }
+ radeon_property_change_mode(radeon_encoder-base);
+ }
+
return 0;
}
[...]
+static struct radeon_encoder_int_tmds *radeon_legacy_get_tmds_info(struct
radeon_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct radeon_device *rdev = dev-dev_private;
+ struct radeon_encoder_int_tmds *tmds = NULL;
+ bool ret;
+
+ tmds = kzalloc(sizeof(struct radeon_encoder_int_tmds), GFP_KERNEL);
+
+ if (!tmds)
+ return NULL;
+
+ if (rdev-is_atom_bios)
+ ret = radeon_legacy_get_tmds_info_from_combios(encoder, tmds);
+ else
+ ret = radeon_atombios_get_tmds_info(encoder, tmds);
+
+ if (ret == false)
+ radeon_legacy_get_tmds_info_from_table(encoder, tmds);
+
+ return tmds;
+}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ FWIW: No, compiz (and any other GLX compositing manager, for that matter) works with direct rendering with DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] dri2proto: protocol requests for OML_sync_control and SGI_video_sync
On Sun, 2009-09-06 at 09:46 -0700, Jesse Barnes wrote: On Sun, 06 Sep 2009 12:23:12 +0200 Michel Dänzer mic...@daenzer.net wrote: On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: I've been working on coding up the server and client side of SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with this set of new protocol (against the dri2-swapbuffers branch) to support the new requests. We still need to change the DRI2SwapBuffers request to handle the various OML bits before it gets merged. To summarize: DRI2GetMSCReq - get MSC triple DRI2WaitMSCReq - wait on an MSC count or divisor/remainder DRI2WaitSBCReq - wait on a swap count or all pending swaps Waiting in the X server will make it quite unlikely that the client will be notified within a reasonable timeframe from when vertical blank actually occurs. Won't this jeopardize the usefulness of the functionality? As they're mainly used for throttling drawing, I don't think so. But I also don't see a way to avoid it. In the composited case, compositor interaction will be necessary, and even for non-redirected windows, the client doesn't know which CRTC it's on w/o racing with the server. Waiting in the server doesn't solve the latter problem, does it? The window could move to another CRTC while it's waiting. - compositor interaction; in the compositor case the display server will be incrementing frame count based on compositor drawing rather than vblank events I think that's a bad idea, as it will confuse apps if the compositor misses a frame or renders the app window more than once per frame. It seems to match what people want though; so far we've heard from Soren and Robert and both want to know when the pixels are actually displayed for various apps. W/o compositor interaction I don't see how we can do that. I'm not arguing there should be no protocol between the compositor and clients, but I'm arguing that the frame counter probably isn't appropriate for this. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] dri2proto: protocol requests for OML_sync_control and SGI_video_sync
On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: I've been working on coding up the server and client side of SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with this set of new protocol (against the dri2-swapbuffers branch) to support the new requests. We still need to change the DRI2SwapBuffers request to handle the various OML bits before it gets merged. To summarize: DRI2GetMSCReq - get MSC triple DRI2WaitMSCReq - wait on an MSC count or divisor/remainder DRI2WaitSBCReq - wait on a swap count or all pending swaps Waiting in the X server will make it quite unlikely that the client will be notified within a reasonable timeframe from when vertical blank actually occurs. Won't this jeopardize the usefulness of the functionality? DRI2MSCReply - MSC triple (generated in response to any of the above) Kristian and I talked briefly about doing this client side using events to notify clients when their CRTC changes, but there are a few issues: - races between client blocking and other server events (DPMS, window movement) Maybe the X server could trigger a DRM event that the client could wait for directly, or something like that. - compositor interaction; in the compositor case the display server will be incrementing frame count based on compositor drawing rather than vblank events I think that's a bad idea, as it will confuse apps if the compositor misses a frame or renders the app window more than once per frame. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Wed, 2009-09-02 at 08:24 +0200, Daniel Vetter wrote: btw: intel hw has some nice support for executing untrusted batchbuffers, so no monsterous checker/relocater/munger already present. The radeon CS checker goes far beyond what the Intel hardware provides (and can provide, as e.g. it doesn't know the properties of buffer objects). Whereas on the Thinkpad with a GM45, Mesa driver bugs still result in GPU lockups (with a reboot being the only remedy) too often, on the PowerBook the radeon CS checker usually catches them and sometimes even helps find and fix the bug. That said, the suggestion to use command streams for the overlay doesn't make much sense to me. If that was a good idea, why aren't we doing modesetting that way? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Partial updates with glX/DRI
On Sun, 2009-08-30 at 09:35 +0200, thomas.cook...@nokia.com wrote: While I have this working, it seems a little hacky and isn't widely supported (I have it working on 1 driver build for 1 bit of hardware). If you mean rendering to pixmaps isn't widely supported, that should be getting better with DRI2. I hope so. Although even with DRI2, I think my Intel drivers have broken pixmap rendering at the moment (although it could be Qt which is doing something strange). What's your test? mesa/progs/xdemos/glxgears_pixmap seems to work fine here with intel and radeon. I was testing with just Qt API, but I've also checked that mesa/progs/xdemos/glxpixmap also fails with BadDrawable errors if you change it to use a direct rendering context: v v - ctx = glXCreateContext( dpy, visinfo, NULL, False ); v + ctx = glXCreateContext( dpy, visinfo, NULL, True ); However, after your suggestion, I also tried glxgears_pixmap which seems to work fine with a direct rendering context. I can only assume this is because it uses the FBConfig APIs rather than the older glX APIs (which Qt also uses)? The Mesa libGL patch below fixes progs/xdemos/glxpixmap here with direct rendering, does it help for Qt? Yes, this seems to work for Qt too. Is there any chance of getting this patch into a release? Pushed to the mesa Git 7.5 and master branches[0], so it should be in the 7.5.1 and 7.6 releases. Thanks for testing it. [0] for the mesa3d-dev list: This was complicated by the GLX code re-indenting in master. I wonder if that was worth the trouble... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel fails to boot with radeondrmfb
On Thu, 2009-08-27 at 22:08 +0200, Gerhard Pircher wrote: I gave Radeon kernel mode setting a try on my PPC G4/7455 machine, but the Radeon DRM driver fails to initialize and then the kernel prints Badness at kernel/mutex-debug.c:77. I tested it with an almost (yesterday) fresh checkout of the linus-2.6 (no log, but same output), drm-2.6/drm-fixes and drm-2.6/drm-next git tree. Please take a look at the kernel config, log and lspci.txt files: http://boot.homelinux.org:8080/kernel/drm.config http://boot.homelinux.org:8080/kernel/drm-next.log http://boot.homelinux.org:8080/kernel/drm-fixes.log http://boot.homelinux.org:8080/kernel/lspci.txt The machine is a bit special (non coherent DMA) and there is no AGPGART driver for the northbridge (so the Radeon card should operate in PCIGART mode!?). My guess would be that radeon_gart_table_ram_alloc() fails. Maybe you can add some debugging output there and in r100_pci_gart_enable() to verify that. But I thought it would be good to have it working before the radeonfb driver is removed. :-) I wouldn't worry about that yet, but in the long run we certainly want to encourage everyone to move from radeonfb to KMS. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote: 2009/8/27 Thomas Hellström tho...@shipmail.org: b) It requires the master to act as a scheduler, and circumvents the DRM command submission mechanism through the delayed unpin callback. If this is to workaround any inability of GEM to serve a command submission while a previous command submission is blocked in the kernel, then IMHO that should be fixed and not worked around. It's not about workarounds. Your suggestion *blocks the hw* while waiting for vsync. My patch doesn't do that, it lets other clients submit rendering to pixmap or backbuffer BOs that aren't involved in the pending page flip. If you're willing to block the command stream, GEM can keep the buffer pinned for you until the swap happens just fine. Just like it does for any other command - it's not about that. In fact, I think using the scheduler to keep buffers pinned for scanout is conflating things. The scheduler pulls buffers in and out of the aperture so that they are there for the GPU when it needs to access them. Pinning and unpinning buffers for scanout is a different matter. How is scanout not GPU access? :) I'd look at it the other way around: pinning a scanout buffer is a workaround which is only needed while there are no outstanding fences on it. If the plan is to eliminate DRI2GetBuffers() once per frame, what will then be used to block clients rendering to the old back buffer? There'll be an event that's sent back after each DRI2SwapBuffer and the clients will block on receiving that event. Are you referring to a DRI2 protocol event or a DRM event? We still need to send a request to the xserver and receive confirmation that the xserver has received it before we can render again. DRI2GetBuffers is a request that expects a reply and will block the client on the xserver when we call it. DRI2SwapBuffers is an async request, ie there's no reply and calling it wont block necessarily the client. We still have to wait for the new event before we can go on rendering, but doing it this way makes the client and server less tightly coupled. We may end up doing the roundtrip between client and server at a point where the client was going to block anyway (like disk i/o or something) saving a context switch. It's still a bit fuzzy how this is all supposed to work. To me it seems like (ab)using DRI2GetBuffers for this will only allow clients to avoid synchronous rendering with triple buffering, which would be a shame. If you disagree, can you explain why that isn't the case? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event
for the next frame, and then for the client to block (which could involve a DRM event or whatever if just plain blocking turns out to be a real problem in practice - doubtful IME) on command submission if those buffers still have pending flips. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
