linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: phorton@bitbox.co.uk (Peter Horton)
To: linux-arm-kernel@lists.infradead.org
Subject: MX51: add FIQ support for TZIC
Date: Thu, 25 Nov 2010 23:30:28 +0000	[thread overview]
Message-ID: <4CEEF194.9010707@bitbox.co.uk> (raw)
In-Reply-To: <20101125203819.GK4693@pengutronix.de>

On 25/11/2010 20:38, Uwe Kleine-K?nig wrote:
>
> On Thu, Nov 25, 2010 at 03:19:09PM +0000, Peter Horton wrote:
>> Add support for FIQ on MX51 TZIC.
>>
>> (patch is against Sascha's "imx-for-2.6.38" branch)
> <nitpick>The comment about which tree this applies to isn't of interest
> anymore when the patch is applied, so better write it after the triple
> (eww, double?) dash below.  Then it won't make it into git.</nitpick>
>
>> Signed-off-by: Peter Horton<phorton@bitbox.co.uk>
>>
>> --
>>
> Back some time I tried to achieve something similar.  IIRC my patch was
> easier.  I definitly didn't patch entry-macro.S.  But OTOH I had some
> problems with it so this might have been my problem.  I cannot find it
> at the moment, will talk to Sascha tomorrow about it.
>

There is a tiny window where the interrupt entry code reads the HIPND 
register and can see a pending FIQ. This can cause the interrupt code to 
pick up the FIQ interrupt number rather than the requesting interrupt 
number which results in the kernel's interrupt handler disabling the FIQ 
(as an interrupt without a handler).

When playing audio using the FIQ this happens after a few seconds 
without the attached entry macro fix.

>> diff --git a/arch/arm/plat-mxc/include/mach/entry-macro.S b/arch/arm/plat-mxc/include/mach/entry-macro.S
>> index aeb0869..c7dd4a9 100644
>> --- a/arch/arm/plat-mxc/include/mach/entry-macro.S
>> +++ b/arch/arm/plat-mxc/include/mach/entry-macro.S
>> @@ -54,8 +54,18 @@
>>   #elif defined CONFIG_MXC_TZIC
>>   	@ Load offset&  priority of the highest priority
>>   	@ interrupt pending.
>> +	@ 0x080 is INTSEC0 register
>>   	@ 0xD80 is HIPND0 register
>>   	mov     \irqnr, #0
>> +#ifdef CONFIG_FIQ
>> +1000:
>> +	add	\irqstat, \base, \irqnr, lsr #3
>> +	ldr	\tmp, [\irqstat, #0xd80]
>> +	ldr	\irqstat, [\irqstat, #0x080]
>> +	ands	\tmp, \tmp, \irqstat
>> +	bne	1001f
>> +	add	\irqnr, \irqnr, #32
>> +#else
>>   	mov     \irqstat, #0x0D80
>>   1000:
>>   	ldr     \tmp,   [\irqstat, \base]
>> @@ -63,6 +73,7 @@
>>   	bne     1001f
>>   	addeq   \irqnr, \irqnr, #32
>>   	addeq   \irqstat, \irqstat, #4
>> +#endif
>>   	cmp     \irqnr, #128
>>   	blo     1000b
>>   	b       2001f
>> diff --git a/arch/arm/plat-mxc/tzic.c b/arch/arm/plat-mxc/tzic.c
>> index 3703ab2..b648a76 100644
>> --- a/arch/arm/plat-mxc/tzic.c
>> +++ b/arch/arm/plat-mxc/tzic.c
>> @@ -47,6 +47,33 @@
>>
>>   void __iomem *tzic_base; /* Used as irq controller base in entry-macro.S */
>>
>> +#ifdef CONFIG_FIQ
>> +
>> +/*
>> + * switch interrupt between IRQ and FIQ mode.
>> + *
>> + * 'type' is true for FIQ mode and false for IRQ mode.
>> + */
>> +int mxc_set_irq_fiq(unsigned int irq, unsigned int type)
>> +{
>> +	unsigned int index, mask, value;
>> +
>> +	index = irq>>  5;
>> +	if (unlikely(index>= 4))
>> +		return -EBUSY;
>> +	mask = 1U<<  (irq&  0x1F);
>> +
>> +	value = __raw_readl(tzic_base + TZIC_INTSEC0(index));
>> +	value = (value | mask) ^ (type ? mask : 0);
>> +	__raw_writel(value, tzic_base + TZIC_INTSEC0(index));
> Does this result in better code than the straigt forward
>
> 	value = __raw_readl(...)&  ~mask;
> 	if (type)
> 		vale |= mask
> 	__raw_writel(...);
>
> If not, what is the idea to write it this way?

Write it however you like :)

>> +
>> +	return 0;
>> +}
>> +
>> +EXPORT_SYMBOL(mxc_set_irq_fiq);
> Hmm, I guess this makes it impossible to compile avic.c and tzic.c with
> FIQ=y into a single binary.
>

Fair point.

P.

  reply	other threads:[~2010-11-25 23:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 15:19 MX51: add FIQ support for TZIC Peter Horton
2010-11-25 20:38 ` Uwe Kleine-König
2010-11-25 23:30   ` Peter Horton [this message]
2010-11-26 10:09   ` Peter Horton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEEF194.9010707@bitbox.co.uk \
    --to=phorton@bitbox.co.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).