On Mar 24, 2010, at 8:04 AM, Masao Uebayashi wrote:
> It's in bus_space(9) because it's API for device drivers. Its behavior needs
> UVM's help, of course.
Also, because bus-specific code needs to map the bus_space_tag_t + the
bus_addr_t into a system physical address.
-- thorpej
Hi,
On Tue, Apr 6, 2010 at 10:48 AM, David Young wrote:
> You haven't mmap()'d the entire range. Shouldn't that be:
>
> const bus_addr_t busp = addr;
> const bus_addr_t busq = addr + size;
> off_t i;
> const paddr_t physp = bus_space_mm
Hi,
On Tue, Apr 6, 2010 at 10:41 AM, David Young wrote:
> I don't think that we should register device memory as part of "usual"
> memory, if that means putting the device memory into the same pool as
> the rest. The device memory may have different properties than the
> rest.
>
> Properties of
On Thu, Mar 25, 2010 at 11:43:52AM +0900, Masao Uebayashi wrote:
> On Wed, Mar 24, 2010 at 01:07:15PM -0500, David Young wrote:
> > Can it be implemented like this?
> >
> > void *
> > bus_space_physload(bus_space_tag_t bst, bus_addr_t addr, bus_size_t size,
> > vm_prot_t prot, int flags)
> > {
On Thu, Mar 25, 2010 at 02:39:18PM +0900, Masao Uebayashi wrote:
> Another question is, do we want to register device memory as part of usual
> memory?
I don't think that we should register device memory as part of "usual"
memory, if that means putting the device memory into the same pool as
the r
(I'll learn TTE then reply again.)
for everyone:
TTE is sparc64 for PTE. "translation table entry". defined in
sparc64/include/pte.h :-)
Hi,
On Fri, Mar 26, 2010 at 04:25:19PM +, Eduardo Horvath wrote:
> On Fri, 26 Mar 2010, Masao Uebayashi wrote:
>
> > This is the list of updated functions:
> >
> > /* register device memory as part of system memory */
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t add
On Fri, 26 Mar 2010, Masao Uebayashi wrote:
> This is the list of updated functions:
>
> /* register device memory as part of system memory */
> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> bus_size_t size);
> void bus_space_physunload(void *physs
This is the list of updated functions:
/* register device memory as part of system memory */
void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
bus_size_t size);
void bus_space_physunload(void *physseg);
/* register device region as user-m
Another question is, do we want to register device memory as part of usual
memory? For example OpenBSD seems to be trying to use framebuffer's memory
for mbufs.
It's possible if we prepare the relevant interface and call uvm_page_physload(9)
instead of uvm_page_physload_device(9). Maybe worth pr
On Thu, Mar 25, 2010 at 11:43:52AM +0900, Masao Uebayashi wrote:
> void *
> bus_space_physload(bus_space_tag_t t, bus_addr_t addr, bus_size_t size,
> int prot, int flags)
> {
> const bus_addr_t busp = addr;
> const bus_addr_t busq = addr + siz
onst paddr_t physp = bus_space_mmap(t, busp, 0, prot, flags);
const paddr_t physq = bus_space_mmap(t, busq, 0, prot, flags);
/* return struct vm_physseg * as a cookie */
return uvm_page_physload_device(
physp, /* physical st
On Wed, Mar 24, 2010 at 10:35:20AM -0700, Matt Thomas wrote:
> > bus_space_physload(9) is to replace bus_space_mmap(9).
>
> Then where is bus_space_unphysload? You have to be able to undo it when
> you start talking about devices.
You're right, bus_space_unphysload(9) (
On Wed, Mar 24, 2010 at 05:09:23PM +0900, Masao Uebayashi wrote:
> On Wed, Mar 24, 2010 at 03:06:08PM +0900, Masao Uebayashi wrote:
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size);
>
> This function should take the same arguments as bus_space_m
On Mar 24, 2010, at 8:07 AM, Masao Uebayashi wrote:
> On Wed, Mar 24, 2010 at 09:15:53PM +0900, Izumi Tsutsui wrote:
>>> I'd like to propose a new function in bus_space(9) API,
>>> bus_space_physload(9).
>>>
>>> void *bus_space_phy
On Wed, Mar 24, 2010 at 09:15:53PM +0900, Izumi Tsutsui wrote:
> > I'd like to propose a new function in bus_space(9) API,
> > bus_space_physload(9).
> >
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size);
>
ion is write-only, its device driver should register
the region as write-only. If not, don't need to do so.
The other point is, bus_space_physload(9) provides a path to tell device's
memory access characteristic to VM. bus_space_physload(9) will replace
bus_space_mmap(9), and returns a cooki
> I'd like to propose a new function in bus_space(9) API, bus_space_physload(9).
>
> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> bus_size_t size);
>
> This function is provided for device drivers to register its linear memory
>
"int prot" is the device's characteristic. Audio mic devices would use
VM_PROT_READ. Framebuffers would use VM_PROT_WRITE. We need to introduce
BUS_SPACE_PROT_* symbols too.
i don't see why you think that reads from fb devices never occur.
i'm also unsure how audio devices matter f
i don't understand why you think framebuffers are mapped uncacheable.
your proposal appears to provide no benefit for anything currently
supported, and i'm not sure why bus_space_physload() needs to be
in the bus_space domain, rather than plain UVM. your XIP use-case
may be valid -- i haven't co
On Wed, Mar 24, 2010 at 03:06:08PM +0900, Masao Uebayashi wrote:
> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> bus_size_t size);
This function should take the same arguments as bus_space_mmap(9). I've
added "int prot" and "int flags":
void *bus_spac
I'd like to propose a new function in bus_space(9) API, bus_space_physload(9).
void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
bus_size_t size);
This function is provided for device drivers to register its linear memory
region to be managed by VM. When
22 matches
Mail list logo
