stable: 2124b72e6283c4e84a55e71077fee91793f4c801 need backport

Kamal Mostafa kamal at canonical.com
Mon Oct 28 17:52:29 UTC 2013


> > On Wed, 2013-10-16 at 14:15 +0800, Shuduo Sang wrote:
> >> I hope at least 3.8 stable tree would like to backport this patch
> >> since the patch be merged into v3.9-rc5 and v3.8 is used widely. Loop
> >> kernel-team at lists.ubuntu.com.

> On Thu, Oct 17, 2013 at 11:58 PM, Kamal Mostafa <kamal at canonical.com>
> wrote:
> >
> >  but that commit says:
> >
> >     This fixes problems caused by the following commit:
> >       commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898
> >       Author: Daniel Vetter <daniel.vetter at ffwll.ch>
> >       Date:   Tue Jan 29 16:35:20 2013 -0200
> >            drm/i915: dynamic Haswell display power well support
> >
> > But 3.8-stable doesn't include d6dd9eb.   Is 2124b72 actually necessary
> > in 3.8?  (Or at least, would it actually be useful?)

On Mon, 2013-10-21 at 20:05 +0800, Shuduo Sang wrote:
> I think so. Thanks.

After looking at it more closely, I'm pretty sure that this commit
(2124b72) just isn't relevant for 3.8-stable ...

In 3.8, the i915 power wells simply all get enabled by
intel_init_power_wells() and nothing ever tries to disable them.  This
commit commit tries to modify the routine intel_set_power_well() which
takes a boolean 'enable' param to enable or disable a power well -- but
that routine doesn't exist in 3.8 (it was added to i915 later).

So, if I understand the commit description and the code correctly, 3.8
doesn't doesn't need and couldn't make use of a "disable_power_well"
override boot parameter.

If you still think it would be useful for 3.8-stable, please explain why
and supply a backport of the patch.

Thanks,

 -Kamal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20131028/c0e3d700/attachment.sig>


More information about the kernel-team mailing list