Linux IIO development
 help / color / mirror / Atom feed
From: David Lechner <dlechner@baylibre.com>
To: Jonathan Cameron <jic23@kernel.org>,
	Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: robh@kernel.org, conor+dt@kernel.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>
Subject: Re: [PATCH v3 3/3] Documentation: ABI: adl8113: add documentation
Date: Mon, 17 Nov 2025 17:59:09 -0600	[thread overview]
Message-ID: <aa2808d2-58fd-41a9-a533-86896352a485@baylibre.com> (raw)
In-Reply-To: <20251116155013.2b55af25@jic23-huawei>

On 11/16/25 9:50 AM, Jonathan Cameron wrote:
> On Fri, 14 Nov 2025 11:57:25 +0000
> Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> 
>> Add ABI documentation for the ADL8113 Low Noise Amplifier,
>> covering the 4 pin-selectable operating modes.
>>
>> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> +CC all the IIO subsystem reviewers as I'm not sure how to handle
> what this device does, and would like some more opinions.
> 
> Anyone who has expertise or design experience with this sort
> of amplifier with external bypass path: how are these actually used?
> 
> The development board seems to just be suited to measurement of
> device characteristics, not representative of a design using it.
> 
>> ---
>>
>> Changes in v3:
>> - Replace "mode" attribute documentation with "signal_path" attribute
>> - Update descriptions to reflect separation of gain control (hardwaregain) and path control (signal_path)
>> - Add explanation of automatic bypass mode switching when selecting external paths
>> - Update attribute names from mode/mode_available to signal_path/signal_path_available
>> - Clarify that external paths enable connection of external components for filtering or amplification
>> ---
>>  .../testing/sysfs-bus-iio-amplifiers-adl8113  | 30 +++++++++++++++++++
>>  1 file changed, 30 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-amplifiers-adl8113
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-amplifiers-adl8113 b/Documentation/ABI/testing/sysfs-bus-iio-amplifiers-adl8113
>> new file mode 100644
>> index 000000000000..31fb1e6e80fc
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-amplifiers-adl8113
>> @@ -0,0 +1,30 @@
>> +What:		/sys/bus/iio/devices/iio:deviceX/signal_path
>> +Date:		January 2025
>> +KernelVersion:	6.14
>> +Contact:	linux-iio@vger.kernel.org
>> +Description:
>> +		This attribute controls the signal routing path for the ADL8113
>> +		Low Noise Amplifier. The supported signal paths are:
>> +
>> +		* internal - Signal passes through internal path. Can be used with
>> +		  either amplifier mode (14dB gain) or bypass mode (0dB gain).
>> +
>> +		* external_a - Signal routes from RFIN to OUT_A and from IN_A to RFOUT
>> +		  (VA=0, VB=1). External components can be connected for filtering or
>> +		  additional amplification. Automatically switches to bypass mode (0dB).
>> +
>> +		* external_b - Signal routes from RFIN to OUT_B and from IN_B to RFOUT
>> +		  (VA=1, VB=0). External components can be connected for filtering or
>> +		  additional amplification. Automatically switches to bypass mode (0dB).
> 
> I'm still not sure how to handle these external paths.  The one thing they won't be
> is truly zero gain (because that would be pointless given the internal bypass path does that).
> 
> So how are these used in practice?

Afraid I don't have any experience with this. But I would assume that the two external
bypasses each have another amplifier (or attenuator) connected to them.

> 
> Do we need to figure out how to describe the real characteristics of those paths?

It sounds like this is just a multiplexer. So a few ideas:

1. We could handle this like iio-mux.c and have 4 channels and just restrict use
   to one channel at a time. Not exactly sure how we would do that. Perhaps an
   enable attribute that is interlocked so that it will fail to enable if another
   channel is already enabled? In this case, the devicetree would need to have an
   io-channels property to get the two bypass amplifier channels and basically pass
   them through.

2. Have the devicetree specify the gain of the two external bypass amplifiers
   so that we can use the hardwaregain attribute to select between the 4 mux
   positions without needing a custom attribute. This works as long as none
   of the amplifiers have the same gain.

I'm envisioning this would be e.g. part of a range selection on some sort of
test equipment. In that case, option 2 seems the right way to go about it.



  reply	other threads:[~2025-11-17 23:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14 11:57 [PATCH v3 0/3] iio: amplifiers: add support for ADL8113 Low Noise Amplifier Antoniu Miclaus
2025-11-14 11:57 ` [PATCH v3 1/3] dt-bindings: iio: amplifiers: add adl8113 Antoniu Miclaus
2025-11-17 19:22   ` Conor Dooley
2025-11-17 23:42   ` David Lechner
2025-11-14 11:57 ` [PATCH v3 2/3] iio: amplifiers: adl8113: add driver support Antoniu Miclaus
2025-11-16 15:38   ` Jonathan Cameron
2025-11-14 11:57 ` [PATCH v3 3/3] Documentation: ABI: adl8113: add documentation Antoniu Miclaus
2025-11-16 15:50   ` Jonathan Cameron
2025-11-17 23:59     ` David Lechner [this message]
2025-11-18  8:08       ` Nuno Sá
2025-11-19  9:09     ` Miclaus, Antoniu

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=aa2808d2-58fd-41a9-a533-86896352a485@baylibre.com \
    --to=dlechner@baylibre.com \
    --cc=andy@kernel.org \
    --cc=antoniu.miclaus@analog.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox