Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Sep 2003 06:28:22 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/uart uart_cpu_pc98.c
Message-ID:  <20030912061218.Q1530@gamplex.bde.org>
In-Reply-To: <20030911.104147.54186211.imp@bsdimp.com>
References:  <200309110414.h8B4ERi2062520@repoman.freebsd.org> <20030911.104147.54186211.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Sep 2003, M. Warner Losh wrote:

> In message: <20030911.204333.41730710.nyan@jp.FreeBSD.org>
>             Takahashi Yoshihiro <nyan@jp.FreeBSD.org> writes:
> : In article <200309110414.h8B4ERi2062520@repoman.freebsd.org>
> : Warner Losh <imp@FreeBSD.org> writes:
> :
> : > imp         2003/09/10 21:14:27 PDT
> : >
> : >   FreeBSD src repository
> : >
> : >   Modified files:
> : >     sys/dev/uart         uart_cpu_pc98.c
> : >   Log:
> : >   Fix compile on pc98.  Maybe this is correct.
> :
> : It should not call i386_bus_space_handle_alloc() directly in device
> : driver.  I think that we need to implement bus_space_map() function.

sio also needs the map function.  From pc98/sio.c

% 	    com->data_port = iobase + iat[com_data];
% 	    com->int_id_port = iobase + iat[com_iir];
% 	    ...

This needs the map function so that the map is not hard-coded.  After
all i/o addresses (only 8 for 8250-16950) are mapped like this, all
offsets can be 0 (and direct).

> The functions in uart_cpu_* are used for the console port support
> before the device system is up and running.  It is currently abusing
> bus space handles a little bit here.  Since we're only planning on

Hmm.  I only have 2 sio ports that can use a special mapping
(multiplication of the offset by 4 for the memory-mapped case), and
currently just hard-codes this in a way that doesn't work for consoles.
But the ports also support pio and that could be used for consoles.

> supporting console ports on the first two serial ports, the number of
> different devices we need to support is sufficiently small that I
> thought this abuse was OK.

Restricting the number doesn't help much since all cases may be present
on different machines with just 1 port.

Bruce



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