On Sat, Mar 22, 2014 at 09:06:00PM +, Chris Wilson wrote:
> On Sat, Mar 22, 2014 at 11:42:17AM -0700, Ben Widawsky wrote:
> > On Thu, Mar 20, 2014 at 07:24:38AM +, Chris Wilson wrote:
> > > On Wed, Mar 19, 2014 at 06:31:14PM -0700, Ben Widawsky wrote:
> > > > Programming it outside of the r
On Sat, Mar 22, 2014 at 11:42:17AM -0700, Ben Widawsky wrote:
> On Thu, Mar 20, 2014 at 07:24:38AM +, Chris Wilson wrote:
> > On Wed, Mar 19, 2014 at 06:31:14PM -0700, Ben Widawsky wrote:
> > > Programming it outside of the rp0-rp1 range is considered a programming
> > > error. Since we do not
On Thu, Mar 20, 2014 at 07:24:38AM +, Chris Wilson wrote:
> On Wed, Mar 19, 2014 at 06:31:14PM -0700, Ben Widawsky wrote:
> > Programming it outside of the rp0-rp1 range is considered a programming
> > error. Since we do not know that the previous value would actually be in
> > the range, progr
On Wed, Mar 19, 2014 at 06:31:14PM -0700, Ben Widawsky wrote:
> Programming it outside of the rp0-rp1 range is considered a programming
> error. Since we do not know that the previous value would actually be in
> the range, program something we've read from the hardware, and therefore
> know will w
Programming it outside of the rp0-rp1 range is considered a programming
error. Since we do not know that the previous value would actually be in
the range, program something we've read from the hardware, and therefore
know will work.
This is potentially an issue for platforms whose ranges are outs
