[re-adding the list] On 2013-02-08 14:28, Stéphane LOS wrote: > Le 08/02/2013 12:28, Jan Kiszka a écrit : >> On 2013-02-08 10:18, Gilles Chanteperdrix wrote: >>> On 02/08/2013 10:07 AM, Stéphane LOS wrote: >>> >>>> Le 07/02/2013 17:11, Gilles Chanteperdrix a écrit : >>>>> On 02/07/2013 03:53 PM, Stéphane LOS wrote: >>>>> >>>>>> Hello Sirs, >>>>>> >>>>>> Hilscher is offering a Linux driver based on UIO for cifX boards. >>>>>> >>>>>> In my understanding, down to 1ms cycle time, a PREEMPT RT solution >>>>>> should be enough. >>>>>> >>>>>> The cifX boards can manage with bus cycle times down to 250µs like with >>>>>> EtherCAT or Sercos III firmwares. >>>>>> >>>>>> So it seems in that cases that using Xenomai would be the way to go. >>>>>> I suppose that it would be needed to modify or change the existing >>>>>> driver but I can't figure out how things (Xenomai / RTDM / UIO) fit >>>>>> together. >>>>>> >>>>>> UIO is the kernel module that allows the mapping of the board memory to >>>>>> user space. >>>>>> >>>>>> The cifX driver uses the libpciaccess to pick up the board and retrieve >>>>>> some board information from UIO before the mapping. >>>>>> Then it uses pthread and rt functions when accessing the board. >>>>>> >>>>>> Since UIO and libpciaccess are only used during the initialization, is >>>>>> it a problem for a Xenomai application ? >>>>>> >>>>>> We have setup a Xenomai system and tried to compile the user land >>>>>> library with Xenomai options and flags and it seems we have been >>>>>> successful. >>>>>> The driver should be using the POSIX skin of Xenomai if we have been >>>>>> lucky. >>>>>> >>>>>> I can't see why we would need RTDM. Any hint please ? >>>>>> >>>>>> I am an absolute beginner in the Xenomai arena, don't throw me to the >>>>>> lions... >>>>>> >>>>> If UIO is used to register an interrupt handler for instance, the >>>>> interrupt handler will not be called in real-time context when used with >>>>> Xenomai, so, you would have to use the (deprecated) native or posix skin >>>>> services to register a user-space interrupt handler, or more likely >>>>> write an RTDM driver. On the other hand, if what you need is simply >>>>> accessing the board registers through MMIO, then you do not need RTDM. >>>>> >>>>> While accessing registers from user-space may be tempting, there is a >>>>> risk of ending up with an application where the driver code is not >>>>> clearly separated. Writing a driver separated from the application is >>>>> preferable, as it provides a sane isolation between the two. If you >>>>> change the hardware, you just have to rewrite a driver which follows the >>>>> same profile, if you want to write another application using the same >>>>> driver, you can keep the driver. >>>>> >>>> Thank you for your kind support Gilles. >>>> >>>> The cifX Device Driver is Hilscher's library to deal with cifX boards >>>> and is available for the major OSes. >>>> Additionally it is available to anybody as source code, the cifX Driver >>>> Toolkit when one has to create a driver for his own OS. >>>> >>>> This driver library accesses the board interface which is a Dual Port >>>> Memory. >>>> >>>> So the user application shall use this layer and gets independence from >>>> the target OS. >>>> >>>> I understand that we should create an RTDM driver instead of a UIO >>>> driver and adapt the user library so that it uses the RTDM driver. >>>> Am I right ? >>> >>> I tried to explain why it may be better to create an RTDM driver, but in >>> this case this may not be the best option. The answer to your question >>> depends on what you have to do to implement the driver. As I said, if >>> you simply have to access MMIO registers, user-space may be fine, if you >>> have to handle interrupts kernel-space (so, RTDM) is preferable. >> Are we talking about linux/drivers/uio/uio_cif.c here? That one >> obviously has interrupt support. >> >> If your customers may want to use Xenomai 3 with I-pipe instead of >> Preempt-RT underneath (both options will exist), RTDM will still be >> required for interrupt handling. If you like to, you could propose such >> a driver for Xenomai integration. That would ensure it will come with >> future releases. >> >> I also wonder if it didn't make sense for us to provide an UIO-like >> infrastructure for such use cases (single-user device drivers with IRQ >> event channel needs). >> >> Jan >> > > I am talking about the new products based on the netX chip : > http://lxr.free-electrons.com/source/drivers/uio/uio_netx.c
Ah, I see. Structurally similar, though. > > I have been through : > http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3 > > Looks like we should create an RTDM driver and build our Xenomai > specific libcifx on top of it. > > Since the kernel now includes by default the UIO stuff, the board will > likely be detected twice, once by UIO and second by the RTDM driver. > Is it a problem ? > Should the user of the RTDM driver disable UIO / netX in the kernel ? It's not problem to have multiple drivers registered for the same IDs. You can always rebind them via sysfs or black-list one of them in the local modprobe configuration. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
