I found one thing - in kernel, I've accessed the DSP memory space via
bus_space_read() and bus_space_write(), and in userland I've
referenced the memory space directly. Is that could be the cause of
this problem? If it is, then how could I use the mmaped area in
userland? Of couse I can't use bus_space_() in userland, can I?


On Wed, 9 Mar 2005 10:01:57 +0100, Jachym Holecek <freza@liberouter.org> wrote:
> Hi,
> 
> > [... Can't bus_space_mmap(), mmap routine looks correct ...]
> >
> > here, pmemt and pmema is the tag and physical address of the DSP
> > memory space which are get using pci_mapreg_info.
> 
> Just to make sure -- do you 1) also call pci_mapreg_map() or 2) call
> bus_space_map() before allowing accessing that space by method?
> 
> Btw, memory protection value of "1" you're seeing is relevant and means
> "allow reads" (PROT_READ that is, see /usr/include/sys/mman.h), which is
> correct.
> 
> > And below is a part of a test application program to see the DSP memory space.
> > ----
> > tdsph = open("/dev/tdsp", O_RDWR, 0);
> > sram.addr = mmap(0, sram.len, PROT_READ, MAP_SHARED, tdsph,
> >             (off_t)sram.offset);
> 
> Does mmap() succeed? Is sram.offset really correct (relative to start of
> SRAM window)?
> 
> >  while(i < sram.len){
> >                 addr = (u_int8_t*)sram.addr + i;
> >  [...]
> 
> Does the DSP SRAM (and the bus hierarchy it's connected to) allow you 8bit
> accesses?
> 
> > What should I check to see what is wrong? And in addition, is there a
> > good simple code that I can study the usage of device mmap function?
> 
> Hmm, I couldn't see anything obviously wrong. After checking the
> questions above, we can look at more code...
> 
>        Regards,
>                -- Jachym Holecek
>