From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@oracle.com (santosh shilimkar) Date: Wed, 2 Sep 2015 11:25:41 -0700 Subject: [PATCH] ARM: dts: keystone: use one to one address translations under netcp In-Reply-To: <55E738AE.9000207@ti.com> References: <1441139324-29296-1-git-send-email-w-kwok2@ti.com> <55E61658.9010207@oracle.com> <230CBA6E4B6B6B418E8730AC28E6FC7E04221776@DFLE11.ent.ti.com> <55E71AB3.7070406@oracle.com> <55E7255A.8060402@ti.com> <55E730D4.6040102@oracle.com> <55E738AE.9000207@ti.com> Message-ID: <55E73F25.2050608@oracle.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 at someaddress { >>> reg =
; >>> } >>> } >>> >>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh shilimkar Subject: Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp Date: Wed, 2 Sep 2015 11:25:41 -0700 Message-ID: <55E73F25.2050608@oracle.com> References: <1441139324-29296-1-git-send-email-w-kwok2@ti.com> <55E61658.9010207@oracle.com> <230CBA6E4B6B6B418E8730AC28E6FC7E04221776@DFLE11.ent.ti.com> <55E71AB3.7070406@oracle.com> <55E7255A.8060402@ti.com> <55E730D4.6040102@oracle.com> <55E738AE.9000207@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E738AE.9000207-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Murali Karicheri , "Kwok, WingMan" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "pawel.moll-5wv7dgnIgG8@public.gmane.org" , "mark.rutland-5wv7dgnIgG8@public.gmane.org" , "ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org" , "galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" List-Id: devicetree@vger.kernel.org 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 =
; >>> } >>> } >>> >>> 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 devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932142AbbIBS01 (ORCPT ); Wed, 2 Sep 2015 14:26:27 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:27639 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754914AbbIBS0Z (ORCPT ); Wed, 2 Sep 2015 14:26:25 -0400 Subject: Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp To: Murali Karicheri , "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" References: <1441139324-29296-1-git-send-email-w-kwok2@ti.com> <55E61658.9010207@oracle.com> <230CBA6E4B6B6B418E8730AC28E6FC7E04221776@DFLE11.ent.ti.com> <55E71AB3.7070406@oracle.com> <55E7255A.8060402@ti.com> <55E730D4.6040102@oracle.com> <55E738AE.9000207@ti.com> From: santosh shilimkar Organization: Oracle Corporation Message-ID: <55E73F25.2050608@oracle.com> Date: Wed, 2 Sep 2015 11:25:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55E738AE.9000207@ti.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 =
; >>> } >>> } >>> >>> 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