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

[Murali Karicheri]

On 09/02/2015 02:25 PM, santosh shilimkar wrote:
> 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.

Sure!

Murali
> Regards,
> Santosh


--
Murali Karicheri
Linux Kernel, Keystone
--
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/