From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 8 Nov 2015 18:45:12 +0100 From: Gilles Chanteperdrix Message-ID: <20151108174512.GT1798@hermes.click-hack.org> References: <20151104070414.GD24848@hermes.click-hack.org> <20151108084205.GG1798@hermes.click-hack.org> <20151108171031.GR1798@hermes.click-hack.org> <20151108172614.GS1798@hermes.click-hack.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Xenomai] Support for Raspberry PI 2 B List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mathieu Rondonneau Cc: xenomai@xenomai.org On Sun, Nov 08, 2015 at 09:36:16AM -0800, Mathieu Rondonneau wrote: > On 15-11-08 09:26 AM, Gilles Chanteperdrix wrote: > > On Sun, Nov 08, 2015 at 09:20:47AM -0800, Mathieu Rondonneau wrote: > >> On 15-11-08 09:10 AM, Gilles Chanteperdrix wrote: > >>> On Sun, Nov 08, 2015 at 09:04:38AM -0800, Mathieu Rondonneau wrote: > >>>> On 15-11-08 12:42 AM, Gilles Chanteperdrix wrote: > >>>>> On Sat, Nov 07, 2015 at 09:55:48PM -0800, Mathieu Rondonneau wrote: > >>>>>> On 15-11-04 10:08 PM, Mathieu Rondonneau wrote: > >>>>>>> On 15-11-04 04:51 PM, Mathieu Rondonneau wrote: > >>>>>>>> On 15-11-03 11:04 PM, Gilles Chanteperdrix wrote: > >>>>>>>>> On Tue, Nov 03, 2015 at 07:18:37PM -0800, Mathieu Rondonneau wr= ote: > >>>>>>>>>> On 15-11-02 07:15 AM, Philippe Gerum wrote: > >>>>>>>>>>> On 11/02/2015 06:23 AM, Mathieu Rondonneau wrote: > >>>>>>>>>>>> On 15-11-01 07:21 PM, Mathieu Rondonneau wrote: > >>>>>>>>>>>>> On 15-11-01 06:58 PM, Mathieu Rondonneau wrote: > >>>>>>>>>>>>>> On 15-10-31 08:58 PM, Mathieu Rondonneau wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> irq handlers registered with devm_request_threaded_irq do= es not > >>>>>>>>>>>>>>> get > >>>>>>>>>>>>>>> triggered when interrupt fires. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The mmc driver uses this (can not load the rootfs). > >>>>>>>>>>>>>>> Only the IPIPE patch is enabled. > >>>>>>>>>>>>>>> the armctrl chipirq is triggering the .ack handler instea= d so the > >>>>>>>>>>>>>>> interrupt is happening. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Any suggestion on where I should look? how is this suppor= ted by > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> ipipe layer? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> -Mathieu > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think I might have answered my own question. > >>>>>>>>>>>>>> Looks like I need to use ipipe_request_irq() instead. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> -Mathieu > >>>>>>>>>>>>> mmmm it is not true, it seems we still need a > >>>>>>>>>>>>> ipipe_request_threaded_irq() to call the ackfn, put the han= dler in > >>>>>>>>>>>>> the > >>>>>>>>>>>>> queue and wake up the thread once handler is executed. Or u= ser > >>>>>>>>>>>>> will have > >>>>>>>>>>>>> to move this functionality into their driver's IRQ handler. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It strangely looks like ipipe_request_irq's idea is similar= to what > >>>>>>>>>>>>> request_threaded_irq is already doing (delaying IRQ process= later). > >>>>>>>>>>>>> > >>>>>>>>>>>>> -Mathieu > >>>>>>>>>>>> Looks like my bigger problem is that the handler_level_irq i= s not > >>>>>>>>>>>> called. Only the timer handler is called (handler_percpu_dev= id_irq). > >>>>>>>>>>> > >>>>>>>>>>> Which may mean that the regular IRQ top half for that interru= pt source > >>>>>>>>>>> is not connected to the pipeline. You may want to check wheth= er the > >>>>>>>>>>> irqchip handling that device's IRQs has been made aware of the > >>>>>>>>>>> interrupt > >>>>>>>>>>> pipeline. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks for replying Philippe, > >>>>>>>>>> This is the think, I did change the arch_irq_default_handler t= o call > >>>>>>>>>> the > >>>>>>>>>> __ipipe_grab_irq and __ipipe_grab_ipi. > >>>>>>>>>> Is that what you are referring to when you say "interrupt sour= ce is not > >>>>>>>>>> connected to the pipile", that's what __ipipe_grab_xxx does is= n't it? > >>>>>>>>>> > >>>>>>>>>> Obviously I am still missing something. > >>>>>>>>>> If I use irq_set_chained_handler in the driver then the handle= r gets > >>>>>>>>>> called but it's just replacing the handler_irq by the driver o= ne. > >>>>>>>>>> When I use request_irq then it does not call my handler (the > >>>>>>>>>> action.handler one). > >>>>>>>>>> I will keep looking. > >>>>>>>>> > >>>>>>>>> This is explained here: > >>>>>>>>> http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new= -arm-soc/#GPIOs_as_interrupt_sources > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> and here: > >>>>>>>>> http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new= -arm-soc/#CONFIG_MULTI_IRQ_HANDLER > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Chained handlers have to call ipipe_handle_demuxed_irq instead = of > >>>>>>>>> generic_handle_irq. > >>>>>>>>> And the arch irq handler has to call ipipe_handle_multi_irq or > >>>>>>>>> ipipe_handle_multi_ipi instead of handle_IRQ > >>>>>>>>> > >>>>>>>> > >>>>>>>> Thanks Gilles for the pointers, > >>>>>>>> MULTI_IRQ_HANDLER is not enabled for RPI2 (so I did not look at = the > >>>>>>>> multi_irq_handler section), is it a requirement for the ipipe pa= tch to > >>>>>>>> work? > >>>>>>>> > >>>>>>>> For GPIO I got it to work, but it is easier to me because they h= ave > >>>>>>>> their own irqchip. > >>>>>>>> It is the arch irq handler that cause me trouble. > >>>>>>>> > >>>>>>>> Maybe I just have to enable MULTI_IRQ_HANDLER. > >>>>>>>> I will play around with it. > >>>>>>>> > >>>>>>>> Thanks again for your feedback, it helps, > >>>>>>>> Regards, > >>>>>>>> -Mathieu > >>>>>>>> > >>>>>>>> > >>>>>>> Also confirming that the ipipe_handler_multi_irq and > >>>>>>> ipipe_handler_multi_ipi are called properly. > >>>>>>> so it looks like the arch irq handler is working as expected. > >>>>>>> > >>>>>>> it is the handle_level_irq that is not called properly when I use= the > >>>>>>> request_irq in the driver. > >>>>>>> the desc->irq_data.chip->irq_ack is called properly but not the > >>>>>>> irqaction->handler (that is the handler of my driver) that should= have > >>>>>>> been triggered by handle_level_irq. > >>>>>>> > >>>>>>> So I think my problem is that handle_level_irq() is not called. > >>>>>>> if I register my driver handler with irq_set_chained_handler then > >>>>>>> ipipe_handler_multi_irq is still called, but the > >>>>>>> desc->irq_data.chip->irq_ack does not get called and my driver ha= ndle > >>>>>>> gets called properly. > >>>>>>> In this case, the ipipe is bypassed it seems since if I understand > >>>>>>> correctly, the irq_ack is still expected to trigger. > >>>>>>> > >>>>>>> Maybe I am missing a ipipe_handle_demuxed_irq call in an interrupt > >>>>>>> handler that gets called before my driver interrupt handler gets a > >>>>>>> chance to get called. > >>>>>>> > >>>>>>> I have to look at what interrupt happens before mine. > >>>>>>> > >>>>>>> -Mathieu > >>>>>> > >>>>>> more info: > >>>>>> 1) interrupt (lets say #I) triggers, the ipipe_dispatch_irq calls = the > >>>>>> irqchip->mask() which calls ipipe_lock_irq (IPIPE_LOCK_FLAG is now > >>>>>> set). > >>>>> > >>>>> it should not call irqchip->mask, but irqchip->ipipe_ack, which > >>>>> should not call ipipe_lock_irq. See for instance the documentation > >>>>> about fasteoi irq: > >>>>> http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm= -soc/#flow_handler > >>>>> > >>>> > >>>> Gilles, thanks again for you response, > >>>> the code (and execution path observed) does not seem to match with w= hat > >>>> you are saying (please don't take this the wrong way :)), please help > >>>> clarifying. See explanation below: > >>>> > >>>> From the doc: > >>>> "the irq_mask handler should call ipipe_lock_irq before accessing the > >>>> interrupt controller registers" > >>>> So I did put a ipipe_lock_irq in the irq_mask. > >>> > >>> The documentation also says: > >>> "If the flow handler is =93handle_fasteoi_irq=94 the implementation of > >>> the =93struct irq_chip=94 members should be modified:" > >>> and > >>> an irq_hold handler should be added (when CONFIG_IPIPE is enabled) > >>> having the same effect as the irq_mask handler (but without the > >>> call to ipipe_lock_irq), and the irq_eoi handler. > >>> > >>> In which case the irq_hold handler is called upon handling the > >>> interrupt. > >>> > >>> You can not just apply half of what the documentation says and hope > >>> to have a working system. > >>> > >> > >> But I don't use handle_fasteoi_irq, I use handle_level_irq. > > > > Exactly my point. > > >=20 > ok so you are saying, that for handle_level_irq, do not add the=20 > ipipe_lock_irq in the irq_mask? > Can you confirm this? > Does it mean for handle_level_irq, the irq_hold and irq_release are not=20 > needed as well. > Ok this is the part I did not understood from the doc then. I think this = > could be clarified in the doc. (more clarification does not hurt). The doc looks clear enough to me. It says: if condition, then=20 do 1 do 2 do 3 if condition is not true, there is no reason to do 1, 2, or 3. perhaps you want me to add else do nothing ? As a C programmer, do you put,=20 else ; To all your ifs with no else ? >=20 > Just to confirm, you were saying "it should not call irqchip->mask, but=20 > irqchip->ipipe_ack". > But for handle_level_irq the mask and the ack are called. > Is that correct? The answer is in the implementation of ipipe_ack for level interrupts. It calls mask_ack_irq. >=20 > I think understand what my mistake was. > I have not tested it yet but without the irq_lock, it should call the=20 > handler. > Thank you Gilles again! You are welcome. I suggest however to take the time to read the documentation completely from beginning to end, before jumping head-on in the port, only reading parts of it, and wasting time stupidly because you only read part of a sentence. --=20 Gilles. https://click-hack.org