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


Groups > linux.kernel > #1447235

Re: SOC-specific action for irq_set_wake

From Marc Zyngier <marc.zyngier@arm.com>
Newsgroups linux.kernel
Subject Re: SOC-specific action for irq_set_wake
Date 2016-07-20 15:40 +0200
Message-ID <rWZTb-21W-11@gated-at.bofh.it> (permalink)
References <rWLZU-1uE-15@gated-at.bofh.it> <rWLZU-1uE-13@gated-at.bofh.it> <rWUTv-7mO-9@gated-at.bofh.it> <rWUTv-7mO-7@gated-at.bofh.it> <rWZzP-1Ui-5@gated-at.bofh.it>
Organization ARM Ltd

Show all headers | View raw


Hi Sören,

On 20/07/16 14:16, Sören Brinkmann wrote:
> Hi Marc,

>>>>> Does anybody have similar problems and probably already solved it?
>>>>> Any other suggestions for approaching the problem? Any preferred
>>>>> solution?
>>>>
>>>> I think we have the same problem.  Can you provide more detail on the hardware
>>>> implementation of your wake irq controller?  I presume you have some set of
>>>> registers, an irq maybe, and some other stuff?  And how does it fit into the
>>>> overall architecture from a hardware perspective?
>>>
>>> We have essentially a whole second interrupt controller. All IRQs are
>>> connected to the A53 GIC and this second interrupt controller that is
>>> controlled by the companion core. The companion core is supposed to be
>>> informed about what source the A53 needs to wake up on and will program
>>> this second IRQ controller, etc.
>>
>> So your "special case" is exactly like everyone else's. Implement it as
>> a hierarchical chip on top of the GIC, just like Tegra, OMAP, iMX6,
>> Exynos and a few others. Unless you implement PSCI.
> 
> I didn't really think that our case is unique. I was just looking for
> some pointers into the right direction as the extension mechanism that I
> remembered disappeared and I haven't been following the development
> closely enough to just know what alternatives are available.
> So, you say the approach of letting the secure monitor infer the wake
> IRQ by reading the GIC config is preferred over handling it as
> hierarchical chip within Linux?

The in-kernel approach is a consequence of the firmware-less 32bit
configuration. Hopefully, we won't see anything like that anymore.
Fingers crossed.

So the firmware approach is clearly the preferred one on arm64, as it
simplifies absolutely everything (and your power management has to know
about all of this anyway).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: SOC-specific action for irq_set_wake Andy Gross <andy.gross@linaro.org> - 2016-07-20 00:50 +0200
  Re: SOC-specific action for irq_set_wake Thomas Gleixner <tglx@linutronix.de> - 2016-07-20 08:50 +0200
  Re: SOC-specific action for irq_set_wake Marc Zyngier <marc.zyngier@arm.com> - 2016-07-20 10:20 +0200
    Re: SOC-specific action for irq_set_wake Sören Brinkmann <soren.brinkmann@xilinx.com> - 2016-07-20 15:20 +0200
      Re: SOC-specific action for irq_set_wake Andy Gross <andy.gross@linaro.org> - 2016-07-20 15:30 +0200
      Re: SOC-specific action for irq_set_wake Marc Zyngier <marc.zyngier@arm.com> - 2016-07-20 15:40 +0200

csiph-web