From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11416C433EF for ; Fri, 26 Nov 2021 10:43:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7E2A783775; Fri, 26 Nov 2021 11:43:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="W3y5Hick"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 258528372E; Fri, 26 Nov 2021 11:43:45 +0100 (CET) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EA4A58372E for ; Fri, 26 Nov 2021 11:43:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: by mail.kernel.org (Postfix) with ESMTPSA id E8133601FF; Fri, 26 Nov 2021 10:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1637923419; bh=RN9zl1+yR1yQmSBN2mKwZmJkiYeNDEc9+025bMSOyb4=; h=From:To:Cc:Subject:Date:From; b=W3y5HickSGvd4UUByQ+TL8oAwckfjDUV6za7+kzQEYMkiPr+6mWHkuMNmp6YRW8fy Ax0Fw0XQaUsftQ3BbagmYTxSPBnyx6Fz+royP7lna78f++O4xGYSb+8H9DhRckau+U mVMYf25BtSJmWdplRAABncPdPJir/5MYd79zN0RmhjNZlZKbS/kiugh2IbJ7NDO7AD +tdjXkNw90+TQgAAy91Xj8CdPdeb0ZMZQbI4bQObyYzI7fOsgpvO/GGo9Gd2Q90XGM 8ouKBCAhnIhCTFsBeJaH87yOPN4Jmy7TNKhcVut94CjOPj2ylyC7PqzU+cRVSOmGWn uFrQvBvQwOwnA== Received: by pali.im (Postfix) id 8FCE85B2; Fri, 26 Nov 2021 11:43:36 +0100 (CET) From: =?UTF-8?q?Pali=20Roh=C3=A1r?= To: Stefan Roese , Simon Glass , Bin Meng , Daniel Schwierzeck , Heiko Schocher , Marek Vasut , Ryder Lee , Weijie Gao , Chunfeng Yun , GSS_MTK_Uboot_upstream , Huan Wang , Angelo Dureghello 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 Message-Id: <20211126104252.5443-1-pali@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.37 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean 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