Re: [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@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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/