On 10/19/2017 10:04 AM, Ramesh Shanmugasundaram wrote:

quoted

quoted

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

quoted

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   |