Conference turris::digital_unix

>  2. The documentation says that some Alpha processors do not
>support memory mapping.

I don't think that is correct.

>What happens if I register a xxmmap
>function in the device driver and invoke mmap system call with
>the device descriptor? Will the device driver mmap entry point
>gets invoked?

I am not familiar with device drivers.  But, if you have an entry point
for mmap (d_mmap field in cdevsw), it will be called.  Note that no
call is made on mmap().  The entry point is called on the first access to
the mapped memory region.

FYI, we also support the SVR4 DDI/DKI segmap interface in mmap().  I don't
know what that interface looks like.

--shashi
[Posted by WWW Notes gateway]

Hi, Gerrit.

.0> We are having IVR system running on Unixware/HPUX. We are
.0> in the process of porting the source code to Digital Unix 4.0B.
.0> Our application does a lot of memory and I/O access of ISA
.0> boards from user space. To achieve this functionality we have
.0> written device drivers, which allows us to map the physical
.0> memory and I/O space to user space.

.0>   After going through the device driver tutorial document, we are
.0> slightly confused how this functionality can be achieved on
.0> Digital Unix, since the document says that some of the Alpha
.0> processors do not support memory mapping. Any suggestions
.0> from you regarding achieving this functionality would be of great
.0> help. Also give us some answers for the following queries.

Actually, mmap(2) is technically not supported for use with character
device drivers on Alpha processors. But, I'll be kind and say the doc 
is a little ambiguous on this topic! (See page 8-15 in the Tutorial).
However, it does work in many cases - especially with VME device drivers. 
With EISA/ISA/PCI it has been problematic and very much platform specific.  
If you do not need to make any xfers less than 32 bits then it should be 
easier. If you do need to make some 8 or 16 bit xfers, then you will need 
to use SPARSE space mapping instead of DENSE space and that's a bit more 
complex and platform specific. The stride between SPARSE space addresses
is not always the same on different platforms. 

.0>   1. Where would I get information regarding EISA address
.0>   mapping for Alpha AXP SB21064 processor.

You would use the get_config() kernel call to get the EISA address
mapping for you device. See chapter 5 of the "Writing EISA and ISA
Bus Device Drivers" manual for examples.

.0>   2. The documentation says that some Alpha processors do not
.0> support memory mapping. What happens if I register a xxmmap
.0> function in the device driver and invoke mmap system call with
.0> the device descriptor? Will the device driver mmap entry point
.0> gets invoked?

Yes, but as Shashi notes, it won't get called until the memory is 
actually accessed. That's generated a few calls for us! 

.0>   3. Is it possible to achieve memory mapping in the following
.0>      way.
.0>       - Map eisa address space to kernel memory
.0>       - pass the starting address of the mapped kernel address to
.0>         user space
.0>       - open /dev/kmem and do a mmap of the pages which map to
.0>         eisa address space (which is already mapped)

Possibly, but I don't think I'd do it that way. I think you should 
check out /usr/examples/devdriver/lh100/lhdriver.c and lh_test.c. This 
is an example VMEbus device driver that contains an mmap() routine and
the user level code contains macros that will allow you to perform byte
and word xfers using SPARSE space - if you need to. If you don't, then
it also shows how to perform xfers to/from DENSE space. If using DENSE
space, be sure to call mb() after writes - see the macros in lh_test.c 
for examples.

.0>   Please let us know if it would be possible to access the isa
.0> devices from user space.  Be as technical as possible in your
.0> replies.

I hope I was technical enough. :-) Seriously, if you run into problems,
I'd be willing to try to help a little - but, be prepared to come up 
with a backup plan.

Best Regards,

Lee Parker                       [email protected]
Digital UNIX Device Driver & Realtime Support
Realtime Expertise Center        1-800-354-9000

    

Thanks for the information. 

Gerrit
[Posted by WWW Notes gateway]

> >  2. The documentation says that some Alpha processors do not
> >support memory mapping.
> 
> I don't think that is correct.
    
    I believe the issue relates to dense/spare I/O space mapping
    and its support/nonsupport on the target platform. My recollections
    are quite fuzzy by now on this, but I'm thinking platforms like
    the Cobra (4000-600) that had mailbox I/O or something, rather
    than the bird machines dense/sparse model. I know I've hashed
    this pretty badly, but it's something like that. Someone will
    straighten this out for me, I hope...

    
    That's pretty much it Jeff. Also, as I mentioned in .2, the stride
    or offset between byte/word addresses in SPARSE space is often not
    the same from platform to platform so supporting mmap() for device
    drivers was considered to be a potential support nightmare. On the
    EISA/ISA/PCI busses, this has proven to be the case. I've been more
    successful in getting it to work with PCI but, again, changes often
    have to be made if you move to a different platform. Some of the
    Alpha's also use a different number of bits for physical addresses
    so that's another gotcha. I've found ISA/EISA to be a real pain to
    get mmap() working and it's quite fragile. 
    
    In general, in order to calculate the kernel page frame number to
    return to user mode, you first call iohandle_to_phys() :
    
                /* Change csr I/O handle to a physical address */
                phys_addr =
                    ((caddr_t)iohandle_to_phys((io_handle_t)reg, flags));
    
    then you call PHYS_TO_KSEG to get a physical address
    
                phys_addr = (char *)PHYS_TO_KSEG(phys_addr);
    
    then you swizzle it to get the kernel page frame number
    
             kpfnum = (long) ((((u_long)phys_addr + off) >> 13) & (0x1fffffL)); 
    
    And, this last call depends on the number of bits your dealing with.
    
    For example, from a recent PCI driver I worked on,
    
    /*
    ** On AlphaStation 600 a mask of 0x7FFFFFFFL must be used
    ** On AlphaServer 1000 a mask of 0x7FFFFFFFL or 0x1FFFFFL can be used
    */
    
    Without the system manual or source code, it can be quite difficult
    to support. 
    
    Lee
    

A few follow up questions from .2:

*******************************
Actually, mmap(2) is technically not supported for use with
character
device drivers on Alpha processors. But, I'll be kind and say the
doc 
is a little ambiguous on this topic! (See page 8-15 in the
Tutorial).
However, it does work in many cases - especially with VME
device drivers. 
With EISA/ISA/PCI it has been problematic and very much
platform specific.  
*******************************
1.
  We are planning to use SB21064 Alpha AXP processor. Would
you be having any information on the behaviour of memory
mapping  of ISA addresses on this processor?


*****************************
If you do not need to make any xfers less than 32 bits then it
should be 
easier. If you do need to make some 8 or 16 bit xfers, then you
will need 
to use SPARSE space mapping instead of DENSE space and
that's a bit more 
complex and platform specific. The stride between SPARSE
space addresses
is not always the same on different platforms. 
************************
2.
  Our application uses a combination of 16-bit and 32-bit
memory and 8-bit and 16-bit I/O. Would it be possible for you to
send us the details of the stride between SPARSE space
addresses for SB21064 Alpha AXP processor.

*******************
This 
is an example VMEbus device driver that contains an mmap()
routine and
the user level code contains macros that will allow you to
perform byte
and word xfers using SPARSE space - if you need to. If you don't,
then
it also shows how to perform xfers to/from DENSE space. If
using DENSE
space, be sure to call mb() after writes - see the macros in
lh_test.c 
for examples.
****************************
3.
  Will these macros also work for memory mapped ISA /EISA
addresses, if not where do I get the information to write such a
macros. Will the macros be same for I/O and memory or will it
have to be different. Any information on SPARSE  address
access would be of great help for us. 

4.
  I am having a hard time trying to find out routines to use which
will allow me to map EISA/ISA bus address to kernel space.
Please let us know which calls we should be using for mapping
I/O and memory addresses form bus to kernel.

  Many thanks in advance.

5. HPUX provides an IOMAP driver, which allows us to map the 
physical memory and I/O address range to user space. We are 
trying to write a driver on Digital Unix to provide us with the same
functionality. I guess this would give you a better idea of our
purpose.

[Posted by WWW Notes gateway]

Hi, Gerrit.

> 1.
>   We are planning to use SB21064 Alpha AXP processor. Would
> you be having any information on the behaviour of memory
> mapping  of ISA addresses on this processor?

No, I'm sorry but I've never heard of that one. Do 
you maybe mean a 21064 SBC ? What's the system type or code
name?

> 2.
>   Our application uses a combination of 16-bit and 32-bit
> memory and 8-bit and 16-bit I/O. Would it be possible for you to
> send us the details of the stride between SPARSE space
> addresses for SB21064 Alpha AXP processor.

Maybe once I find out what it is. Perhaps someone in the UNIX hardware 
support group will enlighten us. You will need to use SPARSE space.
The macros in lh_test.c should work ok. If they don't, then we will
have to fix them up so they do...

> 3.
>   Will these macros also work for memory mapped ISA /EISA
> addresses, if not where do I get the information to write such a
> macros. Will the macros be same for I/O and memory or will it
> have to be different. Any information on SPARSE  address
> access would be of great help for us.

The macros should be ok. You probably will just have to try it and
see. As mentioned above, it should be a fairly small task to fix them
so they work.

> 4.
>   I am having a hard time trying to find out routines to use which
> will allow me to map EISA/ISA bus address to kernel space.
> Please let us know which calls we should be using for mapping
> I/O and memory addresses from bus to kernel.

I already did. Have you looked at the lhdriver and user level code?
The "Writing EISA/ISA Bus Drivers" would also be a good start. If you
need an example EISA/ISA driver, let me know and I'll see what I can
come up with.

> 5. HPUX provides an IOMAP driver, which allows us to map the
> physical memory and I/O address range to user space. We are
> trying to write a driver on Digital Unix to provide us with the same
> functionality. I guess this would give you a better idea of our
> purpose.

How is the board layed out? Is the memory at an offset from the board
registers? I hope so because if not, then calling mmap(2) a second time
will undo the first mapping. You can only have one active mapping at a
time. You could have a second "driver" or instance of the driver with
a different minor number to get around that, I think.

We might want to take this offline at this point. Feel free to send me
mail...

Best Regards,

Lee Parker                       [email protected]
Digital UNIX Device Driver & Realtime Support
Realtime Expertise Center        1-800-354-9000