On Thu, 1 Mar 2007 21:33:16 +0200 Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> On Thursday 01 March 2007 20:11, Aapo Tahkola wrote: > > On Thu, 1 Mar 2007 17:46:12 +0200 > > > > Panagiotis Papadakos <[EMAIL PROTECTED]> wrote: > > > Diving more into the code, I also found weird how the scratch cmd > > > packet is build in radeon_mm_use, in radeon_mm.c. I think it > > > should be like in the attached patch. > > > > This patch will break 64 bit systems. It only works on your system > > because drm cuts 32 bits off the pointer. > > This is what drm expects to see: > > 64_bit_pointer > > for every buffer > > 32_bit_index > > > > Thus, rmesa->rmm->u_list[id].age is at > > 64_bit_pointer[32_bit_index] . Since age and h_pending go in pairs, > > rmesa->rmm->u_list[id].h_pending is at 64_bit_pointer[32_bit_index > > + 1] . > > > > Hope this clears out things a bit. > Yep. I think you are right. > > Two questions though: > > 1) Should we increment h_pending, before memcpy to the buf? > (Is there any way that the drm reads the old value?) Doesn't matter as long as it is done before pushing it in r300_cmdbuf.c. > 2) Could you also see the attached patch, for the drm r300_scratch? > I think that the logic is wrong. Before the loop, you increment the > buf, 8 bytes, although you should already be reading age and > h_pending, since the outer while loop removes the head. > Somehow all the loop seems a bit weird to me. You are mixing up what comes from the command buffer and what kernel calculates itself. "buf_idx *= 2; /* 8 bytes per buf */" converts index of age and h_pending pairs into index that points to a .age in 32 bit buffer. In reality, buf_idx is always 0. Remember that ref_age_base + 1 equals &ref_age_base[1] . > > P.S. > Before applying this patch I was getting many messages like this one: > Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] pid=3538, > cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 > Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] ret = fffffffc > which I have not seen after applying this patch. Sure you didn't just turn off debug messages? See "Method to limit rendering latency" in driconf if you don't want to use irqs. > > Thanks for your time. > > > !DSPAM:45e727c3100221632612511! -- Aapo Tahkola ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
