Hi, Do I need to add an rtems_filesystem_file_handlers_r struct to the pru driver to register it or are the cdevsw sufficient? Current status of the driver: https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L806
I am still not clear what the differences between these two structs are. Best, Nils On Wed, 17 Jul 2019 at 11:43, Nils Hölscher <nilho...@gmail.com> wrote: > Hi, > > I applied the patch and now all compiles. > But I haven't tested anything yet, I am currently working on an > application for testing. > I will keep in contact concerning the mmap patch. > > Best, > Nils > > On Tue, 16 Jul 2019 at 15:47, Christian Mauderer < > christian.maude...@embedded-brains.de> wrote: > >> On 16/07/2019 15:35, Vijay Kumar Banerjee wrote: >> > >> > >> > >> > On Tue, Jul 16, 2019 at 6:57 PM Nils Hölscher <nilho...@gmail.com >> > <mailto:nilho...@gmail.com>> wrote: >> > >> > Thanks I have been able to resolve this. >> > >> > But I have run into another issue. >> > RTEMS port of the character device switch table doesn't support >> > a .d_mmap entry. >> > >> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/sys/conf.h#L199 >> > >> > And I am not certain how the >> > struct rtems_filesystem_file_handlers_r and the structs cdevsw are >> > related. >> > The current BSD driver uses two cdevsw structs, one to manage >> > interrupts and one to manage io. >> > Should or can I switch them out? >> > >> > Hi Nils, >> > >> > I have recently worked on a patch to add d_mmap to libbsd. I couldn't >> > send it to devel because >> > it could not be tested. >> > Christian, by the time the VT issue is resolved. I would like to prepare >> > a separate clean patch >> > for the mmap, what is your suggestion about this? >> >> You create a clean patch only for mmap. Please don't forget to add a >> test case to the libbsd devfs test. Although I would have preferred a >> working driver to test it, it should be OK to be added without one if >> the devfs test works. >> >> Please send a preview of the patch (without devfs test) to the mailing >> list so that Nils can already have a look at it and try it. >> >> Best regards >> >> Christian >> >> > >> > Best, >> > Nils >> > >> > On Tue, 16 Jul 2019 at 13:47, Joel Sherrill <j...@rtems.org >> > <mailto:j...@rtems.org>> wrote: >> > >> > >> > >> > On Tue, Jul 16, 2019, 6:34 AM Nils Hölscher <nilho...@gmail.com >> > <mailto:nilho...@gmail.com>> wrote: >> > >> > Hi, >> > >> > I am currently porting the pruss driver functions, that I >> > want to add in: >> > rtems_filesystem_file_handlers_r pruss_irq_handler. >> > But when I add my functions like this: >> > .open_h =ti_pruss_irq_open >> > I receive the following compiler warnings: >> > ../../pruss.c:156:13: warning: initialization from >> > incompatible pointer type [-Wincompatible-pointer-types] >> > .open_h = ti_pruss_irq_open, >> > ^~~~~~~~~~~~~~~~~ >> > ../../pruss.c:156:13: note: (near initialization for >> > 'pruss_irq_handler.open_h') >> > ../../pruss.c:158:13: warning: initialization from >> > incompatible pointer type [-Wincompatible-pointer-types] >> > .read_h = ti_pruss_irq_read, >> > >> > Can anyone help please? >> > >> > >> > This usually means that either the prototype of the method has >> > not been seen before it is used or the method signature does not >> > match that expected of the indirect method pointer on the left >> > hand side. Make sure the signature matches. >> > >> > The full source can be found here: >> > >> https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L91 >> > >> https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L155 >> > >> > Best, >> > Nils >> > >> > On Mon, 15 Jul 2019 at 10:15, Sebastian Huber >> > <sebastian.hu...@embedded-brains.de >> > <mailto:sebastian.hu...@embedded-brains.de>> wrote: >> > >> > On 15/07/2019 10:10, Nils Hölscher wrote: >> > > Thanks this is very helpful. >> > > But has anyone an existing example of a similar >> driver? >> > > I wasn't able find one in /bsps, maybe I didn't search >> > long enough. >> > >> > There are some in cpukit: >> > >> > cpukit/libcsupport/src/consolesimple.c: >> > IMFS_make_generic_node( >> > cpukit/libcsupport/src/termios.c: rv = >> > IMFS_make_generic_node( >> > cpukit/libcsupport/src/consolesimpletask.c: >> > IMFS_make_generic_node( >> > cpukit/include/rtems/imfs.h: * rv = >> > IMFS_make_generic_node( >> > cpukit/include/rtems/imfs.h:extern int >> > IMFS_make_generic_node( >> > cpukit/libfs/src/imfs/imfs_make_generic_node.c:int >> > IMFS_make_generic_node( >> > cpukit/dev/i2c/i2c-bus.c: rv = IMFS_make_generic_node( >> > cpukit/dev/i2c/i2c-dev.c: rv = IMFS_make_generic_node( >> > cpukit/dev/spi/spi-bus.c: rv = IMFS_make_generic_node( >> > cpukit/libblock/src/blkdev-imfs.c: int rv = >> > IMFS_make_generic_node( >> > cpukit/libblock/src/blkdev-imfs.c: rv = >> > IMFS_make_generic_node( >> > >> > -- >> > Sebastian Huber, embedded brains GmbH >> > >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >> > Phone : +49 89 189 47 41-16 >> > Fax : +49 89 189 47 41-09 >> > E-Mail : sebastian.hu...@embedded-brains.de >> > <mailto:sebastian.hu...@embedded-brains.de> >> > PGP : Public key available on request. >> > >> > Diese Nachricht ist keine geschäftliche Mitteilung im >> > Sinne des EHUG. >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org <mailto:devel@rtems.org> >> > http://lists.rtems.org/mailman/listinfo/devel >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org <mailto:devel@rtems.org> >> > http://lists.rtems.org/mailman/listinfo/devel >> > >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> > >> >> -- >> -------------------------------------------- >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
