Date: Fri, 22 Aug 2003 15:45:15 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: marcel@xcllnt.net Subject: Re: PERFORCE change 36551 for review Message-ID: <20030822.154515.101560696.imp@bsdimp.com> In-Reply-To: <XFMail.20030822125414.jhb@FreeBSD.org> References: <20030821192214.GA25805@ns1.xcllnt.net> <XFMail.20030822125414.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20030822125414.jhb@FreeBSD.org>
John Baldwin <jhb@freebsd.org> writes:
:
: On 21-Aug-2003 Marcel Moolenaar wrote:
: > On Thu, Aug 21, 2003 at 10:32:25AM -0700, Marcel Moolenaar wrote:
: >>
: >> > If the UART devices raise an ISA interrupt, then by my reading,
: >> > the ACPI resource should specify the ISA interrupt number (0-15),
: >> > and the MADT should include a source override that maps that
: >> > ISA interrupt number to a global interrupt number of 66 or
: >> > whatever (which maps to a SAPIC:intpin).
: >>
: >> This makes sense. It's however not how it is (unfortunately).
: >
: > The updated SPPA specification (HP's ia64 platform) has a section
: > devoted to the interrupt polarity and mode of the UART. It basicly
: > says this:
: > o The DIG64 HCDP table [supported] or the Mcrosoft SPCR table
: > [unsupported] tells whether the UART is a PCI device or not.
: > o PCI UARTs have level triggered, active low interrupts. They
: > are not described in ACPI then (reminder: this is SPPA).
: > o Non-PCI UARTs described in the ACPI namespace have interrupt
: > polarity and mode as described by _CRS in the device object!
: > o Non-PCI devices that are not decribed in the ACPI namespace
: > can still be mentioned in the HCDP table and we [FreeBSD]
: > will use the UART as console. Interrupt polarity and mode
: > should be assumed active low, level sensitive.
: > Currently we will panic the moment we try to go single-user
: > or multi-user because there will not be a device major number
: > assigned to the console. We need to catch this case someday.
: >
: > So: It appears that we need to interpret the _CRS method, field
: > or whatever. Especially the Interrupt Descriptor.
: >
: > Going to the source: in acpi_parse_resources() we need to create
: > a callback to MD code to tell it about polarity and mode. This
: > means tweaking the ACPI_RSTYPE_IRQ or ACPI_RSTYPE_EXT_IRQ cases.
: > Better would be to create bus methods for this (see for example
: > acpi_res_set_irq()).
:
: Yes. For i386 definitely it would make sense to have a bus method
: that bubbles back up to the nexus(4) and eventually calls the
: MD interrupt code. Maybe some kind of interrupt properties kobj
: interface:
:
: INTERFACE interrupt_properties
:
: #
: # Set the polarity to one of three values:
: # - conforming (conform to the bus attached to, the bus can set
: # this on the way up through the chain maybe?)
: # - active high
: # - active low
: #
: METHOD int set_polarity {
: device_t dev;
: device_t child;
: struct resource *irq;
: int polarity;
: };
:
: #
: # Set the trigger mode to one of three values:
: # - conforming (conform to the bus attached to, the bus can set
: # this on the way up through the chain maybe?)
: # - edge triggered
: # - level triggered
PC Card defines 'pulse triggered' interrupts too.
: #
: METHOD int set_trigger_mode {
: device_t dev
: device_t child;
: struct resource *irq;
: int trigger_mode;
: };
:
: Or I guess we could just add these to the bus interface.
:
: What do you think we should do?
Something like this in the bus interface, but this brushes up against
the bigger 'interrupt sharing' and 'fast interrupt sharing' problems, no?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030822.154515.101560696.imp>