linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer
Date: Sun, 09 Dec 2012 14:06:48 +0100	[thread overview]
Message-ID: <50C48CE8.9070400@gmail.com> (raw)
In-Reply-To: <20121209083046.GA25466@lunn.ch>

On 12/09/2012 09:30 AM, Andrew Lunn wrote:
> On Sat, Dec 08, 2012 at 07:57:48PM -0700, Jason Gunthorpe wrote:
>> On Sat, Dec 08, 2012 at 12:26:24PM +0100, Andrew Lunn wrote:
>>
>>> 1) It should have an IRQ domain, like the other IRQ chips we have.
>>> 2) It should have a DT binding, like the other IRQ chips we have.
>>
>> I was going to look at a DT binding for this as a follow on, since
>> I'll want to bind to these interrupts.
>>
>> Are you OK with keeping this patch as is and seeing DT in a follow up,
>> or as a series? It is already pretty big.
>
> Hi Jason
>
> A patch series is great. However, its not so good practice to add
> something on the first patch, and then move it somewhere else in the
> next. So i would suggest initializing the controller in
> kirkwood_irq_init(), etc as its added.

Hi Andrew, Jason,

first of all I have adjusted the Cc list a little bit: Gregory is missing,
and I removed Mike and Olof as they might not be that interested in discussing
mvebu internals. Please re-add if I am wrong.

I have an irqchip driver for orion that I wrote some weeks ago. I can
prepare a patch today. I will allow to have main irq controller by DT
and I can also add a secondary irq controller for the bridge registers
as chained irq handler.

If I dig hard enough in my branches I will also find time-orion drivers,
that are either "standalone" (i.e. orion only) or merged with time-mvebu.

The main irq controller will be required for sure, but for the secondary
irq controller we had a discussion long ago. IIRC Gregory proposed to have
shared irqs handled by timer and watchdog, I was proposing chained irqs.

For mvebu archs, IIRC, we have wrt to timer-related irqs:
- Armada 370/XP with different irq handler and timer irq handling within
   timer registers.
- Orion SoCs with Bridge irq registers for timer related stuff (timer0/1)
- Kirkwood and Dove with watchdog timers (both with wdt irq in bridge irqs)
- RTC in bridge irqs, but Dove with RTC connected to PMU irqs

I think we should have patches for irqchip-orion first and then rethink
if we want a standalone timer-orion or merge it with timer-mvebu. Having
watchdog using irqs is kind of independent from this.

> ...
>>> 3) We then pass the timer interrupt via DT to the timer driver.
>>> 3) is not so simple, because we currently don't have a timer binding
>>> for Orion SoC. However, with this cleanup, we are much closer to being
>>> able to use the 370/XP timer code.
>>
>> Interesting.. The 370/XP is a more advanced version of the same timer
>> IP, there are several registers that driver is touching that are not
>> HW supported, at least on kirkwood.
>
> Yes, the 25MHz and the divider for example. I'm not 100% sure it will
> actually work, it will need a different compatibility string, and a
> bit of configuration based on that string, but i think it goes. If you
> compare the two different drivers, they are very similar.

Back in the days when Gregory, Thomas, and I were looking into merged timer
we agreed not to have an extra check on 25MHz support. If you put the
property in the node, it will try to set the timer to fixed 25MHz. If you
use the property on Orion timer, it will just break timer handling.

Sebastian

  reply	other threads:[~2012-12-09 13:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 22:55 [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer Jason Gunthorpe
2012-12-08 11:26 ` Andrew Lunn
2012-12-09  2:57   ` Jason Gunthorpe
2012-12-09  8:30     ` Andrew Lunn
2012-12-09 13:06       ` Sebastian Hesselbarth [this message]
2013-06-04 17:26         ` Jason Gunthorpe
2013-06-05  8:57           ` Sebastian Hesselbarth

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=50C48CE8.9070400@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --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).