Date: Fri, 05 Jun 1998 18:57:53 -0700 From: Mike Smith <mike@smith.net.au> To: Julian Elischer <julian@whistle.com> Cc: Shiaw Yi Hsieh <syhsieh@ali.com.tw>, johnson@ali.com.tw, Hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2.x can't find SIO on ALi M5135 Message-ID: <199806060157.SAA02769@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 05 Jun 1998 13:46:27 PDT." <35785923.2C67412E@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have forwarded your email to the people responsible for the Serial > driver. > However I had some trouble understanding your email. > Your english is much better than my Chinese so please do not > take this as a critisism, but as an attempt to clear some points that > are unclear in the email. > > We are thrilled that our problems with the iWill motherboard have been > taken seriously and will attempt to assist you in any way possible. I would second this and say that the opportunity to resolve this issue with Acer Labs is greatly appreciated. We strive to achieve the highest level of hardware compatibility possible, and direct dialog with vendors is the best method of realising this. Being slightly more familiar with the issues at hand, I may be able to clarify both some of the original message and also your questions. > Shiaw Yi Hsieh wrote: > > > > Dear sir, > > Several month ago, one of our customers name Iwill feedback one > > question: > > FreeBSD 2.2.5 can not found UART port at Iwill motherboard (use Acer > > labs. M5135). This parts is use Intel new technology name--serial IRQ. > > and did not found any problem in the other parts such as M5113,M5123 AND > > M1543. > > And our R&D people made much effort to study how FreeBSD can not found > > UART and Tape out a new version to fixed this issue(for 2.2.5). > > But after we get the new chip we still have got the following issue: > > > > 1. FreeBSD boot from CD-ROM PASS > > 2. FreeBSD boot from HDD PASS > > 3 FreeBSD boot from FDD FAIL > > > > After we studied the different between boot from CD-ROM,HDD AND FDD > > we found the different is in the command and command recovery time when > > FreeBSD polling UART's IRQ(read IIR register 2fa,3fa,2ea,3ea). The > > recovery time of CD-ROM,HDD is around several us but FDD command > > recovery time only 2us. would it possible last the FDD commend recovery > > time to over 10us? > > Your request is for FreeBSD to allow a longer time > for IO recovery period after reading FDD registers? I believe the reference is to the behaviour of the interrupt handler when reading the UART IIR; their observations indicate that the IIR is read extremely quickly following the interrupt itself, and that they observed a shorter delay when booted from FDD than when booted from CDROM or HDD. There should be no difference at all in the interrupt response time based on the device from which FreeBSD was booted, however there may be many other factors affecting the situation. In order to optimise serial port performance, FreeBSD uses an extremely aggressive interrupt handling mechanism. I would assume from the request that the ALI M5135 does not set the IIR bits until *after* it has completed the Serial IRQ protocol - can you confirm this? This should not affect the probe process, however it might adversely affect the performance of the port in actual use. > > Another issue is read 8259 IRQ status method, in the parallel IRQ you > > can read from edge or level but NEW serial IRQ our chip M5135 only have > > got a pulse and not the level. Maybe this is why FreeBSD can not found > > UART. Your point here is that if the 8259 is programmed to latch the interrupt, it will not indicate that an interrupt delivered by the Serial IRQ protocol is still driven after being latched? This would cause problems with the FreeBSD serial port probe code, which expects the UART to drive the interrupt signal until the interrupt cause is cleared. The only resolution for this is in software, as it would appear to be a feature of the Intel PIIX4. > You say that the parallel-Port IRQ and the serial-port IRQ on the same > chip behave differently? Surely the serial IRQ must act the same a > National Semiconductor NS16450 for compatibility? No, you are confusing the interrupt delivery mechanism (parallel or serial) with the ports on the M5135. For more information, see the Intel PIIX4 documentation. > > Our new chip had been option to change the IRQ from pulse to level, but > > in FDD boot still have this issue. Do you have any comments? > > It is surprising that the FDD boot behaves differently. > there is no code difference in FreeBSD if booted from FDD. > Maybe the BIOS adjusts the ISA-BUS IO-recover time during FDD > operations? The Serial IRQ protocol requires a total of over 100 clock cycles (about 3us) to register an interrupt. From the time that (eg.) IRQ4 is transmitted there are still approx. 2.8us remaining before the end of the protocol. If the M5135 does not set bits in the IIR until *after* the serial IRQ protocol is complete, it is not unlikely that the FreeBSD interrupt handler will have already read the IIR and discarded the interrupt as spurious. Bruce; this is definitely one for you. Can we delay the IIR read without adversely affecting the overall performance of the interrupt handler? Also, do we depend elsewhere on the dual edge/level IRQ signal behaviour? There is no clarification I can find in the Intel documentation for the PIIX4 indicating the behaviour of the ISR/IRR registers in the presence of Serial IRQ inputs. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806060157.SAA02769>