<div dir="ltr">Hi,<div><br></div><div>Do I need to add an <span style="color:rgb(0,0,0);font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";font-size:14px;white-space:pre-wrap">rtems_filesystem_file_</span><span style="color:rgb(0,0,0);font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";font-size:14px;white-space:pre-wrap">handlers_r</span> struct to the pru driver to register it or are the <span style="color:rgb(0,0,0);font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";font-size:14px;white-space:pre-wrap">cdevsw </span>sufficient?</div><div>Current status of the driver:</div><div><a href="https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L806">https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L806</a><br></div><div><br></div><div>I am still not clear what the differences between these two structs are.</div><div><br></div><div>Best,</div><div>Nils</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Jul 2019 at 11:43, Nils Hölscher <<a href="mailto:nilhoel1@gmail.com">nilhoel1@gmail.com</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"><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" target="_blank">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>
</blockquote></div>