[Xenomai-help] RTDM driver hints

[Xenomai-help] RTDM driver hints

[juanba romance]

Hello all, i am re-writing a old linux driver which i did myself some
time ago, cause i am in charge to provide a RT system framework. This
is one of the first steps so i have followed the RTDM model to do the
stuff.
Now i also have enough time to change its ugly capabilities/defects
but i am a little stuck right now..

I would like to improve my previous design fully buffering the
incoming user data flow on write method so a input FIFO it's planned.
The FIFO will be emptied using a rt-task created from the "open"
procedure and signalled from the "write" method before the user flow
exit. The point is:
where the FIFO handler references should be defined ?

I have take a look to the serial driver 16550 and my code is really
biased by its data device definition strategy ( obviously this is my
first RTDM monster ;-) and i need some guide ), instead of my
proposal, its design empty the TX FIFO from the IRQ service stuff
where the user context was passed as argument at the "open" call, so
all the parts are softly linked..

I would prefer to add the above program capability to avoid rewrite as
much as possible the current ISR symbol.
but i don't know the beast strategy to be applied to overcome the .

I have pass the "context" field dev_private area pointer to the
rt_task "by hand" but its value is really weird. Should this kind of
information be defined globally trough the "static" stuff and pass
this argument to the rt_task_init symbol

Any hints, advices.. ?
Thanks in advance

PD: Sorry about the brick..

Re: [Xenomai-help] RTDM driver hints

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

juanba romance wrote:
> Hello all, i am re-writing a old linux driver which i did myself some
> time ago, cause i am in charge to provide a RT system framework. This
> is one of the first steps so i have followed the RTDM model to do the
> stuff.
> Now i also have enough time to change its ugly capabilities/defects
> but i am a little stuck right now..
> 
> I would like to improve my previous design fully buffering the
> incoming user data flow on write method so a input FIFO it's planned.
> The FIFO will be emptied using a rt-task created from the "open"
> procedure and signalled from the "write" method before the user flow
> exit. The point is:
> where the FIFO handler references should be defined ?
> 
> I have take a look to the serial driver 16550 and my code is really
> biased by its data device definition strategy ( obviously this is my
> first RTDM monster ;-) and i need some guide ), instead of my
> proposal, its design empty the TX FIFO from the IRQ service stuff
> where the user context was passed as argument at the "open" call, so
> all the parts are softly linked..
> 
> I would prefer to add the above program capability to avoid rewrite as
> much as possible the current ISR symbol.
> but i don't know the beast strategy to be applied to overcome the .
> 
> I have pass the "context" field dev_private area pointer to the
> rt_task "by hand" but its value is really weird. Should this kind of
> information be defined globally trough the "static" stuff and pass
> this argument to the rt_task_init symbol

Before going into details on how to pass references between driver tasks
etc.:

Why do you want to establish a dedicated task for transmission? Is the
job you have to perform there too heavy for IRQ context? Keep in mind
that such a task requires additional management (assign reasonable
priorities e.g.) and adds further latencies. It's no magic bullet, but
it may be appropriate if there is actually a lot of work to do that
shall not block other, more important jobs.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] RTDM driver hints

[juanba romance]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

Thanks Jan..
On 7/30/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Before going into details on how to pass references between driver tasks
> etc.:
>
> Why do you want to establish a dedicated task for transmission? Is the
> job you have to perform there too heavy for IRQ context?


The application has two issues related on:
1.- The transmission setup would be really time extensive, so the ISR will
be really too busy sucking the data from the FIFO and pushing it into the
chipset
2.- Due to system specifications, we have focused the ISR performance in the
data reception flow, so the transmission irq context management must/need be
really fast.
We would like to hold as much as possible both features and this is the
reason to evaluate the rt_task approach..

Keep in mind that such a task requires additional management (assign
> reasonable
> priorities e.g.) and adds further latencies. It's no magic bullet, but
> it may be appropriate if there is actually a lot of work to do that
> shall not block other, more important jobs.


I mean the application specifications allow us to block a little bit the
internal driver write capabilities but the isr read management should be
inherently the most priority program flow.

Jan


As I have mentioned in the previous mail the driver is also a formal design
review, so lot of  variables and data addresses have been re-arranged and
re-structured, one of their was the killer one cause was pointed to the
hyperspace into the thread symbol..
I have checked the context pass argument with the decoded one at the thread
and all is ok now, no troubles related on.
The writer thread is always coupled to the "context" area reference through
the "open" call softly. Anyway, I think that a more generic question could
be stated right now.

Could i assume that the memory references coupled with the context argument
at the "open" call are stables along the context cycle life?
I think that this is not any data trusting if i always link the thread
creation/destroy to the "open"/"close" call entries, but i assume also that
i could have a fully wrong picture about all this stuff.

If you are so kind to give me any extra hints i would be really grateful
Thanks a lot..

[-- Attachment #2: Type: text/html, Size: 2940 bytes --]

Re: [Xenomai-help] RTDM driver hints

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

juanba romance wrote:
> Thanks Jan..
> On 7/30/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Before going into details on how to pass references between driver tasks
>> etc.:
>>
>> Why do you want to establish a dedicated task for transmission? Is the
>> job you have to perform there too heavy for IRQ context?
> 
> 
> The application has two issues related on:
> 1.- The transmission setup would be really time extensive, so the ISR will
> be really too busy sucking the data from the FIFO and pushing it into the
> chipset
> 2.- Due to system specifications, we have focused the ISR performance in the
> data reception flow, so the transmission irq context management must/need be
> really fast.
> We would like to hold as much as possible both features and this is the
> reason to evaluate the rt_task approach..

Ok, got it.

> 
> Keep in mind that such a task requires additional management (assign
>> reasonable
>> priorities e.g.) and adds further latencies. It's no magic bullet, but
>> it may be appropriate if there is actually a lot of work to do that
>> shall not block other, more important jobs.
> 
> 
> I mean the application specifications allow us to block a little bit the
> internal driver write capabilities but the isr read management should be
> inherently the most priority program flow.
> 
> Jan
> 
> 
> As I have mentioned in the previous mail the driver is also a formal design
> review, so lot of  variables and data addresses have been re-arranged and
> re-structured, one of their was the killer one cause was pointed to the
> hyperspace into the thread symbol..
> I have checked the context pass argument with the decoded one at the thread
> and all is ok now, no troubles related on.
> The writer thread is always coupled to the "context" area reference through
> the "open" call softly. Anyway, I think that a more generic question could
> be stated right now.
> 
> Could i assume that the memory references coupled with the context argument
> at the "open" call are stables along the context cycle life?
> I think that this is not any data trusting if i always link the thread
> creation/destroy to the "open"/"close" call entries, but i assume also that
> i could have a fully wrong picture about all this stuff.

If you create the task on "open", stuff its reference into the context,
maybe additionally pass the context as argument to the task function,
and then clean things up on "close", I see no problems of
stalled/inconsistent references. Problems may only arise from races
between the open/close and the task function. So make sure not to rely
on specific, only-valid-on-UP execution orders.

> 
> If you are so kind to give me any extra hints i would be really grateful
> Thanks a lot..

If things are not fully clear yet, I would suggest to post some code
now. That is far more efficient than just describing the design.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]