[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e339312-f265-ce7e-dc70-253d1c93256d@redhat.com>
Date: Sun, 7 Mar 2021 20:13:11 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: "Neftin, Sasha" <sasha.neftin@...el.com>,
"David E. Box" <david.e.box@...ux.intel.com>,
irenic.rajneesh@...il.com, mgross@...ux.intel.com
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
intel-wired-lan@...ts.osuosl.org
Subject: Re: [PATCH] platform/x86: intel_pmc: Ignore GBE LTR on Tiger Lake
platforms
Hi,
On 3/7/21 9:39 AM, Neftin, Sasha wrote:
> On 3/5/2021 21:06, David E. Box wrote:
>> Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
>> programmed in the Tiger Lake GBE controller is not large enough to allow
>> the platform to enter Package C10, which in turn prevents the platform from
>> achieving its low power target during suspend-to-idle. Ignore the GBE LTR
>> value on Tiger Lake. LTR ignore functionality is currently performed solely
>> by a debugfs write call. Split out the LTR code into its own function that
>> can be called by both the debugfs writer and by this work around.
>>
>> Signed-off-by: David E. Box <david.e.box@...ux.intel.com>
>> Reviewed-by: Sasha Neftin <sasha.neftin@...el.com>
>> Cc: intel-wired-lan@...ts.osuosl.org
>> ---
>> drivers/platform/x86/intel_pmc_core.c | 55 ++++++++++++++++++++-------
>> 1 file changed, 42 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
>> index ee2f757515b0..ab31eb646a1a 100644
>> --- a/drivers/platform/x86/intel_pmc_core.c
>> +++ b/drivers/platform/x86/intel_pmc_core.c
>> @@ -863,34 +863,45 @@ static int pmc_core_pll_show(struct seq_file *s, void *unused)
>> }
>> DEFINE_SHOW_ATTRIBUTE(pmc_core_pll);
>> -static ssize_t pmc_core_ltr_ignore_write(struct file *file,
>> - const char __user *userbuf,
>> - size_t count, loff_t *ppos)
>> +static int pmc_core_write_ltr_ignore(u32 value)
>> {
>> struct pmc_dev *pmcdev = &pmc;
>> const struct pmc_reg_map *map = pmcdev->map;
>> - u32 val, buf_size, fd;
>> - int err;
>> -
>> - buf_size = count < 64 ? count : 64;
>> -
>> - err = kstrtou32_from_user(userbuf, buf_size, 10, &val);
>> - if (err)
>> - return err;
>> + u32 fd;
>> + int err = 0;
>> mutex_lock(&pmcdev->lock);
>> - if (val > map->ltr_ignore_max) {
>> + if (fls(value) > map->ltr_ignore_max) {
>> err = -EINVAL;
>> goto out_unlock;
>> }
>> fd = pmc_core_reg_read(pmcdev, map->ltr_ignore_offset);
>> - fd |= (1U << val);
>> + fd |= value;
>> pmc_core_reg_write(pmcdev, map->ltr_ignore_offset, fd);
>> out_unlock:
>> mutex_unlock(&pmcdev->lock);
>> +
>> + return err;
>> +}
>> +
>> +static ssize_t pmc_core_ltr_ignore_write(struct file *file,
>> + const char __user *userbuf,
>> + size_t count, loff_t *ppos)
>> +{
>> + u32 buf_size, val;
>> + int err;
>> +
>> + buf_size = count < 64 ? count : 64;
>> +
>> + err = kstrtou32_from_user(userbuf, buf_size, 10, &val);
>> + if (err)
>> + return err;
>> +
>> + err = pmc_core_write_ltr_ignore(1U << val);
>> +
>> return err == 0 ? count : err;
>> }
>> @@ -1189,6 +1200,15 @@ static int quirk_xtal_ignore(const struct dmi_system_id *id)
>> return 0;
>> }
>> +static int quirk_ltr_ignore(u32 val)
>> +{
>> + int err;
>> +
>> + err = pmc_core_write_ltr_ignore(val);
>> +
>> + return err;
>> +}
>> +
>> static const struct dmi_system_id pmc_core_dmi_table[] = {
>> {
>> .callback = quirk_xtal_ignore,
>> @@ -1244,6 +1264,15 @@ static int pmc_core_probe(struct platform_device *pdev)
>> pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit();
>> dmi_check_system(pmc_core_dmi_table);
>> + /*
>> + * On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when
>> + * a cable is attached. Tell the PMC to ignore it.
>> + */
>> + if (pmcdev->map == &tgl_reg_map) {
> I would suggest: if (pmcdev->map >= &tgl_reg_map)
Erm, no just no. tgl_reg_map is a global variable you can absolutely NOT rely
on the ordering of global variables in memory like this. Moreover using ordered
comparisons on pointers generally is a very bad idea, please don't.
Regards,
Hans
Powered by blists - more mailing lists