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

Groups > linux.kernel > #1217068 > unrolled thread

[PATCH] ARM: dts: keystone: use one to one address translations under netcp

Back to article view | Back to linux.kernel

Contents

  [PATCH] ARM: dts: keystone: use one to one address translations under netcp WingMan Kwok <w-kwok2@ti.com> - 2015-09-01 22:40 +0200
    Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp "santosh.shilimkar@oracle.com" <santosh.shilimkar@oracle.com> - 2015-09-01 23:30 +0200
      RE: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp "Kwok, WingMan" <w-kwok2@ti.com> - 2015-09-02 17:40 +0200
        Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp santosh shilimkar <santosh.shilimkar@oracle.com> - 2015-09-02 18:00 +0200
          Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp Murali Karicheri <m-karicheri2@ti.com> - 2015-09-02 18:40 +0200
            Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp santosh shilimkar <santosh.shilimkar@oracle.com> - 2015-09-02 19:30 +0200
              Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp Murali Karicheri <m-karicheri2@ti.com> - 2015-09-02 20:00 +0200
                Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp santosh shilimkar <santosh.shilimkar@oracle.com> - 2015-09-02 20:30 +0200
                  Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp Murali Karicheri <m-karicheri2@ti.com> - 2015-09-02 20:50 +0200
          Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp Tony Lindgren <tony@atomide.com> - 2015-09-03 16:30 +0200
            Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp "santosh.shilimkar@oracle.com" <santosh.shilimkar@oracle.com> - 2015-09-03 17:00 +0200
            Re: [PATCH] ARM: dts: keystone: use one to one address translations  under netcp Murali Karicheri <m-karicheri2@ti.com> - 2015-09-03 21:20 +0200

#1217068 — [PATCH] ARM: dts: keystone: use one to one address translations under netcp

Network subsystem NetCP in Keystone-2 devices includes some HW blocks
that are memory mapped to ranges outside that of the NetCP itself.
Thus address space of a child node of the NetCP node needs to be
mapped 1:1 onto the parent address space.  Hence empty ranges
should be used under the NetCP node.

Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
---
 arch/arm/boot/dts/k2e-netcp.dtsi  |    8 +++-----
 arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++++++--------
 arch/arm/boot/dts/k2l-netcp.dtsi  |    8 +++-----
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
index b13b3c9..e103ed9 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -111,9 +111,7 @@ netcp: netcp@24000000 {
 	compatible = "ti,netcp-1.0";
 	#address-cells = <1>;
 	#size-cells = <1>;
-
-	/* NetCP address range */
-	ranges = <0 0x24000000 0x1000000>;
+	ranges;
 
 	clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
 	dma-coherent;
@@ -127,10 +125,10 @@ netcp: netcp@24000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		ranges;
-		gbe@200000 { /* ETHSS */
+		gbe@24200000 { /* ETHSS */
 			label = "netcp-gbe";
 			compatible = "ti,netcp-gbe-9";
-			reg = <0x200000 0x900>, <0x220000 0x20000>;
+			reg = <0x24200000 0x900>, <0x24220000 0x20000>;
 			/* enable-ale; */
 			tx-queue = <896>;
 			tx-channel = "nettx";
diff --git a/arch/arm/boot/dts/k2hk-netcp.dtsi b/arch/arm/boot/dts/k2hk-netcp.dtsi
index 77a32c3..3b885f5 100644
--- a/arch/arm/boot/dts/k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/k2hk-netcp.dtsi
@@ -127,9 +127,7 @@ netcp: netcp@2000000 {
 	compatible = "ti,netcp-1.0";
 	#address-cells = <1>;
 	#size-cells = <1>;
-
-	/* NetCP address range */
-	ranges  = <0 0x2000000 0x100000>;
+	ranges;
 
 	clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
 	dma-coherent;
@@ -140,15 +138,15 @@ netcp: netcp@2000000 {
 	ti,navigator-dma-names = "netrx0", "netrx1", "nettx";
 
 	netcp-devices {
-		ranges;
 		#address-cells = <1>;
 		#size-cells = <1>;
-		gbe@90000 { /* ETHSS */
-			#address-cells = <1>;
-			#size-cells = <1>;
+		ranges;
+		gbe@2090000 { /* ETHSS */
 			label = "netcp-gbe";
 			compatible = "ti,netcp-gbe";
-			reg = <0x90000 0x300>, <0x90400 0x400>, <0x90800 0x700>;
+			reg = <0x02090000 0x300>,
+			      <0x02090400 0x400>,
+			      <0x02090800 0x700>;
 			/* enable-ale; */
 			tx-queue = <648>;
 			tx-channel = "nettx";
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 6b95284..97ae805 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -110,9 +110,7 @@ netcp: netcp@26000000 {
 	compatible = "ti,netcp-1.0";
 	#address-cells = <1>;
 	#size-cells = <1>;
-
-	/* NetCP address range */
-	ranges = <0 0x26000000 0x1000000>;
+	ranges;
 
 	clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
 	dma-coherent;
@@ -126,10 +124,10 @@ netcp: netcp@26000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		ranges;
-		gbe@200000 { /* ETHSS */
+		gbe@26200000 { /* ETHSS */
 			label = "netcp-gbe";
 			compatible = "ti,netcp-gbe-5";
-			reg = <0x200000 0x900>, <0x220000 0x20000>;
+			reg = <0x26200000 0x900>, <0x26220000 0x20000>;
 			/* enable-ale; */
 			tx-queue = <896>;
 			tx-channel = "nettx";
-- 
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]

#1217092 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 9/1/15 1:28 PM, WingMan Kwok wrote:
> Network subsystem NetCP in Keystone-2 devices includes some HW blocks
> that are memory mapped to ranges outside that of the NetCP itself.
> Thus address space of a child node of the NetCP node needs to be
> mapped 1:1 onto the parent address space.  Hence empty ranges
> should be used under the NetCP node.
>
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> ---
>   arch/arm/boot/dts/k2e-netcp.dtsi  |    8 +++-----
>   arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++++++--------
>   arch/arm/boot/dts/k2l-netcp.dtsi  |    8 +++-----
>   3 files changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
> index b13b3c9..e103ed9 100644
> --- a/arch/arm/boot/dts/k2e-netcp.dtsi
> +++ b/arch/arm/boot/dts/k2e-netcp.dtsi
> @@ -111,9 +111,7 @@ netcp: netcp@24000000 {
>   	compatible = "ti,netcp-1.0";
>   	#address-cells = <1>;
>   	#size-cells = <1>;
> -
> -	/* NetCP address range */
> -	ranges = <0 0x24000000 0x1000000>;
> +	ranges;
>
What blocks are we talking here. We need to increase the
range if the current range isn't covering entire NETCP
address space. Removing range isn't a solution.

Regards,
Santosh

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

#1217702 — RE: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2FudG9zaC5zaGlsaW1r
YXJAb3JhY2xlLmNvbSBbbWFpbHRvOnNhbnRvc2guc2hpbGlta2FyQG9yYWNsZS5jb21dDQo+IFNl
bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMSwgMjAxNSA1OjE5IFBNDQo+IFRvOiBLd29rLCBXaW5n
TWFuOyByb2JoK2R0QGtlcm5lbC5vcmc7IHBhd2VsLm1vbGxAYXJtLmNvbTsNCj4gbWFyay5ydXRs
YW5kQGFybS5jb207IGlqYytkZXZpY2V0cmVlQGhlbGxpb24ub3JnLnVrOyBnYWxha0Bjb2RlYXVy
b3JhLm9yZzsNCj4gbGludXhAYXJtLmxpbnV4Lm9yZy51azsgZGV2aWNldHJlZUB2Z2VyLmtlcm5l
bC5vcmc7IGxpbnV4LWFybS0NCj4ga2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGxpbnV4LWtl
cm5lbEB2Z2VyLmtlcm5lbC5vcmc7IHNzYW50b3NoQGtlcm5lbC5vcmcNCj4gQ2M6IEthcmljaGVy
aSwgTXVyYWxpZGhhcmFuDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIEFSTTogZHRzOiBrZXlzdG9u
ZTogdXNlIG9uZSB0byBvbmUgYWRkcmVzcyB0cmFuc2xhdGlvbnMNCj4gdW5kZXIgbmV0Y3ANCj4g
DQo+IE9uIDkvMS8xNSAxOjI4IFBNLCBXaW5nTWFuIEt3b2sgd3JvdGU6DQo+ID4gTmV0d29yayBz
dWJzeXN0ZW0gTmV0Q1AgaW4gS2V5c3RvbmUtMiBkZXZpY2VzIGluY2x1ZGVzIHNvbWUgSFcgYmxv
Y2tzDQo+ID4gdGhhdCBhcmUgbWVtb3J5IG1hcHBlZCB0byByYW5nZXMgb3V0c2lkZSB0aGF0IG9m
IHRoZSBOZXRDUCBpdHNlbGYuDQo+ID4gVGh1cyBhZGRyZXNzIHNwYWNlIG9mIGEgY2hpbGQgbm9k
ZSBvZiB0aGUgTmV0Q1Agbm9kZSBuZWVkcyB0byBiZQ0KPiA+IG1hcHBlZCAxOjEgb250byB0aGUg
cGFyZW50IGFkZHJlc3Mgc3BhY2UuICBIZW5jZSBlbXB0eSByYW5nZXMNCj4gPiBzaG91bGQgYmUg
dXNlZCB1bmRlciB0aGUgTmV0Q1Agbm9kZS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFdpbmdN
YW4gS3dvayA8dy1rd29rMkB0aS5jb20+DQo+ID4gLS0tDQo+ID4gICBhcmNoL2FybS9ib290L2R0
cy9rMmUtbmV0Y3AuZHRzaSAgfCAgICA4ICsrKy0tLS0tDQo+ID4gICBhcmNoL2FybS9ib290L2R0
cy9rMmhrLW5ldGNwLmR0c2kgfCAgIDE0ICsrKysrKy0tLS0tLS0tDQo+ID4gICBhcmNoL2FybS9i
b290L2R0cy9rMmwtbmV0Y3AuZHRzaSAgfCAgICA4ICsrKy0tLS0tDQo+ID4gICAzIGZpbGVzIGNo
YW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDE4IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAt
LWdpdCBhL2FyY2gvYXJtL2Jvb3QvZHRzL2syZS1uZXRjcC5kdHNpIGIvYXJjaC9hcm0vYm9vdC9k
dHMvazJlLQ0KPiBuZXRjcC5kdHNpDQo+ID4gaW5kZXggYjEzYjNjOS4uZTEwM2VkOSAxMDA2NDQN
Cj4gPiAtLS0gYS9hcmNoL2FybS9ib290L2R0cy9rMmUtbmV0Y3AuZHRzaQ0KPiA+ICsrKyBiL2Fy
Y2gvYXJtL2Jvb3QvZHRzL2syZS1uZXRjcC5kdHNpDQo+ID4gQEAgLTExMSw5ICsxMTEsNyBAQCBu
ZXRjcDogbmV0Y3BAMjQwMDAwMDAgew0KPiA+ICAgCWNvbXBhdGlibGUgPSAidGksbmV0Y3AtMS4w
IjsNCj4gPiAgIAkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiAgIAkjc2l6ZS1jZWxscyA9IDwx
PjsNCj4gPiAtDQo+ID4gLQkvKiBOZXRDUCBhZGRyZXNzIHJhbmdlICovDQo+ID4gLQlyYW5nZXMg
PSA8MCAweDI0MDAwMDAwIDB4MTAwMDAwMD47DQo+ID4gKwlyYW5nZXM7DQo+ID4NCj4gV2hhdCBi
bG9ja3MgYXJlIHdlIHRhbGtpbmcgaGVyZS4gV2UgbmVlZCB0byBpbmNyZWFzZSB0aGUNCj4gcmFu
Z2UgaWYgdGhlIGN1cnJlbnQgcmFuZ2UgaXNuJ3QgY292ZXJpbmcgZW50aXJlIE5FVENQDQo+IGFk
ZHJlc3Mgc3BhY2UuIFJlbW92aW5nIHJhbmdlIGlzbid0IGEgc29sdXRpb24uDQo+IA0KDQpUaGUg
U2VyZGVzLiAgSXQgaXMgYSBIVyBibG9jayBpbnNpZGUgdGhlIE5ldENQIGJ1dCBpdHMgYWRkcmVz
cw0Kc3BhY2Ugc3RhcnRzIGZyb20gMHgwMjMyYTAwMC4gIFdlIGNhbiBjaGFuZ2UgdGhlIGJhc2Ug
aW4gdGhlDQpyYW5nZXMgcHJvcGVydHkgdG8gaW5jbHVkZSB0aGUgc2VyZGVzLiAgQnV0IHRoZW4g
b2Zmc2V0cyBvZg0Kb3RoZXIgSFcgYmxvY2tzIHRoYXQgYXJlIHdpdGhpbiB0aGUgTmV0Q1AgYWRk
cmVzcyByYW5nZSB3aWxsIGJlDQpyZWxhdGl2ZSB0byB0aGlzIG5ldyBiYXNlIGFuZCBhcmUgbm90
IGFzIGRvY3VtZW50ZWQgaW4gdGhlIEhXDQp1c2VyIGd1aWRlcy4NCg0KUmVnYXJkcw0KV2luZ01h
bg0K
--
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]

#1217722 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 9/2/2015 8:31 AM, Kwok, WingMan wrote:
>
>
>> -----Original Message-----
>> From: santosh.shilimkar@oracle.com [mailto:santosh.shilimkar@oracle.com]
>> Sent: Tuesday, September 01, 2015 5:19 PM
>> To: Kwok, WingMan; robh+dt@kernel.org; pawel.moll@arm.com;
>> mark.rutland@arm.com; ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
>> linux@arm.linux.org.uk; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; ssantosh@kernel.org
>> Cc: Karicheri, Muralidharan
>> Subject: Re: [PATCH] ARM: dts: keystone: use one to one address translations
>> under netcp
>>
>> On 9/1/15 1:28 PM, WingMan Kwok wrote:
>>> Network subsystem NetCP in Keystone-2 devices includes some HW blocks
>>> that are memory mapped to ranges outside that of the NetCP itself.
>>> Thus address space of a child node of the NetCP node needs to be
>>> mapped 1:1 onto the parent address space.  Hence empty ranges
>>> should be used under the NetCP node.
>>>
>>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>>> ---
>>>    arch/arm/boot/dts/k2e-netcp.dtsi  |    8 +++-----
>>>    arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++++++--------
>>>    arch/arm/boot/dts/k2l-netcp.dtsi  |    8 +++-----
>>>    3 files changed, 12 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-
>> netcp.dtsi
>>> index b13b3c9..e103ed9 100644
>>> --- a/arch/arm/boot/dts/k2e-netcp.dtsi
>>> +++ b/arch/arm/boot/dts/k2e-netcp.dtsi
>>> @@ -111,9 +111,7 @@ netcp: netcp@24000000 {
>>>    	compatible = "ti,netcp-1.0";
>>>    	#address-cells = <1>;
>>>    	#size-cells = <1>;
>>> -
>>> -	/* NetCP address range */
>>> -	ranges = <0 0x24000000 0x1000000>;
>>> +	ranges;
>>>
>> What blocks are we talking here. We need to increase the
>> range if the current range isn't covering entire NETCP
>> address space. Removing range isn't a solution.
>>
>
> The Serdes.  It is a HW block inside the NetCP but its address
> space starts from 0x0232a000.  We can change the base in the
> ranges property to include the serdes.  But then offsets of
> other HW blocks that are within the NetCP address range will be
> relative to this new base and are not as documented in the HW
> user guides.
>
I suspected the same. I know back then we started with SERDES code
with NETCP but as you already know, its a separate block which
is needed for NIC card to work. Its more of phy and hence its
having different address space is not surprising.

IIRC, there was a plan to consolidate the serdes code together
since the PCIE also needs it. Irrespective of that, I suggest
you model the serdes address space in another node and fetch
it from there if that works for you. Please also add DTS
documentation if you are going ahead with that approach.

Regards,
Santosh



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

#1217739 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

Santosh,

On 09/02/2015 11:50 AM, santosh shilimkar wrote:
> On 9/2/2015 8:31 AM, Kwok, WingMan wrote:
>>
>>
>>> -----Original Message-----
>>> From: santosh.shilimkar@oracle.com [mailto:santosh.shilimkar@oracle.com]
>>> Sent: Tuesday, September 01, 2015 5:19 PM
>>> To: Kwok, WingMan; robh+dt@kernel.org; pawel.moll@arm.com;
>>> mark.rutland@arm.com; ijc+devicetree@hellion.org.uk;
>>> galak@codeaurora.org;
>>> linux@arm.linux.org.uk; devicetree@vger.kernel.org; linux-arm-
>>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>> ssantosh@kernel.org
>>> Cc: Karicheri, Muralidharan
>>> Subject: Re: [PATCH] ARM: dts: keystone: use one to one address
>>> translations
>>> under netcp
>>>
>>> On 9/1/15 1:28 PM, WingMan Kwok wrote:
>>>> Network subsystem NetCP in Keystone-2 devices includes some HW blocks
>>>> that are memory mapped to ranges outside that of the NetCP itself.
>>>> Thus address space of a child node of the NetCP node needs to be
>>>> mapped 1:1 onto the parent address space.  Hence empty ranges
>>>> should be used under the NetCP node.
>>>>
>>>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>>>> ---
>>>>    arch/arm/boot/dts/k2e-netcp.dtsi  |    8 +++-----
>>>>    arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++++++--------
>>>>    arch/arm/boot/dts/k2l-netcp.dtsi  |    8 +++-----
>>>>    3 files changed, 12 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-
>>> netcp.dtsi
>>>> index b13b3c9..e103ed9 100644
>>>> --- a/arch/arm/boot/dts/k2e-netcp.dtsi
>>>> +++ b/arch/arm/boot/dts/k2e-netcp.dtsi
>>>> @@ -111,9 +111,7 @@ netcp: netcp@24000000 {
>>>>        compatible = "ti,netcp-1.0";
>>>>        #address-cells = <1>;
>>>>        #size-cells = <1>;
>>>> -
>>>> -    /* NetCP address range */
>>>> -    ranges = <0 0x24000000 0x1000000>;
>>>> +    ranges;
>>>>
>>> What blocks are we talking here. We need to increase the
>>> range if the current range isn't covering entire NETCP
>>> address space. Removing range isn't a solution.
>>>
>>
>> The Serdes.  It is a HW block inside the NetCP but its address
>> space starts from 0x0232a000.  We can change the base in the
>> ranges property to include the serdes.  But then offsets of
>> other HW blocks that are within the NetCP address range will be
>> relative to this new base and are not as documented in the HW
>> user guides.
>>
> I suspected the same. I know back then we started with SERDES code
> with NETCP but as you already know, its a separate block which
> is needed for NIC card to work. Its more of phy and hence its
> having different address space is not surprising.

Using Phy interface is not acceptable to the subsystem maintainer based 
on the communication I had on this. Also the Phy here is tighly coupled 
with the hardware block it is working with. So this model is not right 
for SerDes driver as it require additional enhancements as described 
below if needs to be used.

The serdes initialization procedure requires checking the status in the 
hardware block (PCIe, 1G or 10G) and then taking corrective action. This 
means a Phy driver would require mapping of related hw address space 
(PCIe, 1G and 10G) as well which is already mapped by the hardware 
driver(PCIe, 1G and 10G). One solution is to treat this as a libray 
function that can be called from the respective hardware device driver. 
  A device node of h/w device (PCIe or 1G) in such as looks like

pcie {

	serdes@someaddress {
		reg = <address of serdes>;
	}
}

hw driver will call ks2_serdes_init(node, hw_base_address) to initialize 
the serdes. Other APIs can be added to enable/disable lane or shutdown 
etc. The libary will be added to drivers/soc/ti/ and used by various 
device drivers to initialize and use the phy. As the serdes is slightly 
integrated with the hardware block, IMO, this is a better approach than 
using the phy model. The API definitions will be added to 
include/linux/soc/ti/ folder.

The SerDes will use the firmware interface to download and configure the 
hardware block to use with PCIe/1G/10G/SRIO. I queried the linux forum 
on this and the response was that firmware interface can be used for 
this. The patch will be using the firmware interface instead of 
embedding magic values in the serdes driver.

Murali

>
> IIRC, there was a plan to consolidate the serdes code together
> since the PCIE also needs it. Irrespective of that, I suggest
> you model the serdes address space in another node and fetch
> it from there if that works for you. Please also add DTS
> documentation if you are going ahead with that approach.
>

> Regards,
> Santosh
>
>
>
>
>


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

#1217768 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 9/2/2015 9:35 AM, Murali Karicheri wrote:
> Santosh,
>
> On 09/02/2015 11:50 AM, santosh shilimkar wrote:
>> On 9/2/2015 8:31 AM, Kwok, WingMan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: santosh.shilimkar@oracle.com
>>>> [mailto:santosh.shilimkar@oracle.com]
>>>> Sent: Tuesday, September 01, 2015 5:19 PM
>>>> To: Kwok, WingMan; robh+dt@kernel.org; pawel.moll@arm.com;
>>>> mark.rutland@arm.com; ijc+devicetree@hellion.org.uk;
>>>> galak@codeaurora.org;
>>>> linux@arm.linux.org.uk; devicetree@vger.kernel.org; linux-arm-
>>>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>>> ssantosh@kernel.org
>>>> Cc: Karicheri, Muralidharan
>>>> Subject: Re: [PATCH] ARM: dts: keystone: use one to one address
>>>> translations
>>>> under netcp
>>>>
>>>> On 9/1/15 1:28 PM, WingMan Kwok wrote:
>>>>> Network subsystem NetCP in Keystone-2 devices includes some HW blocks
>>>>> that are memory mapped to ranges outside that of the NetCP itself.
>>>>> Thus address space of a child node of the NetCP node needs to be
>>>>> mapped 1:1 onto the parent address space.  Hence empty ranges
>>>>> should be used under the NetCP node.
>>>>>
>>>>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>>>>> ---
>>>>>    arch/arm/boot/dts/k2e-netcp.dtsi  |    8 +++-----
>>>>>    arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++++++--------
>>>>>    arch/arm/boot/dts/k2l-netcp.dtsi  |    8 +++-----
>>>>>    3 files changed, 12 insertions(+), 18 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-
>>>> netcp.dtsi
>>>>> index b13b3c9..e103ed9 100644
>>>>> --- a/arch/arm/boot/dts/k2e-netcp.dtsi
>>>>> +++ b/arch/arm/boot/dts/k2e-netcp.dtsi
>>>>> @@ -111,9 +111,7 @@ netcp: netcp@24000000 {
>>>>>        compatible = "ti,netcp-1.0";
>>>>>        #address-cells = <1>;
>>>>>        #size-cells = <1>;
>>>>> -
>>>>> -    /* NetCP address range */
>>>>> -    ranges = <0 0x24000000 0x1000000>;
>>>>> +    ranges;
>>>>>
>>>> What blocks are we talking here. We need to increase the
>>>> range if the current range isn't covering entire NETCP
>>>> address space. Removing range isn't a solution.
>>>>
>>>
>>> The Serdes.  It is a HW block inside the NetCP but its address
>>> space starts from 0x0232a000.  We can change the base in the
>>> ranges property to include the serdes.  But then offsets of
>>> other HW blocks that are within the NetCP address range will be
>>> relative to this new base and are not as documented in the HW
>>> user guides.
>>>
>> I suspected the same. I know back then we started with SERDES code
>> with NETCP but as you already know, its a separate block which
>> is needed for NIC card to work. Its more of phy and hence its
>> having different address space is not surprising.
>
> Using Phy interface is not acceptable to the subsystem maintainer based
> on the communication I had on this. Also the Phy here is tighly coupled
> with the hardware block it is working with. So this model is not right
> for SerDes driver as it require additional enhancements as described
> below if needs to be used.
>
Thanks for update on that.

> The serdes initialization procedure requires checking the status in the
> hardware block (PCIe, 1G or 10G) and then taking corrective action. This
> means a Phy driver would require mapping of related hw address space
> (PCIe, 1G and 10G) as well which is already mapped by the hardware
> driver(PCIe, 1G and 10G). One solution is to treat this as a libray
> function that can be called from the respective hardware device driver.
>   A device node of h/w device (PCIe or 1G) in such as looks like
>
Or SerDes driver can embed the status reg address space.
This is read only access so should be fine.

> pcie {
>
>      serdes@someaddress {
>          reg = <address of serdes>;
>      }
> }
>
> hw driver will call ks2_serdes_init(node, hw_base_address) to initialize
> the serdes. Other APIs can be added to enable/disable lane or shutdown
> etc. The libary will be added to drivers/soc/ti/ and used by various
> device drivers to initialize and use the phy. As the serdes is slightly
> integrated with the hardware block, IMO, this is a better approach than
> using the phy model. The API definitions will be added to
> include/linux/soc/ti/ folder.
>
Serdes Driver with its status register address space might solve this
sharing problem. Library might work but we should try to have driver
considering there is a physical device. I don't have strong opinion
on drivers vs library.


> The SerDes will use the firmware interface to download and configure the
> hardware block to use with PCIe/1G/10G/SRIO. I queried the linux forum
> on this and the response was that firmware interface can be used for
> this. The patch will be using the firmware interface instead of
> embedding magic values in the serdes driver.
>
Firmware interface usage seems to be correct way.
Thanks for giving the details. It helped me to get better picture.

Regards,
Santosh

Regards,
Santosh
--
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]

#1217780 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 09/02/2015 01:24 PM, santosh shilimkar wrote:
> On 9/2/2015 9:35 AM, Murali Karicheri wrote:
>> Santosh,
>>

---Cut-------------------

>>> I suspected the same. I know back then we started with SERDES code
>>> with NETCP but as you already know, its a separate block which
>>> is needed for NIC card to work. Its more of phy and hence its
>>> having different address space is not surprising.
>>
>> Using Phy interface is not acceptable to the subsystem maintainer based
>> on the communication I had on this. Also the Phy here is tighly coupled
>> with the hardware block it is working with. So this model is not right
>> for SerDes driver as it require additional enhancements as described
>> below if needs to be used.
>>
> Thanks for update on that.
>
>> The serdes initialization procedure requires checking the status in the
>> hardware block (PCIe, 1G or 10G) and then taking corrective action. This
>> means a Phy driver would require mapping of related hw address space
>> (PCIe, 1G and 10G) as well which is already mapped by the hardware
>> driver(PCIe, 1G and 10G). One solution is to treat this as a libray
>> function that can be called from the respective hardware device driver.
>>   A device node of h/w device (PCIe or 1G) in such as looks like
>>
> Or SerDes driver can embed the status reg address space.
> This is read only access so should be fine.
>
>> pcie {
>>
>>      serdes@someaddress {
>>          reg = <address of serdes>;
>>      }
>> }
>>
>> hw driver will call ks2_serdes_init(node, hw_base_address) to initialize
>> the serdes. Other APIs can be added to enable/disable lane or shutdown
>> etc. The libary will be added to drivers/soc/ti/ and used by various
>> device drivers to initialize and use the phy. As the serdes is slightly
>> integrated with the hardware block, IMO, this is a better approach than
>> using the phy model. The API definitions will be added to
>> include/linux/soc/ti/ folder.
>>
> Serdes Driver with its status register address space might solve this
> sharing problem. Library might work but we should try to have driver
> considering there is a physical device. I don't have strong opinion
> on drivers vs library.
>

In addition to checking status in the SerDes, it needs to also check the 
status of the associated hardware block (PCIe, 1G, 10G etc). So this 
means, same needs to be mapped twice, first by the above hardware device 
drivers and then by the serdes driver which causes problem. My point is 
since they both are tightly coupled, a libary is a better option. That 
way the mapped address can be passed to the serdes API to perform the 
required task, instead of using Phy API which doesn't allow us to do the 
same. If SerDes h/w can be brought up independently, the Phy model fits 
well.

Murali
>
>> The SerDes will use the firmware interface to download and configure the
>> hardware block to use with PCIe/1G/10G/SRIO. I queried the linux forum
>> on this and the response was that firmware interface can be used for
>> this. The patch will be using the firmware interface instead of
>> embedding magic values in the serdes driver.
>>
> Firmware interface usage seems to be correct way.
> Thanks for giving the details. It helped me to get better picture.
>
> Regards,
> Santosh
>
> Regards,
> Santosh
>
>


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

#1217796 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

9/2/2015 10:58 AM, Murali Karicheri wrote:
> On 09/02/2015 01:24 PM, santosh shilimkar wrote:
>> On 9/2/2015 9:35 AM, Murali Karicheri wrote:
>>> Santosh,
>>>
>
> ---Cut-------------------
>
>>>> I suspected the same. I know back then we started with SERDES code
>>>> with NETCP but as you already know, its a separate block which
>>>> is needed for NIC card to work. Its more of phy and hence its
>>>> having different address space is not surprising.
>>>
>>> Using Phy interface is not acceptable to the subsystem maintainer based
>>> on the communication I had on this. Also the Phy here is tighly coupled
>>> with the hardware block it is working with. So this model is not right
>>> for SerDes driver as it require additional enhancements as described
>>> below if needs to be used.
>>>
>> Thanks for update on that.
>>
>>> The serdes initialization procedure requires checking the status in the
>>> hardware block (PCIe, 1G or 10G) and then taking corrective action. This
>>> means a Phy driver would require mapping of related hw address space
>>> (PCIe, 1G and 10G) as well which is already mapped by the hardware
>>> driver(PCIe, 1G and 10G). One solution is to treat this as a libray
>>> function that can be called from the respective hardware device driver.
>>>   A device node of h/w device (PCIe or 1G) in such as looks like
>>>
>> Or SerDes driver can embed the status reg address space.
>> This is read only access so should be fine.
>>
>>> pcie {
>>>
>>>      serdes@someaddress {
>>>          reg = <address of serdes>;
>>>      }
>>> }
>>>
>>> hw driver will call ks2_serdes_init(node, hw_base_address) to initialize
>>> the serdes. Other APIs can be added to enable/disable lane or shutdown
>>> etc. The libary will be added to drivers/soc/ti/ and used by various
>>> device drivers to initialize and use the phy. As the serdes is slightly
>>> integrated with the hardware block, IMO, this is a better approach than
>>> using the phy model. The API definitions will be added to
>>> include/linux/soc/ti/ folder.
>>>
>> Serdes Driver with its status register address space might solve this
>> sharing problem. Library might work but we should try to have driver
>> considering there is a physical device. I don't have strong opinion
>> on drivers vs library.
>>
>
> In addition to checking status in the SerDes, it needs to also check the
> status of the associated hardware block (PCIe, 1G, 10G etc). So this
> means, same needs to be mapped twice, first by the above hardware device
> drivers and then by the serdes driver which causes problem. My point is
> since they both are tightly coupled, a libary is a better option. That
> way the mapped address can be passed to the serdes API to perform the
> required task, instead of using Phy API which doesn't allow us to do the
> same. If SerDes h/w can be brought up independently, the Phy model fits
> well.
>
As I said, I don't have strong preference and fine with library approach.
I suggest you do a RFC to take this further. Include Arnd on CC for
that.

Regards,
Santosh


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

#1217800 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 09/02/2015 02:25 PM, santosh shilimkar wrote:
> 9/2/2015 10:58 AM, Murali Karicheri wrote:
>> On 09/02/2015 01:24 PM, santosh shilimkar wrote:
>>> On 9/2/2015 9:35 AM, Murali Karicheri wrote:
>>>> Santosh,
>>>>
>>
>> ---Cut-------------------
>>
>>>>> I suspected the same. I know back then we started with SERDES code
>>>>> with NETCP but as you already know, its a separate block which
>>>>> is needed for NIC card to work. Its more of phy and hence its
>>>>> having different address space is not surprising.
>>>>
>>>> Using Phy interface is not acceptable to the subsystem maintainer based
>>>> on the communication I had on this. Also the Phy here is tighly coupled
>>>> with the hardware block it is working with. So this model is not right
>>>> for SerDes driver as it require additional enhancements as described
>>>> below if needs to be used.
>>>>
>>> Thanks for update on that.
>>>
>>>> The serdes initialization procedure requires checking the status in the
>>>> hardware block (PCIe, 1G or 10G) and then taking corrective action.
>>>> This
>>>> means a Phy driver would require mapping of related hw address space
>>>> (PCIe, 1G and 10G) as well which is already mapped by the hardware
>>>> driver(PCIe, 1G and 10G). One solution is to treat this as a libray
>>>> function that can be called from the respective hardware device driver.
>>>>   A device node of h/w device (PCIe or 1G) in such as looks like
>>>>
>>> Or SerDes driver can embed the status reg address space.
>>> This is read only access so should be fine.
>>>
>>>> pcie {
>>>>
>>>>      serdes@someaddress {
>>>>          reg = <address of serdes>;
>>>>      }
>>>> }
>>>>
>>>> hw driver will call ks2_serdes_init(node, hw_base_address) to
>>>> initialize
>>>> the serdes. Other APIs can be added to enable/disable lane or shutdown
>>>> etc. The libary will be added to drivers/soc/ti/ and used by various
>>>> device drivers to initialize and use the phy. As the serdes is slightly
>>>> integrated with the hardware block, IMO, this is a better approach than
>>>> using the phy model. The API definitions will be added to
>>>> include/linux/soc/ti/ folder.
>>>>
>>> Serdes Driver with its status register address space might solve this
>>> sharing problem. Library might work but we should try to have driver
>>> considering there is a physical device. I don't have strong opinion
>>> on drivers vs library.
>>>
>>
>> In addition to checking status in the SerDes, it needs to also check the
>> status of the associated hardware block (PCIe, 1G, 10G etc). So this
>> means, same needs to be mapped twice, first by the above hardware device
>> drivers and then by the serdes driver which causes problem. My point is
>> since they both are tightly coupled, a libary is a better option. That
>> way the mapped address can be passed to the serdes API to perform the
>> required task, instead of using Phy API which doesn't allow us to do the
>> same. If SerDes h/w can be brought up independently, the Phy model fits
>> well.
>>
> As I said, I don't have strong preference and fine with library approach.
> I suggest you do a RFC to take this further. Include Arnd on CC for
> that.

Sure!

Murali
>
> Regards,
> Santosh
>
>
>
>


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

#1218289 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

* santosh shilimkar <santosh.shilimkar@oracle.com> [150902 08:55]:
>
> I suspected the same. I know back then we started with SERDES code
> with NETCP but as you already know, its a separate block which
> is needed for NIC card to work. Its more of phy and hence its
> having different address space is not surprising.

The point Santosh is making here though is that any drivers
tinkering with registers belonging to a separate hardware block
is a recipe for a long term maintenance nightmare with mysterious
bugs popping up as things are not clocked or powered properly
or become racy with other drivers.

Each hardware block needs to have it's own driver and then the
drivers can communicate using some Linux generic APIs like clock,
regulator, phy, or mailbox frameworks.

Regards,

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

#1218308 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

On 9/3/15 7:26 AM, Tony Lindgren wrote:
> * santosh shilimkar <santosh.shilimkar@oracle.com> [150902 08:55]:
>>
>> I suspected the same. I know back then we started with SERDES code
>> with NETCP but as you already know, its a separate block which
>> is needed for NIC card to work. Its more of phy and hence its
>> having different address space is not surprising.
>
> The point Santosh is making here though is that any drivers
> tinkering with registers belonging to a separate hardware block
> is a recipe for a long term maintenance nightmare with mysterious
> bugs popping up as things are not clocked or powered properly
> or become racy with other drivers.
>
> Each hardware block needs to have it's own driver and then the
> drivers can communicate using some Linux generic APIs like clock,
> regulator, phy, or mailbox frameworks.
>
Right !!

Regards,
Santosh



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

#1218527 — Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

Tony,
On 09/03/2015 10:26 AM, Tony Lindgren wrote:
> * santosh shilimkar <santosh.shilimkar@oracle.com> [150902 08:55]:
>>
>> I suspected the same. I know back then we started with SERDES code
>> with NETCP but as you already know, its a separate block which
>> is needed for NIC card to work. Its more of phy and hence its
>> having different address space is not surprising.
>
> The point Santosh is making here though is that any drivers
> tinkering with registers belonging to a separate hardware block
> is a recipe for a long term maintenance nightmare with mysterious

That is what we want to avoid as well. If I interpret your statement 
correctly, you don't want SerDes driver update the register of say 
SGMII, right? But we will have to based on the hardware design. So it 
can't be a standalone device driver IMO and it has to be part of the 
respective peripheral device driver.

> bugs popping up as things are not clocked or powered properly
> or become racy with other drivers.
>
> Each hardware block needs to have it's own driver and then the
> drivers can communicate using some Linux generic APIs like clock,
> regulator, phy, or mailbox frameworks.

That depends on what your definition of a hardware block is. Inside 
NetCP, there are many hardware blocks that work together to provide the 
NIC functionality, and SerDes is one of them. Where ever possible, we 
have separate drivers :- knav qmss, knav pkt dma, ethss, mdio etc. Ethss 
driver manages Eth subsystem that includes SGMII and SerDes. 
Unfortunately SerDes is tightly integrated with ethss and taking it out 
as a separate driver (Say Phy) is not a good idea. We will posting an 
RFC for this soon and probably we can discuss it more then.

Probably we will fold this into the RFC series to give this a better 
context.

Murali

>
> Regards,
>
> Tony
>


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

Back to top | Article view | linux.kernel

csiph-web