VME userland API

[Wolfgang Mauerer]

On 25/07/12 13:15, Martyn Welch wrote:
> On 25/07/12 10:20, Wolfgang Mauerer wrote:
>> On 24/07/12 23:53, Martyn Welch wrote:
>>> On 24/07/12 16:34, Wolfgang Mauerer wrote:
>>>> On 20/07/12 10:48, Martyn Welch wrote:
(...)
>>>>       ca91c42x: Allow for exporting status information
>>>
>>> Don't add the function if it's not supported - have the framework just
>>> return -EINVAL if the pointer is null (which it already does)
>> the reason there's a nop function here is that I don't know if ca91c42x
>> can expose these status bits -- perhaps any of the experts on this
>> chipset can help out.
>>
>> As I go along, I may be adding other pieces of information that are also
>> supported by ca91c42x, so I'll keep the function for the time being
>> (if it turns out there's really nothing that can be exported from this
>> bridge, the function will be removed)
>>
> 
> No, just don't add it. It can be added at a later date if it gets supported.
okay, I'll remove the function.
> 
> Looking at the data sheet quickly suggests that the ca91c42x does provide
> support for ACFAIL and SYSFAIL. It would appear the both the tsi148 and
> ca91c42x provide interrupt support on these lines as well, so a simple polling
> method to read the status of these lines many not be the best way to go. It
> would seem that, these signals are likely to be asynchronous in nature and
> especially with ACFAIL will need to be actioned promptly.
> 
> What do you think about supporting these (at the kernel API level) as
> interrupts with callbacks? This could be exposed to user space in vme_user as
> a signal on assertion of the relevant line or vme_user could expose this as a
> polled interface (inactive until callback triggered).
supporting these via interrupt callbacks makes sense. I'll probably use
the mechanisms provided by the uio framework to forward the interrupt
notification to userland.
> 
>>>
>>>>       vme, vme_user: Make bridge status public
>>>
>>> Either the status structure should be in vme.h (so as not to need
>>> vme_user.h in the core) or the sysfail and acfail should be retrievable
>>> without the structure and the structure is a vme_user only thing.
>> if it's okay to put it into vme.h, I'm fine with that. But since it's
>> shared information between kernel and userland, this would require
>> to make vme.h available for userland, which it is currently
>> not (vme_user would need need to be marked as header-y anyway).
>>
> 
> Hmm, I don't think vme.h should be exposed to user space. This was probably
> the rationale for the "We do not want to push aspace, cycle and width to
> userspace as they are" message. IIRC, vme_user currently uses the definitions
> in vme.h in it's structures to enumerate these attributes.
> 
>> We could also create a separate file with shared definitions that
>> is included by vme.h and vme_user.h. Any preferences?
> 
> Pulling out the definitions (address spaces, cycle types and data widths) near
> the top of vme.h into a separate shared header file probably makes a lot of
> sense and would mean that we could get rid of the aforementioned messages.
okay, sounds good to me.

Best, Wolfgang