[LV] TURBOchannel support -- success!

[Maciej W. Rozycki]

On Fri, 23 Feb 2007, Kenn Humborg wrote:

> This is seriously cool!  Are you working from Jan-Benedict's latest GIT
> tree?

 Do you really think this work is valuable in any way?  Well, then that 
evening was not a waste of time after all... ;-)

 I used the same tree I used for rewriting the TURBOchannel core, which is 
a snapshot from linux-mips.org from Sep 20th, 2006, with all the changes 
from JBG's tree applied on top and then some changes needed for an update 
to 2.6.18, some bug fixes and then further bits for the KA49 itself.  I 
plan to update to 2.6.21 soon.  It should be reasonably easy to update our 
"official" tree for someone with some reasonable GIT experience as the 
port seems well-separated.

 This was only an initial attempt though.  In the course I have discovered 
these problems with the port that need to be addressed sooner or later if 
it is to be treated seriously enough for a merge with upstream to be 
possible one day:

1. Kernel-mode memory management -- vmalloc() is not implemented, the DMA 
   API is not implemented, ioremap() has serius limitations.  My brief 
   study of how the MMU is implemented suggests these are not problems 
   that could not be overcome, but they require some considerable effort.  
   I am not sure if keeping page clustering in place is worth the hassle 
   -- these days there is nothing in Linux that would justify an 
   assumption about any fixed size of the page used.

2. Interrupt subsystem -- its unacceptable to keep interrupts masked for 
   long periods as it is done now.  The problem is Linux assumes there is 
   a binary setting for interrupt enable available in addition to any 
   prioritisation available.  We do not have such a control, but we may 
   still be able to fit reasonably in the Linux model.  For systems with 
   external per-device masks (such as the KA49) the IPL may be lowered 
   once the source has been masked.  Systems with no external interrupt 
   masks (I gather there are some -- am I correct?) are more difficult.  
   In principle the IPL may be left intact in the handler under the 
   assumption the designers made their homework and low-priority devices 
   do not really mind long latencies, but this approach still leaves the 
   question as to how to handle local_irq_disable(), local_irq_enable()  
   and irqs_disabled().  I guess we should try to adopt the approach taken 
   by the Alpha port, which, although seemingly opposite to what happened 
   in the history, might have a chance to succeed.  Additionally the 
   interrupt controller model has to be implemented.

 What do you think?

 I can publish patches once I polish them a little bit if there is 
interest.  TURBOchannel framebuffer devices should work too, but for now 
the REX emulator has to be run before a bootstrap to initialize the 
boards.

  Maciej
_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax