[RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops
Jonathan Lemon
jonathan.lemon at gmail.com
Mon Jun 27 12:27:52 PDT 2022
On Sun, Jun 26, 2022 at 08:28:34PM +0100, Vadim Fedorenko wrote:
> On 24.06.2022 00:36, Jonathan Lemon wrote:
> > On Fri, Jun 24, 2022 at 12:11:43AM +0100, Vadim Fedorenko wrote:
> > > On 23.06.2022 19:28, Jonathan Lemon wrote:
> > > > On Thu, Jun 23, 2022 at 03:57:17AM +0300, Vadim Fedorenko wrote:
> > > > > From: Vadim Fedorenko <vadfed at fb.com>
> > > > > +static int ptp_ocp_dpll_get_source_type(struct dpll_device *dpll, int sma)
> > > > > +{
> > > > > + struct ptp_ocp *bp = (struct ptp_ocp *)dpll_priv(dpll);
> > > > > + int ret;
> > > > > +
> > > > > + if (bp->sma[sma].mode != SMA_MODE_IN)
> > > > > + return -1;
> > > > > +
> > > > > + switch (ptp_ocp_sma_get(bp, sma)) {
> > > > > + case 0:
> > > > > + ret = DPLL_TYPE_EXT_10MHZ;
> > > > > + break;
> > > > > + case 1:
> > > > > + case 2:
> > > > > + ret = DPLL_TYPE_EXT_1PPS;
> > > > > + break;
> > > > > + default:
> > > > > + ret = DPLL_TYPE_INT_OSCILLATOR;
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > >
> > > > These case statements switch on private bits. This needs to match
> > > > on the selector name instead.
> > > >
> > >
> > > Not sure that string comparison is a good idea. Maybe it's better to extend
> > > struct ocp_selector with netlink type id and fill it according to hardware?
> >
> > Sure, that could be an option. But, as this is DPLL only, how does it
> > handle things when a pin is used for non-clock IO? In the timecard,
> > for example, we have the frequency counters for input, and the frequency
> > generators/VCC/GND for output.
> >
> > Actually our HW has a multi-level input, where the DPLL selects its
> > source from an internal mux - this isn't reflected here. The external
> > pins feed into some complex HW logic, which performs its own priority
> > calculations before presenting the end result as an available selection
> > for the DPLL.
>
> I don't really know how to deal with such configuration. For now I simply added
> CUSTOM type but I'm not sure how to deal it 'set' functions. Do you have any
> suggestions?
No suggestions other than the API should be able to handle things?
Also, should there be a notifier if the source changes?
--
Jonathan
More information about the linux-arm-kernel
mailing list