GSoC Linux UIO driver for PRU

Nils Hölscher nilhoel1 at gmail.com
Thu Jul 18 08:30:31 UTC 2019


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 <nilhoel1 at 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.mauderer at 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 <nilhoel1 at gmail.com
>> > <mailto:nilhoel1 at 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 <joel at rtems.org
>> >     <mailto:joel at rtems.org>> wrote:
>> >
>> >
>> >
>> >         On Tue, Jul 16, 2019, 6:34 AM Nils Hölscher <nilhoel1 at gmail.com
>> >         <mailto:nilhoel1 at 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.huber at embedded-brains.de
>> >             <mailto:sebastian.huber at 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.huber at embedded-brains.de
>> >                 <mailto:sebastian.huber at embedded-brains.de>
>> >                 PGP     : Public key available on request.
>> >
>> >                 Diese Nachricht ist keine geschäftliche Mitteilung im
>> >                 Sinne des EHUG.
>> >
>> >             _______________________________________________
>> >             devel mailing list
>> >             devel at rtems.org <mailto:devel at rtems.org>
>> >             http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >     _______________________________________________
>> >     devel mailing list
>> >     devel at rtems.org <mailto:devel at rtems.org>
>> >     http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>>
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.mauderer at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190718/fca5dc51/attachment-0002.html>


More information about the devel mailing list