On 1/9/2019 03:51, Chris Wilson wrote:
Quoting Mika Kuoppala (2019-01-09 09:23:53)
I should have been more specific. My concern was on documenting
the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
I think Mik
Quoting Mika Kuoppala (2019-01-09 09:23:53)
> I should have been more specific. My concern was on documenting
> the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
-Chris
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-08 16:23:18)
>> > @@ -3965,7 +4014,7 @@ void intel_power_domains_init_hw(struct
>> > drm_i915_private *dev_priv, bool resume)
>> > void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
>> > {
>> > /* Keep the power well
Quoting Mika Kuoppala (2019-01-08 16:23:18)
> > @@ -3965,7 +4014,7 @@ void intel_power_domains_init_hw(struct
> > drm_i915_private *dev_priv, bool resume)
> > void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
> > {
> > /* Keep the power well enabled, but cancel its rpm wa
Chris Wilson writes:
> The majority of runtime-pm operations are bounded and scoped within a
> function; these are easy to verify that the wakeref are handled
> correctly. We can employ the compiler to help us, and reduce the number
> of wakerefs tracked when debugging, by passing around cookies
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
