All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] implementing a new rtdm driver
@ 2008-10-15 12:21 Axel Beierlein
  2008-10-15 14:51 ` Jan Kiszka
  0 siblings, 1 reply; 3+ messages in thread
From: Axel Beierlein @ 2008-10-15 12:21 UTC (permalink / raw)
  To: xenomai

Hello,

i will implement my Serial ppc-PSC driver into the rtdm and
there are some hardwarespecific things that differ from the 
implementation of the 16550A.

Is it right that i have to add these things to the existing Serial 
Profile in rtserial.h?
What for is the device sub class Makro and how can i use it for a new 
profile? Perhaps #ifdef compiling?

Summarize:
What is the preferred way to implement an new serial Hardware into the 
existing RTDM Serial Device Profile?


At the moment i use Xeno 2.3.5 with an 2.4.25 Kernel on an MP5200B

Thanks

Axel




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Xenomai-help] implementing a new rtdm driver
  2008-10-15 12:21 [Xenomai-help] implementing a new rtdm driver Axel Beierlein
@ 2008-10-15 14:51 ` Jan Kiszka
       [not found]   ` <48F64626.7040304@domain.hid>
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Kiszka @ 2008-10-15 14:51 UTC (permalink / raw)
  To: belatronix; +Cc: xenomai

Axel Beierlein wrote:
> Hello,
> 
> i will implement my Serial ppc-PSC driver into the rtdm and
> there are some hardwarespecific things that differ from the 
> implementation of the 16550A.
> 
> Is it right that i have to add these things to the existing Serial 
> Profile in rtserial.h?

Well, unless that UART comes with some very special features or someone
made a mistake when defining the serial profile, you should be able to
provide a compatible driver.

> What for is the device sub class Makro and how can i use it for a new 
> profile? Perhaps #ifdef compiling?

Please discuss with us what you want to #ifdef so that we can tell you
why you shouldn't. ;)

Regarding the subclass: It might only be for informational purposes, but
it would definitely make sense when you add new services to the profile
(or leave out existing ones).

> 
> Summarize:
> What is the preferred way to implement an new serial Hardware into the 
> existing RTDM Serial Device Profile?
> 

Unless you find significant shared code in your to-be-written driver and
the 16550A, I would say go for a separate implementation of the same API
(== RTDM profile). If you find common code, than let us discuss some
generic UART framework for RTDM.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Xenomai-help] implementing a new rtdm driver
       [not found]   ` <48F64626.7040304@domain.hid>
@ 2008-10-16 13:21     ` Jan Kiszka
  0 siblings, 0 replies; 3+ messages in thread
From: Jan Kiszka @ 2008-10-16 13:21 UTC (permalink / raw)
  To: belatronix; +Cc: Xenomai-help

[ Save the CCs! ]

Axel Beierlein wrote:
> Jan Kiszka schrieb:
>> Axel Beierlein wrote:
>>  
>>> Hello,
>>>
>>> i will implement my Serial ppc-PSC driver into the rtdm and
>>> there are some hardwarespecific things that differ from the
>>> implementation of the 16550A.
>>>
>>> Is it right that i have to add these things to the existing Serial
>>> Profile in rtserial.h?
>>>     
>>
>> Well, unless that UART comes with some very special features or someone
>> made a mistake when defining the serial profile, you should be able to
>> provide a compatible driver.
>>
>>  
>>> What for is the device sub class Makro and how can i use it for a new
>>> profile? Perhaps #ifdef compiling?
>>>     
>>
>>   
> My first Idea was anything like
> #if RTDM_SUB_CLASS  = = RT_SERIAL_PSC
> ioctl functions for the new Hardware
> ...
>> Please discuss with us what you want to #ifdef so that we can tell you
>> why you shouldn't. ;)
>>
>>   
> Ok, I also think that this was not a good idea :-(
>> Regarding the subclass: It might only be for informational purposes, but
>> it would definitely make sense when you add new services to the profile
>> (or leave out existing ones).
>>
>>   
> Why does this make sense?
> In the testdriver profile there you have defined three subclasses and
> special ioctl functions for different uses of the driver. But the
> defined subclass Makros are not used apart from writing to the device
> structure.
> For what kind of Information are the different subclasses?

It pops up under /proc/xenomai/rtdm, and the user application can query
the subclass via RTIOC_DEVICE_INFO.

> Sorry, when i am a little bit slow on the uptake!
> 
>>> Summarize:
>>> What is the preferred way to implement an new serial Hardware into
>>> the existing RTDM Serial Device Profile?
>>>
>>>     
>>
>> Unless you find significant shared code in your to-be-written driver and
>> the 16550A, I would say go for a separate implementation of the same API
>> (== RTDM profile). If you find common code, than let us discuss some
>> generic UART framework for RTDM.
>>   
> The most of your 16550 code i can use for the psc one but the ioctl
> routine will differ slightly. Also the init and
> configuration sequences.
> 
> Ok, i will post the drivercode the next time, perhaps we can find a way
> to fit it to xenomai. But first i will make a working beta
> and do some tests on our hardware.

Looking forward!

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-16 13:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-15 12:21 [Xenomai-help] implementing a new rtdm driver Axel Beierlein
2008-10-15 14:51 ` Jan Kiszka
     [not found]   ` <48F64626.7040304@domain.hid>
2008-10-16 13:21     ` Jan Kiszka

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.