Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 3:38 PM, Ulf Hansson wrote: > [...] > So I guess I'll simply evaluate dev_pm_qos_read_value(dev) if subsys_data or subsys_data->domain_data is not there. >>> >>> Yes. >>> >>> However, if it returns -1, what value should you pick? 0? >>

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 3:38 PM, Ulf Hansson wrote: > [...] > So I guess I'll simply evaluate dev_pm_qos_read_value(dev) if subsys_data or subsys_data->domain_data is not there. >>> >>> Yes. >>> >>> However, if it returns -1, what value should you pick? 0? >> >> Without the second

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

[...] >>> >>> So I guess I'll simply evaluate dev_pm_qos_read_value(dev) if >>> subsys_data or subsys_data->domain_data is not there. >> >> Yes. >> >> However, if it returns -1, what value should you pick? 0? > > Without the second patch, -1 will just mean "no suspend", so the > parent cannot be

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

[...] >>> >>> So I guess I'll simply evaluate dev_pm_qos_read_value(dev) if >>> subsys_data or subsys_data->domain_data is not there. >> >> Yes. >> >> However, if it returns -1, what value should you pick? 0? > > Without the second patch, -1 will just mean "no suspend", so the > parent cannot be

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 1:44 PM, Ulf Hansson wrote: > [...] > static int dev_update_qos_constraint(struct device *dev, void *data) { s64 *constraint_ns_p = data; - s32 constraint_ns = -1; - - if (dev->power.subsys_data &&

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 1:44 PM, Ulf Hansson wrote: > [...] > static int dev_update_qos_constraint(struct device *dev, void *data) { s64 *constraint_ns_p = data; - s32 constraint_ns = -1; - - if (dev->power.subsys_data &&

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

[...] >>> static int dev_update_qos_constraint(struct device *dev, void *data) >>> { >>> s64 *constraint_ns_p = data; >>> - s32 constraint_ns = -1; >>> - >>> - if (dev->power.subsys_data && dev->power.subsys_data->domain_data) >>> - constraint_ns = >>>

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

[...] >>> static int dev_update_qos_constraint(struct device *dev, void *data) >>> { >>> s64 *constraint_ns_p = data; >>> - s32 constraint_ns = -1; >>> - >>> - if (dev->power.subsys_data && dev->power.subsys_data->domain_data) >>> - constraint_ns = >>>

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 1:10 PM, Ulf Hansson wrote: > On 3 November 2017 at 12:47, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The genpd governor currently uses negative PM QoS values to indicate >> the "no

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Mon, Nov 6, 2017 at 1:10 PM, Ulf Hansson wrote: > On 3 November 2017 at 12:47, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The genpd governor currently uses negative PM QoS values to indicate >> the "no suspend" condition and 0 as "no restriction", but it doesn't >> use them

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 3 November 2017 at 12:47, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently.

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 3 November 2017 at 12:47, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it tries to refresh QoS values for >

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-04 at 12:24:15 +0100, Rafael J. Wysocki wrote: > On Sat, Nov 4, 2017 at 3:34 AM, Ramesh Thomas wrote: > > On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> The genpd governor currently

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-04 at 12:24:15 +0100, Rafael J. Wysocki wrote: > On Sat, Nov 4, 2017 at 3:34 AM, Ramesh Thomas wrote: > > On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> The genpd governor currently uses negative PM QoS values to indicate > >> the "no

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Sat, Nov 4, 2017 at 3:34 AM, Ramesh Thomas wrote: > On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The genpd governor currently uses negative PM QoS values to indicate >> the "no suspend"

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On Sat, Nov 4, 2017 at 3:34 AM, Ramesh Thomas wrote: > On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The genpd governor currently uses negative PM QoS values to indicate >> the "no suspend" condition and 0 as "no restriction", but it doesn't >> use

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it tries to refresh QoS values