On 10/19/2017 10:04 AM, Ramesh Shanmugasundaram wrote: >>> Sounds reasonable. What's the status of this series? >> >> I have had some offline discussions with Franklin on this, and I am not >> fully convinced that DT is the way to go here (although I don't have the >> agreement with Franklin there). >> >> There are two components in configuring the secondary sample point. It is >> the transceiver loopback delay and an offset (example half of the bit time >> in data phase). >> >> While the transceiver loopback delay is pretty board dependent (and thus >> amenable to DT encoding), I am not quite sure the offset can be configured >> in DT because its not really board dependent. >> >> Unfortunately, offset calculation does not seem to be an exact science. >> There are recommendations ranging from using 50% of bit time to making it >> same as the sample point configured. This means users who need to change >> the SSP due to offset variations need to change their DT even without >> anything changing on their board. >> >> Since we have a netlink socket interface to configure sample point, I >> wonder if that should be extended to configure SSP too (or at least the >> offset part of SSP)? > > +1 > > I also wonder how a default TDCO setting in DT would help. For a given board with a given transceiver and layout and proper values in the supplied DT the higher bitrates would work out of the box. > Is the driver going to hard code the Tq settings as well for the > most commonly used bitrate? What's Tq in this context. Time Quanta? > A link up start-up script (using netlink) would help setting a > default TDCO along with other params if this is the main concern. There are various ways to setup these values. Plain old start-up scripts are one of them, systemd-networkd or network manager are others. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |