Jon Hunter <jonath...@nvidia.com> writes: > Some IRQ chips may be located in a power domain outside of the CPU subsystem > and hence will require device specific runtime power management. Ideally, > rather than adding more functions to the irq_chip_ops function table, using > existing chip functions such as irq_startup/shutdown or > irq_request/release_resources() would be best. However, these existing chip > functions are called in the context of a spinlock which is not ideal for > power management operations that may take some time to power up a domain. > > Two possible solutions are: > 1. Move existing chip operators such as irq_request/release_resources() > outside of the spinlock and use these helpers. > 2. Add new chip operators that are called outside of any spinlocks while > setting up and freeing an IRQ.
> Not knowing whether we can safely move irq_request/release_resources() to > outside the spinlock (but hopefully this will solicit some feedback), add > new chip operators for runtime resuming and suspending of an IRQ chip. I'm not quite seeing how this would connect to the actual hardware power domain (presumabaly managed by genpd) and any other devices in that domain (presumably managed by runtime PM.) If all the RPM devices in the domain go idle, it will be powered off independently of the status of the irqchip because the irqchip isn't using RPM. Is there a longer-term plan to handle the irqchips as a "normal" device and use RPM? IMO, that approach would be helpful even for irqchips that share power domains with CPUs, since there are efforts working towards using genpd/RPM to manage CPUs/clusters. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
