All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilad Ben-Yossef <gilad@codefidence.com>
To: Tom Cooksey <thomas.cooksey@trolltech.com>
Cc: Robert Schwebel <r.schwebel@pengutronix.de>,
	linux-embedded mailing list <linux-embedded@vger.kernel.org>
Subject: Re: Getting physical addresses of mmap'd pages from userspace
Date: Mon, 13 Oct 2008 11:37:09 +0200	[thread overview]
Message-ID: <48F316C5.1070905@codefidence.com> (raw)
In-Reply-To: <200810130833.26399.thomas.cooksey@trolltech.com>

Tom Cooksey wrote:

> ...
>  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.
>
>   
You lost me on why you can't have the library allocate the memory - I 
understand the library needs the physical address to render into, but 
why does your server needs the physical address to blit to the frame 
buffer? I assume it access the frame buffer in host memory so needs the 
virtual address, not the physical one...

Anyways, ignoring that, it's pretty trivial to write  a character driver 
with an IOCTL that will get an mlocked virtual address of the processes, 
call virt_to_phys on it and return the result. Yes, it's an ugly as hell 
solution, but then again so is the problem (proprietary libraries etc.)

You do realize that the mlocked memory isn't contiguous in physical 
memory, right? unless your graphics engine has something like AGP GART 
or an IOMMU I think you might find that problematic.

Gilad


-- 
Gilad Ben-Yossef 
Chief Coffee Drinker

Codefidence Ltd.
The code is free, your time isn't.(TM)

Web:    http://codefidence.com
Email:  gilad@codefidence.com
Office: +972-8-9316883 ext. 201
Fax:    +972-8-9316885
Mobile: +972-52-8260388

	The Doctor: Don't worry, Reinette, just a nightmare. 
	Everyone has nightmares. Even monsters from under the 
	bed have nightmares, don't you, monster?
	Reinette: What do monsters have nightmares about?
	The Doctor: Me! 

  parent reply	other threads:[~2008-10-13  9:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-10 16:15 Getting physical addresses of mmap'd pages from userspace Tom Cooksey
2008-10-10 16:37 ` Bart Van Assche
2008-10-10 19:12 ` Robert Schwebel
2008-10-13  6:33   ` Tom Cooksey
2008-10-13  7:00     ` Robert Schwebel
2008-10-13  7:20       ` Tom Cooksey
2008-10-13  7:28       ` Thomas Petazzoni
2008-10-13  7:31         ` Robert Schwebel
2008-10-13 12:50       ` Bill Gatliff
2008-10-13 13:23         ` Robert Schwebel
2008-10-13 15:58           ` George G. Davis
2008-10-13 16:09             ` Robert Schwebel
2008-10-14  6:36               ` Tom Cooksey
2008-10-14 15:47                 ` Bill Gatliff
2008-10-15  7:06                   ` Tom Cooksey
2008-10-15  8:30                     ` James Chapman
2008-10-15 18:27                   ` Robert Schwebel
2008-10-15 18:29                     ` Bill Gatliff
2008-10-13  9:37     ` Gilad Ben-Yossef [this message]
     [not found]     ` <48F31155.6090603@codefidence.com>
2008-10-13  9:38       ` Tom Cooksey
2008-10-13 12:48     ` Bill Gatliff
2008-10-13 14:45       ` Tom Cooksey
2008-10-13 15:09         ` Daniel THOMPSON
2008-10-13 17:21           ` George G. Davis
2008-10-13 17:29     ` Chris
2008-10-14  6:46       ` Tom Cooksey
2008-10-14  7:31     ` Daniel J Laird
2008-10-14  9:03       ` Tom Cooksey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F316C5.1070905@codefidence.com \
    --to=gilad@codefidence.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=r.schwebel@pengutronix.de \
    --cc=thomas.cooksey@trolltech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.