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
