[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #16 from madbiologist 2010-07-06 20:32:30 PDT --- This patch has been included in kernel 2.6.35-rc4. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Report for 2.6.35-rc3-00262-g984bc96
On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius wrote: > Good morning! > > A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with > the Lenovo X201: So you see two post-2.6.34 regressions? > == xrandr == > > After using xrandr several times in xorg, the screen gets > "fancy": blue/white/black changing patterns. > Getting even more weired when changing to a conosle. > > The only thing that keeps on working is the mouse cursor > in xorg. This did not happen with 2.6.34-rcsomething, neither > with 2.6.33 iirc. > > This is a Intel Corporation Core Processor Integrated Graphics Controller > (rev 02), > attached xorg.log. (cc dri-devel) > == netlink/carrier messag == > > dhcpcd does not get updated when the link is established, > need to restart it. (cc netdev) > == suspend/resume (to ram) == > > So far no real crash! Only xorg is sometimes not coming up > again, but this may be related to the first issue. > > == wifi / intel 6000 == > > Works! Works! (Besides the netlink issue, which is annoying, > but for all devices).
No subject
a) Both r300c and r300g have difficulty with compressed textures, and b) r300g also has a more serious problem with b8g8r8a8_unorm, b4g4r4a4_unorm, b5g6r5_unorm textures (and possibly others), because these are what WoW uses when compressed texture support isn't available. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #4 from Chris Rankin 2010-07-06 14:40:14 PDT --- (In reply to comment #3) > Can you obtain a backtrace of the crash? The crash seems to happen within WoW itself, which suggests to me that WoW *needs* S3TC textures to run correctly. I get the exact same crash when I remove libtxc_dxtn.so from r300c too. r300: texture_create: Macro: NO, Micro: NO, Pitch: 128, Dim: 128x8x0, LastLevel: 0, Size: 4096, Format: b8g8r8a8_unorm r300: texture_create: Macro: NO, Micro: NO, Pitch: 8, Dim: 8x64x0, LastLevel: 0, Size: 2048, Format: b8g8r8a8_unorm wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP: ESP:0196fd04 EBP:0196fd64 EFLAGS:00210246( R- -- I Z- -P- ) EAX:83f1 EBX:8000 ECX:0de1 EDX:0cf0ece0 ESI: EDI:0c37c558 Stack dump: 0x0196fd04: 0069de43 0de1 83f1 0x0196fd14: 0100 0100 8000 0x0196fd24: 0cf0ece0 0100 0c37c558 0100 0x0196fd34: 0100 0100 0x0196fd44: 813d 0008 0200 0x0196fd54: 0cf16ce0 8000 0cf0ece0 83f1 Backtrace: =>0 0x (0x0196fd64) 1 0x0069e078 in wow (+0x29e077) (0x0196fdbc) Ouch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #3 from Marek Ol??k 2010-07-06 14:33:08 PDT --- Can you obtain a backtrace of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #2 from Chris Rankin 2010-07-06 12:33:59 PDT --- I tried running WoW with the RADEON_DEBUG="tex" option, and noticed that many textures were in formats: dxt1_rgba dxt3_rgba dxt5_rgba And so because I am also using libtxc_dxtn070518.tar.gz, I moved the libtxc_dxtn.so object out of /usr/lib and tried running WoW again. And this time, the textures were all fine... right up until WoW crashed a few seconds later.
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 --- Comment #3 from Alex Deucher 2010-07-06 07:15:54 PDT --- Does mesa from git master work any better? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 --- Comment #2 from Darin McBride 2010-07-06 07:02:10 PDT --- mesa 7.8.2, xorg-server 1.8.1.902 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 Alex Deucher changed: What|Removed |Added Version|git |unspecified -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Component|Driver/Radeon |Drivers/DRI/R600 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | --- Comment #1 from Alex Deucher 2010-07-06 06:58:53 PDT --- What version of mesa are you using? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28928] New: [ati-dri] R100 OpenGL Crash buffer overflow
https://bugs.freedesktop.org/show_bug.cgi?id=28928 Summary: [ati-dri] R100 OpenGL Crash buffer overflow Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: redtux2k9 at gmail.com DRI is working with direct rendering and hardware acceleration, but only working OpenGL application is glxgears and small example written by me using gtkglext. When I try to run yabause or any application that uses OpenGL then I've got this: *WARN_ONCE* File radeon_swtcl.c function r100_swtcl_flush line 322 Rendering was 13 commands larger than predicted size. We might overflow command buffer. *** drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. And then crash. When I write dmesg I got this: [drm:r100_cs_track_texture_check] *ERROR* No texture bound to unit 0 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! I'm using module radeon under ATI Radeon M6 (R100) and packages version under Archlinux i686: ati-dri 7.8.2-1 xf86-video-ati 6.13.0-1 mesa 7.8.2-1 libgl 7.8.2-1 The DRI module is from 20090101, but was working ok with version from 20061018, so with Mesa 7.2 (2008). I've tried to compile Mesa 7.2, but the DRI was not working (only swrast). Please help me, I can't even watch youtube with proper speed. Only alternative for me is Debian Lenny that has everything (DRI) working ok, because it has the old version. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
EXA - when does it's implementation depend on DRM?
2010/7/4 Dave Airlie : > 2010/7/5 Rafa? Mi?ecki : >> W dniu 4 lipca 2010 22:24 u?ytkownik Dave Airlie >> napisa?: >>> 2010/7/5 Rafa? Mi?ecki : AFAIU EXA is collection of operations (Solid, Copy, UploadToScreen, DownloadFromScreen) that touch VRAM. So we can tell hardware to move xterm window 100px right (Copy) and fill freed place with blue (Solid). Is that right? So my question is: when implementing EXA (in DDX) needs DRM and when it does not? I know in case of R6xx-R7xx we had to get DRM first to receive EXA. AFAIK it wasn't the case with R1xx-R5xx. On the other hand some VIA's driver needs DRM for EXA on Chrome9, while openChrome claims to support EXA without DRM[1]. Could someone explain this to me, please? [1] http://phoronix.com/forums/showthread.php?p=89776 >>> >>> Nothing to do with EXA, its up to the driver underneath. >> >> That's why I mentioned "implementation" in subject, not EXA itself :) >> >> >>> If the driver can accel the operations without the drm, it doesn't >>> need the drm, it the driver requires the drm to accel operations then >>> it needs the drm >> >> Any tip why acceleration operations are available on some hardware >> only with DRM, and sometimes not? Is this related to the way how we >> send commands to GPU? AFAIK every command submission implementation >> needs DRM... but somehow in case of r1xx-r5xx it is not true. > > You can program some GPUs via MMIO, its slower and you can't DMA > to/from main memory at all, it just works in an offscreen memory area. > > Its generally pointless maintaining these codepaths since nobody tests > them, and for chips like r600 I don't think MMIO is sufficient to > program accel engines. You can't program the r6xx+ 3D engines via MMIO directly. > > Not so sure on r500 its sufficient either since some regs can't be > programmed via MMIO properly, but we have the codepaths since they are > so similiar to r100. Only copy and solid are available via mmio on r5xx since the WAIT_UNTIL register and a few others are not accessible via MMIO. In theory even the 2D engine could be problematic without those regs, but it's generally fairly well behaved. Alex
Fair eviction for i915, based on Daniel's drm_mm scanner
On Fri, 2 Jul 2010 15:02:10 +0100, Chris Wilson wrote: > This is a resend of Daniel Vetter's drm mm work to provide a basis for > performing fair eviction in i915. I've taken the liberty of attaching the > acks and review comments from the previous round, so please look over and > check that they still hold true. This is in Dave's hands now to review the core bits -- I like the i915 bits. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100706/d88753a0/attachment.pgp>
[patch] i915: cleanup: use ARRAY_SIZE()
On Wed, 23 Jun 2010 19:29:54 +0200, Dan Carpenter wrote: > NUM_TV_MODES is the same as ARRAY_SIZE(tv_modes). In the end, I > decided it was cleaner to remove NUM_TV_MODES and just use > ARRAY_SIZE(tv_modes) through out. > > Signed-off-by: Dan Carpenter Applied. Thanks! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100706/1cb10cb8/attachment-0001.pgp>
Re: [patch] i915: cleanup: use ARRAY_SIZE()
On Wed, 23 Jun 2010 19:29:54 +0200, Dan Carpenter erro...@gmail.com wrote: NUM_TV_MODES is the same as ARRAY_SIZE(tv_modes). In the end, I decided it was cleaner to remove NUM_TV_MODES and just use ARRAY_SIZE(tv_modes) through out. Signed-off-by: Dan Carpenter erro...@gmail.com Applied. Thanks! pgpxRo4IzRAqg.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fair eviction for i915, based on Daniel's drm_mm scanner
On Fri, 2 Jul 2010 15:02:10 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: This is a resend of Daniel Vetter's drm mm work to provide a basis for performing fair eviction in i915. I've taken the liberty of attaching the acks and review comments from the previous round, so please look over and check that they still hold true. This is in Dave's hands now to review the core bits -- I like the i915 bits. pgp2v6yuYlxKO.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Version|git |unspecified -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=28932 --- Comment #2 from Darin McBride tankta...@gmail.com 2010-07-06 07:02:10 PDT --- mesa 7.8.2, xorg-server 1.8.1.902 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #3 from Marek Olšák mar...@gmail.com 2010-07-06 14:33:08 PDT --- Can you obtain a backtrace of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #4 from Chris Rankin ranki...@googlemail.com 2010-07-06 14:40:14 PDT --- (In reply to comment #3) Can you obtain a backtrace of the crash? The crash seems to happen within WoW itself, which suggests to me that WoW *needs* S3TC textures to run correctly. I get the exact same crash when I remove libtxc_dxtn.so from r300c too. r300: texture_create: Macro: NO, Micro: NO, Pitch: 128, Dim: 128x8x0, LastLevel: 0, Size: 4096, Format: b8g8r8a8_unorm r300: texture_create: Macro: NO, Micro: NO, Pitch: 8, Dim: 8x64x0, LastLevel: 0, Size: 2048, Format: b8g8r8a8_unorm wine: Unhandled page fault on read access to 0x at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP: ESP:0196fd04 EBP:0196fd64 EFLAGS:00210246( R- -- I Z- -P- ) EAX:83f1 EBX:8000 ECX:0de1 EDX:0cf0ece0 ESI: EDI:0c37c558 Stack dump: 0x0196fd04: 0069de43 0de1 83f1 0x0196fd14: 0100 0100 8000 0x0196fd24: 0cf0ece0 0100 0c37c558 0100 0x0196fd34: 0100 0100 0x0196fd44: 813d 0008 0200 0x0196fd54: 0cf16ce0 8000 0cf0ece0 83f1 Backtrace: =0 0x (0x0196fd64) 1 0x0069e078 in wow (+0x29e077) (0x0196fdbc) Ouch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Report for 2.6.35-rc3-00262-g984bc96
On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius nico-linux-2010-07...@schottelius.org wrote: Good morning! A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with the Lenovo X201: So you see two post-2.6.34 regressions? == xrandr == After using xrandr several times in xorg, the screen gets fancy: blue/white/black changing patterns. Getting even more weired when changing to a conosle. The only thing that keeps on working is the mouse cursor in xorg. This did not happen with 2.6.34-rcsomething, neither with 2.6.33 iirc. This is a Intel Corporation Core Processor Integrated Graphics Controller (rev 02), attached xorg.log. (cc dri-devel) == netlink/carrier messag == dhcpcd does not get updated when the link is established, need to restart it. (cc netdev) == suspend/resume (to ram) == So far no real crash! Only xorg is sometimes not coming up again, but this may be related to the first issue. == wifi / intel 6000 == Works! Works! (Besides the netlink issue, which is annoying, but for all devices). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: add vblank event trace point
On Fri, Jul 2, 2010 at 9:47 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: Emit a trace point for vblank events. This can be helpful for mapping drawing activity against the vblank frequency and period. Pushed these 3 out to drm-core-next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #16 from madbiologist s.j.tur...@uq.net.au 2010-07-06 20:32:30 PDT --- This patch has been included in kernel 2.6.35-rc4. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
Ignore this one, picked up a problem in the ioports patch, so its gone. new pull req sent. Dave. The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82: Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 09:52:58 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (2): drm/radeon/kms: add ioport register access drm/radeon/kms: fix shared ddc handling Francisco Jerez (1): drm/ttm: Allocate the page pool manager in the heap. Jesse Barnes (1): drm: correctly update connector DPMS status in drm_fb_helper drivers/gpu/drm/drm_fb_helper.c| 23 - drivers/gpu/drm/radeon/atom.c |5 +- drivers/gpu/drm/radeon/atom.h |2 + drivers/gpu/drm/radeon/radeon.h| 25 ++ drivers/gpu/drm/radeon/radeon_connectors.c |4 +- drivers/gpu/drm/radeon/radeon_device.c | 34 ++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 68 +-- include/drm/ttm/ttm_page_alloc.h |4 -- 8 files changed, 119 insertions(+), 46 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm v2 fixes
Okay I dropped the ioports patch from the last pull, it broke a few systems unexpectedly, so no more of that, just 3 simple fixes now. Dave. The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82: Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 09:52:58 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (1): drm/radeon/kms: fix shared ddc handling Francisco Jerez (1): drm/ttm: Allocate the page pool manager in the heap. Jesse Barnes (1): drm: correctly update connector DPMS status in drm_fb_helper drivers/gpu/drm/drm_fb_helper.c| 23 - drivers/gpu/drm/radeon/radeon_connectors.c |4 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 68 +-- include/drm/ttm/ttm_page_alloc.h |4 -- 4 files changed, 56 insertions(+), 43 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add ioport register access
int radeon_atombios_init(struct radeon_device *rdev) { struct card_info *atom_card_info = @@ -427,6 +443,9 @@ int radeon_atombios_init(struct radeon_device *rdev) atom_card_info-dev = rdev-ddev; atom_card_info-reg_read = cail_reg_read; atom_card_info-reg_write = cail_reg_write; + /* needed for iio ops */ + atom_card_info-ioreg_read = cail_ioreg_read; + atom_card_info-ioreg_write = cail_ioreg_write; atom_card_info-mc_read = cail_mc_read; atom_card_info-mc_write = cail_mc_write; atom_card_info-pll_read = cail_pll_read; @@ -659,6 +678,19 @@ int radeon_device_init(struct radeon_device *rdev, DRM_INFO(register mmio base: 0x%08X\n, (uint32_t)rdev-rmmio_base); DRM_INFO(register mmio size: %u\n, (unsigned)rdev-rmmio_size); + /* io port mapping */ + if (rdev-family = CHIP_RV770) { + rdev-rio_mem_size = pci_resource_len(rdev-pdev, 4); + rdev-rio_mem = pci_iomap(rdev-pdev, 4, rdev-rio_mem_size); + } else { + rdev-rio_mem_size = pci_resource_len(rdev-pdev, 1); + rdev-rio_mem = pci_iomap(rdev-pdev, 1, rdev-rio_mem_size); + } + if (rdev-rio_mem == NULL) { + iounmap(rdev-rmmio); + return -EIO; + } + This is all bad, my main r600 stopped working after this, from my quick boot test r100-r300 are all port 1, discrete r480 and upwards (not sure about rv410) is port 4, IGP, rs480 is port 1, rs690 is port 4, rs780 is port 1. We need to either guarantee these work or fallback gracefully instead of failing to load the driver. Dave. /* if we have 1 VGA cards, then disable the radeon VGA resources */ /* this will fail for cards that aren't VGA class devices, just * ignore it */ @@ -701,6 +733,8 @@ void radeon_device_fini(struct radeon_device *rdev) destroy_workqueue(rdev-wq); vga_switcheroo_unregister_client(rdev-pdev); vga_client_register(rdev-pdev, NULL, NULL, NULL); + pci_iounmap(rdev-pdev, rdev-rio_mem); + rdev-rio_mem = NULL; iounmap(rdev-rmmio); rdev-rmmio = NULL; } -- 1.7.0.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add ioport register access
On Wed, Jul 7, 2010 at 12:29 AM, Dave Airlie airl...@gmail.com wrote: int radeon_atombios_init(struct radeon_device *rdev) { struct card_info *atom_card_info = @@ -427,6 +443,9 @@ int radeon_atombios_init(struct radeon_device *rdev) atom_card_info-dev = rdev-ddev; atom_card_info-reg_read = cail_reg_read; atom_card_info-reg_write = cail_reg_write; + /* needed for iio ops */ + atom_card_info-ioreg_read = cail_ioreg_read; + atom_card_info-ioreg_write = cail_ioreg_write; atom_card_info-mc_read = cail_mc_read; atom_card_info-mc_write = cail_mc_write; atom_card_info-pll_read = cail_pll_read; @@ -659,6 +678,19 @@ int radeon_device_init(struct radeon_device *rdev, DRM_INFO(register mmio base: 0x%08X\n, (uint32_t)rdev-rmmio_base); DRM_INFO(register mmio size: %u\n, (unsigned)rdev-rmmio_size); + /* io port mapping */ + if (rdev-family = CHIP_RV770) { + rdev-rio_mem_size = pci_resource_len(rdev-pdev, 4); + rdev-rio_mem = pci_iomap(rdev-pdev, 4, rdev-rio_mem_size); + } else { + rdev-rio_mem_size = pci_resource_len(rdev-pdev, 1); + rdev-rio_mem = pci_iomap(rdev-pdev, 1, rdev-rio_mem_size); + } + if (rdev-rio_mem == NULL) { + iounmap(rdev-rmmio); + return -EIO; + } + This is all bad, my main r600 stopped working after this, from my quick boot test r100-r300 are all port 1, discrete r480 and upwards (not sure about rv410) is port 4, IGP, rs480 is port 1, rs690 is port 4, rs780 is port 1. We need to either guarantee these work or fallback gracefully instead of failing to load the driver. The attached patch should handle it gracefully. Alex Dave. /* if we have 1 VGA cards, then disable the radeon VGA resources */ /* this will fail for cards that aren't VGA class devices, just * ignore it */ @@ -701,6 +733,8 @@ void radeon_device_fini(struct radeon_device *rdev) destroy_workqueue(rdev-wq); vga_switcheroo_unregister_client(rdev-pdev); vga_client_register(rdev-pdev, NULL, NULL, NULL); + pci_iounmap(rdev-pdev, rdev-rio_mem); + rdev-rio_mem = NULL; iounmap(rdev-rmmio); rdev-rmmio = NULL; } -- 1.7.0.1 From aa44b434805ef7d04198302a76fea20844702d37 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Wed, 7 Jul 2010 01:54:57 -0400 Subject: [PATCH] drm/radeon/kms: ioport fixes Walk the pci resources and make sure to use the I/O resource. Unfortunately, the pci I/O resource number varies between asic families. If we don't find an I/O resource fall back the the previous behavior of using MMIO for ATOM IIO. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/radeon_device.c | 30 +- 1 files changed, 17 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index fa85a34..d3e86f4 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -444,8 +444,14 @@ int radeon_atombios_init(struct radeon_device *rdev) atom_card_info-reg_read = cail_reg_read; atom_card_info-reg_write = cail_reg_write; /* needed for iio ops */ - atom_card_info-ioreg_read = cail_ioreg_read; - atom_card_info-ioreg_write = cail_ioreg_write; + if (rdev-rio_mem) { + atom_card_info-ioreg_read = cail_ioreg_read; + atom_card_info-ioreg_write = cail_ioreg_write; + } else { + DRM_ERROR(Unable to find PCI I/O BAR; using MMIO for ATOM IIO\n); + atom_card_info-ioreg_read = cail_reg_read; + atom_card_info-ioreg_write = cail_reg_write; + } atom_card_info-mc_read = cail_mc_read; atom_card_info-mc_write = cail_mc_write; atom_card_info-pll_read = cail_pll_read; @@ -592,7 +598,7 @@ int radeon_device_init(struct radeon_device *rdev, struct pci_dev *pdev, uint32_t flags) { - int r; + int r, i; int dma_bits; rdev-shutdown = false; @@ -679,17 +685,15 @@ int radeon_device_init(struct radeon_device *rdev, DRM_INFO(register mmio size: %u\n, (unsigned)rdev-rmmio_size); /* io port mapping */ - if (rdev-family = CHIP_RV770) { - rdev-rio_mem_size = pci_resource_len(rdev-pdev, 4); - rdev-rio_mem = pci_iomap(rdev-pdev, 4, rdev-rio_mem_size); - } else { - rdev-rio_mem_size = pci_resource_len(rdev-pdev, 1); - rdev-rio_mem = pci_iomap(rdev-pdev, 1, rdev-rio_mem_size); - } - if (rdev-rio_mem == NULL) { - iounmap(rdev-rmmio); - return -EIO; + for (i = 0; i DEVICE_COUNT_RESOURCE; i++) { + if (pci_resource_flags(rdev-pdev, i) IORESOURCE_IO) { + rdev-rio_mem_size = pci_resource_len(rdev-pdev, i); + rdev-rio_mem = pci_iomap(rdev-pdev, i, rdev-rio_mem_size); + break; + } } + if (rdev-rio_mem == NULL) + DRM_ERROR(Unable to find PCI I/O BAR\n); /* if we have 1 VGA cards, then disable the radeon VGA resources */ /* this