RE: VME driver patch for PowerPC

quoted

quoted

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/

Heater, Daniel (GE Infrastructure) wrote:

quoted

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/