[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220630112742.0a1d0bf0@kernel.org>
Date: Thu, 30 Jun 2022 11:27:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vadim Fedorenko <vfedorenko@...ek.ru>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
Vadim Fedorenko <vadfed@...com>, Aya Levin <ayal@...dia.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jonathan Lemon <jonathan.lemon@...il.com>,
linux-arm-kernel@...ts.infradead.org,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [RFC PATCH v1 1/3] dpll: Add DPLL framework base functions
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.
Powered by blists - more mailing lists