[PATCH u-boot-next 00/12] Common U-Boot macros for PCI Configuration Mechanism #1

From: "Pali Rohár" <pali@kernel.org>
To: Stefan Roese <sr@denx.de>, Simon Glass <sjg@chromium.org>,
	Bin Meng <bmeng.cn@gmail.com>,
	Daniel Schwierzeck <daniel.schwierzeck@gmail.com>,
	Heiko Schocher <hs@denx.de>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Weijie Gao <weijie.gao@mediatek.com>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	GSS_MTK_Uboot_upstream <GSS_MTK_Uboot_upstream@mediatek.com>,
	Huan Wang <alison.wang@nxp.com>,
	Angelo Dureghello <angelo@sysam.it>
Cc: u-boot@lists.denx.de
Subject: [PATCH u-boot-next 00/12] Common U-Boot macros for PCI Configuration Mechanism #1
Date: Fri, 26 Nov 2021 11:42:40 +0100	[thread overview]
Message-ID: <20211126104252.5443-1-pali@kernel.org> (raw)

This patch series add new U-Boot macros for composing Config Address for
PCI Configuration Mechanism #1 as defined in PCI Local Bus Specification,
including extended variant (which do not have any formal specification)
and then use these new macros (PCI_CONF1_ADDRESS and PCI_CONF1_EXT_ADDRESS)
in all PCI drivers that use Config Address according to PCI Configuration
Mechanism #1.

PCI Configuration Mechanism #1 was originally specified for x86 platforms
and it is still supported on x86 together with PCIe ECAM. Nowadays lot of
non-ECAM-compliant ARM PCIe controllers use only extended variant of this
address construction and some of them requires cleared Enable bit. Extended
variant is also supported by x86 AMD Barcelona (and new) CPUs, but U-Boot
code does not provide this support yet.

Note that it exists also PCI Configuration Mechanism #2, but this one was
removed from PCI Local Bus Specification revision 3.0 and seems that it is
not used by any PCI driver in U-Boot. So I have not added macros for this
mechanism in this patch series.

Because lot of hardware still use this (rather old) mechanism, relevant
U-Boot PCI and PCIe drivers have own ad-hoc code address construction,
which is repeated and written in different ways.

This patch series is code cleanup of these PCIe drivers to use common
U-Boot macros for PCI Configuration Mechanism #1.

The last change is fixing construction of Config Address in PCI driver
sh7751. Construction with this change matches Linux kernel code and also
U-Boot code prior commit mentioned in commit message.

I have tested this patch series only for PCI mvebu driver on A385 board and
it is working fine. So Please properly review all other changes. Ideally
test them.

I have run CI tests with these changes on github and everything passed:
https://github.com/u-boot/u-boot/pull/101

Please let me know what do you think about this change.

Pali Rohár (12):
  pci: Add standard PCI Config Address macros
  pci: gt64120: Use PCI_CONF1_ADDRESS() macro
  pci: mpc85xx: Use PCI_CONF1_EXT_ADDRESS() macro
  pci: msc01: Use PCI_CONF1_ADDRESS() macro
  pci: mvebu: Use PCI_CONF1_EXT_ADDRESS() macro
  pci: tegra: Use PCI_CONF1_EXT_ADDRESS() macro
  pci: fsl: Use PCI_CONF1_EXT_ADDRESS() macro
  pci: mediatek: Use PCI_CONF1_EXT_ADDRESS() macro
  pci: sh7780: Use PCI_CONF1_ADDRESS() macro
  x86: pci: Use PCI_CONF1_ADDRESS() macro
  m68k: mcf5445x: pci: Use PCI_CONF1_ADDRESS() macro
  pci: sh7751: Fix access to config space via PCI_CONF1_ADDRESS() macro

 arch/m68k/cpu/mcf5445x/pci.c |  7 +++---
 arch/x86/cpu/pci.c           |  4 ++--
 drivers/pci/pci_gt64120.c    |  7 ++----
 drivers/pci/pci_mpc85xx.c    |  4 ++--
 drivers/pci/pci_msc01.c      |  7 ++----
 drivers/pci/pci_mvebu.c      | 17 ++++----------
 drivers/pci/pci_sh7751.c     | 29 ++---------------------
 drivers/pci/pci_sh7780.c     |  8 +++----
 drivers/pci/pci_tegra.c      | 11 +++------
 drivers/pci/pcie_fsl.c       | 10 ++++----
 drivers/pci/pcie_mediatek.c  | 17 +++++++-------
 include/gt64120.h            | 12 ----------
 include/msc01.h              |  9 --------
 include/pci.h                | 45 ++++++++++++++++++++++++++++++++++++
 14 files changed, 83 insertions(+), 104 deletions(-)

-- 
2.20.1