Documentation/ABI/testing/debugfs-dwc-pcie | 144 +++++ MAINTAINERS | 1 + drivers/pci/controller/dwc/Kconfig | 10 + drivers/pci/controller/dwc/Makefile | 1 + .../controller/dwc/pcie-designware-debugfs.c | 564 ++++++++++++++++++ .../pci/controller/dwc/pcie-designware-ep.c | 5 + .../pci/controller/dwc/pcie-designware-host.c | 6 + drivers/pci/controller/dwc/pcie-designware.c | 46 ++ drivers/pci/controller/dwc/pcie-designware.h | 21 + drivers/perf/dwc_pcie_pmu.c | 25 +- include/linux/pcie-dwc.h | 36 ++ 11 files changed, 837 insertions(+), 22 deletions(-) create mode 100644 Documentation/ABI/testing/debugfs-dwc-pcie create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.c create mode 100644 include/linux/pcie-dwc.h
DesignWare controller provides a vendor specific extended capability
called RASDES as an IP feature. This extended capability provides
hardware information like:
- Debug registers to know the state of the link or controller.
- Error injection mechanisms to inject various PCIe errors including
sequence number, CRC
- Statistical counters to know how many times a particular event
occurred
However, in Linux we do not have any generic or custom support to be
able to use this feature in an efficient manner. This is the reason we
are proposing this framework. Debug and bring up time of high-speed IPs
are highly dependent on costlier hardware analyzers and this solution
will in some ways help to reduce the HW analyzer usage.
The debugfs entries can be used to get information about underlying
hardware and can be shared with user space. Separate debugfs entries has
been created to cater to all the DES hooks provided by the controller.
The debugfs entries interacts with the RASDES registers in the required
sequence and provides the meaningful data to the user. This eases the
effort to understand and use the register information for debugging.
This series creates a generic debugfs framework for DesignWare PCIe
controllers where other debug features apart from RASDES can also be
added as and when required.
v7:
- Moved the patches to make finding VSEC IDs common from Mani's patchset [1]
into this series to remove dependancy as discussed
- Addressed style related change requests from v6
v6: https://lore.kernel.org/all/20250214105007.97582-1-shradha.t@samsung.com/
- Addressed Niklas's comment to make vsec ID finding similar to perf
- Minor changes in the driver to make the debugfs file common and
not specefic to RASDES so that other developers can add debug
related features to this file.
v5: https://lore.kernel.org/all/20250121111421.35437-1-shradha.t@samsung.com/
- Addressed Fan's comment to split the patches for easier review
- Addressed Bjorn's comment to fix vendor specific cap search
- Addressed style related change requests from v4
- Added rasdes debugfs init call to common designware files for host
and EP.
v4: https://lore.kernel.org/lkml/20241206074456.17401-1-shradha.t@samsung.com/
- Addressed comments from Manivannan, Bjorn and Jonathan
- Addressed style related change requests from v3
- Added Documentation under Documentation/ABI/testing and kdoc stype
comments wherever required for better understanding
- Enhanced error injection to include all possible error groups
- Removed debugfs init call from common designware file and left it
up to individual platform drivers to init/deinit as required.
v3: https://lore.kernel.org/all/20240625093813.112555-1-shradha.t@samsung.com/
- v2 had suggestions about moving this framework to perf/EDAC instead of a
controller specific debugfs but after discussions we decided to go ahead
with the same. Rebased and posted v3 with minor style changes.
v2: https://lore.kernel.org/lkml/20231130115044.53512-1-shradha.t@samsung.com/
- Addressed comments from Krzysztof Wilczyński, Bjorn Helgaas and
posted v2 with a changed implementation for a better code design
v1: https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.com/T/
[1] https://lore.kernel.org/all/20250218-pcie-qcom-ptm-v1-0-16d7e480d73e@linaro.org/
Manivannan Sadhasivam (1):
perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h'
Shradha Todi (4):
PCI: dwc: Add helper to find the Vendor Specific Extended Capability
(VSEC)
Add debugfs based silicon debug support in DWC
Add debugfs based error injection support in DWC
Add debugfs based statistical counter support in DWC
Documentation/ABI/testing/debugfs-dwc-pcie | 144 +++++
MAINTAINERS | 1 +
drivers/pci/controller/dwc/Kconfig | 10 +
drivers/pci/controller/dwc/Makefile | 1 +
.../controller/dwc/pcie-designware-debugfs.c | 564 ++++++++++++++++++
.../pci/controller/dwc/pcie-designware-ep.c | 5 +
.../pci/controller/dwc/pcie-designware-host.c | 6 +
drivers/pci/controller/dwc/pcie-designware.c | 46 ++
drivers/pci/controller/dwc/pcie-designware.h | 21 +
drivers/perf/dwc_pcie_pmu.c | 25 +-
include/linux/pcie-dwc.h | 36 ++
11 files changed, 837 insertions(+), 22 deletions(-)
create mode 100644 Documentation/ABI/testing/debugfs-dwc-pcie
create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.c
create mode 100644 include/linux/pcie-dwc.h
--
2.17.1
Hello Shradha, On Fri, Feb 21, 2025 at 06:45:43PM +0530, Shradha Todi wrote: > DesignWare controller provides a vendor specific extended capability > called RASDES as an IP feature. This extended capability provides > hardware information like: > - Debug registers to know the state of the link or controller. > - Error injection mechanisms to inject various PCIe errors including > sequence number, CRC > - Statistical counters to know how many times a particular event > occurred > > However, in Linux we do not have any generic or custom support to be > able to use this feature in an efficient manner. This is the reason we > are proposing this framework. Debug and bring up time of high-speed IPs > are highly dependent on costlier hardware analyzers and this solution > will in some ways help to reduce the HW analyzer usage. > > The debugfs entries can be used to get information about underlying > hardware and can be shared with user space. Separate debugfs entries has > been created to cater to all the DES hooks provided by the controller. > The debugfs entries interacts with the RASDES registers in the required > sequence and provides the meaningful data to the user. This eases the > effort to understand and use the register information for debugging. > > This series creates a generic debugfs framework for DesignWare PCIe > controllers where other debug features apart from RASDES can also be > added as and when required. > > v7: > - Moved the patches to make finding VSEC IDs common from Mani's patchset [1] > into this series to remove dependancy as discussed > - Addressed style related change requests from v6 I tested this series, and one thing that I noticed: # for f in /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/counter_enable; do echo 1 > $f; done # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/ctl_skp_os_parity_err/counter_enable:Counter Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/deskew_uncompleted_err/counter_enable:Counter Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/framing_err_in_l0/counter_enable:Counter Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/margin_crc_parity_err/counter_enable:Counter Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_1st/counter_enable:Counter Disabled /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_2nd/counter_enable:Counter Disabled that there are some events that cannot be enabled when testing on my platform, rk3588, perhaps this is because my version of the DWC IP does not have these events. (Because all the other events can be enabled successfully: # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Enabled | wc -l 29 ) So the question is, how do we want to handle that? E.g. counter_enable_write() could theoretically read back the dw_pcie_readl_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG); register after doing the ww_pcie_writel_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG, val); to actually check if it could enable the event. If counter_enable_write() could not enable the specific event, should it perhaps return a failure to user space? Or, do we want to keep the current behavior of just letting counter_enable_write() return success, even for events that are not supported by the specific DWC PCIe implementation? Kind regards, Niklas
On Mon, Feb 24, 2025 at 06:08:26PM +0100, Niklas Cassel wrote: > Hello Shradha, > > On Fri, Feb 21, 2025 at 06:45:43PM +0530, Shradha Todi wrote: > > DesignWare controller provides a vendor specific extended capability > > called RASDES as an IP feature. This extended capability provides > > hardware information like: > > - Debug registers to know the state of the link or controller. > > - Error injection mechanisms to inject various PCIe errors including > > sequence number, CRC > > - Statistical counters to know how many times a particular event > > occurred > > > > However, in Linux we do not have any generic or custom support to be > > able to use this feature in an efficient manner. This is the reason we > > are proposing this framework. Debug and bring up time of high-speed IPs > > are highly dependent on costlier hardware analyzers and this solution > > will in some ways help to reduce the HW analyzer usage. > > > > The debugfs entries can be used to get information about underlying > > hardware and can be shared with user space. Separate debugfs entries has > > been created to cater to all the DES hooks provided by the controller. > > The debugfs entries interacts with the RASDES registers in the required > > sequence and provides the meaningful data to the user. This eases the > > effort to understand and use the register information for debugging. > > > > This series creates a generic debugfs framework for DesignWare PCIe > > controllers where other debug features apart from RASDES can also be > > added as and when required. > > > > v7: > > - Moved the patches to make finding VSEC IDs common from Mani's patchset [1] > > into this series to remove dependancy as discussed > > - Addressed style related change requests from v6 > > I tested this series, and one thing that I noticed: > > # for f in /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/counter_enable; do echo 1 > $f; done > > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/ctl_skp_os_parity_err/counter_enable:Counter Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/deskew_uncompleted_err/counter_enable:Counter Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/framing_err_in_l0/counter_enable:Counter Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/margin_crc_parity_err/counter_enable:Counter Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_1st/counter_enable:Counter Disabled > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_2nd/counter_enable:Counter Disabled > > that there are some events that cannot be enabled when testing on my platform, > rk3588, perhaps this is because my version of the DWC IP does not have these > events. > > (Because all the other events can be enabled successfully: > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Enabled | wc -l > 29 > ) > > > So the question is, how do we want to handle that? > This is a really good question. > E.g. counter_enable_write() could theoretically read back the > dw_pcie_readl_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG); > register after doing the > ww_pcie_writel_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG, val); > > to actually check if it could enable the event. > > If counter_enable_write() could not enable the specific event, should it > perhaps return a failure to user space? > Yes, it would be appropriate to return -EOPNOTSUPP in that case. But I'd like to merge this series asap. So this patch can come on top of this series. - Mani -- மணிவண்ணன் சதாசிவம்
On Tue, Feb 25, 2025 at 01:58:35PM +0530, Manivannan Sadhasivam wrote: > On Mon, Feb 24, 2025 at 06:08:26PM +0100, Niklas Cassel wrote: > > Hello Shradha, > > > > On Fri, Feb 21, 2025 at 06:45:43PM +0530, Shradha Todi wrote: > > > DesignWare controller provides a vendor specific extended capability > > > called RASDES as an IP feature. This extended capability provides > > > hardware information like: > > > - Debug registers to know the state of the link or controller. > > > - Error injection mechanisms to inject various PCIe errors including > > > sequence number, CRC > > > - Statistical counters to know how many times a particular event > > > occurred > > > > > > However, in Linux we do not have any generic or custom support to be > > > able to use this feature in an efficient manner. This is the reason we > > > are proposing this framework. Debug and bring up time of high-speed IPs > > > are highly dependent on costlier hardware analyzers and this solution > > > will in some ways help to reduce the HW analyzer usage. > > > > > > The debugfs entries can be used to get information about underlying > > > hardware and can be shared with user space. Separate debugfs entries has > > > been created to cater to all the DES hooks provided by the controller. > > > The debugfs entries interacts with the RASDES registers in the required > > > sequence and provides the meaningful data to the user. This eases the > > > effort to understand and use the register information for debugging. > > > > > > This series creates a generic debugfs framework for DesignWare PCIe > > > controllers where other debug features apart from RASDES can also be > > > added as and when required. > > > > > > v7: > > > - Moved the patches to make finding VSEC IDs common from Mani's patchset [1] > > > into this series to remove dependancy as discussed > > > - Addressed style related change requests from v6 > > > > I tested this series, and one thing that I noticed: > > > > # for f in /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/counter_enable; do echo 1 > $f; done > > > > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/ctl_skp_os_parity_err/counter_enable:Counter Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/deskew_uncompleted_err/counter_enable:Counter Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/framing_err_in_l0/counter_enable:Counter Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/margin_crc_parity_err/counter_enable:Counter Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_1st/counter_enable:Counter Disabled > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_2nd/counter_enable:Counter Disabled > > > > that there are some events that cannot be enabled when testing on my platform, > > rk3588, perhaps this is because my version of the DWC IP does not have these > > events. > > > > (Because all the other events can be enabled successfully: > > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Enabled | wc -l > > 29 > > ) > > > > > > So the question is, how do we want to handle that? > > > > This is a really good question. > > > E.g. counter_enable_write() could theoretically read back the > > dw_pcie_readl_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG); > > register after doing the > > ww_pcie_writel_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG, val); > > > > to actually check if it could enable the event. > > > > If counter_enable_write() could not enable the specific event, should it > > perhaps return a failure to user space? > > > > Yes, it would be appropriate to return -EOPNOTSUPP in that case. But I'd like to > merge this series asap. So this patch can come on top of this series. I agree that returning an error is probably the nicest thing. However, this series has been picked up already :) Is there anyone who volunteers on implementing the proposed feature? If you have time, it would be interesting to see if you see the same behavior on QCOM SoCs. (Assuming that your DWC PCIe controller does not implement all events that Samsung DWC PCIe controller does.) Kind regards, Niklas
On Tue, Feb 25, 2025 at 03:35:25PM +0100, Niklas Cassel wrote: > On Tue, Feb 25, 2025 at 01:58:35PM +0530, Manivannan Sadhasivam wrote: > > On Mon, Feb 24, 2025 at 06:08:26PM +0100, Niklas Cassel wrote: > > > Hello Shradha, > > > > > > On Fri, Feb 21, 2025 at 06:45:43PM +0530, Shradha Todi wrote: > > > > DesignWare controller provides a vendor specific extended capability > > > > called RASDES as an IP feature. This extended capability provides > > > > hardware information like: > > > > - Debug registers to know the state of the link or controller. > > > > - Error injection mechanisms to inject various PCIe errors including > > > > sequence number, CRC > > > > - Statistical counters to know how many times a particular event > > > > occurred > > > > > > > > However, in Linux we do not have any generic or custom support to be > > > > able to use this feature in an efficient manner. This is the reason we > > > > are proposing this framework. Debug and bring up time of high-speed IPs > > > > are highly dependent on costlier hardware analyzers and this solution > > > > will in some ways help to reduce the HW analyzer usage. > > > > > > > > The debugfs entries can be used to get information about underlying > > > > hardware and can be shared with user space. Separate debugfs entries has > > > > been created to cater to all the DES hooks provided by the controller. > > > > The debugfs entries interacts with the RASDES registers in the required > > > > sequence and provides the meaningful data to the user. This eases the > > > > effort to understand and use the register information for debugging. > > > > > > > > This series creates a generic debugfs framework for DesignWare PCIe > > > > controllers where other debug features apart from RASDES can also be > > > > added as and when required. > > > > > > > > v7: > > > > - Moved the patches to make finding VSEC IDs common from Mani's patchset [1] > > > > into this series to remove dependancy as discussed > > > > - Addressed style related change requests from v6 > > > > > > I tested this series, and one thing that I noticed: > > > > > > # for f in /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/counter_enable; do echo 1 > $f; done > > > > > > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/ctl_skp_os_parity_err/counter_enable:Counter Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/deskew_uncompleted_err/counter_enable:Counter Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/framing_err_in_l0/counter_enable:Counter Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/margin_crc_parity_err/counter_enable:Counter Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_1st/counter_enable:Counter Disabled > > > /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/retimer_parity_err_2nd/counter_enable:Counter Disabled > > > > > > that there are some events that cannot be enabled when testing on my platform, > > > rk3588, perhaps this is because my version of the DWC IP does not have these > > > events. > > > > > > (Because all the other events can be enabled successfully: > > > # grep "" /sys/kernel/debug/dwc_pcie_a40000000.pcie/rasdes_event_counter/*/* | grep Enabled | wc -l > > > 29 > > > ) > > > > > > > > > So the question is, how do we want to handle that? > > > > > > > This is a really good question. > > > > > E.g. counter_enable_write() could theoretically read back the > > > dw_pcie_readl_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG); > > > register after doing the > > > ww_pcie_writel_dbi(pci, rinfo->ras_cap_offset + RAS_DES_EVENT_COUNTER_CTRL_REG, val); > > > > > > to actually check if it could enable the event. > > > > > > If counter_enable_write() could not enable the specific event, should it > > > perhaps return a failure to user space? > > > > > > > Yes, it would be appropriate to return -EOPNOTSUPP in that case. But I'd like to > > merge this series asap. So this patch can come on top of this series. > > I agree that returning an error is probably the nicest thing. > > However, this series has been picked up already :) > > Is there anyone who volunteers on implementing the proposed feature? > I did and submitted the fix [1]. > If you have time, it would be interesting to see if you see the same behavior > on QCOM SoCs. (Assuming that your DWC PCIe controller does not implement all > events that Samsung DWC PCIe controller does.) > Yeah, I observed the same behavior on the Qcom platform, though only 2 counters were not supported. But I also noticed a null ptr dereference due to refclk dependency, so submitted a fix for that also. - Mani [1] https://lore.kernel.org/linux-pci/20250225171239.19574-1-manivannan.sadhasivam@linaro.org/ -- மணிவண்ணன் சதாசிவம்
Hello, [...] > Yes, it would be appropriate to return -EOPNOTSUPP in that case. But I'd like to > merge this series asap. So this patch can come on top of this series. I pulled the series so that we can get some mileage out of the 0-day bot, so to speak, and also get some testing via the linux-next tree. That said, while looking at the code, there have been bits where I wanted to get some clarification. Nothing will be a blocker. Krzysztof
>Subject: [PATCH v7 0/5] Add support for debugfs based RAS DES feature in > PCIe DW >Date: Fri, 21 Feb 2025 18:45:43 +0530 >Message-Id: <20250221131548.59616-1-shradha.t@samsung.com> >X-Mailer: git-send-email 2.17.1 >Precedence: bulk >X-Mailing-List: linux-kernel@vger.kernel.org >List-Id: <linux-kernel.vger.kernel.org> >List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> >List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> >MIME-Version: 1.0 >Content-Transfer-Encoding: 8bit >X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJsWRmVeSWpSXmKPExsWy7bCmum7f2p3pBpev8Fhcaf/NbjH9sKLF > kqYMi2MTVjBbNK2+y2qx4stMdotVC6+xWTT0/Ga12PT4GqvF5V1z2CzOzjvOZnFl6zoWi5Y/ > LSwWd1s6WS2WXr/IZPF3215Gi0Vbv7BbLGx+yWjxf88Odovew7UWLXdMLd7/3MzmIOaxeMUU > Vo8189YweuycdZfdY8GmUo+WI29ZPTat6mTzuHNtD5vHzoeWHk+uTGfy2Lyk3qNvyypGj8+b > 5AJ4orJtMlITU1KLFFLzkvNTMvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4C+ > VVIoS8wpBQoFJBYXK+nb2RTll5akKmTkF5fYKqUWpOQUmBToFSfmFpfmpevlpZZYGRoYGJkC > FSZkZ9w5vYalYLZqxYb7X5gaGB/IdjFyckgImEi83vKXqYuRi0NIYDejxLsX7UwgCSGBT4wS > u6dkQySA7IMTF7PDdKyZ08QKkdjJKHFn3nso5wujxL2+j2BVbAJaEo1fu5hBbBGBVkaJI8/E > QIqYBbYxSxxYsQIsISwQJPFjXRsLiM0ioCrx/e98oGYODl4BK4k9K+0htslLrN5wAKycV0BQ > 4uTMJ2DlzEDx5q2zmSFqvnBIfJnNB2G7SCzadQPqUmGJV8e3QNlSEp/f7WWDsNMlVm6eAdWb > I/Ft8xImCNte4sCVOSwgJzALaEqs36UPEZaVmHpqHRPEWj6J3t9PoMp5JXbMg7GVJb783cMC > YUtKzDt2mRXC9pDYufkh2EghgViJ/v+2ExjlZyF5ZhaSZ2YhLF7AyLyKUTK1oDg3PTXZtMAw > L7UcHq3J+bmbGMFJXstlB+ON+f/0DjEycTAeYpTgYFYS4dUt2ZEuxJuSWFmVWpQfX1Sak1p8 > iNEUGMATmaVEk/OBeSavJN7QxNLAxMzMzMTS2MxQSZy3eWdLupBAemJJanZqakFqEUwfEwen > VAOTyWph2UVGD0z1j0+NvfvEdnGQ413ON1OnCFx4vMfJeqvN3Mp7Kx86NXwKsN+sdkziZXTt > kesTTnswSfQ/W1W2UrvUr+Mf14yGGbL9V1cY802NfhC1Su7CI57OFPH5lz5En/srKjG9MXbJ > wbvLF2vMuPtkX2nEE4bFtdvOlN1YvEY1xMF6apLnj5CG0sSSXn3PgKUsajzVWQ/TfU7n/lD5 > bfjrwVJLhqPcRqoTSkq8zi29HTM1wO3dCcNfq6we9H4Sbrx8ef67MN+3L8NLzveyuAo5iV1+ > s8+BVbngfu6khvO+c9YriUadC2QxkJvBY3eiVHQx3yuDqBXzeubVRsnkfzzpt9tl19/cGTOv > 1GuzKrEUZyQaajEXFScCAMosolJ7BAAA >X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsWy7bCSvG537Y50g2MLlC2utP9mt5h+WNFi > SVOGxbEJK5gtmlbfZbVY8WUmu8WqhdfYLBp6frNabHp8jdXi8q45bBZn5x1ns7iydR2LRcuf > FhaLuy2drBZLr19ksvi7bS+jxaKtX9gtFja/ZLT4v2cHu0Xv4VqLljumFu9/bmZzEPNYvGIK > q8eaeWsYPXbOusvusWBTqUfLkbesHptWdbJ53Lm2h81j50NLjydXpjN5bF5S79G3ZRWjx+dN > cgE8UVw2Kak5mWWpRfp2CVwZd06vYSmYrVqx4f4XpgbGB7JdjJwcEgImEmvmNLF2MXJxCAls > Z5Q4cm4FE0RCUuLzxXVQtrDEyn/P2SGKPjFKnLi3HyzBJqAl0fi1ixkkISLQySix98g7sCpm > gXPMEjM/tzCCVAkLBEicWbwezGYRUJX4/nc+UBEHB6+AlcSelfYQG+QlVm84wAxi8woISpyc > +YQFpIRZQF1i/TwhkDAzUEnz1tnMExj5ZyGpmoVQNQtJ1QJG5lWMoqkFxbnpuckFhnrFibnF > pXnpesn5uZsYwbGpFbSDcdn6v3qHGJk4GA8xSnAwK4nw6pbsSBfiTUmsrEotyo8vKs1JLT7E > KM3BoiTOq5zTmSIkkJ5YkpqdmlqQWgSTZeLglGpg4pjMtu2b3EL3R9/vnl2nEvFC55TM2YSA > my6J94qZeTt8782a/COa5zfzt5k3prcfseJ7luLkekH78Adlm03yN7mZkk1XMM56/M3uTPar > ex8KP295FMh6s2nhnKm/5osxdX5TKq3b61nX9iT1YXNdyKerQsdqYjgT+VaEJK99GX3A6He8 > 1XIWZ2vz9ffnsnQutJ2jtMajR/n7bM0NmbNmena/SZXhnfzD5alN2PFWrd0vK8Je8Blf3/b1 > x9bwBX5/Yl/s/XhNzGKZrer2uvBbUQqvGNOWb17bYhX/xT3W2q3tpEjcHY7SxiIpxtc63+us > rinukH9y8IUFl3ej4vrW9/u/5z0wPMPHsW9quEntZSWW4oxEQy3mouJEAI4aFoM8AwAA >X-CMS-MailID: 20250221132011epcas5p4dea1e9ae5c09afaabcd1822f3a7d15c5 >X-Msg-Generator: CA >Content-Type: text/plain; charset="utf-8" >X-Sendblock-Type: REQ_APPROVE >CMS-TYPE: 105P >DLP-Filter: Pass >X-CFilter-Loop: Reflected >X-CMS-RootMailID: 20250221132011epcas5p4dea1e9ae5c09afaabcd1822f3a7d15c5 >References: <CGME20250221132011epcas5p4dea1e9ae5c09afaabcd1822f3a7d15c5@epcas5p4.samsung.com> > >DesignWare controller provides a vendor specific extended capability >called RASDES as an IP feature. This extended capability provides >hardware information like: > - Debug registers to know the state of the link or controller. > - Error injection mechanisms to inject various PCIe errors including > sequence number, CRC > - Statistical counters to know how many times a particular event > occurred > >However, in Linux we do not have any generic or custom support to be >able to use this feature in an efficient manner. This is the reason we >are proposing this framework. Debug and bring up time of high-speed IPs >are highly dependent on costlier hardware analyzers and this solution >will in some ways help to reduce the HW analyzer usage. > >The debugfs entries can be used to get information about underlying >hardware and can be shared with user space. Separate debugfs entries has >been created to cater to all the DES hooks provided by the controller. >The debugfs entries interacts with the RASDES registers in the required >sequence and provides the meaningful data to the user. This eases the >effort to understand and use the register information for debugging. > >This series creates a generic debugfs framework for DesignWare PCIe >controllers where other debug features apart from RASDES can also be >added as and when required. > >v7: > - Moved the patches to make finding VSEC IDs common from Mani's patchset [1] > into this series to remove dependancy as discussed > - Addressed style related change requests from v6 > >v6: https://lore.kernel.org/all/20250214105007.97582-1-shradha.t@samsung.com/ > - Addressed Niklas's comment to make vsec ID finding similar to perf > - Minor changes in the driver to make the debugfs file common and > not specefic to RASDES so that other developers can add debug > related features to this file. > >v5: https://lore.kernel.org/all/20250121111421.35437-1-shradha.t@samsung.com/ > - Addressed Fan's comment to split the patches for easier review > - Addressed Bjorn's comment to fix vendor specific cap search > - Addressed style related change requests from v4 > - Added rasdes debugfs init call to common designware files for host > and EP. > >v4: https://lore.kernel.org/lkml/20241206074456.17401-1-shradha.t@samsung.com/ > - Addressed comments from Manivannan, Bjorn and Jonathan > - Addressed style related change requests from v3 > - Added Documentation under Documentation/ABI/testing and kdoc stype > comments wherever required for better understanding > - Enhanced error injection to include all possible error groups > - Removed debugfs init call from common designware file and left it > up to individual platform drivers to init/deinit as required. > >v3: https://lore.kernel.org/all/20240625093813.112555-1-shradha.t@samsung.com/ > - v2 had suggestions about moving this framework to perf/EDAC instead of a > controller specific debugfs but after discussions we decided to go ahead > with the same. Rebased and posted v3 with minor style changes. > >v2: https://lore.kernel.org/lkml/20231130115044.53512-1-shradha.t@samsung.com/ > - Addressed comments from Krzysztof Wilczyński, Bjorn Helgaas and > posted v2 with a changed implementation for a better code design > >v1: https://lore.kernel.org/all/20210518174618.42089-1-shradha.t@samsung.com/T/ > >[1] https://lore.kernel.org/all/20250218-pcie-qcom-ptm-v1-0-16d7e480d73e@linaro.org/ > >Manivannan Sadhasivam (1): > perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h' > >Shradha Todi (4): > PCI: dwc: Add helper to find the Vendor Specific Extended Capability > (VSEC) > Add debugfs based silicon debug support in DWC > Add debugfs based error injection support in DWC > Add debugfs based statistical counter support in DWC > > Documentation/ABI/testing/debugfs-dwc-pcie | 144 +++++ > MAINTAINERS | 1 + > drivers/pci/controller/dwc/Kconfig | 10 + > drivers/pci/controller/dwc/Makefile | 1 + > .../controller/dwc/pcie-designware-debugfs.c | 564 ++++++++++++++++++ > .../pci/controller/dwc/pcie-designware-ep.c | 5 + > .../pci/controller/dwc/pcie-designware-host.c | 6 + > drivers/pci/controller/dwc/pcie-designware.c | 46 ++ > drivers/pci/controller/dwc/pcie-designware.h | 21 + > drivers/perf/dwc_pcie_pmu.c | 25 +- > include/linux/pcie-dwc.h | 36 ++ > 11 files changed, 837 insertions(+), 22 deletions(-) > create mode 100644 Documentation/ABI/testing/debugfs-dwc-pcie > create mode 100644 drivers/pci/controller/dwc/pcie-designware-debugfs.c > create mode 100644 include/linux/pcie-dwc.h > >-- >2.17.1 > > Thanks for adding the support! Tested the patch in one of our internal SoC with DesginWare PCIe controller. The patch works fine. Tested-by: Hrishikesh Deleep <hrishikesh.d@samsung.com>
Hello, > Thanks for adding the support! > > Tested the patch in one of our internal SoC with DesginWare PCIe controller. The patch works fine. I assume this was for an entire series, not any specific patch. > Tested-by: Hrishikesh Deleep <hrishikesh.d@samsung.com> Thank you for testing! I will add your tag to the current branch. Krzysztof
Hello, > DesignWare controller provides a vendor specific extended capability > called RASDES as an IP feature. This extended capability provides > hardware information like: > - Debug registers to know the state of the link or controller. > - Error injection mechanisms to inject various PCIe errors including > sequence number, CRC > - Statistical counters to know how many times a particular event > occurred > > However, in Linux we do not have any generic or custom support to be > able to use this feature in an efficient manner. This is the reason we > are proposing this framework. Debug and bring up time of high-speed IPs > are highly dependent on costlier hardware analyzers and this solution > will in some ways help to reduce the HW analyzer usage. > > The debugfs entries can be used to get information about underlying > hardware and can be shared with user space. Separate debugfs entries has > been created to cater to all the DES hooks provided by the controller. > The debugfs entries interacts with the RASDES registers in the required > sequence and provides the meaningful data to the user. This eases the > effort to understand and use the register information for debugging. > > This series creates a generic debugfs framework for DesignWare PCIe > controllers where other debug features apart from RASDES can also be > added as and when required. Applied to controller/dwc, thank you! Krzysztof
© 2016 - 2025 Red Hat, Inc.