From: Jonathan Cameron <jic23@kernel.org>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: David Lechner <dlechner@baylibre.com>,
Kim Seer Paller <kimseer.paller@analog.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Michael Hennerich <michael.hennerich@analog.com>
Subject: Re: [PATCH 2/4] iio: ABI: add ABI file for the LTC2664 DAC
Date: Sat, 20 Apr 2024 11:22:27 +0100 [thread overview]
Message-ID: <20240420112227.68577ac0@jic23-huawei> (raw)
In-Reply-To: <79734a9f54e320cd09aab83015f1c0e6d93e700c.camel@gmail.com>
On Mon, 15 Apr 2024 14:45:52 +0200
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Sat, 2024-04-13 at 16:25 +0100, Jonathan Cameron wrote:
> > On Fri, 12 Apr 2024 16:26:17 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >
> > > On Thu, Apr 11, 2024 at 10:21 PM Kim Seer Paller
> > > <kimseer.paller@analog.com> wrote:
> > > >
> > > > Define the sysfs interface for toggle capable channels.
> > > >
> > > > Toggle enabled channels will have:
> > > >
> > > > * out_voltageY_toggle_en
> > The big missing thing in this ABI is a reference to existing precedence.
> > You aren't actually defining anything new, it just hasn't yet been generalized
> > beyond 1 device (unless you include PSK / FSK DDS drivers that are 'still'
> > after
> > 13+ years in staging!)
> >
> > This patch needs to be generalizing that documentation from the ltc2688.
> >
> > Probably in sysfs-bus-iio-dac
> >
> > >
> > > It looks like there are 3 toggle modes.
> > >
> > > Two involve the notion of "enabled" outputs that I assume this attribute is
> > > for:
> > >
> > > 1. Toggling all enabled pins at the same time using a software trigger
> > > (global toggle bit)
> > > 2. Toggling all enabled pins at the same time using a hardware trigger
> > > (TGP pin) and toggling pins
> > >
> >
> > This is presumably the tricky one as that hardware toggle may not be in
> > control of the host CPU.
> >
> > > The third mode though looks like it uses the same toggle select
> > > register for selecting A or B for each channel instead of enabling or
> > > disabling each channel.
> > >
> > > 3. Toggling all pins to A or B based on the toggle select register. No
> > > notion of enabled pins here.
> > >
> > > I haven't looked at the driver implementation, but it sounds like
> > > out_voltageY_toggle_en and out_voltageY_symbol would be writing to the
> > > same register in conflicting ways. So maybe we need yet another custom
> > > attribute to select the currently active toggle mode?
> >
> > This one feels like it could be handled as a software optimisation over
> > just changing the DAC value directly.
>
> Things may be slightly different in these devices. But for ltc2688 and AFAIR,
> the symbol attribute is about toggling between A and B through SW (not really
> enabling the mode). That interface will only pop up if there's no HW (PWM for
> example) toggle present.
I can't remember if we discussed it at the time of that driver,
but from a userspace interface point of view, for a single channel there would
be little point in this. I guess the key is it simultaneously switches
a bunch of channels. Perhaps we can make that clearer in the ABI docs
(if it isn't already clear enough!)
So a software interface does seem appropriate.
There is a fun question of whether the toggle select is useful to software.
That is picking which of A or B each output uses for next toggle.
At first glance I don't think so, but I'm open to people suggesting why
that might need a userspace interface.
Superficially feels like anything that can be done with that interface can
also be done keeping all channels toggling to A or all to B at one time and
potentially a few more register writes.
Jonathan
next prev parent reply other threads:[~2024-04-20 10:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 3:20 [PATCH 0/4] Add driver for LTC2664 and LTC2672 Kim Seer Paller
2024-04-12 3:20 ` [PATCH 1/4] dt-bindings: iio: dac: Add adi,ltc2664.yaml Kim Seer Paller
2024-04-12 5:50 ` Krzysztof Kozlowski
2024-04-13 14:54 ` Jonathan Cameron
2024-04-16 14:16 ` Paller, Kim Seer
2024-04-12 21:23 ` David Lechner
2024-04-13 15:06 ` Jonathan Cameron
2024-04-13 15:11 ` Jonathan Cameron
2024-04-13 16:21 ` David Lechner
2024-04-13 17:10 ` Jonathan Cameron
2024-04-16 14:40 ` Paller, Kim Seer
2024-04-20 10:13 ` Jonathan Cameron
2024-04-12 3:21 ` [PATCH 2/4] iio: ABI: add ABI file for the LTC2664 DAC Kim Seer Paller
2024-04-12 21:26 ` David Lechner
2024-04-13 15:25 ` Jonathan Cameron
2024-04-13 20:38 ` David Lechner
2024-04-15 12:45 ` Nuno Sá
2024-04-20 10:22 ` Jonathan Cameron [this message]
2024-04-12 3:21 ` [PATCH 3/4] iio: ABI: add ABI file for the LTC2672 DAC Kim Seer Paller
2024-04-13 15:26 ` Jonathan Cameron
2024-04-16 14:18 ` Paller, Kim Seer
2024-04-20 10:23 ` Jonathan Cameron
2024-04-12 3:21 ` [PATCH 4/4] iio: dac: ltc2664: Add driver for LTC2664 and LTC2672 Kim Seer Paller
2024-04-13 15:55 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240420112227.68577ac0@jic23-huawei \
--to=jic23@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=kimseer.paller@analog.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=noname.nuno@gmail.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.