On 2011-01-18 18:37, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> On 2011-01-18 18:27, Philippe Gerum wrote: >>> On Tue, 2011-01-18 at 18:22 +0100, Jan Kiszka wrote: >>>> On 2011-01-18 18:13, Philippe Gerum wrote: >>>>> On Thu, 2010-11-25 at 17:33 +0100, Jan Kiszka wrote: >>>>>> The following changes since commit >>>>>> 4c83ab8e3ac5b194695e38bbc253f78e6072ad24: >>>>>> >>>>>> ipipe: tell __ipipe_run_irqtail about the latest IRQ number >>>>>> (2010-11-05 13:52:55 +0100) >>>>>> >>>>>> are available in the git repository at: >>>>>> git://git.kiszka.org/ipipe-2.6 queues/2.6.35-noarch >>>>>> >>>>>> [edited log] >>>>>> Jan Kiszka (4): >>>>>> ipipe: Provide wrapper for IRQ mask/unmask at chip level >>>>> Could you give me some hints about the intended usage of these? >>>> The idea was (and still is but effort stalled ATM) to emulate MSI >>>> masking on top of that. >>> Ok, let's keep this on the shelf until we come with a complete solution. >>> I suspect we will have to resync the Xenomai and I-pipe interfaces to >>> this end. >> >> Definitely. So the patch was intended as a starting point, enbling >> refactoring on Xenomai side. Quite a lot of work is actually to be done >> on the rthal, also to clean up lots of duplicate irq descriptor >> translations over there. > > As a maintainer of low end architectures, I am not too fond with > introducing one more level of function pointers. A substantial part of > the worst case interrupt latency on ARM is spent in these routines, so, > it would be nice if we could avoid make this even longer. And still on > ARM, acking/masking an interrupt line is just about writing some bit to > some MMIO memory, so, the cost of the function pointer is definitely not > negligible.
Then we need to push the definition of ipipe_irq_chip_[un]mask into arch hands and effectively keep it for those setups as is which do not need more. But we do need this abstraction. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
