Re: How to backlight_device_register with some kind of low prior (for KMS)
OK, you provided me fair amount of texts to read :) W dniu 15 września 2009 09:43 użytkownik Zhang Rui rui.zh...@intel.com napisał: And I think it may work for you as well, i.e. two backlight sysfs I/F may co-exist, it's the user space to decide which I/F to use. Could you explain, please, how does work Fn+F5 and Fn+F6 in notebooks? I thought it generates some ACPI that kernel identifies as backlight up/down and kernel passes it to module registered with: backlight_device_register(...) is that right? Then two backlight devices would be a problem, I guess? -- Rafał -- 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: clear confusion in GART init/deinit path
GART static one time initialization was mixed up with GART
enabling/disabling which could happen several time for instance
during suspend/resume cycles. This patch splits all GART
handling into 4 differents function. gart_init is for one
time initialization, gart_deinit is called upon module unload
to free resources allocated by gart_init, gart_enable enable
the GART and is intented to be call after first initialization
and at each resume cycle or reset cycle. Finaly gart_disable
stop the GART and is intended to be call at suspend time or
when unloading the module.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 40 ++--
drivers/gpu/drm/radeon/r300.c | 108 +--
drivers/gpu/drm/radeon/r420.c | 57 +++--
drivers/gpu/drm/radeon/r520.c |5 --
drivers/gpu/drm/radeon/r600.c | 53 +++-
drivers/gpu/drm/radeon/radeon.h| 11 +++
drivers/gpu/drm/radeon/radeon_asic.h | 38 +---
drivers/gpu/drm/radeon/radeon_device.c | 36 +--
drivers/gpu/drm/radeon/radeon_gart.c |9 +++-
drivers/gpu/drm/radeon/rs400.c | 53 +++-
drivers/gpu/drm/radeon/rs600.c | 41 +---
drivers/gpu/drm/radeon/rs690.c |3 -
drivers/gpu/drm/radeon/rv515.c |5 --
drivers/gpu/drm/radeon/rv770.c | 37 +++-
14 files changed, 306 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 47263d3..fa0fdc1 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -84,23 +84,28 @@ void r100_pci_gart_tlb_flush(struct radeon_device *rdev)
* could end up in wrong address. */
}
-int r100_pci_gart_enable(struct radeon_device *rdev)
+int r100_pci_gart_init(struct radeon_device *rdev)
{
- uint32_t tmp;
int r;
+ if (rdev-gart.table.ram.ptr) {
+ WARN(1, R100 PCI GART already initialized.\n);
+ return 0;
+ }
/* Initialize common gart structure */
r = radeon_gart_init(rdev);
- if (r) {
+ if (r)
return r;
- }
- if (rdev-gart.table.ram.ptr == NULL) {
- rdev-gart.table_size = rdev-gart.num_gpu_pages * 4;
- r = radeon_gart_table_ram_alloc(rdev);
- if (r) {
- return r;
- }
- }
+ rdev-gart.table_size = rdev-gart.num_gpu_pages * 4;
+ rdev-asic-gart_tlb_flush = r100_pci_gart_tlb_flush;
+ rdev-asic-gart_set_page = r100_pci_gart_set_page;
+ return radeon_gart_table_ram_alloc(rdev);
+}
+
+int r100_pci_gart_enable(struct radeon_device *rdev)
+{
+ uint32_t tmp;
+
/* discard memory request outside of configured range */
tmp = RREG32(RADEON_AIC_CNTL) | RADEON_DIS_OUT_OF_PCI_GART_ACCESS;
WREG32(RADEON_AIC_CNTL, tmp);
@@ -140,13 +145,11 @@ int r100_pci_gart_set_page(struct radeon_device *rdev,
int i, uint64_t addr)
return 0;
}
-int r100_gart_enable(struct radeon_device *rdev)
+void r100_pci_gart_fini(struct radeon_device *rdev)
{
- if (rdev-flags RADEON_IS_AGP) {
- r100_pci_gart_disable(rdev);
- return 0;
- }
- return r100_pci_gart_enable(rdev);
+ r100_pci_gart_disable(rdev);
+ radeon_gart_table_ram_free(rdev);
+ radeon_gart_fini(rdev);
}
@@ -273,9 +276,6 @@ int r100_mc_init(struct radeon_device *rdev)
void r100_mc_fini(struct radeon_device *rdev)
{
- r100_pci_gart_disable(rdev);
- radeon_gart_table_ram_free(rdev);
- radeon_gart_fini(rdev);
}
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index ced3322..bb151ec 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -42,7 +42,6 @@ int r100_cp_reset(struct radeon_device *rdev);
int r100_rb2d_reset(struct radeon_device *rdev);
int r100_cp_init(struct radeon_device *rdev, unsigned ring_size);
int r100_pci_gart_enable(struct radeon_device *rdev);
-void r100_pci_gart_disable(struct radeon_device *rdev);
void r100_mc_setup(struct radeon_device *rdev);
void r100_mc_disable_clients(struct radeon_device *rdev);
int r100_gui_wait_for_idle(struct radeon_device *rdev);
@@ -86,26 +85,57 @@ void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev)
mb();
}
-int rv370_pcie_gart_enable(struct radeon_device *rdev)
+int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
+{
+ void __iomem *ptr = (void *)rdev-gart.table.vram.ptr;
+
+ if (i 0 || i rdev-gart.num_gpu_pages) {
+ return -EINVAL;
+ }
+ addr = (lower_32_bits(addr) 8) |
+ ((upper_32_bits(addr) 0xff) 24) |
+ 0xc;
+ /* on x86 we want this to be CPU endian, on powerpc
+* on powerpc without HW swappers, it'll get
Re: How to backlight_device_register with some kind of low prior (for KMS)
On Tue, 2009-09-15 at 14:24 +0800, Rafał Miłecki wrote: Hi, There are some unfunny cases, when ACPI can not be used for controlling backlight level. Example can be my Sony VAIO (http://bugzilla.kernel.org/show_bug.cgi?id=11682) where bl control doesn't work with sony-laptop. This notebook has ATI GPU that is responsible for backlight level. So we have to implement that in radeon module, which has access to card and can just use register/AtomBIOS to manage backlight. Of course KMS is perfect place for that. However we don't want to play with controlling backlight when there is specific vendor driver for that. Many notebooks are well supported by sony-laptop (and other modules) and in these cases we don't want to change that. Is there some way of detecting if there is vendor-specific driver that cares backlight? Or can we register bl device with some low priority, so when acpi module registers with higher, it will be used? well, a similar issue happens on Intel graphics, http://bugs.freedesktop.org/show_bug.cgi?id=20963 and we have a similar proposal but in fact it doesn't work. you can get detailed information in the below link: http://marc.info/?l=linux-acpim=124650087015684w=2 Now the solution is: 1. register another backlight sysfs device in KMS driver, which is different from ACPI. 2. xrandr supports changing the backlight in multiple way, via different backlight sysfs devices. And I think it may work for you as well, i.e. two backlight sysfs I/F may co-exist, it's the user space to decide which I/F to use. thanks, rui -- 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
[Bug 23402] Latest CVS leads to crash in sauerbraten
http://bugs.freedesktop.org/show_bug.cgi?id=23402 Pauli suok...@gmail.com changed: What|Removed |Added Attachment #29548|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23402] Latest CVS leads to crash in sauerbraten
http://bugs.freedesktop.org/show_bug.cgi?id=23402 --- Comment #17 from Pauli suok...@gmail.com 2009-09-15 01:58:10 PST --- It doesn't reproduce with KMS and kernel memory manager. So if you want to test in your system yo ucan upgrade to 2.6.31 kernel and enable stagging drivers to build KMS support. You will need user-space driver support for KMS. http://xorg.freedesktop.org/wiki/radeonBuildHowTo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: How to backlight_device_register with some kind of low prior (for KMS)
On Tue, 2009-09-15 at 15:54 +0800, Rafał Miłecki wrote: OK, you provided me fair amount of texts to read :) W dniu 15 września 2009 09:43 użytkownik Zhang Rui rui.zh...@intel.com napisał: And I think it may work for you as well, i.e. two backlight sysfs I/F may co-exist, it's the user space to decide which I/F to use. Could you explain, please, how does work Fn+F5 and Fn+F6 in notebooks? I thought it generates some ACPI that kernel identifies as backlight up/down and kernel passes it to module registered with: backlight_device_register(...) is that right? No... the hotkey events can be controlled either by ACPI video device or by ACPI platform specific device, say sony-laptop. There are also other ways that ACPI is not involved but they're beyond my scope. :) If it's controlled via ACPI video device, the ACPI video backlight control usually works at this time. When hotkey is pressed, an ACPI notification is sent to ACPI video device, and then the backlight is changed via ACPI control methods (_BCM/_BCL/_BQC). If it's controlled in ACPI platform specific way, then the platform specific driver (e.g. sony-laptop) can catch the event when hotkey is pressed and invokes the platform specific methods to change the backlight. Then two backlight devices would be a problem, I guess? I agree. but we don't have any better idea for now. :( thanks, rui -- 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
[Bug 23234] radeon , kms , xrandr - mouse disspaears on secondary screen
http://bugs.freedesktop.org/show_bug.cgi?id=23234 --- Comment #12 from Ioannis Koutras ioannis.kout...@gmail.com 2009-09-15 02:09:59 PST --- I confirm that SWcursor is working, as well as the xrandr commands Kevin DeKorte gave in #10: xrandr in two commands (off and auto with placement setting) is working just fine, but in three commands (off, auto and placement setting seperately) it is not. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
On Fri, Sep 11, 2009 at 11:00:27PM +0100, Dave Airlie wrote: Okay incompatible interfaces are not acceptable unless they are major version number changes. Minor or patch version changes should not break the kernel interface in any way unless its a major security hole being solved, and even then a major version bump is probably preferred. Userspace should always be able to work with the major number it expects, it can also place a lower bound on minor numbers if it wants, but it should not require an equality of minor or path. Are you saying Yes, it is right to carry version information in the drm.h file? And yes, the usage of major, minor and patchlevel is clear, and didn't really need repeating. If we have shipped a minor version bump in the upstream kernel that breaks userspace point it out and I'll revert it. No, you didn't ship it, yet, and exactly to stop this from shipping the major issues i have with these patches were pointed out. Now if a certain vendor ships kernel patches without testing or posting them upstream first, then there isn't much we can do except bitch at the clueless maintainers of that kernel. That part was being taken care of, and by pointing out the problem, i hoped that it would first finally really get reverted, and secondly not happen again for the same set of patches. The thing is the major number is all you should need to carry really, the userspace API isn't just defined by this header file, other thing internal to the module can affect the API like the command stream verifier. So the kernel could require a drm minor bump for some new verifier restriction, and this header file wouldn't change at all, or would just have a pointless version number bump. So the kernel version should not be tied directly to this file version either. But why not have all three numbers _in_ _the_ _same_ _place_. Disperse them, and sooner or later someone tries to be smart and then breaks the versioning scheme. Userspace is free to try to be compatible as much as it wants then, or ignore as much as it can, or it can just stupidly break down and cry loudly when just the patchlevel gets bumped. At least you get good feedback. It doesn't allow for major version number changes gracefully at all, nothing does, Depends on the definition of gracefully. I fully agree that major bumps should be avoided at all cost, but they are sometimes impossible to avoid. And then we can try to deal with it as gracefully as possible. if the kernel suddenly only produces a version 3.0 via drm API it will break all current VIA userspace drivers, this would never be acceptable *ever*. Hence my statements in the original mail. For KMS we have made an exception as its a requirement that people update userspace to enable KMS, but we've also made sure we enver enable these by deafult upstream, only at a distro level where hopefully they realise they need a compat userspace before turning stuff on. For unichrome, the dma stuff suddenly lost bouncebuffer (iirc this was once used for pitch conversion) support and the respective structure members. Now in autotool-world, you can check headers for that easily, in Imake world, things were not that easy. One can easily make things buildtime compatible, by providing version numbers in the header file, and by bumping the major number. Runtime compatibility can then be checked easily by using the major define directly. I still do not see why you are against this. It is not exactly rocketscience, it solves some of the problems we were facing, and it works. A clean updated patch to the kernel, but really nothing you've said convinces me in any way this isn't just an attempt to workaround a crap developemnt process where nobody is maintaining API compatability. To be able to deal with things, the version numbering was introduced. API compatibility would have had a better chance of surviving if the versioning was also put in the kernel tree. This whole situation clearly reeks of a broken process. Have you recently diffed the mesa/drm and the kernel/drm and seen what the differences are, or are you just grabbing patches from one and putting them in the other, letting both trees grow apart over time? Okay so if that is these patches, then that is an issue, Novell screwed up by not upstreaming this first, but thats not uncommon. This were VIA patches sent to the dri-devel ml which got ignored completely. Gregkh used these patches that never really became upstreamed, and then failed to even warn the SUSE X developers about it (at least, i missed it at the time it was included, and i was still there, not 100% sure about the others, even though i am sure that i would've been told this immediately). Novell did not have to upstream itself, so please stop suggesting that this was Novell doing stuff behind closed doors. Surely redhat never used/shipped code that wasn't fully upstream yet. And
[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: [BUG] radeon kernel command checker blocks 32 bit gl(x)info on x86_64
2009/9/15 Thierry Vignaud tvign...@mandriva.com:
Hi,
It looks like the radeon kernel command checker blocks some of
gl(x)info's 32 bit commands. Here's dmesg output
ioctl32(glxinfo:5153): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ff9b517c) on /dev/dri/card0
ioctl32(glinfo:5184): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ff86c5dc) on /dev/dri/card0
ioctl32(glxinfo:9875): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ffed0e1c) on /dev/dri/card0
The result is that glinfo glxinfo reports bogus data with KMS enabled:
$ glinfo|egrep 'RENDER|VENDOR'
GL_RENDERER: Software Rasterizer
GL_VENDOR: Mesa Project
... whereas openarena does show the proper strings and (more
importantly) run smoothly using hw acceleration.
This is with 32bit glinfo on 64bit kernel (2.6.31 final with
CONFIG_DRM_RADEON_KMS=y, libdrm). Both 32b 64b build of libdrm-2.4.13
have been build --enable-radeon-experimental-api. In fact all are
standard packages from Mandriva Cooker.
Note that the 64bit build works nicely:
# ./32/glinfo |egrep 'RENDER|VENDOR'
GL_RENDERER: Software Rasterizer
GL_VENDOR: Mesa Project
# ./64/glinfo |egrep 'RENDER|VENDOR'
GL_RENDERER: Mesa DRI R300 (RV350 4150) 20090101 TCL DRI2
GL_VENDOR: DRI R300 Project
Maybe a compat ioctl issue?
Already fixed. See:
http://bugs.freedesktop.org/show_bug.cgi?id=22271
Alex
--
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
[BUG] radeon kernel command checker blocks 32 bit gl(x)info on x86_64
Hi,
It looks like the radeon kernel command checker blocks some of
gl(x)info's 32 bit commands. Here's dmesg output
ioctl32(glxinfo:5153): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ff9b517c) on /dev/dri/card0
ioctl32(glinfo:5184): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4} arg(ff86c5dc)
on /dev/dri/card0
ioctl32(glxinfo:9875): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ffed0e1c) on /dev/dri/card0
The result is that glinfo glxinfo reports bogus data with KMS enabled:
$ glinfo|egrep 'RENDER|VENDOR'
GL_RENDERER: Software Rasterizer
GL_VENDOR: Mesa Project
... whereas openarena does show the proper strings and (more
importantly) run smoothly using hw acceleration.
This is with 32bit glinfo on 64bit kernel (2.6.31 final with
CONFIG_DRM_RADEON_KMS=y, libdrm). Both 32b 64b build of libdrm-2.4.13
have been build --enable-radeon-experimental-api. In fact all are
standard packages from Mandriva Cooker.
Note that the 64bit build works nicely:
# ./32/glinfo |egrep 'RENDER|VENDOR'
GL_RENDERER: Software Rasterizer
GL_VENDOR: Mesa Project
# ./64/glinfo |egrep 'RENDER|VENDOR'
GL_RENDERER: Mesa DRI R300 (RV350 4150) 20090101 TCL DRI2
GL_VENDOR: DRI R300 Project
Maybe a compat ioctl issue?
--
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
[Bug 23965] New: radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 Summary: radeonBackground objects appear in front of foreground ones in neverball Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: p...@kantaka.co.uk When playing neverball with git mesa drm-adg5f as of today, the textures for the level exits appear on in front of other foreground objects. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #1 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 10:36:17 PST --- Created an attachment (id=29569) -- (http://bugs.freedesktop.org/attachment.cgi?id=29569) Exit appears over foreground objects -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 Phil Armstrong p...@kantaka.co.uk changed: What|Removed |Added OS/Version|All |Linux (All) Platform|Other |x86 (IA32) Version|XOrg CVS|DRI CVS -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #2 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 10:37:15 PST --- Sorry, that posted by accident. Extra information: r600 DRI driver from drm-agd5f with kernel 2.6.30, git mesa as of today. $ lspci ... 01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #3 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 10:41:41 PST --- Created an attachment (id=29570) -- (http://bugs.freedesktop.org/attachment.cgi?id=29570) Correct software rendering -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #4 from Alex Deucher ag...@yahoo.com 2009-09-15 11:02:23 PST --- Seems to work fine here with neverball 1.4.0. I wonder if this is a bug in your version of neverball. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
bisected engine demo
The following commit causes texture issues on r600 at least, I haven't tried other hardware currently. Running engine demo starts out correctly, but when cycling 'm' the issue appears. bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit commit bcb62ae78a9d2f4d08001e9f207b6f1291443968 Author: Brian Paul bri...@vmware.com Date: Thu Sep 3 21:27:06 2009 -0600 mesa: _mesa_meta_bitmap() function :04 04 59187a621eb3c63005926ba958fa0ad610ddbb88 eb4da44a186e7f90c07b64a0abf7e1307e015c25 M src robert. -- Robert Noland rnol...@2hip.net 2Hip Networks -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #5 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 11:29:01 PST --- C'set possible. neverball version 1.5.2 here. Just tried 1.4: The level exits are correctly rendered with that version, but looking closely, the edges of the rotating coins are incorrectly rendered: they appear to be transparent round the top half and reflecting some unknown texture on the bottom half. With software rendering through git mesa, the edges of the coins are golden shaded like the faces are. I can try and get a screenshot to show it, but it's more obvious when they're rotating. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #6 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 11:29:26 PST --- (In reply to comment #5) C'set possible. or C'est even. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: bisected engine demo
Robert Noland wrote: The following commit causes texture issues on r600 at least, I haven't tried other hardware currently. Running engine demo starts out correctly, but when cycling 'm' the issue appears. bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit commit bcb62ae78a9d2f4d08001e9f207b6f1291443968 Author: Brian Paul bri...@vmware.com Date: Thu Sep 3 21:27:06 2009 -0600 mesa: _mesa_meta_bitmap() function :04 04 59187a621eb3c63005926ba958fa0ad610ddbb88 eb4da44a186e7f90c07b64a0abf7e1307e015c25 M src This can't possibly be the right commit since at that point in the history, nobody calls that function yet. That said, I found a bug in the code which probably causes the textured bitmap bug. I've committed it to master. -Brian -- 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
[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball
http://bugs.freedesktop.org/show_bug.cgi?id=23965 --- Comment #7 from Phil Armstrong p...@kantaka.co.uk 2009-09-15 11:48:26 PST --- Created an attachment (id=29571) -- (http://bugs.freedesktop.org/attachment.cgi?id=29571) Bad rendering of coin edges in neverball 1.4 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
Are you saying Yes, it is right to carry version information in the drm.h file? No I'm still in no way convinced of this, the fact Thomas doesn't see it as a requirement either, and *no* other drm driver does it, is all pointing towards its unnecessary. You seem to think its obvious but we've survived with radeon and intel and mga and multiple other drivers never having this requirement, hence why I am asking for clarification. And yes, the usage of major, minor and patchlevel is clear, and didn't really need repeating. It didn't seem to be, you seem to want to have a fixed minor/patch level support in the DDX which isn't the normal definition of minor/patch. So clarification was required. No, you didn't ship it, yet, and exactly to stop this from shipping the major issues i have with these patches were pointed out. And thats how the process should work, people review the patches and crappy breaks don't get in, not we shove them in, and hope the DDX has graceful abilities to fall over in a heap. But why not have all three numbers _in_ _the_ _same_ _place_. Disperse them, and sooner or later someone tries to be smart and then breaks the versioning scheme. So you haven't answered the point I raised, the API version isn't only tied to this file, other internal things like the verifier also influcence the API, how do you detect these sort of things at build time? Userspace is free to try to be compatible as much as it wants then, or ignore as much as it can, or it can just stupidly break down and cry loudly when just the patchlevel gets bumped. At least you get good feedback. I don't think userspace should be given that option, userspace should be required to be sane, it should work with any kernel with the same major version and possibly a minor bump, I wouldn't want distros shipping a user space that was uniquely tied to a shipping kernel api minor/patch version, that is crazy and makes the whole point of having a major/minor/patch version stupid. So maybe adding this version number allows for this use-case but its not something we should be making any attempt to support. Depends on the definition of gracefully. I fully agree that major bumps should be avoided at all cost, but they are sometimes impossible to avoid. And then we can try to deal with it as gracefully as possible. You cannot just bump major in the kernel version, its easier to publish either a while new driver with a new name, *or* have a kernel option to expose old or new versions, with the new version never getting enabled by default for something around 5-6 years. For unichrome, the dma stuff suddenly lost bouncebuffer (iirc this was once used for pitch conversion) support and the respective structure members. Now in autotool-world, you can check headers for that easily, in Imake world, things were not that easy. One can easily make things buildtime compatible, by providing version numbers in the header file, and by bumping the major number. Runtime compatibility can then be checked easily by using the major define directly. I still do not see why you are against this. It is not exactly rocketscience, it solves some of the problems we were facing, and it works. To be able to deal with things, the version numbering was introduced. API compatibility would have had a better chance of surviving if the versioning was also put in the kernel tree. This whole situation clearly reeks of a broken process. Have you recently diffed the mesa/drm and the kernel/drm and seen what the differences are, or are you just grabbing patches from one and putting them in the other, letting both trees grow apart over time? Okay so if that is these patches, then that is an issue, Novell screwed up by not upstreaming this first, but thats not uncommon. This were VIA patches sent to the dri-devel ml which got ignored completely. Gregkh used these patches that never really became upstreamed, and then failed to even warn the SUSE X developers about it (at least, i missed it at the time it was included, and i was still there, not 100% sure about the others, even though i am sure that i would've been told this immediately). We didn't ignore any via patches to the mailing list, we reviewed nearly every submission of code and found most of it unsuitable for upstreaming as it was. Novell did not have to upstream itself, so please stop suggesting that this was Novell doing stuff behind closed doors. If Greg did this as part of staging I also objected to this on lkml at one time. Surely redhat never used/shipped code that wasn't fully upstream yet. Not when the upstream maintainer said there was now way it would ever ship in the current form. You can't gracefuly handle major bumps, unless you count disabling DRI on someones working system acceptable which we don't anymore. The only way I can think to do a major number rest is with a Kconfig option that
Re: bisected engine demo
On Tue, 2009-09-15 at 12:38 -0600, Brian Paul wrote: Robert Noland wrote: The following commit causes texture issues on r600 at least, I haven't tried other hardware currently. Running engine demo starts out correctly, but when cycling 'm' the issue appears. bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit commit bcb62ae78a9d2f4d08001e9f207b6f1291443968 Author: Brian Paul bri...@vmware.com Date: Thu Sep 3 21:27:06 2009 -0600 mesa: _mesa_meta_bitmap() function :04 04 59187a621eb3c63005926ba958fa0ad610ddbb88 eb4da44a186e7f90c07b64a0abf7e1307e015c25 M src This can't possibly be the right commit since at that point in the history, nobody calls that function yet. That said, I found a bug in the code which probably causes the textured bitmap bug. I've committed it to master. This is where git bisect led me... covering the full tree using r600. That said, I was only installing r600_dri.so during the bisection. Your commit does resolve the issue. robert. -Brian -- Robert Noland rnol...@2hip.net 2Hip Networks -- 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
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 --- Comment #8 from Adam K Kirchhoff ad...@voicenet.com 2009-09-15 13:29:41 PST --- After a brief discussion with airlied on #radeon, I checked the contents of /sys/class/drm/card0-*/dpms and both monitors had On. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 22271] On 64bit kernel(drm-next-radeon) ioctls from 32bit application doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=22271 --- Comment #14 from Krzysztof A. Sobiecki sob...@gmail.com 2009-09-15 13:29:17 PST --- It looks like commit 70ba2a374704e00df8868a7ac3d7350329d28924 in drm-next(drm-2.6) fixed this bug. I will close it, after merging of this commit into main tree. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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.
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. Dave. 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
Re: [PATCH] drm/radeon/kms: Use depth 16 for console.
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. Dave. 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
Re: [PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.
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_t flags;
};
-#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?
Dave.
--
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: Use depth 16 for console.
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. Dave. -- 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, 16 Sep 2009 00:12:21 +0200 Michel Dänzer mic...@daenzer.net wrote: 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. We had a similar bug on the intel side; turned out our pipe base function wasn't masking out the depth bits, just or'ing them in, so the correct setting wouldn't take effect if the depth changed in some cases. Not that I've looked at the radeon bits... -- Jesse Barnes, Intel Open Source Technology Center -- 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
[Bug 9468] mesa compiles different versions of libGL.so in different modes
http://bugs.freedesktop.org/show_bug.cgi?id=9468 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #2 from Brian Paul brian.e.p...@gmail.com 2009-09-15 15:24:27 PST --- Nothing to do for this old bug report. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 0/8] drmmode overlay support v3
Hi all, Latest version of my overlay kms work. I've added the new stuff as separated patches for easier testing in case something blows up. Please review. Thanks, Daniel Daniel Vetter (8): [drm]: make drm_mode_object_find typesafe [drm/i915]: add i915_lp_ring_sync helper [drm/i915]: kill superflous IS_I855 macro [drm/i915] implement drmmode overlay support v4 [drm/i915] fully switch off overlay when not in use [drm/i915] implement fastpath for overlay flip waiting [drm/i915] implement interruptible sleeps in the overlay code [drm/i915] kill i915_lp_ring_sync drivers/gpu/drm/drm_crtc.c |3 +- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_dma.c |7 + drivers/gpu/drm/i915/i915_drv.h |8 +- drivers/gpu/drm/i915/i915_gem.c | 37 +- drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_display.c | 45 +- drivers/gpu/drm/i915/intel_drv.h | 39 + drivers/gpu/drm/i915/intel_overlay.c | 1420 ++ include/drm/drm_crtc.h |3 +- include/drm/drm_os_linux.h |2 +- include/drm/i915_drm.h | 71 ++ 12 files changed, 1620 insertions(+), 21 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay.c -- 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 4/8] [drm/i915] implement drmmode overlay support v4
This implements intel overlay support for kms via a device-specific
ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on
dri-devel). We've reached the conclusion that such an infrastructure
only makes sense when multiple kms overlay implementations exists,
which atm don't (and it doesn't look like this is gonna change).
Open issues:
- Runs in sync with the gpu, i.e. unnecessary waiting. I've decided
to wait on this because the hw tends to hang when changing something
in this area. I left some dummy functions as infrastructure.
- polyphase filtering uses a static table.
- uses uninterruptible sleeps. Unfortunately the alternatives may
unnecessarily wedged the hw if/when we timeout too early (and
userspace only overloaded the batch buffers with stuff worth a few
secs of gpu time).
Changes since v1:
- fix off-by-one misconception on my side. This fixes fullscreen
playback.
Changes since v2:
- add underrun detection as spec'ed for i965.
- flush caches properly, fixing visual corruptions.
Changes since v4:
- fix up cache flushing of overlay memory regs.
- killed require_pipe_a logic - it hangs the chip.
Tested-By: diego.abele...@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_dma.c |7 +
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 30 +
drivers/gpu/drm/i915/intel_overlay.c | 1293 ++
include/drm/i915_drm.h | 71 ++
8 files changed, 1434 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5269dfa..b2f030c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -22,6 +22,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_fb.o \
intel_tv.o \
intel_dvo.o \
+ intel_overlay.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
dvo_ivch.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5a6b731..146655b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -800,6 +800,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_NUM_FENCES_AVAIL:
value = dev_priv-num_fence_regs - dev_priv-fence_reg_start;
break;
+ case I915_PARAM_HAS_OVERLAY:
+ value = dev_priv-overlay ? 1 : 0;
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
@@ -1498,6 +1501,8 @@ int i915_driver_unload(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
drm_mm_takedown(dev_priv-vram);
i915_gem_lastclose(dev);
+
+ intel_cleanup_overlay(dev);
}
pci_dev_put(dev_priv-bridge_dev);
@@ -1605,6 +1610,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, 0),
DRM_IOCTL_DEF(DRM_I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
0),
DRM_IOCTL_DEF(DRM_I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, 0),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7e5683e..d31198b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -153,6 +153,7 @@ struct drm_i915_error_state {
struct timeval time;
};
+struct intel_overlay;
typedef struct drm_i915_private {
struct drm_device *dev;
@@ -216,6 +217,9 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
+ /* overlay */
+ struct intel_overlay *overlay;
+
/* LVDS info */
int backlight_duty_cycle; /* restore backlight to this value */
bool panel_wants_dither;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f7c2de8..88c6884 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -135,6 +135,7 @@
#define MI_NOOPMI_INSTR(0, 0)
#define MI_USER_INTERRUPT MI_INSTR(0x02, 0)
#define MI_WAIT_FOR_EVENT MI_INSTR(0x03, 0)
+#define MI_WAIT_FOR_OVERLAY_FLIP (116)
#define MI_WAIT_FOR_PLANE_B_FLIP (16)
#define MI_WAIT_FOR_PLANE_A_FLIP (12)
#define MI_WAIT_FOR_PLANE_A_SCANLINES (11)
@@ -146,6 +147,10 @@
#define MI_END_SCENE (1 4) /* flush binner and incr
[PATCH 7/8] [drm/i915] implement interruptible sleeps in the overlay code
At least for the common case of userspace ioctls. When doing a
modeset operation, the wait is still uninterruptible. But considering
that failing to turn off the overlay when switching off the crtc it's
running on hangs the chip, it doesn't complicate matters _very_
much. There's just an unkillable X in addition to a black screen.
BUG() about it and explain in the code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 17 +++-
drivers/gpu/drm/i915/intel_drv.h |9 ++-
drivers/gpu/drm/i915/intel_overlay.c | 167 +++---
3 files changed, 159 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19773c9..3112bf3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1703,11 +1703,26 @@ static void igdng_crtc_dpms(struct drm_crtc *crtc, int
mode)
static void intel_crtc_dpms_overlay(struct intel_crtc *intel_crtc, bool enable)
{
struct intel_overlay *overlay;
+ int ret;
if (!enable intel_crtc-overlay) {
overlay = intel_crtc-overlay;
mutex_lock(overlay-dev-struct_mutex);
- intel_overlay_switch_off(overlay);
+ for (;;) {
+ ret = intel_overlay_switch_off(overlay);
+ if (ret == 0)
+ break;
+
+ ret = intel_overlay_recover_from_interrupt(overlay, 0);
+ if (ret != 0) {
+ /* overlay doesn't react anymore. Usually
+* results in a black screen and an unkillable
+* X server. */
+ BUG();
+ overlay-hw_wedged = HW_WEDGED;
+ break;
+ }
+ }
mutex_unlock(overlay-dev-struct_mutex);
}
/* Let userspace switch the overlay on again. In most cases userspace
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9eea5c7..8a0fddf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -126,8 +126,13 @@ struct intel_overlay {
struct drm_i915_gem_object *reg_bo;
void *virt_addr;
/* flip handling */
- int hw_wedged;
uint32_t last_flip_req;
+ int hw_wedged;
+#define HW_WEDGED 1
+#define NEEDS_WAIT_FOR_FLIP2
+#define RELEASE_OLD_VID3
+#define SWITCH_OFF_STAGE_1 4
+#define SWITCH_OFF_STAGE_2 5
};
struct intel_crtc {
@@ -207,6 +212,8 @@ extern int intel_framebuffer_create(struct drm_device *dev,
extern void intel_setup_overlay(struct drm_device *dev);
extern void intel_cleanup_overlay(struct drm_device *dev);
extern int intel_overlay_switch_off(struct intel_overlay *overlay);
+extern int intel_overlay_recover_from_interrupt(struct intel_overlay *overlay,
+ int interruptible);
extern int intel_overlay_put_image(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int intel_overlay_attrs(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 85e07e4..972d715 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -222,6 +222,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
BUG_ON(overlay-active);
+ overlay-active = 1;
+ overlay-hw_wedged = NEEDS_WAIT_FOR_FLIP;
+
BEGIN_LP_RING(6);
OUT_RING(MI_FLUSH);
OUT_RING(MI_NOOP);
@@ -231,15 +234,16 @@ static int intel_overlay_on(struct intel_overlay *overlay)
OUT_RING(MI_NOOP);
ADVANCE_LP_RING();
- ret = i915_lp_ring_sync(dev);
- if (ret != 0) {
- DRM_ERROR(intel overlay: ring sync failed, hw likely
wedged\n);
- overlay-hw_wedged = 1;
- return 0;
- }
+ overlay-last_flip_req = i915_add_request(dev, NULL, 0);
+ if (overlay-last_flip_req == 0)
+ return -ENOMEM;
- overlay-active = 1;
+ ret = i915_do_wait_request(dev, overlay-last_flip_req, 1);
+ if (ret != 0)
+ return ret;
+ overlay-hw_wedged = 0;
+ overlay-last_flip_req = 0;
return 0;
}
@@ -283,7 +287,6 @@ static int intel_overlay_wait_flip(struct intel_overlay
*overlay)
if (overlay-last_flip_req != 0) {
ret = i915_do_wait_request(dev, overlay-last_flip_req, 0);
-
if (ret != 0)
return ret;
@@ -296,19 +299,24 @@ static int intel_overlay_wait_flip(struct intel_overlay
*overlay)
}
/* synchronous slowpath */
+ overlay-hw_wedged =
[PATCH 1/8] [drm]: make drm_mode_object_find typesafe
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ba728ad..78eeec7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -247,7 +247,8 @@ static void drm_mode_object_put(struct drm_device *dev,
mutex_unlock(dev-mode_config.idr_mutex);
}
-void *drm_mode_object_find(struct drm_device *dev, uint32_t id, uint32_t type)
+struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type)
{
struct drm_mode_object *obj = NULL;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ae1e9e1..f4c0fbc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -699,7 +699,8 @@ extern void drm_mode_connector_detach_encoder(struct
drm_connector *connector,
struct drm_encoder *encoder);
extern bool drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-extern void *drm_mode_object_find(struct drm_device *dev, uint32_t id,
uint32_t type);
+extern struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type);
/* IOCTLs */
extern int drm_mode_getresources(struct drm_device *dev,
void *data, struct drm_file *file_priv);
--
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 0/2] [VIA UniChrome DRM] Patch system hang issue caused by 3D scaling+ACPI
On Tue, Sep 15, 2009 at 08:57:28PM +0100, Dave Airlie wrote: Novell did not have to upstream itself, so please stop suggesting that this was Novell doing stuff behind closed doors. If Greg did this as part of staging I also objected to this on lkml at one time. Huh? I added this code to a Novell kernel tree on behalf of a vendor and in coordination with the xorg developers at Novell. If that kernel is messed up, it's my fault, and I'll go fix it up. But that has nothing to do with upstream at all, as I have not put the via driver into the staging tree. thanks, greg k-h -- 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 3/8] [drm/i915]: kill superflous IS_I855 macro
It is identical to I85X. Use that one instead.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0327ecf..7e5683e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -858,7 +858,6 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
#define IS_I830(dev) ((dev)-pci_device == 0x3577)
#define IS_845G(dev) ((dev)-pci_device == 0x2562)
#define IS_I85X(dev) ((dev)-pci_device == 0x3582)
-#define IS_I855(dev) ((dev)-pci_device == 0x3582)
#define IS_I865G(dev) ((dev)-pci_device == 0x2572)
#define IS_I915G(dev) ((dev)-pci_device == 0x2582 || (dev)-pci_device ==
0x258a)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cadb9ef..7294a8f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1922,7 +1922,7 @@ static int intel_get_core_clock_speed(struct drm_device
*dev)
}
} else if (IS_I865G(dev))
return 266000;
- else if (IS_I855(dev)) {
+ else if (IS_I85X(dev)) {
u16 hpllcc = 0;
/* Assume that the hardware is in the high speed state. This
* should be the default.
@@ -4019,7 +4019,7 @@ void intel_init_clock_gating(struct drm_device *dev)
dstate |= DSTATE_PLL_D3_OFF | DSTATE_GFX_CLOCK_GATING |
DSTATE_DOT_CLOCK_GATING;
I915_WRITE(D_STATE, dstate);
- } else if (IS_I855(dev) || IS_I865G(dev)) {
+ } else if (IS_I85X(dev) || IS_I865G(dev)) {
I915_WRITE(RENCLK_GATE_D1, SV_CLOCK_GATE_DISABLE);
} else if (IS_I830(dev)) {
I915_WRITE(DSPCLK_GATE_D, OVRUNIT_CLOCK_GATE_DISABLE);
--
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 6/8] [drm/i915] implement fastpath for overlay flip waiting
As long as the gpu can keep up, neither the cpu (waiting for gpu)
nore the gpu (waiting for vblank to do an overlay flip) stalls.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_gem.c |4 +-
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_overlay.c | 43 ++---
4 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d31198b..8b17942 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -724,6 +724,9 @@ void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int i915_gem_do_init(struct drm_device *dev, unsigned long start,
unsigned long end);
int i915_gem_idle(struct drm_device *dev);
+uint32_t i915_add_request(struct drm_device *dev, struct drm_file *file_priv,
+ uint32_t flush_domains);
+int i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int
interruptible);
int i915_lp_ring_sync(struct drm_device *dev);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int i915_gem_object_set_to_gtt_domain(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a3d8fa8..4793766 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1518,7 +1518,7 @@ i915_gem_object_move_to_inactive(struct drm_gem_object
*obj)
*
* Returned sequence numbers are nonzero on success.
*/
-static uint32_t
+uint32_t
i915_add_request(struct drm_device *dev, struct drm_file *file_priv,
uint32_t flush_domains)
{
@@ -1738,7 +1738,7 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(dev-struct_mutex);
}
-static int
+int
i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int interruptible)
{
drm_i915_private_t *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f84a0cf..9eea5c7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -125,7 +125,9 @@ struct intel_overlay {
u32 flip_addr;
struct drm_i915_gem_object *reg_bo;
void *virt_addr;
+ /* flip handling */
int hw_wedged;
+ uint32_t last_flip_req;
};
struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 4e88abb..85e07e4 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -251,7 +251,6 @@ static void intel_overlay_continue(struct intel_overlay
*overlay,
drm_i915_private_t *dev_priv = dev-dev_private;
u32 flip_addr = overlay-flip_addr;
u32 tmp;
- int ret;
RING_LOCALS;
BUG_ON(!overlay-active);
@@ -264,11 +263,40 @@ static void intel_overlay_continue(struct intel_overlay
*overlay,
if (tmp (1 17))
DRM_DEBUG(overlay underrun, DOVSTA: %x\n, tmp);
- BEGIN_LP_RING(6);
+ BEGIN_LP_RING(4);
OUT_RING(MI_FLUSH);
OUT_RING(MI_NOOP);
OUT_RING(MI_OVERLAY_FLIP | MI_OVERLAY_CONTINUE);
OUT_RING(flip_addr);
+ADVANCE_LP_RING();
+
+ overlay-last_flip_req = i915_add_request(dev, NULL, 0);
+}
+
+static int intel_overlay_wait_flip(struct intel_overlay *overlay)
+{
+ struct drm_device *dev = overlay-dev;
+drm_i915_private_t *dev_priv = dev-dev_private;
+ int ret;
+ u32 tmp;
+ RING_LOCALS;
+
+ if (overlay-last_flip_req != 0) {
+ ret = i915_do_wait_request(dev, overlay-last_flip_req, 0);
+
+ if (ret != 0)
+ return ret;
+
+ overlay-last_flip_req = 0;
+
+ tmp = I915_READ(ISR);
+
+ if (!(tmp I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
+ return 0;
+ }
+
+ /* synchronous slowpath */
+ BEGIN_LP_RING(2);
OUT_RING(MI_WAIT_FOR_EVENT | MI_WAIT_FOR_OVERLAY_FLIP);
OUT_RING(MI_NOOP);
ADVANCE_LP_RING();
@@ -279,13 +307,8 @@ static void intel_overlay_continue(struct intel_overlay
*overlay,
DRM_ERROR(intel overlay: ring sync failed, hw likely
wedged\n);
overlay-hw_wedged = 1;
}
-}
-static int intel_overlay_wait_flip(struct intel_overlay *overlay)
-{
- /* don't overcomplicate things for now with asynchronous operations
-* see comment above */
- return 0;
+ return ret;
}
/* overlay needs to be disabled in OCMD reg */
@@ -344,7 +367,9 @@ static int intel_overlay_off(struct intel_overlay *overlay)
return ret;
}
-/* wait for pending overlay flip and release old frame */
+/* Wait for pending overlay flip and release old frame.
+ * Needs to be called before the overlay register are changed
[PATCH 8/8] [drm/i915] kill i915_lp_ring_sync
It's not needed anymore.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 18 --
2 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b17942..a4fa3e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -727,7 +727,6 @@ int i915_gem_idle(struct drm_device *dev);
uint32_t i915_add_request(struct drm_device *dev, struct drm_file *file_priv,
uint32_t flush_domains);
int i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int
interruptible);
-int i915_lp_ring_sync(struct drm_device *dev);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int i915_gem_object_set_to_gtt_domain(struct drm_gem_object *obj,
int write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4793766..b1dd1d6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1803,24 +1803,6 @@ i915_wait_request(struct drm_device *dev, uint32_t seqno)
return i915_do_wait_request(dev, seqno, 1);
}
-/**
- * Waits for the ring to finish up to the latest request. Usefull for waiting
- * for flip events, e.g for the overlay support. */
-int i915_lp_ring_sync(struct drm_device *dev)
-{
- uint32_t seqno;
- int ret;
-
- seqno = i915_add_request(dev, NULL, 0);
-
- if (seqno == 0)
- return -ENOMEM;
-
- ret = i915_do_wait_request(dev, seqno, 0);
- BUG_ON(ret == -ERESTARTSYS);
- return ret;
-}
-
static void
i915_gem_flush(struct drm_device *dev,
uint32_t invalidate_domains,
--
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 2/8] [drm/i915]: add i915_lp_ring_sync helper
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm/drm_os_linux.h |2 +-
3 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0344afd..0327ecf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -720,6 +720,7 @@ void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int i915_gem_do_init(struct drm_device *dev, unsigned long start,
unsigned long end);
int i915_gem_idle(struct drm_device *dev);
+int i915_lp_ring_sync(struct drm_device *dev);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int i915_gem_object_set_to_gtt_domain(struct drm_gem_object *obj,
int write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e0da986..a3d8fa8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1738,12 +1738,8 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(dev-struct_mutex);
}
-/**
- * Waits for a sequence number to be signaled, and cleans up the
- * request and object lists appropriately for that event.
- */
static int
-i915_wait_request(struct drm_device *dev, uint32_t seqno)
+i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int interruptible)
{
drm_i915_private_t *dev_priv = dev-dev_private;
u32 ier;
@@ -1765,10 +1761,17 @@ i915_wait_request(struct drm_device *dev, uint32_t
seqno)
dev_priv-mm.waiting_gem_seqno = seqno;
i915_user_irq_get(dev);
- ret = wait_event_interruptible(dev_priv-irq_queue,
-
i915_seqno_passed(i915_get_gem_seqno(dev),
-seqno) ||
- dev_priv-mm.wedged);
+ if (interruptible)
+ ret = wait_event_interruptible(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+ else
+ wait_event(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+
i915_user_irq_put(dev);
dev_priv-mm.waiting_gem_seqno = 0;
}
@@ -1790,6 +1793,34 @@ i915_wait_request(struct drm_device *dev, uint32_t seqno)
return ret;
}
+/**
+ * Waits for a sequence number to be signaled, and cleans up the
+ * request and object lists appropriately for that event.
+ */
+static int
+i915_wait_request(struct drm_device *dev, uint32_t seqno)
+{
+ return i915_do_wait_request(dev, seqno, 1);
+}
+
+/**
+ * Waits for the ring to finish up to the latest request. Usefull for waiting
+ * for flip events, e.g for the overlay support. */
+int i915_lp_ring_sync(struct drm_device *dev)
+{
+ uint32_t seqno;
+ int ret;
+
+ seqno = i915_add_request(dev, NULL, 0);
+
+ if (seqno == 0)
+ return -ENOMEM;
+
+ ret = i915_do_wait_request(dev, seqno, 0);
+ BUG_ON(ret == -ERESTARTSYS);
+ return ret;
+}
+
static void
i915_gem_flush(struct drm_device *dev,
uint32_t invalidate_domains,
@@ -1856,7 +1887,7 @@ i915_gem_flush(struct drm_device *dev,
#endif
BEGIN_LP_RING(2);
OUT_RING(cmd);
- OUT_RING(0); /* noop */
+ OUT_RING(MI_NOOP);
ADVANCE_LP_RING();
}
}
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 26641e9..3933691 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -123,5 +123,5 @@ do {
\
remove_wait_queue((queue), entry);\
} while (0)
-#define DRM_WAKEUP( queue ) wake_up_interruptible( queue )
+#define DRM_WAKEUP( queue ) wake_up( queue )
#define DRM_INIT_WAITQUEUE( queue ) init_waitqueue_head( queue )
--
1.6.3.3
--
Come build
[PATCH 5/8] [drm/i915] fully switch off overlay when not in use
Now that the cache flushing of the memory based overlay regs works, we can safely switch off the overlay. Beforehand it was only disabled (like in userspace). Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_overlay.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index 3f6f3a3..4e88abb 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -323,7 +323,6 @@ static int intel_overlay_off(struct intel_overlay *overlay) } /* turn overlay off */ - /* this is not done in userspace! BEGIN_LP_RING(6); OUT_RING(MI_FLUSH); OUT_RING(MI_NOOP); @@ -338,7 +337,7 @@ static int intel_overlay_off(struct intel_overlay *overlay) DRM_ERROR(intel overlay: ring sync failed, hw likely wedged\n); overlay-hw_wedged = 1; return ret; - }*/ + } overlay-active = 0; -- 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
[Bug 23402] Latest CVS leads to crash in sauerbraten
http://bugs.freedesktop.org/show_bug.cgi?id=23402 --- Comment #18 from David Ronis david.ro...@mcgill.ca 2009-09-15 18:18:25 PST --- I tried setting up KMS as described in the wiki. I'm not sure I was successful, but if so, there's no change with the bug. Couple of things: 1. I didn't activate any of the device specific staging drivers in the kernel (just the overall staging CONFIG_STAGING=y option). 2. XOrg.0.log shows only one reference to KMS: (II) [KMS] drm report modesetting isn't supported. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: reprogram format in set base.
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;
@@ -476,6 +495,16 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x, int
y,
base = ~7;
+ if (radeon_crtc-crtc_id == 1)
+ gen_cntl_reg = RADEON_CRTC2_GEN_CNTL;
+ else
+ gen_cntl_reg = RADEON_CRTC_GEN_CNTL;
+
+ gen_cntl_val = RREG32(gen_cntl_reg);
+ gen_cntl_val = ~(0xf 8);
+ gen_cntl_val |= (format 8);
+ WREG32(gen_cntl_reg, gen_cntl_val);
+
crtc_offset = (u32)base;
WREG32(RADEON_DISPLAY_BASE_ADDR + radeon_crtc-crtc_offset,
radeon_crtc-legacy_display_base_addr);
--
1.6.4.2
--
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
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #11 from Shuang He shuang...@intel.com 2009-09-15 20:34:59 PST --- (In reply to comment #10) (In reply to comment #9) Created an attachment (id=29361) -- (http://bugs.freedesktop.org/attachment.cgi?id=29361) [details] [details] small case This case simply render a rectangle area in stencil buffer with glDrawPixels(GL_STENCIL). then render a red rectangle to validate the result. This case works with software rendering, but not with i965 driver. This should be fixed as of mesa commit 9e6ae75cc8d6bff139aa21bda0aa682755ab7a7c For the other failures I need more information to know what's wrong. I've tested a variety of pixel transfer and pixel store modes with glDrawPixels(GL_DEPTH_COMPONENT) (which I suspect pxstore-depth.c and pxtrans-cidraw.c exercise) but haven't found any issues. Yes, that's fixed. I'm uploading another small case for glDrawPixels(GL_DEPTH_COMPONENT) case -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #12 from Shuang He shuang...@intel.com 2009-09-15 20:37:59 PST --- Created an attachment (id=29580) -- (http://bugs.freedesktop.org/attachment.cgi?id=29580) another small case This case simply render two points through glDrawPixels(GL_DEPTH_COMPONENT), with ALPHA test enabled, and set to GL_ALWAYS. but it turn out the leftmost point is missed when rendering. This works well if only the leftmost point is rendered, or using software rendering -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
