Subject: Re: maple bus code
To: None <itohy@netbsd.org>
From: Marcus Comstedt <marcus@idonex.se>
List: port-dreamcast
Date: 03/26/2001 14:53:06
>>>>> "ITOH" == ITOH Yasufumi <itohy@netbsd.org> writes:

  ITOH> I played with maple bus devices (VMS, Controller), and and I made
  ITOH> some functions working.
  ITOH> However, current implementation of the maple bus has some problems
  ITOH> and needs being rewritten.  Some of them are:

I am working on a rewrite on some of it while doing a memory card
driver.


  ITOH>   - periodic status request only, and each driver can't send commands
  ITOH>     on demand,

Yup.  This is on the TODO.  Maybe I'll fix so that you can get
different periodic status requests from the same unit as well, on a
round-robin basis.


  ITOH>   - only one request per subunit between timeouts, which is not enough for
  ITOH>     storage devices,

Well, it has to be enough, as you can't send requests much faster to
some devices or they will fail.  Current frequency allows 25Kbyte per
second from a standard memory card, which allows you to read the whole
card in 4 seconds.  Writing is slower, as you have to use four write
requests per sector.


  ITOH>   - the detection whether the command/request is finished is kludgy.
  ITOH>     Doesn't the DMA driver have interrupts?

Yes, it does.  I've considered using them, but I'm not sure whether it
would actually make the code all that much less kludgy.  :-)  It would
reduce latency for one shot commands though.  I'll look at it again.

What really does need a good cleanup though is the interrupt code in
general.  Right now IRQ 9 and 11 are hardcoded to be associated with
certain interrupt sources within the system ASIC.  What we need is a
more fine-grained system that allows you to bind to/mask individual
interrupt sources rather than just the CPU IRQ levels (which are not
individually maskable anyway).


  ITOH> I believe Marcus is working on the problems and I should wait
  ITOH> for a while, right? :)

The Maple rewrite will happen as soon as Jason gives me the
explanation of how device nodes associated with physical location is
supposed to work.


  // Marcus