[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux kernel 3.2.0-3-amiga misses Cyberstorm 1 SCSI



Hi!

Yesterday I googled a little bit about Amiga and DMA. There are some docs from the Hardware Reference Manual that have details about DMA transfer within the chipset and everyone mentioned the length of the transfer. Even some caveats were listed, for example that the last 3 bits of every write or that every last byte from reads are missing. Though, that is for OCS/ECS chipsets, not the ESP chip, but I think there should be some similar docs. Unfortunately I am on board of AIDAbella with limited internet access.

On 2012-11-19 02:51, schmitz wrote:
Finn,
I've seen that - the old Amiga drivers only set the DMA start address but no transfer length, no idea whether that will work for command data.


As far as the low level driver dma routines are concerned, they only get called by the ESP core and they are always passed a transfer length. I don't doubt that - the transfer length wasn't used by the Cyberstorm and Blizzard drivers though (the mind boggles how that could have worked, but hey - it seems to have worked OK).

To wit:

/* The Blizzard 2060 DMA interface
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 * Only two things can be programmed in the Blizzard DMA:
* 1) The data direction is controlled by the status of bit 31 (1 = write) * 2) The source/dest address (word aligned, shifted one right) in bits 30-0
 *
 * Figure out interrupt status by reading the ESP status byte.
 */
struct blz2060_dma_registers {
volatile unsigned char dma_led_ctrl; /* DMA led control [0x000] */
        unsigned char dmapad1[0x0f];
volatile unsigned char dma_addr0; /* DMA address (MSB) [0x010] */
        unsigned char dmapad2[0x03];
volatile unsigned char dma_addr1; /* DMA address [0x014] */
        unsigned char dmapad3[0x03];
volatile unsigned char dma_addr2; /* DMA address [0x018] */
        unsigned char dmapad4[0x03];
volatile unsigned char dma_addr3; /* DMA address (LSB) [0x01c] */
};

No length field - must have relied on the ESP interrupt to terminate
the transfer.

Does Mac ESP PIO run in some sort of coroutine?

Cheers,

 Michael

--
Ciao...          //    Fon: 0381-2744150
.     Ingo     \X/     http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.


Reply to: