All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tiejun.chen" <tiejun.chen@windriver.com>
To: Scott Wood <scottwood@freescale.com>
Cc: david.hagood@gmail.com,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Questions on interrupt vector assignment on MPC8641D
Date: Wed, 13 Oct 2010 09:17:01 +0800	[thread overview]
Message-ID: <4CB5088D.4090201@windriver.com> (raw)
In-Reply-To: <20101012162152.5246744a@udp111988uds.am.freescale.net>

Scott Wood wrote:
> On Tue, 12 Oct 2010 15:55:28 -0500
> <david.hagood@gmail.com> wrote:
> 
>> I wonder about the next lines:
>>
>>
>> 	mpic_assign_isu(mpic1, 0, res.start + 0x10000);
>>
>> 	/* 48 Internal Interrupts */
>> 	mpic_assign_isu(mpic1, 1, res.start + 0x10200);
>> 	mpic_assign_isu(mpic1, 2, res.start + 0x10400);
>> 	mpic_assign_isu(mpic1, 3, res.start + 0x10600);
>>
>> 	/* 16 External interrupts
>> 	 * Moving them from [0 - 15] to [64 - 79]
>> 	 */
>> 	mpic_assign_isu(mpic1, 4, res.start + 0x10000);
> 
> No mainline 86xx boards do that, even in 2.6.26.  I suspect you need to
> either get rid of the isu stuff altogether, or add a mapping for the
> MSI interrupts.
> 
>> Looking at the code, and where it appears to be faulting, it looks like
>> its in kernel/irq/chip.c:
>>
>>
>> int set_irq_type(unsigned int irq, unsigned int type)
>> {
>> 	struct irq_desc *desc;
>> 	unsigned long flags;
>> 	int ret = -ENXIO;
>>
>> 	if (irq >= NR_IRQS) {
>> 		printk(KERN_ERR "Trying to set irq type for IRQ%d\n", irq);
>> 		return -ENODEV;
>> 	}
>>
>> 	desc = irq_desc + irq;
>> ------------------------
>> 	if (desc->chip->set_type) {
>> 		spin_lock_irqsave(&desc->lock, flags);
>> 		ret = desc->chip->set_type(irq, type);
>> ------------------------
>>
>>
>> 		spin_unlock_irqrestore(&desc->lock, flags);
>> 	}
>> 	return ret;
>> }
>>
>> My conjecture is that desc->chip isn't set. Is mpic_assign_isu the
>> function that does that?
> 
> That happens in set_irq_chip_and_handler(), called from mpic_host_map()
> -- just a few lines before calling set_irq_type().
> 
> The crash is happening somewhere in mpic_set_irq_type():

Agreed. That is just where I pointed out on my email replied for OOPS. To enable
DBG to figure out 'src' and 'mpic->irq_count' from the file,
arch/powerpc/sysdev/mpic.c,    .
======
int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
	......
	if (src >= mpic->irq_count)
		return -EINVAL;
			^
			I think this OOPS may be from here.


Tiejun

>> NIP [c0016540] mpic_set_irq_type+0x188/0x1c4
> 
> -Scott
> 
> 

  reply	other threads:[~2010-10-13  1:15 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-21 14:12 Questions on interrupt vector assignment on MPC8641D david.hagood
2010-09-21 21:37 ` Anderson, Trevor
2010-09-21 22:07   ` Scott Wood
2010-09-22  0:36     ` Chen, Tiejun
2010-10-07 20:12     ` david.hagood
2010-10-07 20:26       ` Scott Wood
2010-10-07 21:01         ` david.hagood
2010-10-09 15:52         ` david.hagood
2010-10-11  9:51           ` tiejun.chen
2010-10-11 11:30             ` David Hagood
2010-10-11 14:44             ` david.hagood
2010-10-13  1:10               ` Michael Ellerman
2010-10-11 15:51             ` Scott Wood
2010-10-12  1:39               ` tiejun.chen
2010-10-11 15:50           ` Scott Wood
2010-10-11 17:02             ` david.hagood
2010-10-11 17:30               ` Scott Wood
2010-10-12  3:11                 ` tiejun.chen
2010-10-09 17:03         ` david.hagood
2010-10-11  9:55           ` tiejun.chen
2010-10-11 17:17             ` Scott Wood
2010-10-12 20:55               ` david.hagood
2010-10-12 21:21                 ` Scott Wood
2010-10-13  1:17                   ` tiejun.chen [this message]
2010-10-13 15:28                     ` Scott Wood
2010-10-13 17:08                       ` david.hagood
2010-10-13 19:56                         ` Scott Wood
2010-10-13 21:16                           ` david.hagood
2010-10-14  1:39                       ` tiejun.chen
2010-10-14  3:27                         ` tiejun.chen
2010-10-14 15:51                           ` Scott Wood
2010-10-14 16:22                             ` david.hagood
2010-10-14 16:32                               ` Scott Wood
2010-10-14 17:20                                 ` david.hagood
2010-10-14 17:50                                   ` Scott Wood
2010-10-14 18:44                                     ` david.hagood
2010-10-15  1:28                             ` tiejun.chen
2010-10-12  3:00             ` tiejun.chen

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=4CB5088D.4090201@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=david.hagood@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.com \
    /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.