[RFC PATCH v1 1/3] dpll: Add DPLL framework base functions

[Jakub Kicinski]

On Thu, 30 Jun 2022 16:50:46 +0100 Vadim Fedorenko wrote:
> On 30.06.2022 03:23, Jakub Kicinski wrote:
>> On Thu, 30 Jun 2022 00:30:08 +0100 Vadim Fedorenko wrote:  
>>> This way it's getting closer and closer to ptp, but still having phase offset is
>>> fair point and I will go this way. Jakub, do you have any objections?  
>> 
>> How does the DPLL interface interact with PTP? Either API can set the
>> phase.  
> 
> Well, if the same hardware is exposed to both subsystem, it will be serialised 
> by hardware driver. And it goes to hardware implementation on how to deal with 
> such changes. Am I wrong?

That's what ends up happening in practice. But it's a pretty poor
experience for everyone involved :(

Stating the obvious, perhaps, but the goal should be that either the
APIs are disjoint or one is a superset of the other and there can be 
a kernel translation layer so that the driver only has to implement 
one.

By a quick look at the PTP header it has phase offsets for both the
clock and the outputs? Not sure. Don't see much in the docs either.