From owner-freebsd-hardware  Wed May 20 11:25:52 1998
Return-Path: <owner-freebsd-hardware@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA19275
          for freebsd-hardware-outgoing; Wed, 20 May 1998 11:25:52 -0700 (PDT)
          (envelope-from owner-freebsd-hardware@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA19132;
          Wed, 20 May 1998 11:25:21 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id EAA22099;
	Thu, 21 May 1998 04:22:51 +1000
Date: Thu, 21 May 1998 04:22:51 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199805201822.EAA22099@godzilla.zeta.org.au>
To: bde@zeta.org.au, mike@smith.net.au
Subject: Re: IWill and sio, again and again
Cc: current@FreeBSD.ORG, grog@lemis.com, hardware@FreeBSD.ORG,
        tarkhil@asteroid.svib.ru
Sender: owner-freebsd-hardware@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>> The port worked fine on the system I debugged it on. 
>
>Do you mean to say that you've assessed the problem with the ACER UART 
>(or the PIC arrangement used with it)?  What is your prognosis?

No, I only worked around the problem on one IWill system.  The PIC (or
something beteween the UART and the PIC) apparently latches rising edges
of IRQ signals even for IRQs that are masked in the PIC.

>> The attach makes
>> no assumptions about the results of the probe, but it assumes that a
>> successful probe leaves a couple of registers in a certain state.
>> Butchery of the probe to do more than ignore the failures could easily
>> break this.
>
>Butchery of the probe to merely ignore the failures results in a 
>nonworking port.

>Butchery of the probe to include the bogus-but-functional probe code on 
>Greg's page results in a working port.

That patch is just as bad as its author says.  It assumes working loopback
mode and IIRC breaks the shared IRQ case.  It works by ignoring all errors
and all non-errors, and replacing the tests by another one which doesn't
fail.  Side affects of the test apparently help.  They wouldn't have helped
on the system that I tested.

>The inference here is that the attach assumes some port state that is 
>not achieved by the normal probe.  If we were to use the PnP BIOS data 
>to determine the port's configuration and ignored the probe, it would 
>be interesting to know if the attach would result in a working port.

It should not-work even for non-IWill UARTs, since the attach assumes
certain values in the cfcr, ier and mcr registers.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message