Messages in this thread | | | Subject | Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp | From | santosh shilimkar <> | Date | Wed, 2 Sep 2015 10:24:36 -0700 |
| |
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
| |