archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <>
To: Icenowy Zheng <>
Cc: Lorenzo Pieralisi <>,
	Andrew Murray <>,
	Bjorn Helgaas <>, Chen-Yu Tsai <>,
	Rob Herring <>,,,,,
Subject: Re: [RFC PATCH] PCI: dwc: add support for Allwinner SoCs' PCIe controller
Date: Mon, 6 Apr 2020 10:27:32 +0200	[thread overview]
Message-ID: <20200406082732.nt5d7puwn65j4nvl@gilmour.lan> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]


On Fri, Apr 03, 2020 at 12:05:49AM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC uses DesignWare's PCIe controller to provide a PCIe
> host.
> However, on Allwinner H6, the PCIe host has bad MMIO, which needs to be
> workarounded. A workaround with the EL2 hypervisor functionality of ARM
> Cortex cores is now available, which wraps MMIO operations.
> This patch is going to add a driver for the DWC PCIe controller
> available in Allwinner SoCs, either the H6 one when wrapped by the
> hypervisor (so that the driver can consider it as an ordinary PCIe
> controller) or further not buggy ones.
> Signed-off-by: Icenowy Zheng <>
> ---
> There's no device tree binding patch available, because I still have
> questions on the device tree compatible string. I want to use it to
> describe that this driver doesn't support the "native Allwinner H6 PCIe
> controller", but a wrapped version with my hypervisor.
> I think supporting a "para-physical" device is some new thing, so this
> patch is RFC.
> My hypervisor is at [1], and some basic usage documentation is at [2].
> [1]
> [2]

I'm a bit concerned to throw yet another mandatory, difficult to
update, component in the already quite long boot chain.

Getting fixes deployed in ATF or U-Boot is already pretty long, having
another component in there will just make it worse, and it's another
hard to debug component that we throw into the mix.

And this prevents any use of virtualisation on the platform.

I haven't found an explanation on what that hypervisor is doing
exactly, but from a look at it it seems that it will trap all the
accesses to the PCIe memory region to emulate a regular space on top
of the restricted one we have?

If so, can't we do that from the kernel directly by using a memory
region that always fault with a fault handler like Framebuffer's
deferred_io is doing (drivers/video/fbdev/core/fb_defio.c) ?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2020-04-06  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 16:05 [RFC PATCH] PCI: dwc: add support for Allwinner SoCs' PCIe controller Icenowy Zheng
2020-04-06  8:27 ` Maxime Ripard [this message]
2020-04-20  8:18   ` Icenowy Zheng
2020-05-06 15:36     ` Maxime Ripard

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200406082732.nt5d7puwn65j4nvl@gilmour.lan \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).