[U-Boot] [PATCH 1/5] pci: tegra: port to standard clock/reset/pwr domain APIs
Stephen Warren
swarren at wwwdotorg.org
Mon Aug 1 17:22:33 CEST 2016
On 07/31/2016 07:02 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 27 July 2016 at 15:48, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Tegra186 supports the new standard clock, reset, and power domain APIs.
>> Older Tegra SoCs still use custom APIs. Enhance the Tegra PCIe driver so
>> that it can operate with either set of APIs.
>>
>> On Tegra186, the BPMP handles all aspects of PCIe PHY (UPHY) programming.
>> Consequently, this logic is disabled too.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>> This whole series builds on the other Tegra186 series that I just sent.
>>
>> drivers/pci/Kconfig | 1 +
>> drivers/pci/pci_tegra.c | 154 ++++++++++++++++++++++++++++++++++++++++++++++--
>> 2 files changed, 150 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 26aa2b0930a0..669e37bb5dc5 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -31,6 +31,7 @@ config PCI_SANDBOX
>> config PCI_TEGRA
>> bool "Tegra PCI support"
>> depends on TEGRA
>> + depends on (TEGRA186 && POWER_DOMAIN) || (!TEGRA186)
>> help
>> Enable support for the PCIe controller found on some generations of
>> Tegra. Tegra20 has 2 root ports with a total of 4 lanes, Tegra30 has
>> diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
>> index 352cdef56ab4..a6785ad0bbee 100644
>> --- a/drivers/pci/pci_tegra.c
>> +++ b/drivers/pci/pci_tegra.c
>> @@ -13,22 +13,26 @@
>> #define pr_fmt(fmt) "tegra-pcie: " fmt
>>
>> #include <common.h>
>> +#include <clk.h>
>> #include <dm.h>
>> #include <errno.h>
>> #include <fdtdec.h>
>> #include <malloc.h>
>> #include <pci.h>
>> +#include <power-domain.h>
>> +#include <reset.h>
>>
>> #include <asm/io.h>
>> #include <asm/gpio.h>
>>
>> +#include <linux/list.h>
>> +
>> +#ifndef CONFIG_TEGRA186
>> #include <asm/arch/clock.h>
>> #include <asm/arch/powergate.h>
>> #include <asm/arch-tegra/xusb-padctl.h>
>> -
>> -#include <linux/list.h>
>> -
>> #include <dt-bindings/pinctrl/pinctrl-tegra-xusb.h>
>> +#endif
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -103,6 +107,9 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222 (0x1 << 20)
>> #define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_X4_X1 (0x1 << 20)
>> #define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411 (0x2 << 20)
>> +#define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_401 (0x0 << 20)
>> +#define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_211 (0x1 << 20)
>> +#define AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_111 (0x2 << 20)
>>
>> #define AFI_FUSE 0x104
>> #define AFI_FUSE_PCIE_T0_GEN2_DIS (1 << 2)
>> @@ -110,6 +117,7 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define AFI_PEX0_CTRL 0x110
>> #define AFI_PEX1_CTRL 0x118
>> #define AFI_PEX2_CTRL 0x128
>> +#define AFI_PEX2_CTRL_T186 0x19c
>> #define AFI_PEX_CTRL_RST (1 << 0)
>> #define AFI_PEX_CTRL_CLKREQ_EN (1 << 1)
>> #define AFI_PEX_CTRL_REFCLK_EN (1 << 3)
>> @@ -173,6 +181,7 @@ enum tegra_pci_id {
>> TEGRA30_PCIE,
>> TEGRA124_PCIE,
>> TEGRA210_PCIE,
>> + TEGRA186_PCIE,
>> };
>>
>> struct tegra_pcie_port {
>> @@ -189,6 +198,7 @@ struct tegra_pcie_soc {
>> unsigned int num_ports;
>> unsigned long pads_pll_ctl;
>> unsigned long tx_ref_sel;
>> + unsigned long afi_pex2_ctrl;
>> u32 pads_refclk_cfg0;
>> u32 pads_refclk_cfg1;
>> bool has_pex_clkreq_en;
>> @@ -209,7 +219,17 @@ struct tegra_pcie {
>> unsigned long xbar;
>>
>> const struct tegra_pcie_soc *soc;
>> +
>> +#ifdef CONFIG_TEGRA186
>> + struct clk clk_afi;
>> + struct clk clk_pex;
>> + struct reset_ctl reset_afi;
>> + struct reset_ctl reset_pex;
>> + struct reset_ctl reset_pcie_x;
>> + struct power_domain pwrdom;
>> +#else
>
> Eek. This is a compile-time driver configuration. Can you use the
> device tree compatible string to detect which to use?
No. The legacy APIs are simply not available (not compiled in) on the
newer SoCs, so there must be a compile-time condition.
It is theoretically possible to convert all the old SoCs to the new APIs
so that this conditional goes away in the future, but we don't have that
work scheduled at present.
More information about the U-Boot
mailing list