Hi,
On 10/19/20 8:49 PM, Mark Pearson wrote:
> Hi
>
>> On 19/10/2020 14:43, Hans de Goede wrote:
>> Hi,
>>
>> On 10/18/20 2:31 PM, Rafael J. Wysocki wrote:
>>> On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
Hi,
On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
> On
On Mon, Oct 19, 2020 at 8:43 PM Hans de Goede wrote:
>
> Hi,
>
> On 10/18/20 2:31 PM, Rafael J. Wysocki wrote:
> > On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
> >>> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede
Hi
> On 19/10/2020 14:43, Hans de Goede wrote:
Hi,
On 10/18/20 2:31 PM, Rafael J. Wysocki wrote:
On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
Hi,
On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote:
Hi,
On 10/14/20 5:42 PM,
Hi,
On 10/18/20 2:31 PM, Rafael J. Wysocki wrote:
> On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
>>> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote:
>>> one from both threads to the Cc>
Hi,
On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote:
>
> Hi,
>
> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
> > On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote:
> >>
> >> >> one from both threads to the Cc>
> >>
> >> Hi,
> >>
> >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> >>> On
Hi,
On 10/16/20 4:51 PM, Rafael J. Wysocki wrote:
> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote:
>>
>> > from both threads to the Cc>
>>
>> Hi,
>>
>> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
>>> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote:
On 10/14/20 3:33 PM, Rafael
t; > ; Darren Hart ; Andy
> > Shevchenko ; Mark Gross ;
> > Benjamin Berg ; linux-a...@vger.kernel.org
> > ; platform-driver-...@vger.kernel.org
> >
> > *Subject:* [External] Re: [RFC] Documentation: Add documentation for new
> > performance_profile sysfs cl
On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote:
>
> from both threads to the Cc>
>
> Hi,
>
> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote:
> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:
>
>
>
> >>> First, a common place to
ion for new
performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add
the DTPM framework)
Hi,
In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto:
Hi,
On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede
Hi,
In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto:
> from both threads to the Cc>
>
> Hi,
>
> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote:
> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:
>
>
> >>> First,
Hi,
On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote:
>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:
>>> First, a common place to register a DPTF system profile seems to be
>>> needed and, as I said above, I wouldn't expect more than one
> As far as I know, the profiles affect the thermal behavior like "how long to
> wait before starting the fan and at what temperature" or "how fast to run the
> fan with the current cpu load and temperature".
>
> The only way that firmware uses to "control" performance should be the odvp0
> DPTF
;>>>>
> > >>>>> This seemed to me like an implementation detail (eg. the same
> > >>>>> metadata
> > >>>>> is being exported, but in a different way), and I don't feel
> > >>>>> strongly
> > >
wrapping them up into a certain
> >>> "translation" layer allowing user space to use a unified interface (I
> >>> think that is what everybody wants) and the other boils down to how
> >>> the unified interface between the kernel and user space will look
>
ssumes we have some sort of DPTF support
such as mjg59's reverse engineered support) but the profile-names
under Windows are: "Performance", "HP recommended", "Cool" and
"Quiet". If you read the discussion from the
"[RFC] Documentation: Add documenta
nk that something line /sys/power/profile allowing
> > drivers (and other kernel entities) to register callbacks might work
> > (as stated in my last reply to Hans).
>
> Note to others reading along I pointed to this thread in this thread:
> https://lore.kernel.org/linux-pm/20201006122
ch as mjg59's reverse engineered support) but the profile-names
under Windows are: "Performance", "HP recommended", "Cool" and
"Quiet". If you read the discussion from the
"[RFC] Documentation: Add documentation for new performance_profile sysfs class"
threa
On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario
wrote:
>
> > On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote:
> > >
> > > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario wrote:
> > > > > > On modern systems CPU/GPU/... performance is often dynamically
> > > > > >
Hi,
On 10/5/20 2:58 PM, Limonciello, Mario wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some automatic-mechanism (which may
very well live
Hi,
On 10/5/20 3:13 PM, Benjamin Berg wrote:
Hi,
seems reasonable to me. Quite simple, but likely good enough as we are
sticking to only use well known names.
Just found a small typo.
Benjamin
On Sat, 2020-10-03 at 15:19 +0200, Hans de Goede wrote:
On modern systems CPU/GPU/... performance
Hi,
On 10/5/20 12:29 AM, Elia Devito wrote:
Hi Hans,
On 2020-10-03 9:19 a.m., Hans de Goede wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some
> On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote:
> >
> > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario wrote:
> > > > > On modern systems CPU/GPU/... performance is often dynamically
> > > > > configurable
> > > > > in the form of e.g. variable clock-speeds and TPD. The
> >
On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote:
>
> > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario wrote:
> > > > On modern systems CPU/GPU/... performance is often dynamically
> > > > configurable
> > > > in the form of e.g. variable clock-speeds and TPD. The
> > > >
> On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario wrote:
> > > On modern systems CPU/GPU/... performance is often dynamically
> > > configurable
> > > in the form of e.g. variable clock-speeds and TPD. The performance
> > > is often
> > > automatically adjusted to the load by some
On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario wrote:
> > On modern systems CPU/GPU/... performance is often dynamically
> > configurable
> > in the form of e.g. variable clock-speeds and TPD. The performance
> > is often
> > automatically adjusted to the load by some automatic-mechanism
>
On 2020-10-05 12:56 p.m., Limonciello, Mario wrote:
When implemented for the two vendors mentioned here, it would be using a
proprietary "firmware API" implemented by those two vendors. For example
write
arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to
> On 2020-10-05 12:11 p.m., Limonciello, Mario wrote:
> >>
> >> Excuse my ignorance, but I don't really see why this interface would be
> tied
> >> to
> >> ACPI devices? Why is it not possible to write a driver that implements this
> >> interface
> >> and directly modifies device registers? Am I
On 2020-10-05 12:11 p.m., Limonciello, Mario wrote:
Excuse my ignorance, but I don't really see why this interface would be tied
to
ACPI devices? Why is it not possible to write a driver that implements this
interface
and directly modifies device registers? Am I missing something obvious
> 2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta:
> > > On modern systems CPU/GPU/... performance is often dynamically
> configurable
> > > in the form of e.g. variable clock-speeds and TPD. The performance is
> often
> > > automatically adjusted to the load by some
Hi
2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta:
> > On modern systems CPU/GPU/... performance is often dynamically configurable
> > in the form of e.g. variable clock-speeds and TPD. The performance is often
> > automatically adjusted to the load by some
> On modern systems CPU/GPU/... performance is often dynamically configurable
> in the form of e.g. variable clock-speeds and TPD. The performance is often
> automatically adjusted to the load by some automatic-mechanism (which may
> very well live outside the kernel).
>
> These auto
Hi,
seems reasonable to me. Quite simple, but likely good enough as we are
sticking to only use well known names.
Just found a small typo.
Benjamin
On Sat, 2020-10-03 at 15:19 +0200, Hans de Goede wrote:
> On modern systems CPU/GPU/... performance is often dynamically configurable
> in the
Hi Hans,
On 2020-10-03 9:19 a.m., Hans de Goede wrote:
> On modern systems CPU/GPU/... performance is often dynamically configurable
> in the form of e.g. variable clock-speeds and TPD. The performance is often
> automatically adjusted to the load by some automatic-mechanism (which may
> very
Hi Hans,
On 2020-10-03 9:19 a.m., Hans de Goede wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some automatic-mechanism (which may
very well live
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some automatic-mechanism (which may
very well live outside the kernel).
These auto performance-adjustment
35 matches
Mail list logo
