On Thu, 2009-04-23 at 16:27 -0600, Gary Thomas wrote:
> I don't think any of this matters. It turns out that even
> the 2.6.26 kernel fails on an identical board with a newer
> revision of the 8347 chip. I'm sure that the problem is
> that the Coral-P fails when mapped to 0 (PCI relative).
Ther
Kumar Gala wrote:
>
> On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
>
>> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>>
>> static void
>> fixup_hide_host_resource_fsl(struct pci_dev *dev)
>> {
>> int i, class = dev->class >> 8;
>>
>> #if 0
>> if ((class == PCI_CLASS_PROCE
On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == P
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
>
>> Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>>
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function
'fs
On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
Kumar Gala wrote:
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function
'fsl_add_bridge'
was common among architectures and
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>
>>
>> I found the difference - in 2.6.28 the inbound/outbound windows
>> don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
>> was common among architectures and ended up calling 'setup_pci_atmu'
>> whi
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function
'fsl_add_bridge'
was common among architectures and ended up calling 'setup_pci_atmu'
which created those mappings. In 2.
Kumar Gala wrote:
I'm still looking into how the PCI address register for the video
card did not get written, even though the system obviously thinks
it did (hence "virtual")
>>>
>>> It most definitely has something to do with 0xC000 being
>>> assigned to the video card. I
I'm still looking into how the PCI address register for the video
card did not get written, even though the system obviously thinks
it did (hence "virtual")
It most definitely has something to do with 0xC000 being
assigned to the video card. I changed my DTS to move everything
up (started
On Apr 21, 2009, at 5:22 PM, Gary Thomas wrote:
Gary Thomas wrote:
Kumar Gala wrote:
On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
The [two] big differences I see are that the video card (00:0d.0)
is being assigned 0xC000, which lspci marks as "virtual".
I think I've had trouble in th
Gary Thomas wrote:
> Kumar Gala wrote:
>> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>>
>>> The [two] big differences I see are that the video card (00:0d.0)
>>> is being assigned 0xC000, which lspci marks as "virtual".
>>> I think I've had trouble in the past with memory regions which
>>>
Kumar Gala wrote:
>
> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>
>> The [two] big differences I see are that the video card (00:0d.0)
>> is being assigned 0xC000, which lspci marks as "virtual".
>> I think I've had trouble in the past with memory regions which
>> started at 0 relative
On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
The [two] big differences I see are that the video card (00:0d.0)
is being assigned 0xC000, which lspci marks as "virtual".
I think I've had trouble in the past with memory regions which
started at 0 relative to the PCI space. Also "virtual"
Gary Thomas wrote:
> Gary Thomas wrote:
>> I had a stable port of 2.6.26 for my 834x hardware, with a
>> frame buffer on a PCI device. After I upgraded to 2.6.28,
>> this isn't working any more. The frame buffer code is happily
>> writing to a mapped [memory] space on the PCI card, but nothing
>>
Gary Thomas wrote:
> I had a stable port of 2.6.26 for my 834x hardware, with a
> frame buffer on a PCI device. After I upgraded to 2.6.28,
> this isn't working any more. The frame buffer code is happily
> writing to a mapped [memory] space on the PCI card, but nothing
> is happening.
>
> Did so
I had a stable port of 2.6.26 for my 834x hardware, with a
frame buffer on a PCI device. After I upgraded to 2.6.28,
this isn't working any more. The frame buffer code is happily
writing to a mapped [memory] space on the PCI card, but nothing
is happening.
Did something [subtle] change in how th
16 matches
Mail list logo
