> The instrumented dmesg had a couple of my local test changes and was
> bad now that I had ROM. Reverted them exept my readb changes (instead
> of direct dereferences of iomapped space) and redid
> logging to be more precise.
>
> > [drm] radeon kernel modesetting enabl
On 27 August 2014 04:24, Michel D?nzer wrote:
> On 26.08.2014 16:07, Meelis Roos wrote:
>
> r100 init hangs in a different place. Original dmesg first, then my
> instrumented dmesg (seems to get further):
The instrumented dmesg had a couple of my local test changes and w
On 26.08.2014 16:07, Meelis Roos wrote:
r100 init hangs in a different place. Original dmesg first, then my
instrumented dmesg (seems to get further):
>>>
>>> The instrumented dmesg had a couple of my local test changes and was
>>> bad now that I had ROM. Reverted them exept my readb chan
On 25.08.2014 23:48, Meelis Roos wrote:
>> r100 init hangs in a different place. Original dmesg first, then my
>> instrumented dmesg (seems to get further):
>
> The instrumented dmesg had a couple of my local test changes and was
> bad now that I had ROM. Reverted them exept my readb changes (inste
> > > r100 init hangs in a different place. Original dmesg first, then my
> > > instrumented dmesg (seems to get further):
> >
> > The instrumented dmesg had a couple of my local test changes and was
> > bad now that I had ROM. Reverted them exept my readb changes (instead
> > of direct dereference
> r100 init hangs in a different place. Original dmesg first, then my
> instrumented dmesg (seems to get further):
The instrumented dmesg had a couple of my local test changes and was
bad now that I had ROM. Reverted them exept my readb changes (instead
of direct dereferences of iomapped space)
> > I'll try to follow up with a patch some time next week.
>
> And next week became 4 months later, sorry :-/
>
> Meelis, I've coded up a patch series that should take care of this
> issue, which I'll post to sparclinux with you CC:'d right now.
Tested them yesterday.
PCI ROM allocation seems
From: David Miller
Date: Fri, 04 Apr 2014 16:52:02 -0400 (EDT)
> I'll try to follow up with a patch some time next week.
And next week became 4 months later, sorry :-/
Meelis, I've coded up a patch series that should take care of this
issue, which I'll post to sparclinux with you CC:'d right no
From: Meelis Roos
Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST)
>> > > That looks quite strange. I guess the kernel should map the ROM at the
>> > > address OpenBoot/OF assigned to it. ( 1002 ).
>> >
>> > The address you see is a raw physical I/O address, which is a concatenation
>> > of the I
> > > That looks quite strange. I guess the kernel should map the ROM at the
> > > address OpenBoot/OF assigned to it. ( 1002 ).
> >
> > The address you see is a raw physical I/O address, which is a concatenation
> > of the I/O window physical address for that PCI controller and the
> > PCI bu
> > >> The pci_assign_resource() path must have some bug that causes the
> > >> resource values to be set incorrectly or similar.
> > >>
> > >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
> > >> before the pci_map_rom() call?
> > >
> > > [drm] radeon_read_bios: pci_re
> >> > That looks quite strange. I guess the kernel should map the ROM at the
> >> > address OpenBoot/OF assigned to it. ( 1002 ).
> >>
> >> The address you see is a raw physical I/O address, which is a concatenation
> >> of the I/O window physical address for that PCI controller and the
> >>
From: mr...@linux.ee
Date: Tue, 24 Sep 2013 00:14:41 +0300 (EEST)
>> > That looks quite strange. I guess the kernel should map the ROM at the
>> > address OpenBoot/OF assigned to it. ( 1002 ).
>>
>> The address you see is a raw physical I/O address, which is a concatenation
>> of the I/O wind
From: Kjetil Oftedal
Date: Mon, 23 Sep 2013 21:06:11 +0200
> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 1002 ).
The address you see is a raw physical I/O address, which is a concatenation
of the I/O window physical address f
Hi,
That looks quite strange. I guess the kernel should map the ROM at the
address OpenBoot/OF assigned to it. ( 1002 ).
Are pci devices located beneatch pci@1f,0 not reserving resources
correctly ? (Thus the reuse of addresses when the addresses are
assigned during runtime ? or is there some
> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 1002 ).
DaveM already explained about the phys/virt mapping.
> Are pci devices located beneatch pci@1f,0 not reserving resources
> correctly ? (Thus the reuse of addresses when the
> > That looks quite strange. I guess the kernel should map the ROM at the
> > address OpenBoot/OF assigned to it. ( 1002 ).
>
> The address you see is a raw physical I/O address, which is a concatenation
> of the I/O window physical address for that PCI controller and the
> PCI bus assigned a
Resurrecting an old thread...
> On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote:
> > From: Michel Dänzer
> > Date: Thu, 06 Sep 2012 18:55:51 +0200
> >
> >> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> >>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
> >>> Ul
> we should just skip the igp reading function on not-x86, since IGP on
> not x86 makes no sense.
I #ifdef'ed out the igp part with CONFIG_X86. This time it got to
[drm] radeon: ring at 0x01FF0C002000
and stopped here. Some printks showed the actual hang happens in
radeon_ring_commit() with th
> we should just skip the igp reading function on not-x86, since IGP on
> not x86 makes no sense.
I #ifdef'ed out the igp part with CONFIG_X86. This time it got to
[drm] radeon: ring at 0x01FF0C002000
and stopped here. Some printks showed the actual hang happens in
radeon_ring_commit() with th
On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote:
> From: Michel D?nzer
> Date: Thu, 06 Sep 2012 18:55:51 +0200
>
>> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
>>> Ultra 10 (clean, without my "Video RAM" hack th
On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote:
> From: Michel Dänzer
> Date: Thu, 06 Sep 2012 18:55:51 +0200
>
>> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
>>> Ultra 10 (clean, without my "Video RAM" hack th
From: Michel Dänzer
Date: Thu, 06 Sep 2012 18:55:51 +0200
> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
>> Ultra 10 (clean, without my "Video RAM" hack that I talked in other
>> sparclinux posts). When I saw that
From: Adam Jackson
Date: Thu, 06 Sep 2012 12:51:17 -0400
> On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>
>> And here the machine hangs. Debugging printk-s reveal that it does not
>> find any active I/O port resources and then continues into initializing
>> the card. Down in igp_read_
From: Meelis Roos
Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST)
> And here the machine hangs. Debugging printk-s reveal that it does not
> find any active I/O port resources and then continues into initializing
> the card. Down in igp_read_bios_from_vram() it successfully ioremaps
> memory regio
On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
> Ultra 10 (clean, without my "Video RAM" hack that I talked in other
> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
> kernel, I compiled radeo
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
Ultra 10 (clean, without my "Video RAM" hack that I talked in other
sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
kernel, I compiled radeon drm driver with modesetting enabled and tried
it:
[drm] rad
From: Michel D?nzer
Date: Thu, 06 Sep 2012 18:55:51 +0200
> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
>> Ultra 10 (clean, without my "Video RAM" hack that I talked in other
>> sparclinux posts). When I saw that
From: Adam Jackson
Date: Thu, 06 Sep 2012 12:51:17 -0400
> On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
>
>> And here the machine hangs. Debugging printk-s reveal that it does not
>> find any active I/O port resources and then continues into initializing
>> the card. Down in igp_read_
From: Meelis Roos
Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST)
> And here the machine hangs. Debugging printk-s reveal that it does not
> find any active I/O port resources and then continues into initializing
> the card. Down in igp_read_bios_from_vram() it successfully ioremaps
> memory regio
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> PCI: Enabling device: (:02:02.0), cmd 82
> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
> [drm] register mmio base:
On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
> Ultra 10 (clean, without my "Video RAM" hack that I talked in other
> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
> kernel, I compiled radeo
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> PCI: Enabling device: (:02:02.0), cmd 82
> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
> [drm] register mmio base:
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
Ultra 10 (clean, without my "Video RAM" hack that I talked in other
sparclinux posts). When I saw that Sun XVR-100 was detected fine by the
kernel, I compiled radeon drm driver with modesetting enabled and tried
it:
[drm] rad
34 matches
Mail list logo
