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

[santosh shilimkar]

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