path: root/drivers/acorn/block/mfmhd.c

/*
 * linux/arch/arm/drivers/block/mfmhd.c
 *
 * Copyright (C) 1995, 1996 Russell King, Dave Alan Gilbert (gilbertd@cs.man.ac.uk)
 *
 * MFM hard drive code [experimental]
 */

/*
 * Change list:
 *
 *  3/2/96:DAG: Started a change list :-)
 *              Set the hardsect_size pointers up since we are running 256 byte
 *                sectors
 *              Added DMA code, put it into the rw_intr
 *              Moved RCAL out of generic interrupt code - don't want to do it
 *                while DMA'ing - its now in individual handlers.
 *              Took interrupt handlers off task queue lists and called
 *                directly - not sure of implications.
 *
 * 18/2/96:DAG: Well its reading OK I think, well enough for image file code
 *              to find the image file; but now I've discovered that I actually
 *              have to put some code in for image files.
 *
 *              Added stuff for image files; seems to work, but I've not
 *              got a multisegment image file (I don't think!).
 *              Put in a hack (yep a real hack) for multiple cylinder reads.
 *              Not convinced its working.
 *
 *  5/4/96:DAG: Added asm/hardware.h and use IOC_ macros
 *              Rewrote dma code in mfm.S (again!) - now takes a word at a time
 *              from main RAM for speed; still doesn't feel speedy!
 *
 * 20/4/96:DAG: After rewriting mfm.S a heck of a lot of times and speeding
 *              things up, I've finally figured out why its so damn slow.
 *              Linux is only reading a block at a time, and so you never
 *              get more than 1K per disc revoloution ~=60K/second.
 *
 * 27/4/96:DAG: On Russell's advice I change ll_rw_blk.c to ask it to
 *              join adjacent blocks together. Everything falls flat on its
 *              face.
 *              Four hours of debugging later; I hadn't realised that
 *              ll_rw_blk would be so generous as to join blocks whose
 *              results aren't going into consecutive buffers.
 * 
 *              OK; severe rehacking of mfm_rw_interrupt; now end_request's
 *              as soon as its DMA'd each request.  Odd thing is that
 *              we are sometimes getting interrupts where we are not transferring
 *              any data; why? Is that what happens when you miss? I doubt
 *              it; are we too fast? No - its just at command ends. Got 240K/s
 *              better than before, but RiscOS hits 480K/s
 *
 * 25/6/96:RMK: Fixed init code to allow the MFM podule to work.  Increased the
 *              number of errors for my Miniscribe drive (8425).
 *
 * 30/6/96:DAG: Russell suggested that a check drive 0 might turn the LEDs off
 *              - so in request_done just before it clears Busy it sends a
 *              check drive 0 - and the LEDs go off!!!!
 *
 *              Added test for mainboard controller. - Removes need for separate
 *              define.
 *
 * 13/7/96:DAG: Changed hardware sectore size to 512 in attempt to make
 *              IM drivers work.
 * 21/7/96:DAG: Took out old image file stuff (accessing it now produces an IO
 *              error.)
 *
 * 17/8/96:DAG: Ran through indent -kr -i8; evil - all my nice 2 character indents
 *              gone :-( Hand modified afterwards.
 *		Took out last remains of the older image map system.
 *
 * 22/9/96:DAG:	Changed mfm.S so it will carry on DMA'ing til; BSY is dropped
 *		Changed mfm_rw_intr so that it doesn't follow the error
 *		code until BSY is dropped. Nope - still broke. Problem
 *		may revolve around when it reads the results for the error
 *		number?
 *
 *16/11/96:DAG:	Modified for 2.0.18; request_irq changed
 *
 *17/12/96:RMK: Various cleanups, reorganisation, and the changes for new IO system.
 *		Improved probe for onboard MFM chip - it was hanging on my A5k.
 *		Added autodetect CHS code such that we don't rely on the presence
 *		of an ADFS boot block.  Added ioport resource manager calls so
 *		that we don't clash with already-running hardware (eg. RiscPC Ether
 *		card slots if someone tries this)!
 *
 * 17/1/97:RMK:	Upgraded to 2.1 kernels.
 *
 *  4/3/98:RMK:	Changed major number to 21.
 *
 * 27/6/98:RMK:	Changed asm/delay.h to linux/delay.h for mdelay().
 */

/*
 * Possible enhancements:
 *  Multi-thread the code so that it is possible that while one drive
 *  is seeking, the other one can be reading data/seeking as well.
 *  This would be a performance boost with dual drive systems.
 */

#include <linux/module.h>
#include <linux/config.h>
#include <linux/sched.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/timer.h>
#include <linux/mm.h&g