[PATCH] mmp: irq: Don't clear unused interrupt enable bits

Eric Miao eric.y.miao at gmail.com
Sat Jun 29 00:55:03 EDT 2013


On Fri, Jun 28, 2013 at 10:24 PM, Daniel Drake <dsd at laptop.org> wrote:
> On Thu, Jun 27, 2013 at 11:15 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
>> Is there any way to check this at run-time or at least by boot parameters?
>
> The only thing that occurs to me would be checking for the device tree
> node that corresponds to our input serio. But doing that from platform
> code would be horrible, and it would also be nasty doing it from the
> input driver.

I think that should be OK and clean, e.g.

  if (of_property_read_bool(np, "irq-route-to-sp")) {
     ....
  }

I'm fine with leaving these bits out as your patch does, the only concern
is some other code may have a chance to depend on this, and may
benefit from this boot configuration flexibility as well.

>
>> Decide whether the interrupt gets delivered to SP seems to be a choice
>> that the main CPU should be doing, as well as the interrupt priority.
>
> Incidentally the main CPU does make these choices - just before Linux
> has booted.
>
> While Linux has no interaction with the SP (it is not even aware of
> it), I would say not stomping on its configuration is an OK policy to
> have.
>
>> And this is really all about bit 4 right?
>
> Yes, bit 4 is the crucial one, it is required for the OLPC inbuilt
> keyboard/touchpad to work.
>
> However on numerous occasions during interactions with Marvell they
> have stressed the importance of setting interrupt priorities on
> interrupts used for wakeups. We don't think it makes a difference for
> the issues that we have seen, but we do not ignore the request. As
> that cannot be done in Linux, we do it in the firmware, and it seems
> like while Linux does not work with interrupt priorities it should not
> overwite any earlier setup.

Haojian & Mingliang, could you help check this is the case, and that no
known driver (including those for upstream) is depending on this behavior?

>
> Daniel



More information about the linux-arm-kernel mailing list