[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6hcqrcy3meskddrklb3jtlpca2snrs4upwms56lhq7mkes7krm@vdiaqkfc6lgg>
Date: Mon, 12 Jan 2026 09:56:25 +0000
From: Rodrigo Alencar <455.rodrigo.alencar@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>,
rodrigo.alencar@...log.com
Cc: linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v3 2/6] iio: frequency: adf41513: driver implementation
On 26/01/09 08:55PM, Andy Shevchenko wrote:
> On Thu, Jan 08, 2026 at 12:14:51PM +0000, Rodrigo Alencar via B4 Relay wrote:
> >
> > The driver is based on existing PLL drivers in the IIO subsystem and
> > implements the following key features:
> >
> > - Integer-N and fractional-N (fixed/variable modulus) synthesis modes
> > - High-resolution frequency calculations using microhertz (µHz) precision
> > to handle sub-Hz resolution across multi-GHz frequency ranges
> > - IIO debugfs interface for direct register access
> > - FW property parsing from devicetree including charge pump settings,
> > reference path configuration and muxout options
> > - Power management support with suspend/resume callbacks
> > - Lock detect GPIO monitoring
> >
> > The driver uses 64-bit microhertz values throughout PLL calculations to
> > maintain precision when working with frequencies that exceed 32-bit Hz
> > representation while requiring fractional Hz resolution.
>
> ...
>
> > +/* Specifications */
> > +#define ADF41510_MAX_RF_FREQ (10000ULL * HZ_PER_MHZ)
> > +#define ADF41513_MIN_RF_FREQ (1000ULL * HZ_PER_MHZ)
> > +#define ADF41513_MAX_RF_FREQ (26500ULL * HZ_PER_MHZ)
>
> We need HZ_PER_GHZ. I think it's easy to have one be present in units.h.
>
26.5 GHz is not going to use HZ_PER_GHZ, so for consistency I think it makes
sense to keep HZ_PER_MHZ for the others.
> ...
>
> > +#define ADF41513_MIN_REF_FREQ (10U * HZ_PER_MHZ)
> > +#define ADF41513_MAX_REF_FREQ (800U * HZ_PER_MHZ)
> > +#define ADF41513_MAX_REF_FREQ_DOUBLER (225U * HZ_PER_MHZ)
>
> How does "U" help here?
not much really, will remove.
> ...
>
> > +#define ADF41513_MIN_INT_4_5 20
> > +#define ADF41513_MAX_INT_4_5 511
> > +#define ADF41513_MIN_INT_8_9 64
> > +#define ADF41513_MAX_INT_8_9 1023
>
> Not sure if we want (BIT(x) - 1) for the limits as we have non-0 minimums.
>
> ...
>
> > +#define ADF41513_MAX_CLK_DIVIDER 4095
>
> Sounds like a candidate for (BIT(12) - 1).
>
limits for INT are taken from the datasheet as is, so I think it makes to leave them
like this, as for CLK1/CLK2 max divider, indeed I can make it (BIT(12) - 1) as it
refers to a 12-bit register field.
> ...
>
> > +#define ADF41513_MAX_PHASE_MICRORAD 6283185UL
>
> Basically I'm replying to this just for this line. 180° is PI radians, which is
> something like 31415926... Can we use here (2 * 314...) where PI is provided in
> one of the used form? This will help to grep and replace in case we will have a
> common PI constant defined in the kernel (units.h).
>
> --
> With Best Regards,
> Andy Shevchenko
>
kind regards,
Rodrigo Alencar
Powered by blists - more mailing lists