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 11:25:41 -0700 |
| |
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
| |