public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel@lists.01.org, graeme.gregory@linaro.org,
	masahisa.kojima@linaro.org
Subject: Re: [PATCH edk2-platforms 2/5] Silicon/SynQuacer: tweak PCI I/O windows for ACPI/Linux support
Date: Wed, 28 Feb 2018 16:26:11 +0000	[thread overview]
Message-ID: <20180228162611.v6h4ll666u4gmf7e@bivouac.eciton.net> (raw)
In-Reply-To: <20180227092017.23617-3-ard.biesheuvel@linaro.org>

On Tue, Feb 27, 2018 at 09:20:14AM +0000, Ard Biesheuvel wrote:
> ACPI is not able to describe PCI resource windows that involve both type
> and address translation (i.e., for I/O windows on architectures that do
> not support port I/O natively), and so the ACPI/Linux code has a hard
> time performing the resource allocation in such cases. For instance, the
> secondary I/O window we implement on SynQuacer:
> 
>    I/O  0x10000 ... 0x1ffff -> 0x77f00000
> 
> is misinterpreted by Linux, and results in the MMIO range starting at
> 0x77f10000 to be mapped for I/O port access to this range.
> 
> This can be mitigated by using the same PCI range for I/O port access
> on both RCs., i.e., 0x0 ... 0xffff. This configuration can be represented
> using both DT and ACPI, and will work as expected in Linux, since it only
> involves type translation and not address translation.
> 
> However, there is a downside: EDK2 does not cope with I/O address
> translation in the generic PCI host bridge driver, and so it does
> not allow two regions 0x0 ... 0xffff to be configured.
> 
> So in addition, let's reduce the windows declared to the UEFI PCI layer
> to 0x0 ... 0x7fff and 0x8000 ... 0xffff.

", able to cover windows witha single 64KB page."?

> This leaves ample room for I/O
> BARs (which nobody uses anymore anyway), and allows UEFI and the OS to
> share the same static configuration of the PCIe BAR windows.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> Heyi Gui is currently implementing support for address translation in
> the generic PCI host bridge driver, so hopefully, limiting the I/O
> ranges in UEFI is something we can revert shortly.
> 
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi                                                |  2 +-
>  Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h                                                  | 18 +++++++++++-------
>  Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c |  4 ++--
>  3 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> index 05d1673a5c2b..6eb5fd9430cb 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> @@ -483,7 +483,7 @@
>          bus-range = <0x0 0x7e>;
>          #address-cells = <3>;
>          #size-cells = <2>;
> -        ranges = <0x1000000 0x00 0x00010000 0x00 0x77f00000 0x0 0x00010000>,
> +        ranges = <0x1000000 0x00 0x00000000 0x00 0x77f00000 0x0 0x00010000>,
>                   <0x2000000 0x00 0x78000000 0x00 0x78000000 0x0 0x08000000>,
>                   <0x3000000 0x3f 0x00000000 0x3f 0x00000000 0x1 0x00000000>;
>  
> diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
> index 2d3d5cd91be0..ee57377ac3be 100644
> --- a/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
> +++ b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
> @@ -23,12 +23,12 @@
>  
>  #define SYNQUACER_PCI_SEG0_BUSNUM_MIN       0x0
>  #define SYNQUACER_PCI_SEG0_BUSNUM_MAX       0x7e
> +#define SYNQUACER_PCI_SEG0_BUSNUM_RANGE     0x7f
>  
>  #define SYNQUACER_PCI_SEG0_PORTIO_MIN       0x0
> -#define SYNQUACER_PCI_SEG0_PORTIO_MAX       0xffff
> -#define SYNQUACER_PCI_SEG0_PORTIO_SIZE      0x10000
> +#define SYNQUACER_PCI_SEG0_PORTIO_MAX       0x7fff
>  #define SYNQUACER_PCI_SEG0_PORTIO_MEMBASE   0x67f00000
> -#define SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE   SYNQUACER_PCI_SEG0_PORTIO_SIZE
> +#define SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE   0x10000
>  
>  #define SYNQUACER_PCI_SEG0_MMIO32_MIN       0x68000000
>  #define SYNQUACER_PCI_SEG0_MMIO32_MAX       0x6fffffff
> @@ -45,12 +45,12 @@
>  
>  #define SYNQUACER_PCI_SEG1_BUSNUM_MIN       0x0
>  #define SYNQUACER_PCI_SEG1_BUSNUM_MAX       0x7e
> +#define SYNQUACER_PCI_SEG1_BUSNUM_RANGE     0x7f
>  
> -#define SYNQUACER_PCI_SEG1_PORTIO_MIN       0x10000
> -#define SYNQUACER_PCI_SEG1_PORTIO_MAX       0x1ffff
> -#define SYNQUACER_PCI_SEG1_PORTIO_SIZE      0x10000
> +#define SYNQUACER_PCI_SEG1_PORTIO_MIN       0x8000
> +#define SYNQUACER_PCI_SEG1_PORTIO_MAX       0xffff
>  #define SYNQUACER_PCI_SEG1_PORTIO_MEMBASE   0x77f00000
> -#define SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE   SYNQUACER_PCI_SEG1_PORTIO_SIZE
> +#define SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE   0x10000
>  
>  #define SYNQUACER_PCI_SEG1_MMIO32_MIN       0x78000000
>  #define SYNQUACER_PCI_SEG1_MMIO32_MAX       0x7fffffff
> @@ -65,4 +65,8 @@
>  #define SYNQUACER_PCI_SLOT1_LOCATION        SYNQUACER_PCI_LOCATION(0, 1, 3)
>  #define SYNQUACER_PCI_SLOT2_LOCATION        SYNQUACER_PCI_LOCATION(0, 1, 7)
>  
> +#define SYNQUACER_PCI_OS_IO_BASE            0x0
> +#define SYNQUACER_PCI_OS_IO_LIMIT           0xffff
> +#define SYNQUACER_PCI_OS_IO_RANGE           0x10000

Would you be greatly opposed to describing these as

#define SYNQUACER_PCI_OS_IO_BASE   SYNQUACER_PCI_SEG0_PORTIO_MIN
#define SYNQUACER_PCI_OS_IO_LIMIT  SYNQUACER_PCI_SEG1_PORTIO_MAX
#define SYNQUACER_PCI_OS_IO_RANGE  SYNQUACER_PCI_SEG1_PORTIO_MEMSIZE
or
#define SYNQUACER_PCI_OS_IO_RANGE  SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE

which aren't conceptually the same, but explicitly describe the
desired configuration in this case?

/
    Leif

> +
>  #endif
> diff --git a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> index e4679543cc66..6a3b32f6ca55 100644
> --- a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> +++ b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> @@ -348,8 +348,8 @@ PciInitControllerPost (
>    // Region 3: port I/O range
>    ConfigureWindow (DbiBase, 3,
>      IoMemBase,
> -    RootBridge->Io.Base,
> -    RootBridge->Io.Limit - RootBridge->Io.Base + 1,
> +    SYNQUACER_PCI_OS_IO_BASE,
> +    SYNQUACER_PCI_OS_IO_RANGE,
>      IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_IO,
>      0);
>  
> -- 
> 2.11.0
> 


  reply	other threads:[~2018-02-28 16:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27  9:20 [PATCH edk2-platforms 0/5] SynQuacer ACPI support Ard Biesheuvel
2018-02-27  9:20 ` [PATCH edk2-platforms 1/5] Platform/Socionext/DeveloperBox: fix PCIe slot to B/D/F mapping Ard Biesheuvel
2018-02-28 16:17   ` Leif Lindholm
2018-02-28 16:18     ` Ard Biesheuvel
2018-02-28 16:39       ` Leif Lindholm
2018-02-27  9:20 ` [PATCH edk2-platforms 2/5] Silicon/SynQuacer: tweak PCI I/O windows for ACPI/Linux support Ard Biesheuvel
2018-02-28 16:26   ` Leif Lindholm [this message]
2018-02-28 16:30     ` Ard Biesheuvel
2018-02-28 16:43       ` Leif Lindholm
2018-02-28 16:46         ` Ard Biesheuvel
2018-02-27  9:20 ` [PATCH edk2-platforms 3/5] Silicon/SynQuacer: add ACPI drivers and tables Ard Biesheuvel
2018-02-27  9:20 ` [PATCH edk2-platforms 4/5] Silicon/SynQuacer/PlatformDxe: add option to enable ACPI mode Ard Biesheuvel
2018-02-28 16:32   ` Leif Lindholm
2018-02-27  9:20 ` [PATCH edk2-platforms 5/5] Silicon/SynQuacer/PlatformDxe: add ACPI description of eMMC Ard Biesheuvel

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-list 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=20180228162611.v6h4ll666u4gmf7e@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /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