qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: "qemu-ppc@nongnu.org List" <qemu-ppc@nongnu.org>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 16/19] openpic: add Shared MSI support
Date: Tue, 11 Dec 2012 19:42:28 -0600	[thread overview]
Message-ID: <1355276548.16025.6@snotra> (raw)
In-Reply-To: <B79E70A8-6147-42E3-B727-702B06D2769C@suse.de> (from agraf@suse.de on Tue Dec 11 18:53:44 2012)

On 12/11/2012 06:53:44 PM, Alexander Graf wrote:
> 
> On 11.12.2012, at 18:35, Scott Wood wrote:
> 
> > On 12/11/2012 02:10:14 AM, Alexander Graf wrote:
> >> On 11.12.2012, at 01:36, Scott Wood <scottwood@freescale.com>  
> wrote:
> >> > On 12/08/2012 07:44:39 AM, Alexander Graf wrote:
> >> >> The OpenPIC allows MSI access through shared MSI registers.  
> Implement
> >> >> them for the MPC8544 MPIC, so we can support MSIs.
> >> >> Signed-off-by: Alexander Graf <agraf@suse.de>
> >> >> ---
> >> >> hw/openpic.c |  150  
> ++++++++++++++++++++++++++++++++++++++++++++++++++--------
> >> >> 1 files changed, 130 insertions(+), 20 deletions(-)
> >> >> diff --git a/hw/openpic.c b/hw/openpic.c
> >> >> index f2f152f..f71d668 100644
> >> >> --- a/hw/openpic.c
> >> >> +++ b/hw/openpic.c
> >> >> @@ -38,6 +38,7 @@
> >> >> #include "pci.h"
> >> >> #include "openpic.h"
> >> >> #include "sysbus.h"
> >> >> +#include "msi.h"
> >> >> //#define DEBUG_OPENPIC
> >> >> @@ -52,6 +53,7 @@
> >> >> #define MAX_TMR     4
> >> >> #define VECTOR_BITS 8
> >> >> #define MAX_IPI     4
> >> >> +#define MAX_MSI     8
> >> >> #define VID         0x03 /* MPIC version ID */
> >> >> /* OpenPIC capability flags */
> >> >> @@ -62,6 +64,8 @@
> >> >> #define OPENPIC_GLB_REG_SIZE         0x10F0
> >> >> #define OPENPIC_TMR_REG_START        0x10F0
> >> >> #define OPENPIC_TMR_REG_SIZE         0x220
> >> >> +#define OPENPIC_MSI_REG_START        0x1600
> >> >> +#define OPENPIC_MSI_REG_SIZE         0x200
> >> >> #define OPENPIC_SRC_REG_START        0x10000
> >> >> #define OPENPIC_SRC_REG_SIZE         (MAX_IRQ * 0x20)
> >> >> #define OPENPIC_CPU_REG_START        0x20000
> >> >> @@ -126,6 +130,12 @@
> >> >> #define IDR_P1_SHIFT      1
> >> >> #define IDR_P0_SHIFT      0
> >> >> +#define MSIIR_OFFSET       0x140
> >> >> +#define MSIIR_SRS_SHIFT    29
> >> >> +#define MSIIR_SRS_MASK     (0x7 << MSIIR_SRS_SHIFT)
> >> >> +#define MSIIR_IBS_SHIFT    24
> >> >> +#define MSIIR_IBS_MASK     (0x1f << MSIIR_IBS_SHIFT)
> >> >
> >> > FWIW, if you want to model newer MPICs such as on p4080, they  
> have multiple banks of MSIs, so you may not want to hardcode one bank.
> >> The OpenPIC code was suffering a lot from attempts to generalize  
> different implementations without implementing them.
> >> If we want to add support for p4080 MPICs later, we add a new  
> model to the emulation and make the nr of msi banks a parameter, like  
> the patch set does for all the other raven/mpc8544 differences. That  
> way we don't get into the current mess of a halfway accurate  
> emulation unless we really want it.
> >
> > So because the old code made a mess of it, we're saying  
> "abstraction is bad" in general?
> 
> No, because the old code messed up abstraction, I would like to move  
> to a non-abstract level and then start abstracting at the correct  
> layer. What that correct layer is is still up for discussion :).
> 
> > All I'm saying is this should be done with a runtime data structure  
> (of which there could be more than one) rather than #defines.
> 
> Yeah, and my argument was that this should be introduced as part of a  
> new model. But if it makes you happy I can of course also make it  
> generic right now, without a user, which means we can't even test  
> whether the generalization works, which means we might screw it up  
> again ;).

It would have a user.  It just wouldn't have multiple users, or a user  
that instantiates multiple banks.  This feels like writing a kernel  
driver that can only handle one instance of a device, just because  
that's all your SoC happens to have at the moment.  Nobody objects to a  
driver having its state in a struct, or the driver maintaining a list  
of said structs, just because you don't have hardware to test the case  
where there are multiple instances.

-Scott

  reply	other threads:[~2012-12-12  1:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-08 13:44 [Qemu-devel] [PATCH 00/19] OpenPIC refactoring and MSI support Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 01/19] openpic: Remove unused code Alexander Graf
2012-12-08 15:12   ` Andreas Färber
2012-12-08 15:14     ` Alexander Graf
2012-12-08 17:06     ` Hervé Poussineau
2012-12-08 13:44 ` [Qemu-devel] [PATCH 02/19] mpic: Unify numbering scheme Alexander Graf
2012-12-10 23:34   ` [Qemu-devel] [Qemu-ppc] " Scott Wood
2012-12-10 23:40     ` Scott Wood
2012-12-11  8:14     ` Alexander Graf
2012-12-11 17:39       ` Scott Wood
2012-12-08 13:44 ` [Qemu-devel] [PATCH 03/19] openpic: update to proper memory api Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 04/19] openpic: combine mpic and openpic src handlers Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 05/19] openpic: Convert subregions to memory api Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 06/19] openpic: combine mpic and openpic irq raise functions Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 07/19] openpic: merge mpic and openpic timer handling Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 08/19] openpic: combine openpic and mpic reset functions Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 09/19] openpic: unify memory api subregions Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 10/19] openpic: remove unused type variable Alexander Graf
2012-12-10 23:42   ` [Qemu-devel] [Qemu-ppc] " Scott Wood
2012-12-11  8:17     ` Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 11/19] openpic: convert simple reg operations to builtin bitops Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 12/19] openpic: rename openpic_t to OpenPICState Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 13/19] openpic: remove irq_out Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 14/19] openpic: convert to qdev Alexander Graf
2012-12-10 23:47   ` Scott Wood
2012-12-11  8:25     ` Alexander Graf
2012-12-11 17:47       ` Scott Wood
2012-12-12  0:56         ` Alexander Graf
2012-12-12  1:38           ` Scott Wood
2012-12-12 10:37             ` Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 15/19] openpic: make brr1 model specific Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 16/19] openpic: add Shared MSI support Alexander Graf
2012-12-11  0:36   ` [Qemu-devel] [Qemu-ppc] " Scott Wood
2012-12-11  8:10     ` Alexander Graf
2012-12-11 17:35       ` Scott Wood
2012-12-12  0:53         ` Alexander Graf
2012-12-12  1:42           ` Scott Wood [this message]
2012-12-12 11:12             ` Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 17/19] PPC: e500: Add " Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 18/19] PPC: e500: Declare pci bridge as bridge Alexander Graf
2012-12-08 13:44 ` [Qemu-devel] [PATCH 19/19] MSI-X: Fix endianness Alexander Graf
2012-12-08 22:41   ` Michael S. Tsirkin

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=1355276548.16025.6@snotra \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).