| Message ID | F9C1BAB5-56D3-40E2-B0B2-184C92CD51AB@p0n4ik.tk (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
I meant 0x07dc07e0 not 0x07dc0x07e0 for sure... 04.09.2013, 22:34, "Alex Ivanov" <gnidorah@p0n4ik.tk>: > 02.09.2013, ? 18:10, John David Anglin <dave.anglin@bell.net> ???????(?): > >> You don't think it ran briefly and crashed? >> >> I have a thought. The code that loads the microcode appears to be trying to load in 32-bit hunks. Maybe >> we have a 64-bit path on the bus and we need to load the firmware in 64-bit words. >> >> Dave >> -- >> John David Anglin dave.anglin@bell.net > > Dave, > > Am i understood you right? > > --- r100.c.orig 2013-09-04 16:53:28.000000000 +0000 > +++ r100.c 2013-09-04 18:28:23.000000000 +0000 > @@ -1049,9 +1049,13 @@ static int r100_cp_init_microcode(struct > return err; > } > > +#define RADEON_CP_ME_RAM_DATAHL 0x07dc0x07e0 > + > +void r100_mm_wregq(struct radeon_device *rdev, uint64_t reg, uint64_t v, > + bool always_indirect); > static void r100_cp_load_microcode(struct radeon_device *rdev) > { > - const __be32 *fw_data; > + const __be64 *fw_data; > int i, size; > > if (r100_gui_wait_for_idle(rdev)) { > @@ -1060,14 +1064,12 @@ static void r100_cp_load_microcode(struc > } > > if (rdev->me_fw) { > - size = rdev->me_fw->size / 4; > - fw_data = (const __be32 *)&rdev->me_fw->data[0]; > + size = rdev->me_fw->size / 8; > + fw_data = (const __be64 *)&rdev->me_fw->data[0]; > WREG32(RADEON_CP_ME_RAM_ADDR, 0); > - for (i = 0; i < size; i += 2) { > - WREG32(RADEON_CP_ME_RAM_DATAH, > - be32_to_cpup(&fw_data[i])); > - WREG32(RADEON_CP_ME_RAM_DATAL, > - be32_to_cpup(&fw_data[i + 1])); > + for (i = 0; i < size; i += 1) { > + r100_mm_wregq(rdev, RADEON_CP_ME_RAM_DATAHL, > + be64_to_cpup(&fw_data[i]), false); > } > } > } > @@ -4078,6 +4080,21 @@ void r100_mm_wreg(struct radeon_device * > } > } > > +void r100_mm_wregq(struct radeon_device *rdev, uint64_t reg, uint64_t v, > + bool always_indirect) > +{ > + if (reg < rdev->rmmio_size && !always_indirect) > + writeq(v, ((void __iomem *)rdev->rmmio) + reg); > + else { > + unsigned long flags; > + > + spin_lock_irqsave(&rdev->mmio_idx_lock, flags); > + writeq(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); > + writeq(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA); > + spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags); > + } > +} > + > u32 r100_io_rreg(struct radeon_device *rdev, u32 reg) > { > if (reg < rdev->rio_mem_size) > > I'm not sure if this correct, but it didn't help.-- > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Should have just given link: http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ It is listed near bottom as "R5xx Family 3D Programming Guide". On 4-Sep-13, at 3:53 PM, John David Anglin wrote: > Alex, > > That was the general idea although I was looking at the code in > radeon_cp.c. I now think my suggestion > was incorrect as the CP data is loaded via registers. > > After a bit of searching, I found a document which describes reading > and writing to MicroEngine RAM. > See page 22. I think we need to confirm after writing that we can > read back the control program > successfully. Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
04.09.2013, 23:54, "John David Anglin" <dave.anglin@bell.net>: > Alex, > > That was the general idea although I was looking at the code in > radeon_cp.c. I now think my suggestion > was incorrect as the CP data is loaded via registers. > > After a bit of searching, I found a document which describes reading and > writing to MicroEngine RAM. > See page 22. I think we need to confirm after writing that we can read > back the control program > successfully. > > Dave I disregarded this too, though WREG32 macro name evidently says that it does writing to registers. I'm touching the r100.c, as they've opted out a radeon_cp.c one. Good find! I though that it would be worth to check the load somehow, as well. I've added the following piece after the load: WREG32(RADEON_CP_ME_RAM_RADDR, 0); for (i = 0; i < size; i += 2) if (RREG32(RADEON_CP_ME_RAM_DATAH) != be32_to_cpup(&fw_data[i]) || RREG32(RADEON_CP_ME_RAM_DATAL) != be32_to_cpup(&fw_data[i+1])) { printk(KERN_WARNING "RADEON_CP_ME_RAM_DATAH " "MISMATCH!\n"); break; } I've recompiled with this and booted to the new kernel, but seeing no warning, so it looks like it passes. What's strange though is why they write zero instead of concrete memory address to the CP_ME_RAM_ADDR register... -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/05/2013 01:58 AM, John David Anglin wrote: > Should have just given link: > http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ > It is listed near bottom as "R5xx Family 3D Programming Guide". I found this "older" one: http://www.x.org/docs/AMD/R5xx_Acceleration_v1.1.pdf Maybe section 4.5 (Chips et Coherency Issues) is relevant too: ? The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an update to its copy of the Write Pointer. In an effort to alleviate this problem, we?ve introduced a mechanism into the Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in order to give the chipset time to flush its internal write buffers to memory. There are two register fields that control this mechanism: PRE_WRITE_TIMER and PRE_WRITE_LIMIT.[...] In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?... Just a thought. Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
05.09.2013, ? 16:49, John David Anglin <dave.anglin@bell.net> ???????(?): > On 5-Sep-13, at 5:23 AM, Alex Ivanov wrote: > > >> Good find! I though that it would be worth to check the load somehow, >> as well. I've added the following piece after the load: >> >> WREG32(RADEON_CP_ME_RAM_RADDR, 0); >> for (i = 0; i < size; i += 2) >> if (RREG32(RADEON_CP_ME_RAM_DATAH) >> != be32_to_cpup(&fw_data[i]) || >> RREG32(RADEON_CP_ME_RAM_DATAL) >> != be32_to_cpup(&fw_data[i+1])) { >> printk(KERN_WARNING "RADEON_CP_ME_RAM_DATAH " >> "MISMATCH!\n"); >> break; >> } >> >> I've recompiled with this and booted to the new kernel, but seeing no warning, >> so it looks like it passes. > > Could you add a line of code just to be sure the check is executed? > > From the boot log, it looks like register accesses generally seem to work, so it's > starting to look like the card doesn't like the firmware. Looks like. > > About all that I can see in the above that might be a problem is be32_to_cpup. > Maybe you could just print in hex what you read back? The R100 file is quite > small. > >> >> What's strange though is why they write zero instead of concrete memory address >> to the CP_ME_RAM_ADDR register... > > Do you think the initial value should be different? The documentation states the register > is auto incremented on reads and writes. My bad. I didn't take the written in manual correctly during first reading. > > Dave > -- > John David Anglin dave.anglin@bell.net I've added hex printing in a check and at brief view the output seems to match cp firmware. In my case, it's a r420_cp.bin -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/5/2013 5:15 PM, Alex Ivanov wrote: > I've added hex printing in a check and at brief view the output seems to match cp firmware. > In my case, it's a r420_cp.bin OK, so the problem is probably not in the firmware load. Maybe it's the chipset coherency issue mentioned by Helge. This may break ring test, etc. Dave
On Thu, Sep 05, 2013 at 10:58:25PM +0200, Helge Deller wrote: > Maybe section 4.5 (Chips et Coherency Issues) is relevant too: ? > The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee but radeon is not r128, iirc. My current state is: - parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds - our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA I've hacked around both problems, but it doesn't solve the ring test issue. I even bought an PCI Radeon card to rule out any AGP oddities, but nothing new came out of the experiments with the PCI card. I've started checking drivers/video/aty to see what it does with acceleration and compare that with radeon DRM. The aty driver uses an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture. What I'm still wondering is whether radeon DRM really works on 64bit big endian boxes. Is there any prove, that someone has it running ? Is it running on any big endian boxes ? Thomas.
06.09.2013, ? 12:52, Thomas Bogendoerfer <tsbogend@alpha.franken.de> ???????(?): > On Thu, Sep 05, 2013 at 10:58:25PM +0200, Helge Deller wrote: >> Maybe section 4.5 (Chips et Coherency Issues) is relevant too: ? >> The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee > > but radeon is not r128, iirc. There is a discussion on coherency issues with radeon on powerpc platform in linuxppc-embedded mail list. See e.g. here: http://en.it-usenet.org/thread/19030/8457/ I actually tried sync suggestions from there, but they didn't help. > > My current state is: > > - parisc AGP GART code writes IOMMU entries in the wrong byte order and > doesn't add the coherency information SBA code adds I've played with SBA IOMMU code once too. I've added an IOMMU bypass like it done in counterpart ia64 driver, though it didn't help with DRM, plus it broke Fusion MPT SCSI driver, and then i've seen why: /* We are just "encouraging" 32-bit DMA masks here since we can * never allow IOMMU bypass unless we add special support for ZX1. */ In addition, it has nothing to do in AGP mode which is DMA32 limited. > > - our PCI BAR setup doesn't really work very well together with the Radeon > DRM address setup. > DRM will generate addresses, which are even outside > of the connected LBA Aren't they fixing this sort of problems, like here: https://lkml.org/lkml/2010/12/6/516 ? > > I've hacked around both problems, but it doesn't solve the ring test > issue. I even bought an PCI Radeon card to rule out any AGP oddities, > but nothing new came out of the experiments with the PCI card. > > I've started checking drivers/video/aty to see what it does with > acceleration and compare that with radeon DRM. The aty driver uses > an endian config bit DRM doesn't use, but I haven't tested whether > this makes a difference and how it is connected to the overall picture. > > What I'm still wondering is whether radeon DRM really works on 64bit > big endian boxes. Is there any prove, that someone has it running ? > Is it running on any big endian boxes ? I've seen some patches were made for KMS in order to fix support for big-endian machines, however all of them seem to be done for relatively new chips, like r600. All big endian support in r100.c looks like just one buffer swap, AFAIR. > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ] -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2013-09-06 at 10:52 +0200, Thomas Bogendoerfer wrote: > On Thu, Sep 05, 2013 at 10:58:25PM +0200, Helge Deller wrote: > > Maybe section 4.5 (Chips et Coherency Issues) is relevant too: ? > > The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee > > but radeon is not r128, iirc. > > My current state is: > > - parisc AGP GART code writes IOMMU entries in the wrong byte order and > doesn't add the coherency information SBA code adds > > - our PCI BAR setup doesn't really work very well together with the Radeon > DRM address setup. DRM will generate addresses, which are even outside > of the connected LBA > > I've hacked around both problems, but it doesn't solve the ring test > issue. I even bought an PCI Radeon card to rule out any AGP oddities, > but nothing new came out of the experiments with the PCI card. Hang on, if you bought a new Radeon card, how are you POSTing it? The BIOS will have the x86 POST code. > I've started checking drivers/video/aty to see what it does with > acceleration and compare that with radeon DRM. The aty driver uses > an endian config bit DRM doesn't use, but I haven't tested whether > this makes a difference and how it is connected to the overall picture. > > What I'm still wondering is whether radeon DRM really works on 64bit > big endian boxes. Is there any prove, that someone has it running ? > Is it running on any big endian boxes ? Yes, I've got (or rather had) one working on a power station (the IBM Linux on Power workstation) before it died. It was an R128. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 06, 2013 at 06:12:01PM +0400, Alex Ivanov wrote: > 06.09.2013, ? 12:52, Thomas Bogendoerfer <tsbogend@alpha.franken.de> ???????(?): > > DRM will generate addresses, which are even outside > > of the connected LBA > > Aren't they fixing this sort of problems, like here: https://lkml.org/lkml/2010/12/6/516 ? no it's the side CPU->card. It only happens with PCI GART mode. DRM shuffles around the addresses for VRAM and GTT, but misses that non PC platforms might have more than one PCI bus, where transactions are forwarded... or whatever it misses in our setup. > > Is it running on any big endian boxes ? > > I've seen some patches were made for KMS in order to fix support for > big-endian machines, however all of them seem to be done for relatively > new chips, like r600. do you have a pointer to them ? Thomas.
On Fri, Sep 06, 2013 at 07:50:57AM -0700, James Bottomley wrote: > Hang on, if you bought a new Radeon card, how are you POSTing it? The > BIOS will have the x86 POST code. there is an x86 emulator in PDC. I even get PDC console on nvidia cards. I also tested matrox cards but their bios hangs the machine. > Yes, I've got (or rather had) one working on a power station (the IBM > Linux on Power workstation) before it died. It was an R128. was that with the KMS/DRM driver or the aty one ? Thomas.
On Fri, 2013-09-06 at 18:11 +0200, Thomas Bogendoerfer wrote: > On Fri, Sep 06, 2013 at 07:50:57AM -0700, James Bottomley wrote: > > Hang on, if you bought a new Radeon card, how are you POSTing it? The > > BIOS will have the x86 POST code. > > there is an x86 emulator in PDC. I even get PDC console on nvidia > cards. I also tested matrox cards but their bios hangs the machine. Hm, OK ... what you describe sounds like the card is incorrectly POSTed. > > Yes, I've got (or rather had) one working on a power station (the IBM > > Linux on Power workstation) before it died. It was an R128. > > was that with the KMS/DRM driver or the aty one ? It was with the vanilla kernel. The machine went belly up about two years ago, so it's not with anything recent. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
With the new modules, I sometimes encounter the following warning at
boot on rp3440:
[drm] radeon: 8M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x0000000042540000).
radeon 0000:e0:02.0: WB disabled
radeon 0000:e0:02.0: fence driver on ring 0 use gpu addr
0xffffffffd0000000 and cpu addr 0x000000007c716000
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
------------[ cut here ]------------
WARNING: at kernel/workqueue.c:1378
Modules linked in: radeon(+) cfbfillrect cfbimgblt cfbcopyarea
i2c_algo_bit drm_kms_helper ttm drm i2c_core backlight ohci_pci
ohci_hcd xfs exportfs btrfs xor lzo_compress zlib_deflate raid6_pq
crc32c libcrc32c dm_mod zalon7xx lasi700 53c700 hilkbd sd_mod
crc_t10dif usb_storage sg sr_mod cdrom ehci_pci tg3 ehci_hcd
pata_cmd64x ptp sym53c8xx libata pps_core scsi_transport_spi usbcore
scsi_mod usb_common
CPU: 0 PID: 1220 Comm: modprobe Not tainted 3.11.0+ #1
task: 000000007f054808 ti: 000000007f0c8000 task.ti: 000000007f0c8000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001000000000000001110 Not tainted
r00-03 000000000804000e 000000007f0c92b0 000000004015edb8
000000007f0c92b0
r04-07 0000000040768900 0000000042536d00 000000007c809f20
000000007c809f28
r08-11 000000007f0c9350 000000007fc40600 0000000000000020
0000000000000020
r12-15 0000000000000000 0000000000000001 000000004078c100
000000007f0c8288
r16-19 0000000000000050 0000000000000000 000000007f0c8410
0000000000000000
r20-23 000000000800000e 000000007c808006 0000000000000000
000000001e071628
r24-27 000000007c809f20 0000000000000000 0000000042533600
0000000040768900
r28-31 0000000000000001 000000007f0c9350 000000007f0c9380
0000000000000000
sr00-03 0000000000162800 0000000000000000 0000000000000000
0000000000113000
sr04-07 0000000000000000 0000000000000000 0000000000000000
0000000000000000
IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004015ee5c
000000004015ee60
IIR: 03ffe01f ISR: 0000000010240000 IOR: 000000094cd33600
CPU: 0 CR30: 000000007f0c8000 CR31: a001019408140000
ORIG_R28: 0000000000000001
IAOQ[0]: __queue_work+0x2dc/0x360
IAOQ[1]: __queue_work+0x2e0/0x360
RP(r2): __queue_work+0x238/0x360
Backtrace:
[<000000004015ef64>] queue_work_on+0x84/0xa8
[<000000001df55dfc>] r100_irq_process+0x2ec/0x5d8 [radeon]
[<000000001df48cc4>] radeon_driver_irq_preinstall_kms+0x16c/0x1a0
[radeon]
[<000000001cdbd024>] drm_irq_install+0x11c/0x3c0 [drm]
[<000000001df48f8c>] radeon_irq_kms_init+0x8c/0x168 [radeon]
[<000000001df5aeac>] r100_startup+0x22c/0x3c8 [radeon]
[<000000001df5b880>] r100_init+0x348/0x5c0 [radeon]
[<000000001defbff4>] radeon_device_init+0x79c/0x9d0 [radeon]
[<000000001deff588>] radeon_driver_load_kms+0xb8/0x1a8 [radeon]
[<000000001cdc682c>] drm_get_pci_dev+0x28c/0x390 [drm]
[<000000001def96e4>] radeon_pci_probe+0xcc/0x120 [radeon]
[<000000004035fd74>] pci_device_probe+0xc4/0xf8
[<00000000403d0fd8>] really_probe+0xd0/0x328
[<00000000403d13e8>] __driver_attach+0x100/0x108
[<00000000403ce290>] bus_for_each_dev+0xa0/0x100
[<00000000403d08cc>] driver_attach+0x34/0x48
---[ end trace 9a90037d977025eb ]---
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
Dave
--
John David Anglin dave.anglin@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
08.09.2013, 01:08, "John David Anglin" <dave.anglin@bell.net>: > With the new modules, I sometimes encounter the following warning at > boot on rp3440: > > [drm] radeon: 8M of VRAM memory ready > [drm] radeon: 512M of GTT memory ready. > [drm] GART: num cpu pages 131072, num gpu pages 131072 > [drm] PCI GART of 512M enabled (table at 0x0000000042540000). > radeon 0000:e0:02.0: WB disabled > radeon 0000:e0:02.0: fence driver on ring 0 use gpu addr > 0xffffffffd0000000 and cpu addr 0x000000007c716000 > [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [drm] Driver supports precise vblank timestamp query. > ------------[ cut here ]------------ > WARNING: at kernel/workqueue.c:1378 > Modules linked in: radeon(+) cfbfillrect cfbimgblt cfbcopyarea > i2c_algo_bit drm_kms_helper ttm drm i2c_core backlight ohci_pci > ohci_hcd xfs exportfs btrfs xor lzo_compress zlib_deflate raid6_pq > crc32c libcrc32c dm_mod zalon7xx lasi700 53c700 hilkbd sd_mod > crc_t10dif usb_storage sg sr_mod cdrom ehci_pci tg3 ehci_hcd > pata_cmd64x ptp sym53c8xx libata pps_core scsi_transport_spi usbcore > scsi_mod usb_common > CPU: 0 PID: 1220 Comm: modprobe Not tainted 3.11.0+ #1 > task: 000000007f054808 ti: 000000007f0c8000 task.ti: 000000007f0c8000 > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00001000000001000000000000001110 Not tainted > r00-03 000000000804000e 000000007f0c92b0 000000004015edb8 > 000000007f0c92b0 > r04-07 0000000040768900 0000000042536d00 000000007c809f20 > 000000007c809f28 > r08-11 000000007f0c9350 000000007fc40600 0000000000000020 > 0000000000000020 > r12-15 0000000000000000 0000000000000001 000000004078c100 > 000000007f0c8288 > r16-19 0000000000000050 0000000000000000 000000007f0c8410 > 0000000000000000 > r20-23 000000000800000e 000000007c808006 0000000000000000 > 000000001e071628 > r24-27 000000007c809f20 0000000000000000 0000000042533600 > 0000000040768900 > r28-31 0000000000000001 000000007f0c9350 000000007f0c9380 > 0000000000000000 > sr00-03 0000000000162800 0000000000000000 0000000000000000 > 0000000000113000 > sr04-07 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > > IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004015ee5c > 000000004015ee60 > IIR: 03ffe01f ISR: 0000000010240000 IOR: 000000094cd33600 > CPU: 0 CR30: 000000007f0c8000 CR31: a001019408140000 > ORIG_R28: 0000000000000001 > IAOQ[0]: __queue_work+0x2dc/0x360 > IAOQ[1]: __queue_work+0x2e0/0x360 > RP(r2): __queue_work+0x238/0x360 > Backtrace: > [<000000004015ef64>] queue_work_on+0x84/0xa8 > [<000000001df55dfc>] r100_irq_process+0x2ec/0x5d8 [radeon] > [<000000001df48cc4>] radeon_driver_irq_preinstall_kms+0x16c/0x1a0 > [radeon] > [<000000001cdbd024>] drm_irq_install+0x11c/0x3c0 [drm] > [<000000001df48f8c>] radeon_irq_kms_init+0x8c/0x168 [radeon] > [<000000001df5aeac>] r100_startup+0x22c/0x3c8 [radeon] > [<000000001df5b880>] r100_init+0x348/0x5c0 [radeon] > [<000000001defbff4>] radeon_device_init+0x79c/0x9d0 [radeon] > [<000000001deff588>] radeon_driver_load_kms+0xb8/0x1a8 [radeon] > [<000000001cdc682c>] drm_get_pci_dev+0x28c/0x390 [drm] > [<000000001def96e4>] radeon_pci_probe+0xcc/0x120 [radeon] > [<000000004035fd74>] pci_device_probe+0xc4/0xf8 > [<00000000403d0fd8>] really_probe+0xd0/0x328 > [<00000000403d13e8>] __driver_attach+0x100/0x108 > [<00000000403ce290>] bus_for_each_dev+0xa0/0x100 > [<00000000403d08cc>] driver_attach+0x34/0x48 > > ---[ end trace 9a90037d977025eb ]--- > [drm] radeon: irq initialized. > [drm] Loading R100 Microcode > > Dave > -- > John David Anglin dave.anglin@bell.net Seen with 3.11.0 on c8000 few times. Though it was workqueue.c:137*9* and no modules were linked in. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- r100.c.orig 2013-09-04 16:53:28.000000000 +0000 +++ r100.c 2013-09-04 18:28:23.000000000 +0000 @@ -1049,9 +1049,13 @@ static int r100_cp_init_microcode(struct return err; } +#define RADEON_CP_ME_RAM_DATAHL 0x07dc0x07e0 + +void r100_mm_wregq(struct radeon_device *rdev, uint64_t reg, uint64_t v, + bool always_indirect); static void r100_cp_load_microcode(struct radeon_device *rdev) { - const __be32 *fw_data; + const __be64 *fw_data; int i, size; if (r100_gui_wait_for_idle(rdev)) { @@ -1060,14 +1064,12 @@ static void r100_cp_load_microcode(struc } if (rdev->me_fw) { - size = rdev->me_fw->size / 4; - fw_data = (const __be32 *)&rdev->me_fw->data[0]; + size = rdev->me_fw->size / 8; + fw_data = (const __be64 *)&rdev->me_fw->data[0]; WREG32(RADEON_CP_ME_RAM_ADDR, 0); - for (i = 0; i < size; i += 2) { - WREG32(RADEON_CP_ME_RAM_DATAH, - be32_to_cpup(&fw_data[i])); - WREG32(RADEON_CP_ME_RAM_DATAL, - be32_to_cpup(&fw_data[i + 1])); + for (i = 0; i < size; i += 1) { + r100_mm_wregq(rdev, RADEON_CP_ME_RAM_DATAHL, + be64_to_cpup(&fw_data[i]), false); } } } @@ -4078,6 +4080,21 @@ void r100_mm_wreg(struct radeon_device * } } +void r100_mm_wregq(struct radeon_device *rdev, uint64_t reg, uint64_t v, + bool always_indirect) +{ + if (reg < rdev->rmmio_size && !always_indirect) + writeq(v, ((void __iomem *)rdev->rmmio) + reg); + else { + unsigned long flags; + + spin_lock_irqsave(&rdev->mmio_idx_lock, flags); + writeq(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); + writeq(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA); + spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags); + } +} + u32 r100_io_rreg(struct radeon_device *rdev, u32 reg) { if (reg < rdev->rio_mem_size)