From mboxrd@z Thu Jan 1 00:00:00 1970 References: <561568AE.30109@xenomai.org> <56156AB4.2080705@xenomai.org> <56161232.50803@xenomai.org> <20151008144340.GE21923@csclub.uwaterloo.ca> <5616838F.7030507@xenomai.org> <20151008151744.GG21923@csclub.uwaterloo.ca> From: Philippe Gerum Message-ID: <56168EB5.10104@xenomai.org> Date: Thu, 8 Oct 2015 17:41:41 +0200 MIME-Version: 1.0 In-Reply-To: <20151008151744.GG21923@csclub.uwaterloo.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: "Xenomai@xenomai.org" On 10/08/2015 05:17 PM, Lennart Sorensen wrote: > On Thu, Oct 08, 2015 at 04:54:07PM +0200, Philippe Gerum wrote: >> I could not find one that would not look weird. That logic is deeply >> buried in kernel space, and introducing a dynamic dependency on whether >> e.g. the PCI layer has to be traversed for carrying out such ops would >> be rather confusing for the end user, especially when porting the >> application code over different SoCs. > > Yep, that sounds ugly. > >> Likely, yes. The relevant handlers dealing with the interrupt controller >> of the QUICC Engine do not tread on problematic code, so this should be >> ok for this platform. > > Then I have the icky situation that we want the same kernel source to > run on arm. I wonder if the am572x would care. I guess I could #ifdef > it for powerpc only and leave the new way on arm. > No guarantee, I only had a quick look at this, but AFAICS: - the irqchip from the PCA953X gpio extender module does not seem to have any requirement for running over a regular kernel context - the main GIC IRQ controller is fine, since the fast ack code we use over the head domain is shared with the IRQ enabling/disabling support. So this should be ok (famous last words). -- Philippe.