On Tue, Aug 31, 2021 at 06:58:24PM -0700, Jakub Kicinski wrote: > On Tue, 31 Aug 2021 09:19:27 -0700 Richard Cochran wrote: > > As you said later on in this thread, any API we merge now will have to > > last. That is why I'm being so picky here. We want new APIs to cover > > current HW _and_ be reasonable for the future. > > > > I don't see a DPLL as either a PTP Hardware Clock or a Network > > Device. It is a PLL. > > > > The kernel can and should have a way to represent the relationship > > between these three different kind of IP block. We already have a > > way to get from PHC to netdev interface. > > Makes sense to me. I was wondering how to split things at high level > into the areas you mentioned, but TBH the part I'm struggling with is > the delineation of what falls under PTP. PLL by itself seems like an > awfully small unit to create a subsystem for, and PTP already has aux > stuff like PIN control. These pins are a direct HW interface to the posix dynamic clock that also generates time stamps on the PTP frames. They can either generate time stamps on external signals, or produce output signals from the very same clock. So the pins are rather tightly coupled to the PTP clock itself. But the pins do NOT cover input clock sources into the IP cores. This kind of thing is already covered by the DTS for many SoCs (for a static input clock choice, not changeable at run time) > Then there's the whole bunch of stuff that Jonathan > is adding via driver specific sysfs interfaces [1]. I was hoping the > "new API" would cover his need but PLL would be a tiny part of it. > > IOW after looking at the code I'm not so sure how to reasonably divide > things. Right, me neither. It is a big topic, and we needn't over engineer it now, but I still think this DPLL is not part of the PTP clock. There has to be a better place for it. Thanks, Richard
