Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230331165336.1047102-1-srinivas.pandruvada@linux.intel.com>
 <CAJZ5v0jocwROiayCpkp2CrmOFrBSShO5zPicWZQzaM+rj_25zg@mail.gmail.com>
 <221ff60648e0e76920cb5054e9cfb98ec77612b1.camel@linux.intel.com>
 <CAJZ5v0gSfNpPx_6daiHSrzozeqU7iMnErbMhD6fBU9w3EtYhJw@mail.gmail.com> <a32bbd493a8d9decc275c327d40e15985e11b0be.camel@linux.intel.com>
In-Reply-To: <a32bbd493a8d9decc275c327d40e15985e11b0be.camel@linux.intel.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Thu, 6 Apr 2023 20:56:04 +0200
Message-ID: <CAJZ5v0j2KG9+ozSkHZ9uiBca9c0tG8Nz_QH7w=DkwkChmJbp0w@mail.gmail.com>
Subject: Re: [PATCH] thermal/drivers/intel/int340x: Add DLVR support
To:     srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>, rui.zhang@intel.com,
        daniel.lezcano@linaro.org, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Tue, Apr 4, 2023 at 7:55 PM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Tue, 2023-04-04 at 18:46 +0200, Rafael J. Wysocki wrote:
> > On Tue, Apr 4, 2023 at 6:39 PM srinivas pandruvada
> > <srinivas.pandruvada@linux.intel.com> wrote:
> > >
> > > On Mon, 2023-04-03 at 20:37 +0200, Rafael J. Wysocki wrote:
> > > > On Fri, Mar 31, 2023 at 6:53 PM Srinivas Pandruvada
> > > > <srinivas.pandruvada@linux.intel.com> wrote:
> > > > >
> > > > > Add support for DLVR (Digital Linear Voltage Regulator)
> > > > > attributes,
> > > > > which can be used to control RFIM.
> > > > > Here instead of "fivr" another directory "dlvr" is created with
> > > > > DLVR
> > > > > attributes:
> > > > >
> > > > > /sys/bus/pci/devices/0000:00:04.0/dlvr
> > > > > ├── dlvr_freq_mhz
> > > > > ├── dlvr_freq_select
> > > > > ├── dlvr_hardware_rev
> > > > > ├── dlvr_pll_busy
> > > > > ├── dlvr_rfim_enable
> > > > > └── dlvr_spread_spectrum_pct
> > > > >
> > > > > Attributes
> > > > > dlvr_freq_mhz (RO):
> > > > > Current DLVR PLL frequency in MHz.
> > > > >
> > > > > dlvr_freq_select (RW):
> > > > > Sets DLVR PLL clock frequency.
> > > > >
> > > > > dlvr_hardware_rev (RO):
> > > > > DLVR hardware revision.
> > > > >
> > > > > dlvr_pll_busy (RO):
> > > > > PLL can't accept frequency change when set.
> > > > >
> > > > > dlvr_rfim_enable (RW):
> > > > > 0: Disable RF frequency hopping, 1: Enable RF frequency
> > > > > hopping.
> > > > >
> > > > > dlvr_spread_spectrum_pct (RW)
> > > > > A write to this register updates the DLVR spread spectrum
> > > > > percent
> > > > > value.
> > > >
> > > > How is this attribute going to be used by user space in practice?
> > >
> > > Spread spectrum percent helps to reduce the DLVR clock noise to
> > > meet
> > > regulatory compliance. This spreading % increases bandwidth of
> > > signal
> > > transmission and hence reduces the effects of interference, noise,
> > > and
> > > signal fading.
> >
> > The above information should be added to the documentation I think.
> >
> > Still, I would like to know when user space is going to write to it
> > and how it is going to find out what value to write.
> As specified in the
> https://docs.kernel.org/driver-api/thermal/intel_dptf.html
> This is all related to reduce interference with WiFi radio frequencies.

So the first two paragraphs in the "DPTF Processor thermal RFIM
interface" section need to be updated to mention/cover DLVR.  Then, it
will all be clear (at least AFAIAC).

> The algorithm should be read current dlvr_freq_mhz,
> dlvr_spread_spectrum_pct, current WiFi frequency (channel has a fix
> freq), find the error in WiFi frame error rates (From WiFi module), and
> do small adjustment +- to dlvr_freq. While changing the dlvr
> frequencies you may induce more interference so you spread the signal
> to reduce S/N ratio using this percent knob.
>
> >
> > > > Also should it be split like the frequency one (for consistency)?
> > >
> > > This is a RW field and is applied immediately unlike frequency,
> > > where
> > > it is two step process. First you specify and enable and then see
> > > the
> > > effect. So they are two fields.
> >
> > I was talking about dlvr_freq_mhz (RO) and dlvr_freq_select (RW).
> > I'm
> > not sure how the above is related to them TBH.
> The frequency is the base signal to which interference must be reduced.
> A good explanation for this technique
> https://www.eetimes.com/tutorial-on-spread-spectrum-technology/

Yes, I know what "spread spectrum" means.