[RFC,v2,04/10] ARM: vexpress: Extend UART with FIQ support

This patch provides the UART with a second interrupt resource that can
be used to route the UARTs interrupt to FIQ. The size of the interrupt
map is doubled and new mappings for the FIQ shadows added (demarked by
setting bit 7 in the final item in the tuple).

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: devicetree@vger.kernel.org
---
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi     |  8 ++++----
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 10 ++++++++--
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  |  8 +++++++-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts     | 10 ++++++++--
 4 files changed, 27 insertions(+), 9 deletions(-)

On Fri, May 23, 2014 at 02:57:52PM +0100, Daniel Thompson wrote:
> @@ -140,7 +140,7 @@
>  			v2m_serial0: uart@090000 {
>  				compatible = "arm,pl011", "arm,primecell";
>  				reg = <0x090000 0x1000>;
> -				interrupts = <5>;
> +				interrupts = <5>, <69>;

NAK.  This is obviously a Linux implementation detail - the second
number is your "FIQ" number which you've decided will be offset by
64.

On 23/05/14 16:04, Russell King - ARM Linux wrote:
> On Fri, May 23, 2014 at 02:57:52PM +0100, Daniel Thompson wrote:
>> @@ -140,7 +140,7 @@
>>  			v2m_serial0: uart@090000 {
>>  				compatible = "arm,pl011", "arm,primecell";
>>  				reg = <0x090000 0x1000>;
>> -				interrupts = <5>;
>> +				interrupts = <5>, <69>;
> 
> NAK.  This is obviously a Linux implementation detail - the second
> number is your "FIQ" number which you've decided will be offset by
> 64.

Certainly the offset of 64 is a more or less meaningless magic number
that I decided on, however I don't think it originates within Linux. It
is both introduced and consumed within the device tree itself.

I've proposed adding a flag to the gic bindings to mark a FIQ; the GIC
calls interrupt 69 (above) <0 5 0x84> (where 0x80 is the flag to request
FIQ routing alongside 0x04 which is the trigger type).

However vexpress-a15 has an interrupt-map between the UART and the GIC.
Thus far I've not found a way, other by offset, to allow a UART sitting
on a child bus to be provided with both IRQ and FIQ versions of an
interrupt.

> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -233,7 +233,7 @@
>  			 <5 0 0 0x10000000 0x04000000>;
>  
>  		#interrupt-cells = <1>;
> -		interrupt-map-mask = <0 0 63>;
> +		interrupt-map-mask = <0 0 127>;
                                         ^^^^^

The 64 offset is introduced here. Nothing in Linux imposes anything on
the value (I originally had the shadow routings from 59 to 63 and this
also worked).

My code may still be inappropriate but, right now, I'm unsure whether
the proposed changes to the gic bindings are included in the NAK, not in
the NAK or whether they sit in the middle ground where I have to provide
better argumentation.


Daniel.

On Thu, May 29, 2014 at 5:31 AM, Daniel Thompson
<daniel.thompson@linaro.org> wrote:
> On 23/05/14 16:04, Russell King - ARM Linux wrote:
>> On Fri, May 23, 2014 at 02:57:52PM +0100, Daniel Thompson wrote:
>>> @@ -140,7 +140,7 @@
>>>                      v2m_serial0: uart@090000 {
>>>                              compatible = "arm,pl011", "arm,primecell";
>>>                              reg = <0x090000 0x1000>;
>>> -                            interrupts = <5>;
>>> +                            interrupts = <5>, <69>;
>>
>> NAK.  This is obviously a Linux implementation detail - the second
>> number is your "FIQ" number which you've decided will be offset by
>> 64.

+1

> Certainly the offset of 64 is a more or less meaningless magic number
> that I decided on, however I don't think it originates within Linux. It
> is both introduced and consumed within the device tree itself.
>
> I've proposed adding a flag to the gic bindings to mark a FIQ; the GIC
> calls interrupt 69 (above) <0 5 0x84> (where 0x80 is the flag to request
> FIQ routing alongside 0x04 which is the trigger type).

That would be better than the magic number, but I'm not convinced that
belongs in the DT either.

Whether the uart uses FIQ is not dependent on this DT setting, but
based on whether the user wants to use the uart for kdb or not. You
have enough information already to figure out which interrupt. What's
missing is whether you have the capability to use FIQ or not. I don't
recall if you can tell that from the GIC or not.

Rob

On 29/05/14 14:44, Rob Herring wrote:
> On Thu, May 29, 2014 at 5:31 AM, Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
>> On 23/05/14 16:04, Russell King - ARM Linux wrote:
>>> On Fri, May 23, 2014 at 02:57:52PM +0100, Daniel Thompson wrote:
>>>> @@ -140,7 +140,7 @@
>>>>                      v2m_serial0: uart@090000 {
>>>>                              compatible = "arm,pl011", "arm,primecell";
>>>>                              reg = <0x090000 0x1000>;
>>>> -                            interrupts = <5>;
>>>> +                            interrupts = <5>, <69>;
>>>
>>> NAK.  This is obviously a Linux implementation detail - the second
>>> number is your "FIQ" number which you've decided will be offset by
>>> 64.
> 
> +1
> 
>> Certainly the offset of 64 is a more or less meaningless magic number
>> that I decided on, however I don't think it originates within Linux. It
>> is both introduced and consumed within the device tree itself.
>>
>> I've proposed adding a flag to the gic bindings to mark a FIQ; the GIC
>> calls interrupt 69 (above) <0 5 0x84> (where 0x80 is the flag to request
>> FIQ routing alongside 0x04 which is the trigger type).
> 
> That would be better than the magic number, but I'm not convinced that
> belongs in the DT either.
> 
> Whether the uart uses FIQ is not dependent on this DT setting, but
> based on whether the user wants to use the uart for kdb or not. You
> have enough information already to figure out which interrupt. What's
> missing is whether you have the capability to use FIQ or not. I don't
> recall if you can tell that from the GIC or not.

Ok.

I've just started playing with an idea that keeps the shadow virqw for
FIQ idea but doesn't require any device tree changes...

Another RFC will follow in due course.


Daniel.