On Tue, 16 Nov 2021 14:43:14 +0000 "Miclaus, Antoniu" <Antoniu.Miclaus@xxxxxxxxxx> wrote: > Hello Jonathan, > > -- > Antoniu Miclăuş > > > -----Original Message----- > > From: Jonathan Cameron <jic23@xxxxxxxxxx> > > Sent: Friday, November 12, 2021 7:46 PM > > To: Miclaus, Antoniu <Antoniu.Miclaus@xxxxxxxxxx> > > Cc: robh+dt@xxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx; > > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH 3/4] dt-bindings:iio:filter: add admv8818 doc > > > > [External] > > > > On Tue, 9 Nov 2021 14:31:26 +0200 > > Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx> wrote: > > > > > Add device tree bindings for the ADMV8818 Filter. > > > > > > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx> > > > --- > > > .../bindings/iio/filter/adi,admv8818.yaml | 78 +++++++++++++++++++ > > > 1 file changed, 78 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml > > > > > > diff --git > > a/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml > > b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml > > > new file mode 100644 > > > index 000000000000..d581e236dbdc > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml > > > @@ -0,0 +1,78 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > https://urldefense.com/v3/__http://devicetree.org/schemas/iio/filter/adi,a > > dmv8818.yaml*__;Iw!!A3Ni8CS0y2Y!qkKokhmcgS0YEIy3uC6OfOOF7Bq3yE_r > > Ny91yIkDRTXFe54x-cHq_BtsyzDOedLohB5D$ > > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta- > > schemas/core.yaml*__;Iw!!A3Ni8CS0y2Y!qkKokhmcgS0YEIy3uC6OfOOF7Bq3 > > yE_rNy91yIkDRTXFe54x-cHq_BtsyzDOeYdHtx0a$ > > > + > > > +title: ADMV8818 Digitally Tunable, High-Pass and Low-Pass Filter > > > + > > > +maintainers: > > > + - Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx> > > > + > > > +description: | > > > + Fully monolithic microwave integrated circuit (MMIC) that > > > + features a digitally selectable frequency of operation. > > > + The device features four independently controlled high-pass > > > + filters (HPFs) and four independently controlled low-pass filters > > > + (LPFs) that span the 2 GHz to 18 GHz frequency range. > > > + > > > + https://www.analog.com/en/products/admv8818.html > > > + > > > +properties: > > > + compatible: > > > + enum: > > > + - adi,admv8818 > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + spi-max-frequency: > > > + maximum: 10000000 > > > + > > > + clocks: > > > + description: > > > + Definition of the external clock. > > > + minItems: 1 > > > + > > > + clock-names: > > > + items: > > > + - const: "rf_in" > > > > Is this what we'd normally think of as a clock signal? I'd not expect > > a nice squarewave on that pin for example so this seems an odd way to > > define it. > > > The only actual use of this part, until now, was to filter the output of the following part: > https://www.analog.com/en/products/adf5610.html > This is the reason of using the clock framework in the driver. Moreover, the clock input is > optional inside the driver. OK, so in theory that part is generating a sinusoid. I guess the clk framework works for handling such devices, even if it's not typically what people expect from a clk. > > > + > > > + clock-output-names: > > > + maxItems: 1 > > > + > > > + adi,bw-hz: > > > + description: > > > + Allows the user to increase the Bandpass Filter (BPF) bandwidth > > > + in Hz. Normally when invoked by the clk notifier, the driver > > > + sets the HPF cutoff close below the frequency and the LPF cutoff > > > + close above the frequency, and thus creating a BPF. > > > > I don't understand this item at all. Why do we need a control to > > basically change how the other filter parameters are expressed? > > > > Indeed, this property was requested by the users of the application in which this part was involved. > Same goes for the filter modes and the bandwidth in the ABI documentation. > > If you think these attributes/properties are way too custom, I can drop them. It's interesting. I guess the point here is people want a nice autonomous system to keep the filter set appropriately for cleaning up a generated sine wave. It could be argued that is a hardware related thing so makes sense in DT. We are sort of 'emulating' a bandpass filter in the driver if we use this, but I guess if that's the main use case then this is perhaps a reasonable decision. > > Let me know your thoughts. > > > + $ref: /schemas/types.yaml#/definitions/uint64 > > > + > > > + '#clock-cells': > > > + const: 0 > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - clocks > > > + - clock-names > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > + spi { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + admv8818@0 { > > > + compatible = "adi,admv8818"; > > > + reg = <0>; > > > + spi-max-frequency = <10000000>; > > > + clocks = <&admv8818_rfin>; > > > + clock-names = "rf_in"; > > > + adi,bw-hz = /bits/ 64 <600000000>; > > > + }; > > > + }; > > > +... > > > + >
