GSoC Linux UIO driver for PRU

[Nils Hölscher]

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?

Best,
Nils

On Tue, 16 Jul 2019 at 13:47, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Jul 16, 2019, 6:34 AM Nils Hölscher <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> 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
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190716/5672abf4/attachment-0002.html>