All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: Guenter Roeck <linux@roeck-us.net>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andrew Jeffery <andrew@aj.id.au>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH 2/2] clocksource/drivers/fttmr010: Be stricter on IRQs
Date: Sat, 28 Aug 2021 10:08:27 +0200	[thread overview]
Message-ID: <567a65a8-077b-7394-c8e2-dbd9f063e02c@kaod.org> (raw)
In-Reply-To: <4d87c7af-d2e3-9456-130a-b35b507ff3a2@roeck-us.net>

Hello,

On 8/28/21 5:37 AM, Guenter Roeck wrote:
> On 8/27/21 3:01 PM, Linus Walleij wrote:
>> On Sat, Aug 21, 2021 at 6:20 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>> On Sun, Jul 25, 2021 at 12:44:24AM +0200, Linus Walleij wrote:
>>
>>>> Make sure we check that the right interrupt occurred before
>>>> calling the event handler for timer 1. Report spurious IRQs
>>>> as IRQ_NONE.
>>>>
>>>> Cc: Cédric Le Goater <clg@kaod.org>
>>>> Cc: Joel Stanley <joel@jms.id.au>
>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>>
>>> This patch results in boot stalls with several qemu aspeed emulations
>>> (quanta-q71l-bmc, palmetto-bmc, witherspoon-bmc, ast2500-evb,
>>> romulus-bmc, g220a-bmc). Reverting this patch together with
>>> "clocksource/drivers/fttmr010: Clear also overflow bit on AST2600"
>>> fixes the problem. Bisect log is attached.
>>
>> Has it been tested on real hardware?

It breaks the AST2500 EVB.
 
>>
>> We are reading register 0x34 TIMER_INTR_STATE for this.
>> So this should reflect the state of raw interrupts from the timers.
>>
>> I looked in qemu/hw/timer/aspeed_timer.c
>> and the aspeed_timer_read() looks dubious.
>> It rather looks like this falls down to returning whatever
>> was written to this register and not reflect which IRQ
>> was fired at all.
>>
> 
> Actually, no. Turns out the qemu code is just a bit difficult to understand.
> The code in question is:
> 
>     default:
>         value = ASPEED_TIMER_GET_CLASS(s)->read(s, offset);
>         break;
> 
> For ast2500-evb, that translates to a call to aspeed_2500_timer_read().
> Here is a trace example (after adding some more tracing):
> 
> aspeed_2500_timer_read From 0x34: 0x0
> aspeed_timer_read From 0x34: of size 4: 0x0
> 
> Problem is that - at least in qemu - only the 2600 uses register 0x34
> for the interrupt status. On the 2500, 0x34 is the ctrl2 register.
> 
> Indeed, the patch works fine on, for example, ast2600-evb.
> It only fails on ast2400 and ast2500 boards.

The QEMU modelling is doing a good job ! I agree that the timer model 
is not the most obvious one to read. 

> I don't have the manuals, so I can't say what the correct behavior is,
> but at least there is some evidence that TIMER_INTR_STATE may not exist
> on ast2400 and ast2500 SOCs. 

On Aspeed SoCs AST2400 and AST2500, the TMC[34] register is a
"control register #2" whereas on the AST2600 it is an "interrupt
status register" with bits [0-7] holding the timers status.

I would say that the patch simply should handle the "is_aspeed" case.  

> From drivers/clocksource/timer-fttmr010.c:

yes. See commit 86fe57fc47b1 ("clocksource/drivers/fttmr010: Fix 
invalid interrupt register access")

AFAICT, the ast2600 does not use a fttmr010 clocksource. Something to 
clarify may be Joel ? 

Thanks,

C.

> 
> /*
>  * Interrupt status/mask register definitions for fttmr010/gemini/moxart
>  * timers.
>  * The registers don't exist and they are not needed on aspeed timers
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  * because:
>  *   - aspeed timer overflow interrupt is controlled by bits in Control
>  *     Register (TMC30).
>  *   - aspeed timers always generate interrupt when either one of the
>  *     Match registers equals to Status register.
>  */
> 
> Guenter


  reply	other threads:[~2021-08-28 10:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24 22:44 [PATCH 1/2] clocksource/drivers/fttmr010: Pass around less pointers Linus Walleij
2021-07-24 22:44 ` [PATCH 2/2] clocksource/drivers/fttmr010: Be stricter on IRQs Linus Walleij
2021-08-20  8:53   ` Daniel Lezcano
2021-08-20 13:39     ` Linus Walleij
2021-08-20 14:16       ` Daniel Lezcano
2021-08-21  4:20   ` Guenter Roeck
2021-08-21  8:04     ` Daniel Lezcano
2021-08-27 22:01     ` Linus Walleij
2021-08-27 22:31       ` Guenter Roeck
2021-08-28  3:37       ` Guenter Roeck
2021-08-28  8:08         ` Cédric Le Goater [this message]
2021-08-30  4:16           ` Andrew Jeffery
2021-08-30  4:58             ` [PATCH 2/2]: Be stric clocksource/drivers/fttmr010ter " Guenter Roeck
2021-08-30  6:30               ` Andrew Jeffery
2021-08-30  7:47               ` [PATCH 2/2]: Be stric clocksource/drivers/fttmr010 " Cédric Le Goater
2021-08-30 15:24                 ` Guenter Roeck
2021-09-01 23:38           ` [PATCH 2/2] clocksource/drivers/fttmr010: Be stricter " Joel Stanley
2021-08-26 16:25 ` [tip: timers/core] clocksource/drivers/fttmr010: Pass around less pointers tip-bot2 for Linus Walleij

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=567a65a8-077b-7394-c8e2-dbd9f063e02c@kaod.org \
    --to=clg@kaod.org \
    --cc=andrew@aj.id.au \
    --cc=daniel.lezcano@linaro.org \
    --cc=joel@jms.id.au \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.