Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1413681 > unrolled thread

Re: [PATCH V4 3/9] irqdomain: Don't set type when mapping an IRQ

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V4 3/9] irqdomain: Don't set type when mapping an IRQ Marc Zyngier <marc.zyngier@arm.com> - 2016-06-04 12:00 +0200

#1413681 — Re: [PATCH V4 3/9] irqdomain: Don't set type when mapping an IRQ

On Thu, 12 May 2016 16:19:26 +0100
Jon Hunter <jonathanh@nvidia.com> wrote:

> Some IRQ chips, such as GPIO controllers or secondary level interrupt
> controllers, may require require additional runtime power management
> control to ensure they are accessible. For such IRQ chips, it makes sense
> to enable the IRQ chip when interrupts are requested and disabled them
> again once all interrupts have been freed.
> 
> When mapping an IRQ, the IRQ type settings are read and then programmed.
> The mapping of the IRQ happens before the IRQ is requested and so the
> programming of the type settings occurs before the IRQ is requested. This
> is a problem for IRQ chips that require additional power management
> control because they may not be accessible yet. Therefore, when mapping
> the IRQ, don't program the type settings, just save them and then program
> these saved settings when the IRQ is requested (so long as if they are not
> overridden via the call to request the IRQ).
> 
> Add a stub function for irq_domain_free_irqs() to avoid any compilation
> errors when CONFIG_IRQ_DOMAIN_HIERARCHY is not selected.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>

As discussed just before the 4.7 merge window, this patch is going to
uncover quite a few broken configurations (the main one being the PPI
triggers for the ARM architected timer, which seems to be wrong on a lot
of different platforms).

I'm proposing to put this patch[1] in the same queue in order to
uncover the guilty ones, but we have to be prepared for more breakage
(I've also identified kvmtool as a sinner).

Thanks,

	M.
[1] https://lkml.org/lkml/2016/5/9/546
-- 
Jazz is not dead. It just smells funny.

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web