shaig@shum.huji.ac.il (05/25/90)
I am currently preparing a device driver for a card that performs DMA to addresses on a Sun4/60 S-bus. One of the limitations that I have encountered is that the DMA memory area is limited to 600Kb, and the memory buffers that my device would like to work with can reach 3*192Kb each. Is it possible to reconfigure the kernel to a DMA size of say 900Kb? If so how? If not, what is the cause of the actual limitation?
kevin@corp.sun.com (Kevin Sheehan {Consulting Poster Child}) (05/26/90)
In article <8124@brazos.Rice.edu> shaig@shum.huji.ac.il writes: > >I am currently preparing a device driver for a card that performs DMA to >addresses on a Sun4/60 S-bus. One of the limitations that I have >encountered is that the DMA memory area is limited to 600Kb, and the >memory buffers that my device would like to work with can reach 3*192Kb >each. Is it possible to reconfigure the kernel to a DMA size of say 900Kb? >If so how? If not, what is the cause of the actual limitation? The SS1 doesn't really have a "DVMA window" - a small portion of the kernel map was set aside so that drivers could still believe in the fiction if they so desired. On the SS1, all of the kernel context is visible to the SBus devices, so all you really need to do is use bp_mapin() to make it visible, then set up the xfer. Note that 4.0.3c only allowed 63K mappings. This limitation has been removed in 4.1 - if the space exists to map, bp_mapin() (and cousins) will do it now. Kevin Sheehan Sun Microsystems kevin@sun.com
jeffz@sun.com (Jeffrey Zank - SBus Software) (05/29/90)
>I am currently preparing a device driver for a card that performs DMA to >addresses on a Sun4/60 S-bus. One of the limitations that I have >encountered is that the DMA memory area is limited to 600Kb, and the >memory buffers that my device would like to work with can reach 3*192Kb >each. Is it possible to reconfigure the kernel to a DMA size of say 900Kb? >If so how? If not, what is the cause of the actual limitation? You need to be clear here. If you are using DVMA, 600 KBytes sounds about right for mb_ampalloc() and mb_mapfree() type of usage. Total space for DVMA is about 1 MByte, and its shared with all other devices that do DVMA. You really cannot "reconfigure" your kernel to add more space, you are limited by other kernel resources that currently are not configurable (PMEGS, and IOPB Memory for example). If you're not using DVMA you might try bp_mapin() and bp_mapfree() and set your own size in minphys(). All the above discussion is under SunOS 4.1 on the 4/60 and 4/65 class machines. If you are building a SBus board out there then you "should" be getting something called SBulletin, the quarterly news letter about technical happenings with the SBus. It just so happens that their is an article on the above subject in the next edition, due out in June. If you have any questions about developing SBus hardware and software, call the Sun SBus Technical Support Hot line number 415-336-3558 or send mail to sbustech@sun.com
das@harvard.harvard.edu (David Steffens) (05/31/90)
In article <8186@brazos.Rice.edu>, Sun-Spots Volume 9, Issue 180, message 13 kevin@corp.sun.com (Kevin Sheehan {Consulting Poster Child}) writes: > On the SS1, all of the kernel context is visible to the SBus devices, > so all you really need to do is use bp_mapin() to make it visible, > then set up the xfer. In article <8228@brazos.Rice.edu>, Sun-Spots Volume 9, Issue 185, message 1 jeffz@sun.com (Jeffrey Zank - SBus Software) writes: > If you are using DVMA, 600 KBytes sounds about right > for mb_mapalloc() and mb_mapfree() type of usage. ... > If you're not using DVMA you might try bp_mapin() and bp_mapfree() > and set your own size in minphys(). ... > All the above discussion is under SunOS 4.1 > on the 4/60 and 4/65 class machines. What are the implications, if any, of these comments for a DMA driver running on a Sun4/260 under SunOS4.1? Is there now a general way around the 600K DVMA limit, i.e. does bp_mapin() on the 4/260 work as described for the SS1? And while I've got your attention... I'm currently using mbsetup(), MBI_ADDR() and mbrelse() as described in the 24 Apr 89 edition of "Writing Device Drivers". I have skimmed the 27 Mar 90 edition of "Writing Device Drivers" and the "SunOS4.1 Release Manual", but have been unable to find a definitive answer to the following question: Are there any changes I absolutely _must_ make to a DMA driver which runs under SunOS4.0.3 in order to run it under SunOS4.1? {harvard,mit-eddie,think}!eplunix!das David Allan Steffens 243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory (617) 573-3748 (1400-1900h EST) Mass. Eye & Ear Infirmary
kevin@corp.sun.com (Kevin Sheehan {Consulting Poster Child}) (06/02/90)
In article <8290@brazos.Rice.edu> eplunix!das@harvard.harvard.edu (David Steffens) writes: >X-Sun-Spots-Digest: Volume 9, Issue 185, message 10 > >In article <8186@brazos.Rice.edu>, Sun-Spots Volume 9, Issue 180, message 13 >kevin@corp.sun.com (Kevin Sheehan {Consulting Poster Child}) writes: >> On the SS1, all of the kernel context is visible to the SBus devices, >> so all you really need to do is use bp_mapin() to make it visible, >> then set up the xfer. > >What are the implications, if any, of these comments for a DMA driver >running on a Sun4/260 under SunOS4.1? Is there now a general way around >the 600K DVMA limit, i.e. does bp_mapin() on the 4/260 work as described >for the SS1? No - VME still goes thru the 1MB DVMA window. You are limited by hardware to 1MB, by usage to something less. You can map more than 64K in 4.1, as the mapping routines now allow it, but the 1MB limit remains for VME machines like the 4/260. The SBus does not have this limit, as it can see all of the kernel context. >And while I've got your attention... I'm currently using mbsetup(), >MBI_ADDR() and mbrelse() as described in the 24 Apr 89 edition of "Writing >Device Drivers". > [ stuff deleted ] >Are there any changes I >absolutely _must_ make to a DMA driver which runs under SunOS4.0.3 in >order to run it under SunOS4.1? No - mbsetup() is now a front end to the routines that do the real work, but you don't *need* to know that. It would be a good idea to read the 4.1 manual to see the direction we are going with drivers, but the old stuff still works just fine in 4.1. Kevin Sheehan Sun Microsystems kevin@sun.com