Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Nov 1997 01:13:59 -0800
From:      John-Mark Gurney <gurney_j@efn.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        jak@cetlink.net, hackers@FreeBSD.ORG
Subject:   Re: 650 UART, SIO driver, 8259 PIC
Message-ID:  <19971130011359.25067@hydrogen.nike.efn.org>
In-Reply-To: <199711300856.TAA05947@godzilla.zeta.org.au>; from Bruce Evans on Sun, Nov 30, 1997 at 07:56:41PM %2B1100
References:  <199711300856.TAA05947@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans scribbled this message on Nov 30:
> >I've thought about upgrading sio so that it would understand the
> >existance of it, but there were a number of problems...  the status
> >register is stored in the scratch register of the fourth port of the
> >board...  also, on the AST/4 the port to write to, to clear ALL the
> >...
> >then you have to decide you to tell each port what it's number in the
> >status register...  you don't want to have to force some aweful hack
> >like requiring the port number to be congruent to device number mod 4...
> >that would just be terrible (though most people do something similar)..
> 
> Doesn't the master port give it?  The master port is more for control,
> but it is a normal h/w hack for the control and status ports to be
> the same.

well..  assuming that you make the master port, port 4 on the board..
but there is nothing that assures us this will happen.. the only way
it to document it's requirement...

but this still doesn't lend an easy way to obtain the port number to
sio number mappings... which need to be determined at boot time...
(unless we do the hack of forcing the ports in order)...

> >then to make matters worse... BOTH boards could possible be on the same
> >interrupt, and you have to check both port 4's scratch registers to see
> >who generated the port...
> 
> >after all this came to light, I stopped work on it as there really was
> >no easy way to describe the different configurations in the flags of
> >the device...  and this was even before Bruce used another bit to store
> >what one is the serial console...
> 
> NetBSD uses a separate driver (with just the AST-specific parts).  I'm
> not sure how it configures a pair of boards sharing an irq.

seems a waste to me...  all the code to manipulate the uart is already
in sio...

personally, I would like to see a complete rewrite of most of the hardware
into two layers, the "chip interface" layer which describes how the
chip interacts, and then a bus layer in how the chip is mapped to the
computer...  but this probably won't ever happen.. :)  and probably some
hardware it wouldn't work well with...  but it would mean porting to a
new platform would just require rewriting the bus code...  and possibly
create a new "bus interface" layer...

> BTW, flags hacks don't work well for multiple, not explicitly configurable
> units.  E.g., we use the flags to configure individual wd drives, but
> there is no way to use them for inidividual sd drives.  The console flag
> works for individual sio ports, but can't work for indiidual cy ports.

yes, but in this case, each sio port has it's own sio entry...  so it
can apply...  but if we force that the ports are in order and that the
master port's scratch register be it, it would make the code VERY easy
for the one board problem... then for the two board shared, we could
simply reserve a bit for the "secondary" master port...  and now that
I think about it, this wouldn't be that hard...

at the same time, I was thinking it wouldn't be hard to use a similar
interface so that we only test the ports that are bound to a specific
interrupt...

hmm...  now that I think about it, I think I'll see what I can hack
together tonight...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971130011359.25067>