From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <503658B3.9060401@openwide.fr> Date: Thu, 23 Aug 2012 18:22:11 +0200 From: Romain Naour MIME-Version: 1.0 References: <50350308.8010405@openwide.fr> <50350712.4020704@xenomai.org> <5035E4CD.9080302@xenomai.org> <50364114.9090804@openwide.fr> <503641EA.2020201@xenomai.org> In-Reply-To: <503641EA.2020201@xenomai.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Xenomai] s3c24xx: Priority rotate enable !? List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Le 23/08/2012 16:44, Gilles Chanteperdrix a =C3=A9crit : > On 08/23/2012 04:41 PM, Romain Naour wrote: >> Le 23/08/2012 10:07, Gilles Chanteperdrix a =C3=A9crit : >>> 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 applicatio= ns. >>>> This can always happen even with interrupt priorities: imagine that = the >>>> first interrupt happens 1 microsecond before the timer interrupt, ev= en >>>> 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 be= fore >>>> 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_bas= ed_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" priorit= y >> 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=20 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=20 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=20 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 i= s >>> 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