From owner-freebsd-hackers@freebsd.org Tue Apr 25 09:55:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 145A7D4F4C6 for ; Tue, 25 Apr 2017 09:55:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C92431FB for ; Tue, 25 Apr 2017 09:55:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15678 invoked from network); 25 Apr 2017 09:58:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 09:58:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 05:55:42 -0400 (EDT) Received: (qmail 5287 invoked from network); 25 Apr 2017 09:55:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 09:55:41 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2D235EC8552; Tue, 25 Apr 2017 02:55:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] Date: Tue, 25 Apr 2017 02:55:40 -0700 References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <62AF263E-8028-44AB-8AFA-B5F08C96673D@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:55:44 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard = wrote: >=20 >> I found some basic reference material for the=20 >> "last irq" numbers for the A64 that is in the >> Pine64+ 2GB (and 1GB). . . >>=20 >> IRQ 27: PPI 11 interrupt, vector 0x006C >> (I've no clue about this one beyond it being a >> "Private Peripheral Interrupt" example, somehow >> specific to each core separately.) >=20 > Looks to be a timer, not that I can tell > much about it: >=20 > timer { > compatible =3D "arm,armv8-timer"; > interrupts =3D (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>; > }; >=20 > But looking around I've seen references to needing IRQ_TYPE_NONE > if the register is read-only, avoiding writes to read-only > registers, --with such timers as examples (not necessarily > A64 specific material though). Looking around more the read-only status seems to be an implementation defined area for PPI's. But I have other notes later below on what appears to me to be a mismatch between _HIGH vs. _LOW use and what arm_gic_architecture_specification_v2.0.pdf says. >> The rest of the IRQs are "Shared Peripheral >> Interrupt"s. . . >>=20 >> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >>=20 >> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >>=20 >>=20 >> There were some: >>=20 >> IRQ 114: EMAC interrupt, vector 0x01C8 >> IRQ 32: UART 0 interrupt, vector 0x0080 >>=20 >> And the first "last irq:" for each boot was >> one of: >>=20 >> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >>=20 >> Neither 107 or 64 occurred again after the first >> message for a boot. 64 showed up when no USB device >> was plugged in; 107 showed when one was left plugged >> in (plugged in before powering on the Pine64+ 2GB). >>=20 >> 1023 for the current irq number is special >> and not specific to the A64. >>=20 >>=20 >> So far I can not tell if the kernel mishandles the >> A64 in some way that leads to 1023's vs. if this >> is just what an A64 does for some odd reason, even >> with fully-correct software. Looking around I see in sys/arm/arm/gic_common.h : #define GICD_ICFGR(n) (0x0C00 + (((n) >> 4) * 4)) /* v1 = ICDICFR */ #define GICD_I_PER_ICFGRn 16 /* First bit is a polarity bit (0 - low, 1 - high) */ #define GICD_ICFGR_POL_LOW (0 << 0) #define GICD_ICFGR_POL_HIGH (1 << 0) #define GICD_ICFGR_POL_MASK 0x1 /* Second bit is a trigger bit (0 - level, 1 - edge) */ #define GICD_ICFGR_TRIG_LVL (0 << 1) #define GICD_ICFGR_TRIG_EDGE (1 << 1) #define GICD_ICFGR_TRIG_MASK 0x2 But Pine64+ is based on (from what I read): arm_gic_architecture_specification_v2.0.pdf and that does not match for the "polarity" part of GICD_ICFGR code in the above. Quoting (for both bits, focused on PPI to some extent but some material applies to SPIs as well). . . For each supported PPI, it is IMPLEMENTATION DEFINED whether software can program the corresponding Int_config field. [2F+1:2F] Int_config, field F For Int_config[1], the most significant bit, bit [2F+1], the encoding = is: =E2=80=A2 0 Corresponding interrupt is level-sensitive. =E2=80=A2 1 Corresponding interrupt is edge-triggered. Int_config[0], the least significant bit, bit [2F], is reserved, but see Table 4-19 for the encoding of this bit on some early implementations of this GIC architecture. [so reserved instead of polarity in general] For SGIs: Int_config[1] Not programmable, RAO/WI. [So 1's fit with SGIs for Int_config[1].] For PPIs and SPIs: Int_config[1] For SPIs, this bit is programmable.a For PPIs it is = IMPLEMENTATION DEFINED whether this bit is programmable. A read of this bit always returns the = correct value to indicate whether the corresponding interrupt is level-sensitive or = edge-triggered. [But SGIs and PPIs are not the same for Int_config[1].] As for what reserved bits are intended to be, quoting more places. . . Bit positions described as Reserved are UNK/SBZP. UNK/SBZP UNKNOWN on reads, Should-Be-Zero-or-Preserved on writes. In any implementation, the bit must read as 0, or all 0s for a bit = field, and writes to the field must be ignored. Software must not rely on the = field reading as 0, or all 0s for a bit field, and must use an SBZP policy to write to the field. [The Int_config[1] wording overrides the read part of the above.] So it would appear that use of IRQ_TYPE_LEVEL_HIGH is a violation of the intent for PPI's by it translating to include use of GICD_ICFGR_POL_HIGH which uses 1 instead of 0 for the reserved bit. [As for those "early" implementations. . .] On a GIC where the handling mode of peripheral interrupts is = configurable, the encoding of Int_config[0] for PPIs and SPIs, is: =E2=80=A2 0 Corresponding interrupt is handled using the N-N = model. =E2=80=A2 1 Corresponding interrupt is handled using the 1-N = model. [which I do not think applies to the A64, instead the N-N model applies to PPIs and the 1-N model to SPIs with no control to do otherwise. But it is very different from a high vs. low polarity when it does apply.] Quoting another place. . . In a multiprocessor implementation, if bit[1] of the Int_config field for any PPI is programmable then GICD_ICFGR1 is banked for each connected processor. This register holds the Int_config fields for the PPIs, interrupts 16-31. =3D=3D=3D Mark Millard markmi at dsl-only.net