[LV] TURBOchannel support -- success!

[Kenn Humborg]

On Fri, Feb 23, 2007 at 05:54:04PM +0000, Maciej W. Rozycki wrote:
> 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... ;-)

For a sufficiently broad value of "valuable" :-)

>  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.  

Yes.  A lot of that was just doing the minimum required to get things to
boot.  Not having a sparse system address space is a bit of a pain.

>    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.

The problem is the number of "struct page"s we need.  Last time I looked,
struct page was about 44 bytes.  If we had one struct page for each
512-byte hardware page, we'd be losing 8% of our RAM to the mem_map
array.

> 
> 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 saw two possible approaches to interrupt priority handling:

1. The easy way - we run at either IPL 0 or IPL 31 (interrupts enabled
   or disabled).  This fits well with the local_irq_enable/disable API.
   When I started looking at the VAX port, we were back at kernel 2.0,
   where the linux interrupt model seemed to be like this anyway.

2. The harder way - each device driver knows the IPL that its device
   uses and raises IPL to that level (or leaves IPL as-is if already
   greater).  This allows higher priority devices to interrupt the
   drivers for lower-priority devices.  However, could this lead to
   re-entrancy issues within core code?  Driver A raises IPL to 16,
   calls into some core subsystem, gets interrupted by device B at
   IPL 17 which calls into the same subsystem.  Perhaps these days
   all the core code is re-entrant enough for this?

>  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.

I would be interested to see the diffs to support TURBOchannel.

Later,
Kenn

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