On Tue, 23 Feb 2021 17:37:40 +0100
Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
> On 2/18/21 3:05 PM, Jonathan Cameron wrote:
> > On Wed, 17 Feb 2021 10:34:38 +0200
> > Alexandru Ardelean <alexandru.ardelean@xxxxxxxxxx> wrote:
> >
> >> From: Mircea Caprioru <mircea.caprioru@xxxxxxxxxx>
> >>
> >> A PWM signal will be used as a trigger source to have a deterministic
> >> sampling frequency since this family of DAC has no hardware interrupt
> >> source.
> >>
> >> This feature is made optional however, as there are some board setups where
> >> this isn't used.
> >>
> > So this is taking a very generic setup, but then implementing it
> > as a bit of a hack within the driver.
> >
> > It's effectively a PWM connected up to an instance
> > of iio/triggers/iio-trig-interrupt.c
> >
> > Now, I've not looked at that trigger driver for a while, so you may well
> > need to figure out how to add a binding to instantiate it.
> > (looks like no one has used it since board file days, or via instantiation
> > from another driver).
> >
> > It's a slightly odd corner case as what it reflects is that we have
> > an interrupt available that is intended to drive some sort of data
> > capture or output (it's a trigger signal) - but exactly what is done
> > is a runtime configurable. In this particular case that interrupt
> > is hooked up to a PWM and we also want to represent that.
> >
> > The fact it's being driven via a PWM is interesting but we should be
> > able to extend that trigger driver to optionally accept a pwm provider
> > and if it has one provide frequency control.
> >
> > Binding might look something like the following..
> >
> > interrupt-trigger {
> > interrupts = <>;
> > pwms = <&pwm 0 4000 PWM_POLARITY_INVERTED>;
> > };
> >
> > @Rob, what do you think of this odd beast?
> >
> > So all in all, this generic facility needs a generic implementation, not
> > one buried in a driver.
> >
> > Another open question here is whether you really can't just use an hrtimer
> > to get similar precision? Way back at the dawn of time in IIO we had
> > code to use the RTC periodic ticks as a trigger with the theory that they
> > would give very precise and even timing. In the end it turned out that
> > hrtimers worked just as well (and RTCs drivers emulated the periodic
> > ticks via hrtimers, dropping their use of the hardware periodic timers).
> >
> The way this DAC works is that it has a "latch" pin and some shadow
> registers. The way this is supposed to be used is that you update the
> shadow registers and then when the there is a rising edge on the latch
> pin all the shadow register values are transferred to DAC output registers.
>
> This means if you hook up a periodic signal like a PWM or clock to the
> latch pin you can generate very precise waveforms that have much lower
> jitter than when using a hrtimer since there is no variable interrupt
> latency for the update step itself. This is useful when generating
> periodic signals.
>
> But you could for example also use a GPIO to update multiple discrete
> DACs at the same time.
>
> This is not specific to this particular chip. There are quite a few ADI
> (and probably from other vendors) precision DACs that have this
> functionality. I agree that this should be a some sort of generic
> trigger helper module.
>
> Now for the implementation since there is a direct connection between
> the PWM and the DAC I think it makes sense to describe this connection
> in the DT. After all if there is no connection this will not work.
Thanks for the detailed description. That makes a lot more sense.
This is some sort of hybrid of the hardware internal triggers
we have for some SoC ADCs and wiring up a gpio pin to trigger the latch
signal. PWM is one valid way of wiring it up (possibly most sensible
one), but not necessarily the only one.
I guess the one behind element is also a bit non intuitive (data is
put in place on previous interrupt / edge but latched on the next
one)
Hmm. If we makes sure the binding is cleanly defined, we could do
a driver specific implementation for now, with the option to figure
something else out later.
Exactly how to do this needs some thought...
+ lifting this description of hot it works into the patch description
would help :)
Jonathan
>
> As for the interrupt, most PWM controllers do have the ability to
> generate an IRQ by themselves once per period. There should be not need
> for a hardware loopback. Unfortunately the PWM framework does not have a
> mechanism yet to expose those IRQs and register a callback.
>
> A similar feature btw exists for many of the ADCs and we did have this
> special Blackfin PWM trigger[1] back in the day to support this. The
> bfin PWM trigger driver essentially implements what I'm describing
> above, but without using the PWM framework.
>
> - Lars
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/iio/trigger/iio-trig-bfin-timer.c?h=v3.15
>
