[Intel-gfx] [PATCH 1/6] drm/i915/crt: don't set HOTPLUG bits on !PCH

Daniel Vetter daniel.vetter at ffwll.ch
Fri Oct 12 10:45:39 CEST 2012


On Fri, Oct 12, 2012 at 4:47 AM, Paulo Zanoni <przanoni at gmail.com> wrote:
> 2012/10/11 Daniel Vetter <daniel.vetter at ffwll.ch>:
>> ... since they don't apply to pre-pch platforms and could actually be
>> harmful.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter at 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. 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



More information about the Intel-gfx mailing list