Designware EP support and code clean up
Subsystems (6)
v7 cover Designware EP support and code clean up
The patch set was made against the Lorenzo's master branch.
Adds support Designware EP support.
Increases the maximum number of interrupts allowed for Designware IP controller.
Does a code cleanup on Designware driver:
- Replaces magic numbers without a easy meaning by a well known define that helps the human compreension.
- Replaces a division by 2 by a simple right shift rotation of 1 bit.
- Fixes all first letter characters on comments and debug messages to upper case to maintain coherency.
Gustavo Pimentel (9):
bindings: PCI: designware: Example update
PCI: dwc: Add support for endpoint mode
PCI: endpoint: functions/pci-epf-test: Add second entry
bindings: PCI: designware: Add support for the EP in Designware driver
misc: pci_endpoint_test: Add designware EP entry
PCI: dwc: Define maximum number of vectors
PCI: dwc: Replace lower into upper case characters
PCI: dwc: Small computation improvement
PCI: dwc: Replace magic number by defines
.../PCI/endpoint/function/binding/pci-test.txt | 2 + .../devicetree/bindings/pci/designware-pcie.txt | 24 +++- drivers/misc/pci_endpoint_test.c | 1 + drivers/pci/dwc/Kconfig | 41 ++++-- drivers/pci/dwc/pcie-designware-ep.c | 16 +-- drivers/pci/dwc/pcie-designware-host.c | 77 +++++----- drivers/pci/dwc/pcie-designware-plat.c | 155 +++++++++++++++++++-- drivers/pci/dwc/pcie-designware.c | 22 +-- drivers/pci/dwc/pcie-designware.h | 1 + drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++ 10 files changed, 267 insertions(+), 80 deletions(-)
Signature · 1 line
2.7.4
PATCH v7 1/9 bindings: PCI: designware: Example update
Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers, however it still be compatible with any previous DT that uses the old reg-name.
Replaces the PCIe base address example by a real PCIe base address in use.
---
Changes v1->v2:
- Removed any iATU reference or changes to avoid confusion.
- Add "snps,dw-pcie" compatible string following Kishon's suggestion.
Changes v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Documentation/devicetree/bindings/pci/designware-pcie.txt +6 -6
@@ -1,7 +1,8 @@ * Synopsys DesignWare PCIe interface Required properties: -- compatible: should contain "snps,dw-pcie" to identify the core. +- compatible: + "snps,dw-pcie" for RC mode; - reg: Should contain the configuration address space. - reg-names: Must be "config" for the PCIe configuration space. (The old way of getting the configuration address space from "ranges"
@@ -41,11 +42,11 @@ EP mode: Example configuration: - pcie: pcie@dffff000 { + pcie: pcie@dfc00000 { compatible = "snps,dw-pcie"; - reg = <0xdffff000 0x1000>, /* Controller registers */ - <0xd0000000 0x2000>; /* PCI config space */ - reg-names = "ctrlreg", "config"; + reg = <0xdfc00000 0x0001000>, /* IP registers */ + <0xd0000000 0x0002000>; /* Configuration space */ + reg-names = "dbi", "config"; #address-cells = <3>; #size-cells = <2>; device_type = "pci";
@@ -54,5 +55,4 @@ Example configuration: interrupts = <25>, <24>; #interrupt-cells = <1>; num-lanes = <1>; - num-viewport = <3>; };
Signature · 1 line
2.7.4
PATCH v7 2/9 PCI: dwc: Add support for endpoint mode
In reply to Gustavo PimentelThe PCIe controller dual mode is capable of operating in host mode as well as endpoint mode by configuration, therefore this patch aims to add endpoint mode support to the designware driver.
---
Change v1->v2:
- Removed dw_plat_pcie_stop_link empty function.
- Implemented Kishon's suggestions about dw-pcie-rc and dw-pcie strings.
compatibility.
- Added second entry on pci_epf_test_ids structure.
Changes v2->v3:
- Reverted additions in dw_pcie_ep_linkup function.
- Replaced devm_ioremap by devm_ioremap_resource function.
- Moved second entry in pci_epf_test_ids structure into a new patch file.
Changes v3->v4:
- Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Removed PCIE_DW_PLAT entry helps and description in order to be hidden.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/pci/dwc/Kconfig | 41 ++++++--- drivers/pci/dwc/pcie-designware-plat.c | 149 ++++++++++++++++++++++++++++++--- 2 files changed, 169 insertions(+), 21 deletions(-)
drivers/pci/dwc/Kconfig +30 -11
@@ -7,8 +7,7 @@ config PCIE_DW config PCIE_DW_HOST bool - depends on PCI - depends on PCI_MSI_IRQ_DOMAIN + depends on PCI && PCI_MSI_IRQ_DOMAIN select PCIE_DW config PCIE_DW_EP
@@ -51,17 +50,37 @@ config PCI_DRA7XX_EP This uses the DesignWare core. config PCIE_DW_PLAT - bool "Platform bus based DesignWare PCIe Controller" - depends on PCI - depends on PCI_MSI_IRQ_DOMAIN - select PCIE_DW_HOST - ---help--- - This selects the DesignWare PCIe controller support. Select this if - you have a PCIe controller on Platform bus. + bool - If you have a controller with this interface, say Y or M here. +config PCIE_DW_PLAT_HOST + bool "Platform bus based DesignWare PCIe Controller - Host mode" + depends on PCI && PCI_MSI_IRQ_DOMAIN + select PCIE_DW_HOST + select PCIE_DW_PLAT + default y + help + Enables support for the PCIe controller in the Designware IP to + work in host mode. There are two instances of PCIe controller in + Designware IP. + This controller can work either as EP or RC. In order to enable + host-specific features PCIE_DW_PLAT_HOST must be selected and in + order to enable device-specific features PCI_DW_PLAT_EP must be + selected. - If unsure, say N. +config PCIE_DW_PLAT_EP + bool "Platform bus based DesignWare PCIe Controller - Endpoint mode" + depends on PCI && PCI_MSI_IRQ_DOMAIN + depends on PCI_ENDPOINT + select PCIE_DW_EP + select PCIE_DW_PLAT + help + Enables support for the PCIe controller in the Designware IP to + work in endpoint mode. There are two instances of PCIe controller + in Designware IP. + This controller can work either as EP or RC. In order to enable + host-specific features PCIE_DW_PLAT_HOST must be selected and in + order to enable device-specific features PCI_DW_PLAT_EP must be + selected. config PCI_EXYNOS bool "Samsung Exynos PCIe controller"
drivers/pci/dwc/pcie-designware-plat.c +139 -10
211 lines not on this page · raw message
Signature · 1 line
2.7.4
PATCH v7 3/9 PCI: endpoint: functions/pci-epf-test: Add second entry
In reply to Gustavo PimentelAdds a seconds entry on the pci_epf_test_ids structure that disables the linkup_notifier parameter on driver for the designware EP.
This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
---
Change v2->v3:
- Added second entry in pci_epf_test_ids structure.
- Remove test_reg_bar field assignment on second entry.
Changes v3->v4:
- Nothing changed, just to follow the patch set version.
Changes v4->v5:
- Changed pci_epf_test_cfg2 to pci_epf_test_designware.
Changes v5->v6:
- Changed name field from pci_epf_test_designware to pci_epf_test_dw.
Changes v6->v7:
- Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)
Documentation/PCI/endpoint/function/binding/pci-test.txt +2 -0
@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP. Configurable Fields: vendorid : should be 0x104c
drivers/pci/endpoint/functions/pci-epf-test.c +8 -0
@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; } +static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {}, };
Signature · 1 line
2.7.4
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the
"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0
Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.
The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 13 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +3
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; } +static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +};
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 10 lines
drivers/pci/endpoint/functions/pci-epf-test.c +5
-0+static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},
Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
I think I am missing something in the whole scheme of things, please clarify.
Thanks,
Lorenzo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 14 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
Quoted 8 lines
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Ok, I will do an overall check to fix the entries.
Quoted 26 lines
Quoted 26 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION
Quoted 6 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 3 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
I will add more information about it.
Quoted 3 lines
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
That's true, it should exist some explanation of that. To be honest I didn't remember of the pci-test-howto.txt file existence.
Quoted 28 lines
Quoted 14 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +3
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; } +static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +};drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 10 lines
drivers/pci/endpoint/functions/pci-epf-test.c +5
-0+static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 2 lines
I think I am missing something in the whole scheme of things, please clarify.
This type of configuration / configuration was suggested by Kishon. I can only assume that it would not be possible (or no one thought of it) to correlate the compatible string of the controller to select the configuration, perhaps Kishon could give his opinion on the feasibility of this and even to provide some example of it. :)
If it is possible, it will be quite straightforward.
Quoted 4 lines
Thanks,
Lorenzo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
In reply to Lorenzo PieralisiHi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }
Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
pci_epf_test is an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers like pcie-designware-plat.c). pci_epf_test uses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.
Thanks
Kishon
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.
I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Lorenzo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
configfs is just one way of creating epf_device and it was mainly added since pci-epf-test cannot have a dt entry because it doesn't represent anything in the HW.
The other option was to have a callback to EPC driver to get the features it supports. But a particular feature that is required might be specific to a EPF driver.
I find the driver_data approach in pci_epf_device_id to be more clean.
Thanks
Kishon
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 104 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.
Quoted 6 lines
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
I am honestly very confused. First off, I do not understand what this patch really does (or better what DW can't do so that it needs a specific configfs string and therefore a specific configuration).
What's the purpose of the linkup notifier ? What does it mean that the DW HW can't handle it ?
Are we referring to the pci_epf_linkup() function ?
If it is a HW configuration (ie the DW HW does not have a signal to report that the link is up ?) its enablement must depend on HW controller properties not configfs entries, I do not like what this patch does (probably because I am confused and I do not understand it).
Please let me know your thoughts on this, thanks.
Lorenzo
Quoted 13 lines
configfs is just one way of creating
epf_deviceand it was mainly added since pci-epf-test cannot have a dt entry because it doesn't represent anything in the HW.The other option was to have a callback to EPC driver to get the features it supports. But a particular feature that is required might be specific to a EPF driver.
I find the
driver_dataapproach inpci_epf_device_idto be more clean.Thanks
Kishon
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Hi Lorenzo,
Quoted 119 lines · Lorenzo Pieralisi
Quoted 104 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.Quoted 6 lines
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
I am honestly very confused. First off, I do not understand what this patch really does (or better what DW can't do so that it needs a specific configfs string and therefore a specific configuration).
What's the purpose of the linkup notifier ? What does it mean that the DW HW can't handle it ?
Quoted 8 lines
Are we referring to the
pci_epf_linkup()function ?If it is a HW configuration (ie the DW HW does not have a signal to report that the link is up ?) its enablement must depend on HW controller properties not configfs entries, I do not like what this patch does (probably because I am confused and I do not understand it).
Please let me know your thoughts on this, thanks.
On my setup, the EP is unable generate a signal which is responsible for notify that the link is established, being therefore necessary to emulate it, this is done by setting the linkup_notifier variable to false.
This signal allows the pci-epf-test driver on the EP side to startup with a cyclic task defined on pci_epf_test_cmd_handler() that checks a command register located on the BAR (by default on BAR 0) settled by pci_endpoint_test driver on the RC side that defines, by his turn defines which type of command to perform.
Quoted 13 lines
Lorenzo
Quoted 10 lines
configfs is just one way of creating
epf_deviceand it was mainly added since pci-epf-test cannot have a dt entry because it doesn't represent anything in the HW.The other option was to have a callback to EPC driver to get the features it supports. But a particular feature that is required might be specific to a EPF driver.
I find the
driver_dataapproach inpci_epf_device_idto be more clean.
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
I think this option is also a good alternative, simple and clean. What do you think?
Quoted 3 lines
Quoted 3 lines
Thanks
Kishon
Regards,
Gustavo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 129 lines · Gustavo Pimentel
Hi Lorenzo,
Quoted 126 lines · Lorenzo Pieralisi
Quoted 104 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.Quoted 6 lines
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
I am honestly very confused. First off, I do not understand what this patch really does (or better what DW can't do so that it needs a specific configfs string and therefore a specific configuration).
What's the purpose of the linkup notifier ? What does it mean that the DW HW can't handle it ?
Are we referring to the
pci_epf_linkup()function ?If it is a HW configuration (ie the DW HW does not have a signal to report that the link is up ?) its enablement must depend on HW controller properties not configfs entries, I do not like what this patch does (probably because I am confused and I do not understand it).
Quoted 6 lines
Quoted 1 line
Please let me know your thoughts on this, thanks.
On my setup, the EP is unable generate a signal which is responsible for notify that the link is established, being therefore necessary to emulate it, this is done by setting the
linkup_notifiervariable to false.
What I do not understand is why the workqueue notification can't be called irrespective of the linkup notifier value from pci_epf_test_bind(), what's the point in calling it earlier with pci_epf_linkup() (or the other way around why is it safe to call it a bind() time if there is no notification available - which is the DW case).
[...]
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
Lorenzo
Quoted 10 lines
I think this option is also a good alternative, simple and clean. What do you think?
Quoted 3 lines
Quoted 3 lines
Thanks
KishonRegards,
Gustavo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Hi Lorenzo,
Quoted 137 lines · Lorenzo Pieralisi
Quoted 129 lines · Gustavo Pimentel
Hi Lorenzo,
Quoted 126 lines · Lorenzo Pieralisi
Quoted 104 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.Quoted 6 lines
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
I am honestly very confused. First off, I do not understand what this patch really does (or better what DW can't do so that it needs a specific configfs string and therefore a specific configuration).
What's the purpose of the linkup notifier ? What does it mean that the DW HW can't handle it ?
Are we referring to the
pci_epf_linkup()function ?If it is a HW configuration (ie the DW HW does not have a signal to report that the link is up ?) its enablement must depend on HW controller properties not configfs entries, I do not like what this patch does (probably because I am confused and I do not understand it).
Quoted 6 lines
Quoted 1 line
Please let me know your thoughts on this, thanks.
On my setup, the EP is unable generate a signal which is responsible for notify that the link is established, being therefore necessary to emulate it, this is done by setting the
linkup_notifiervariable to false.
Quoted 5 lines
What I do not understand is why the workqueue notification can't be called irrespective of the linkup notifier value from
pci_epf_test_bind(), what's the point in calling it earlier withpci_epf_linkup()(or the other way around why is it safe to call it abind()time if there is no notification available - which is the DW case).
The linkup notifier is used just to prevent the system from wasting cpu cycles. Without linkup notifier, pci_epf_test will start checking for commands from host after the pci_epf_test is bound to the EP controller (bind() callback) though the host can issue commands only when after the link is up. So for platforms which supports linkup notification, it's better we poll command register only after link is established.
Quoted 9 lines
[...]
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
Quoted 4 lines
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
The problem is because pci-epf-test cannot be described in HW. pci-epf-test is also not automatically bound to the EP controller but is bound by the user like below
ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/
So given that user anyways has to bind the epf device to the controller, based on the platform the user can use a different configfs entry like below ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
If the epf can be described in dt, then something like below can be done
pcie1_ep: pcie_ep@51000000 {
compatible = "ti,dra7-pcie-ep";
interrupts = <0 232 0x4>;
num-lanes = <1>;
num-ib-windows = <4>;
num-ob-windows = <16>;
phys = <&pcie1_phy>;
phy-names = "pcie-phy0";
pci_epf_test: pci_epf_test@0 {
name = "pci_epf_test_dw";
<other properties>;
}
};With this pci-dra7xx.c driver should create pci_epf_device using pci_epf_create("pci_epf_test_dw");
Then the driver_data corresponding to "pci_epf_test_dw" will select linkup notifier or BAR index etc.
Having different pci_epf_device_id entries and corresponding driver_data for each entry seems fine to me (as done in this patch). We use configfs only since pci_epf_test cannot be described in dt.
Thanks
Kishon
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
[...]
Quoted 36 lines
Quoted 10 lines
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
The problem is because pci-epf-test cannot be described in HW. pci-epf-test is also not automatically bound to the EP controller but is bound by the user like below
ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/So given that user anyways has to bind the epf device to the controller, based on the platform the user can use a different configfs entry like below ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
If the epf can be described in dt, then something like below can be done
pcie1_ep: pcie_ep@51000000 { compatible = "ti,dra7-pcie-ep"; interrupts = <0 232 0x4>; num-lanes = <1>; num-ib-windows = <4>; num-ob-windows = <16>; phys = <&pcie1_phy>; phy-names = "pcie-phy0"; pci_epf_test: pci_epf_test@0 { name = "pci_epf_test_dw"; <other properties>; } };
Quoted 5 lines
With this
pci-dra7xx.cdriver should createpci_epf_deviceusingpci_epf_create("pci_epf_test_dw");Then the
driver_datacorresponding to "pci_epf_test_dw" will select linkup notifier or BAR index etc.
Those two properties are properties of the EP controller (it is not 100% clear to me how the test BAR register is defined), is this correct ?
If yes, given that those properties are not useful before an EPF is bound to an EPC, can't they be retrieved at bind time from the EPC controller data (that we can add through DT bindings) ?
Thanks,
Lorenzo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Hi Lorenzo,
Quoted 40 lines · Lorenzo Pieralisi
On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
[...]
Quoted 36 lines
Quoted 10 lines
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
The problem is because pci-epf-test cannot be described in HW. pci-epf-test is also not automatically bound to the EP controller but is bound by the user like below
ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/So given that user anyways has to bind the epf device to the controller, based on the platform the user can use a different configfs entry like below ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
If the epf can be described in dt, then something like below can be done
pcie1_ep: pcie_ep@51000000 { compatible = "ti,dra7-pcie-ep"; interrupts = <0 232 0x4>; num-lanes = <1>; num-ib-windows = <4>; num-ob-windows = <16>; phys = <&pcie1_phy>; phy-names = "pcie-phy0"; pci_epf_test: pci_epf_test@0 { name = "pci_epf_test_dw"; <other properties>; } };
Quoted 8 lines
Quoted 5 lines
With this
pci-dra7xx.cdriver should createpci_epf_deviceusingpci_epf_create("pci_epf_test_dw");Then the
driver_datacorresponding to "pci_epf_test_dw" will select linkup notifier or BAR index etc.Those two properties are properties of the EP controller (it is not 100% clear to me how the test BAR register is defined), is this correct ?
Right, these properties are specific to a platform. In some of the platforms like K2G (BAR0 is reserved i.e it is used to map PCIe app registers and cannot be used by pci_epf_test. In such cases we should use a BAR other than BAR0).
Quoted 4 lines
If yes, given that those properties are not useful before an EPF is bound to an EPC, can't they be retrieved at bind time from the EPC controller data (that we can add through DT bindings) ?
hmm..
We can have quirk in pci_epc, something like below
struct pci_epc {
.
.
unsigned int quirks;
.
.
};#define EPC_QUIRKS_NO_LINKUP_NOTIFIER BIT(0)
#define EPC_QUIRKS_BAR0_RESERVED BIT(1)
#define EPC_QUIRKS_BAR1_RESERVED BIT(2)
#define EPC_QUIRKS_BAR2_RESERVED BIT(3)
#define EPC_QUIRKS_BAR3_RESERVED BIT(4)
#define EPC_QUIRKS_BAR4_RESERVED BIT(5)
#define EPC_QUIRKS_BAR5_RESERVED BIT(6)
The controller driver can set the appropriate quirks epc->quirks |= EPC_QUIRKS_NO_LINKUP_NOTIFIER | EPC_QUIRKS_BAR0_RESERVED;
Then pci-epf-test driver can checks the quirks to see the supported EPC features.
Does something like above looks okay to you?
Thanks
Kishon
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Quoted 49 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 46 lines · Lorenzo Pieralisi
On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
[...]
Quoted 41 lines
Quoted 10 lines
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
The problem is because pci-epf-test cannot be described in HW. pci-epf-test is also not automatically bound to the EP controller but is bound by the user like below
ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/So given that user anyways has to bind the epf device to the controller, based on the platform the user can use a different configfs entry like below ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
If the epf can be described in dt, then something like below can be done
pcie1_ep: pcie_ep@51000000 { compatible = "ti,dra7-pcie-ep"; interrupts = <0 232 0x4>; num-lanes = <1>; num-ib-windows = <4>; num-ob-windows = <16>; phys = <&pcie1_phy>; phy-names = "pcie-phy0"; pci_epf_test: pci_epf_test@0 { name = "pci_epf_test_dw"; <other properties>; } };With this
pci-dra7xx.cdriver should createpci_epf_deviceusingpci_epf_create("pci_epf_test_dw");Then the
driver_datacorresponding to "pci_epf_test_dw" will select linkup notifier or BAR index etc.
Quoted 6 lines
Quoted 2 lines
Those two properties are properties of the EP controller (it is not 100% clear to me how the test BAR register is defined), is this correct ?
Right, these properties are specific to a platform. In some of the platforms like K2G (BAR0 is reserved i.e it is used to map PCIe app registers and cannot be used by
pci_epf_test. In such cases we should use a BAR other than BAR0).
I do not think those properties are pci_epf_test specific, that's the whole point I am making. Those are EPC controller features.
Quoted 24 lines
Quoted 3 lines
If yes, given that those properties are not useful before an EPF is bound to an EPC, can't they be retrieved at bind time from the EPC controller data (that we can add through DT bindings) ?
hmm..
We can have quirk in
pci_epc, something like belowstruct pci_epc { . . unsigned int quirks; . . };#define
EPC_QUIRKS_NO_LINKUP_NOTIFIERBIT(0)
#defineEPC_QUIRKS_BAR0_RESERVEDBIT(1)
#defineEPC_QUIRKS_BAR1_RESERVEDBIT(2)
#defineEPC_QUIRKS_BAR2_RESERVEDBIT(3)
#defineEPC_QUIRKS_BAR3_RESERVEDBIT(4)
#defineEPC_QUIRKS_BAR4_RESERVEDBIT(5)
#defineEPC_QUIRKS_BAR5_RESERVEDBIT(6)
Quoted 6 lines
The controller driver can set the appropriate quirks
epc->quirks|=EPC_QUIRKS_NO_LINKUP_NOTIFIER|EPC_QUIRKS_BAR0_RESERVED;Then pci-epf-test driver can checks the quirks to see the supported EPC features.
Does something like above looks okay to you?
Well, it is better than the driver_data approach, I would not call them quirks but features and for the BARs you should define a mask it does not make sense to enumerate them. It is probably a good idea to leave room for additional "features" so please choose the bits placement wisely.
Thanks,
Lorenzo
Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
In reply to Kishon Vijay Abraham IHi Lorenzo and Kishon,
Quoted 194 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 137 lines · Lorenzo Pieralisi
Quoted 129 lines · Gustavo Pimentel
Hi Lorenzo,
Quoted 126 lines · Lorenzo Pieralisi
Quoted 104 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 101 lines · Lorenzo Pieralisi
Quoted 88 lines · Kishon Vijay Abraham I
Hi Lorenzo,
Quoted 68 lines · Lorenzo Pieralisi
Quoted 1 line · Gustavo Pimentel
Adds a seconds entry on the
pci_epf_test_idsstructure that disables the"Add a second entry to..."
Quoted 6 lines
linkup_notifierparameter on driver for the designware EP.This allows designware EPs that doesn't have linkup notification signal to work with pcitest.
Updates the binding documentation accordingly.
Valid for all the series: use imperative sentences.
eg:
"Update the binding documentation accordingly".
not
"Updates the binding documentation accordingly".
Quoted 24 lines
Signed-off-by Gustavo Pimentel <[email protected]>---
Changev2->v3:
- Added second entry inpci_epf_test_idsstructure.
- Removetest_reg_barfield assignment on second entry.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Changedpci_epf_test_cfg2topci_epf_test_designware.
Changesv5->v6:
- Changed name field frompci_epf_test_designwaretopci_epf_test_dw.
Changesv6->v7:
- Changed variable name fromdata_cfg2todata_linkup_notifier_disabled.Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++ drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++++++++ 2 files changed, 10 insertions(+)Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Documentation/PCI/endpoint/function/binding/pci-test.txt line 5
Quoted 5 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +2
-0@@ -1,6 +1,8 @@ PCI TEST ENDPOINT FUNCTION name: Should be "pci_epf_test" to bind to the pci_epf_test driver. +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver + with a custom configuration for the designware EP.The link between the "name" and the device created is quite obscure and reading pci-test-howto.txt certainly does not clarify it.
In pci-test-howto.txt an explanation should be added to the configs device creation paragraph to clarify it.
Quoted 10 lines
Documentation/PCI/endpoint/function/binding/pci-test.txt +0
-0Configurable Fields: vendorid : should be 0x104cdrivers/pci/endpoint/functions/pci-epf-test.c +0
-0@@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)return 0 ; }Quoted 16 lines
drivers/pci/endpoint/functions/pci-epf-test.c static int pci_epf_test_bind(struct pci_epf *epf) · line 474
Quoted 13 lines
drivers/pci/endpoint/functions/pci-epf-test.c +8
-0+static const struct pci_epf_test_data data_linkup_notifier_disabled = { + .linkup_notifier = false +}; +static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name ="pci_epf_test" , }, + { + .name ="pci_epf_test_dw" , + .driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled, + }, {},Should not this be a property derived from the controller compatible property instead of the test device name written in configfs ?
Quoted 4 lines
pci_epf_testis an independent driver on its own that operates in a layer above the controller driver. So it does not get the controller compatible (which is used in controller drivers likepcie-designware-plat.c).pci_epf_testuses "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.I understand that, the problem is that the independent driver depends on features of the related controller driver as this patch shows. This patch basically says that if you use a specific path in configfs (that includes
pci_epf_test_dw) your device has specific HW features (eg linkup notifier above), that obviously depends on the platform HW not on the string you use in configfs.Quoted 6 lines
Quoted 2 lines
What I am questioning is a) if I understand this right and b) whether this is the right approach.
Your understanding is right. Ideally pci-epf-test driver shouldn't have any HW specific configuration. But different HW have different configurations and pci-epf-test should be informed of the configuration the HW supports.
I am honestly very confused. First off, I do not understand what this patch really does (or better what DW can't do so that it needs a specific configfs string and therefore a specific configuration).
What's the purpose of the linkup notifier ? What does it mean that the DW HW can't handle it ?
Are we referring to the
pci_epf_linkup()function ?If it is a HW configuration (ie the DW HW does not have a signal to report that the link is up ?) its enablement must depend on HW controller properties not configfs entries, I do not like what this patch does (probably because I am confused and I do not understand it).
Quoted 6 lines
Quoted 1 line
Please let me know your thoughts on this, thanks.
On my setup, the EP is unable generate a signal which is responsible for notify that the link is established, being therefore necessary to emulate it, this is done by setting the
linkup_notifiervariable to false.Quoted 5 lines
What I do not understand is why the workqueue notification can't be called irrespective of the linkup notifier value from
pci_epf_test_bind(), what's the point in calling it earlier withpci_epf_linkup()(or the other way around why is it safe to call it abind()time if there is no notification available - which is the DW case).The linkup notifier is used just to prevent the system from wasting cpu cycles. Without linkup notifier,
pci_epf_testwill start checking for commands from host after thepci_epf_testis bound to the EP controller (bind()callback) though the host can issue commands only when after the link is up. So for platforms which supports linkup notification, it's better we poll command register only after link is established.Quoted 9 lines
[...]
Quoted 5 lines
Since the linkup notifier and BAR index (where auxiliary registers are located) may be configurable and is something platform dependent, perhaps the configuration of this variables should be done by module parameter and not by configfs, leaving this configuration responsibility in charge of each platform.
Quoted 4 lines
They are platform dependent because they depend on the EP controller. That's why I said that those are EP controller parameters. I do not think they are module parameters either - they should be part of HW description in firmware.
The problem is because pci-epf-test cannot be described in HW. pci-epf-test is also not automatically bound to the EP controller but is bound by the user like below
ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/So given that user anyways has to bind the epf device to the controller, based on the platform the user can use a different configfs entry like below ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
If the epf can be described in dt, then something like below can be done
pcie1_ep: pcie_ep@51000000 { compatible = "ti,dra7-pcie-ep"; interrupts = <0 232 0x4>; num-lanes = <1>; num-ib-windows = <4>; num-ob-windows = <16>; phys = <&pcie1_phy>; phy-names = "pcie-phy0"; pci_epf_test: pci_epf_test@0 { name = "pci_epf_test_dw"; <other properties>; } };With this
pci-dra7xx.cdriver should createpci_epf_deviceusingpci_epf_create("pci_epf_test_dw");
Quoted 6 lines
Then the
driver_datacorresponding to "pci_epf_test_dw" will select linkup notifier or BAR index etc.Having different
pci_epf_device_identries and correspondingdriver_datafor each entry seems fine to me (as done in this patch). We use configfs only sincepci_epf_testcannot be described in dt.
I think I understood your point of view Lorenzo and it makes sense. However I think I have an alternative, since this 2 parameters are platform dependent, but there aren't quite a HW description, so they shouldn't be described on DT, right?
So I would propose another alternative. What if each EP driver (in my case pcie-designware-plat) provided a callback that could be used to set the test configuration data, if needed? Similar to the dw_plat_set_num_vectors callback.
In fact, something similar mechanism already exists, for example when the pci_epf_test driver tries to get the number of MSI/MSI-X, the driver retrieves the value through callbacks.
In this way each driver would be responsible for adapting to their needs, there would be no changes to the DT modification or extra configfs entries.
What do you think?
Regards,
Gustavo
Quoted 4 lines
Thanks
Kishon
PATCH v7 4/9 bindings: PCI: designware: Add support for the EP in Designware driver
In reply to Gustavo PimentelAdd device tree binding documentation for the Endpoint in PCIe Designware driver.
---
Change v1->v2:
- Add a missing log description.
- Add "snps,dw-pcie" compatible string following Kishon's suggestion.
Change v2->v3:
- Reverted pcie_ep name to pcie.
Changes v3->v4:
- Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
Changes v4->v5:
- Removed device_type entry from EP requested by Rob Herring.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Documentation/devicetree/bindings/pci/designware-pcie.txt +12 -0
@@ -3,6 +3,7 @@ Required properties: - compatible: "snps,dw-pcie" for RC mode; + "snps,dw-pcie-ep" for EP mode; - reg: Should contain the configuration address space. - reg-names: Must be "config" for the PCIe configuration space. (The old way of getting the configuration address space from "ranges"
@@ -56,3 +57,14 @@ Example configuration: #interrupt-cells = <1>; num-lanes = <1>; }; +or + pcie: pcie@dfc00000 { + compatible = "snps,dw-pcie-ep"; + reg = <0xdfc00000 0x0001000>, /* IP registers 1 */ + <0xdfc01000 0x0001000>, /* IP registers 2 */ + <0xd0000000 0x2000000>; /* Configuration space */ + reg-names = "dbi", "dbi2", "addr_space"; + num-ib-windows = <6>; + num-ob-windows = <2>; + num-lanes = <1>; + };
Signature · 1 line
2.7.4
PATCH v7 5/9 misc: pci_endpoint_test: Add designware EP entry
In reply to Gustavo PimentelAdds the designware EP device ID entry to pci_endpoint_test driver table to allow this device to be recognize and handle by the pci_endpoint_test driver.
---
Change v1->v2:
- Changed device id following Kishon's suggestion.
Change v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Nothing changed, just to follow the patch set version.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Reverted Kishon's suggestion by Bjorn request.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/misc/pci_endpoint_test.c | 1 + 1 file changed, 1 insertion(+)
drivers/misc/pci_endpoint_test.c +1 -0
@@ -634,6 +634,7 @@ static void pci_endpoint_test_remove(struct pci_dev *pdev)static const struct pci_device_id pci_endpoint_test_tbl[] = { {PCI_DEVICE (PCI_VENDOR_ID_TI , PCI_DEVICE_ID_TI_DRA74x) }, {PCI_DEVICE (PCI_VENDOR_ID_TI , PCI_DEVICE_ID_TI_DRA72x) }, + {PCI_DEVICE (PCI_VENDOR_ID_SYNOPSYS ,0xedda ) }, { } };MODULE_DEVICE_TABLE (pci, pci_endpoint_test_tbl);
Signature · 1 line
2.7.4
PATCH v7 6/9 PCI: dwc: Define maximum number of vectors
In reply to Gustavo PimentelAdds a callback that defines the maximum number of vectors that can be use by the Root Complex.
Since this is a parameter associated to each SoC IP setting, makes sense to be configurable and easily visible to future modifications.
The designware IP supports a maximum of 256 vectors.
---
Change v1->v2:
- Nothing changed, just to follow the patch set version.
Change v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Nothing changed, just to follow the patch set version.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/pci/dwc/pcie-designware-plat.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/pci/dwc/pcie-designware-plat.c +6 -0
@@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)return 0 ; } +static void dw_plat_set_num_vectors (struct pcie_port *pp) +{ + pp->num_vectors =MAX_MSI_IRQS ; +} +static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = { .host_init = dw_plat_pcie_host_init, + .set_num_vectors = dw_plat_set_num_vectors, };static int dw_plat_pcie_establish_link (struct dw_pcie *pci)
Signature · 1 line
2.7.4
Re: [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors
Quoted 4 lines · Gustavo Pimentel
Adds a callback that defines the maximum number of vectors that can be use by the Root Complex.
Quoted 8 lines
Since this is a parameter associated to each SoC IP setting, makes sense to
be configurable and easily visible to future modifications.The designware IP supports a maximum of 256 vectors.
Signed-off-by Gustavo Pimentel <[email protected]>Acked-by Joao Pinto <[email protected]>
Best regards,
Jingoo Han
Quoted 40 lines
---
Changev1->v2:
- Nothing changed, just to follow the patch set version.
Changev2->v3:
- Nothing changed, just to follow the patch set version.
Changesv3->v4:
- Nothing changed, just to follow the patch set version.
Changesv4->v5:
- Nothing changed, just to follow the patch set version.
Changesv5->v6:
- Nothing changed, just to follow the patch set version.
Changesv6->v7:
- Nothing changed, just to follow the patch set version.drivers/pci/dwc/pcie-designware-plat.c | 6 ++++++ 1 file changed, 6 insertions(+)drivers/pci/dwc/pcie-designware-plat.c +6
-1@@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)return 0 ; } +static void dw_plat_set_num_vectors (struct pcie_port *pp) +{ + pp->num_vectors =MAX_MSI_IRQS ; +} +static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = { .host_init = dw_plat_pcie_host_init, + .set_num_vectors = dw_plat_set_num_vectors, };static int dw_plat_pcie_establish_link (struct dw_pcie *pci) --2.7.4
PATCH v7 7/9 PCI: dwc: Replace lower into upper case characters
In reply to Gustavo PimentelReplaces lower into upper case characters in comments and debug printks.
This is an attempt to keep the messages coherent within the designware driver.
Also fixed code style on dw_pcie_irq_domain_free function.
---
Change v1->v2:
- Added an extra log description line about code style following Fabio
Estevam suggestion.
Change v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Nothing changed, just to follow the patch set version.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/pci/dwc/pcie-designware-ep.c | 16 ++++++++-------- drivers/pci/dwc/pcie-designware-host.c | 35 ++++++++++++++++++---------------- drivers/pci/dwc/pcie-designware.c | 22 ++++++++++----------- 3 files changed, 38 insertions(+), 35 deletions(-)
drivers/pci/dwc/pcie-designware-ep.c +8 -8
@@ -75,7 +75,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar, free_win =find_first_zero_bit (ep->ib_window_map, ep->num_ib_windows);if (free_win >= ep->num_ib_windows) { -dev_err (pci->dev,"no free inbound window\n" ); +dev_err (pci->dev,"No free inbound window\n" );return -EINVAL ; }
@@ -100,7 +100,7 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t phys_addr, free_win =find_first_zero_bit (ep->ob_window_map, ep->num_ob_windows);if (free_win >= ep->num_ob_windows) { -dev_err (pci->dev,"no free outbound window\n" ); +dev_err (pci->dev,"No free outbound window\n" );return -EINVAL ; }
@@ -204,7 +204,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no, ret =dw_pcie_ep_outbound_atu (ep, addr, pci_addr, size);if (ret) { -dev_err (pci->dev,"failed to enable address\n" ); +dev_err (pci->dev,"Failed to enable address\n" );return ret; }
@@ -348,21 +348,21 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep) ret =of_property_read_u32 (np,"num-ib-windows" , &ep->num_ib_windows);if (ret <0 ) { -dev_err (dev,"unable to read *num-ib-windows* property\n" ); +dev_err (dev,"Unable to read *num-ib-windows* property\n" );return ret; }if (ep->num_ib_windows >MAX_IATU_IN ) { -dev_err (dev,"invalid *num-ib-windows*\n" ); +dev_err (dev,"Invalid *num-ib-windows*\n" );return -EINVAL ; } ret =of_property_read_u32 (np,"num-ob-windows" , &ep->num_ob_windows);if (ret <0 ) { -dev_err (dev,"unable to read *num-ob-windows* property\n" ); +dev_err (dev,"Unable to read *num-ob-windows* property\n" );return ret; }if (ep->num_ob_windows >MAX_IATU_OUT ) { -dev_err (dev,"invalid *num-ob-windows*\n" ); +dev_err (dev,"Invalid *num-ob-windows*\n" );return -EINVAL ; }
@@ -389,7 +389,7 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep) epc =devm_pci_epc_create (dev, &epc_ops);if (IS_ERR (epc)) { -dev_err (dev,"failed to create epc device\n" ); +dev_err (dev,"Failed to create epc device\n" );return PTR_ERR (epc); }
drivers/pci/dwc/pcie-designware-host.c +19 -16
@@ -248,8 +248,10 @@ static void dw_pcie_irq_domain_free(struct irq_domain *domain,unsigned long flags;raw_spin_lock_irqsave (&pp->lock, flags); +bitmap_release_region (pp->msi_irq_in_use, data->hwirq,order_base_2 (nr_irqs)); +raw_spin_unlock_irqrestore (&pp->lock, flags); }
@@ -266,7 +268,7 @@ int dw_pcie_allocate_domains(struct pcie_port *pp) pp->irq_domain =irq_domain_create_linear (fwnode, pp->num_vectors, &dw_pcie_msi_domain_ops, pp);if (!pp->irq_domain) { -dev_err (pci->dev,"failed to create IRQ domain\n" ); +dev_err (pci->dev,"Failed to create IRQ domain\n" );return -ENOMEM ; }
@@ -274,7 +276,7 @@ int dw_pcie_allocate_domains(struct pcie_port *pp) &dw_pcie_msi_domain_info, pp->irq_domain);if (!pp->msi_domain) { -dev_err (pci->dev,"failed to create MSI domain\n" ); +dev_err (pci->dev,"Failed to create MSI domain\n" );irq_domain_remove (pp->irq_domain);return -ENOMEM ; }
@@ -301,13 +303,13 @@ void dw_pcie_msi_init(struct pcie_port *pp) page =alloc_page (GFP_KERNEL ); pp->msi_data =dma_map_page (dev, page,0 ,PAGE_SIZE ,DMA_FROM_DEVICE );if (dma_mapping_error (dev, pp->msi_data)) { -dev_err (dev,"failed to map MSI data\n" ); +dev_err (dev,"Failed to map MSI data\n" );__free_page (page);return ; } msi_target = (u64 )pp->msi_data; -/* program the msi_data */ +/* Program the msi_data */ dw_pcie_wr_own_conf (pp,PCIE_MSI_ADDR_LO ,4 ,lower_32_bits (msi_target)); dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4,
@@ -335,7 +337,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->cfg0_base = cfg_res->start; pp->cfg1_base = cfg_res->start + pp->cfg0_size; }else if (!pp->va_cfg0_base) { -dev_err (dev,"missing *config* reg space\n" ); +dev_err (dev,"Missing *config* reg space\n" ); } bridge =pci_alloc_host_bridge (0 );
@@ -357,7 +359,7 @@ int dw_pcie_host_init(struct pcie_port *pp)case IORESOURCE_IO : ret =pci_remap_iospace (win->res, pp->io_base);if (ret) { -dev_warn (dev,"error %d: failed to map resource %pR\n" , +dev_warn (dev,"Error %d: failed to map resource %pR\n" , ret, win->res);resource_list_destroy_entry (win); }else {
@@ -391,7 +393,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->cfg->start, resource_size(pp->cfg));if (!pci->dbi_base) { -dev_err (dev,"error with ioremap\n" ); +dev_err (dev,"Error with ioremap\n" ); ret = -ENOMEM ; goto error; }
@@ -403,7 +405,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->va_cfg0_base =devm_pci_remap_cfgspace (dev, pp->cfg0_base, pp->cfg0_size);if (!pp->va_cfg0_base) { -dev_err (dev,"error with ioremap in function\n" ); +dev_err (dev,"Error with ioremap in function\n" ); ret = -ENOMEM ; goto error; }
@@ -414,7 +416,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->cfg1_base, pp->cfg1_size);if (!pp->va_cfg1_base) { -dev_err (dev,"error with ioremap\n" ); +dev_err (dev,"Error with ioremap\n" ); ret = -ENOMEM ; goto error; }
@@ -586,7 +588,7 @@ static int dw_pcie_valid_device(struct pcie_port *pp, struct pci_bus *bus,return 0 ; } -/* access only one slot on each root port */ +/* Access only one slot on each root port */ if (bus->number == pp->root_bus_nr && dev >0 )return 0 ;
@@ -652,11 +654,12 @@ void dw_pcie_setup_rc(struct pcie_port *pp)for (ctrl =0 ; ctrl < num_ctrls; ctrl++)dw_pcie_rd_own_conf (pp,PCIE_MSI_INTR0_ENABLE + (ctrl *12 ),4 , &pp->irq_status[ctrl]); -/* setup RC BARs */ + +/* Setup RC BARs */ dw_pcie_writel_dbi (pci,PCI_BASE_ADDRESS_0 ,0x00000004 );dw_pcie_writel_dbi (pci,PCI_BASE_ADDRESS_1 ,0x00000000 ); -/* setup interrupt pins */ +/* Setup interrupt pins */ dw_pcie_dbi_ro_wr_en (pci); val =dw_pcie_readl_dbi (pci,PCI_INTERRUPT_LINE ); val &=0xffff00ff ;
@@ -664,13 +667,13 @@ void dw_pcie_setup_rc(struct pcie_port *pp)dw_pcie_writel_dbi (pci,PCI_INTERRUPT_LINE , val);dw_pcie_dbi_ro_wr_dis (pci); -/* setup bus numbers */ +/* Setup bus numbers */ val =dw_pcie_readl_dbi (pci,PCI_PRIMARY_BUS ); val &=0xff000000 ; val |=0x00ff0100 ;dw_pcie_writel_dbi (pci,PCI_PRIMARY_BUS , val); -/* setup command register */ +/* Setup command register */ val =dw_pcie_readl_dbi (pci,PCI_COMMAND ); val &=0xffff0000 ; val |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
@@ -683,7 +686,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)* we should not program the ATU here. */ if (!pp->ops->rd_other_conf) { -/* get iATU unroll support */ +/* Get iATU unroll support */ pci->iatu_unroll_enabled =dw_pcie_iatu_unroll_enabled (pci);dev_dbg (pci->dev,"iATU unroll: %s\n" , pci->iatu_unroll_enabled ?"enabled" :"disabled" );
@@ -701,7 +704,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)/* Enable write permission for the DBI read-only register */ dw_pcie_dbi_ro_wr_en (pci); -/* program correct class for RC */ +/* Program correct class for RC */ dw_pcie_wr_own_conf (pp,PCI_CLASS_DEVICE ,2 ,PCI_CLASS_BRIDGE_PCI );/* Better disable write permission right after the update */ dw_pcie_dbi_ro_wr_dis (pci);
drivers/pci/dwc/pcie-designware.c +11 -11
@@ -69,7 +69,7 @@ u32 __dw_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base, u32 reg, ret =dw_pcie_read (base + reg, size, &val);if (ret) -dev_err (pci->dev,"read DBI address failed\n" ); +dev_err (pci->dev,"Read DBI address failed\n" );return val; }
@@ -86,7 +86,7 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem *base, u32 reg, ret =dw_pcie_write (base + reg, size, val);if (ret) -dev_err (pci->dev,"write DBI address failed\n" ); +dev_err (pci->dev,"Write DBI address failed\n" ); }static u32 dw_pcie_readl_ob_unroll (struct dw_pcie *pci,u32 index,u32 reg)
@@ -137,7 +137,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,usleep_range (LINK_WAIT_IATU_MIN ,LINK_WAIT_IATU_MAX ); } -dev_err (pci->dev,"outbound iATU is not being enabled\n" ); +dev_err (pci->dev,"Outbound iATU is not being enabled\n" ); } void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
@@ -180,7 +180,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,usleep_range (LINK_WAIT_IATU_MIN ,LINK_WAIT_IATU_MAX ); } -dev_err (pci->dev,"outbound iATU is not being enabled\n" ); +dev_err (pci->dev,"Outbound iATU is not being enabled\n" ); }static u32 dw_pcie_readl_ib_unroll (struct dw_pcie *pci,u32 index,u32 reg)
@@ -238,7 +238,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,usleep_range (LINK_WAIT_IATU_MIN ,LINK_WAIT_IATU_MAX ); } -dev_err (pci->dev,"inbound iATU is not being enabled\n" ); +dev_err (pci->dev,"Inbound iATU is not being enabled\n" );return -EBUSY ; }
@@ -284,7 +284,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,usleep_range (LINK_WAIT_IATU_MIN ,LINK_WAIT_IATU_MAX ); } -dev_err (pci->dev,"inbound iATU is not being enabled\n" ); +dev_err (pci->dev,"Inbound iATU is not being enabled\n" );return -EBUSY ; }
@@ -313,16 +313,16 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci) {int retries; -/* check if the link is up or not */ +/* Check if the link is up or not */ for (retries =0 ; retries <LINK_WAIT_MAX_RETRIES ; retries++) {if (dw_pcie_link_up (pci)) { -dev_info (pci->dev,"link up\n" ); +dev_info (pci->dev,"Link up\n" );return 0 ; }usleep_range (LINK_WAIT_USLEEP_MIN ,LINK_WAIT_USLEEP_MAX ); } -dev_err (pci->dev,"phy link never came up\n" ); +dev_err (pci->dev,"Phy link never came up\n" );return -ETIMEDOUT ; }
@@ -351,7 +351,7 @@ void dw_pcie_setup(struct dw_pcie *pci)if (ret) lanes =0 ; -/* set the number of lanes */ +/* Set the number of lanes */ val =dw_pcie_readl_dbi (pci,PCIE_PORT_LINK_CONTROL ); val &= ~PORT_LINK_MODE_MASK ;switch (lanes) {
@@ -373,7 +373,7 @@ void dw_pcie_setup(struct dw_pcie *pci) }dw_pcie_writel_dbi (pci,PCIE_PORT_LINK_CONTROL , val); -/* set link width speed control register */ +/* Set link width speed control register */ val =dw_pcie_readl_dbi (pci,PCIE_LINK_WIDTH_SPEED_CONTROL ); val &= ~PORT_LOGIC_LINK_WIDTH_MASK ;switch (lanes) {
Signature · 1 line
2.7.4
PATCH v7 8/9 PCI: dwc: Small computation improvement
In reply to Gustavo PimentelReplaces a simple division by 2 to a right shift rotation of 1 bit.
Probably any recent and decent compiler does this kind of substitution in order to improve code performance. Nevertheless it's a coding good practice whenever there is a division / multiplication by multiple of 2 to replace it by the equivalent operation in this case, the shift rotation.
---
Change v1->v2:
- Nothing changed, just to follow the patch set version.
Change v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Added a small explication to the log description.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/pci/dwc/pcie-designware-host.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/pci/dwc/pcie-designware-host.c +4 -4
@@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp) cfg_res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"config" );if (cfg_res) { - pp->cfg0_size =resource_size (cfg_res) /2 ; - pp->cfg1_size =resource_size (cfg_res) /2 ; + pp->cfg0_size =resource_size (cfg_res) >>1 ; + pp->cfg1_size =resource_size (cfg_res) >>1 ; pp->cfg0_base = cfg_res->start; pp->cfg1_base = cfg_res->start + pp->cfg0_size; }else if (!pp->va_cfg0_base) {
@@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)break ;case 0 : pp->cfg = win->res; - pp->cfg0_size =resource_size (pp->cfg) /2 ; - pp->cfg1_size =resource_size (pp->cfg) /2 ; + pp->cfg0_size =resource_size (pp->cfg) >>1 ; + pp->cfg1_size =resource_size (pp->cfg) >>1 ; pp->cfg0_base = pp->cfg->start; pp->cfg1_base = pp->cfg->start + pp->cfg0_size;break ;
Signature · 1 line
2.7.4
PATCH v7 9/9 PCI: dwc: Replace magic number by defines
In reply to Gustavo PimentelReplace magic numbers by a well known define in order to make the code human readable and also facilitate the code reusability.
---
Change v1->v2:
- Nothing changed, just to follow the patch set version.
Change v2->v3:
- Nothing changed, just to follow the patch set version.
Changes v3->v4:
- Nothing changed, just to follow the patch set version.
Changes v4->v5:
- Nothing changed, just to follow the patch set version.
Changes v5->v6:
- Nothing changed, just to follow the patch set version.
Changes v6->v7:
- Nothing changed, just to follow the patch set version.
drivers/pci/dwc/pcie-designware-host.c | 34 ++++++++++++++++++++-------------- drivers/pci/dwc/pcie-designware.h | 1 + 2 files changed, 21 insertions(+), 14 deletions(-)
drivers/pci/dwc/pcie-designware-host.c +20 -14
@@ -83,18 +83,23 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp) num_ctrls = pp->num_vectors /MAX_MSI_IRQS_PER_CTRL ;for (i =0 ; i < num_ctrls; i++) { -dw_pcie_rd_own_conf (pp,PCIE_MSI_INTR0_STATUS + i *12 ,4 , - &val); +dw_pcie_rd_own_conf (pp,PCIE_MSI_INTR0_STATUS + + (i *MSI_REG_CTRL_BLOCK_SIZE ), +4 , &val);if (!val)continue ; ret =IRQ_HANDLED ; pos =0 ; -while ((pos =find_next_bit ((unsigned long *) &val,32 , - pos)) !=32 ) { - irq =irq_find_mapping (pp->irq_domain, i *32 + pos); +while ((pos =find_next_bit ((unsigned long *) &val, +MAX_MSI_IRQS_PER_CTRL , + pos)) !=MAX_MSI_IRQS_PER_CTRL ) { + irq =irq_find_mapping (pp->irq_domain, + (i *MAX_MSI_IRQS_PER_CTRL ) + + pos);generic_handle_irq (irq); -dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_STATUS + i *12 , +dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_STATUS + + (i *MSI_REG_CTRL_BLOCK_SIZE ),4 ,1 << pos); pos++; }
@@ -157,9 +162,9 @@ static void dw_pci_bottom_mask(struct irq_data *data)if (pp->ops->msi_clear_irq) { pp->ops->msi_clear_irq (pp, data->hwirq); }else { - ctrl = data->hwirq /32 ; - res = ctrl *12 ; - bit = data->hwirq %32 ; + ctrl = data->hwirq /MAX_MSI_IRQS_PER_CTRL ; + res = ctrl *MSI_REG_CTRL_BLOCK_SIZE ; + bit = data->hwirq %MAX_MSI_IRQS_PER_CTRL ; pp->irq_status[ctrl] &= ~(1 << bit); dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
@@ -180,9 +185,9 @@ static void dw_pci_bottom_unmask(struct irq_data *data)if (pp->ops->msi_set_irq) { pp->ops->msi_set_irq (pp, data->hwirq); }else { - ctrl = data->hwirq /32 ; - res = ctrl *12 ; - bit = data->hwirq %32 ; + ctrl = data->hwirq /MAX_MSI_IRQS_PER_CTRL ; + res = ctrl *MSI_REG_CTRL_BLOCK_SIZE ; + bit = data->hwirq %MAX_MSI_IRQS_PER_CTRL ; pp->irq_status[ctrl] |=1 << bit; dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
@@ -652,8 +657,9 @@ void dw_pcie_setup_rc(struct pcie_port *pp)/* Initialize IRQ Status array */ for (ctrl =0 ; ctrl < num_ctrls; ctrl++) -dw_pcie_rd_own_conf (pp,PCIE_MSI_INTR0_ENABLE + (ctrl *12 ),4 , - &pp->irq_status[ctrl]); +dw_pcie_rd_own_conf (pp,PCIE_MSI_INTR0_ENABLE + + (ctrl *MSI_REG_CTRL_BLOCK_SIZE ), +4 , &pp->irq_status[ctrl]);/* Setup RC BARs */ dw_pcie_writel_dbi (pci,PCI_BASE_ADDRESS_0 ,0x00000004 );
drivers/pci/dwc/pcie-designware.h +1 -0
@@ -110,6 +110,7 @@#define MAX_MSI_IRQS 256#define MAX_MSI_IRQS_PER_CTRL 32#define MAX_MSI_CTRLS (MAX_MSI_IRQS / MAX_MSI_IRQS_PER_CTRL) +#define MSI_REG_CTRL_BLOCK_SIZE 12#define MSI_DEF_NUM_VECTORS 32/* Maximum number of inbound/outbound iATUs */
Signature · 1 line
2.7.4