We have a 2D chip on board with our silicon. It too had a driver in kernel space and a queue in user space that allowed us to post jobs to it like Blit/Fill etc. We run DirectFB on the platform and we too needed to get Physical addresses etc. In the end what we did was use Linux FB device to allocate our memory. We allocate more than we need in the FB device when it is created. The Double buffered FB comes first and what is left over we use as scratch memory. This allows us to create surfaces etc in this 'scratch' memory. When we need the physical address we use the offset from FB base in virtual memory (user space) and add that the physical base address of FB device. This then allows us to post the job to the 2D hardware. This approach has worked on 2 different chips now. Maybe this might help for you? Daniel Laird -----Original Message----- From: linux-embedded-owner@xxxxxxxxxxxxxxx [mailto:linux-embedded-owner@xxxxxxxxxxxxxxx] On Behalf Of Tom Cooksey Sent: 2008 Oct 13 07:33 To: Robert Schwebel Cc: linux-embedded mailing list Subject: Re: Getting physical addresses of mmap'd pages from userspace On Friday 10 October 2008 21:12:13 Robert Schwebel wrote: > On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote: > > Is there any way to get the physical address of mlock()'d memory from > > userspace? > > What do you want to do? I don't really see a reason to do such strange > things any more these days. It's quite an annoying problem actually. Basically I have binary drivers for Imagination Technologies's PowerVR graphics drivers. We have tried very hard to get the source code for these drivers and have failed. Eventually ImgTec allowed us to sign an NDA to get the headers for one of their user-space libraries. This library allows us to direct the graphics hardware to render to a specific physical memory region. The problem is that there's no way to find out what the physical addresses are which we need pass to the graphics hardware (via the user-space library). Allthough the library allows us to allocate emory, what I want to do is then blit that memory in a different process. So a client process renders into an off-screen buffer and the server process blits that buffer to the framebuffer. By allowing the server process to do the blit rather than the client process, we can get semi-transparent GL windows. The synchronisation we can do, it's the memory allocation I'm struggling with. If we ask the library to allocate the memory for us, we don't get the physical address to pass to the server process. Instead, we need to allocate memory ourselves and pass the physical address to the library. But like I say, I can't find a way to get the physical address from the kernel. I realise getting round closed-source drivers isn't exactly encoraged, but sadly, we really have no choice. :-( Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
