xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Cc: prasun.Kapoor@caviumnetworks.com,
	Naresh Bhat <naresh.bhat@linaro.org>,
	manish.jaggi@caviumnetworks.com,
	xen-devel <xen-devel@lists.xen.org>,
	Parth Dixit <parth.dixit@linaro.org>,
	Vijaya.Kumar@caviumnetworks.com
Subject: Re: ACPI Xen and SMMU driver
Date: Thu, 18 Sep 2014 19:04:30 +0100	[thread overview]
Message-ID: <1411063470.1920.20.camel@citrix.com> (raw)
In-Reply-To: <CAAiw7Jn+8njfK7yADC6FgaPWFuOoR7zWKfeC_pCQhv+dhht-Tg@mail.gmail.com>

On Wed, 2014-09-17 at 09:36 +0530, manish jaggi wrote:

Adding Naresh and Parth who are working on Xen ACPI support within
Linaro.

> Hi Stefano / Ian,
> 
> Currently the SMMU code for ARM is derived from Linux SMMU code which
> is dependent on device tree. My current PCI passthrough work is based
> on the platform device passthrough support which is actually the
> device tree node pass through.
> 
> With ACPI smmu.c have to be split into smmu-dt.c and smmu-acpi.c,
> smmu-ops.c. The smmu-ops would be much simpler driver.
> 
> As PCI passthrough on ARM is only on ARMv8 servers

I don't think this is a true assumption (but I also don't think it makes
a difference to the approach we should take)

>  do you think it
> makes sense to provide the PCI passthrough support via acpi smmu
> driver  or we would have to still base it on (current)smmu-dt driver,
> when targeting for 4.5 Xen.

We certainly don't want to be duplicating the actual driver
functionality (I don't think you were suggesting that though).

What we will need is an ACPI equivalent of the "glue" bit (i.e.
DT_DEVICE_START and the functions it references). I think it remains to
be seen once ACPI patches start turning up but I hope that the glue
layer will be small enough that it can all live alongside the DT glue in
the smmu.c file, and perhaps even share some of the code between the DT
and ACPI glue.

If it turns out that the ACPI glue is a significant portion of the
smmu.c file then perhaps we will need to consider splitting it out, but
I'm hopeful it won't come to that.

Ian.

      reply	other threads:[~2014-09-18 18:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17  4:06 ACPI Xen and SMMU driver manish jaggi
2014-09-18 18:04 ` Ian Campbell [this message]

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=1411063470.1920.20.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=manishjaggi.oss@gmail.com \
    --cc=naresh.bhat@linaro.org \
    --cc=parth.dixit@linaro.org \
    --cc=prasun.Kapoor@caviumnetworks.com \
    --cc=xen-devel@lists.xen.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).