“4610e4137b5fb93042a248928a2c0049ef7d4190”上不存在“tools/perf/ui/helpline.h”
  1. 23 11月, 2022 5 次提交
    • S
      PCI: dwc: Introduce generic platform clocks and resets · ef69f852
      Serge Semin 提交于
      Currently almost each platform driver uses its own resets and clocks
      naming in order to get the corresponding descriptors. It makes the code
      harder to maintain and comprehend especially seeing the DWC PCIe core main
      resets and clocks signals set hasn't changed much for about at least one
      major IP-core release. So in order to organize things around these signals
      we suggest to create a generic interface for them in accordance with the
      naming introduced in the DWC PCIe IP-core reference manual:
      
      Application clocks:
      - "dbi"  - data bus interface clock (on some DWC PCIe platforms it's
                 referred as "pclk", "pcie", "sys", "ahb", "cfg", "iface",
                 "gio", "reg", "pcie_apb_sys");
      - "mstr" - AXI-bus master interface clock (some DWC PCIe glue drivers
                 refer to this clock as "port", "bus", "pcie_bus",
                 "bus_master/master_bus/axi_m", "pcie_aclk");
      - "slv"  - AXI-bus slave interface clock (also called as "port", "bus",
                 "pcie_bus", "bus_slave/slave_bus/axi_s", "pcie_aclk",
                 "pcie_inbound_axi").
      
      Core clocks:
      - "pipe" - core-PCS PIPE interface clock coming from external PHY (it's
                 normally named by the platform drivers as just "pipe");
      - "core" - primary clock of the controller (none of the platform drivers
                 declare such a clock but in accordance with the ref. manual
                 the devices may have it separately specified);
      - "aux"  - auxiliary PMC domain clock (it is named by some platforms as
                 "pcie_aux" and just "aux");
      - "ref"  - Generic reference clock (it is a generic clock source, which
                 can be used as a signal source for multiple interfaces, some
                 platforms call it as "ref", "general", "pcie_phy",
                 "pcie_phy_ref").
      
      Application resets:
      - "dbi"  - Data-bus interface reset (it's CSR interface clock and is
                 normally called as "apb" though technically it's not APB but
                 DWC PCIe-specific interface);
      - "mstr" - AXI-bus master reset (some platforms call it as "port", "apps",
                 "bus", "axi_m");
      - "slv"  - ABI-bus slave reset (some platforms call it as "port", "apps",
                 "bus", "axi_s").
      
      Core resets:
      - "non-sticky" - non-sticky CSR flags reset;
      - "sticky"     - sticky CSR flags reset;
      - "pipe"       - PIPE-interface (Core-PCS) logic reset (some platforms
                       call it just "pipe");
      - "core"       - controller primary reset (resets everything except PMC
                       module, some platforms refer to this signal as "soft",
                       "pci");
      - "phy"        - PCS/PHY block reset (strictly speaking it is normally
                       connected to the input of an external block, but the
                       reference manual says it must be available for the PMC
                       working correctly, some existing platforms call it
                       "pciephy", "phy", "link");
      - "hot"        - PMC hot reset signal (also called as "sleep");
      - "pwr"        - cold reset signal (can be referred as "pwr", "turnoff").
      
      Bus reset:
      - "perst" - PCIe standard signal used to reset the PCIe peripheral
                  devices.
      
      As you can see each platform uses it's own naming for basically the same
      set of the signals. In the framework of this commit we suggest to add a
      set of the clocks and reset signals resources, corresponding names and
      identifiers for each denoted entity. At current stage the platforms will
      be able to use the provided infrastructure to automatically request all
      these resources and manipulate with them in the Host/EP init callbacks.
      Alas it isn't that easy to create a common cold/hot reset procedure due to
      too many platform-specifics in the procedure, like the external flags
      exposure and the delays requirement.
      
      Link: https://lore.kernel.org/r/20221113191301.5526-20-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
      ef69f852
    • S
      PCI: dwc: Combine iATU detection procedures · 9f67ecdd
      Serge Semin 提交于
      Since the iATU CSR region is now retrieved in the DW PCIe resources getter
      there is no much benefits in the iATU detection procedures splitting up.
      Therefore let's join the iATU unroll/viewport detection procedure with the
      rest of the iATU parameters detection code. The resultant method will be
      as coherent as before, while the redundant functions will be eliminated
      thus producing more readable code.
      
      Link: https://lore.kernel.org/r/20221113191301.5526-19-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      9f67ecdd
    • S
      PCI: dwc: Introduce generic resources getter · ef8c5887
      Serge Semin 提交于
      Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in
      the separate parts of the DW PCIe core driver. It doesn't really make
      sense since the both controller types have identical set of the core CSR
      regions: DBI, DBI CS2 and iATU/eDMA. Thus we can simplify the DW PCIe Host
      and EP initialization methods by moving the platform-specific registers
      space getting and mapping into a common method. It gets to be even more
      justified seeing the CSRs base address pointers are preserved in the
      common DW PCIe descriptor. Note all the OF-based common DW PCIe settings
      initialization will be moved to the new method too in order to have a
      single function for all the generic platform properties handling in single
      place.
      
      A nice side-effect of this change is that the pcie-designware-host.c and
      pcie-designware-ep.c drivers are cleaned up from all the direct dw_pcie
      storage modification, which makes the DW PCIe core, Root Port and Endpoint
      modules more coherent.
      
      Link: https://lore.kernel.org/r/20221113191301.5526-18-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      ef8c5887
    • S
      PCI: dwc: Introduce generic controller capabilities interface · 7f9e982d
      Serge Semin 提交于
      Since in addition to the already available iATU unrolled mapping we are
      about to add a few more DW PCIe platform-specific capabilities (CDM-check
      and generic clocks/resets resources) let's add a generic interface to set
      and get the flags indicating their availability. The new interface shall
      improve maintainability of the platform-specific code.
      
      Link: https://lore.kernel.org/r/20221113191301.5526-17-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      7f9e982d
    • S
      PCI: dwc: Introduce dma-ranges property support for RC-host · 8522e17d
      Serge Semin 提交于
      In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges"
      property has the same format as the "ranges" property. The only difference
      is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU
      memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges"
      property. Even though the DW PCIe controllers are normally equipped with
      the internal Address Translation Unit which inbound and outbound tables
      can be used to implement both properties semantics, it was surprising for
      me to discover that the host-related part of the DW PCIe driver currently
      supports the "ranges" property only while the "dma-ranges" windows are
      just ignored. Having the "dma-ranges" supported in the driver would be
      very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory
      mapping and require a customized PCIe memory layout. So let's fix that by
      introducing the "dma-ranges" property support.
      
      First of all we suggest to rename the dw_pcie_prog_inbound_atu() method to
      dw_pcie_prog_ep_inbound_atu() and create a new version of the
      dw_pcie_prog_inbound_atu() function. Thus we'll have two methods for the
      RC and EP controllers respectively in the same way as it has been
      developed for the outbound ATU setup methods.
      
      Secondly aside with the memory window index and type the new
      dw_pcie_prog_inbound_atu() function will accept CPU address, PCIe address
      and size as its arguments. These parameters define the PCIe and CPU memory
      ranges which will be used to setup the respective inbound ATU mapping. The
      passed parameters need to be verified against the ATU ranges constraints
      in the same way as it is done for the outbound ranges.
      
      Finally the DMA-ranges detected for the PCIe controller need to be
      converted to the inbound ATU entries during the host controller
      initialization procedure. It will be done in the framework of the
      dw_pcie_iatu_setup() method. Note before setting the inbound ranges up we
      need to disable all the inbound ATU entries in order to prevent unexpected
      PCIe TLPs translations defined by some third party software like
      bootloaders.
      
      Link: https://lore.kernel.org/r/20221113191301.5526-16-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      8522e17d
  2. 10 11月, 2022 1 次提交
  3. 27 10月, 2022 1 次提交
  4. 02 8月, 2022 9 次提交
  5. 06 7月, 2022 8 次提交
  6. 02 12月, 2021 1 次提交
  7. 30 9月, 2021 1 次提交
  8. 30 4月, 2021 1 次提交
  9. 25 2月, 2021 4 次提交
  10. 19 11月, 2020 2 次提交
  11. 13 10月, 2020 1 次提交
  12. 28 9月, 2020 1 次提交
  13. 21 9月, 2020 1 次提交
  14. 10 9月, 2020 3 次提交
    • R
      PCI: dwc: Move N_FTS setup to common setup · aeaa0bfe
      Rob Herring 提交于
      The Designware controller has common registers to set number of fast
      training sequence ordered sets. The Artpec6, Intel, and Tegra driver
      initialize these register fields. Let's move the initialization to the
      common setup code and drivers just have to provide the value.
      
      There's a slight change in that the common clock mode N_FTS field is
      now initialized. Previously only the Intel driver set this. It's not
      clear from the code if common clock mode is used in the Artpec6 or Tegra
      driver. It depends on the DWC configuration. Given the field is not
      initialized while the others are, it seems unlikely common clock mode
      is used.
      
      Link: https://lore.kernel.org/r/20200821035420.380495-40-robh@kernel.orgSigned-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Jingoo Han <jingoohan1@gmail.com>
      Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Cc: linux-tegra@vger.kernel.org
      aeaa0bfe
    • R
      PCI: dwc: Set PORT_LINK_DLL_LINK_EN in common setup code · 441e48fd
      Rob Herring 提交于
      The Intel driver is the only one to set PORT_LINK_DLL_LINK_EN. The
      default value is set and it seems pretty certain that enabling link
      initialization is always required. Maybe it could just be dropped from
      the Intel driver, but lets move setting it into the common code to be
      sure.
      
      Link: https://lore.kernel.org/r/20200821035420.380495-36-robh@kernel.orgSigned-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Dilip Kota <eswara.kota@linux.intel.com>
      Cc: Jingoo Han <jingoohan1@gmail.com>
      Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      441e48fd
    • R
      PCI: dwc: Centralize link gen setting · 39bc5006
      Rob Herring 提交于
      keystone would force gen2 if no DT property. Now it relies on the
      PCI_EXP_LNKCAP value.
      
      Link: https://lore.kernel.org/r/20200821035420.380495-35-robh@kernel.orgSigned-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Richard Zhu <hongxing.zhu@nxp.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: NXP Linux Team <linux-imx@nxp.com>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: Jingoo Han <jingoohan1@gmail.com>
      Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
      Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
      Cc: Andy Gross <agross@kernel.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Pratyush Anand <pratyush.anand@gmail.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Cc: linux-omap@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arm-msm@vger.kernel.org
      Cc: linux-tegra@vger.kernel.org
      39bc5006
  15. 08 9月, 2020 1 次提交