home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / misc / 3747 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.3 KB  |  85 lines

  1. Newsgroups: comp.sys.sun.misc
  2. Path: sparky!uunet!psinntp!ptsys1!jjg
  3. From: jjg@pt.com (John Grana)
  4. Subject: Re: S-Bus device driver  question
  5. Message-ID: <1992Aug18.114601.395@pt.com>
  6. Organization: Performance Technologies, Incorporated
  7. References: <MISHA.92Aug12193338@espresso.ai.mit.edu>
  8. Date: Tue, 18 Aug 1992 11:46:01 GMT
  9. Lines: 74
  10.  
  11. In article <MISHA.92Aug12193338@espresso.ai.mit.edu> misha@ai.mit.edu (Mike Bolotski) writes:
  12. >
  13. >Forwarded for a friend at the AI Lab:
  14. >
  15. >--------
  16. >
  17. >    I'm trying to write a simple device driver for a memory mapped
  18. >sbus-peripheral.  I am trying to understand how the device specific xxmmap
  19. >fits in with relation to mmap and unmap.  Particularly, I don't understand
  20. >why there is no xxunmap routine.
  21. >
  22. Andrea,
  23.  
  24.     The driver specific xxmmap routine is called to provide range
  25. checking (i.e. is the user request in the address range of the device) and
  26. for Page Table Entry (PTE) information for the kernel. The kernel
  27. takes this PTE info and maps the page into user virtual address space.
  28. This point is important for your next question/issue:
  29.  
  30. >
  31. >    My peripheral has a potentially large address space (e.g. the
  32. >entire 25 bits provided on early S-Busses).  Experience has shown that I
  33. >cannot simply map the entire region once since that requires too much space
  34. >in the kernel and hence panics/crashes the machine.  So, I understand that
  35. >I need to map and unmap regions as I need access to them.  Ok, I have
  36. >written an xxmmap routing, which I understand will be called once by mmap
  37. >for each page that needs allocating.  My user program then calls mmap and
  38. >munmap.  However, after running for a while, the machine panics and crashes
  39. >do to insufficient space in some kernel map table.
  40.  
  41. So far so good. Yup, the kernel will call your driver xxmmap routine many
  42. times (once per "pagesize" of the user request).
  43.  
  44. >
  45. >    In my xx_mmap routine, I am using map_regs to map the sbus physical
  46. >address into a kernel address and hat_getkpfnum to get an address to return
  47. >to the user program.  This generally seems to have the desired effect.
  48. >However, I note that there is an unmap_regs routine, which one might want
  49. >called to release mappings.  However, since there is no xx_munmap routine,
  50. >I don't seem to have a hook which allows me to umap_regs when the user
  51. >level program does a munmap.
  52.  
  53. Since the kernel just needs the physical page frame information, you
  54. dont have to map the request virtually yourself. Actually, you are
  55. mapping the request into kernel virtual space... Anways, just return
  56. the page frame information... (phys address page (btop) or'ed with page type
  57. (PGT_OBIO))
  58. something like this:
  59.  
  60.     {
  61.         check boundrys...
  62.  
  63.         get SBus physical base address (from dev_info structure)
  64.         add in users offset into your SBus physical base...
  65.  
  66.         and return:
  67.  
  68.         return(PGT_OBIO | btop(SBusPhysAddr));
  69.     }
  70.  
  71. This should allow pretty large mappings... we have never had a problem
  72. mapping in pretty large chunks - up to 28 MB. You also get the benefit
  73. of not using up page table entries - I suspect that is the reason for
  74. the panics. Let the kernel worry about it!
  75.  
  76. Good Luck
  77. John Grana
  78. jjg@pt.com
  79.  
  80. -- 
  81. ___________________________________________________________________________
  82. |John Grana, Performance Technologies Incorporated        jjg@pt.com|
  83. |315 Science Parkway, Rochester, New York 14620           uupsi!ptsys1!jjg|
  84. |Phone: (716) 256-0200   Fax: (716) 256-0791                              |
  85.