RE: VME - PowerPC: Resource sizes

RE: VME - PowerPC: Resource sizes

[Heater, Daniel (GE Infrastructure)]

> We could iterate the PCI bus tree to the top (there is some
> parent bus
> field, IIRC), and then start complete iteration until a suitable
> resource is found. This may produce larger resource regions with
> reasonable effort.

On the x86 boards we've dealt with we've gotten away with opening
VMEbus windows in PCI space not allocated by the Universe's parent
bridge because the parent bridges have always been set up for
subtractive decoding. So if no one else claimed the cycle, it got
passed down through the bridge to the Universe anyway.

> Are you sure you mean 768 _KB_ and 2 _MB_, not 768 _MB_ and 2
> _GB_? My SLSI window is already 64 MB big.

My bad. It's actually 768KB and 2GB are correct. The SLSI window
does fail to allocate with the patch.

daniel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: VME - PowerPC: Resource sizes

[Oliver Korpilla]

Heater, Daniel (GE Infrastructure) wrote:

>>We could iterate the PCI bus tree to the top (there is some
>>parent bus
>>field, IIRC), and then start complete iteration until a suitable
>>resource is found. This may produce larger resource regions with
>>reasonable effort.
>>
>>
>
>On the x86 boards we've dealt with we've gotten away with opening
>VMEbus windows in PCI space not allocated by the Universe's parent
>bridge because the parent bridges have always been set up for
>subtractive decoding. So if no one else claimed the cycle, it got
>passed down through the bridge to the Universe anyway.
>
>
>>Are you sure you mean 768 _KB_ and 2 _MB_, not 768 _MB_ and 2
>>_GB_? My SLSI window is already 64 MB big.
>>
>>
>
>My bad. It's actually 768KB and 2GB are correct. The SLSI window
>does fail to allocate with the patch.
>
>
That's not very good. I'm getting an Intel board (I guess VMIVME7700) In
the near future, so I could test several options. If my code does
prevent you from getting resonable window sizes, we could either walk
the tree, or conditionalize the code that way, that for the x86 resource
are again requested from iomem_resource directly.

But I guess that walking the tree should have a net result very similar
to your original code.

With kind regards,
Oliver Korpilla

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: VME driver patch for PowerPC

[Heater, Daniel (GE Infrastructure)]

> >>Could you check, whether the patch to your driver (version
> >>7433-3.2 of your
> >>Linux support) still compiles on an Intel platform, and works
> >>as intended?
> >>
> >Yep. I only did a quick test, but it appears to work fine on x86.
> >I've merged your patch up with the code base for the next release.
> >
> Great!
>
> I don't know about x86 bus organization, but maybe it limits
> the address
> range for available addresses too strongly (on a single bus,
> where the
> Universe is on). Comparing how much window space you can map with the
> old version and the new one on x86 could prove useful.

Your dead on right. I cannot allocate as much space. In fact,
on a VMIVME-7750 I'm only able to allocate 768KB now vs. the
~2MB I could access before.

> Adding the patch below activated correct behaviour for vme_peek/poke,
> with correct data width (tested VME_D8, VME_D16 and VME_D32), and
> without cache bursts.
>
> It simply sets the cache-inhibited and guarded bits before
> remapping the pages (these flags are PowerPC-specific, and the
> pci_mmap_page_range() function is sadly no exported kernel symbol).
>
> Would you again be so kind to run some "still works"-test on an
> Intel board?

That part still works.

Thanks,
Daniel L. Heater
Software Development, Embedded Systems
GE Fanuc Automation Americas, Inc.
VMIC, Inc.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

VME - PowerPC: Resource sizes

[Oliver Korpilla]

Heater, Daniel (GE Infrastructure) wrote:

>>I don't know about x86 bus organization, but maybe it limits
>>the address
>>range for available addresses too strongly (on a single bus,
>>where the
>>Universe is on). Comparing how much window space you can map with the
>>old version and the new one on x86 could prove useful.
>>
>>
>
>Your dead on right. I cannot allocate as much space. In fact,
>on a VMIVME-7750 I'm only able to allocate 768KB now vs. the
>~2MB I could access before.
>
>
Since we only request the current bus the Universe is on, there could be
a fix:
We could iterate the PCI bus tree to the top (there is some parent bus
field, IIRC), and then start complete iteration until a suitable
resource is found. This may produce larger resource regions with
reasonable effort.

Are you sure you mean 768 _KB_ and 2 _MB_, not 768 _MB_ and 2 _GB_? My
SLSI window is already 64 MB big, and with the PCI layout on my MVME2100
it is imaginable that I could map 84000000 - BEFFFFFF = 944MB (from end
of SLSI window to start of the Universe I/O memory)?

With kind regards,
Oliver Korpilla

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/