From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/6] drm/i915/crt: don't set HOTPLUG bits on !PCH Date: Fri, 12 Oct 2012 10:45:39 +0200 Message-ID: References: <1349978908-7687-1-git-send-email-daniel.vetter@ffwll.ch> <1349978908-7687-2-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 118269E787 for ; Fri, 12 Oct 2012 01:45:39 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id dq11so1803274wgb.12 for ; Fri, 12 Oct 2012 01:45:39 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Paulo Zanoni Cc: Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Fri, Oct 12, 2012 at 4:47 AM, Paulo Zanoni wrote: > 2012/10/11 Daniel Vetter : >> ... since they don't apply to pre-pch platforms and could actually be >> harmful. >> >> Signed-off-by: Daniel Vetter > > 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. 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