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