GSoC Linux UIO driver for PRU

Christian Mauderer christian.mauderer at embedded-brains.de
Thu Jul 18 09:24:29 UTC 2019


On 18/07/2019 11:14, Nils Hölscher wrote:
> 
> 
> On Thu, 18 Jul 2019 at 10:48, Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto: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

>From a quick look your mmap just returns the address of a memory
resource (most likely defined in your device tree) with an offset. That
should be a physical address and therefore I would expect that it works
without a problem.

You maybe should check that: If you call mmap take a look at the return
value. If it returns the address in an expected range (is that a shared
memory for your PRU?) everything is OK.

> 
> 
>     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>
>     > <mailto: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>
>     >     <mailto: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>>
>     >         > <mailto: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>>
>     >         >     <mailto: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>>
>     >         >         <mailto: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>>
>     >         >             <mailto: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>>
>     >         >               
>      <mailto: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>>
>     >         <mailto: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>>
>     >         <mailto: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
>     >         >
>     >
>     >         --
>     >         --------------------------------------------
>     >         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>
>     >         <mailto: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 <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.
> 

-- 
--------------------------------------------
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.



More information about the devel mailing list