[Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Pintu Kumar]

Hi,

I have a sample linux char driver which I am registering using normal
misc_register/deregister function.
In this driver, I have used, open, read, write, ioctl, release system calls.

Now I wanted to convert this driver to RTDM interface and compare it.
Later I wanted to add some more use cases related to interrupt
processing by connecting some external peripheral.

Firstly, please guide me how to easily convert an existing linux char
driver to RTDM model.


Thank You!

Regards,
Pintu

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Jan Kiszka]

On 2018-02-26 12:26, Pintu Kumar wrote:
> Hi,
> 
> I have a sample linux char driver which I am registering using normal
> misc_register/deregister function.
> In this driver, I have used, open, read, write, ioctl, release system calls.
> 
> Now I wanted to convert this driver to RTDM interface and compare it.
> Later I wanted to add some more use cases related to interrupt
> processing by connecting some external peripheral.
> 
> Firstly, please guide me how to easily convert an existing linux char
> driver to RTDM model.
> 

Conversion of existing Linux UART drivers to RTDM is not straightforward
as the former relies on a larger hierarchy of Linux drivers, starting
with the tty core over the serial core and possibly some chip
abstractions (8250). RTDM, as you can see from the existing drivers in
kernel/drivers/serial, is rather compact and does not come with that
infrastructure, primarily as it has a confined use case. Best is to
study those drivers, use one as template and replace the required
hardware accesses.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Pintu Kumar]

Dear Jan,

This thread is about porting a normal misc char driver to rtdm model.

Anyways I got some clue by looking into rtdmtest driver.
But what is confusing to me is the rtdm context_ part and the rt, nrt part.
How can I map this eith my exusting driver?
Can I leave the context part NULL and use only rt for all other calls.

Thanks,
Pintu

On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:

> On 2018-02-26 12:26, Pintu Kumar wrote:
> > Hi,
> >
> > I have a sample linux char driver which I am registering using normal
> > misc_register/deregister function.
> > In this driver, I have used, open, read, write, ioctl, release system
> calls.
> >
> > Now I wanted to convert this driver to RTDM interface and compare it.
> > Later I wanted to add some more use cases related to interrupt
> > processing by connecting some external peripheral.
> >
> > Firstly, please guide me how to easily convert an existing linux char
> > driver to RTDM model.
> >
>
> Conversion of existing Linux UART drivers to RTDM is not straightforward
> as the former relies on a larger hierarchy of Linux drivers, starting
> with the tty core over the serial core and possibly some chip
> abstractions (8250). RTDM, as you can see from the existing drivers in
> kernel/drivers/serial, is rather compact and does not come with that
> infrastructure, primarily as it has a confined use case. Best is to
> study those drivers, use one as template and replace the required
> hardware accesses.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Greg Gallagher]

You'd have to decide what functionality you want with respect to rt
and non rt for your driver.  What's confusing about the context?  The
gpio driver is pretty up to date, you can look at it for some
guidance.  Unfortunately there isn't a lot of documentation at the
moment, so your best bet is to look at some of the existing drivers.
It's easier to answer specific questions you may have about the RTDM
framework.  The other question is do you need at RTDM driver?  Could
you use the UDD framework instead?  With the UDD framework you just
need to support a small RTDM driver and the rest of the driver lives
in user space.

-Greg

On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
> Dear Jan,
>
> This thread is about porting a normal misc char driver to rtdm model.
>
> Anyways I got some clue by looking into rtdmtest driver.
> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
> How can I map this eith my exusting driver?
> Can I leave the context part NULL and use only rt for all other calls.
>
> Thanks,
> Pintu
>
> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>
>> On 2018-02-26 12:26, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I have a sample linux char driver which I am registering using normal
>> > misc_register/deregister function.
>> > In this driver, I have used, open, read, write, ioctl, release system
>> > calls.
>> >
>> > Now I wanted to convert this driver to RTDM interface and compare it.
>> > Later I wanted to add some more use cases related to interrupt
>> > processing by connecting some external peripheral.
>> >
>> > Firstly, please guide me how to easily convert an existing linux char
>> > driver to RTDM model.
>> >
>>
>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>> as the former relies on a larger hierarchy of Linux drivers, starting
>> with the tty core over the serial core and possibly some chip
>> abstractions (8250). RTDM, as you can see from the existing drivers in
>> kernel/drivers/serial, is rather compact and does not come with that
>> infrastructure, primarily as it has a confined use case. Best is to
>> study those drivers, use one as template and replace the required
>> hardware accesses.
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Pintu Kumar]

Dear Greg & Jan,

Thank you so much for your help. Yes I am looking into existing sample
drivers to understand. I think I got some clue.
Basically I am developing a dummy RTDM char driver for some
experimentation and analysis purpose.
As you said, since there is no proper documentation for developing a
RTDM driver, I might be having some more silly queries (if I am
stuck).

1)
> What's confusing about the context?
As I see, there is a context_size that we need to set in rtdm_driver structure.
Is this really required to set ? Can I set it to 0 ?
Anyways, I currently set like this (for time being):
struct dummy_context {
        unsigned char *buffer;
        unsigned int len;
};
Hope this fine ?

2)
> The other question is do you need at RTDM driver?
Yes, I need to develop a RTDM driver because I need to compare it with
normal kernel driver.
Later I need to add some specific use case for some purpose.

3) How do we allocate memory in RTDM driver ?
    I see rtdm_malloc()/free() is used. Is this in kernel allocation
like kmalloc/vmalloc ?
    Or, I need to directly use kmalloc/vmalloc itself , considering
similar scenario like normal kernel approach.

4) ^^Most important^^: how to I compile a sample RTDM char driver?
    Is it the same method like normal kernel Makefile and using the
xeno_config in addition ?
    Is there any RTDM Makefile reference available ?


5) When I install the RTDM driver (using insmod or modprobe), will it
create the /dev node automatically like "misc" ?
    I am registering the driver using: RTDM_CLASS_MISC


Thanks,
Pintu


On Mon, Feb 26, 2018 at 10:58 PM, Greg Gallagher <greg@embeddedgreg.com> wrote:
> You'd have to decide what functionality you want with respect to rt
> and non rt for your driver.  What's confusing about the context?  The
> gpio driver is pretty up to date, you can look at it for some
> guidance.  Unfortunately there isn't a lot of documentation at the
> moment, so your best bet is to look at some of the existing drivers.
> It's easier to answer specific questions you may have about the RTDM
> framework.  The other question is do you need at RTDM driver?  Could
> you use the UDD framework instead?  With the UDD framework you just
> need to support a small RTDM driver and the rest of the driver lives
> in user space.
>
> -Greg
>
> On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>> Dear Jan,
>>
>> This thread is about porting a normal misc char driver to rtdm model.
>>
>> Anyways I got some clue by looking into rtdmtest driver.
>> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
>> How can I map this eith my exusting driver?
>> Can I leave the context part NULL and use only rt for all other calls.
>>
>> Thanks,
>> Pintu
>>
>> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>>
>>> On 2018-02-26 12:26, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I have a sample linux char driver which I am registering using normal
>>> > misc_register/deregister function.
>>> > In this driver, I have used, open, read, write, ioctl, release system
>>> > calls.
>>> >
>>> > Now I wanted to convert this driver to RTDM interface and compare it.
>>> > Later I wanted to add some more use cases related to interrupt
>>> > processing by connecting some external peripheral.
>>> >
>>> > Firstly, please guide me how to easily convert an existing linux char
>>> > driver to RTDM model.
>>> >
>>>
>>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>>> as the former relies on a larger hierarchy of Linux drivers, starting
>>> with the tty core over the serial core and possibly some chip
>>> abstractions (8250). RTDM, as you can see from the existing drivers in
>>> kernel/drivers/serial, is rather compact and does not come with that
>>> infrastructure, primarily as it has a confined use case. Best is to
>>> study those drivers, use one as template and replace the required
>>> hardware accesses.
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Pintu Kumar]

Hi,

I am getting some error while building a RTDM driver. Please check my
inline reply.


On Tue, Feb 27, 2018 at 7:09 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
> Dear Greg & Jan,
>
> Thank you so much for your help. Yes I am looking into existing sample
> drivers to understand. I think I got some clue.
> Basically I am developing a dummy RTDM char driver for some
> experimentation and analysis purpose.
> As you said, since there is no proper documentation for developing a
> RTDM driver, I might be having some more silly queries (if I am
> stuck).
>
> 1)
>> What's confusing about the context?
> As I see, there is a context_size that we need to set in rtdm_driver structure.
> Is this really required to set ? Can I set it to 0 ?
> Anyways, I currently set like this (for time being):
> struct dummy_context {
>         unsigned char *buffer;
>         unsigned int len;
> };
> Hope this fine ?
>
> 2)
>> The other question is do you need at RTDM driver?
> Yes, I need to develop a RTDM driver because I need to compare it with
> normal kernel driver.
> Later I need to add some specific use case for some purpose.
>
> 3) How do we allocate memory in RTDM driver ?
>     I see rtdm_malloc()/free() is used. Is this in kernel allocation
> like kmalloc/vmalloc ?
>     Or, I need to directly use kmalloc/vmalloc itself , considering
> similar scenario like normal kernel approach.
>
> 4) ^^Most important^^: how to I compile a sample RTDM char driver?
>     Is it the same method like normal kernel Makefile and using the
> xeno_config in addition ?
>     Is there any RTDM Makefile reference available ?
>

Hi,

I get this errors when compiling a sample RTDM driver.

rtdummy.c:63:15: error: initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
   .write_rt = dummy_write,
               ^
/home/pintu/rtdummy.c:63:15: note: (near initialization for
‘dummy_driver.ops.write_rt’)
cc1: some warnings being treated as errors


However, if I comment the write_rt part, the module is build successfully.
Why this error is coming only for write part, but not for read, open,
ioctl and others ?

This is my Makefile (simple Makefile used for building linux kernel module)
--------------------------------
EXTRA_CFLAGS    += -I$(shell pwd)

obj-m := rtdummy.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
        $(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
        $(MAKE) -C $(KDIR) M=$(PWD) clean
--------------------------------

This is the structure used:

-------------------------------------------------------------
static struct rtdm_driver dummy_driver = {
        .profile_info           =       RTDM_PROFILE_INFO(dummy,
                                                          RTDM_CLASS_DUMMY,
                                                          RTDM_SUBCLASS_DUMMY,
                                                          0),
        .device_flags           =       RTDM_NAMED_DEVICE|RTDM_EXCLUSIVE,
        .device_count           =       1,
        .context_size           =       sizeof(struct dummy_context),
        .ops = {
                .open           =       dummy_open,
                .read_rt        =       dummy_read,
                .write_rt       =       dummy_write,
                .ioctl_rt       =       dummy_ioctl,
                .ioctl_nrt      =       dummy_ioctl,
                .close          =       dummy_close,
        },
};
-------------------------------------------------------------

Please let me know how to fix this error ?


Thanks,
Pintu


>
> 5) When I install the RTDM driver (using insmod or modprobe), will it
> create the /dev node automatically like "misc" ?
>     I am registering the driver using: RTDM_CLASS_MISC
>
>
> Thanks,
> Pintu
>
>
> On Mon, Feb 26, 2018 at 10:58 PM, Greg Gallagher <greg@embeddedgreg.com> wrote:
>> You'd have to decide what functionality you want with respect to rt
>> and non rt for your driver.  What's confusing about the context?  The
>> gpio driver is pretty up to date, you can look at it for some
>> guidance.  Unfortunately there isn't a lot of documentation at the
>> moment, so your best bet is to look at some of the existing drivers.
>> It's easier to answer specific questions you may have about the RTDM
>> framework.  The other question is do you need at RTDM driver?  Could
>> you use the UDD framework instead?  With the UDD framework you just
>> need to support a small RTDM driver and the rest of the driver lives
>> in user space.
>>
>> -Greg
>>
>> On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>>> Dear Jan,
>>>
>>> This thread is about porting a normal misc char driver to rtdm model.
>>>
>>> Anyways I got some clue by looking into rtdmtest driver.
>>> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
>>> How can I map this eith my exusting driver?
>>> Can I leave the context part NULL and use only rt for all other calls.
>>>
>>> Thanks,
>>> Pintu
>>>
>>> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 2018-02-26 12:26, Pintu Kumar wrote:
>>>> > Hi,
>>>> >
>>>> > I have a sample linux char driver which I am registering using normal
>>>> > misc_register/deregister function.
>>>> > In this driver, I have used, open, read, write, ioctl, release system
>>>> > calls.
>>>> >
>>>> > Now I wanted to convert this driver to RTDM interface and compare it.
>>>> > Later I wanted to add some more use cases related to interrupt
>>>> > processing by connecting some external peripheral.
>>>> >
>>>> > Firstly, please guide me how to easily convert an existing linux char
>>>> > driver to RTDM model.
>>>> >
>>>>
>>>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>>>> as the former relies on a larger hierarchy of Linux drivers, starting
>>>> with the tty core over the serial core and possibly some chip
>>>> abstractions (8250). RTDM, as you can see from the existing drivers in
>>>> kernel/drivers/serial, is rather compact and does not come with that
>>>> infrastructure, primarily as it has a confined use case. Best is to
>>>> study those drivers, use one as template and replace the required
>>>> hardware accesses.
>>>>
>>>> Jan
>>>>
>>>> --
>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>>> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Greg Gallagher]

What's your prototype for dummy_write?  Can you post the function
definition.  It looks like there's a rt_write is expecting a different
type.

On Wed, Feb 28, 2018 at 7:16 AM, Pintu Kumar <pintu.ping@gmail.com> wrote:
> Hi,
>
> I am getting some error while building a RTDM driver. Please check my
> inline reply.
>
>
> On Tue, Feb 27, 2018 at 7:09 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>> Dear Greg & Jan,
>>
>> Thank you so much for your help. Yes I am looking into existing sample
>> drivers to understand. I think I got some clue.
>> Basically I am developing a dummy RTDM char driver for some
>> experimentation and analysis purpose.
>> As you said, since there is no proper documentation for developing a
>> RTDM driver, I might be having some more silly queries (if I am
>> stuck).
>>
>> 1)
>>> What's confusing about the context?
>> As I see, there is a context_size that we need to set in rtdm_driver structure.
>> Is this really required to set ? Can I set it to 0 ?
>> Anyways, I currently set like this (for time being):
>> struct dummy_context {
>>         unsigned char *buffer;
>>         unsigned int len;
>> };
>> Hope this fine ?
>>
>> 2)
>>> The other question is do you need at RTDM driver?
>> Yes, I need to develop a RTDM driver because I need to compare it with
>> normal kernel driver.
>> Later I need to add some specific use case for some purpose.
>>
>> 3) How do we allocate memory in RTDM driver ?
>>     I see rtdm_malloc()/free() is used. Is this in kernel allocation
>> like kmalloc/vmalloc ?
>>     Or, I need to directly use kmalloc/vmalloc itself , considering
>> similar scenario like normal kernel approach.
>>
>> 4) ^^Most important^^: how to I compile a sample RTDM char driver?
>>     Is it the same method like normal kernel Makefile and using the
>> xeno_config in addition ?
>>     Is there any RTDM Makefile reference available ?
>>
>
> Hi,
>
> I get this errors when compiling a sample RTDM driver.
>
> rtdummy.c:63:15: error: initialization from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>    .write_rt = dummy_write,
>                ^
> /home/pintu/rtdummy.c:63:15: note: (near initialization for
> ‘dummy_driver.ops.write_rt’)
> cc1: some warnings being treated as errors
>
>
> However, if I comment the write_rt part, the module is build successfully.
> Why this error is coming only for write part, but not for read, open,
> ioctl and others ?
>
> This is my Makefile (simple Makefile used for building linux kernel module)
> --------------------------------
> EXTRA_CFLAGS    += -I$(shell pwd)
>
> obj-m := rtdummy.o
>
> KDIR := /lib/modules/$(shell uname -r)/build
> PWD := $(shell pwd)
>
> default:
>         $(MAKE) -C $(KDIR) M=$(PWD) modules
>
> clean:
>         $(MAKE) -C $(KDIR) M=$(PWD) clean
> --------------------------------
>
> This is the structure used:
>
> -------------------------------------------------------------
> static struct rtdm_driver dummy_driver = {
>         .profile_info           =       RTDM_PROFILE_INFO(dummy,
>                                                           RTDM_CLASS_DUMMY,
>                                                           RTDM_SUBCLASS_DUMMY,
>                                                           0),
>         .device_flags           =       RTDM_NAMED_DEVICE|RTDM_EXCLUSIVE,
>         .device_count           =       1,
>         .context_size           =       sizeof(struct dummy_context),
>         .ops = {
>                 .open           =       dummy_open,
>                 .read_rt        =       dummy_read,
>                 .write_rt       =       dummy_write,
>                 .ioctl_rt       =       dummy_ioctl,
>                 .ioctl_nrt      =       dummy_ioctl,
>                 .close          =       dummy_close,
>         },
> };
> -------------------------------------------------------------
>
> Please let me know how to fix this error ?
>
>
> Thanks,
> Pintu
>
>
>>
>> 5) When I install the RTDM driver (using insmod or modprobe), will it
>> create the /dev node automatically like "misc" ?
>>     I am registering the driver using: RTDM_CLASS_MISC
>>
>>
>> Thanks,
>> Pintu
>>
>>
>> On Mon, Feb 26, 2018 at 10:58 PM, Greg Gallagher <greg@embeddedgreg.com> wrote:
>>> You'd have to decide what functionality you want with respect to rt
>>> and non rt for your driver.  What's confusing about the context?  The
>>> gpio driver is pretty up to date, you can look at it for some
>>> guidance.  Unfortunately there isn't a lot of documentation at the
>>> moment, so your best bet is to look at some of the existing drivers.
>>> It's easier to answer specific questions you may have about the RTDM
>>> framework.  The other question is do you need at RTDM driver?  Could
>>> you use the UDD framework instead?  With the UDD framework you just
>>> need to support a small RTDM driver and the rest of the driver lives
>>> in user space.
>>>
>>> -Greg
>>>
>>> On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>>>> Dear Jan,
>>>>
>>>> This thread is about porting a normal misc char driver to rtdm model.
>>>>
>>>> Anyways I got some clue by looking into rtdmtest driver.
>>>> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
>>>> How can I map this eith my exusting driver?
>>>> Can I leave the context part NULL and use only rt for all other calls.
>>>>
>>>> Thanks,
>>>> Pintu
>>>>
>>>> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> On 2018-02-26 12:26, Pintu Kumar wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I have a sample linux char driver which I am registering using normal
>>>>> > misc_register/deregister function.
>>>>> > In this driver, I have used, open, read, write, ioctl, release system
>>>>> > calls.
>>>>> >
>>>>> > Now I wanted to convert this driver to RTDM interface and compare it.
>>>>> > Later I wanted to add some more use cases related to interrupt
>>>>> > processing by connecting some external peripheral.
>>>>> >
>>>>> > Firstly, please guide me how to easily convert an existing linux char
>>>>> > driver to RTDM model.
>>>>> >
>>>>>
>>>>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>>>>> as the former relies on a larger hierarchy of Linux drivers, starting
>>>>> with the tty core over the serial core and possibly some chip
>>>>> abstractions (8250). RTDM, as you can see from the existing drivers in
>>>>> kernel/drivers/serial, is rather compact and does not come with that
>>>>> infrastructure, primarily as it has a confined use case. Best is to
>>>>> study those drivers, use one as template and replace the required
>>>>> hardware accesses.
>>>>>
>>>>> Jan
>>>>>
>>>>> --
>>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>>>> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RTDM] Converting existing Linux char driver to rtdm driver

[Pintu Kumar]

On Wed, Feb 28, 2018 at 8:19 PM, Greg Gallagher <greg@embeddedgreg.com> wrote:
> What's your prototype for dummy_write?  Can you post the function
> definition.  It looks like there's a rt_write is expecting a different
> type.
>

OK it is working now after adding "const" to void *buf in write function.
Thank you for the clue :)

Regards,
Pintu


> On Wed, Feb 28, 2018 at 7:16 AM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>> Hi,
>>
>> I am getting some error while building a RTDM driver. Please check my
>> inline reply.
>>
>>
>> On Tue, Feb 27, 2018 at 7:09 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>>> Dear Greg & Jan,
>>>
>>> Thank you so much for your help. Yes I am looking into existing sample
>>> drivers to understand. I think I got some clue.
>>> Basically I am developing a dummy RTDM char driver for some
>>> experimentation and analysis purpose.
>>> As you said, since there is no proper documentation for developing a
>>> RTDM driver, I might be having some more silly queries (if I am
>>> stuck).
>>>
>>> 1)
>>>> What's confusing about the context?
>>> As I see, there is a context_size that we need to set in rtdm_driver structure.
>>> Is this really required to set ? Can I set it to 0 ?
>>> Anyways, I currently set like this (for time being):
>>> struct dummy_context {
>>>         unsigned char *buffer;
>>>         unsigned int len;
>>> };
>>> Hope this fine ?
>>>
>>> 2)
>>>> The other question is do you need at RTDM driver?
>>> Yes, I need to develop a RTDM driver because I need to compare it with
>>> normal kernel driver.
>>> Later I need to add some specific use case for some purpose.
>>>
>>> 3) How do we allocate memory in RTDM driver ?
>>>     I see rtdm_malloc()/free() is used. Is this in kernel allocation
>>> like kmalloc/vmalloc ?
>>>     Or, I need to directly use kmalloc/vmalloc itself , considering
>>> similar scenario like normal kernel approach.
>>>
>>> 4) ^^Most important^^: how to I compile a sample RTDM char driver?
>>>     Is it the same method like normal kernel Makefile and using the
>>> xeno_config in addition ?
>>>     Is there any RTDM Makefile reference available ?
>>>
>>
>> Hi,
>>
>> I get this errors when compiling a sample RTDM driver.
>>
>> rtdummy.c:63:15: error: initialization from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>>    .write_rt = dummy_write,
>>                ^
>> /home/pintu/rtdummy.c:63:15: note: (near initialization for
>> ‘dummy_driver.ops.write_rt’)
>> cc1: some warnings being treated as errors
>>
>>
>> However, if I comment the write_rt part, the module is build successfully.
>> Why this error is coming only for write part, but not for read, open,
>> ioctl and others ?
>>
>> This is my Makefile (simple Makefile used for building linux kernel module)
>> --------------------------------
>> EXTRA_CFLAGS    += -I$(shell pwd)
>>
>> obj-m := rtdummy.o
>>
>> KDIR := /lib/modules/$(shell uname -r)/build
>> PWD := $(shell pwd)
>>
>> default:
>>         $(MAKE) -C $(KDIR) M=$(PWD) modules
>>
>> clean:
>>         $(MAKE) -C $(KDIR) M=$(PWD) clean
>> --------------------------------
>>
>> This is the structure used:
>>
>> -------------------------------------------------------------
>> static struct rtdm_driver dummy_driver = {
>>         .profile_info           =       RTDM_PROFILE_INFO(dummy,
>>                                                           RTDM_CLASS_DUMMY,
>>                                                           RTDM_SUBCLASS_DUMMY,
>>                                                           0),
>>         .device_flags           =       RTDM_NAMED_DEVICE|RTDM_EXCLUSIVE,
>>         .device_count           =       1,
>>         .context_size           =       sizeof(struct dummy_context),
>>         .ops = {
>>                 .open           =       dummy_open,
>>                 .read_rt        =       dummy_read,
>>                 .write_rt       =       dummy_write,
>>                 .ioctl_rt       =       dummy_ioctl,
>>                 .ioctl_nrt      =       dummy_ioctl,
>>                 .close          =       dummy_close,
>>         },
>> };
>> -------------------------------------------------------------
>>
>> Please let me know how to fix this error ?
>>
>>
>> Thanks,
>> Pintu
>>
>>
>>>
>>> 5) When I install the RTDM driver (using insmod or modprobe), will it
>>> create the /dev node automatically like "misc" ?
>>>     I am registering the driver using: RTDM_CLASS_MISC
>>>
>>>
>>> Thanks,
>>> Pintu
>>>
>>>
>>> On Mon, Feb 26, 2018 at 10:58 PM, Greg Gallagher <greg@embeddedgreg.com> wrote:
>>>> You'd have to decide what functionality you want with respect to rt
>>>> and non rt for your driver.  What's confusing about the context?  The
>>>> gpio driver is pretty up to date, you can look at it for some
>>>> guidance.  Unfortunately there isn't a lot of documentation at the
>>>> moment, so your best bet is to look at some of the existing drivers.
>>>> It's easier to answer specific questions you may have about the RTDM
>>>> framework.  The other question is do you need at RTDM driver?  Could
>>>> you use the UDD framework instead?  With the UDD framework you just
>>>> need to support a small RTDM driver and the rest of the driver lives
>>>> in user space.
>>>>
>>>> -Greg
>>>>
>>>> On Mon, Feb 26, 2018 at 12:20 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>>>>> Dear Jan,
>>>>>
>>>>> This thread is about porting a normal misc char driver to rtdm model.
>>>>>
>>>>> Anyways I got some clue by looking into rtdmtest driver.
>>>>> But what is confusing to me is the rtdm context_ part and the rt, nrt part.
>>>>> How can I map this eith my exusting driver?
>>>>> Can I leave the context part NULL and use only rt for all other calls.
>>>>>
>>>>> Thanks,
>>>>> Pintu
>>>>>
>>>>> On 26 Feb 2018 7:54 pm, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>>>>>
>>>>>> On 2018-02-26 12:26, Pintu Kumar wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I have a sample linux char driver which I am registering using normal
>>>>>> > misc_register/deregister function.
>>>>>> > In this driver, I have used, open, read, write, ioctl, release system
>>>>>> > calls.
>>>>>> >
>>>>>> > Now I wanted to convert this driver to RTDM interface and compare it.
>>>>>> > Later I wanted to add some more use cases related to interrupt
>>>>>> > processing by connecting some external peripheral.
>>>>>> >
>>>>>> > Firstly, please guide me how to easily convert an existing linux char
>>>>>> > driver to RTDM model.
>>>>>> >
>>>>>>
>>>>>> Conversion of existing Linux UART drivers to RTDM is not straightforward
>>>>>> as the former relies on a larger hierarchy of Linux drivers, starting
>>>>>> with the tty core over the serial core and possibly some chip
>>>>>> abstractions (8250). RTDM, as you can see from the existing drivers in
>>>>>> kernel/drivers/serial, is rather compact and does not come with that
>>>>>> infrastructure, primarily as it has a confined use case. Best is to
>>>>>> study those drivers, use one as template and replace the required
>>>>>> hardware accesses.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> --
>>>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>>>>> Corporate Competence Center Embedded Linux