Linux driver VME-Bridge tsi-148

Mon Jan 14 17:17:04 UTC 2013

(Please keep this on list)

On 14/01/13 15:35, ternaryd wrote:
> On Mon, 14 Jan 2013 11:14:33 +0000
> Martyn Welch <martyn.welch at ge.com> wrote:
>
>> I'm afraid there's not much documentation about the user space access
>> at the moment. There is a module called "vme_user" that needs to be
>> built and loaded. It requires the VME bus to which it is to be bound
>> to be specified. For most people (who only have 1 VME bridge on
>> their board) this will be [...] If you have these built into you
>> kernel, appending "vme_user.bus=0" to your boot args should be
>> sufficient.
>
> I did do this, but obviously, vme-user requires vme-bus to get started
> first (see below).
>

It will require the core and at least one bridge to be registered with it to
be usable.

>> The VME core provides an in-kernel API for the development of VME
>> device drivers. There is a module called "vme_user" which exposes a
>> very limited capability through to user space (no interrupt
>> reception for example). This was written as a debug tool, though
>> some find it useful for writing simple VME drivers/access routines
>> in user space.
>
> So, what do people do, to use this driver? follow the vme-api guide to
> write a driver like vme_user? I'm being naive here, but why is this
> necessary at all, if the chip is always the same tsi148? Wouldn't it be
> possible to have one for everybody?
>

You have a choice:

1) Write a kernel driver for the VME hardware, using the API laid out in
vme-api.txt.
2) Write something in user space, accessing VME via vme_user to utilise
devices on the VME bus.

The first option provides you with a lot more features, the later is viable
for simple tasks and doesn't require kernel level programming.

There are other VME bridges besides the tsi148, the IBM ALMA2e and Tundra
UniverseII bridges being 2 examples.

>>> vme_tsi148 0000:02:0e.0: Can't get assigned pci irq vector 00
>>> vme_tsi148 0000:02:0e.0: Chip Initialization failed.
>>> vme_tsi148: probe of 0000:02:0e.0 failed with error -22
>>
>> It appears that your PCI interrupts aren't getting set up correctly.
>> You should see something more like this:
>>
>> vme_tsi148 0000:0d:00.0: Board is the VME system controller
>> vme_tsi148 0000:0d:00.0: VME geographical address is 1
>> vme_tsi148 0000:0d:00.0: VME Write and flush and error check is
>> disabled vme_tsi148 0000:0d:00.0: CR/CSR Offset: 1
>> vme_tsi148 0000:0d:00.0: Enabling CR/CSR space
>
> This might be the reason, why the kernel with vme_user crashes:
>
> ------------[ cut here ]------------
> kernel BUG at drivers/base/driver.c:169!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=8 VME1022
> Modules linked in:
> NIP: c02b65dc LR: c039bf00 CTR: c02a6518
> REGS: ef049db0 TRAP: 0700   Not tainted  (3.7.1vme1022)
> MSR: 00029000 <CE,EE,ME>  CR: 22000022  XER: 20000000
> TASK = ef044000[1] 'swapper/0' THREAD: ef048000 CPU: 0
> GPR00: 00000001 ef049e60 ef044000 c0675444 c0675498 00000000 c02a8c58 63636573
> GPR08: 73204472 c065629c 00000000 00000001 22000022 00000000 c00027c4 00000000
> GPR16: 00000000 00000000 00000000 c0675444 00000000 00000020 c0649424 c0690000
> GPR24: c0675498 c068b008 c067547c c0690000 c0675428 c0637c58 ef048000 c0675444
> NIP [c02b65dc] driver_register+0x24/0x180
> LR [c039bf00] vme_register_driver+0x4c/0x268
> Call Trace:
> [ef049e80] [c039bf00] vme_register_driver+0x4c/0x268
> [ef049ed0] [c0637ce4] vme_user_init+0x8c/0xa0
> [ef049ee0] [c0002210] do_one_initcall+0x150/0x1b8
> [ef049f10] [c00028f4] kernel_init+0x130/0x2bc
> [ef049f40] [c000e5f8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 38210010 7c0803a6 4e800020 9421ffe0 7c0802a6 bf410008 7c7f1b78 90010024
> 80830004 8004003c 7c000034 5400d97e <0f000000> 80040020 2f800000 419e0010
> ---[ end trace 1e968e8d971b8c72 ]---
>

Hmm, it shouldn't crash, just wait for the correct bus to appear. Something is
obviously not quite right.

I just tried on a very slightly older kernel:

# uname -a
Linux gefanuc-ppc9a 3.7.0-rc2 #4 SMP PREEMPT Mon Jan 14 17:05:07 UTC 2013 ppc
GNU/Linux
# zcat /proc/config.gz | grep VME
# CONFIG_BLK_DEV_NVME is not set
CONFIG_VME_BUS=y
# VME Bridge Drivers
CONFIG_VME_CA91CX42=m
CONFIG_VME_TSI148=m
# VME Board Drivers
CONFIG_VMIVME_7805=m
# VME Device Drivers
CONFIG_VME_USER=m
# CONFIG_VME_PIO2 is not set
CONFIG_STRICT_DEVMEM=y
# lsmod
Module                  Size  Used by
ipv6                  259727  12
# modprobe vme_user bus=0
vme_user: module is from the staging directory, the quality is unknown, you
have been warned.
VME User Space Access Driver
# lsmod
Module                  Size  Used by
vme_user                7632  0
ipv6                  259727  12
# modprobe vme_tsi148
vme_tsi148 0000:0d:00.0: Board is the VME system controller
vme_tsi148 0000:0d:00.0: VME geographical address is 1
vme_tsi148 0000:0d:00.0: VME Write and flush and error check is disabled
vme_tsi148 0000:0d:00.0: CR/CSR Offset: 1
vme_tsi148 0000:0d:00.0: Enabling CR/CSR space
# lsmod
Module                  Size  Used by
vme_tsi148             20846  0
vme_user                7632  0
ipv6                  259727  12
#

I'm not aware of any changes between 3.7.0-rc2 and 3.7.1 that could be causing
this and I can't see any in git either.

>> I suspect your device tree may be wrong and PCI isn't being
>> setup/scanned correctly.
>
> The flattened device tree file I've got was supplied unwillingly by the
> vendor, and actually I couldn't find any reference to VME or TSI or 148.
> How could I find out, what needs to get inserted? What does a correct
> entry look like?
>

It's a PCI device, so should get detected at boot during the PCI scan. However
the entries in the device tree for the PCI bus would need to exist and be correct.

Martyn

>> The vme_user module will provide some dev files to access up to 4
>> slave and 4 master windows. There is currently an IOCTL interface to
>> configure each window from it's device file (you'll have to see
>> "drivers/staging/vme/devices/vme_user.c" in the kernel source code
>> for more information, it's not well documented at the moment).
>
> I'll do my best, once I reach there.
>
> Thanks,
>

-- 
Martyn Welch (Lead Software Engineer)  | Registered in England and Wales
GE Intelligent Platforms               | (3828642) at 100 Barbirolli Square
T +44(0)1327322748                     | Manchester, M2 3AB
E martyn.welch at ge.com                  | VAT:GB 927559189