Date: Fri, 22 Aug 2003 12:54:14 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 36551 for review Message-ID: <XFMail.20030822125414.jhb@FreeBSD.org> In-Reply-To: <20030821192214.GA25805@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
#
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?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030822125414.jhb>