Re: [PATCH 6/10] asm-sh: snapgear ipr/irq updates

[Paul M. <le...@li...>]

On Thu, Jul 26, 2007 at 11:20:30PM +0900, Magnus Damm wrote:
> Hi David,
> 
> Thanks for your patches!
> 
> On 7/26/07, David McCullough <Dav...@se...> wrote:
> >
> > Fix up the IPR/IRQ defines and do a few small cleanups
> >
> > Signed-off-by: David McCullough <dav...@se...>
> >
> > ---
> > commit 729cc761ccd442364de93b5af0e8f40d649d1878
> > tree a022252f2182a5aa6a19101859af0b5a8b135aa0
> > parent 5b55e21c48d5ab697c007781d7b7718293e59e0d
> > author David McCullough <dav...@se...> Thu, 26 Jul 2007 14:11:17 +1000
> > committer David McCullough <davidm@beast.(none)> Thu, 26 Jul 2007 14:11:17 +1000
> >
> >  include/asm-sh/snapgear.h |   31 +++++++++++++++++++++++++++++++
> >  1 files changed, 31 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/asm-sh/snapgear.h b/include/asm-sh/snapgear.h
> > index 3554e3a..a9df1a6 100644
> > --- a/include/asm-sh/snapgear.h
> > +++ b/include/asm-sh/snapgear.h
> > @@ -18,22 +18,46 @@
> >   * depending on the priority for the interrupt.  In fact the priority
> >   * is the interrupt :-)
> >   */
> > +#define        INTC_IPRA       0xffd00004
> > +#define        INTC_IPRB       0xffd00008
> > +#define        INTC_IPRC       0xffd0000c
> > +#define        INTC_IPRD       0xffd00010
> 
> Uhm, these registers are processor specific. The board-specific code
> should not need to poke around with them. There are several boards
> that do this unfortunately - I suspect the code is there for
> historical reasons. These days the vectors should be installed and
> handled by the cpu specific code.
> 
> It should be possible for you to just use ipr_irq_enable_irlm() in
> your board specific code and then request irqs. It looks like no
> board-specific irq handling is needed - you only use IRQ pins for
> external devices, right? No funky FPGA:s with interrupt masks and
> things I hope. =)
> 
> So if you have time - try ripping it all out and check if it still
> works. And I'd be happy to help you to move towards using the intc
> code instead of ipr if board specific code is needed after all.
> 
This should be done incrementally. The INTC conversions are too late for
2.6.23 now that the merge window is closed, but the IPR fixups we can
still merge. It would be worthwhile at least getting the minimal fixes
needed to get the board working for 2.6.23, and leave the restructuring
for 2.6.24.

I've also opened up the 2.6.24 tree already in light of all of the other
INTC work, SH7720 support, etc. so patches for that are of course welcome
at any time, too. The 2.6.24 stuff will be automatically pulled in to
-mm, so the sooner this is done, the more testing it can get before the
next merge window.