GSoC Linux UIO driver for PRU

Nils Hölscher nilhoel1 at gmail.com
Thu Jul 18 09:14:26 UTC 2019


On Thu, 18 Jul 2019 at 10:48, Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> On 18/07/2019 10:30, Nils Hölscher wrote:
> > 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
>
> Hello Nils,
>
> maybe there is a misunderstanding here: Vijays driver adds mmap support
> to the libbsd devfs. So if you port a driver from FreeBSD via libbsd,
> you can use the mmap of that driver (at least if the mmap returns a
> pointer without any address translation or similar unsupported stuff).
>

Is this the case for my mmap function, that return 0?
 https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L730

>
> The driver you just linked creates a RTEMS file system structure
> directly. This structure could be used to create a file with
> IMFS_make_generic_node directly.
>
> Is there some reason that you try to create your own node instead of
> using the already defined ti_pruss_cdevsw structure? With the make_def
> in line 630 it should already create a file.
>
> By the way: You create the structure in a
>
>     #ifndef __rtems__
>
> but it's a RTEMS type so it maybe should be a
>
>     #ifdef __rtems__
>
> instead.
>
> Best regards
>
> Christian
>
> >
> > On Wed, 17 Jul 2019 at 11:43, Nils Hölscher <nilhoel1 at gmail.com
> > <mailto: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
> >     <mailto: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>
> >         > <mailto: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>
> >         >     <mailto: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>
> >         >         <mailto: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>
> >         >             <mailto: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>
> >         >                 <mailto: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>
> >         <mailto: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>
> >         <mailto: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
> >         >
> >
> >         --
> >         --------------------------------------------
> >         embedded brains GmbH
> >         Herr Christian Mauderer
> >         Dornierstr. 4
> >         D-82178 Puchheim
> >         Germany
> >         email: christian.mauderer at embedded-brains.de
> >         <mailto: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.
> >
> >
> > _______________________________________________
> > 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/62291834/attachment-0002.html>


More information about the devel mailing list