[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Wed, Nov 17, 2010 at 04:07:04PM +0000, Eduardo Horvath wrote:
> On Thu, 18 Nov 2010, Masao Uebayashi wrote:
> > On Thu, Nov 18, 2010 at 12:30:52AM +0900, Izumi Tsutsui wrote:
> > > > What I ended up is pmap_mmap(9), which is exactly mmmmap(), but
> > > > made public.
> > > >
> > > > Does this sound right?
> > >
> > > Probably it's time to remove "mmap cookie" type as pmap(9) says
> > > since we have separate paddr_t and vaddr_t?
> > I'm all for rethinking the design from ground.
> Yes, this needs to be carefully considered. The "mmap cookie" is not
> necessarily a PA. On sparc64 it contains additional information that pmap
> needs to know to successfully set up a correct TLB entry. And some
> machines, even modern ones, may not have linear physical address spaces.
Understood. Like the ECC bits you mentioned.
> > And my answer to this question is, bus_space_physload(9).
> What's that do and how is that relevent to managed memory?
Managed memory has vm_pages. Device driver looks up the vm_physseg
(and offset) from vm_pages (usually bus_dma(9) ones). My point
is, by allocating vm_physseg for devices too, we can equally return
physical page identities.
I think cdevs can be easily converted, because there's a dedicated
udv_fault(), where we can easily pass the "mmap cookie" equivalent
(XIP on kernel .data is much different, but this is another story.)
> > cdev_mmap(9) will return "struct vm_physseg *" + "off_t", instead
> > of "mmap cookie". The vm_physseg is either on device's MMIO page
> > or RAM. I hope this will be understood. Otherwise I have to do
> > so many hacks to achieve XIP... :(
> I think that will break existing implementations.
Yes, it needs a new name, like cdev_page(9).
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |