linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: linux-next: manual merge of the thermal tree with the pm tree
Date: Thu, 5 Jan 2023 16:30:55 +0100	[thread overview]
Message-ID: <ea9167d4-0978-fc4b-755f-8df09fc7360e@linaro.org> (raw)
In-Reply-To: <bb71721b-ba20-90d9-df35-aff3c175194e@intel.com>

On 05/01/2023 15:27, Wysocki, Rafael J wrote:
> 
> On 1/5/2023 12:35 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Thu, 5 Jan 2023 10:10:54 +1100 Stephen Rothwell 
>> <sfr@canb.auug.org.au> wrote:
>>> Today's linux-next merge of the thermal tree got a conflict in:
>>>
>>>    drivers/thermal/intel/x86_pkg_temp_thermal.c
>>>
>>> between commit:
>>>
>>>    58374a3970a0 ("thermal/x86_pkg_temp_thermal: Add support for 
>>> handling dynamic tjmax")
>>>
>>> from the pm tree and commit:
>>>
>>>    03b2e86a24aa ("thermal/drivers/intel: Use generic 
>>> thermal_zone_get_trip() function")
>>>
>>> from the thermal tree.
> 
> I'm wondering why the above commit is in the linux-next branch of the 
> thermal tree, though.

If you are referring to commit 03b2e86a24aa, it is part of the series 
which was reviewed but got some locking conflict issues just before the 
merge window so we dropped it. You asked me to reintroduce it with the 
fixes after v6.2-rc1 is out [1].

The previous conflict and this one is because some changes were picked 
in the linux-pm branch instead of the thermal/linux-branch.

We find thermal Intel changes going directly in linux-pm and thermal 
changes going through the thermal tree. And sometime thermal core 
changes picked through linux-pm and sometime through thermal/linux-next.

In order to prevent these conflicts in the future, I suggest to always 
merge thermal patches through the thermal tree.

> It is still under review AFAICS.

The series including the patch "thermal/drivers/intel: Use generic ..." 
are reviewed and ready for inclusion AFAICT.

I'm was waiting for an update of linux-pm/thermal to send a PR against 
this branch.

> Daniel, can you possibly create a bleeding-edge branch for such things? 
> I can merge it into my bleeding-edge branch on a daily basis.

Yes, I can create a bleeding-edge branch for other patches. Some 
questions about it:

  - thermal/linux-next will be based on linux-pm/thermal, and 
thermal/bleeding-edge will be based on thermal/linux-next, right?

  - When patches can be considered for the bleeding-edge?

  - When patches can be considered moving from bleeding-edge to linux-next?

(the questions above are for the thermal tree).

Thanks

   -- Daniel

[1] 
https://lore.kernel.org/all/CAJZ5v0gY-Lhgf_1Kfg6P5O8s+YMkP4TxggxyS=LU9jVgJikAkg@mail.gmail.com/


>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your tree
>>> is submitted for merging.  You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any particularly
>>> complex conflicts.
>> Actually, the resolution I needed was this:
>>
>> diff --cc drivers/thermal/intel/x86_pkg_temp_thermal.c
>> index 9e08d8c8f5fb,494f25250c2d..24c7774cc4a9
>> --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
>> +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
>> @@@ -107,56 -108,37 +108,17 @@@ static struct zone_device *pkg_temp_the
>>    static int sys_get_curr_temp(struct thermal_zone_device *tzd, int 
>> *temp)
>>    {
>>        struct zone_device *zonedev = tzd->devdata;
>>   -    u32 eax, edx;
>>   +    int val;
>>   -    rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_STATUS,
>>   -            &eax, &edx);
>>   -    if (eax & 0x80000000) {
>>   -        *temp = zonedev->tj_max - ((eax >> 16) & 0x7f) * 1000;
>>   -        pr_debug("sys_get_curr_temp %d\n", *temp);
>>   -        return 0;
>>   -    }
>>   -    return -EINVAL;
>>   +    val = intel_tcc_get_temp(zonedev->cpu, true);
>>   +    if (val < 0)
>>   +        return val;
>>   +
>>   +    *temp = val * 1000;
>>   +    pr_debug("sys_get_curr_temp %d\n", *temp);
>>   +    return 0;
>>    }
>> - static int sys_get_trip_temp(struct thermal_zone_device *tzd,
>> -                  int trip, int *temp)
>> - {
>> -     struct zone_device *zonedev = tzd->devdata;
>> -     unsigned long thres_reg_value;
>> -     u32 mask, shift, eax, edx;
>> -     int tj_max, ret;
>> -
>> -     if (trip >= MAX_NUMBER_OF_TRIPS)
>> -         return -EINVAL;
>> -
>> -     if (trip) {
>> -         mask = THERM_MASK_THRESHOLD1;
>> -         shift = THERM_SHIFT_THRESHOLD1;
>> -     } else {
>> -         mask = THERM_MASK_THRESHOLD0;
>> -         shift = THERM_SHIFT_THRESHOLD0;
>> -     }
>> -
>> -     tj_max = intel_tcc_get_tjmax(zonedev->cpu);
>> -     if (tj_max < 0)
>> -         return tj_max;
>> -     tj_max *= 1000;
>> -
>> -     ret = rdmsr_on_cpu(zonedev->cpu, MSR_IA32_PACKAGE_THERM_INTERRUPT,
>> -                &eax, &edx);
>> -     if (ret < 0)
>> -         return ret;
>> -
>> -     thres_reg_value = (eax & mask) >> shift;
>> -     if (thres_reg_value)
>> -         *temp = tj_max - thres_reg_value * 1000;
>> -     else
>> -         *temp = THERMAL_TEMP_INVALID;
>> -     pr_debug("sys_get_trip_temp %d\n", *temp);
>> -
>> -     return 0;
>> - }
>> -
>>    static int
>>    sys_set_trip_temp(struct thermal_zone_device *tzd, int trip, int temp)
>>    {
>> @@@ -330,18 -340,25 +325,25 @@@ static int pkg_temp_thermal_device_add(
>>        thres_count = clamp_val(thres_count, 0, MAX_NUMBER_OF_TRIPS);
>> -     err = intel_tcc_get_tjmax(cpu);
>> -     if (err < 0)
>>   -    err = get_tj_max(cpu, &tj_max);
>>   -    if (err)
>> --        return err;
>> ++    tj_max = intel_tcc_get_tjmax(cpu);
>> ++    if (tj_max < 0)
>> ++        return tj_max;
>> ++    tj_max *= 1000;
>>        zonedev = kzalloc(sizeof(*zonedev), GFP_KERNEL);
>>        if (!zonedev)
>>            return -ENOMEM;
>> +     zonedev->trips = pkg_temp_thermal_trips_init(cpu, tj_max, 
>> thres_count);
>> +     if (IS_ERR(zonedev->trips)) {
>> +         err = PTR_ERR(zonedev->trips);
>> +         goto out_kfree_zonedev;
>> +     }
>> +
>>        INIT_DELAYED_WORK(&zonedev->work, 
>> pkg_temp_thermal_threshold_work_fn);
>>        zonedev->cpu = cpu;
>> -     zonedev->tzone = thermal_zone_device_register("x86_pkg_temp",
>> -             thres_count,
>>   -    zonedev->tj_max = tj_max;
>> +     zonedev->tzone = 
>> thermal_zone_device_register_with_trips("x86_pkg_temp",
>> +             zonedev->trips, thres_count,
>>                (thres_count == MAX_NUMBER_OF_TRIPS) ? 0x03 : 0x01,
>>                zonedev, &tzone_ops, &pkg_temp_tz_params, 0, 0);
>>        if (IS_ERR(zonedev->tzone)) {
>>

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2023-01-05 15:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 23:10 linux-next: manual merge of the thermal tree with the pm tree Stephen Rothwell
2023-01-04 23:35 ` Stephen Rothwell
2023-01-05 14:27   ` Wysocki, Rafael J
2023-01-05 15:30     ` Daniel Lezcano [this message]
2023-01-05 20:13       ` Wysocki, Rafael J
  -- strict thread matches above, loose matches on Subject: below --
2024-01-01 23:09 Stephen Rothwell
2023-04-06  0:32 Stephen Rothwell
2023-01-24 22:45 Stephen Rothwell
2023-01-25 11:57 ` Wysocki, Rafael J
2023-01-24 22:39 Stephen Rothwell
2023-01-25 11:57 ` Wysocki, Rafael J
2023-01-04 23:03 Stephen Rothwell
2022-11-17  1:29 Stephen Rothwell
2022-11-17 16:18 ` Rafael J. Wysocki
2022-11-27 23:22 ` Stephen Rothwell
2022-11-28 12:51   ` Rafael J. Wysocki
2022-11-28 13:22     ` Daniel Lezcano
2022-11-28 13:48       ` Bagas Sanjaya
2022-11-28 13:54         ` Rafael J. Wysocki
2022-11-28 13:56         ` Daniel Lezcano
2022-11-29 14:32           ` Geert Uytterhoeven
2014-10-10  1:10 Stephen Rothwell
2014-10-10  8:40 ` Zhang Rui
2014-01-06  3:14 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea9167d4-0978-fc4b-755f-8df09fc7360e@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=daniel.lezcano@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).