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