On Thu, Mar 20, 2014 at 5:28 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> > I wasn't sure either, but I thought since we didn't do anything special >> > for BBADDR, to leave ACTHD alone. >> > >> > I wonder if it would help splitting it up, having to count 8 extra >> > leading zeros is going to be a nightmare (especially as the decoder >> > doesn't pad it right either...) >> > >> > For reading, I think I would prefer >> > err_printf(m, " ACTHD: 0x%016llx [0x%08x %08x]\n", >> > ring->acthd, (u32)(ring->acthd>>32), (u32)(ring->acthd)); >> > >> > or maybe just >> > err_printf(m, " ACTHD: 0x%08x %08x\n", >> > (u32)(ring->acthd>>32), (u32)(ring->acthd)); >> >> I expect this to lead to a day-long wtf session once we have 64b ppgtt >> enabled and a leaking X hung ;-) I use g* a lot in vim when reading error >> states, so dropping information is dangerous. > > I'm not following, where is the information loss? If you haven't already > guessed, we are seeing ACTHD above 4GiB already. Utter failure to read your diff. I agree that some form of split would look nice. /me hides in shame -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
