On 25/02/13 10:17, ternaryd wrote:
> 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.
>
The address space, the cycle type and the data width fields should be a OR'ed
set of the capabilities you require from the resource. Not all VME windows are
equal, for example on some VME bridges only specific windows are capable of
A16 operation. If you are going to user A16, you need to specify that to
ensure you get a compatible resource.
> What I did not understand is, why image->size_buf is set to PCI_BUF_SIZE
> (0x20000).
Because that's the size of the buffer (memory allocation) that the vme_user
module is allocating for the slave windows:
image[i].kern_buf = vme_alloc_consistent(image[i].resource,
image[i].size_buf, &image[i].pci_buf);
> 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.
>
You will effectively be setting the base address as 0x0000. The upper 16 bits
of that address aren't going to be compared when using the A16 address space.
>> 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.
>
A16 is a 16-bit addressable space. The manual says that bits 0 to 15 of the
base address are reserved, read-only and the reset value is 0x0. 0xffff0000 is
a 32-bit address. Are you sure that's not that the IO device uses from 0x0000
to 0xffff (i.e. the whole of the A16 address space)?
>> 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.
It's automatic, if by bus master you mean the one issuing the read or write.
> 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.
>
It sounds like your hardware doesn't have the geographic lines wired to the
tsi148. Some vendors wire them to an FPGA or other logic and have a custom
method to read the geographic address.
Martyn
--
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@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
