Re: [Xenomai] ipipe + preempt_rt : spinlock issue

["Cédric Perles" <cperles@sepro-group.com>]

Hi Philippe,

Thank's for your answere.
Replacing spin lock calls by equivalent raw spin lock in gpio_generic did 
the trick.

Thank's a lot.

Cédric


-----Message d'origine-----
De : Philippe Gerum [mailto:rpm@xenomai.org]
Envoyé : mercredi 1 novembre 2017 21:57
À : Cédric Perles; xenomai@xenomai.org
Objet : Re: [Xenomai] ipipe + preempt_rt : spinlock issue

On 10/31/2017 12:03 PM, Cédric Perles wrote:
> Hi,
>
>
>
> I’m working on an iMX6 based board with NXP kernel 4.1.15.
>
> I made a Xenomai 3.0.5/ipipe bsp that works well and I also made a
> preempt-rt bsp that works well too.
>
>
>
> However, now I would like to make a Xenomai/ipipe + preempt_rt bsp.
>
>
>
> I adapted preempt_rt patch to fit to ipipe patched kernel but during
> compilation I’m facing issues concerning spinlocks:
>
>
>
> drivers/gpio/gpio-generic.c:496:2: note: in expansion of macro
> 'spin_lock_init'
>
>   spin_lock_init(&bgc->lock);
>
>   ^
>
> include/linux/spinlock_rt.h:17:24: error: '__ipipe_spinlock_t {aka
> struct <anonymous>}' has no member named 'lock'
>
>   rt_mutex_init(&(slock)->lock);   \
>
>

gpio-generic should use raw spinlock accessors (e.g. spin_lock_init -> 
raw_spin_lock_init()).

>
>
>
> Searching some help on internet, I realized that only a few people
> tried to use both Xenomai and Preempt-rt.
>
> => Is it an heresy ? if so, Why ?
>

Not particularly.

> I thought it was the best way to limit preemption for the tasks that
> switched temporarily to secondary mode.
>
>

That may not be the best reason to use such combo, i.e. if this is about 
papering over issues caused by dual kernel's rt threads escaping the proper 
runtime mode. Those threads should not do that in the first place.

A legitimate reason to use such combo is rather to have different classes of 
rt requirements in a single application, which are best served by combined 
approaches.

>
> => If it is not a stupid idea, did somebody already resolve this kind
> of conflict ?

Yes, this may seem daunting at first, but there are usually only a few of 
them, almost only in include/spinlock*. Conflicts in sched/core may be a bit 
trickier to address though, but they don't appear frequently.

> and how ?
>
>
Well, just as you are doing: making sense of the changes, and figuring out 
how to fix the few conflicts.

--
Philippe.