From: Mark Langsdorf <mark.langsdorf@calxeda.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Rob Herring <rob.herring@calxeda.com>,
"paul@codesourcery.com" <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH v3 9/9] arm: make number of a9mpcore GIC interrupts configurable
Date: Tue, 27 Dec 2011 16:04:01 -0600 [thread overview]
Message-ID: <4EFA40D1.3010200@calxeda.com> (raw)
In-Reply-To: <CAFEAcA9LfOVOLgSrErS-dhqu5PBch6nhDvpmKYRke2KNe6wn_Q@mail.gmail.com>
On 12/27/2011 03:59 PM, Peter Maydell wrote:
> On 27 December 2011 20:13, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote:
>> Increase the maximum number of GIC interrupts for a9mp to 192, and
>> create a configurable property defaulting to 96 so that device
>> modelers can set the value appropriately for their SoC.
>
>> /* Configuration for arm_gic.c:
>> * number of external IRQ lines, max number of CPUs, how to ID current CPU
>> */
>> -#define GIC_NIRQ 96
>> +#define GIC_NIRQ 192
>
> This (still) isn't the maximum number of GIC interrupts for
> an A9MP. You want 256.
I know, but I figured "more than anyone would be using" would
be sufficient.
> Moreover:
> now we have a per-cpu #define which is setting the compile-time
> maximum on a run-time parameter. That's pretty pointless --
> we should just have arm_gic.c have its own (purely internal)
> #define of the maximum number of interrupts it can permit,
> and the cpu-specific private peripheral code should only be
> setting the run-time parameter. You can drop the #define completely
> from a9mpcore.c &co. (don't forget to update the comment)
Okay.
> The GIC architectural limit on number of interrupts is 1020;
> that would (I think) imply a ~64K memory usage by the GIC,
> which we can live with I think.
I think you just said you wanted me to define the gic internal
maximum as 1020. I just want to be sure I understood you there.
>> --- a/hw/arm11mpcore.c
>> +++ b/hw/arm11mpcore.c
>> @@ -132,7 +132,7 @@ static int mpcore_priv_init(SysBusDevice *dev)
>> {
>> mpcore_priv_state *s = FROM_SYSBUSGIC(mpcore_priv_state, dev);
>>
>> - gic_init(&s->gic, s->num_cpu);
>> + gic_init(&s->gic, s->num_cpu, GIC_NIRQ);
>
> 11MPCore, like A9MP, has a configurable number of interrupt lines
> (up to 256 including the 32 internal ones, also like A9MP).
I don't have 11mpcore to test with, but I'll make the change.
>> -static void gic_init(gic_state *s)
>> +static void gic_init(gic_state *s, int num_irq)
>> #endif
>> {
>> int i;
>> @@ -808,7 +809,8 @@ static void gic_init(gic_state *s)
>> #if NCPU > 1
>> s->num_cpu = num_cpu;
>> #endif
>> - qdev_init_gpio_in(&s->busdev.qdev, gic_set_irq, GIC_NIRQ - 32);
>> + s->num_irq = num_irq;
>
> This is where you should be hw_error()ing if num_irq is
> too big.
>
> I didn't see any changes to gic_load/gic_save, which means they
> will still be saving all GIC_NIRQ entries in each of the per-irq
> state arrays; this means that you've broken save/load compatibility.
> I think this can be fixed by having save/load only save/load the
> entries which are actually used (ie loop up to s->num_irq rather
> than GIC_NIRQ).
I had considered that, but wasn't sure enough about the pros and
cons. I'll make the changes and thanks for the feedback.
--Mark Langsdorf
Calxeda, Inc.
next prev parent reply other threads:[~2011-12-27 22:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-27 20:13 [Qemu-devel] [PATCH v3 0/9] various arm fixes Mark Langsdorf
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 1/9] arm: add missing scu registers Mark Langsdorf
2011-12-27 22:00 ` Peter Maydell
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 2/9] arm: Set frequencies for arm_timer Mark Langsdorf
2011-12-27 22:02 ` Peter Maydell
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 3/9] arm: add dummy v7 cp15 config_base_register Mark Langsdorf
2011-12-27 22:05 ` Peter Maydell
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 4/9] arm: add dummy gic security registers Mark Langsdorf
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 5/9] ahci: convert ahci_reset to use AHCIState Mark Langsdorf
2011-12-27 22:54 ` Peter Maydell
2011-12-27 23:20 ` Mark Langsdorf
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 6/9] ahci: add support for non-PCI based controllers Mark Langsdorf
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 7/9] add L2x0/PL310 cache controller device Mark Langsdorf
2011-12-28 0:23 ` Peter Maydell
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 8/9] Add xgmac ethernet model Mark Langsdorf
2011-12-28 0:39 ` Peter Maydell
2011-12-27 20:13 ` [Qemu-devel] [PATCH v3 9/9] arm: make number of a9mpcore GIC interrupts configurable Mark Langsdorf
2011-12-27 21:59 ` Peter Maydell
2011-12-27 22:04 ` Mark Langsdorf [this message]
2011-12-27 22:09 ` Peter Maydell
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=4EFA40D1.3010200@calxeda.com \
--to=mark.langsdorf@calxeda.com \
--cc=kwolf@redhat.com \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rob.herring@calxeda.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.