All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Zanoni <przanoni@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/6] drm/i915/crt: don't set HOTPLUG bits on !PCH
Date: Fri, 12 Oct 2012 14:17:11 -0300	[thread overview]
Message-ID: <CA+gsUGQm3S=eTS6f7+M8F+KG7fhuq6AimD2ZwHJ-3LcEqqt98w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uGq9oXsZQQFZxardAwpOxHsu+D=DvEUrD70HLcinvQwBQ@mail.gmail.com>

2012/10/12 Daniel Vetter <daniel.vetter@ffwll.ch>:
> On Fri, Oct 12, 2012 at 4:47 AM, Paulo Zanoni <przanoni@gmail.com> wrote:
>> 2012/10/11 Daniel Vetter <daniel.vetter@ffwll.ch>:
>>> ... since they don't apply to pre-pch platforms and could actually be
>>> harmful.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>
>> Ok, so I checked the specs and yes, these bit definitions don't exist.
>> The problem here is that instead of "must-be-zero", the spec says
>> "Reserved. Software must preserve the contents of these bits" for bits
>> 29:16 (and also some others). So maybe by setting everything to 0
>> instead of enabling bits 17, 18, 20-23 we could actually be breaking
>> things? Either way, both the old and new code don't follow the
>> specification.
>
> Indeed, I've overlooked the "must be preserved" wording, and it goes
> back to gen2 when the ADPA reg was added. So I've fired up all my
> gen2/gen3 machines, and they have all zeros in these registers.

Ok, so please do a final test: try to write something to those
"must-be-preserved" bits and check if the values stay or not. If after
writing 1 to bits 17-18, 20-23 you read 0, then you have my
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>. I still do plan
to test the 6 patches of the series on hsw later btw.

> And we
> never write anything in there. I suspect this is simply a hint from
> the Bspec authors to driver writes that they might eventually use
> these reserved bits in future hw platforms. And if the driver
> preserves the bit settings, it will automatically work. I think MBZ is
> mostly used for bit ranges that have been used once, but are no longer
> implemented (e.g. bits 12:13 do something in gen2/3 but not on later
> hw gens).
>
>> Maybe on non-pch-split we could try to read ADPA and erase all the
>> bits except the "must-be-preserved" ones?
>
> See above, I think we can clear them - at least all my old hw seems to
> work perfectly well with all these bits being zero.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Paulo Zanoni

  reply	other threads:[~2012-10-12 17:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11 18:08 [PATCH 0/6] reduce register save/restoring accross suspend/resume Daniel Vetter
2012-10-11 18:08 ` [PATCH 1/6] drm/i915/crt: don't set HOTPLUG bits on !PCH Daniel Vetter
2012-10-12  2:47   ` Paulo Zanoni
2012-10-12  8:45     ` Daniel Vetter
2012-10-12 17:17       ` Paulo Zanoni [this message]
2012-10-12 17:26         ` Daniel Vetter
2012-10-17 21:31           ` Paulo Zanoni
2012-10-11 18:08 ` [PATCH 2/6] drm/i915/crt: explicitly set up HOTPLUG_BITS on resume Daniel Vetter
2012-10-17 21:42   ` Paulo Zanoni
2012-10-11 18:08 ` [PATCH 3/6] drm/i915: don't save/restor ADPA for kms Daniel Vetter
2012-10-17 21:49   ` Paulo Zanoni
2012-10-18 12:34     ` Daniel Vetter
2012-10-11 18:08 ` [PATCH 4/6] drm/i915: don't save/restore DP regs " Daniel Vetter
2012-10-11 18:08 ` [PATCH 5/6] drm/i915: don't save/restore irq " Daniel Vetter
2012-10-11 18:08 ` [PATCH 6/6] drm/i915: don't save/restore HWS_PGA reg " Daniel Vetter
2012-10-17  9:32   ` [PATCH 1/3] drm/i915: don't save/restore DP regs " Daniel Vetter
2012-10-17  9:32     ` [PATCH 2/3] drm/i915: don't save/restore irq " Daniel Vetter
2012-10-17  9:32     ` [PATCH 3/3] drm/i915: don't save/restore HWS_PGA reg " Daniel Vetter
2012-10-17 19:52     ` [PATCH 1/3] drm/i915: don't save/restore DP regs " Paulo Zanoni
2012-10-17 20:39       ` Daniel Vetter

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='CA+gsUGQm3S=eTS6f7+M8F+KG7fhuq6AimD2ZwHJ-3LcEqqt98w@mail.gmail.com' \
    --to=przanoni@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.