Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Message-ID: <275e34c2e67a85c087ff983354bf74b5257b2fc4.camel@linux.intel.com>
Subject: Re: [PATCH v3 0/7] thermal: processor_thermal: Suport workload hint
From:   srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To:     "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     daniel.lezcano@linaro.org, rui.zhang@intel.com,
        linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Tue, 12 Sep 2023 12:44:10 -0700
In-Reply-To: <CAJZ5v0jrKSUOGG72w-EdzhQqC==CA7zYUofNSEW1wV-58TOnLw@mail.gmail.com>
References: <20230829002346.2104251-1-srinivas.pandruvada@linux.intel.com>
         <CAJZ5v0jrKSUOGG72w-EdzhQqC==CA7zYUofNSEW1wV-58TOnLw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

Hi Rafael,

On Tue, 2023-09-12 at 16:09 +0200, Rafael J. Wysocki wrote:
> On Tue, Aug 29, 2023 at 2:23=E2=80=AFAM Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> >=20
> >=20

[...]

> > --
>=20
> There is a slight issue with the patch ordering in this series,
> because the interface to enable the interrupt should only be provided
> after implementing the interrupt handlers.=C2=A0 I don't think that anyon=
e
> will apply the series partially and try to enable the feature,
> though.
Thanks!

>=20
> Also, I'm not actually sure if proc_thermal_wt_intr_callback() can
> run
> safely against the work item scheduled in proc_thermal_irq_handler()
> in case the workload hint one triggers along with a thermal threshold
> one.=C2=A0 I think that the access to MMIO is cached, so what if they bot=
h
> try to update the same cache line at the same time?=C2=A0 Or are they
> guaranteed to be different cache lines?
These two registers are 90 cache lines apart. Looking at all the
registers on this bar for status offsets, they are several cache lines
apart. Also this bar is non prefetchable, so continuous data can't be
fetched ahead.


>=20
> Anyway, tentatively applied as 6.7 material, but I've changed the
> second patch somewhat, because I couldn't convince myself that the
> implicit type conversions in
> processor_thermal_mbox_interrupt_config()
> would always do the right thing regardless of the numbers involved,
> so
> please check the result in my bleeding-edge branch.
>=20
If I diff, there is only one change in processor_thermal_mbox.c. Tested
that change and works fine.

Thanks,
Srinivas


> Thanks!