Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252789 > unrolled thread

[PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms WingMan Kwok <w-kwok2@ti.com> - 2015-10-21 15:00 +0200
    [PATCH v3 2/2] PCI: keystone: update to use generic keystone serdes driver WingMan Kwok <w-kwok2@ti.com> - 2015-10-21 15:00 +0200
    Re: [PATCH v3 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie Rob Herring <robh+dt@kernel.org> - 2015-10-22 01:00 +0200
      RE: [PATCH v3 1/2] phy: keystone: serdes driver for gbe 10gbe and  pcie "Kwok, WingMan" <w-kwok2@ti.com> - 2015-10-22 16:30 +0200
    Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Murali Karicheri <m-karicheri2@ti.com> - 2015-10-22 17:10 +0200
      Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-22 19:50 +0200
        Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Murali Karicheri <m-karicheri2@ti.com> - 2015-10-23 00:00 +0200
          Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Murali Karicheri <m-karicheri2@ti.com> - 2015-10-23 00:20 +0200
          Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Loc Ho <lho@apm.com> - 2015-10-23 00:30 +0200
            Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Arnd Bergmann <arnd@arndb.de> - 2015-10-23 11:20 +0200
              Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Murali Karicheri <m-karicheri2@ti.com> - 2015-10-23 16:30 +0200
              Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-23 16:50 +0200
                Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Arnd Bergmann <arnd@arndb.de> - 2015-10-23 17:50 +0200
                Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Kishon Vijay Abraham I <kishon@ti.com> - 2015-10-23 21:00 +0200
                  Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms Murali Karicheri <m-karicheri2@ti.com> - 2015-10-26 23:20 +0100

#1252789 — [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch series provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

As an example of the using the SerDes driver, this patch series also
updates the Keystone PCIe host driver to enable and use its SerDes block.

References:
[1] KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide
    (http://www.ti.com/lit/ug/spruho3a/spruho3a.pdf)

v3:
	- addresses the following review comments
		1. https://lkml.org/lkml/2015/10/19/756
			-- included sizes.h
		2. https://lkml.org/lkml/2015/10/19/781
			-- updated base on Fengguang Wu's suggestions.
		3. https://lkml.org/lkml/2015/10/15/896
			-- clarified here https://lkml.org/lkml/2015/10/20/512
			-- nothing to do.

v2:
	- addresses the following review comments on v1:
		1. https://lkml.org/lkml/2015/10/15/896
			-- this does not address the question:
			   "The current code does not do this when compiled,
			    which might be a problem for distributors.
			    Can you clarify the license?"
			-- the question is still under discussion here:
			   https://lkml.org/lkml/2015/10/19/471
		2. https://lkml.org/lkml/2015/10/15/895

v1: 
	- addresses the following review comments
		1. https://lkml.org/lkml/2015/10/13/803
		2. https://lkml.org/lkml/2015/10/14/613
		3. https://lkml.org/lkml/2015/10/13/818

	- An update to PCIe dts bindings to enable the PCIe SerDes is
	  submitted in a separate patch.

WingMan Kwok (2):
  phy: keystone: serdes driver for gbe 10gbe and pcie
  PCI: keystone: update to use generic keystone serdes driver

 Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
 drivers/pci/host/pci-keystone.c                  |   24 +-
 drivers/pci/host/pci-keystone.h                  |    1 +
 drivers/phy/Kconfig                              |    8 +
 drivers/phy/Makefile                             |    1 +
 drivers/phy/phy-keystone-serdes.c                | 2366 ++++++++++++++++++++++
 6 files changed, 2629 insertions(+), 10 deletions(-)
 create mode 100644 drivers/phy/phy-keystone-serdes.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1252794 — [PATCH v3 2/2] PCI: keystone: update to use generic keystone serdes driver

This patch updates the Keystone PCI driver to use the
generic Keystone serdes driver for serdes initialization
and configuration.  The generic serdes driver supports
peripherals on Keystone platforms that require serdes.

Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
---
 drivers/pci/host/pci-keystone.c |   24 ++++++++++++++----------
 drivers/pci/host/pci-keystone.h |    1 +
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd..4cc8faa 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -335,6 +335,7 @@ static int __exit ks_pcie_remove(struct platform_device *pdev)
 {
 	struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
 
+	phy_exit(ks_pcie->serdes_phy);
 	clk_disable_unprepare(ks_pcie->clk);
 
 	return 0;
@@ -342,12 +343,12 @@ static int __exit ks_pcie_remove(struct platform_device *pdev)
 
 static int __init ks_pcie_probe(struct platform_device *pdev)
 {
+	struct device_node *node = pdev->dev.of_node;
 	struct device *dev = &pdev->dev;
 	struct keystone_pcie *ks_pcie;
 	struct pcie_port *pp;
 	struct resource *res;
 	void __iomem *reg_p;
-	struct phy *phy;
 	int ret = 0;
 
 	ks_pcie = devm_kzalloc(&pdev->dev, sizeof(*ks_pcie),
@@ -357,14 +358,6 @@ static int __init ks_pcie_probe(struct platform_device *pdev)
 
 	pp = &ks_pcie->pp;
 
-	/* initialize SerDes Phy if present */
-	phy = devm_phy_get(dev, "pcie-phy");
-	if (!IS_ERR_OR_NULL(phy)) {
-		ret = phy_init(phy);
-		if (ret < 0)
-			return ret;
-	}
-
 	/* index 2 is to read PCI DEVICE_ID */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
 	reg_p = devm_ioremap_resource(dev, res);
@@ -385,6 +378,17 @@ static int __init ks_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	ks_pcie->serdes_phy = devm_of_phy_get(dev, node, NULL);
+	if (IS_ERR(ks_pcie->serdes_phy)) {
+		dev_err(dev, "No %s serdes driver found: %ld\n",
+			node->name, PTR_ERR(ks_pcie->serdes_phy));
+		goto fail_clk;
+	}
+
+	ret = phy_init(ks_pcie->serdes_phy);
+	if (ret < 0)
+		goto fail_clk;
+
 	ret = ks_add_pcie_port(ks_pcie, pdev);
 	if (ret < 0)
 		goto fail_clk;
@@ -392,7 +396,7 @@ static int __init ks_pcie_probe(struct platform_device *pdev)
 	return 0;
 fail_clk:
 	clk_disable_unprepare(ks_pcie->clk);
-
+	phy_exit(ks_pcie->serdes_phy);
 	return ret;
 }
 
diff --git a/drivers/pci/host/pci-keystone.h b/drivers/pci/host/pci-keystone.h
index 478d932..1e6d122 100644
--- a/drivers/pci/host/pci-keystone.h
+++ b/drivers/pci/host/pci-keystone.h
@@ -33,6 +33,7 @@ struct keystone_pcie {
 	/* Application register space */
 	void __iomem		*va_app_base;
 	struct resource		app;
+	struct phy		*serdes_phy;
 };
 
 /* Keystone DW specific MSI controller APIs/definitions */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253328 — Re: [PATCH v3 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

On Wed, Oct 21, 2015 at 7:56 AM, WingMan Kwok <w-kwok2@ti.com> wrote:
> On TI's Keystone platforms, several peripherals such as the
> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> require the use of a SerDes for converting SoC parallel data into
> serialized data that can be output over a high-speed electrical
> interface, and also converting high-speed serial input data
> into parallel data that can be processed by the SoC.  The
> SerDeses used by those peripherals, though they may be different,
> are largely similar in functionality and setup.
>
> This patch provides a SerDes phy driver implementation that can be
> used by the above mentioned peripheral drivers to configure their
> respective SerDeses.
>
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++

For the binding:

Acked-by: Rob Herring <robh@kernel.org>


One other comment:

> +       if (of_device_is_compatible(np, "ti,keystone-serdes-gbe")) {
> +               sc->phy_type = KSERDES_PHY_SGMII;
> +       } else if (of_device_is_compatible(np, "ti,keystone-serdes-xgbe")) {
> +               sc->phy_type = KSERDES_PHY_XGE;
> +       } else if (of_device_is_compatible(np, "ti,keystone-serdes-pcie")) {
> +               sc->phy_type = KSERDES_PHY_PCIE;
> +       } else {
> +               dev_err(dev, "unknown phy type\n");
> +               return -EINVAL;
> +       }

Use the match data to set the type:

> +static const struct of_device_id kserdes_of_match[] = {
> +       { .compatible = "ti,keystone-serdes-gbe" },
> +       { .compatible = "ti,keystone-serdes-pcie" },
> +       { .compatible = "ti,keystone-serdes-xgbe" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, kserdes_of_match);

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253862 — RE: [PATCH v3 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iIEhlcnJpbmcgW21h
aWx0bzpyb2JoK2R0QGtlcm5lbC5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMSwg
MjAxNSA2OjU1IFBNDQo+IFRvOiBLd29rLCBXaW5nTWFuDQo+IENjOiBQYXdlbCBNb2xsOyBNYXJr
IFJ1dGxhbmQ7IElhbiBDYW1wYmVsbDsgS3VtYXIgR2FsYTsgS0lTSE9OIFZJSkFZIEFCUkFIQU07
DQo+IFF1YWRyb3MsIFJvZ2VyOyBLYXJpY2hlcmksIE11cmFsaWRoYXJhbjsgQmpvcm4gSGVsZ2Fh
czsgU2FudG9zaCBTaGlsaW1rYXI7DQo+IFJ1c3NlbGwgS2luZyAtIEFSTSBMaW51eDsgZGV2aWNl
dHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwub3JnOyBs
aW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtlcm5lbEBsaXN0cy5pbmZy
YWRlYWQub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMS8yXSBwaHk6IGtleXN0b25lOiBz
ZXJkZXMgZHJpdmVyIGZvciBnYmUgMTBnYmUgYW5kDQo+IHBjaWUNCj4gDQo+IE9uIFdlZCwgT2N0
IDIxLCAyMDE1IGF0IDc6NTYgQU0sIFdpbmdNYW4gS3dvayA8dy1rd29rMkB0aS5jb20+IHdyb3Rl
Og0KPiA+IE9uIFRJJ3MgS2V5c3RvbmUgcGxhdGZvcm1zLCBzZXZlcmFsIHBlcmlwaGVyYWxzIHN1
Y2ggYXMgdGhlDQo+ID4gZ2JlIGV0aGVybmV0IHN3aXRjaCwgMTBnYmUgZXRoZXJuZXQgc3dpdGNo
IGFuZCBQQ0llIGNvbnRyb2xsZXINCj4gPiByZXF1aXJlIHRoZSB1c2Ugb2YgYSBTZXJEZXMgZm9y
IGNvbnZlcnRpbmcgU29DIHBhcmFsbGVsIGRhdGEgaW50bw0KPiA+IHNlcmlhbGl6ZWQgZGF0YSB0
aGF0IGNhbiBiZSBvdXRwdXQgb3ZlciBhIGhpZ2gtc3BlZWQgZWxlY3RyaWNhbA0KPiA+IGludGVy
ZmFjZSwgYW5kIGFsc28gY29udmVydGluZyBoaWdoLXNwZWVkIHNlcmlhbCBpbnB1dCBkYXRhDQo+
ID4gaW50byBwYXJhbGxlbCBkYXRhIHRoYXQgY2FuIGJlIHByb2Nlc3NlZCBieSB0aGUgU29DLiAg
VGhlDQo+ID4gU2VyRGVzZXMgdXNlZCBieSB0aG9zZSBwZXJpcGhlcmFscywgdGhvdWdoIHRoZXkg
bWF5IGJlIGRpZmZlcmVudCwNCj4gPiBhcmUgbGFyZ2VseSBzaW1pbGFyIGluIGZ1bmN0aW9uYWxp
dHkgYW5kIHNldHVwLg0KPiA+DQo+ID4gVGhpcyBwYXRjaCBwcm92aWRlcyBhIFNlckRlcyBwaHkg
ZHJpdmVyIGltcGxlbWVudGF0aW9uIHRoYXQgY2FuIGJlDQo+ID4gdXNlZCBieSB0aGUgYWJvdmUg
bWVudGlvbmVkIHBlcmlwaGVyYWwgZHJpdmVycyB0byBjb25maWd1cmUgdGhlaXINCj4gPiByZXNw
ZWN0aXZlIFNlckRlc2VzLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogV2luZ01hbiBLd29rIDx3
LWt3b2syQHRpLmNvbT4NCj4gPiAtLS0NCj4gPiAgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL3BoeS90aS1waHkudHh0IHwgIDIzOSArKysNCj4gDQo+IEZvciB0aGUgYmluZGluZzoN
Cj4gDQo+IEFja2VkLWJ5OiBSb2IgSGVycmluZyA8cm9iaEBrZXJuZWwub3JnPg0KPiANCj4gDQo+
IE9uZSBvdGhlciBjb21tZW50Og0KPiANCj4gPiArICAgICAgIGlmIChvZl9kZXZpY2VfaXNfY29t
cGF0aWJsZShucCwgInRpLGtleXN0b25lLXNlcmRlcy1nYmUiKSkgew0KPiA+ICsgICAgICAgICAg
ICAgICBzYy0+cGh5X3R5cGUgPSBLU0VSREVTX1BIWV9TR01JSTsNCj4gPiArICAgICAgIH0gZWxz
ZSBpZiAob2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobnAsICJ0aSxrZXlzdG9uZS1zZXJkZXMteGdi
ZSIpKQ0KPiB7DQo+ID4gKyAgICAgICAgICAgICAgIHNjLT5waHlfdHlwZSA9IEtTRVJERVNfUEhZ
X1hHRTsNCj4gPiArICAgICAgIH0gZWxzZSBpZiAob2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobnAs
ICJ0aSxrZXlzdG9uZS1zZXJkZXMtcGNpZSIpKQ0KPiB7DQo+ID4gKyAgICAgICAgICAgICAgIHNj
LT5waHlfdHlwZSA9IEtTRVJERVNfUEhZX1BDSUU7DQo+ID4gKyAgICAgICB9IGVsc2Ugew0KPiA+
ICsgICAgICAgICAgICAgICBkZXZfZXJyKGRldiwgInVua25vd24gcGh5IHR5cGVcbiIpOw0KPiA+
ICsgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gPiArICAgICAgIH0NCj4gDQo+IFVz
ZSB0aGUgbWF0Y2ggZGF0YSB0byBzZXQgdGhlIHR5cGU6DQo+IA0KDQp3aWxsIGRvLg0KDQo+ID4g
K3N0YXRpYyBjb25zdCBzdHJ1Y3Qgb2ZfZGV2aWNlX2lkIGtzZXJkZXNfb2ZfbWF0Y2hbXSA9IHsN
Cj4gPiArICAgICAgIHsgLmNvbXBhdGlibGUgPSAidGksa2V5c3RvbmUtc2VyZGVzLWdiZSIgfSwN
Cj4gPiArICAgICAgIHsgLmNvbXBhdGlibGUgPSAidGksa2V5c3RvbmUtc2VyZGVzLXBjaWUiIH0s
DQo+ID4gKyAgICAgICB7IC5jb21wYXRpYmxlID0gInRpLGtleXN0b25lLXNlcmRlcy14Z2JlIiB9
LA0KPiA+ICsgICAgICAgeyB9LA0KPiA+ICt9Ow0KPiA+ICtNT0RVTEVfREVWSUNFX1RBQkxFKG9m
LCBrc2VyZGVzX29mX21hdGNoKTsNCj4gDQo+IFJvYg0KDQpUaGFua3MsDQpXaW5nTWFuDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253897

On 10/21/2015 08:56 AM, WingMan Kwok wrote:
> On TI's Keystone platforms, several peripherals such as the
> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> require the use of a SerDes for converting SoC parallel data into
> serialized data that can be output over a high-speed electrical
> interface, and also converting high-speed serial input data
> into parallel data that can be processed by the SoC.  The
> SerDeses used by those peripherals, though they may be different,
> are largely similar in functionality and setup.
>
> This patch series provides a SerDes phy driver implementation that can be
> used by the above mentioned peripheral drivers to configure their
> respective SerDeses.
>
> As an example of the using the SerDes driver, this patch series also
> updates the Keystone PCIe host driver to enable and use its SerDes block.
>
> References:
> [1] KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide
>      (http://www.ti.com/lit/ug/spruho3a/spruho3a.pdf)
>
> v3:
> 	- addresses the following review comments
> 		1. https://lkml.org/lkml/2015/10/19/756
> 			-- included sizes.h
> 		2. https://lkml.org/lkml/2015/10/19/781
> 			-- updated base on Fengguang Wu's suggestions.
> 		3. https://lkml.org/lkml/2015/10/15/896
> 			-- clarified here https://lkml.org/lkml/2015/10/20/512
> 			-- nothing to do.
>
> v2:
> 	- addresses the following review comments on v1:
> 		1. https://lkml.org/lkml/2015/10/15/896
> 			-- this does not address the question:
> 			   "The current code does not do this when compiled,
> 			    which might be a problem for distributors.
> 			    Can you clarify the license?"
> 			-- the question is still under discussion here:
> 			   https://lkml.org/lkml/2015/10/19/471
> 		2. https://lkml.org/lkml/2015/10/15/895
>
> v1:
> 	- addresses the following review comments
> 		1. https://lkml.org/lkml/2015/10/13/803
> 		2. https://lkml.org/lkml/2015/10/14/613
> 		3. https://lkml.org/lkml/2015/10/13/818
>
> 	- An update to PCIe dts bindings to enable the PCIe SerDes is
> 	  submitted in a separate patch.
>
> WingMan Kwok (2):
>    phy: keystone: serdes driver for gbe 10gbe and pcie
>    PCI: keystone: update to use generic keystone serdes driver
>
>   Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
>   drivers/pci/host/pci-keystone.c                  |   24 +-
>   drivers/pci/host/pci-keystone.h                  |    1 +
>   drivers/phy/Kconfig                              |    8 +
>   drivers/phy/Makefile                             |    1 +
>   drivers/phy/phy-keystone-serdes.c                | 2366 ++++++++++++++++++++++
>   6 files changed, 2629 insertions(+), 10 deletions(-)
>   create mode 100644 drivers/phy/phy-keystone-serdes.c
>
Kishon, Bjorn

Who will pick this up? Do we have time to get this in 4.4?
-- 
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254012

On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote:
> On 10/21/2015 08:56 AM, WingMan Kwok wrote:
> >On TI's Keystone platforms, several peripherals such as the
> >gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> >require the use of a SerDes for converting SoC parallel data into
> >serialized data that can be output over a high-speed electrical
> >interface, and also converting high-speed serial input data
> >into parallel data that can be processed by the SoC.  The
> >SerDeses used by those peripherals, though they may be different,
> >are largely similar in functionality and setup.
> >
> >This patch series provides a SerDes phy driver implementation that can be
> >used by the above mentioned peripheral drivers to configure their
> >respective SerDeses.
> >
> >As an example of the using the SerDes driver, this patch series also
> >updates the Keystone PCIe host driver to enable and use its SerDes block.
> >
> >References:
> >[1] KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide
> >     (http://www.ti.com/lit/ug/spruho3a/spruho3a.pdf)
> >
> >v3:
> >	- addresses the following review comments
> >		1. https://lkml.org/lkml/2015/10/19/756
> >			-- included sizes.h
> >		2. https://lkml.org/lkml/2015/10/19/781
> >			-- updated base on Fengguang Wu's suggestions.
> >		3. https://lkml.org/lkml/2015/10/15/896
> >			-- clarified here https://lkml.org/lkml/2015/10/20/512
> >			-- nothing to do.
> >
> >v2:
> >	- addresses the following review comments on v1:
> >		1. https://lkml.org/lkml/2015/10/15/896
> >			-- this does not address the question:
> >			   "The current code does not do this when compiled,
> >			    which might be a problem for distributors.
> >			    Can you clarify the license?"
> >			-- the question is still under discussion here:
> >			   https://lkml.org/lkml/2015/10/19/471
> >		2. https://lkml.org/lkml/2015/10/15/895
> >
> >v1:
> >	- addresses the following review comments
> >		1. https://lkml.org/lkml/2015/10/13/803
> >		2. https://lkml.org/lkml/2015/10/14/613
> >		3. https://lkml.org/lkml/2015/10/13/818
> >
> >	- An update to PCIe dts bindings to enable the PCIe SerDes is
> >	  submitted in a separate patch.
> >
> >WingMan Kwok (2):
> >   phy: keystone: serdes driver for gbe 10gbe and pcie
> >   PCI: keystone: update to use generic keystone serdes driver
> >
> >  Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
> >  drivers/pci/host/pci-keystone.c                  |   24 +-
> >  drivers/pci/host/pci-keystone.h                  |    1 +
> >  drivers/phy/Kconfig                              |    8 +
> >  drivers/phy/Makefile                             |    1 +
> >  drivers/phy/phy-keystone-serdes.c                | 2366 ++++++++++++++++++++++
> >  6 files changed, 2629 insertions(+), 10 deletions(-)
> >  create mode 100644 drivers/phy/phy-keystone-serdes.c
> >
> Kishon, Bjorn
> 
> Who will pick this up? Do we have time to get this in 4.4?

I've been avoiding this since my initial comments, but if you're wanting
to get it into v4.4, then I have to say something.

Again, there's other SoCs out there which have serdes.  Adding 2.5k of
lines for vendor serdes implementations does not scale - this needs to
be re-thought in a way which reduces the code maintanence burden.

Other SoCs like Marvell Armada have serdes links which can be configured
between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
lines to support their device too?  What happens when we have 10 of
these, and we have 25k lines of code here?

Again, this does not scale.  Please look at what can be done to reduce
the code size when other implementations come along.

(I am aware that guys working on Marvell Armada are looking into this
problem - but I know they're ready to post anything yet.)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254196

On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote:
>> On 10/21/2015 08:56 AM, WingMan Kwok wrote:
>>> On TI's Keystone platforms, several peripherals such as the
>>> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
>>> require the use of a SerDes for converting SoC parallel data into
>>> serialized data that can be output over a high-speed electrical
>>> interface, and also converting high-speed serial input data
>>> into parallel data that can be processed by the SoC.  The
>>> SerDeses used by those peripherals, though they may be different,
>>> are largely similar in functionality and setup.
------------Cut-------------------------------------------------
>>>
>>>   Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
>>>   drivers/pci/host/pci-keystone.c                  |   24 +-
>>>   drivers/pci/host/pci-keystone.h                  |    1 +
>>>   drivers/phy/Kconfig                              |    8 +
>>>   drivers/phy/Makefile                             |    1 +
>>>   drivers/phy/phy-keystone-serdes.c                | 2366 ++++++++++++++++++++++
>>>   6 files changed, 2629 insertions(+), 10 deletions(-)
>>>   create mode 100644 drivers/phy/phy-keystone-serdes.c
>>>
>> Kishon, Bjorn
>>
>> Who will pick this up? Do we have time to get this in 4.4?
>
> I've been avoiding this since my initial comments, but if you're wanting
> to get it into v4.4, then I have to say something.
Russell,

I saw you have raised this point earlier against v1 of the patch series. 
I have responded as below  (cut-n-pasted from that email)

"The serdes on K2 are re-used on multiple hardware blocks as already 
indicated in this thread. It has got multiple lanes, each lane can be 
enabled/disabled, shutdown etc. Isn't generic phy framework added to 
support this type of hardware block? I see some enhancements needed for 
K2 serdes to support monitoring the serdes link and providing a status 
to the higher layer device. So I am not clear what different way you 
would like to handle serdes drivers? Why do you need a new framework?
"

KISHON VIJAY had responded saying

"The PHY framework (in drivers/phy/) already provides a standard
interface to be used by the controller drivers no?"

But I have not seen your response to these questions from us. v2 and v3 
has gone by and since all of the outstanding comments have been 
addressed and you have not responded to our questions, I thought this 
can be merged for 4.4. Good to see you have responded now :)
>
> Again, there's other SoCs out there which have serdes.  Adding 2.5k of
> lines for vendor serdes implementations does not scale - this needs to
> be re-thought in a way which reduces the code maintanence burden.
>
> Other SoCs like Marvell Armada have serdes links which can be configured
> between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
> lines to support their device too?  What happens when we have 10 of
> these, and we have 25k lines of code here?
>
> Again, this does not scale.  Please look at what can be done to reduce
> the code size when other implementations come along.

Well, per our understanding, this driver is a Generic phy driver and we 
have implemented a device driver based on Generic Phy API. This driver 
is expected to support all of the 3 peripherals :- PCIe, 1G and 10G 
Ethernet.  You have mentioned about Marvell & Armada . Did Marvell post 
any patch already? Without seeing their code, how will we be able to 
investigate what can be factored out to a generic serdes core driver? By 
making this statement, I assume you are still considering using the 
Generic Phy driver framework for SerDes drivers. Don't you?

I did a search in the phy folder and these are the top ones that came 
out in terms of number of lines of code after Phy-core.c.

ls *.[ch] | xargs wc -l | sort -n

    943 phy-core.c
   1279 phy-miphy28lp.c
   1735 phy-xgene.c
   2367 phy-keystone-serdes.c

So focusing on the top 3 drivers (including keystone serdes) under phy.

phy-xgene.c
-----------

Looking at other drivers under drivers/phy, I could find phy-xgene.c 
which is close Keystone SerDes driver (. This is called APM X-Gene 
Multi-Purpose PHY driver. It defines following mode per the driver code

         MODE_SATA       = 0,    /* List them for simple reference */
         MODE_SGMII      = 1,
         MODE_PCIE       = 2,
         MODE_USB        = 3,
         MODE_XFI        = 4,

But seems to support only MODE_SATA. From the code, it appears, this 
driver is expected to be enhanced in the future to support additional 
modes. I have copied the author to this email to participate in this 
discussion.

Keystone SerDes supports following modes
----------------------------------------
	KSERDES_PHY_SGMII,
	KSERDES_PHY_XGE,
	KSERDES_PHY_PCIE,
	KSERDES_PHY_HYPERLINK,
	KSERDES_PHY_SRIO

And phy-miphy28lp.c
---------------------

+#define PHY_TYPE_SATA          1
+#define PHY_TYPE_PCIE          2
+#define PHY_TYPE_USB2          3
+#define PHY_TYPE_USB3          4

Keystone SerDes hardware is highly parameterized. The init has following 
steps:-
   - Configure the Phy to one of the mode (SATA,SGMII,PCIE,USB,XFI)
   - Configure the Phy to the specific mode
   - Configure N lanes for the selected mode
   - Enable N Lanes

So at a high level, I can imagine these kind of Phys require additionally

   - Enable/Disable Lane
   - check lane status periodically

So there is a scope for enhancing the Phy core API to handle these kinds 
of phy ops. This might help to re-use some code. But at the lower level 
driver, we still need to write to vendor specific registers and 
configure the SerDes which is the major part of the driver and that 
still will be a major part of these drivers.

I would also like to hear from Kishon (Maintainer) on his ideas for 
Generic Phy driver to support these kind of SerDes hardwares.

I think it is fair to ask to merge the Keystone SerDes driver right now 
as we have spend considerable time reviewing the current series and 
taken care of all other outstanding comments. We are most happy to 
enhance the Phy core framework to help re-use code across the above and 
future SerDes driver that supports multiple modes.

Or do you have some other ideas that you would like to share?

Murali

>
> (I am aware that guys working on Marvell Armada are looking into this
> problem - but I know they're ready to post anything yet.)
>


-- 
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254200

+ Alexandre Torgue <alexandre.torgue@st.com> (Owner of phy-miphy28lp.c)
+ Loc Ho <lho@apm.com> (Owner of phy-miphy28lp.c)

On 10/22/2015 05:56 PM, Murali Karicheri wrote:
> On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote:
>> On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote:
>>> On 10/21/2015 08:56 AM, WingMan Kwok wrote:
>>>> On TI's Keystone platforms, several peripherals such as the
>>>> gbe ethernet switch, 10gbe ethernet switch and PCIe controller
>>>> require the use of a SerDes for converting SoC parallel data into
>>>> serialized data that can be output over a high-speed electrical
>>>> interface, and also converting high-speed serial input data
>>>> into parallel data that can be processed by the SoC.  The
>>>> SerDeses used by those peripherals, though they may be different,
>>>> are largely similar in functionality and setup.
> ------------Cut-------------------------------------------------
>>>>
>>>>   Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
>>>>   drivers/pci/host/pci-keystone.c                  |   24 +-
>>>>   drivers/pci/host/pci-keystone.h                  |    1 +
>>>>   drivers/phy/Kconfig                              |    8 +
>>>>   drivers/phy/Makefile                             |    1 +
>>>>   drivers/phy/phy-keystone-serdes.c                | 2366
>>>> ++++++++++++++++++++++
>>>>   6 files changed, 2629 insertions(+), 10 deletions(-)
>>>>   create mode 100644 drivers/phy/phy-keystone-serdes.c
>>>>
>>> Kishon, Bjorn
>>>
>>> Who will pick this up? Do we have time to get this in 4.4?
>>
>> I've been avoiding this since my initial comments, but if you're wanting
>> to get it into v4.4, then I have to say something.
> Russell,
>
> I saw you have raised this point earlier against v1 of the patch series.
> I have responded as below  (cut-n-pasted from that email)
>
> "The serdes on K2 are re-used on multiple hardware blocks as already
> indicated in this thread. It has got multiple lanes, each lane can be
> enabled/disabled, shutdown etc. Isn't generic phy framework added to
> support this type of hardware block? I see some enhancements needed for
> K2 serdes to support monitoring the serdes link and providing a status
> to the higher layer device. So I am not clear what different way you
> would like to handle serdes drivers? Why do you need a new framework?
> "
>
> KISHON VIJAY had responded saying
>
> "The PHY framework (in drivers/phy/) already provides a standard
> interface to be used by the controller drivers no?"
>
> But I have not seen your response to these questions from us. v2 and v3
> has gone by and since all of the outstanding comments have been
> addressed and you have not responded to our questions, I thought this
> can be merged for 4.4. Good to see you have responded now :)
>>
>> Again, there's other SoCs out there which have serdes.  Adding 2.5k of
>> lines for vendor serdes implementations does not scale - this needs to
>> be re-thought in a way which reduces the code maintanence burden.
>>
>> Other SoCs like Marvell Armada have serdes links which can be configured
>> between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
>> lines to support their device too?  What happens when we have 10 of
>> these, and we have 25k lines of code here?
>>
>> Again, this does not scale.  Please look at what can be done to reduce
>> the code size when other implementations come along.
>
> Well, per our understanding, this driver is a Generic phy driver and we
> have implemented a device driver based on Generic Phy API. This driver
> is expected to support all of the 3 peripherals :- PCIe, 1G and 10G
> Ethernet.  You have mentioned about Marvell & Armada . Did Marvell post
> any patch already? Without seeing their code, how will we be able to
> investigate what can be factored out to a generic serdes core driver? By
> making this statement, I assume you are still considering using the
> Generic Phy driver framework for SerDes drivers. Don't you?
>
> I did a search in the phy folder and these are the top ones that came
> out in terms of number of lines of code after Phy-core.c.
>
> ls *.[ch] | xargs wc -l | sort -n
>
>     943 phy-core.c
>    1279 phy-miphy28lp.c
>    1735 phy-xgene.c
>    2367 phy-keystone-serdes.c
>
> So focusing on the top 3 drivers (including keystone serdes) under phy.
>
> phy-xgene.c
> -----------
>
> Looking at other drivers under drivers/phy, I could find phy-xgene.c
> which is close Keystone SerDes driver (. This is called APM X-Gene
> Multi-Purpose PHY driver. It defines following mode per the driver code
>
>          MODE_SATA       = 0,    /* List them for simple reference */
>          MODE_SGMII      = 1,
>          MODE_PCIE       = 2,
>          MODE_USB        = 3,
>          MODE_XFI        = 4,
>
> But seems to support only MODE_SATA. From the code, it appears, this
> driver is expected to be enhanced in the future to support additional
> modes. I have copied the author to this email to participate in this
> discussion.
>
> Keystone SerDes supports following modes
> ----------------------------------------
>      KSERDES_PHY_SGMII,
>      KSERDES_PHY_XGE,
>      KSERDES_PHY_PCIE,
>      KSERDES_PHY_HYPERLINK,
>      KSERDES_PHY_SRIO
>
> And phy-miphy28lp.c
> ---------------------
>
> +#define PHY_TYPE_SATA          1
> +#define PHY_TYPE_PCIE          2
> +#define PHY_TYPE_USB2          3
> +#define PHY_TYPE_USB3          4
>
> Keystone SerDes hardware is highly parameterized. The init has following
> steps:-
>    - Configure the Phy to one of the mode (SATA,SGMII,PCIE,USB,XFI)
>    - Configure the Phy to the specific mode
>    - Configure N lanes for the selected mode
>    - Enable N Lanes
>
> So at a high level, I can imagine these kind of Phys require additionally
>
>    - Enable/Disable Lane
>    - check lane status periodically
>
> So there is a scope for enhancing the Phy core API to handle these kinds
> of phy ops. This might help to re-use some code. But at the lower level
> driver, we still need to write to vendor specific registers and
> configure the SerDes which is the major part of the driver and that
> still will be a major part of these drivers.
>
> I would also like to hear from Kishon (Maintainer) on his ideas for
> Generic Phy driver to support these kind of SerDes hardwares.
>
> I think it is fair to ask to merge the Keystone SerDes driver right now
> as we have spend considerable time reviewing the current series and
> taken care of all other outstanding comments. We are most happy to
> enhance the Phy core framework to help re-use code across the above and
> future SerDes driver that supports multiple modes.
>
> Or do you have some other ideas that you would like to share?
>
> Murali
>
>>
>> (I am aware that guys working on Marvell Armada are looking into this
>> problem - but I know they're ready to post anything yet.)
>>
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254213

Hi Murali,

>>
>>
>> Again, there's other SoCs out there which have serdes.  Adding 2.5k of
>> lines for vendor serdes implementations does not scale - this needs to
>> be re-thought in a way which reduces the code maintanence burden.
>>
>> Other SoCs like Marvell Armada have serdes links which can be configured
>> between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
>> lines to support their device too?  What happens when we have 10 of
>> these, and we have 25k lines of code here?
>>
>> Again, this does not scale.  Please look at what can be done to reduce
>> the code size when other implementations come along.
>
>
> Well, per our understanding, this driver is a Generic phy driver and we have
> implemented a device driver based on Generic Phy API. This driver is
> expected to support all of the 3 peripherals :- PCIe, 1G and 10G Ethernet.
> You have mentioned about Marvell & Armada . Did Marvell post any patch
> already? Without seeing their code, how will we be able to investigate what
> can be factored out to a generic serdes core driver? By making this
> statement, I assume you are still considering using the Generic Phy driver
> framework for SerDes drivers. Don't you?
>
> I did a search in the phy folder and these are the top ones that came out in
> terms of number of lines of code after Phy-core.c.
>
> ls *.[ch] | xargs wc -l | sort -n
>
>    943 phy-core.c
>   1279 phy-miphy28lp.c
>   1735 phy-xgene.c
>   2367 phy-keystone-serdes.c
>
> So focusing on the top 3 drivers (including keystone serdes) under phy.
>
> phy-xgene.c
> -----------
>
> Looking at other drivers under drivers/phy, I could find phy-xgene.c which
> is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
> PHY driver. It defines following mode per the driver code
>
>         MODE_SATA       = 0,    /* List them for simple reference */
>         MODE_SGMII      = 1,
>         MODE_PCIE       = 2,
>         MODE_USB        = 3,
>         MODE_XFI        = 4,
>
> But seems to support only MODE_SATA. From the code, it appears, this driver
> is expected to be enhanced in the future to support additional modes. I have
> copied the author to this email to participate in this discussion.

Let me comment on this APM X-Gene driver. This driver is dead and
won't be supported in near or foreseeable future. And someday, it will
be ripped out. Based on experience, this solution (having PHY driver
in Linux) can't be supported across boards and etc as it is just too
much maintenance. And therefore, we followed Arnd B guidance and move
all this into the boot loader. From Linux or OS perspective, it only
cares about the interface in which its interface with. This is just
your reference and may be this will help you as well.

-Loc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254414

On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
> >
> > phy-xgene.c
> > -----------
> >
> > Looking at other drivers under drivers/phy, I could find phy-xgene.c which
> > is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
> > PHY driver. It defines following mode per the driver code
> >
> >         MODE_SATA       = 0,    /* List them for simple reference */
> >         MODE_SGMII      = 1,
> >         MODE_PCIE       = 2,
> >         MODE_USB        = 3,
> >         MODE_XFI        = 4,
> >
> > But seems to support only MODE_SATA. From the code, it appears, this driver
> > is expected to be enhanced in the future to support additional modes. I have
> > copied the author to this email to participate in this discussion.
> 
> Let me comment on this APM X-Gene driver. This driver is dead and
> won't be supported in near or foreseeable future. And someday, it will
> be ripped out. Based on experience, this solution (having PHY driver
> in Linux) can't be supported across boards and etc as it is just too
> much maintenance. And therefore, we followed Arnd B guidance and move
> all this into the boot loader. From Linux or OS perspective, it only
> cares about the interface in which its interface with. This is just
> your reference and may be this will help you as well.

This depends a lot on the use case. If the chip is only used on server
parts that have a real firmware and you can deliver bug fixes for the
firmware if necessary, it's always best to do as much of the setup as
possible there, and let Linux see a simplified view of the hardware.

However, for embedded systems that tend to ship with a minimal binary
bootloader and no way to update that as an end-user, we rely on Linux
to know about all the hardware that requires some form of setup, which
is why we have all sorts of drivers and frameworks in the kernel that
a server can easily ignore.

While keystone can show up in servers that won't use this driver, my
impression is that its main market is actually in embedded space.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254642

On 10/23/2015 05:17 AM, Arnd Bergmann wrote:
> On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
>>>
>>> phy-xgene.c
>>> -----------
>>>
>>> Looking at other drivers under drivers/phy, I could find phy-xgene.c which
>>> is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
>>> PHY driver. It defines following mode per the driver code
>>>
>>>          MODE_SATA       = 0,    /* List them for simple reference */
>>>          MODE_SGMII      = 1,
>>>          MODE_PCIE       = 2,
>>>          MODE_USB        = 3,
>>>          MODE_XFI        = 4,
>>>
>>> But seems to support only MODE_SATA. From the code, it appears, this driver
>>> is expected to be enhanced in the future to support additional modes. I have
>>> copied the author to this email to participate in this discussion.
>>
>> Let me comment on this APM X-Gene driver. This driver is dead and
>> won't be supported in near or foreseeable future. And someday, it will
>> be ripped out. Based on experience, this solution (having PHY driver
>> in Linux) can't be supported across boards and etc as it is just too
>> much maintenance. And therefore, we followed Arnd B guidance and move
>> all this into the boot loader. From Linux or OS perspective, it only
>> cares about the interface in which its interface with. This is just
>> your reference and may be this will help you as well.
>
> This depends a lot on the use case. If the chip is only used on server
> parts that have a real firmware and you can deliver bug fixes for the
> firmware if necessary, it's always best to do as much of the setup as
> possible there, and let Linux see a simplified view of the hardware.
>
> However, for embedded systems that tend to ship with a minimal binary
> bootloader and no way to update that as an end-user, we rely on Linux
> to know about all the hardware that requires some form of setup, which
> is why we have all sorts of drivers and frameworks in the kernel that
> a server can easily ignore.
>
> While keystone can show up in servers that won't use this driver, my
> impression is that its main market is actually in embedded space.
It is in embedded space predominantly. From our experience, this has to 
be a Linux driver and moving this to boot loader doesn't make sense.

Murali
>
> 	Arnd
>


-- 
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254650

On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:
> On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
> > >
> > > phy-xgene.c
> > > -----------
> > >
> > > Looking at other drivers under drivers/phy, I could find phy-xgene.c which
> > > is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
> > > PHY driver. It defines following mode per the driver code
> > >
> > >         MODE_SATA       = 0,    /* List them for simple reference */
> > >         MODE_SGMII      = 1,
> > >         MODE_PCIE       = 2,
> > >         MODE_USB        = 3,
> > >         MODE_XFI        = 4,
> > >
> > > But seems to support only MODE_SATA. From the code, it appears, this driver
> > > is expected to be enhanced in the future to support additional modes. I have
> > > copied the author to this email to participate in this discussion.
> > 
> > Let me comment on this APM X-Gene driver. This driver is dead and
> > won't be supported in near or foreseeable future. And someday, it will
> > be ripped out. Based on experience, this solution (having PHY driver
> > in Linux) can't be supported across boards and etc as it is just too
> > much maintenance. And therefore, we followed Arnd B guidance and move
> > all this into the boot loader. From Linux or OS perspective, it only
> > cares about the interface in which its interface with. This is just
> > your reference and may be this will help you as well.
> 
> This depends a lot on the use case. If the chip is only used on server
> parts that have a real firmware and you can deliver bug fixes for the
> firmware if necessary, it's always best to do as much of the setup as
> possible there, and let Linux see a simplified view of the hardware.
> 
> However, for embedded systems that tend to ship with a minimal binary
> bootloader and no way to update that as an end-user, we rely on Linux
> to know about all the hardware that requires some form of setup, which
> is why we have all sorts of drivers and frameworks in the kernel that
> a server can easily ignore.
> 
> While keystone can show up in servers that won't use this driver, my
> impression is that its main market is actually in embedded space.

That's an interesting point of view - especially as you can't make the
argument that Marvell Armada chips would ever be anything but the
embedded space, but we're so far getting away with having the serdes
setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.

The real question here is:

  Why would we want to statically setup serdes links in the kernel
  according to the DTB, rather than having the boot loader set them up?

For the most part, the choice between the serdes modes is fairly static,
depending on the board wiring.  You wouldn't ever want to configure a
mini-PCIe socket for gigabit ethernet.

However, there are cases when you would want to change it, and I'm
aware of these cases:

* Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
  There's an argument here to allow the serdes link to be switched at
  runtime between PCIe and mSATA.  However, the card type can't be
  detected at run time, so this would have to be a manual configuration
  change by the user.

  Since mini-PCIe is not hot-pluggable, this configuration isn't
  something that could be changed without powering the system down.

* Serdes routed to a SFP cage, where the serdes link is configured
  for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
  is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
  non-802.3 modification to 1000base-X) depending on the type of
  transceiver plugged in.

  Arguably, there's a third option here, which is SATA as well -  I'm
  aware of one non-standard SFP module on the market which provides a
  SATA connector, but this is highly non-standard, is not covered by
  the SFP specifications, so such a switch to this mode would have to
  be done manually.

The difference between 1000base-X vs SGMII is to do with the generation
and interpretation of a 16-bit configuration word passed across the
link.  Otherwise, the two are identical - and so far I've seen the
configuration word mode is determined by the ethernet block rather than
the serdes block.

My argument would be that even in the case of the last paragraph,
normal use for serdes reconfiguration would be a power cycle, even in
the embedded environment.

Now, that all said, it looks to me like TI's serdes implementation can't
be switched between different modes - it's statically configured to
whatever the DTB says it should be.

So, this brings up the obvious question: why do we need to support
serdes configuration in the kernel rather than statically in the boot
loader according to the board setup?

Specifically on this patch series, I think that if we're going to have
code doing serdes configuration in the kernel, we need to come up with
a common set of DT properties for it, rather than having everyone doing
their own thing.  I'd also like to see the code shrink in size - it
doesn't do anything beyond configuring the hardware for the settings
that DTB tells it to, so why it has to be 2.5k lines I've no idea.

There's some specific comments I have about it using readl/writel, and
its wrapping of those, which IMHO it shouldn't be doing, and the horrid
for loops (what's wrong with the standard Linux way of defining a
for_each_xxx() operator and leaving the body at the callsite?)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254683

On Friday 23 October 2015 15:46:31 Russell King - ARM Linux wrote:
> On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:
> > On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
> > However, for embedded systems that tend to ship with a minimal binary
> > bootloader and no way to update that as an end-user, we rely on Linux
> > to know about all the hardware that requires some form of setup, which
> > is why we have all sorts of drivers and frameworks in the kernel that
> > a server can easily ignore.
> > 
> > While keystone can show up in servers that won't use this driver, my
> > impression is that its main market is actually in embedded space.
> 
> That's an interesting point of view - especially as you can't make the
> argument that Marvell Armada chips would ever be anything but the
> embedded space, but we're so far getting away with having the serdes
> setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.
> 
> The real question here is:
> 
>   Why would we want to statically setup serdes links in the kernel
>   according to the DTB, rather than having the boot loader set them up?
> 
> For the most part, the choice between the serdes modes is fairly static,
> depending on the board wiring.  You wouldn't ever want to configure a
> mini-PCIe socket for gigabit ethernet.

To rephrase what I was saying above: we need to know whether we can
trust the bootloader to get it right. In servers, it's absolutely
required for the firmware to do this properly as far as I'm concerned.

If Marvell's bootloader gets this right reliably as well, that's great.
However, certain companies have been known in the past to ship
crazy broken bootloaders and for each thing that they get wrong, we
have to make up in the kernel unless we can get all users to upgrade
their bootloaders to a fixed version.

> However, there are cases when you would want to change it, and I'm
> aware of these cases:
> 
> * Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
>   There's an argument here to allow the serdes link to be switched at
>   runtime between PCIe and mSATA.  However, the card type can't be
>   detected at run time, so this would have to be a manual configuration
>   change by the user.
> 
>   Since mini-PCIe is not hot-pluggable, this configuration isn't
>   something that could be changed without powering the system down.

Right, but isn't this something that the firmware ought to be able
to figure out? For a server, I would expect that there needs to be
a way to detect what card is plugged and, have it set up correctly
and put all the right entries into the DT.

u-boot could probably do the same thing, but I would expect at least
some hardware vendors to get some part of it wrong on an embedded
machine.

> * Serdes routed to a SFP cage, where the serdes link is configured
>   for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
>   is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
>   non-802.3 modification to 1000base-X) depending on the type of
>   transceiver plugged in.
> 
>   Arguably, there's a third option here, which is SATA as well -  I'm
>   aware of one non-standard SFP module on the market which provides a
>   SATA connector, but this is highly non-standard, is not covered by
>   the SFP specifications, so such a switch to this mode would have to
>   be done manually.
> 
> The difference between 1000base-X vs SGMII is to do with the generation
> and interpretation of a 16-bit configuration word passed across the
> link.  Otherwise, the two are identical - and so far I've seen the
> configuration word mode is determined by the ethernet block rather than
> the serdes block.
> 
> My argument would be that even in the case of the last paragraph,
> normal use for serdes reconfiguration would be a power cycle, even in
> the embedded environment.
> 
> Now, that all said, it looks to me like TI's serdes implementation can't
> be switched between different modes - it's statically configured to
> whatever the DTB says it should be.

Right, otherwise we would use a single compatible string and use the
settings as an argument.

> So, this brings up the obvious question: why do we need to support
> serdes configuration in the kernel rather than statically in the boot
> loader according to the board setup?
> 
> Specifically on this patch series, I think that if we're going to have
> code doing serdes configuration in the kernel, we need to come up with
> a common set of DT properties for it, rather than having everyone doing
> their own thing.  I'd also like to see the code shrink in size - it
> doesn't do anything beyond configuring the hardware for the settings
> that DTB tells it to, so why it has to be 2.5k lines I've no idea.

I can think of one more point that you have not mentioned: we may need
to want to include the PHY in the runtime power management. If the PHY
loses its state in low-power mode, we need to either read it out on
suspend to program it back, or regenerate the settings from DT.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254938

Hi,

On Friday 23 October 2015 08:16 PM, Russell King - ARM Linux wrote:
> On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:
>> On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
>>>>
>>>> phy-xgene.c
>>>> -----------
>>>>
>>>> Looking at other drivers under drivers/phy, I could find phy-xgene.c which
>>>> is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
>>>> PHY driver. It defines following mode per the driver code
>>>>
>>>>         MODE_SATA       = 0,    /* List them for simple reference */
>>>>         MODE_SGMII      = 1,
>>>>         MODE_PCIE       = 2,
>>>>         MODE_USB        = 3,
>>>>         MODE_XFI        = 4,
>>>>
>>>> But seems to support only MODE_SATA. From the code, it appears, this driver
>>>> is expected to be enhanced in the future to support additional modes. I have
>>>> copied the author to this email to participate in this discussion.
>>>
>>> Let me comment on this APM X-Gene driver. This driver is dead and
>>> won't be supported in near or foreseeable future. And someday, it will
>>> be ripped out. Based on experience, this solution (having PHY driver
>>> in Linux) can't be supported across boards and etc as it is just too
>>> much maintenance. And therefore, we followed Arnd B guidance and move
>>> all this into the boot loader. From Linux or OS perspective, it only
>>> cares about the interface in which its interface with. This is just
>>> your reference and may be this will help you as well.
>>
>> This depends a lot on the use case. If the chip is only used on server
>> parts that have a real firmware and you can deliver bug fixes for the
>> firmware if necessary, it's always best to do as much of the setup as
>> possible there, and let Linux see a simplified view of the hardware.
>>
>> However, for embedded systems that tend to ship with a minimal binary
>> bootloader and no way to update that as an end-user, we rely on Linux
>> to know about all the hardware that requires some form of setup, which
>> is why we have all sorts of drivers and frameworks in the kernel that
>> a server can easily ignore.
>>
>> While keystone can show up in servers that won't use this driver, my
>> impression is that its main market is actually in embedded space.
> 
> That's an interesting point of view - especially as you can't make the
> argument that Marvell Armada chips would ever be anything but the
> embedded space, but we're so far getting away with having the serdes
> setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.
> 
> The real question here is:
> 
>   Why would we want to statically setup serdes links in the kernel
>   according to the DTB, rather than having the boot loader set them up?

Lot of PHYs have HW configure the parameters with default values so the
driver really doesn't have to touch them (like programming the equalizer
and the various digital mode configuration and analog mode
configuration). Then the SW just has to take care of clock programming
and powering on/off the PHY.

Some platforms require the controller core be in reset before powering
on the PHY, so we can't have all the configurations done in bootloader
for all the platforms.

The problem w.r.t code size starts when the drivers starts to configure
the analog and digital components inside the PHY (like equalizer,
attenuation etc..).

While performing all these configurations in bootloader will help reduce
the code size, as Arnd pointed out, it'll cause problems if the PHY
loses the contents after a suspend/resume cycle.
> 
> For the most part, the choice between the serdes modes is fairly static,
> depending on the board wiring.  You wouldn't ever want to configure a
> mini-PCIe socket for gigabit ethernet.
> 
> However, there are cases when you would want to change it, and I'm
> aware of these cases:
> 
> * Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
>   There's an argument here to allow the serdes link to be switched at
>   runtime between PCIe and mSATA.  However, the card type can't be
>   detected at run time, so this would have to be a manual configuration
>   change by the user.
> 
>   Since mini-PCIe is not hot-pluggable, this configuration isn't
>   something that could be changed without powering the system down.
> 
> * Serdes routed to a SFP cage, where the serdes link is configured
>   for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
>   is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
>   non-802.3 modification to 1000base-X) depending on the type of
>   transceiver plugged in.
> 
>   Arguably, there's a third option here, which is SATA as well -  I'm
>   aware of one non-standard SFP module on the market which provides a
>   SATA connector, but this is highly non-standard, is not covered by
>   the SFP specifications, so such a switch to this mode would have to
>   be done manually.
> 
> The difference between 1000base-X vs SGMII is to do with the generation
> and interpretation of a 16-bit configuration word passed across the
> link.  Otherwise, the two are identical - and so far I've seen the
> configuration word mode is determined by the ethernet block rather than
> the serdes block.
> 
> My argument would be that even in the case of the last paragraph,
> normal use for serdes reconfiguration would be a power cycle, even in
> the embedded environment.
> 
> Now, that all said, it looks to me like TI's serdes implementation can't
> be switched between different modes - it's statically configured to
> whatever the DTB says it should be.
> 
> So, this brings up the obvious question: why do we need to support
> serdes configuration in the kernel rather than statically in the boot
> loader according to the board setup?
> 
> Specifically on this patch series, I think that if we're going to have
> code doing serdes configuration in the kernel, we need to come up with
> a common set of DT properties for it, rather than having everyone doing
> their own thing.  I'd also like to see the code shrink in size - it
> doesn't do anything beyond configuring the hardware for the settings
> that DTB tells it to, so why it has to be 2.5k lines I've no idea.
> 
> There's some specific comments I have about it using readl/writel, and
> its wrapping of those, which IMHO it shouldn't be doing, and the horrid
> for loops (what's wrong with the standard Linux way of defining a
> for_each_xxx() operator and leaving the body at the callsite?)

+1

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256323

Russell,

On 10/23/2015 02:52 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 23 October 2015 08:16 PM, Russell King - ARM Linux wrote:
>> On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:
>>> On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
>>>>>
>>>>> phy-xgene.c
>>>>> -----------
>>>>>
---CUT-------------------------------------------------------------------
>>>>
>>>> Let me comment on this APM X-Gene driver. This driver is dead and
>>>> won't be supported in near or foreseeable future. And someday, it will
>>>> be ripped out. Based on experience, this solution (having PHY driver
>>>> in Linux) can't be supported across boards and etc as it is just too
>>>> much maintenance. And therefore, we followed Arnd B guidance and move
>>>> all this into the boot loader. From Linux or OS perspective, it only
>>>> cares about the interface in which its interface with. This is just
>>>> your reference and may be this will help you as well.
>>>
>>> This depends a lot on the use case. If the chip is only used on server
>>> parts that have a real firmware and you can deliver bug fixes for the
>>> firmware if necessary, it's always best to do as much of the setup as
>>> possible there, and let Linux see a simplified view of the hardware.
>>>
>>> However, for embedded systems that tend to ship with a minimal binary
>>> bootloader and no way to update that as an end-user, we rely on Linux
>>> to know about all the hardware that requires some form of setup, which
>>> is why we have all sorts of drivers and frameworks in the kernel that
>>> a server can easily ignore.
>>>
>>> While keystone can show up in servers that won't use this driver, my
>>> impression is that its main market is actually in embedded space.
>>
>> That's an interesting point of view - especially as you can't make the
>> argument that Marvell Armada chips would ever be anything but the
>> embedded space, but we're so far getting away with having the serdes
>> setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.
>>
>> The real question here is:
>>
>>    Why would we want to statically setup serdes links in the kernel
>>    according to the DTB, rather than having the boot loader set them up?
>
> Lot of PHYs have HW configure the parameters with default values so the
> driver really doesn't have to touch them (like programming the equalizer
> and the various digital mode configuration and analog mode
> configuration). Then the SW just has to take care of clock programming
> and powering on/off the PHY.
>
> Some platforms require the controller core be in reset before powering
> on the PHY, so we can't have all the configurations done in bootloader
> for all the platforms.
>
> The problem w.r.t code size starts when the drivers starts to configure
> the analog and digital components inside the PHY (like equalizer,
> attenuation etc..).
>

Agree. There are also calibration required on the receive side for 10G 
and SRIO that adds to the code size. SRIO is currently not supported, 
but expected to be supported in the future. For 10G, and SRIO, it is 
expected that user may need to tune the coefficients on a per board 
basis and hence we can't afford to have the driver in the boot loader.

> While performing all these configurations in bootloader will help reduce
> the code size, as Arnd pointed out, it'll cause problems if the PHY
> loses the contents after a suspend/resume cycle.
>>

Agree.

>> For the most part, the choice between the serdes modes is fairly static,
>> depending on the board wiring.  You wouldn't ever want to configure a
>> mini-PCIe socket for gigabit ethernet.
>>
This is true for most of the serdes except 10G. 10G would require 
reconfiguration of the SerDes if it has to work in 1G mode. You wouldn't 
want to power cycle the board in case user wants to plug in a 1G link. 
We plan to add 10G support based on this serdes patch and also need to 
handle 1G mode on 10G as well in the future.

10G also has another mode to use a firmware that handles auto 
negotiation. User may use different firmware as well and has to be taken 
care of in the driver. How do we support this if this has to be in boot 
loader?

>> However, there are cases when you would want to change it, and I'm
>> aware of these cases:
>>
>> * Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
>>    There's an argument here to allow the serdes link to be switched at
>>    runtime between PCIe and mSATA.  However, the card type can't be
>>    detected at run time, so this would have to be a manual configuration
>>    change by the user.
>>
>>    Since mini-PCIe is not hot-pluggable, this configuration isn't
>>    something that could be changed without powering the system down.
>>
>> * Serdes routed to a SFP cage, where the serdes link is configured
>>    for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
>>    is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
>>    non-802.3 modification to 1000base-X) depending on the type of
>>    transceiver plugged in.
>>
>>    Arguably, there's a third option here, which is SATA as well -  I'm
>>    aware of one non-standard SFP module on the market which provides a
>>    SATA connector, but this is highly non-standard, is not covered by
>>    the SFP specifications, so such a switch to this mode would have to
>>    be done manually.
>>
>> The difference between 1000base-X vs SGMII is to do with the generation
>> and interpretation of a 16-bit configuration word passed across the
>> link.  Otherwise, the two are identical - and so far I've seen the
>> configuration word mode is determined by the ethernet block rather than
>> the serdes block.
>>
>> My argument would be that even in the case of the last paragraph,
>> normal use for serdes reconfiguration would be a power cycle, even in
>> the embedded environment.
>>
>> Now, that all said, it looks to me like TI's serdes implementation can't
>> be switched between different modes - it's statically configured to
>> whatever the DTB says it should be.
>>

For 10G and SRIO, there are coefficients (tx-coeff in DTS) that needs to 
be tuned on a per board basis. How would you do that if this has to be 
added to boot loader? Not scalable as boot loader has to be different 
for different boards

>> So, this brings up the obvious question: why do we need to support
>> serdes configuration in the kernel rather than statically in the boot
>> loader according to the board setup?
>>

The cases described above makes it clear we need a Linux driver for 
these SerDes.

>> Specifically on this patch series, I think that if we're going to have
>> code doing serdes configuration in the kernel, we need to come up with
>> a common set of DT properties for it, rather than having everyone doing
>> their own thing.

Not sure if there are standard configuration across various SERDES 
hardware provided by different vendors that we can identify. Some of the 
common are probably num-lanes, phy-mode etc. Do you know who can help us 
find these?

I'd also like to see the code shrink in size - it
>> doesn't do anything beyond configuring the hardware for the settings
>> that DTB tells it to, so why it has to be 2.5k lines I've no idea.
>>

Kishon has described the reason above.

>> There's some specific comments I have about it using readl/writel, and
>> its wrapping of those, which IMHO it shouldn't be doing,

Are you referring to below code?

+static inline u32 kserdes_readl(void __iomem *base, u32 offset)
+{
+	return readl(base + offset);
+}
+
+static inline void kserdes_writel(void __iomem *base, u32 offset, u32 
value)
+{
+	writel(value, base + offset);
+}

Any reason why you don't like these in the driver code?

  and the horrid
>> for loops (what's wrong with the standard Linux way of defining a
>> for_each_xxx() operator and leaving the body at the callsite?)
>

Will add for_each_xxx() in the next version.

Thanks

Murali & Wingman

> +1
>
> Thanks
> Kishon
>
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web