On Mon, 25 Feb 2013 09:44:48 +0000
Martyn Welch <martyn.welch@xxxxxx> wrote:
On 21/02/13 08:42, ternaryd wrote:
>> The point is, that vme_user must not be compiled into the kernel,
>> it needs to be built as a module. Otherwise, vme_user is executed
>> before vme_tsi148 (and probably any other hardware driver) and
>> hence can't find any device at all.
>
> That shouldn't be a problem, if this is the case it's a bug.
It is, and it is a very confusing one. This is the behavior on the
MicroSys VME1022 board, leaving the vme-subsystem from the stock kernel
untouched. I also have an Emerson MVME2500 board, where the vme
subsystem has long patches, but in regard to this issue, I couldn't
find a difference. The fact is, that on the MicroSys board, only the
module allows finishing the startup.
>> I've come so far to understand, that a master window is configured
>> by opening /dev/bus/vme/m0 and making an ioctl call with the
>> VME_SET_MASTER command. But besides 0, any base address (VME space)
>> for that window is rejected. Would it be possible, that someone
>> posted a few lines, showing how it is done correctly? As vme_user
>> was used for debugging vme_tsi148, there should be a way to set
>> up such a window and write/read a few demo values, right?
> Sending ioctl calls to /dev/bus/vme/m0 will setup master window 0.
>
> Are you using A16?
Yes. The problem is in vme_user.c:
image[i].resource = vme_master_request (vme_user_bridge,
VME_A32, VME_SCT, VME_D32);
If I understood this right, the request allocates the resources, where
the address space, the cycle type and the data width are bit strings
restricting the actual setup. As these are the resource attributes, the
above line should mean, that only the a32 address space may be used. As
a matter of fact, changing VME_A32 to "VME_A16 | VME_A32", and VME_D32
to "VME_D16 | VME_D32" resolves this part for me.
What I did not understand is, why image->size_buf is set to PCI_BUF_SIZE
(0x20000). As you suggested, I made a renamed copy of vme_user and
changed that: With my copy, it is necessary to request an image, where
these parameters can be specified (this is an ioctl, which also has a
sister to remove these resources). In my setup, aspace becomes a16,
cyce sct|super|data and dwidth d16. This seems to work. After this
request, the setup uses the same aspace, cycle, dwidth values, and
addes the VME base address 0xffff0000.
> The master windows on the tsi148 have to be 16-bit aligned, so for
> A16 address space, the master windows must be setup to see the whole
> A16 address space.
I'm not sure, to know what 16-bit aligned actually means, but the VME
address I need is 0xffff-0000, which is imposed by an I/O card (which
has no CPU nor any configuration). As the lower 16 bits are 0, this
should be perfectly aligned, but of course it is greater than
VME_A16_MAX.
> IIRC 2 of the slave windows can do A16, these must be 4-bit aligned
> when using A16. The requirements for A32 and A64 are different and
> covered in the hardware manual.
I didn't reach the point of using slave windows yet. Right now, I'm
very puzzled by hard lockups which doe not generate any type of kernel
output (not even with all lockdep enabled). I'm also trying to figure
out, how I can find out whether the local controller is the VME bus
master and, in case it is not, how to acquire ownership of the bus. In
the TSI148 manual, I only found four bits (VS/VSA and DWB/DHB) which
are not used in vme_tsi148.c at all. I could not find any reference for
who is the bus master after boot. I would have guessed, that it is the
same as the System Controller (slot 1) but vme_get_slot() only returns
zero, no matter in which slot the card actually is.
Thanks,
--
Christoph
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
