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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
