diff mbox

kzm9g boot fail (was Re: irqdomain breaks ap4 boot)

Message ID 20120820075408.GA21643@linux-sh.org (mailing list archive)
State Rejected
Headers show

Commit Message

Paul Mundt Aug. 20, 2012, 7:54 a.m. UTC
On Mon, Aug 20, 2012 at 12:41:28AM -0700, Kuninori Morimoto wrote:
> 
> Hi Paul
> Cc Magnus
> 
> > > > place. At least we know the irqdomain code isn't at fault anymore.
> 
> I tried show irq number on "non-irqdomain kernel" and "irqdomain kernel".
> And compared these 2 kernel irq table.
> ("irqdomain kernel" doesn't have my quick hack patch => got WARNING)
> 
> It were
> 	register_intc_controller(&intcs_desc);
> 	register_intc_controller(&intca_irq_pins_desc);
> 	register_intc_controller(&intc_pint0_desc);
> 	register_intc_controller(&intc_pint1_desc);
> 
> 1st register_intc_controller()'s irq were
> 	irqdomain	: from 448 to 680
>         non-irqdomain	: from 448 to 680
> 2nd register_intc_controller()'s irq were
> 	irqdomain	: from 560 to 959 <=
>         non-irqdomain	: from 544 to 943 <=

How are you getting these ranges?

The irqdomain ranges are calculated using evt2irq(), but it looks like
sh73a0 needs to use intcs_evt2irq()/to_intc_vect() for factoring in the
offsets. That offset factorization appears to be what is throwing this
out of range -- though why evt2irq() use on these vectors hasn't resulted
in issues before this I don't know.

Do you observe any difference by dropping evt2irq() bounding for the
linear range and simply using the tree type?

---

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Kuninori Morimoto Aug. 20, 2012, 8:12 a.m. UTC | #1
Hi Paul

> The irqdomain ranges are calculated using evt2irq(), but it looks like
> sh73a0 needs to use intcs_evt2irq()/to_intc_vect() for factoring in the
> offsets. That offset factorization appears to be what is throwing this
> out of range -- though why evt2irq() use on these vectors hasn't resulted
> in issues before this I don't know.
>
> Do you observe any difference by dropping evt2irq() bounding for the
> linear range and simply using the tree type?

I tried your patch, but I got same result as before.
I'm using 
 linus/master + paul/sh-latest + your-patch

----------------
irq: irq_domain_associate_many(<no-node>, irqbase=516, hwbase=516, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=517, hwbase=517, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=518, hwbase=518, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=520, hwbase=520, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=521, hwbase=521, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=522, hwbase=522, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=523, hwbase=523, count=1)
(snip)
intc: Registered controller 'sh73a0-intca-irq-pins' with 32 IRQs
irq: Allocated domain of type 3 @0xde8029c0
irq: irq_domain_associate_many(<no-node>, irqbase=544, hwbase=544, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=545, hwbase=545, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=546, hwbase=546, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=547, hwbase=547, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=548, hwbase=548, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=549, hwbase=549, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=550, hwbase=550, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=551, hwbase=551, count=1)
irq: irq_domain_associate_many(<no-node>, irqbase=552, hwbase=552, count=1)
------------[ cut here ]------------
WARNING: at /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/kernel/irq/irqdomain.)
error: irq_desc already associated; irq=552 hwirq=0x228
Modules linked in:
Backtrace:
[<c0012358>] (dump_backtrace+0x0/0x10c) from [<c02e7e1c>] (dump_stack+0x18/0x1c)
 r6:c0065640 r5:00000009 r4:c03e9ed8 r3:c0404908
[<c02e7e04>] (dump_stack+0x0/0x1c) from [<c001cecc>] (warn_slowpath_common+0x54)
[<c001ce78>] (warn_slowpath_common+0x0/0x6c) from [<c001cf88>] (warn_slowpath_f)
 r8:00000228 r7:c03de514 r6:00000228 r5:00000000 r4:de8029c0
r3:00000009

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kuninori Morimoto Aug. 20, 2012, 8:35 a.m. UTC | #2
Hi

> > 1st register_intc_controller()'s irq were
> > 	irqdomain	: from 448 to 680
> >         non-irqdomain	: from 448 to 680
> > 2nd register_intc_controller()'s irq were
> > 	irqdomain	: from 560 to 959 <=
> >         non-irqdomain	: from 544 to 943 <=
> 
> How are you getting these ranges?

Grr. I'm so sorry.
It was my fault.
Above 2nd irqdomain kernel had my quick hack patch.
I double checked irq ranges, and both kernel had same ranges.

I'm so sorry again

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/sh/intc/irqdomain.c b/drivers/sh/intc/irqdomain.c
index 3968f1c..5ba8ba7 100644
--- a/drivers/sh/intc/irqdomain.c
+++ b/drivers/sh/intc/irqdomain.c
@@ -44,6 +44,7 @@  static const struct irq_domain_ops intc_evt_ops = {
 void __init intc_irq_domain_init(struct intc_desc_int *d,
 				 struct intc_hw_desc *hw)
 {
+#if 0
 	unsigned int irq_base, irq_end;
 
 	/*
@@ -62,6 +63,7 @@  void __init intc_irq_domain_init(struct intc_desc_int *d,
 		d->domain = irq_domain_add_linear(NULL, hw->nr_vectors,
 						  &intc_evt_ops, NULL);
 	else
+#endif
 		d->domain = irq_domain_add_tree(NULL, &intc_evt_ops, NULL);
 
 	BUG_ON(!d->domain);