Groups > linux.kernel > #1247844 > unrolled thread

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

Started by	WingMan Kwok <w-kwok2@ti.com>
First post	2015-10-15 16:30 +0200
Last post	2015-10-16 16:20 +0200
Articles	17 — 7 participants

Back to article view | Back to linux.kernel

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

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

From	WingMan Kwok <w-kwok2@ti.com>
Date	2015-10-15 16:30 +0200
Subject	[PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms
Message-ID	<qjRHA-AM-13@gated-at.bofh.it>

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethether 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)

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 |  278 +++
 drivers/pci/host/pci-keystone.c                  |   54 +-
 drivers/pci/host/pci-keystone.h                  |    2 +
 drivers/phy/Kconfig                              |    8 +
 drivers/phy/Makefile                             |    1 +
 drivers/phy/phy-keystone-serdes.c                | 2373 ++++++++++++++++++++++
 6 files changed, 2707 insertions(+), 9 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]

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

From	WingMan Kwok <w-kwok2@ti.com>
Date	2015-10-15 16:30 +0200
Subject	[PATCH v1 2/2] PCI: keystone: update to use generic keystone serdes driver
Message-ID	<qjRHA-AM-25@gated-at.bofh.it>
In reply to	#1247844

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.

v1:
	- no change.

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

diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 0aa81bd..b4de05b 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,6 +343,8 @@ 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_node *serdeses_np, *child;
 	struct device *dev = &pdev->dev;
 	struct keystone_pcie *ks_pcie;
 	struct pcie_port *pp;
@@ -349,6 +352,7 @@ static int __init ks_pcie_probe(struct platform_device *pdev)
 	void __iomem *reg_p;
 	struct phy *phy;
 	int ret = 0;
+	u32 phy_num;
 
 	ks_pcie = devm_kzalloc(&pdev->dev, sizeof(*ks_pcie),
 				GFP_KERNEL);
@@ -357,14 +361,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 +381,46 @@ static int __init ks_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	serdeses_np = of_get_child_by_name(node, "serdeses");
+	if (serdeses_np) {
+		for_each_available_child_of_node(serdeses_np, child) {
+			ret = of_property_read_u32(child, "reg", &phy_num);
+			if (ret) {
+				dev_err(dev, "Failed to parse device tree\n");
+				of_node_put(child);
+				of_node_put(serdeses_np);
+				goto fail_clk;
+			}
+
+			if (phy_num >= MAX_NUM_PCI_SERDES) {
+				dev_err(dev, "Invalid phy number: %u\n",
+					phy_num);
+				of_node_put(child);
+				of_node_put(serdeses_np);
+				ret = -EINVAL;
+				goto fail_clk;
+			}
+
+			phy = devm_of_phy_get(dev, child, NULL);
+			of_node_put(child);
+			ks_pcie->serdes_phy = phy;
+			if (IS_ERR(phy)) {
+				dev_err(dev, "No %s serdes driver found: %ld\n",
+					node->name, PTR_ERR(phy));
+				of_node_put(serdeses_np);
+				ret = PTR_ERR(phy);
+				goto fail_clk;
+			}
+
+			ret = phy_init(phy);
+			if (ret < 0) {
+				of_node_put(serdeses_np);
+				goto fail_clk;
+			}
+		}
+		of_node_put(serdeses_np);
+	}
+
 	ret = ks_add_pcie_port(ks_pcie, pdev);
 	if (ret < 0)
 		goto fail_clk;
@@ -392,7 +428,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..21662ba 100644
--- a/drivers/pci/host/pci-keystone.h
+++ b/drivers/pci/host/pci-keystone.h
@@ -15,6 +15,7 @@
 #define MAX_LEGACY_IRQS			4
 #define MAX_MSI_HOST_IRQS		8
 #define MAX_LEGACY_HOST_IRQS		4
+#define MAX_NUM_PCI_SERDES		1
 
 struct keystone_pcie {
 	struct	clk		*clk;
@@ -33,6 +34,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]

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

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-10-15 17:00 +0200
Subject	Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjSaC-19v-9@gated-at.bofh.it>
In reply to	#1247844

On Thursday 15 October 2015 10:25:44 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 provides a SerDes phy driver implementation that can be
> used by the above mentioned peripheral drivers to configure their
> respective SerDeses.
> 
> v1:
> 	- see cover letter for review comments addressed.
> 
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
>  drivers/phy/Kconfig                              |    8 +
>  drivers/phy/Makefile                             |    1 +
>  drivers/phy/phy-keystone-serdes.c                | 2373 ++++++++++++++++++++++
>  4 files changed, 2660 insertions(+)
>  create mode 100644 drivers/phy/phy-keystone-serdes.c

This is quite a bit of code. Are you very sure that this PHY is
not used on any other SoC family, and that it is not licensed
from a third party? I would hate to see multiple copies of
this getting merged into the kernel over time, so thename should
be chosen carefully to let the next person know when they have
related hardware.

> +
> +gbe_serdes0: gbe_serdes@232a000 {


make that phy@232a000, the name should be one of the usual identifiers,
not specific to the instance.

> +config PHY_TI_KEYSTONE_SERDES
> +	tristate "TI Keystone SerDes PHY support"
> +	depends on OF && ARCH_KEYSTONE
> +	select GENERIC_PHY
> +	help
> +	  This option enables support for TI Keystone SerDes PHY found
> +	  in peripherals GBE, 10GBE and PCIe.
> +

(ARCH_KEYSTONE || COMPILE_TEST) ?

> + * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the
> + * distribution.

The current code does not do this when compiled, which might be a
problem for distributors. Can you clarify the license?

> +#define reg_rmw(addr, value, mask) \
> +	__raw_writel(((__raw_readl(addr) & (~(mask))) | \
> +			(value & (mask))), (addr))

not endian safe, and potentially racy.

> +static inline void _kserdes_reset_cdr(void __iomem *sregs, int lane)
> +{
> +	/* toggle signal detect */
> +	_kserdes_force_signal_detect_low(sregs, lane);
> +	mdelay(1);
> +	_kserdes_force_signal_detect_high(sregs, lane);
> +}

Can you change the code so you can use msleep(1) here?

> +
> +	do {
> +		mdelay(10);
> +		memset(lane_down, 0, sizeof(lane_down));
> +
> +		link_up = _kserdes_check_link_status(dev, sregs,
> +						     pcsr_regmap, lanes,
> +						     lanes_enable,
> +						     current_state, lane_down);
> +
> +		/* if we did not get link up then wait 100ms
> +		 * before calling it again
> +		 */
> +		if (link_up)
> +			break;
> +
> +		for (i = 0; i < lanes; i++) {
> +			if ((lanes_enable & (1 << i)) && lane_down[i])
> +				dev_dbg(dev,
> +					"XGE: detected lane down on lane %d\n",
> +					i);
> +		}
> +
> +		if (++retries > 100)
> +			return -ETIMEDOUT;
> +
> +	} while (!link_up);

an more importantly here. Blocking the CPU for over one second is not good.

Any use of mdelay() should have a comment explaining why you cannot use
msleep() in that instance.

> +
> +static int __init keystone_serdes_phy_init(void)
> +{
> +	return platform_driver_register(&kserdes_driver);
> +}
> +module_init(keystone_serdes_phy_init);
> +
> +static void __exit keystone_serdes_phy_exit(void)
> +{
> +	platform_driver_unregister(&kserdes_driver);
> +}
> +module_exit(keystone_serdes_phy_exit);

module_platform_driver()

	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]

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

From	Murali Karicheri <m-karicheri2@ti.com>
Date	2015-10-15 18:10 +0200
Subject	Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjTgm-2Z7-17@gated-at.bofh.it>
In reply to	#1247870

On 10/15/2015 10:51 AM, Arnd Bergmann wrote:
> On Thursday 15 October 2015 10:25:44 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 provides a SerDes phy driver implementation that can be
>> used by the above mentioned peripheral drivers to configure their
>> respective SerDeses.
>>
>> v1:

--------cut-------------------------------------------------------------

>> + * Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the
>> + * distribution.
>
> The current code does not do this when compiled, which might be a
> problem for distributors. Can you clarify the license?
>
Arnd,

Can you elaborate on this? I did a grep on the string "Redistributions 
in binary form must reproduce the above copyright" and I could find 
several instance of this. So I am not sure what you mean by "The current 
code does not do this when compiled".

Thanks
-- 
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]

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

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-10-15 21:40 +0200
Subject	Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjWxA-7L8-13@gated-at.bofh.it>
In reply to	#1247938

On Thursday 15 October 2015 12:01:04 Murali Karicheri wrote:
> 
> >> + * Redistributions in binary form must reproduce the above copyright
> >> + * notice, this list of conditions and the following disclaimer in the
> >> + * documentation and/or other materials provided with the
> >> + * distribution.
> >
> > The current code does not do this when compiled, which might be a
> > problem for distributors. Can you clarify the license?
> >
> Arnd,
> 
> Can you elaborate on this? I did a grep on the string "Redistributions 
> in binary form must reproduce the above copyright" and I could find 
> several instance of this. So I am not sure what you mean by "The current 
> code does not do this when compiled".

You write that the binary form of the code must produce the copyright
notice. I don't see any code that does this. If I was looking in the
wrong place, let me know.

	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]

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

From	"Kwok, WingMan" <w-kwok2@ti.com>
Date	2015-10-15 22:10 +0200
Subject	RE: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjX0C-8R-31@gated-at.bofh.it>
In reply to	#1247870

SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJuZCBCZXJnbWFu
biBbbWFpbHRvOmFybmRAYXJuZGIuZGVdDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAy
MDE1IDEwOjUxIEFNDQo+IFRvOiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcN
Cj4gQ2M6IEt3b2ssIFdpbmdNYW47IHJvYmgrZHRAa2VybmVsLm9yZzsgcGF3ZWwubW9sbEBhcm0u
Y29tOw0KPiBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsgaWpjK2RldmljZXRyZWVAaGVsbGlvbi5vcmcu
dWs7IGdhbGFrQGNvZGVhdXJvcmEub3JnOw0KPiBLSVNIT04gVklKQVkgQUJSQUhBTTsgUXVhZHJv
cywgUm9nZXI7IEthcmljaGVyaSwgTXVyYWxpZGhhcmFuOw0KPiBiaGVsZ2Fhc0Bnb29nbGUuY29t
OyBzc2FudG9zaEBrZXJuZWwub3JnOyBsaW51eEBhcm0ubGludXgub3JnLnVrOw0KPiBkZXZpY2V0
cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXgt
DQo+IHBjaUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MSAxLzJdIHBo
eToga2V5c3RvbmU6IHNlcmRlcyBkcml2ZXIgZm9yIGdiZSAxMGdiZSBhbmQNCj4gcGNpZQ0KPiAN
Cj4gT24gVGh1cnNkYXkgMTUgT2N0b2JlciAyMDE1IDEwOjI1OjQ0IFdpbmdNYW4gS3dvayB3cm90
ZToNCj4gPiBPbiBUSSdzIEtleXN0b25lIHBsYXRmb3Jtcywgc2V2ZXJhbCBwZXJpcGhlcmFscyBz
dWNoIGFzIHRoZQ0KPiA+IGdiZSBldGhlcm5ldCBzd2l0Y2gsIDEwZ2JlIGV0aGVybmV0IHN3aXRj
aCBhbmQgUENJZSBjb250cm9sbGVyDQo+ID4gcmVxdWlyZSB0aGUgdXNlIG9mIGEgU2VyRGVzIGZv
ciBjb252ZXJ0aW5nIFNvQyBwYXJhbGxlbCBkYXRhIGludG8NCj4gPiBzZXJpYWxpemVkIGRhdGEg
dGhhdCBjYW4gYmUgb3V0cHV0IG92ZXIgYSBoaWdoLXNwZWVkIGVsZWN0cmljYWwNCj4gPiBpbnRl
cmZhY2UsIGFuZCBhbHNvIGNvbnZlcnRpbmcgaGlnaC1zcGVlZCBzZXJpYWwgaW5wdXQgZGF0YQ0K
PiA+IGludG8gcGFyYWxsZWwgZGF0YSB0aGF0IGNhbiBiZSBwcm9jZXNzZWQgYnkgdGhlIFNvQy4g
IFRoZQ0KPiA+IFNlckRlc2VzIHVzZWQgYnkgdGhvc2UgcGVyaXBoZXJhbHMsIHRob3VnaCB0aGV5
IG1heSBiZSBkaWZmZXJlbnQsDQo+ID4gYXJlIGxhcmdlbHkgc2ltaWxhciBpbiBmdW5jdGlvbmFs
aXR5IGFuZCBzZXR1cC4NCj4gPg0KPiA+IFRoaXMgcGF0Y2ggcHJvdmlkZXMgYSBTZXJEZXMgcGh5
IGRyaXZlciBpbXBsZW1lbnRhdGlvbiB0aGF0IGNhbiBiZQ0KPiA+IHVzZWQgYnkgdGhlIGFib3Zl
IG1lbnRpb25lZCBwZXJpcGhlcmFsIGRyaXZlcnMgdG8gY29uZmlndXJlIHRoZWlyDQo+ID4gcmVz
cGVjdGl2ZSBTZXJEZXNlcy4NCj4gPg0KPiA+IHYxOg0KPiA+IAktIHNlZSBjb3ZlciBsZXR0ZXIg
Zm9yIHJldmlldyBjb21tZW50cyBhZGRyZXNzZWQuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBX
aW5nTWFuIEt3b2sgPHcta3dvazJAdGkuY29tPg0KPiA+IC0tLQ0KPiA+ICBEb2N1bWVudGF0aW9u
L2RldmljZXRyZWUvYmluZGluZ3MvcGh5L3RpLXBoeS50eHQgfCAgMjc4ICsrKw0KPiA+ICBkcml2
ZXJzL3BoeS9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA4ICsNCj4g
PiAgZHJpdmVycy9waHkvTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg
MSArDQo+ID4gIGRyaXZlcnMvcGh5L3BoeS1rZXlzdG9uZS1zZXJkZXMuYyAgICAgICAgICAgICAg
ICB8IDIzNzMNCj4gKysrKysrKysrKysrKysrKysrKysrKw0KPiA+ICA0IGZpbGVzIGNoYW5nZWQs
IDI2NjAgaW5zZXJ0aW9ucygrKQ0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy9waHkv
cGh5LWtleXN0b25lLXNlcmRlcy5jDQo+IA0KPiBUaGlzIGlzIHF1aXRlIGEgYml0IG9mIGNvZGUu
IEFyZSB5b3UgdmVyeSBzdXJlIHRoYXQgdGhpcyBQSFkgaXMNCj4gbm90IHVzZWQgb24gYW55IG90
aGVyIFNvQyBmYW1pbHksIGFuZCB0aGF0IGl0IGlzIG5vdCBsaWNlbnNlZA0KPiBmcm9tIGEgdGhp
cmQgcGFydHk/IEkgd291bGQgaGF0ZSB0byBzZWUgbXVsdGlwbGUgY29waWVzIG9mDQo+IHRoaXMg
Z2V0dGluZyBtZXJnZWQgaW50byB0aGUga2VybmVsIG92ZXIgdGltZSwgc28gdGhlbmFtZSBzaG91
bGQNCj4gYmUgY2hvc2VuIGNhcmVmdWxseSB0byBsZXQgdGhlIG5leHQgcGVyc29uIGtub3cgd2hl
biB0aGV5IGhhdmUNCj4gcmVsYXRlZCBoYXJkd2FyZS4NCj4gDQo+ID4gKw0KPiA+ICtnYmVfc2Vy
ZGVzMDogZ2JlX3NlcmRlc0AyMzJhMDAwIHsNCj4gDQo+IA0KPiBtYWtlIHRoYXQgcGh5QDIzMmEw
MDAsIHRoZSBuYW1lIHNob3VsZCBiZSBvbmUgb2YgdGhlIHVzdWFsIGlkZW50aWZpZXJzLA0KPiBu
b3Qgc3BlY2lmaWMgdG8gdGhlIGluc3RhbmNlLg0KPiANCg0Kd2lsbCBjaGFuZ2UgdG8gc29tZXRo
aW5nIGxpa2UgZ2JlX3NlcmRlczA6IHBoeUAyMzJhMDAwIHt9Ow0KDQo+ID4gK2NvbmZpZyBQSFlf
VElfS0VZU1RPTkVfU0VSREVTDQo+ID4gKwl0cmlzdGF0ZSAiVEkgS2V5c3RvbmUgU2VyRGVzIFBI
WSBzdXBwb3J0Ig0KPiA+ICsJZGVwZW5kcyBvbiBPRiAmJiBBUkNIX0tFWVNUT05FDQo+ID4gKwlz
ZWxlY3QgR0VORVJJQ19QSFkNCj4gPiArCWhlbHANCj4gPiArCSAgVGhpcyBvcHRpb24gZW5hYmxl
cyBzdXBwb3J0IGZvciBUSSBLZXlzdG9uZSBTZXJEZXMgUEhZIGZvdW5kDQo+ID4gKwkgIGluIHBl
cmlwaGVyYWxzIEdCRSwgMTBHQkUgYW5kIFBDSWUuDQo+ID4gKw0KPiANCj4gKEFSQ0hfS0VZU1RP
TkUgfHwgQ09NUElMRV9URVNUKSA/DQo+IA0KDQp3aWxsIGFkZCBDT01QSUxFX1RFU1QNCg0KPiA+
ICsgKiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFi
b3ZlIGNvcHlyaWdodA0KPiA+ICsgKiBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFu
ZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlDQo+ID4gKyAqIGRvY3VtZW50YXRpb24g
YW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQ0KPiA+ICsgKiBkaXN0cmli
dXRpb24uDQo+IA0KPiBUaGUgY3VycmVudCBjb2RlIGRvZXMgbm90IGRvIHRoaXMgd2hlbiBjb21w
aWxlZCwgd2hpY2ggbWlnaHQgYmUgYQ0KPiBwcm9ibGVtIGZvciBkaXN0cmlidXRvcnMuIENhbiB5
b3UgY2xhcmlmeSB0aGUgbGljZW5zZT8NCj4gDQoNCndpbGwgaW52ZXN0aWdhdGUNCg0KPiA+ICsj
ZGVmaW5lIHJlZ19ybXcoYWRkciwgdmFsdWUsIG1hc2spIFwNCj4gPiArCV9fcmF3X3dyaXRlbCgo
KF9fcmF3X3JlYWRsKGFkZHIpICYgKH4obWFzaykpKSB8IFwNCj4gPiArCQkJKHZhbHVlICYgKG1h
c2spKSksIChhZGRyKSkNCj4gDQo+IG5vdCBlbmRpYW4gc2FmZSwgYW5kIHBvdGVudGlhbGx5IHJh
Y3kuDQo+IA0KDQp3aWxsIGNoYW5nZSB0byANCg0KI2RlZmluZSByZWdfcm13KGFkZHIsIHZhbHVl
LCBtYXNrKSBcDQoJd3JpdGVsKCgocmVhZGwoYWRkcikgJiAofihtYXNrKSkpIHwgXA0KCQkJKHZh
bHVlICYgKG1hc2spKSksIChhZGRyKSkNCg0KPiA+ICtzdGF0aWMgaW5saW5lIHZvaWQgX2tzZXJk
ZXNfcmVzZXRfY2RyKHZvaWQgX19pb21lbSAqc3JlZ3MsIGludCBsYW5lKQ0KPiA+ICt7DQo+ID4g
KwkvKiB0b2dnbGUgc2lnbmFsIGRldGVjdCAqLw0KPiA+ICsJX2tzZXJkZXNfZm9yY2Vfc2lnbmFs
X2RldGVjdF9sb3coc3JlZ3MsIGxhbmUpOw0KPiA+ICsJbWRlbGF5KDEpOw0KPiA+ICsJX2tzZXJk
ZXNfZm9yY2Vfc2lnbmFsX2RldGVjdF9oaWdoKHNyZWdzLCBsYW5lKTsNCj4gPiArfQ0KPiANCj4g
Q2FuIHlvdSBjaGFuZ2UgdGhlIGNvZGUgc28geW91IGNhbiB1c2UgbXNsZWVwKDEpIGhlcmU/DQo+
IA0KDQp3aWxsIHJlcGxhY2UgZGVsYXlzIHdpdGggdXNsZWVwX3JhbmdlKCkNCg0KPiA+ICsNCj4g
PiArCWRvIHsNCj4gPiArCQltZGVsYXkoMTApOw0KPiA+ICsJCW1lbXNldChsYW5lX2Rvd24sIDAs
IHNpemVvZihsYW5lX2Rvd24pKTsNCj4gPiArDQo+ID4gKwkJbGlua191cCA9IF9rc2VyZGVzX2No
ZWNrX2xpbmtfc3RhdHVzKGRldiwgc3JlZ3MsDQo+ID4gKwkJCQkJCSAgICAgcGNzcl9yZWdtYXAs
IGxhbmVzLA0KPiA+ICsJCQkJCQkgICAgIGxhbmVzX2VuYWJsZSwNCj4gPiArCQkJCQkJICAgICBj
dXJyZW50X3N0YXRlLCBsYW5lX2Rvd24pOw0KPiA+ICsNCj4gPiArCQkvKiBpZiB3ZSBkaWQgbm90
IGdldCBsaW5rIHVwIHRoZW4gd2FpdCAxMDBtcw0KPiA+ICsJCSAqIGJlZm9yZSBjYWxsaW5nIGl0
IGFnYWluDQo+ID4gKwkJICovDQo+ID4gKwkJaWYgKGxpbmtfdXApDQo+ID4gKwkJCWJyZWFrOw0K
PiA+ICsNCj4gPiArCQlmb3IgKGkgPSAwOyBpIDwgbGFuZXM7IGkrKykgew0KPiA+ICsJCQlpZiAo
KGxhbmVzX2VuYWJsZSAmICgxIDw8IGkpKSAmJiBsYW5lX2Rvd25baV0pDQo+ID4gKwkJCQlkZXZf
ZGJnKGRldiwNCj4gPiArCQkJCQkiWEdFOiBkZXRlY3RlZCBsYW5lIGRvd24gb24gbGFuZSAlZFxu
IiwNCj4gPiArCQkJCQlpKTsNCj4gPiArCQl9DQo+ID4gKw0KPiA+ICsJCWlmICgrK3JldHJpZXMg
PiAxMDApDQo+ID4gKwkJCXJldHVybiAtRVRJTUVET1VUOw0KPiA+ICsNCj4gPiArCX0gd2hpbGUg
KCFsaW5rX3VwKTsNCj4gDQo+IGFuIG1vcmUgaW1wb3J0YW50bHkgaGVyZS4gQmxvY2tpbmcgdGhl
IENQVSBmb3Igb3ZlciBvbmUgc2Vjb25kIGlzIG5vdCBnb29kLg0KPiANCj4gQW55IHVzZSBvZiBt
ZGVsYXkoKSBzaG91bGQgaGF2ZSBhIGNvbW1lbnQgZXhwbGFpbmluZyB3aHkgeW91IGNhbm5vdCB1
c2UNCj4gbXNsZWVwKCkgaW4gdGhhdCBpbnN0YW5jZS4NCj4gDQoNCndpbGwgcmVwbGFjZSBkZWxh
eXMgd2l0aCB1c2xlZXBfcmFuZ2UoKQ0KDQo+ID4gKw0KPiA+ICtzdGF0aWMgaW50IF9faW5pdCBr
ZXlzdG9uZV9zZXJkZXNfcGh5X2luaXQodm9pZCkNCj4gPiArew0KPiA+ICsJcmV0dXJuIHBsYXRm
b3JtX2RyaXZlcl9yZWdpc3Rlcigma3NlcmRlc19kcml2ZXIpOw0KPiA+ICt9DQo+ID4gK21vZHVs
ZV9pbml0KGtleXN0b25lX3NlcmRlc19waHlfaW5pdCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9p
ZCBfX2V4aXQga2V5c3RvbmVfc2VyZGVzX3BoeV9leGl0KHZvaWQpDQo+ID4gK3sNCj4gPiArCXBs
YXRmb3JtX2RyaXZlcl91bnJlZ2lzdGVyKCZrc2VyZGVzX2RyaXZlcik7DQo+ID4gK30NCj4gPiAr
bW9kdWxlX2V4aXQoa2V5c3RvbmVfc2VyZGVzX3BoeV9leGl0KTsNCj4gDQo+IG1vZHVsZV9wbGF0
Zm9ybV9kcml2ZXIoKQ0KPiAJDQoNCndpbGwgZG8uDQoNCj4gCUFybmQNCg0KVGhhbmtzLA0KV2lu
Z01hbg0K
--
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]

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

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-10-15 23:00 +0200
Subject	Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjXN1-1dR-37@gated-at.bofh.it>
In reply to	#1248131

On Thursday 15 October 2015 20:08:32 Kwok, WingMan wrote:
> 
> > > +#define reg_rmw(addr, value, mask) \
> > > +   __raw_writel(((__raw_readl(addr) & (~(mask))) | \
> > > +                   (value & (mask))), (addr))
> > 
> > not endian safe, and potentially racy.
> > 
> 
> will change to 
> 
> #define reg_rmw(addr, value, mask) \
>         writel(((readl(addr) & (~(mask))) | \
>                         (value & (mask))), (addr))

Ok, sounds good. Note that if any of this is performance critical,
better use readl_relaxed(), but as long as this is just for setup
code and not for data transfers, staying with readl() as you
suggest is better.

> > > +static inline void _kserdes_reset_cdr(void __iomem *sregs, int lane)
> > > +{
> > > +   /* toggle signal detect */
> > > +   _kserdes_force_signal_detect_low(sregs, lane);
> > > +   mdelay(1);
> > > +   _kserdes_force_signal_detect_high(sregs, lane);
> > > +}
> > 
> > Can you change the code so you can use msleep(1) here?
> > 
> 
> will replace delays with usleep_range()

Ok.

> > > +
> > > +   do {
> > > +           mdelay(10);
> > > +           memset(lane_down, 0, sizeof(lane_down));
> > > +
> > > +           link_up = _kserdes_check_link_status(dev, sregs,
> > > +                                                pcsr_regmap, lanes,
> > > +                                                lanes_enable,
> > > +                                                current_state, lane_down);
> > > +
> > > +           /* if we did not get link up then wait 100ms
> > > +            * before calling it again
> > > +            */
> > > +           if (link_up)
> > > +                   break;
> > > +
> > > +           for (i = 0; i < lanes; i++) {
> > > +                   if ((lanes_enable & (1 << i)) && lane_down[i])
> > > +                           dev_dbg(dev,
> > > +                                   "XGE: detected lane down on lane %d\n",
> > > +                                   i);
> > > +           }
> > > +
> > > +           if (++retries > 100)
> > > +                   return -ETIMEDOUT;
> > > +
> > > +   } while (!link_up);
> > 
> > an more importantly here. Blocking the CPU for over one second is not good.
> > 
> > Any use of mdelay() should have a comment explaining why you cannot use
> > msleep() in that instance.
> > 
> 
> will replace delays with usleep_range()

Here you have to be careful with the total runtime. Using usleep_range()
is a good idea, and you can have a particularly wide range, but then you
should changen the timeout condition from number of retries to total
elapsed time like

	unsigned long timeout = jiffies + HZ; /* 1 second maximum */
	do {
		...

		if (link_up)
			break;

		if (time_after(jiffies, timeout)
			return -ETIMEOUT;

		usleep_range(1000, 50000);
	} while (1);

	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]

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

From	"Kwok, WingMan" <w-kwok2@ti.com>
Date	2015-10-16 02:00 +0200
Subject	RE: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qk0Bb-5wE-1@gated-at.bofh.it>
In reply to	#1248175

SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJuZCBCZXJn
bWFubiBbbWFpbHRvOmFybmRAYXJuZGIuZGVdDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1
LCAyMDE1IDQ6NTMgUE0NCj4gVG86IEt3b2ssIFdpbmdNYW4NCj4gQ2M6IGxpbnV4LWFybS1rZXJu
ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOw0KPiBwYXdlbC5tb2xs
QGFybS5jb207IG1hcmsucnV0bGFuZEBhcm0uY29tOyBpamMrZGV2aWNldHJlZUBoZWxsaW9uLm9y
Zy51azsNCj4gZ2FsYWtAY29kZWF1cm9yYS5vcmc7IEtJU0hPTiBWSUpBWSBBQlJBSEFNOyBRdWFk
cm9zLCBSb2dlcjsgS2FyaWNoZXJpLA0KPiBNdXJhbGlkaGFyYW47IGJoZWxnYWFzQGdvb2dsZS5j
b207IHNzYW50b3NoQGtlcm5lbC5vcmc7DQo+IGxpbnV4QGFybS5saW51eC5vcmcudWs7IGRldmlj
ZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsg
bGludXgtcGNpQHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYxIDEvMl0g
cGh5OiBrZXlzdG9uZTogc2VyZGVzIGRyaXZlciBmb3IgZ2JlIDEwZ2JlIGFuZA0KPiBwY2llDQo+
IA0KPiBPbiBUaHVyc2RheSAxNSBPY3RvYmVyIDIwMTUgMjA6MDg6MzIgS3dvaywgV2luZ01hbiB3
cm90ZToNCj4gPg0KPiA+ID4gPiArI2RlZmluZSByZWdfcm13KGFkZHIsIHZhbHVlLCBtYXNrKSBc
DQo+ID4gPiA+ICsgICBfX3Jhd193cml0ZWwoKChfX3Jhd19yZWFkbChhZGRyKSAmICh+KG1hc2sp
KSkgfCBcDQo+ID4gPiA+ICsgICAgICAgICAgICAgICAgICAgKHZhbHVlICYgKG1hc2spKSksIChh
ZGRyKSkNCj4gPiA+DQo+ID4gPiBub3QgZW5kaWFuIHNhZmUsIGFuZCBwb3RlbnRpYWxseSByYWN5
Lg0KPiA+ID4NCj4gPg0KPiA+IHdpbGwgY2hhbmdlIHRvDQo+ID4NCj4gPiAjZGVmaW5lIHJlZ19y
bXcoYWRkciwgdmFsdWUsIG1hc2spIFwNCj4gPiAgICAgICAgIHdyaXRlbCgoKHJlYWRsKGFkZHIp
ICYgKH4obWFzaykpKSB8IFwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAodmFsdWUgJiAo
bWFzaykpKSwgKGFkZHIpKQ0KPiANCj4gT2ssIHNvdW5kcyBnb29kLiBOb3RlIHRoYXQgaWYgYW55
IG9mIHRoaXMgaXMgcGVyZm9ybWFuY2UgY3JpdGljYWwsDQo+IGJldHRlciB1c2UgcmVhZGxfcmVs
YXhlZCgpLCBidXQgYXMgbG9uZyBhcyB0aGlzIGlzIGp1c3QgZm9yIHNldHVwDQo+IGNvZGUgYW5k
IG5vdCBmb3IgZGF0YSB0cmFuc2ZlcnMsIHN0YXlpbmcgd2l0aCByZWFkbCgpIGFzIHlvdQ0KPiBz
dWdnZXN0IGlzIGJldHRlci4NCj4gDQoNCnNpbmNlIHRoaXMgaXMgb25seSBmb3IgaW5pdGlhbGl6
YXRpb24sIEknbGwgcHJvYmFibHkgc3RheSB3aXRoIHJlYWRsKCkuDQoNCj4gPiA+ID4gK3N0YXRp
YyBpbmxpbmUgdm9pZCBfa3NlcmRlc19yZXNldF9jZHIodm9pZCBfX2lvbWVtICpzcmVncywgaW50
IGxhbmUpDQo+ID4gPiA+ICt7DQo+ID4gPiA+ICsgICAvKiB0b2dnbGUgc2lnbmFsIGRldGVjdCAq
Lw0KPiA+ID4gPiArICAgX2tzZXJkZXNfZm9yY2Vfc2lnbmFsX2RldGVjdF9sb3coc3JlZ3MsIGxh
bmUpOw0KPiA+ID4gPiArICAgbWRlbGF5KDEpOw0KPiA+ID4gPiArICAgX2tzZXJkZXNfZm9yY2Vf
c2lnbmFsX2RldGVjdF9oaWdoKHNyZWdzLCBsYW5lKTsNCj4gPiA+ID4gK30NCj4gPiA+DQo+ID4g
PiBDYW4geW91IGNoYW5nZSB0aGUgY29kZSBzbyB5b3UgY2FuIHVzZSBtc2xlZXAoMSkgaGVyZT8N
Cj4gPiA+DQo+ID4NCj4gPiB3aWxsIHJlcGxhY2UgZGVsYXlzIHdpdGggdXNsZWVwX3JhbmdlKCkN
Cj4gDQo+IE9rLg0KPiANCj4gPiA+ID4gKw0KPiA+ID4gPiArICAgZG8gew0KPiA+ID4gPiArICAg
ICAgICAgICBtZGVsYXkoMTApOw0KPiA+ID4gPiArICAgICAgICAgICBtZW1zZXQobGFuZV9kb3du
LCAwLCBzaXplb2YobGFuZV9kb3duKSk7DQo+ID4gPiA+ICsNCj4gPiA+ID4gKyAgICAgICAgICAg
bGlua191cCA9IF9rc2VyZGVzX2NoZWNrX2xpbmtfc3RhdHVzKGRldiwgc3JlZ3MsDQo+ID4gPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwY3NyX3Jl
Z21hcCwgbGFuZXMsDQo+ID4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsYW5lc19lbmFibGUsDQo+ID4gPiA+ICsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50X3N0YXRlLA0KPiBsYW5lX2Rvd24p
Ow0KPiA+ID4gPiArDQo+ID4gPiA+ICsgICAgICAgICAgIC8qIGlmIHdlIGRpZCBub3QgZ2V0IGxp
bmsgdXAgdGhlbiB3YWl0IDEwMG1zDQo+ID4gPiA+ICsgICAgICAgICAgICAqIGJlZm9yZSBjYWxs
aW5nIGl0IGFnYWluDQo+ID4gPiA+ICsgICAgICAgICAgICAqLw0KPiA+ID4gPiArICAgICAgICAg
ICBpZiAobGlua191cCkNCj4gPiA+ID4gKyAgICAgICAgICAgICAgICAgICBicmVhazsNCj4gPiA+
ID4gKw0KPiA+ID4gPiArICAgICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbGFuZXM7IGkrKykgew0K
PiA+ID4gPiArICAgICAgICAgICAgICAgICAgIGlmICgobGFuZXNfZW5hYmxlICYgKDEgPDwgaSkp
ICYmIGxhbmVfZG93bltpXSkNCj4gPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIGRl
dl9kYmcoZGV2LA0KPiA+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
WEdFOiBkZXRlY3RlZCBsYW5lIGRvd24gb24gbGFuZQ0KPiAlZFxuIiwNCj4gPiA+ID4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaSk7DQo+ID4gPiA+ICsgICAgICAgICAgIH0N
Cj4gPiA+ID4gKw0KPiA+ID4gPiArICAgICAgICAgICBpZiAoKytyZXRyaWVzID4gMTAwKQ0KPiA+
ID4gPiArICAgICAgICAgICAgICAgICAgIHJldHVybiAtRVRJTUVET1VUOw0KPiA+ID4gPiArDQo+
ID4gPiA+ICsgICB9IHdoaWxlICghbGlua191cCk7DQo+ID4gPg0KPiA+ID4gYW4gbW9yZSBpbXBv
cnRhbnRseSBoZXJlLiBCbG9ja2luZyB0aGUgQ1BVIGZvciBvdmVyIG9uZSBzZWNvbmQgaXMgbm90
DQo+IGdvb2QuDQo+ID4gPg0KPiA+ID4gQW55IHVzZSBvZiBtZGVsYXkoKSBzaG91bGQgaGF2ZSBh
IGNvbW1lbnQgZXhwbGFpbmluZyB3aHkgeW91IGNhbm5vdCB1c2UNCj4gPiA+IG1zbGVlcCgpIGlu
IHRoYXQgaW5zdGFuY2UuDQo+ID4gPg0KPiA+DQo+ID4gd2lsbCByZXBsYWNlIGRlbGF5cyB3aXRo
IHVzbGVlcF9yYW5nZSgpDQo+IA0KPiBIZXJlIHlvdSBoYXZlIHRvIGJlIGNhcmVmdWwgd2l0aCB0
aGUgdG90YWwgcnVudGltZS4gVXNpbmcgdXNsZWVwX3JhbmdlKCkNCj4gaXMgYSBnb29kIGlkZWEs
IGFuZCB5b3UgY2FuIGhhdmUgYSBwYXJ0aWN1bGFybHkgd2lkZSByYW5nZSwgYnV0IHRoZW4geW91
DQo+IHNob3VsZCBjaGFuZ2VuIHRoZSB0aW1lb3V0IGNvbmRpdGlvbiBmcm9tIG51bWJlciBvZiBy
ZXRyaWVzIHRvIHRvdGFsDQo+IGVsYXBzZWQgdGltZSBsaWtlDQo+IA0KPiAJdW5zaWduZWQgbG9u
ZyB0aW1lb3V0ID0gamlmZmllcyArIEhaOyAvKiAxIHNlY29uZCBtYXhpbXVtICovDQo+IAlkbyB7
DQo+IAkJLi4uDQo+IA0KPiAJCWlmIChsaW5rX3VwKQ0KPiAJCQlicmVhazsNCj4gDQo+IAkJaWYg
KHRpbWVfYWZ0ZXIoamlmZmllcywgdGltZW91dCkNCj4gCQkJcmV0dXJuIC1FVElNRU9VVDsNCj4g
DQo+IAkJdXNsZWVwX3JhbmdlKDEwMDAsIDUwMDAwKTsNCj4gCX0gd2hpbGUgKDEpOw0KPiANCg0K
d2lsbCBkby4gIA0KDQo+IAlBcm5kDQoNClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIGNvbW1lbnRz
Lg0KV2luZ01hbg0K
--
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]

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

From	Rob Herring <robh+dt@kernel.org>
Date	2015-10-15 18:20 +0200
Subject	Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qjTq2-3aG-23@gated-at.bofh.it>
In reply to	#1247844

On Thu, Oct 15, 2015 at 9:25 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.
>
> v1:
>         - see cover letter for review comments addressed.
>
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |  278 +++
>  drivers/phy/Kconfig                              |    8 +
>  drivers/phy/Makefile                             |    1 +
>  drivers/phy/phy-keystone-serdes.c                | 2373 ++++++++++++++++++++++
>  4 files changed, 2660 insertions(+)
>  create mode 100644 drivers/phy/phy-keystone-serdes.c
>
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 9cf9446..4dca271 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -115,4 +115,282 @@ sata_phy: phy@4A096000 {
>         clock-names = "sysclk", "refclk";
>         syscon-pllreset = <&scm_conf 0x3fc>;
>         #phy-cells = <0>;
> +
> +TI Keystone SerDes PHY
> +======================
> +
> +Required properties:
> + - compatible: should be one of
> +       * "ti,keystone-serdes-gbe"
> +       * "ti,keystone-serdes-xgbe"
> +       * "ti,keystone-serdes-pcie"

These are different blocks or different modes of the same block? It's
fine if the former. If the latter, then you should have a single
compatible and then have a mode property. Perhaps phy-connection-type
from ePAPR ethernet binding can be extended.


> + - reg:
> +       * base address and length of the SerDes register set
> + - reg-names:
> +       * "serdes"
> +               - name of the reg SerDes register set

reg-names is kind of pointless with only 1.

> + - #phy-cells:
> +       * From the generic phy bindings, must be 0;
> + - num-lanes:
> +       * Number of lanes in SerDes.
> +
> +Optional properties:
> + - syscon-peripheral:
> +       * Handle to the subsystem register region of the peripheral
> +         inside which the SerDes exists.
> + - syscon-link:
> +       * Handle to the Link register region of the peripheral inside
> +         which the SerDes exists.  Example: it is the PCSR register
> +         region in the case of 10gbe.
> + - rx-force-enable:
> +       * Include this property if receiver attenuation and boost are
> +         to be configured with specific values defined in rx-force.
> + - link-rate-kbps:
> +       * SerDes link rate to be configured, in kbps.
> +
> +
> +For gbe and 10gbe SerDes, it is optional to represent each lane as
> +a sub-node, which can be enabled or disabled individually using
> +the "status" property.
> +
> +Required properties (lane sub-node):
> + - reg:
> +       * lane number
> +
> +Optional properties (lane sub-node):
> + - control-rate:
> +       * Lane control rate
> +               0: full rate
> +               1: half rate
> +               2: quarter rate
> + - rx-start:
> +       * Initial lane rx equalizer attenuation and boost configurations.
> +       * Must be array of 2 integers.
> + - rx-force:
> +       * Forced lane rx equalizer attenuation and boost configurations.
> +       * Must be array of 2 integers.
> + - tx-coeff:
> +       * Lane c1, c2, cm, attenuation and regulator output voltage
> +         configurations.
> +       * Must be array of 5 integers.
> + - loopback:
> +       * Include this property to enable loopback at the SerDes
> +         lane level.

This seems overly complicated. Do you really expect these to be
different per lane?

> +
> +Example for Keystone K2E GBE:
> +-----------------------------
> +
> +gbe_serdes0: gbe_serdes@232a000 {
> +       #phy-cells              = <0>;
> +       compatible              = "ti,keystone-serdes-gbe";
> +       reg                     = <0x0232a000 0x2000>;
> +       reg-names               = "serdes";
> +       link-rate-kbps          = <1250000>;
> +       num-lanes               = <4>;
> +       lanes {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               lane@0 {
> +                       /*loopback;*/
> +                       reg             = <0>;
> +                       control-rate    = <2>; /* quart */
> +                       rx-start        = <7 5>;
> +                       rx-force        = <1 1>;
> +                       tx-coeff        = <0 0 0 12 4>;
> +                              /* c1 c2 cm att vreg */
> +               };
> +               lane@1 {
> +                       /*loopback;*/
> +                       reg             = <1>;
> +                       control-rate    = <2>; /* quart */
> +                       rx-start        = <7 5>;
> +                       rx-force        = <1 1>;
> +                       tx-coeff        = <0 0 0 12 4>;
> +                              /* c1 c2 cm att vreg */
> +               };
> +       };
> +};
> +
> +gbe_serdes1: gbe_serdes@2324000 {
> +       #phy-cells              = <0>;
> +       compatible              = "ti,keystone-serdes-gbe";
> +       reg                     = <0x02324000 0x2000>;
> +       reg-names               = "serdes";
> +       link-rate-kbps          = <1250000>;
> +       num-lanes               = <4>;

4 lanes, but only 2 child nodes?

> +       lanes {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               lane@0 {
> +                       /*loopback;*/
> +                       reg             = <0>;
> +                       control-rate    = <2>; /* quart */
> +                       rx-start        = <7 5>;
> +                       rx-force        = <1 1>;
> +                       tx-coeff        = <0 0 0 12 4>;
> +                              /* c1 c2 cm att vreg */
> +               };
> +               lane@1 {
> +                       /*loopback;*/
> +                       reg             = <1>;
> +                       control-rate    = <2>; /* quart */
> +                       rx-start        = <7 5>;
> +                       rx-force        = <1 1>;
> +                       tx-coeff        = <0 0 0 12 4>;
> +                              /* c1 c2 cm att vreg */
> +               };
> +       };
> +};
> +
> +netcp: netcp@24000000 {
> +       ...
> +
> +       netcp-devices {
> +               ...
> +
> +               gbe@200000 { /* ETHSS */
> +                       ...
> +                       serdeses {
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +                               serdes@0 {
> +                                       reg = <0>;
> +                                       phys = <&gbe_serdes0>;
> +                                       status = "ok";
> +                               };
> +                               serdes@1 {
> +                                       reg = <1>;
> +                                       phys = <&gbe_serdes1>;
> +                                       status = "ok";

This is way too complex. Just do:

phys = <&gbe_serdes0, &gbe_serdes1>;

in the gbe node.

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]

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

From	"Kwok, WingMan" <w-kwok2@ti.com>
Date	2015-10-16 02:00 +0200
Subject	RE: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Message-ID	<qk0Bc-5wE-3@gated-at.bofh.it>
In reply to	#1247951

SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iIEhlcnJp
bmcgW21haWx0bzpyb2JoK2R0QGtlcm5lbC5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy
IDE1LCAyMDE1IDEyOjE1IFBNDQo+IFRvOiBLd29rLCBXaW5nTWFuDQo+IENjOiBQYXdlbCBNb2xs
OyBNYXJrIFJ1dGxhbmQ7IElhbiBDYW1wYmVsbDsgS3VtYXIgR2FsYTsgS0lTSE9OIFZJSkFZIEFC
UkFIQU07DQo+IFF1YWRyb3MsIFJvZ2VyOyBLYXJpY2hlcmksIE11cmFsaWRoYXJhbjsgQmpvcm4g
SGVsZ2FhczsgU2FudG9zaCBTaGlsaW1rYXI7DQo+IFJ1c3NlbGwgS2luZyAtIEFSTSBMaW51eDsg
ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtlcm5lbEBsaXN0
cy5pbmZyYWRlYWQub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjEgMS8yXSBwaHk6IGtleXN0
b25lOiBzZXJkZXMgZHJpdmVyIGZvciBnYmUgMTBnYmUgYW5kDQo+IHBjaWUNCj4gDQo+IE9uIFRo
dSwgT2N0IDE1LCAyMDE1IGF0IDk6MjUgQU0sIFdpbmdNYW4gS3dvayA8dy1rd29rMkB0aS5jb20+
IHdyb3RlOg0KPiA+IE9uIFRJJ3MgS2V5c3RvbmUgcGxhdGZvcm1zLCBzZXZlcmFsIHBlcmlwaGVy
YWxzIHN1Y2ggYXMgdGhlDQo+ID4gZ2JlIGV0aGVybmV0IHN3aXRjaCwgMTBnYmUgZXRoZXJuZXQg
c3dpdGNoIGFuZCBQQ0llIGNvbnRyb2xsZXINCj4gPiByZXF1aXJlIHRoZSB1c2Ugb2YgYSBTZXJE
ZXMgZm9yIGNvbnZlcnRpbmcgU29DIHBhcmFsbGVsIGRhdGEgaW50bw0KPiA+IHNlcmlhbGl6ZWQg
ZGF0YSB0aGF0IGNhbiBiZSBvdXRwdXQgb3ZlciBhIGhpZ2gtc3BlZWQgZWxlY3RyaWNhbA0KPiA+
IGludGVyZmFjZSwgYW5kIGFsc28gY29udmVydGluZyBoaWdoLXNwZWVkIHNlcmlhbCBpbnB1dCBk
YXRhDQo+ID4gaW50byBwYXJhbGxlbCBkYXRhIHRoYXQgY2FuIGJlIHByb2Nlc3NlZCBieSB0aGUg
U29DLiAgVGhlDQo+ID4gU2VyRGVzZXMgdXNlZCBieSB0aG9zZSBwZXJpcGhlcmFscywgdGhvdWdo
IHRoZXkgbWF5IGJlIGRpZmZlcmVudCwNCj4gPiBhcmUgbGFyZ2VseSBzaW1pbGFyIGluIGZ1bmN0
aW9uYWxpdHkgYW5kIHNldHVwLg0KPiA+DQo+ID4gVGhpcyBwYXRjaCBwcm92aWRlcyBhIFNlckRl
cyBwaHkgZHJpdmVyIGltcGxlbWVudGF0aW9uIHRoYXQgY2FuIGJlDQo+ID4gdXNlZCBieSB0aGUg
YWJvdmUgbWVudGlvbmVkIHBlcmlwaGVyYWwgZHJpdmVycyB0byBjb25maWd1cmUgdGhlaXINCj4g
PiByZXNwZWN0aXZlIFNlckRlc2VzLg0KPiA+DQo+ID4gdjE6DQo+ID4gICAgICAgICAtIHNlZSBj
b3ZlciBsZXR0ZXIgZm9yIHJldmlldyBjb21tZW50cyBhZGRyZXNzZWQuDQo+ID4NCj4gPiBTaWdu
ZWQtb2ZmLWJ5OiBXaW5nTWFuIEt3b2sgPHcta3dvazJAdGkuY29tPg0KPiA+IC0tLQ0KPiA+ICBE
b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcGh5L3RpLXBoeS50eHQgfCAgMjc4ICsr
Kw0KPiA+ICBkcml2ZXJzL3BoeS9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fCAgICA4ICsNCj4gPiAgZHJpdmVycy9waHkvTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgMSArDQo+ID4gIGRyaXZlcnMvcGh5L3BoeS1rZXlzdG9uZS1zZXJkZXMuYyAg
ICAgICAgICAgICAgICB8IDIzNzMNCj4gKysrKysrKysrKysrKysrKysrKysrKw0KPiA+ICA0IGZp
bGVzIGNoYW5nZWQsIDI2NjAgaW5zZXJ0aW9ucygrKQ0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQg
ZHJpdmVycy9waHkvcGh5LWtleXN0b25lLXNlcmRlcy5jDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEv
RG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3BoeS90aS1waHkudHh0DQo+IGIvRG9j
dW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3BoeS90aS1waHkudHh0DQo+ID4gaW5kZXgg
OWNmOTQ0Ni4uNGRjYTI3MSAxMDA2NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRy
ZWUvYmluZGluZ3MvcGh5L3RpLXBoeS50eHQNCj4gPiArKysgYi9Eb2N1bWVudGF0aW9uL2Rldmlj
ZXRyZWUvYmluZGluZ3MvcGh5L3RpLXBoeS50eHQNCj4gPiBAQCAtMTE1LDQgKzExNSwyODIgQEAg
c2F0YV9waHk6IHBoeUA0QTA5NjAwMCB7DQo+ID4gICAgICAgICBjbG9jay1uYW1lcyA9ICJzeXNj
bGsiLCAicmVmY2xrIjsNCj4gPiAgICAgICAgIHN5c2Nvbi1wbGxyZXNldCA9IDwmc2NtX2NvbmYg
MHgzZmM+Ow0KPiA+ICAgICAgICAgI3BoeS1jZWxscyA9IDwwPjsNCj4gPiArDQo+ID4gK1RJIEtl
eXN0b25lIFNlckRlcyBQSFkNCj4gPiArPT09PT09PT09PT09PT09PT09PT09PQ0KPiA+ICsNCj4g
PiArUmVxdWlyZWQgcHJvcGVydGllczoNCj4gPiArIC0gY29tcGF0aWJsZTogc2hvdWxkIGJlIG9u
ZSBvZg0KPiA+ICsgICAgICAgKiAidGksa2V5c3RvbmUtc2VyZGVzLWdiZSINCj4gPiArICAgICAg
ICogInRpLGtleXN0b25lLXNlcmRlcy14Z2JlIg0KPiA+ICsgICAgICAgKiAidGksa2V5c3RvbmUt
c2VyZGVzLXBjaWUiDQo+IA0KPiBUaGVzZSBhcmUgZGlmZmVyZW50IGJsb2NrcyBvciBkaWZmZXJl
bnQgbW9kZXMgb2YgdGhlIHNhbWUgYmxvY2s/IEl0J3MNCj4gZmluZSBpZiB0aGUgZm9ybWVyLiBJ
ZiB0aGUgbGF0dGVyLCB0aGVuIHlvdSBzaG91bGQgaGF2ZSBhIHNpbmdsZQ0KPiBjb21wYXRpYmxl
IGFuZCB0aGVuIGhhdmUgYSBtb2RlIHByb3BlcnR5LiBQZXJoYXBzIHBoeS1jb25uZWN0aW9uLXR5
cGUNCj4gZnJvbSBlUEFQUiBldGhlcm5ldCBiaW5kaW5nIGNhbiBiZSBleHRlbmRlZC4NCj4gDQoN
CnRoZXNlIGFyZSBkaWZmZXJlbnQgaHcgYmxvY2tzIGNvbmZpZ3VyZWQgc3BlY2lmaWNhbGx5DQpm
b3IgdGhlIGNvcnJlc3BvbmRpbmcgcGVyaXBoZXJhbC4NCg0KPiANCj4gPiArIC0gcmVnOg0KPiA+
ICsgICAgICAgKiBiYXNlIGFkZHJlc3MgYW5kIGxlbmd0aCBvZiB0aGUgU2VyRGVzIHJlZ2lzdGVy
IHNldA0KPiA+ICsgLSByZWctbmFtZXM6DQo+ID4gKyAgICAgICAqICJzZXJkZXMiDQo+ID4gKyAg
ICAgICAgICAgICAgIC0gbmFtZSBvZiB0aGUgcmVnIFNlckRlcyByZWdpc3RlciBzZXQNCj4gDQo+
IHJlZy1uYW1lcyBpcyBraW5kIG9mIHBvaW50bGVzcyB3aXRoIG9ubHkgMS4NCj4gDQoNCndpbGwg
cmVtb3ZlLg0KDQo+ID4gKyAtICNwaHktY2VsbHM6DQo+ID4gKyAgICAgICAqIEZyb20gdGhlIGdl
bmVyaWMgcGh5IGJpbmRpbmdzLCBtdXN0IGJlIDA7DQo+ID4gKyAtIG51bS1sYW5lczoNCj4gPiAr
ICAgICAgICogTnVtYmVyIG9mIGxhbmVzIGluIFNlckRlcy4NCj4gPiArDQo+ID4gK09wdGlvbmFs
IHByb3BlcnRpZXM6DQo+ID4gKyAtIHN5c2Nvbi1wZXJpcGhlcmFsOg0KPiA+ICsgICAgICAgKiBI
YW5kbGUgdG8gdGhlIHN1YnN5c3RlbSByZWdpc3RlciByZWdpb24gb2YgdGhlIHBlcmlwaGVyYWwN
Cj4gPiArICAgICAgICAgaW5zaWRlIHdoaWNoIHRoZSBTZXJEZXMgZXhpc3RzLg0KPiA+ICsgLSBz
eXNjb24tbGluazoNCj4gPiArICAgICAgICogSGFuZGxlIHRvIHRoZSBMaW5rIHJlZ2lzdGVyIHJl
Z2lvbiBvZiB0aGUgcGVyaXBoZXJhbCBpbnNpZGUNCj4gPiArICAgICAgICAgd2hpY2ggdGhlIFNl
ckRlcyBleGlzdHMuICBFeGFtcGxlOiBpdCBpcyB0aGUgUENTUiByZWdpc3Rlcg0KPiA+ICsgICAg
ICAgICByZWdpb24gaW4gdGhlIGNhc2Ugb2YgMTBnYmUuDQo+ID4gKyAtIHJ4LWZvcmNlLWVuYWJs
ZToNCj4gPiArICAgICAgICogSW5jbHVkZSB0aGlzIHByb3BlcnR5IGlmIHJlY2VpdmVyIGF0dGVu
dWF0aW9uIGFuZCBib29zdCBhcmUNCj4gPiArICAgICAgICAgdG8gYmUgY29uZmlndXJlZCB3aXRo
IHNwZWNpZmljIHZhbHVlcyBkZWZpbmVkIGluIHJ4LWZvcmNlLg0KPiA+ICsgLSBsaW5rLXJhdGUt
a2JwczoNCj4gPiArICAgICAgICogU2VyRGVzIGxpbmsgcmF0ZSB0byBiZSBjb25maWd1cmVkLCBp
biBrYnBzLg0KPiA+ICsNCj4gPiArDQo+ID4gK0ZvciBnYmUgYW5kIDEwZ2JlIFNlckRlcywgaXQg
aXMgb3B0aW9uYWwgdG8gcmVwcmVzZW50IGVhY2ggbGFuZSBhcw0KPiA+ICthIHN1Yi1ub2RlLCB3
aGljaCBjYW4gYmUgZW5hYmxlZCBvciBkaXNhYmxlZCBpbmRpdmlkdWFsbHkgdXNpbmcNCj4gPiAr
dGhlICJzdGF0dXMiIHByb3BlcnR5Lg0KPiA+ICsNCj4gPiArUmVxdWlyZWQgcHJvcGVydGllcyAo
bGFuZSBzdWItbm9kZSk6DQo+ID4gKyAtIHJlZzoNCj4gPiArICAgICAgICogbGFuZSBudW1iZXIN
Cj4gPiArDQo+ID4gK09wdGlvbmFsIHByb3BlcnRpZXMgKGxhbmUgc3ViLW5vZGUpOg0KPiA+ICsg
LSBjb250cm9sLXJhdGU6DQo+ID4gKyAgICAgICAqIExhbmUgY29udHJvbCByYXRlDQo+ID4gKyAg
ICAgICAgICAgICAgIDA6IGZ1bGwgcmF0ZQ0KPiA+ICsgICAgICAgICAgICAgICAxOiBoYWxmIHJh
dGUNCj4gPiArICAgICAgICAgICAgICAgMjogcXVhcnRlciByYXRlDQo+ID4gKyAtIHJ4LXN0YXJ0
Og0KPiA+ICsgICAgICAgKiBJbml0aWFsIGxhbmUgcnggZXF1YWxpemVyIGF0dGVudWF0aW9uIGFu
ZCBib29zdCBjb25maWd1cmF0aW9ucy4NCj4gPiArICAgICAgICogTXVzdCBiZSBhcnJheSBvZiAy
IGludGVnZXJzLg0KPiA+ICsgLSByeC1mb3JjZToNCj4gPiArICAgICAgICogRm9yY2VkIGxhbmUg
cnggZXF1YWxpemVyIGF0dGVudWF0aW9uIGFuZCBib29zdCBjb25maWd1cmF0aW9ucy4NCj4gPiAr
ICAgICAgICogTXVzdCBiZSBhcnJheSBvZiAyIGludGVnZXJzLg0KPiA+ICsgLSB0eC1jb2VmZjoN
Cj4gPiArICAgICAgICogTGFuZSBjMSwgYzIsIGNtLCBhdHRlbnVhdGlvbiBhbmQgcmVndWxhdG9y
IG91dHB1dCB2b2x0YWdlDQo+ID4gKyAgICAgICAgIGNvbmZpZ3VyYXRpb25zLg0KPiA+ICsgICAg
ICAgKiBNdXN0IGJlIGFycmF5IG9mIDUgaW50ZWdlcnMuDQo+ID4gKyAtIGxvb3BiYWNrOg0KPiA+
ICsgICAgICAgKiBJbmNsdWRlIHRoaXMgcHJvcGVydHkgdG8gZW5hYmxlIGxvb3BiYWNrIGF0IHRo
ZSBTZXJEZXMNCj4gPiArICAgICAgICAgbGFuZSBsZXZlbC4NCj4gDQo+IFRoaXMgc2VlbXMgb3Zl
cmx5IGNvbXBsaWNhdGVkLiBEbyB5b3UgcmVhbGx5IGV4cGVjdCB0aGVzZSB0byBiZQ0KPiBkaWZm
ZXJlbnQgcGVyIGxhbmU/DQo+IA0KDQpJdCBpcyBhbiByZXF1aXJlbWVudCB0aGF0IGVhY2ggbGFu
ZSBjYW4gYmUgZW5hYmxlZC9kaXNhYmxlZA0KYW5kIGNvbmZpZ3VyZWQgaW5kaXZpZHVhbGx5LiAg
QWxzbyBpdCBpcyBwb3RlbnRpYWxseSBwb3NzaWJsZQ0KdGhhdCBzb21lIG9mIHRoZW0gYXJlIGRp
ZmZlcmVudCBkdWUgdG8gY2FsaWJyYXRpb24gcmVzdWx0cy4NCg0KPiA+ICsNCj4gPiArRXhhbXBs
ZSBmb3IgS2V5c3RvbmUgSzJFIEdCRToNCj4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCj4gPiArDQo+ID4gK2diZV9zZXJkZXMwOiBnYmVfc2VyZGVzQDIzMmEwMDAgew0KPiA+ICsg
ICAgICAgI3BoeS1jZWxscyAgICAgICAgICAgICAgPSA8MD47DQo+ID4gKyAgICAgICBjb21wYXRp
YmxlICAgICAgICAgICAgICA9ICJ0aSxrZXlzdG9uZS1zZXJkZXMtZ2JlIjsNCj4gPiArICAgICAg
IHJlZyAgICAgICAgICAgICAgICAgICAgID0gPDB4MDIzMmEwMDAgMHgyMDAwPjsNCj4gPiArICAg
ICAgIHJlZy1uYW1lcyAgICAgICAgICAgICAgID0gInNlcmRlcyI7DQo+ID4gKyAgICAgICBsaW5r
LXJhdGUta2JwcyAgICAgICAgICA9IDwxMjUwMDAwPjsNCj4gPiArICAgICAgIG51bS1sYW5lcyAg
ICAgICAgICAgICAgID0gPDQ+Ow0KPiA+ICsgICAgICAgbGFuZXMgew0KPiA+ICsgICAgICAgICAg
ICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiArICAgICAgICAgICAgICAgI3NpemUtY2Vs
bHMgPSA8MD47DQo+ID4gKyAgICAgICAgICAgICAgIGxhbmVAMCB7DQo+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgLypsb29wYmFjazsqLw0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJl
ZyAgICAgICAgICAgICA9IDwwPjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBjb250cm9s
LXJhdGUgICAgPSA8Mj47IC8qIHF1YXJ0ICovDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg
cngtc3RhcnQgICAgICAgID0gPDcgNT47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgcngt
Zm9yY2UgICAgICAgID0gPDEgMT47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgdHgtY29l
ZmYgICAgICAgID0gPDAgMCAwIDEyIDQ+Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAvKiBjMSBjMiBjbSBhdHQgdnJlZyAqLw0KPiA+ICsgICAgICAgICAgICAgICB9Ow0KPiA+
ICsgICAgICAgICAgICAgICBsYW5lQDEgew0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIC8q
bG9vcGJhY2s7Ki8NCj4gPiArICAgICAgICAgICAgICAgICAgICAgICByZWcgICAgICAgICAgICAg
PSA8MT47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgY29udHJvbC1yYXRlICAgID0gPDI+
OyAvKiBxdWFydCAqLw0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJ4LXN0YXJ0ICAgICAg
ICA9IDw3IDU+Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJ4LWZvcmNlICAgICAgICA9
IDwxIDE+Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHR4LWNvZWZmICAgICAgICA9IDww
IDAgMCAxMiA0PjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogYzEgYzIg
Y20gYXR0IHZyZWcgKi8NCj4gPiArICAgICAgICAgICAgICAgfTsNCj4gPiArICAgICAgIH07DQo+
ID4gK307DQo+ID4gKw0KPiA+ICtnYmVfc2VyZGVzMTogZ2JlX3NlcmRlc0AyMzI0MDAwIHsNCj4g
PiArICAgICAgICNwaHktY2VsbHMgICAgICAgICAgICAgID0gPDA+Ow0KPiA+ICsgICAgICAgY29t
cGF0aWJsZSAgICAgICAgICAgICAgPSAidGksa2V5c3RvbmUtc2VyZGVzLWdiZSI7DQo+ID4gKyAg
ICAgICByZWcgICAgICAgICAgICAgICAgICAgICA9IDwweDAyMzI0MDAwIDB4MjAwMD47DQo+ID4g
KyAgICAgICByZWctbmFtZXMgICAgICAgICAgICAgICA9ICJzZXJkZXMiOw0KPiA+ICsgICAgICAg
bGluay1yYXRlLWticHMgICAgICAgICAgPSA8MTI1MDAwMD47DQo+ID4gKyAgICAgICBudW0tbGFu
ZXMgICAgICAgICAgICAgICA9IDw0PjsNCj4gDQo+IDQgbGFuZXMsIGJ1dCBvbmx5IDIgY2hpbGQg
bm9kZXM/DQo+IA0KDQpzaW5jZSBlYWNoIGxhbmUgY2FuIGJlIGVuYWJsZWQvZGlzYWJsZWQgaW5k
aXZpZHVhbGx5LCBhIGRpc2FibGVkDQpsYW5lIGNhbiBoYXZlIGEgbm9kZSBkZWZpbmVkIGJ1dCB3
aXRoIGEgc3RhdHVzID0gImRpc2FibGVkIiBvcg0KZG9lcyBub3QgaGF2ZSBhIGxhbmUgbm9kZSBk
ZWZpbmVkIGF0IGFsbC4gIHRoaXMgZXhhbXBsZSBzaG93cyB0aGUNCmxhdHRlci4NCg0KPiA+ICsg
ICAgICAgbGFuZXMgew0KPiA+ICsgICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsN
Cj4gPiArICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gKyAgICAgICAgICAg
ICAgIGxhbmVAMCB7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgLypsb29wYmFjazsqLw0K
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJlZyAgICAgICAgICAgICA9IDwwPjsNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICBjb250cm9sLXJhdGUgICAgPSA8Mj47IC8qIHF1YXJ0ICov
DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgcngtc3RhcnQgICAgICAgID0gPDcgNT47DQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgICAgcngtZm9yY2UgICAgICAgID0gPDEgMT47DQo+ID4g
KyAgICAgICAgICAgICAgICAgICAgICAgdHgtY29lZmYgICAgICAgID0gPDAgMCAwIDEyIDQ+Ow0K
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBjMSBjMiBjbSBhdHQgdnJlZyAq
Lw0KPiA+ICsgICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAgICAgICAgICBsYW5lQDEgew0K
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgIC8qbG9vcGJhY2s7Ki8NCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICByZWcgICAgICAgICAgICAgPSA8MT47DQo+ID4gKyAgICAgICAgICAgICAg
ICAgICAgICAgY29udHJvbC1yYXRlICAgID0gPDI+OyAvKiBxdWFydCAqLw0KPiA+ICsgICAgICAg
ICAgICAgICAgICAgICAgIHJ4LXN0YXJ0ICAgICAgICA9IDw3IDU+Ow0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgIHJ4LWZvcmNlICAgICAgICA9IDwxIDE+Ow0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgIHR4LWNvZWZmICAgICAgICA9IDwwIDAgMCAxMiA0PjsNCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLyogYzEgYzIgY20gYXR0IHZyZWcgKi8NCj4gPiArICAgICAg
ICAgICAgICAgfTsNCj4gPiArICAgICAgIH07DQo+ID4gK307DQo+ID4gKw0KPiA+ICtuZXRjcDog
bmV0Y3BAMjQwMDAwMDAgew0KPiA+ICsgICAgICAgLi4uDQo+ID4gKw0KPiA+ICsgICAgICAgbmV0
Y3AtZGV2aWNlcyB7DQo+ID4gKyAgICAgICAgICAgICAgIC4uLg0KPiA+ICsNCj4gPiArICAgICAg
ICAgICAgICAgZ2JlQDIwMDAwMCB7IC8qIEVUSFNTICovDQo+ID4gKyAgICAgICAgICAgICAgICAg
ICAgICAgLi4uDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgc2VyZGVzZXMgew0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47DQo+ID4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwwPjsNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcmRlc0AwIHsNCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDA+Ow0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwaHlzID0gPCZnYmVfc2VyZGVzMD47DQo+ID4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXR1cyA9ICJvayI7DQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2VyZGVzQDEgew0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICByZWcgPSA8MT47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHBoeXMgPSA8JmdiZV9zZXJkZXMxPjsNCj4gPiArICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhdHVzID0gIm9rIjsNCj4gDQo+IFRoaXMgaXMg
d2F5IHRvbyBjb21wbGV4LiBKdXN0IGRvOg0KPiANCj4gcGh5cyA9IDwmZ2JlX3NlcmRlczAsICZn
YmVfc2VyZGVzMT47DQo+IA0KPiBpbiB0aGUgZ2JlIG5vZGUuDQo+IA0KDQpnb29kIHBvaW50LiB3
aWxsIGNoYW5nZSB0byBwaHlzID0gPCZnYmVfc2VyZGVzMD4sIDwmZ2JlX3NlcmRlczE+Ow0KDQo+
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]

#1248003

From	Russell King - ARM Linux <linux@arm.linux.org.uk>
Date	2015-10-15 19:00 +0200
Message-ID	<qjU2K-3Ul-9@gated-at.bofh.it>
In reply to	#1247844

On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
> On TI's Keystone platforms, several peripherals such as the
> gbe ethernet switch, 10gbe ethether 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.

Given that serdes is not specific to TI, should this be specific to
TI, or should there be an effort to come up with something which
everyone who has serdes links can make use of?

Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
plethora of SoC specific stuff for this.

When serdes is combined with SFP cages, the situation becomes much
more fun, because the serdes link then needs to become hotpluggable
(SFP modules are designed to be hotplugged) which means you have to
be able to switch between (at least) 1G SGMII and 1000base-X modes,
and probably 10G mode as well.  There's even a SFP module that has
a SATA connector on it, though I believe there's no standard for
that, and it's more a hardware hack.

I've been working in this area but from the Ethernet side on an
Armada 38x based board which has a SFP cage on it, though it's
slightly simpler there because there is no support (or I believe
any desire) to reconfigure the serdes lanes between PCI, ethernet
and SATA - that's all setup and initialised for us by uboot.

-- 
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]

#1248098

From	Kishon Vijay Abraham I <kishon@ti.com>
Date	2015-10-15 21:30 +0200
Message-ID	<qjWnT-7zG-7@gated-at.bofh.it>
In reply to	#1248003

Hi,

On Thursday 15 October 2015 10:21 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
>> On TI's Keystone platforms, several peripherals such as the
>> gbe ethernet switch, 10gbe ethether 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.
> 
> Given that serdes is not specific to TI, should this be specific to
> TI, or should there be an effort to come up with something which
> everyone who has serdes links can make use of?
> 
> Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
> 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
> plethora of SoC specific stuff for this.

Generally every SoC use it's own serdes and the programming required is
different for different SoCs. Each of them have their own register map
and clock programming/regulator programming/reset programming are all
different.

However most SoC vendors use the same PHY/SerDes IP to be used by
multiple controllers like PCIe/SATA/USB in a single SoC and a single PHY
driver is used for programming all these PHYs.

Thanks
Kishon

> 
> When serdes is combined with SFP cages, the situation becomes much
> more fun, because the serdes link then needs to become hotpluggable
> (SFP modules are designed to be hotplugged) which means you have to
> be able to switch between (at least) 1G SGMII and 1000base-X modes,
> and probably 10G mode as well.  There's even a SFP module that has
> a SATA connector on it, though I believe there's no standard for
> that, and it's more a hardware hack.
> 
> I've been working in this area but from the Ethernet side on an
> Armada 38x based board which has a SFP cage on it, though it's
> slightly simpler there because there is no support (or I believe
> any desire) to reconfigure the serdes lanes between PCI, ethernet
> and SATA - that's all setup and initialised for us by uboot.
> 
--
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]

#1248264

From	"Kwok, WingMan" <w-kwok2@ti.com>
Date	2015-10-16 02:10 +0200
Message-ID	<qk0KS-5Z0-5@gated-at.bofh.it>
In reply to	#1248098

SGVsbG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS0lTSE9OIFZJ
SkFZIEFCUkFIQU0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMTUgMzoyMiBQTQ0K
PiBUbzogUnVzc2VsbCBLaW5nIC0gQVJNIExpbnV4OyBLd29rLCBXaW5nTWFuDQo+IENjOiByb2Jo
K2R0QGtlcm5lbC5vcmc7IHBhd2VsLm1vbGxAYXJtLmNvbTsgbWFyay5ydXRsYW5kQGFybS5jb207
DQo+IGlqYytkZXZpY2V0cmVlQGhlbGxpb24ub3JnLnVrOyBnYWxha0Bjb2RlYXVyb3JhLm9yZzsg
UXVhZHJvcywgUm9nZXI7DQo+IEthcmljaGVyaSwgTXVyYWxpZGhhcmFuOyBiaGVsZ2Fhc0Bnb29n
bGUuY29tOyBzc2FudG9zaEBrZXJuZWwub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9y
ZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXgtDQo+IHBjaUB2Z2VyLmtlcm5l
bC5vcmc7IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIHYxIDAvMl0gQ29tbW9uIFNlckRlcyBkcml2ZXIgZm9yIFRJJ3MgS2V5c3RvbmUg
UGxhdGZvcm1zDQo+IA0KPiBIaSwNCj4gDQo+IE9uIFRodXJzZGF5IDE1IE9jdG9iZXIgMjAxNSAx
MDoyMSBQTSwgUnVzc2VsbCBLaW5nIC0gQVJNIExpbnV4IHdyb3RlOg0KPiA+IE9uIFRodSwgT2N0
IDE1LCAyMDE1IGF0IDEwOjI1OjQzQU0gLTA0MDAsIFdpbmdNYW4gS3dvayB3cm90ZToNCj4gPj4g
T24gVEkncyBLZXlzdG9uZSBwbGF0Zm9ybXMsIHNldmVyYWwgcGVyaXBoZXJhbHMgc3VjaCBhcyB0
aGUNCj4gPj4gZ2JlIGV0aGVybmV0IHN3aXRjaCwgMTBnYmUgZXRoZXRoZXIgc3dpdGNoIGFuZCBQ
Q0llIGNvbnRyb2xsZXINCj4gPj4gcmVxdWlyZSB0aGUgdXNlIG9mIGEgU2VyRGVzIGZvciBjb252
ZXJ0aW5nIFNvQyBwYXJhbGxlbCBkYXRhIGludG8NCj4gPj4gc2VyaWFsaXplZCBkYXRhIHRoYXQg
Y2FuIGJlIG91dHB1dCBvdmVyIGEgaGlnaC1zcGVlZCBlbGVjdHJpY2FsDQo+ID4+IGludGVyZmFj
ZSwgYW5kIGFsc28gY29udmVydGluZyBoaWdoLXNwZWVkIHNlcmlhbCBpbnB1dCBkYXRhDQo+ID4+
IGludG8gcGFyYWxsZWwgZGF0YSB0aGF0IGNhbiBiZSBwcm9jZXNzZWQgYnkgdGhlIFNvQy4gIFRo
ZQ0KPiA+PiBTZXJEZXNlcyB1c2VkIGJ5IHRob3NlIHBlcmlwaGVyYWxzLCB0aG91Z2ggdGhleSBt
YXkgYmUgZGlmZmVyZW50LA0KPiA+PiBhcmUgbGFyZ2VseSBzaW1pbGFyIGluIGZ1bmN0aW9uYWxp
dHkgYW5kIHNldHVwLg0KPiA+DQo+ID4gR2l2ZW4gdGhhdCBzZXJkZXMgaXMgbm90IHNwZWNpZmlj
IHRvIFRJLCBzaG91bGQgdGhpcyBiZSBzcGVjaWZpYyB0bw0KPiA+IFRJLCBvciBzaG91bGQgdGhl
cmUgYmUgYW4gZWZmb3J0IHRvIGNvbWUgdXAgd2l0aCBzb21ldGhpbmcgd2hpY2gNCj4gPiBldmVy
eW9uZSB3aG8gaGFzIHNlcmRlcyBsaW5rcyBjYW4gbWFrZSB1c2Ugb2Y/DQo+ID4NCj4gPiBTZXJk
ZXMgY29tZXMgaW4gbXVsdGlwbGUgZGlmZmVyZW50IGZvcm1zOiBQQ0llLCAxRyBTR01JSSBldGhl
cm5ldCwNCj4gPiAxMDAwYmFzZS1YIGV0aGVybmV0LCAxMGcgZXRoZXJuZXQsIFNBVEEuLi4gSSdk
IGhhdGUgdG8gc2VlIGENCj4gPiBwbGV0aG9yYSBvZiBTb0Mgc3BlY2lmaWMgc3R1ZmYgZm9yIHRo
aXMuDQo+IA0KPiBHZW5lcmFsbHkgZXZlcnkgU29DIHVzZSBpdCdzIG93biBzZXJkZXMgYW5kIHRo
ZSBwcm9ncmFtbWluZyByZXF1aXJlZCBpcw0KPiBkaWZmZXJlbnQgZm9yIGRpZmZlcmVudCBTb0Nz
LiBFYWNoIG9mIHRoZW0gaGF2ZSB0aGVpciBvd24gcmVnaXN0ZXIgbWFwDQo+IGFuZCBjbG9jayBw
cm9ncmFtbWluZy9yZWd1bGF0b3IgcHJvZ3JhbW1pbmcvcmVzZXQgcHJvZ3JhbW1pbmcgYXJlIGFs
bA0KPiBkaWZmZXJlbnQuDQo+IA0KPiBIb3dldmVyIG1vc3QgU29DIHZlbmRvcnMgdXNlIHRoZSBz
YW1lIFBIWS9TZXJEZXMgSVAgdG8gYmUgdXNlZCBieQ0KPiBtdWx0aXBsZSBjb250cm9sbGVycyBs
aWtlIFBDSWUvU0FUQS9VU0IgaW4gYSBzaW5nbGUgU29DIGFuZCBhIHNpbmdsZSBQSFkNCj4gZHJp
dmVyIGlzIHVzZWQgZm9yIHByb2dyYW1taW5nIGFsbCB0aGVzZSBQSFlzLg0KPiANCg0KVGhhbmtz
IHNvIG11Y2ggZm9yIHRoZSBjbGFyaWZpY2F0aW9ucy4NCg0KPiBUaGFua3MNCj4gS2lzaG9uDQo+
IA0KDQpSZWdhcmRzLA0KV2luZ01hbg0KDQo+ID4NCj4gPiBXaGVuIHNlcmRlcyBpcyBjb21iaW5l
ZCB3aXRoIFNGUCBjYWdlcywgdGhlIHNpdHVhdGlvbiBiZWNvbWVzIG11Y2gNCj4gPiBtb3JlIGZ1
biwgYmVjYXVzZSB0aGUgc2VyZGVzIGxpbmsgdGhlbiBuZWVkcyB0byBiZWNvbWUgaG90cGx1Z2dh
YmxlDQo+ID4gKFNGUCBtb2R1bGVzIGFyZSBkZXNpZ25lZCB0byBiZSBob3RwbHVnZ2VkKSB3aGlj
aCBtZWFucyB5b3UgaGF2ZSB0bw0KPiA+IGJlIGFibGUgdG8gc3dpdGNoIGJldHdlZW4gKGF0IGxl
YXN0KSAxRyBTR01JSSBhbmQgMTAwMGJhc2UtWCBtb2RlcywNCj4gPiBhbmQgcHJvYmFibHkgMTBH
IG1vZGUgYXMgd2VsbC4gIFRoZXJlJ3MgZXZlbiBhIFNGUCBtb2R1bGUgdGhhdCBoYXMNCj4gPiBh
IFNBVEEgY29ubmVjdG9yIG9uIGl0LCB0aG91Z2ggSSBiZWxpZXZlIHRoZXJlJ3Mgbm8gc3RhbmRh
cmQgZm9yDQo+ID4gdGhhdCwgYW5kIGl0J3MgbW9yZSBhIGhhcmR3YXJlIGhhY2suDQo+ID4NCj4g
PiBJJ3ZlIGJlZW4gd29ya2luZyBpbiB0aGlzIGFyZWEgYnV0IGZyb20gdGhlIEV0aGVybmV0IHNp
ZGUgb24gYW4NCj4gPiBBcm1hZGEgMzh4IGJhc2VkIGJvYXJkIHdoaWNoIGhhcyBhIFNGUCBjYWdl
IG9uIGl0LCB0aG91Z2ggaXQncw0KPiA+IHNsaWdodGx5IHNpbXBsZXIgdGhlcmUgYmVjYXVzZSB0
aGVyZSBpcyBubyBzdXBwb3J0IChvciBJIGJlbGlldmUNCj4gPiBhbnkgZGVzaXJlKSB0byByZWNv
bmZpZ3VyZSB0aGUgc2VyZGVzIGxhbmVzIGJldHdlZW4gUENJLCBldGhlcm5ldA0KPiA+IGFuZCBT
QVRBIC0gdGhhdCdzIGFsbCBzZXR1cCBhbmQgaW5pdGlhbGlzZWQgZm9yIHVzIGJ5IHVib290Lg0K
PiA+DQo=
--
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]

#1248283

From	Rob Herring <robh+dt@kernel.org>
Date	2015-10-16 03:10 +0200
Message-ID	<qk1GW-7np-5@gated-at.bofh.it>
In reply to	#1248003

On Thu, Oct 15, 2015 at 11:51 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
>> On TI's Keystone platforms, several peripherals such as the
>> gbe ethernet switch, 10gbe ethether 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.
>
> Given that serdes is not specific to TI, should this be specific to
> TI, or should there be an effort to come up with something which
> everyone who has serdes links can make use of?
>
> Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
> 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
> plethora of SoC specific stuff for this.

The licensed IP I've seen doesn't provide a standard register
interface, but just signals to the IP block. Same with PLL IP. So
we'll probably get to see vendors continue to differentiate on PHY
register design. :)

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]

#1248445

From	Russell King - ARM Linux <linux@arm.linux.org.uk>
Date	2015-10-16 10:10 +0200
Message-ID	<qk8fn-hv-7@gated-at.bofh.it>
In reply to	#1248283

On Thu, Oct 15, 2015 at 08:00:41PM -0500, Rob Herring wrote:
> On Thu, Oct 15, 2015 at 11:51 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
> >> On TI's Keystone platforms, several peripherals such as the
> >> gbe ethernet switch, 10gbe ethether 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.
> >
> > Given that serdes is not specific to TI, should this be specific to
> > TI, or should there be an effort to come up with something which
> > everyone who has serdes links can make use of?
> >
> > Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
> > 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
> > plethora of SoC specific stuff for this.
> 
> The licensed IP I've seen doesn't provide a standard register
> interface, but just signals to the IP block. Same with PLL IP. So
> we'll probably get to see vendors continue to differentiate on PHY
> register design. :)

So what?  Network drivers differ radically in register design, yet we
still have a standardised interface to network drivers.

-- 
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]

#1248794

From	Murali Karicheri <m-karicheri2@ti.com>
Date	2015-10-16 16:20 +0200
Message-ID	<qke1r-jy-3@gated-at.bofh.it>
In reply to	#1248445

On 10/16/2015 04:02 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 15, 2015 at 08:00:41PM -0500, Rob Herring wrote:
>> On Thu, Oct 15, 2015 at 11:51 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
>>>> On TI's Keystone platforms, several peripherals such as the
>>>> gbe ethernet switch, 10gbe ethether 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.
>>>
>>> Given that serdes is not specific to TI, should this be specific to
>>> TI, or should there be an effort to come up with something which
>>> everyone who has serdes links can make use of?
>>>
Russell,

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?

Murali
>>> Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
>>> 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
>>> plethora of SoC specific stuff for this.
>>
>> The licensed IP I've seen doesn't provide a standard register
>> interface, but just signals to the IP block. Same with PLL IP. So
>> we'll probably get to see vendors continue to differentiate on PHY
>> register design. :)
>
> So what?  Network drivers differ radically in register design, yet we
> still have a standardised interface to network drivers.
>


-- 
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]

#1248807

From	Kishon Vijay Abraham I <kishon@ti.com>
Date	2015-10-16 16:20 +0200
Message-ID	<qke1s-jy-33@gated-at.bofh.it>
In reply to	#1248445

Hi,

On Friday 16 October 2015 01:32 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 15, 2015 at 08:00:41PM -0500, Rob Herring wrote:
>> On Thu, Oct 15, 2015 at 11:51 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:
>>>> On TI's Keystone platforms, several peripherals such as the
>>>> gbe ethernet switch, 10gbe ethether 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.
>>>
>>> Given that serdes is not specific to TI, should this be specific to
>>> TI, or should there be an effort to come up with something which
>>> everyone who has serdes links can make use of?
>>>
>>> Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
>>> 1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
>>> plethora of SoC specific stuff for this.
>>
>> The licensed IP I've seen doesn't provide a standard register
>> interface, but just signals to the IP block. Same with PLL IP. So
>> we'll probably get to see vendors continue to differentiate on PHY
>> register design. :)
> 
> So what?  Network drivers differ radically in register design, yet we
> still have a standardised interface to network drivers.
> 
The PHY framework (in drivers/phy/) already provides a standard
interface to be used by the controller drivers no?

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]

csiph-web

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

Contents

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

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

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

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

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

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

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

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

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

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

#1248003

#1248098

#1248264

#1248283

#1248445

#1248794

#1248807