[Xenomai] s3c24xx: Priority rotate enable !?

[Xenomai] s3c24xx: Priority rotate enable !?

[Romain Naour]

Hello,

On s3c24xx processors the interrupt source priority isn't fixed by Adeos 
patch (ARB_SEL bits in PRIORITY register).
Is it intentional ?
It may be possible to give priority to an interrupt simultaneously 
arrived that the interruption IRQ_TIMER4 (before being grabbed by 
Adeos). Therefore, we can have more jitter for real time applications.

Do we need to fix the priority at this level ?

Thanks,
Romain


-------------- next part --------------
A non-text attachment was scrubbed...
Name: s3c24xx_fix_interrupt_priority.patch
Type: text/x-patch
Size: 514 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120822/ab2cabfa/attachment.bin>

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/22/2012 06:04 PM, Romain Naour wrote:
> Hello,
> 
> On s3c24xx processors the interrupt source priority isn't fixed by Adeos 
> patch (ARB_SEL bits in PRIORITY register).
> Is it intentional ?
> It may be possible to give priority to an interrupt simultaneously 
> arrived that the interruption IRQ_TIMER4 (before being grabbed by 
> Adeos). Therefore, we can have more jitter for real time applications.

This can always happen even with interrupt priorities: imagine that the
first interrupt happens 1 microsecond before the timer interrupt, even
with the priority, the handler for first interrupt will be executed and
the timer interrupt will have to wait for the end of this handler before
it is serviced.

> 
> Do we need to fix the priority at this level ?

I do not think so. However, what can be done is implement interrupt
controller muting using the priority register, see:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting

-- 
					    Gilles.

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
> On 08/22/2012 06:04 PM, Romain Naour wrote:
>> Hello,
>>
>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos 
>> patch (ARB_SEL bits in PRIORITY register).
>> Is it intentional ?
>> It may be possible to give priority to an interrupt simultaneously 
>> arrived that the interruption IRQ_TIMER4 (before being grabbed by 
>> Adeos). Therefore, we can have more jitter for real time applications.
> 
> This can always happen even with interrupt priorities: imagine that the
> first interrupt happens 1 microsecond before the timer interrupt, even
> with the priority, the handler for first interrupt will be executed and
> the timer interrupt will have to wait for the end of this handler before
> it is serviced.
> 
>>
>> Do we need to fix the priority at this level ?
> 
> I do not think so. However, what can be done is implement interrupt
> controller muting using the priority register, see:
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting

Other things which could be done for s3c24xx are:
- convert the timers to clocksource/clockevent: since this platform is
the only one not to use clocksource/clockevent, we have to keep code
around for this case in xenomai-forge which could be removed. Having two
different timers for clocksource and clockevent would allow to avoid the
tsc emulation based on the decrementer, which I am not sure is really
reliable since the conversion to CONFIG_IPIPE_ARM_KUSER_TSC.
- failing that, check that the tsc emulation based on the decrementer
really works, and maybe fix it if it does not work. Or simply use a
different hardware timer for tsc emulation than for the timer.

-- 
					    Gilles.

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Romain Naour]

Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>> Hello,
>>>
>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>> patch (ARB_SEL bits in PRIORITY register).
>>> Is it intentional ?
>>> It may be possible to give priority to an interrupt simultaneously
>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>> Adeos). Therefore, we can have more jitter for real time applications.
>> This can always happen even with interrupt priorities: imagine that the
>> first interrupt happens 1 microsecond before the timer interrupt, even
>> with the priority, the handler for first interrupt will be executed and
>> the timer interrupt will have to wait for the end of this handler before
>> it is serviced.
>>
>>> Do we need to fix the priority at this level ?
>> I do not think so. However, what can be done is implement interrupt
>> controller muting using the priority register, see:
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
The priority register can't be used for implement interrupt controller 
muting using this method .
The PIC hardware can't be configured with only two priority levels.
We are obligated to choose between fixed or "rotation fashion" priority 
with 32 levels...

However, we can try to implement interrupt controller muting using 
bit-mask method.
But, bits mask are scattered between 4 registers:
32 bits in INTMSK (IRQ 16 to 47)
20 bits in EINTMASK (IRQ 48 to 67)
2 bits in LCDINTMSK (IRQ 68 and 69)
15 bits in INTSUBMSK (IRQ 70 to 84)
Fortunately there are only 69 interrupts.

> Other things which could be done for s3c24xx are:
> - convert the timers to clocksource/clockevent: since this platform is
> the only one not to use clocksource/clockevent, we have to keep code
> around for this case in xenomai-forge which could be removed. Having two
> different timers for clocksource and clockevent would allow to avoid the
> tsc emulation based on the decrementer, which I am not sure is really
> reliable since the conversion to CONFIG_IPIPE_ARM_KUSER_TSC.
> - failing that, check that the tsc emulation based on the decrementer
> really works, and maybe fix it if it does not work. Or simply use a
> different hardware timer for tsc emulation than for the timer.
>
I used Xenomai 2.6.0 with kernel 2.6.38.8 on mini2440 board during my 
internship.
I haven't seen bug with tsc emulation.

Xenomai-forge will not work on s3c24xx since it needs 
CONFIG_GENERIC_CLOCKEVENTS.

Regards,
Romain

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/23/2012 04:41 PM, Romain Naour wrote:
> Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
>> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>>> Hello,
>>>>
>>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>>> patch (ARB_SEL bits in PRIORITY register).
>>>> Is it intentional ?
>>>> It may be possible to give priority to an interrupt simultaneously
>>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>>> Adeos). Therefore, we can have more jitter for real time applications.
>>> This can always happen even with interrupt priorities: imagine that the
>>> first interrupt happens 1 microsecond before the timer interrupt, even
>>> with the priority, the handler for first interrupt will be executed and
>>> the timer interrupt will have to wait for the end of this handler before
>>> it is serviced.
>>>
>>>> Do we need to fix the priority at this level ?
>>> I do not think so. However, what can be done is implement interrupt
>>> controller muting using the priority register, see:
>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
> The priority register can't be used for implement interrupt controller 
> muting using this method .
> The PIC hardware can't be configured with only two priority levels.
> We are obligated to choose between fixed or "rotation fashion" priority 
> with 32 levels...

What prevents us from using the "fixed" priorities, with one level for
real-time interrupts and another for non real-time interrupts ?

> 
> However, we can try to implement interrupt controller muting using 
> bit-mask method.
> But, bits mask are scattered between 4 registers:
> 32 bits in INTMSK (IRQ 16 to 47)
> 20 bits in EINTMASK (IRQ 48 to 67)
> 2 bits in LCDINTMSK (IRQ 68 and 69)
> 15 bits in INTSUBMSK (IRQ 70 to 84)
> Fortunately there are only 69 interrupts.
> 
>> Other things which could be done for s3c24xx are:
>> - convert the timers to clocksource/clockevent: since this platform is
>> the only one not to use clocksource/clockevent, we have to keep code
>> around for this case in xenomai-forge which could be removed. Having two
>> different timers for clocksource and clockevent would allow to avoid the
>> tsc emulation based on the decrementer, which I am not sure is really
>> reliable since the conversion to CONFIG_IPIPE_ARM_KUSER_TSC.
>> - failing that, check that the tsc emulation based on the decrementer
>> really works, and maybe fix it if it does not work. Or simply use a
>> different hardware timer for tsc emulation than for the timer.
>>
> I used Xenomai 2.6.0 with kernel 2.6.38.8 on mini2440 board during my 
> internship.
> I haven't seen bug with tsc emulation.

To see if there is a bug, you should read the tsc, sleep for 30 minutes,
read the tsc again, and check if the difference corresponds to 30
minutes. Have you done that test?

> 
> Xenomai-forge will not work on s3c24xx since it needs 
> CONFIG_GENERIC_CLOCKEVENTS.

It currently works. But if someone could convert s3c24xx to clockevents,
we could remove the code allowing that.

-- 
					    Gilles.

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/23/2012 04:44 PM, Gilles Chanteperdrix wrote:
>>> - failing that, check that the tsc emulation based on the decrementer
>>> really works, and maybe fix it if it does not work. Or simply use a
>>> different hardware timer for tsc emulation than for the timer.
>>>
>> I used Xenomai 2.6.0 with kernel 2.6.38.8 on mini2440 board during my 
>> internship.
>> I haven't seen bug with tsc emulation.
> 
> To see if there is a bug, you should read the tsc, sleep for 30 minutes,
> read the tsc again, and check if the difference corresponds to 30
> minutes. Have you done that test?

With a latency test running in parallel.

-- 
					    Gilles.

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Romain Naour]

Le 23/08/2012 16:44, Gilles Chanteperdrix a écrit :
> On 08/23/2012 04:41 PM, Romain Naour wrote:
>> Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
>>> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>>>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>>>> Hello,
>>>>>
>>>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>>>> patch (ARB_SEL bits in PRIORITY register).
>>>>> Is it intentional ?
>>>>> It may be possible to give priority to an interrupt simultaneously
>>>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>>>> Adeos). Therefore, we can have more jitter for real time applications.
>>>> This can always happen even with interrupt priorities: imagine that the
>>>> first interrupt happens 1 microsecond before the timer interrupt, even
>>>> with the priority, the handler for first interrupt will be executed and
>>>> the timer interrupt will have to wait for the end of this handler before
>>>> it is serviced.
>>>>
>>>>> Do we need to fix the priority at this level ?
>>>> I do not think so. However, what can be done is implement interrupt
>>>> controller muting using the priority register, see:
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
>> The priority register can't be used for implement interrupt controller
>> muting using this method .
>> The PIC hardware can't be configured with only two priority levels.
>> We are obligated to choose between fixed or "rotation fashion" priority
>> with 32 levels...
> What prevents us from using the "fixed" priorities, with one level for
> real-time interrupts and another for non real-time interrupts ?
The priority register is used to configure the arbitration procedure 
when multiple interrupts occur.
But some interrupt sources always have higher priority than other.

For example, EINT0 is always takes priority regardless INT_RTC, when 
arrive at the same time.
Whatever the configuration of priority register.

When INT_TIMER4 is trigged, the value of priority register is modified.
Thus, INT_TIMER4 loses its priority for arbitration procedure.
That is why I wonder if it is better to fix the priority for arbitration 
procedure.
>> However, we can try to implement interrupt controller muting using
>> bit-mask method.
>> But, bits mask are scattered between 4 registers:
>> 32 bits in INTMSK (IRQ 16 to 47)
>> 20 bits in EINTMASK (IRQ 48 to 67)
>> 2 bits in LCDINTMSK (IRQ 68 and 69)
>> 15 bits in INTSUBMSK (IRQ 70 to 84)
>> Fortunately there are only 69 interrupts.
>>
>>> Other things which could be done for s3c24xx are:
>>> - convert the timers to clocksource/clockevent: since this platform is
>>> the only one not to use clocksource/clockevent, we have to keep code
>>> around for this case in xenomai-forge which could be removed. Having two
>>> different timers for clocksource and clockevent would allow to avoid the
>>> tsc emulation based on the decrementer, which I am not sure is really
>>> reliable since the conversion to CONFIG_IPIPE_ARM_KUSER_TSC.
>>> - failing that, check that the tsc emulation based on the decrementer
>>> really works, and maybe fix it if it does not work. Or simply use a
>>> different hardware timer for tsc emulation than for the timer.
>>>
>> I used Xenomai 2.6.0 with kernel 2.6.38.8 on mini2440 board during my
>> internship.
>> I haven't seen bug with tsc emulation.
> To see if there is a bug, you should read the tsc, sleep for 30 minutes,
> read the tsc again, and check if the difference corresponds to 30
> minutes. Have you done that test?
No, and I haven't the board right now.
>
>> Xenomai-forge will not work on s3c24xx since it needs
>> CONFIG_GENERIC_CLOCKEVENTS.
> It currently works. But if someone could convert s3c24xx to clockevents,
> we could remove the code allowing that.
>
I will see if i can do that.

Romain

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/23/2012 06:22 PM, Romain Naour wrote:

> Le 23/08/2012 16:44, Gilles Chanteperdrix a écrit :
>> On 08/23/2012 04:41 PM, Romain Naour wrote:
>>> Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
>>>> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>>>>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>>>>> patch (ARB_SEL bits in PRIORITY register).
>>>>>> Is it intentional ?
>>>>>> It may be possible to give priority to an interrupt simultaneously
>>>>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>>>>> Adeos). Therefore, we can have more jitter for real time applications.
>>>>> This can always happen even with interrupt priorities: imagine that the
>>>>> first interrupt happens 1 microsecond before the timer interrupt, even
>>>>> with the priority, the handler for first interrupt will be executed and
>>>>> the timer interrupt will have to wait for the end of this handler before
>>>>> it is serviced.
>>>>>
>>>>>> Do we need to fix the priority at this level ?
>>>>> I do not think so. However, what can be done is implement interrupt
>>>>> controller muting using the priority register, see:
>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
>>> The priority register can't be used for implement interrupt controller
>>> muting using this method .
>>> The PIC hardware can't be configured with only two priority levels.
>>> We are obligated to choose between fixed or "rotation fashion" priority
>>> with 32 levels...
>> What prevents us from using the "fixed" priorities, with one level for
>> real-time interrupts and another for non real-time interrupts ?
> The priority register is used to configure the arbitration procedure 
> when multiple interrupts occur.
> But some interrupt sources always have higher priority than other.
> 
> For example, EINT0 is always takes priority regardless INT_RTC, when 
> arrive at the same time.
> Whatever the configuration of priority register.
> 
> When INT_TIMER4 is trigged, the value of priority register is modified.
> Thus, INT_TIMER4 loses its priority for arbitration procedure.
> That is why I wonder if it is better to fix the priority for arbitration 
> procedure.


I don't get it, could you point me to the datasheet?

-- 
                                                                Gilles.

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Romain Naour]

Le 23/08/2012 19:53, Gilles Chanteperdrix a écrit :
> On 08/23/2012 06:22 PM, Romain Naour wrote:
>
>> Le 23/08/2012 16:44, Gilles Chanteperdrix a écrit :
>>> On 08/23/2012 04:41 PM, Romain Naour wrote:
>>>> Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
>>>>> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>>>>>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>>>>>> patch (ARB_SEL bits in PRIORITY register).
>>>>>>> Is it intentional ?
>>>>>>> It may be possible to give priority to an interrupt simultaneously
>>>>>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>>>>>> Adeos). Therefore, we can have more jitter for real time applications.
>>>>>> This can always happen even with interrupt priorities: imagine that the
>>>>>> first interrupt happens 1 microsecond before the timer interrupt, even
>>>>>> with the priority, the handler for first interrupt will be executed and
>>>>>> the timer interrupt will have to wait for the end of this handler before
>>>>>> it is serviced.
>>>>>>
>>>>>>> Do we need to fix the priority at this level ?
>>>>>> I do not think so. However, what can be done is implement interrupt
>>>>>> controller muting using the priority register, see:
>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
>>>> The priority register can't be used for implement interrupt controller
>>>> muting using this method .
>>>> The PIC hardware can't be configured with only two priority levels.
>>>> We are obligated to choose between fixed or "rotation fashion" priority
>>>> with 32 levels...
>>> What prevents us from using the "fixed" priorities, with one level for
>>> real-time interrupts and another for non real-time interrupts ?
>> The priority register is used to configure the arbitration procedure
>> when multiple interrupts occur.
>> But some interrupt sources always have higher priority than other.
>>
>> For example, EINT0 is always takes priority regardless INT_RTC, when
>> arrive at the same time.
>> Whatever the configuration of priority register.
>>
>> When INT_TIMER4 is trigged, the value of priority register is modified.
>> Thus, INT_TIMER4 loses its priority for arbitration procedure.
>> That is why I wonder if it is better to fix the priority for arbitration
>> procedure.
> I don't get it, could you point me to the datasheet?
>
In the figure 14-1, there is the Priority Generating Block (priority) 
between IRQ mask and INTPND register.
It is detailed in figure 14-2 and its functional principle is explained 
on the next page.
The priority of interrupt source is determined by the configuration of 
each arbiter.
This configuration is set by the priority register (P 14-13) which is 
left on initial state by Linux (0x7F).
(ARB_MODE = 1 for all arbiter)

"ARB_MODE bit is 1, ARB_SEL bits are changed in rotation fashion, e.g., 
if REQ1 is serviced, ARB_SEL bits are changed to 01b automatically so as 
to put REQ1 into the lowest priority"

"Note that REQ0 of an arbiter always has the highest priority, and REQ5 
has the lowest one."
For example, EINT0 always has the highest priority and INT_ADC has the 
lowest one.

I suggest to reset ARB_MODE for all arbiter and modify ARB6 (01b) and 
ARB2 (11b), in order to increase and fix INT_TIMER4's priority'.
This is all what we can do with this register. Tell me if I'm wrong.

Regards,
Romain

Re: [Xenomai] s3c24xx: Priority rotate enable !?

[Gilles Chanteperdrix]

On 08/24/2012 02:51 PM, Romain Naour wrote:
> Le 23/08/2012 19:53, Gilles Chanteperdrix a écrit :
>> On 08/23/2012 06:22 PM, Romain Naour wrote:
>>
>>> Le 23/08/2012 16:44, Gilles Chanteperdrix a écrit :
>>>> On 08/23/2012 04:41 PM, Romain Naour wrote:
>>>>> Le 23/08/2012 10:07, Gilles Chanteperdrix a écrit :
>>>>>> On 08/22/2012 06:21 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 08/22/2012 06:04 PM, Romain Naour wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On s3c24xx processors the interrupt source priority isn't fixed by Adeos
>>>>>>>> patch (ARB_SEL bits in PRIORITY register).
>>>>>>>> Is it intentional ?
>>>>>>>> It may be possible to give priority to an interrupt simultaneously
>>>>>>>> arrived that the interruption IRQ_TIMER4 (before being grabbed by
>>>>>>>> Adeos). Therefore, we can have more jitter for real time applications.
>>>>>>> This can always happen even with interrupt priorities: imagine that the
>>>>>>> first interrupt happens 1 microsecond before the timer interrupt, even
>>>>>>> with the priority, the handler for first interrupt will be executed and
>>>>>>> the timer interrupt will have to wait for the end of this handler before
>>>>>>> it is serviced.
>>>>>>>
>>>>>>>> Do we need to fix the priority at this level ?
>>>>>>> I do not think so. However, what can be done is implement interrupt
>>>>>>> controller muting using the priority register, see:
>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Priority_based_interrupt_controller_muting
>>>>> The priority register can't be used for implement interrupt controller
>>>>> muting using this method .
>>>>> The PIC hardware can't be configured with only two priority levels.
>>>>> We are obligated to choose between fixed or "rotation fashion" priority
>>>>> with 32 levels...
>>>> What prevents us from using the "fixed" priorities, with one level for
>>>> real-time interrupts and another for non real-time interrupts ?
>>> The priority register is used to configure the arbitration procedure
>>> when multiple interrupts occur.
>>> But some interrupt sources always have higher priority than other.
>>>
>>> For example, EINT0 is always takes priority regardless INT_RTC, when
>>> arrive at the same time.
>>> Whatever the configuration of priority register.
>>>
>>> When INT_TIMER4 is trigged, the value of priority register is modified.
>>> Thus, INT_TIMER4 loses its priority for arbitration procedure.
>>> That is why I wonder if it is better to fix the priority for arbitration
>>> procedure.
>> I don't get it, could you point me to the datasheet?
>>
> In the figure 14-1, there is the Priority Generating Block (priority) 
> between IRQ mask and INTPND register.
> It is detailed in figure 14-2 and its functional principle is explained 
> on the next page.
> The priority of interrupt source is determined by the configuration of 
> each arbiter.
> This configuration is set by the priority register (P 14-13) which is 
> left on initial state by Linux (0x7F).
> (ARB_MODE = 1 for all arbiter)
> 
> "ARB_MODE bit is 1, ARB_SEL bits are changed in rotation fashion, e.g., 
> if REQ1 is serviced, ARB_SEL bits are changed to 01b automatically so as 
> to put REQ1 into the lowest priority"
> 
> "Note that REQ0 of an arbiter always has the highest priority, and REQ5 
> has the lowest one."
> For example, EINT0 always has the highest priority and INT_ADC has the 
> lowest one.
> 
> I suggest to reset ARB_MODE for all arbiter and modify ARB6 (01b) and 
> ARB2 (11b), in order to increase and fix INT_TIMER4's priority'.
> This is all what we can do with this register. Tell me if I'm wrong.

Ok, what I asked was for the URL of the datasheet, but I found it. No,
you will not gain much with this register, you would better implement
interrupt controller muting.

-- 
					    Gilles.