Bug 18154 - DRM support for addressing >32 bits on 32 bit cores
Summary: DRM support for addressing >32 bits on 32 bit cores
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/other (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: high major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-21 07:03 UTC by Steve Winiecki
Modified: 2014-08-07 06:13 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
libdrm support for addressing >32 bits on 32 bit cores - syslog w/ drm debug msgs (27.25 KB, text/plain)
2008-10-21 07:03 UTC, Steve Winiecki
no flags Details
Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses (1.29 KB, patch)
2014-08-06 09:59 UTC, Andrej Krutak
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Winiecki 2008-10-21 07:03:50 UTC
Created attachment 19785 [details]
libdrm support for addressing >32 bits on 32 bit cores - syslog w/ drm debug msgs

Using git versions Xorg/Mesa/DRM built last week

Using a PPC 32-bit platform, with a 32 bit core and 36-bit addressing (460EX). The PCIe space is mapped physically above a 32 bit address range.  Have a radeon 1650 adapter plugged in the PCIe slot.

When enabling DRI - get the following Oops error:

------------------------
[drm:radeon_driver_open]
[drm:drm_addmap_core] offset = 0x98000000, size = 0x00010000, type = 1
[drm:drm_addmap_core] offset = 0x80000000, size = 0x10000000, type = 0
[drm:drm_addmap_core] offset = 0x00000000, size = 0x00002000, type = 2
[drm:drm_setup]
[drm:drm_ioctl] pid=2058, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1
[drm:drm_ioctl] pid=2058, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1
[drm:drm_release] open_count = 1
[drm:drm_release] pid = 2058, device = 0xe200, open_count = 1
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_lastclose]
Machine check in kernel mode.
Data Write PLB Error
Oops: Machine check, sig: 7 [#2]
Canyonlands
Modules linked in:
NIP: 00000000 LR: c01796ec CTR: 00000008
REGS: c039bf50 TRAP: 0202   Tainted: G      D   (2.6.25.7-00002-geaaf8db)
MSR: 00000000 <>  CR: 24000428  XER: 00000002
TASK = ded4d3f0[2058] 'X' THREAD: ded86000
GPR00: e93e0b0c ded87e60 ded4d3f0 dfaa7400 000040c1 ffffffff c018c924 00004000
GPR08: 00000000 e93e0b0c 00000000 e93e0000 24000422 101e6c34 101dec74 101def08
GPR16: 101e0000 101e0000 101e0000 101e0000 101e0000 101e0000 00000004 101e0000
GPR24: c03a0000 dfaa7618 dfaa760c dedb5a80 deddc580 dfaa7400 dfaa7400 dfaa7800
NIP [00000000] 0x0
LR [c01796ec] radeon_driver_lastclose+0x40/0x74
Call Trace:
[ded87e60] [c001eacc] printk+0x50/0x60 (unreliable)
[ded87e80] [c01796ec] radeon_driver_lastclose+0x40/0x74
[ded87e90] [c0169b2c] drm_lastclose+0x40/0x340
[ded87ec0] [c016af14] drm_release+0x438/0x498
[ded87ef0] [c007762c] __fput+0xb4/0x19c
[ded87f10] [c00740ac] filp_close+0x68/0xb0
[ded87f30] [c0074184] sys_close+0x90/0xb4
[ded87f40] [c000ccf0] ret_from_syscall+0x0/0x3c
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace a2cb362184c9762b ]---
------------------------------------

Note that the physical mapping for the card has the MMIO and FB at addresses above 32 bits:

------------------------------
0000:81:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 7291 (prog-if 00 [VGA])
        Subsystem: Connect Components Ltd Unknown device 7291
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at e80000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at e98000000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at <unassigned>
        Expansion ROM at e90000000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <4us, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <64ns, L1 <1us
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed 2.5Gb/s, Width x4
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
---------------------------

It appears that within libdrm, the mapping does not support addressing above 32-bts on 32 bit cores, and the addresses are getting truncated.  Note the offsets from the drm debug messages:

---------------------------
[drm:drm_addmap_core] offset = 0x98000000, size = 0x00010000, type = 1
[drm:drm_addmap_core] offset = 0x80000000, size = 0x10000000, type = 0
[drm:drm_addmap_core] offset = 0x00000000, size = 0x00002000, type = 2
----------------------------

Within the mapping function the address/offset is defined as a long wich cannot hold the full physical address:

struct drm_map {
        unsigned long offset;    /**< Requested physical address (0 for SAREA)*/
        unsigned long size;      /**< Requested physical size (bytes) */
        enum drm_map_type type;  /**< Type of memory to map */
        enum drm_map_flags flags;        /**< Flags */
        void *handle;            /**< User-space: "Handle" to pass to mmap() */
                                 /**< Kernel-space: kernel-virtual address */
        int mtrr;                /**< MTRR slot used */
        /*   Private data */
};

I am assuming this is contributing to the error.  Not sure if there are other places this is an issue.  

Last part of Xorg.0.log:
--------------------------------
(II) Primary Device is: PCI 81@00:00:0
(II) resource ranges after xf86ClaimFixedResources() call:
(II) resource ranges after probing:
(II) RADEON(0): TOTO SAYS 0000000e98000000
(II) RADEON(0): MMIO registers at 0x0000000e98000000: size 64KB
(II) RADEON(0): PCI bus 129 card 0 func 0
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(II) RADEON(0): VGAAccess option set to FALSE, VGA module load skipped
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(--) RADEON(0): Chipset: "ATI Radeon X1650" (ChipID = 0x7291)
(WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org
(--) RADEON(0): Linear framebuffer at 0x0000000e80000000
(II) RADEON(0): PCIE card detected
(II) RADEON(0): ATOM BIOS detected
(II) RADEON(0): ATOM BIOS Rom: 
	SubsystemVendorID: 0x17ee SubsystemID: 0x7291
	IOBaseAddress: 0x0000
	Filename: S3A88003.102
	BIOS Bootup Message: 
113-A88003-102 RV560XT BIOS 574e/675m                                       

(II) RADEON(0): Framebuffer space used by Firmware (kb): 0
(WW) RADEON(0): rhdAtomGetFbBaseAndSize: AtomBIOS specified VRAM scratch space size invalid
(II) RADEON(0):  default to: 20480
(II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead
(II) RADEON(0): Default Engine Clock: 574000
(II) RADEON(0): Default Memory Clock: 675000
(II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000
(II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0
(II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500
(II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000
(II) RADEON(0): Maximum Pixel Clock: 400000
(II) RADEON(0): Reference Clock: 27000
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
---------------------------------

Syslog w/ drm debug messages attached.
Comment 1 Andrej Krutak 2014-08-06 09:56:15 UTC
This is a problem in the drm/ttm code, not libdri.
Comment 2 Andrej Krutak 2014-08-06 09:58:01 UTC
I'm attaching a patch that resolves this problem at least with p3041 board + radeon card, where I saw similar problem (the mmio base being truncated). The issue was too small type of ttm_bus_placement.base. Also, the debug prints at the beginning only print 32 bits of the values (even if they are 64 bit).
Comment 3 Andrej Krutak 2014-08-06 09:59:27 UTC
Created attachment 104143 [details] [review]
Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses
Comment 4 Michel Dänzer 2014-08-07 06:13:55 UTC
(In reply to comment #3)
> Created attachment 104143 [details] [review] [review]
> Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses

You should probably split up the TTM and radeon changes into separate patches. Then, please submit them to the dri-devel mailing list directly.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.