From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer
Date: Sun, 9 Dec 2012 09:30:46 +0100 [thread overview]
Message-ID: <20121209083046.GA25466@lunn.ch> (raw)
In-Reply-To: <20121209025748.GA10405@obsidianresearch.com>
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.
> > 4) We than pass the watchdog interrupt via DT.
>
> Right now the watchdog driver is coded to cause a board reset, so it
> doesn't use interrupts at all. Adding interrupt support to watchdog
> seems orthogonal to this?
Yes, its orthogonal, but a logical extension which could be part of a
patchset.
> What would it look like? For my boards I want the watchdog to panic(),
> because I have another watchdog that takes care of reset, but that
> won't be universal.
There are examples of watchdogs that allow this. However, none yet
have DT bindings. I would suggest adding an optional property,
"panic", which indicates the driver should panic rather than
reboot. Make sure to run this by the device tree mailing list.
> > 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.
> The two DT bindings are straightforward, and my testing on Kirkwood
> should cover alot - but it would be great if non-kirkwood boards could
> review/test with this patch..
>
> Do you expect a DT conversion for all orion_time_init users, or just
> the one I can test or ..?
Please take a stab at converting them all. We have an active set of
testers. I can test kirkwood and orion5x, Sebastian tests Dove, Thomas
and Gregory test 370/XP if needed. Nobody seems to care about mv78xx0
so its slowly bit-rotting in a corner.
Thanks
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Mike Turquette <mturquette@linaro.org>,
Jason Cooper <jason@lakedaemon.net>,
Arnd Bergmann <arnd@arndb.de>,
Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>,
linux-kernel@vger.kernel.org, Olof Johansson <olof@lixom.net>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer
Date: Sun, 9 Dec 2012 09:30:46 +0100 [thread overview]
Message-ID: <20121209083046.GA25466@lunn.ch> (raw)
In-Reply-To: <20121209025748.GA10405@obsidianresearch.com>
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.
> > 4) We than pass the watchdog interrupt via DT.
>
> Right now the watchdog driver is coded to cause a board reset, so it
> doesn't use interrupts at all. Adding interrupt support to watchdog
> seems orthogonal to this?
Yes, its orthogonal, but a logical extension which could be part of a
patchset.
> What would it look like? For my boards I want the watchdog to panic(),
> because I have another watchdog that takes care of reset, but that
> won't be universal.
There are examples of watchdogs that allow this. However, none yet
have DT bindings. I would suggest adding an optional property,
"panic", which indicates the driver should panic rather than
reboot. Make sure to run this by the device tree mailing list.
> > 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.
> The two DT bindings are straightforward, and my testing on Kirkwood
> should cover alot - but it would be great if non-kirkwood boards could
> review/test with this patch..
>
> Do you expect a DT conversion for all orion_time_init users, or just
> the one I can test or ..?
Please take a stab at converting them all. We have an active set of
testers. I can test kirkwood and orion5x, Sebastian tests Dove, Thomas
and Gregory test 370/XP if needed. Nobody seems to care about mv78xx0
so its slowly bit-rotting in a corner.
Thanks
Andrew
next prev parent reply other threads:[~2012-12-09 8:30 UTC|newest]
Thread overview: 14+ 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-07 22:55 ` Jason Gunthorpe
2012-12-08 11:26 ` Andrew Lunn
2012-12-08 11:26 ` Andrew Lunn
2012-12-09 2:57 ` Jason Gunthorpe
2012-12-09 2:57 ` Jason Gunthorpe
2012-12-09 8:30 ` Andrew Lunn [this message]
2012-12-09 8:30 ` Andrew Lunn
2012-12-09 13:06 ` Sebastian Hesselbarth
2012-12-09 13:06 ` Sebastian Hesselbarth
2013-06-04 17:26 ` Jason Gunthorpe
2013-06-04 17:26 ` Jason Gunthorpe
2013-06-05 8:57 ` Sebastian Hesselbarth
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=20121209083046.GA25466@lunn.ch \
--to=andrew@lunn.ch \
--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 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.