From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH] add polling support for ns16550 Date: Thu, 24 Nov 2005 07:07:10 -0700 Message-ID: <1132841230.3074.20.camel@localhost.localdomain> References: <1132764049.18843.7.camel@tdi> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Xen Mailing List List-Id: xen-devel@lists.xenproject.org On Thu, 2005-11-24 at 11:13 +0000, Keir Fraser wrote: > On 23 Nov 2005, at 16:40, Alex Williamson wrote: > > > The patch below adds ac_timer based polling to the ns16550 UART > > driver. This is useful when the interrupt line is not connected in > > hardware or the mechanism to enable it is not readily available in the > > hypervisor. Polling is only enabled when the UART IRQ is set to zero. > > Thanks, > > I reworked the patch a little and checked it in, thanks. Thanks! > One thing I removed was the clear-and-reset of IER in the timeout > handler. Given we write zero to IER in the preirq steup function, and > also we do not set the master-enable bit in the MCR, I cannot see how > you could end up accidentally fielding interrupts in the timeout > handler. Did I miss something? It was mainly paranoia, but on ia64 we don't have a good way to hide UARTs from the guest domains, so it's possible that a dom0 with 8250 support will enable those bits on the UART. All sorts of strange things happen when the hypervisor and a guest compete for access to a UART, but I thought I would at least avoid the hypervisor polling triggering the real interrupt. I'm ok with dropping it, the UART isn't really functional no matter what paranoia checks are added when multiple drivers are competing to use it. Thanks, Alex