lkml.org 
[lkml]   [2015]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ARM: dts: keystone: use one to one address translations under netcp
From
Date
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


\
 
 \ /
  Last update: 2015-09-02 19:41    [W:2.094 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site