From owner-freebsd-mips@FreeBSD.ORG Sun Jan 4 06:39:51 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47D61A24 for ; Sun, 4 Jan 2015 06:39:51 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC8633FF4 for ; Sun, 4 Jan 2015 06:39:50 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id n3so1494077wiv.11 for ; Sat, 03 Jan 2015 22:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PHT4tVwzEE/JmPi1iEnXgjJQAMdxWKFiTtH/8Gv0dcE=; b=pENrrpRu6orTmr0rA/vp7QC2P/H0HUdBez0p74dKCCHf1EM/aS12KbzoJEGh2Zllmy IKH+0omWkz1nG9tfdOK+ffWf2l1jgFBpQUl3/QP2g95m8L+7wmyhDefBy1ncsZWskrQK N4mMPmaJDei2th0Ztrvhq6w8pLQi1ZnNZ2c8dIUgsyuu3Ld0ZW3uU0IvKTIXO3mR4XXt ouKdkAdqzxdPb8RgbKbqFVtZGAvABfew26hGs6XI2U38ZyjCpodzB6fjGMmb2N18zxxI aYEIQvKJC2vcxWKZdT4xCGyauiKGVZQq7I30+Qw4VEDxKVK0wpAHN0KajrinN6tCqdb7 XKgg== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr163364438wjb.68.1420353589285; Sat, 03 Jan 2015 22:39:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sat, 3 Jan 2015 22:39:49 -0800 (PST) In-Reply-To: <20150103214818.GJ3265@cicely7.cicely.de> References: <20150103023713.GB3265@cicely7.cicely.de> <20150103114302.GD3265@cicely7.cicely.de> <20150103140918.GF3265@cicely7.cicely.de> <20150103214818.GJ3265@cicely7.cicely.de> Date: Sat, 3 Jan 2015 22:39:49 -0800 X-Google-Sender-Auth: tou9BfrHQDJdd7j5gj0apaoDYuA Message-ID: Subject: Re: USB stability problem on AR9331 with stable/10 From: Adrian Chadd To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Cc: Bernd Walter , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 06:39:51 -0000 On 3 January 2015 at 13:48, Bernd Walter wrote: > On Sat, Jan 03, 2015 at 03:09:18PM +0100, Bernd Walter wrote: >> On Sat, Jan 03, 2015 at 12:43:02PM +0100, Bernd Walter wrote: >> > On Sat, Jan 03, 2015 at 12:54:58AM -0800, Adrian Chadd wrote: >> > > Hi! >> > > >> > > Can you try FreeBSD-HEAD? See if it's more stable? >> > > >> > > There may be some USB PLL related stuff that isn't in stable/10. >> > > (I remember general USB instability on the AR933x chips that was >> > > finally resolved in ath9k/linux and I /think/ I ported it all to >> > > FreeBSD-HEAD.) >> > >> > Ah - great. >> > PLL makes somewhat sense, because in some cases the USB device even >> > seem to have crashed and needed a power cycle. >> > Unfortunately head doesn't compile for me right now because of missing >> > dnstap/dnstap_config.h in libunbound, but I will retry later or go back >> > a few revs. >> >> Didn't get very far: >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat >> Clearing /tmp (X related). >> Updating motd:. >> Mounting late file systems:. >> Starting ntpd. >> Starting rtadvd. >> swapon: mdconfig (attach) error: md99 on file=/home/swap0 >> Generating RSA1 host key. >> 2048 9c:59:9c:a9:83:bf:d2:c0:b6:31:b3:dc:a0:4b:00:2a root@apx2.cicely.de (RSA1) >> Generating RSA host key. >> 2048 ec:5a:29:76:7d:4a:8d:8e:f0:ca:06:d1:e2:a6:78:af root@apx2.cicely.de (RSA) >> Generating DSA host key. >> 1024 c3:f8:2d:98:0c:a1:5b:40:f8:2c:98:be:dd:53:3f:5f root@apx2.cicely.de (DSA) >> Generating ECDSA host key. >> 256 b7:75:c3:53:76:cd:77:22:a5:95:be:36:39:a8:97:6c root@apx2.cicely.de (ECDSA) >> Generating ED25519 host key. >> 256 0d:ff:70:65:f5:69:43:26:84:f2:22:d2:52:16:ec:bf root@apx2.cicely.de (ED25519) >> Performing sanity check on sshd configuration. >> Starting sshd. >> Starting sendmail_submit. >> (da0:umass-sim0:0:0:0): . CDB: 28 00 00 19 5a c0 00 00 50 00 >> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >> (da0:umass-sim0:0:0:0): Retrying command >> (da0:umass-sim0:0:0:0): . CDB: 28 00 00 19 5a c0 00 00 50 00 >> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >> (da0:umass-sim0:0:0:0): Retrying command >> (da0:umass-sim0:0:0:0): . CDB: 28 00 00 19 5a c0 00 00 50 00 >> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >> (da0:umass-sim0:0:0:0): Retrying command >> (da0:umass-sim0:0:0:0): . CDB: 28 00 00 19 5a c0 00 00 50 00 >> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >> (da0:umass-sim0:0:0:0): Retrying command >> (da0:umass-sim0:0:0:0): . CDB: 28 00 00 19 5a c0 00 00 50 00 >> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >> g_vfs_done():da0a[WRITE(offset=3988025344, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=3988492288, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=3988496384, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=3988500480, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=3988504576, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=3988594688, length=4096)]error = 5 >> g_vfs_done():da0a[READ(offset=4651474944, length=57344)]error = 5 >> g_vfs_done():da0a[WRITE(offset=6618730496, length=4096)]error = 5 >> g_vfs_done():da0a[WRITE(offset=6625198080, length=12288)]error = 5 >> g_vfs_done():da0a[WRITE(offset=6625234944, length=4096)]error = 5 >> g_vfs_done():da0a[READ(offset=850747392, length=40960)]error = 5 >> vnode_pager_generic_getpages_done: I/O read error 5 >> vm_fault: pager read error, pid 768 (sshd) >> vnode_pager_generic_getpages_done: I/O read error 5 >> >> I will swap for another board now. >> Reason is that I have one board running on a OS version, which is about >> 1.5 years old and it shows this problem only from time to time. >> I even use it to copy the rootfs from nfs to the stick because of the >> endian issue with mips. >> It is very hard to say when this happens, because copying usually works, >> but once you put some additional load, like compiling, or in this case >> creating host keys. >> Now this board with recent stable/current shows this problem extremly >> often. >> I want to rule out that I put a broken board into my test mix, because >> it was a new one. > > Ok, I can't tell for sure if there is some hardware related influence, > but I'd tested 3 Dragino MS14-P (likely same batch) and retested with one > Carambola 2, which all showed the problem sooner or later. Hm, I wonder which particular AR933x revision they're using. Are you providing them enough power? -adrian From owner-freebsd-mips@FreeBSD.ORG Sun Jan 4 10:31:27 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F0F9CFE; Sun, 4 Jan 2015 10:31:27 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BA192E68; Sun, 4 Jan 2015 10:31:26 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t04AUe5p014836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2015 11:30:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t04AUZFp008240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 11:30:36 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t04AUZC0013706; Sun, 4 Jan 2015 11:30:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t04AUZ3K013705; Sun, 4 Jan 2015 11:30:35 +0100 (CET) (envelope-from ticso) Date: Sun, 4 Jan 2015 11:30:35 +0100 From: Bernd Walter To: Adrian Chadd Subject: Re: USB stability problem on AR9331 with stable/10 Message-ID: <20150104103035.GK3265@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20150103023713.GB3265@cicely7.cicely.de> <20150103114302.GD3265@cicely7.cicely.de> <20150103140918.GF3265@cicely7.cicely.de> <20150103214818.GJ3265@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter , ticso@cicely.de, "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 10:31:27 -0000 On Sat, Jan 03, 2015 at 10:39:49PM -0800, Adrian Chadd wrote: > On 3 January 2015 at 13:48, Bernd Walter wrote: > > On Sat, Jan 03, 2015 at 03:09:18PM +0100, Bernd Walter wrote: > >> > >> I will swap for another board now. > >> Reason is that I have one board running on a OS version, which is about > >> 1.5 years old and it shows this problem only from time to time. > >> I even use it to copy the rootfs from nfs to the stick because of the > >> endian issue with mips. > >> It is very hard to say when this happens, because copying usually works, > >> but once you put some additional load, like compiling, or in this case > >> creating host keys. > >> Now this board with recent stable/current shows this problem extremly > >> often. > >> I want to rule out that I put a broken board into my test mix, because > >> it was a new one. > > > > Ok, I can't tell for sure if there is some hardware related influence, > > but I'd tested 3 Dragino MS14-P (likely same batch) and retested with one > > Carambola 2, which all showed the problem sooner or later. > > Hm, I wonder which particular AR933x revision they're using. The one on all the Dragino is marked: AR9331-AL3A PPW718,006C 1324 KOREA The Carambola is shielded and soldered shut. With the modules I can remove the cap since it is designed to be removeable, but this is the devboard and they added some solder at some points. I can unsolder it if required. A single module, which I'd bought at the same time, has the following: AR9331-AL3A PPU680,001C 1316 KOREA No sure if it has exactly the same chip on the devboard. The Carambola however seems to be running more stable. I've managed to build pkg 2 times of 3 tries, while the Dragino was never able to complete the build in countless tries. > Are you providing them enough power? It is very different in both cases. The Carambola devboard has a single micro-USB running both power and USB-console-UART, so I power it using a self powered hub, which has a switching mode 3.5A rates supply. The devboard has a 5 to 3.3V switching regulator running the module and it passes the 5V to the USB port. The 1.2V is somehow generated on the module. The Dragino has a wide range 9-15V input with 3 regulators. An RT8250 for 5V and 3.3V each - the 5V is used for the USB, the 3.3 for the rest. Don't know how the 1.2V is generated, since all I can find is a coil. Then there is a 1117 5V, which I can only guess that it is used for the moduleslot, which is intended to fit some arduino IO module. I run the board using 12V from a decent lab type bench supply with current limit at 0.5A, which is rated current and well below what it really used. But to be honest - I've already wondered about the power myself, since the only electrolytic cap is for the 1117, while the RT8052 use ceramic only and high rated ceramic have a high DC bias loss plus the RT8052 is not a very high frequency chip. So I just checked and the power rails look fine under a scope. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 5 08:44:38 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CB3EC50; Mon, 5 Jan 2015 08:44:38 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E39F03BDA; Mon, 5 Jan 2015 08:44:37 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so3645856wib.5; Mon, 05 Jan 2015 00:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=aL6P/LL8uGERFmXFwIeCUUJPHi6wdDa5jNJpr8Rq3Oo=; b=XmBnoKf95+cCer8jfrshEDtHPGgRZkbct9++0dRKyNHj8g5H9nC1yan4YoEQNLsZq0 L742R5zkEt8A2JcVLCw1TURnVsmUPgpIzZFd4xGP09E6nu66rFrleVDtCk6DmXbUTPM2 rThGkMDcV6nZmURBbp+NN5MVg/XZqaU7XkyW1SkHptNnlTgVVTL4LzE/FQryeG1wNcx5 OXqU5HdBXGE4Smhnhg6mj4To3TVXPcvvvKyxhTfiy4lWm01S0h7FJDxQ6uhZ3FLb7jUH 71/bQwwt8NcBis8s8Ry2MiOurywFUXMgpcDV0fWn8bErYypS/UppjSplmiJgqCycXoQU 5hBQ== MIME-Version: 1.0 X-Received: by 10.180.87.36 with SMTP id u4mr23171795wiz.20.1420447475332; Mon, 05 Jan 2015 00:44:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 00:44:35 -0800 (PST) Date: Mon, 5 Jan 2015 00:44:35 -0800 X-Google-Sender-Auth: DtjVS3U0cYbU6OwiRX2upXj042s Message-ID: Subject: interrupt muxes, bus memory space and other fun amusing things From: Adrian Chadd To: John Baldwin , Ian Lepore , Warner Losh , "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 08:44:38 -0000 Hi, I have FreeBSD-HEAD booting on the newer Atheros MIPS SoC (QCA955x series) but now I have to sort out the mess which is how the memory and IRQs are routed. I'd appreciate some help with this. Unlike something hierarchical like PCI, there's a mostly-flat device memory layout. Ie, things behind each interrupt "mux" aren't grouped into some contiguous memory region. On earlier chips the only interrupt multiplexer is the atheros peripheral bus, and it has things like USB 1, UART, hwpmc, etc. The wifi, EHCI USB, PCI, ethernet were assigned normal MIPS CPU interrupts and those devices hung off of nexus0. Now with the AR934x the on-board wifi hides behind one level of interrupt mux, which I'm currently getting wrong by referencing IP2 (nexus irq0) directly. Now, that's good enough for this, but not for what the QCA955x does. The QCA955x has: * IP6 - the APB mux - it has a mask and status register pair for interrupts for peripheral devices; * IP2 - PCIE root complex 1, WMAC * IP3 - PCIE root complex 2, USB1, USB2. The more annoying thing is that IP6 has its own status/mask registers, but IP2/IP3 have a shared status register for multiplexing. (Ie, half the bits are for IP2, half the bits are for IP3.) So if I were Linux, I'd just implement a mux that pretends to trigger interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to irq0..7, then they pick another IRQ range for the AHB interrupts, and another IRQ range for the IP2/IP3 interrupt mux. They have a hard-coded mux that takes care of triggering the software IRQ based on the hardware interrupt and mux register contents. So, how should I approach this? The other thing - right now mips/atheros/apb.c registers for a memory region that happens to be big enough to cover the vast majority of devices in the system. However, now I have regions covered by the APB, the IP2 mux and the IP3 mux. If I were evil, and I've thought about it, I've thought about just extending apb.c to include registering for three nexus0 interrupts and doing the muxing itself. That way only one bus thing is covering the entirety of peripheral memory. But it seems .. inelegant. Thanks! The QCA955x is pretty sweet btw - 600MHz DDR3, 720MHz CPU clock, dual-issue out of order pipeline. It's pretty freaking fast. ath> go 0x80050100 ## Starting application at 0x80050100 ... CPU platform: Atheros AR9558 rev 0 CPU Frequency=720 MHz CPU DDR Frequency=600 MHz CPU AHB Frequency=200 MHz platform frequency: 720 MHz CPU reference clock: 40 MHz CPU MDIO clock: 40 MHz .. -adrian From owner-freebsd-mips@FreeBSD.ORG Mon Jan 5 16:47:56 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92389243 for ; Mon, 5 Jan 2015 16:47:56 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 569D42E33 for ; Mon, 5 Jan 2015 16:47:56 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id tr6so19854504ieb.21 for ; Mon, 05 Jan 2015 08:47:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=bag0jbP6ZijNGERzcQVhzHD44V/jvQ/WaG84dEsqM8U=; b=V6XxlH9SsmH16IWllKtD4svpvVDh4WRTUMs9YZVRiyhBAtIMw/Pkn7cNdjDtjqslKv 5Z5fr0c/XQwtgfDj70sJGf/ml29bRVXsSgRsuwGnwh6LWcoNFW+HdDZfWPy+YeOKMyOG qu9wlt7TonpUOJA1HF4MT78MmEzWGpl3OK40lBQC6eBHsohMce9oYzwqtFXOrbHTddGL P0yGOyn8qaNAqBxJPNf3hF7mGWf0NJalhYz53Y0R0SFnhCoQnLE1V8mHr6JOpauBiitE qYH7WXG/lFoi5rNISa/aXBENuuHhDuWnRkBi729iLe6Ba6tjTEqKptXiK5rr33qzK1n9 lD3Q== X-Gm-Message-State: ALoCoQnqez6KLR0KJ9Q+zflR2X7TZm21z1CgSVv2cBOn7r4mkUgXywM/uQrO1y5Y3xdBvnmkIvE1 X-Received: by 10.107.170.98 with SMTP id t95mr79782582ioe.7.1420476081085; Mon, 05 Jan 2015 08:41:21 -0800 (PST) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id 5sm26807062iom.7.2015.01.05.08.41.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 08:41:19 -0800 (PST) Sender: Warner Losh Subject: Re: interrupt muxes, bus memory space and other fun amusing things Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2A0DCA3C-28BD-4620-8D80-8CC4E9EB79BE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Mon, 5 Jan 2015 09:41:17 -0700 Message-Id: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: Warner Losh , Ian Lepore , John Baldwin , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:47:56 -0000 --Apple-Mail=_2A0DCA3C-28BD-4620-8D80-8CC4E9EB79BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > So if I were Linux, I'd just implement a mux that pretends to trigger > interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to > irq0..7, then they pick another IRQ range for the AHB interrupts, and > another IRQ range for the IP2/IP3 interrupt mux. They have a > hard-coded mux that takes care of triggering the software IRQ based on > the hardware interrupt and mux register contents. >=20 > So, how should I approach this? Same way. You=E2=80=99d create an interrupt device that registers an = interrupt for the mux, then farms it out based on the contents of the registers. The MIPS interrupt handler might need some work (arm did) to allow this to happen, but it isn=E2=80=99t super difficult (though IIRc = it is tedious). Warner --Apple-Mail=_2A0DCA3C-28BD-4620-8D80-8CC4E9EB79BE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUqr6uAAoJEGwc0Sh9sBEADiUP/0E+HHna+qJYtDDPXDK+4VcA LZizeR3Eg1MOs58i4vBvkw4DUbJSKFQV2d3eowfh5bcZ9C7GxPin53Re0ckCG9zq W4VJgF2Pb7taZ1wEQH9R/djdX07/JGBiHE9lkVt/Z1mS4TFcQTjRXpHL29BZMO7k atswBinLFXKH0P6rTUlTNIylYaOJPWw3RkRpMMD/Li4LPQBxkBSgml86FP79oh6N h71kX3qeJSy1egzUxs2pfO6H6ksqQu7tL05hqhFcCB7KVctfKvuqVKHpDdMaZ37h HHvaq18cUl8QGsrlSrgZ1krhLvX+O9kIO0cIGqDBZctZpJO76opQfD55/YwlD0uy HGaRwzrCHnvoaI5j3uUprEF2GwfEpkS5VdY7FkjunYRjFEVLGCEwTWzgVFJ19fer ofz/PFFLF1ebby7AAlLi0e2lXYKj17d+lTJfzLD68FYHvwLILKV1/e9425ZxVeEt R60qe3iozSyMqcnfwnLF0x9N+tmZmyxLa3H/ybPg31W0y4JXwKyvMOxYoektRuXM Ne5X/7LOCj72if8pls+Ko3QJ9wEMj+VlFUUF8HnSkz/z3PELpwRONpszu3dUBHiG qc47nqPgyNP/9JHYZ+Bag919dTDnGMGUSP7lzwYKJjpAHNSdIgUAR7CEuntFlEUm TJCXMTGKOwRyk3BqtxNI =vqwO -----END PGP SIGNATURE----- --Apple-Mail=_2A0DCA3C-28BD-4620-8D80-8CC4E9EB79BE-- From owner-freebsd-mips@FreeBSD.ORG Mon Jan 5 20:32:36 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8BE7E92; Mon, 5 Jan 2015 20:32:36 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5DA33AC6; Mon, 5 Jan 2015 20:31:48 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so4089954wiv.7; Mon, 05 Jan 2015 12:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=KyK1vkKU7MuSmgDqp6/rpgpcgR1K1fkbIQ+fq0z3Vzs=; b=fkRIOaal/ve2TwNkrjzgEJYW0ASmHw5PyF5aVLCMUfHctfBYpkO8kzDGMmhOD/L7Qn LRhmK5d59wipTPrDMIQhsUqVgnJCiy6czmvxSHcKMZ6clqYvaA9Sqsw2jBOBUZuAc4xp hwS97zoRmyqgB5cxq9eHKix4jtaOUCHRxvf1ujQZtrZuXnfbCApylQJ90SGwXWQFzD1B bcVqsizCu2ciZmR7KWua4D6cBls9SClEjdOhrAAh3RM0Xzo6yxx/FXdILov9GKJGcp7F LT4eab3mGR4lzuEJJVc4yFiqj+VIjcF0O25yiHE5uSUImtQ6eda6qmMmZbmQV8ezFfDm f4rQ== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr180109268wjb.68.1420489907169; Mon, 05 Jan 2015 12:31:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 12:31:47 -0800 (PST) In-Reply-To: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> References: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> Date: Mon, 5 Jan 2015 12:31:47 -0800 X-Google-Sender-Auth: qM3Tskxy6ZnNDHb1k6GAIHn1ADI Message-ID: Subject: Re: interrupt muxes, bus memory space and other fun amusing things From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Warner Losh , Ian Lepore , John Baldwin , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:32:36 -0000 On 5 January 2015 at 08:41, Warner Losh wrote: > >> So if I were Linux, I'd just implement a mux that pretends to trigger >> interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to >> irq0..7, then they pick another IRQ range for the AHB interrupts, and >> another IRQ range for the IP2/IP3 interrupt mux. They have a >> hard-coded mux that takes care of triggering the software IRQ based on >> the hardware interrupt and mux register contents. >> >> So, how should I approach this? > > Same way. You=E2=80=99d create an interrupt device that registers an inte= rrupt > for the mux, then farms it out based on the contents of the registers. > The MIPS interrupt handler might need some work (arm did) to > allow this to happen, but it isn=E2=80=99t super difficult (though IIRc i= t is tedious). Ok. So I can do that, but then devices hang off of which bus? nexus0? Or this mux? Can I create a mux bus to hang things off of that just pass all the memory region requests up to the parent bus (nexus in this case) ? -adrian From owner-freebsd-mips@FreeBSD.ORG Tue Jan 6 03:10:07 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 419B14CC for ; Tue, 6 Jan 2015 03:10:07 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05D592048 for ; Tue, 6 Jan 2015 03:10:06 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id vy18so704209iec.9 for ; Mon, 05 Jan 2015 19:10:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=pYCQHaKsFhur0qC0TcGiyzAaBvte7L4FbNfBpZF1az0=; b=MeOsrOEMdawH/HFuj8Ou4xECDb6rxC7Q88hb26VwXaA+PqAwlmSUaWTZ/vmF6C9Qfz q3an3dFic6a/yonlUKC+7WFtCMMm3q1gN+gs+NLBBBBQNUbMBgb8O7g4DYk3bF5SfMkT huGojMA0BEVuDLTdGmmEvxTkokQ65BHB+y488ChwCnf/NIWNrT2n6YGjaI1QM3m2jmmu R/pd4vg1apKcUMGxOM2kVPrFujAobPJvwbuOlK51XChfzIlq2jrSmn63zfnGXBB8oxIl eUDfut8eYNW5nN4PicSjIIevQ+d4B4DP2QcDGMdwEuaymsV3lBNmczXeOKDP46Bp7ylm FQCw== X-Gm-Message-State: ALoCoQmlO1Th6iLADNVwp+1a5jKUa/1c1KJ4V5VaZq+L3iRux8bwnNPACugGC/ek/fc/UCPvgoT1 X-Received: by 10.42.253.195 with SMTP id nb3mr5558804icb.34.1420513805881; Mon, 05 Jan 2015 19:10:05 -0800 (PST) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id aw9sm4457916igc.18.2015.01.05.19.10.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 19:10:05 -0800 (PST) Sender: Warner Losh Subject: Re: interrupt muxes, bus memory space and other fun amusing things Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5E74F1EF-78EE-4895-9FE8-3630FEEFDAB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Mon, 5 Jan 2015 20:10:04 -0700 Message-Id: <9F6D585C-7590-4D25-879B-A76D8A959E01@bsdimp.com> References: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: Warner Losh , Ian Lepore , John Baldwin , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:10:07 -0000 --Apple-Mail=_5E74F1EF-78EE-4895-9FE8-3630FEEFDAB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 5, 2015, at 1:31 PM, Adrian Chadd wrote: >=20 > On 5 January 2015 at 08:41, Warner Losh wrote: >>=20 >>> So if I were Linux, I'd just implement a mux that pretends to = trigger >>> interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to >>> irq0..7, then they pick another IRQ range for the AHB interrupts, = and >>> another IRQ range for the IP2/IP3 interrupt mux. They have a >>> hard-coded mux that takes care of triggering the software IRQ based = on >>> the hardware interrupt and mux register contents. >>>=20 >>> So, how should I approach this? >>=20 >> Same way. You=E2=80=99d create an interrupt device that registers an = interrupt >> for the mux, then farms it out based on the contents of the = registers. >> The MIPS interrupt handler might need some work (arm did) to >> allow this to happen, but it isn=E2=80=99t super difficult (though = IIRc it is tedious). >=20 > Ok. So I can do that, but then devices hang off of which bus? nexus0? > Or this mux? >=20 > Can I create a mux bus to hang things off of that just pass all the > memory region requests up to the parent bus (nexus in this case) ? The hard part is mapping an interrupt provided by a mux to a resource number. However, we already do this for the =E2=80=98hard wired=E2=80=99 = interrupts that are muxed through APIC or PIC controllers on x86. I fail to see how this is any different, apart (perhaps) from the need to do things = dynamically in some way. Warner --Apple-Mail=_5E74F1EF-78EE-4895-9FE8-3630FEEFDAB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUq1IMAAoJEGwc0Sh9sBEAFyQQAOXZ4xZQwhR3shuyzDifDy25 /F6t4cjbLZbEEWTAoOpTmIVZQkiXplZJ8qQkvzNXVOhYhYFrYTz2NzcGqv2OuWzH /pSz5STyg8llMKgmMQr30ccZamwjmPDKrasqrQJB1dCZnHCzBiJyNRLvSlwHhn4Q WJeRthfvmWduV3Yg8eGvlr0sNX+6Tb1XqmuTFjCZF/vUPQRnLZf/s44rry+ahSHb e6g3zAK+XmprChXgBW2b66q3dZa7kuWAaYepCfGDcjsiPBu957IBsjJ67KO7KGm4 TRs3XKmjL4dzJJ1fxp46B28ZysllkMz2fJ5XBs2QdsxpF1aMG5iGMvPq80RLVo9Q ZWkOPwgAQEQ7Z2cXjKWU3vwAPepx13BoFPKrfc9AXFUpAZ0ZjpXPdlCFb8fK2z0g qRVaTO+5Qz2vO427KDDppNX5b9qDL2CmljWJ/khcEByFjmjl+Jqq6G52nWCyhNBT /tvpsyiF8i/umriNwD3r+/apdexVwYxc8NE5btcjNQ9w96v3N86sFClBTQ9vihj5 zmGaAnN9L1nrHMfK+Z9K9mz0qNJXwGo9INGRsqn3VVS8aRngSwubF74v5AoHo5eB Tza4RfuGA0g2KoRpvpT3EcY7WVRGfeL7evmEbIi3EAEIJ+nmV3oFCDBtdfMqb8zz rMM+aoQh7XGKIfYjl+q+ =zvzM -----END PGP SIGNATURE----- --Apple-Mail=_5E74F1EF-78EE-4895-9FE8-3630FEEFDAB6-- From owner-freebsd-mips@FreeBSD.ORG Tue Jan 6 03:14:48 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78126519; Tue, 6 Jan 2015 03:14:48 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4852F2121; Tue, 6 Jan 2015 03:14:47 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y8KbQ-000JSs-Ts; Tue, 06 Jan 2015 03:14:41 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t063Ed7N033810; Mon, 5 Jan 2015 20:14:39 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18AboSO+yg7zWA+71/q3x5Z Message-ID: <1420514079.14601.7.camel@freebsd.org> Subject: Re: interrupt muxes, bus memory space and other fun amusing things From: Ian Lepore To: Warner Losh Date: Mon, 05 Jan 2015 20:14:39 -0700 In-Reply-To: <9F6D585C-7590-4D25-879B-A76D8A959E01@bsdimp.com> References: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> <9F6D585C-7590-4D25-879B-A76D8A959E01@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id t063Ed7N033810 Cc: Warner Losh , "freebsd-mips@freebsd.org" , John Baldwin X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:14:48 -0000 On Mon, 2015-01-05 at 20:10 -0700, Warner Losh wrote: > > On Jan 5, 2015, at 1:31 PM, Adrian Chadd wrote: > >=20 > > On 5 January 2015 at 08:41, Warner Losh wrote: > >>=20 > >>> So if I were Linux, I'd just implement a mux that pretends to trigg= er > >>> interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to > >>> irq0..7, then they pick another IRQ range for the AHB interrupts, a= nd > >>> another IRQ range for the IP2/IP3 interrupt mux. They have a > >>> hard-coded mux that takes care of triggering the software IRQ based= on > >>> the hardware interrupt and mux register contents. > >>>=20 > >>> So, how should I approach this? > >>=20 > >> Same way. You=A2d create an interrupt device that registers an inter= rupt > >> for the mux, then farms it out based on the contents of the register= s. > >> The MIPS interrupt handler might need some work (arm did) to > >> allow this to happen, but it isn=A2t super difficult (though IIRc it= is tedious). > >=20 > > Ok. So I can do that, but then devices hang off of which bus? nexus0? > > Or this mux? > >=20 > > Can I create a mux bus to hang things off of that just pass all the > > memory region requests up to the parent bus (nexus in this case) ? >=20 > The hard part is mapping an interrupt provided by a mux to a resource > number. However, we already do this for the =A1hard wired=A2 interrupts > that are muxed through APIC or PIC controllers on x86. I fail to see ho= w > this is any different, apart (perhaps) from the need to do things dynam= ically > in some way. >=20 > Warner >=20 It sounds like mips is ready for intrng. Which would then give us ppc, arm, and mips all with a conceptually-similar intrng-like layer for handling non-hierarchical interrupt sources and controllers and mapping between rman and hardware ideas of interrupt number. Hmmm. This would be the time to argue for a nice shiny new MI intrng implementation... except that we can't quite drive even the arm-only version to completion. -- Ian From owner-freebsd-mips@FreeBSD.ORG Tue Jan 6 03:26:46 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1554A64F for ; Tue, 6 Jan 2015 03:26:46 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBBE82292 for ; Tue, 6 Jan 2015 03:26:45 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id z20so4236102igj.4 for ; Mon, 05 Jan 2015 19:26:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=kQ5a0muy5IOh9dHYTsugoeVL/AmB5bUEFdWwj2mYKH4=; b=YtmNdu747P4LEE53+/LlxNycBt/Y8YZdtQnL1pyYU7+A4Zi0QY9ysyNcxFDwqke0BE fubx8OwH03YG+SUwIu/MsfFplRTGf4D0U4fhsZiOtId+/Y/dAkaqCMo8MO7vfkuNDJg3 szSe8iBKtIcPF6Vl+gL9J77mZBKMRLWQjCgeRx+rc9IzUr+kl0/JWVS++5dkychFV8UP UTnu07ZWp+nQzN0vjoD8Wz+jPeaDdl3WcmnGD6qQ1JLAIMDdWwnWKvA8ncNn9dwcDmwz rdEttEnxmqU1FQj67TGkrBExlgq504jDRgLnTF6ajG6yXilQFjh5ZVog8iIZsBX0cFJo Nziw== X-Gm-Message-State: ALoCoQmnrm5oCTcNUJb3rwbLEMGW0+50xImYcaQDTmQbUA2rGUx4nnbVZrPuCIZkIjEbWuCchmRp X-Received: by 10.50.138.107 with SMTP id qp11mr14051096igb.46.1420514802151; Mon, 05 Jan 2015 19:26:42 -0800 (PST) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o72sm27502939ioo.14.2015.01.05.19.26.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 19:26:41 -0800 (PST) Sender: Warner Losh Subject: Re: interrupt muxes, bus memory space and other fun amusing things Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5A80BF58-FCAC-4A55-8550-F708A28358CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <1420514079.14601.7.camel@freebsd.org> Date: Mon, 5 Jan 2015 20:26:39 -0700 Message-Id: <3AB1B833-6D17-44C4-B588-8CEAB0CA4A42@bsdimp.com> References: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> <9F6D585C-7590-4D25-879B-A76D8A959E01@bsdimp.com> <1420514079.14601.7.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1993) Cc: Warner Losh , "freebsd-mips@freebsd.org" , John Baldwin X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:26:46 -0000 --Apple-Mail=_5A80BF58-FCAC-4A55-8550-F708A28358CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 5, 2015, at 8:14 PM, Ian Lepore wrote: >=20 > On Mon, 2015-01-05 at 20:10 -0700, Warner Losh wrote: >>> On Jan 5, 2015, at 1:31 PM, Adrian Chadd wrote: >>>=20 >>> On 5 January 2015 at 08:41, Warner Losh wrote: >>>>=20 >>>>> So if I were Linux, I'd just implement a mux that pretends to = trigger >>>>> interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to >>>>> irq0..7, then they pick another IRQ range for the AHB interrupts, = and >>>>> another IRQ range for the IP2/IP3 interrupt mux. They have a >>>>> hard-coded mux that takes care of triggering the software IRQ = based on >>>>> the hardware interrupt and mux register contents. >>>>>=20 >>>>> So, how should I approach this? >>>>=20 >>>> Same way. You=E2=80=99d create an interrupt device that registers = an interrupt >>>> for the mux, then farms it out based on the contents of the = registers. >>>> The MIPS interrupt handler might need some work (arm did) to >>>> allow this to happen, but it isn=E2=80=99t super difficult (though = IIRc it is tedious). >>>=20 >>> Ok. So I can do that, but then devices hang off of which bus? = nexus0? >>> Or this mux? >>>=20 >>> Can I create a mux bus to hang things off of that just pass all the >>> memory region requests up to the parent bus (nexus in this case) ? >>=20 >> The hard part is mapping an interrupt provided by a mux to a resource >> number. However, we already do this for the =E2=80=98hard wired=E2=80=99= interrupts >> that are muxed through APIC or PIC controllers on x86. I fail to see = how >> this is any different, apart (perhaps) from the need to do things = dynamically >> in some way. >>=20 >> Warner >>=20 >=20 > It sounds like mips is ready for intrng. Which would then give us = ppc, > arm, and mips all with a conceptually-similar intrng-like layer for > handling non-hierarchical interrupt sources and controllers and = mapping > between rman and hardware ideas of interrupt number. Hmmm. This = would > be the time to argue for a nice shiny new MI intrng implementation... > except that we can't quite drive even the arm-only version to > completion. Maybe now=E2=80=99s the time? Warner --Apple-Mail=_5A80BF58-FCAC-4A55-8550-F708A28358CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUq1XwAAoJEGwc0Sh9sBEAPfYQALK8VaS+NpppE60yn50gkxEm rU+w+i4yMg+R7yhTZhytNMuIL0BA0w9BakGmmD9K0A3JXbF7aHBt+w/LwWwVOAfH 025rZppZK2lveboFQ3t2xngsdwFC6KmsSY6tFsA1SR66HFeO29Bh2fisxtNmqdZP uvyZ1/J7nPGphr+3PPx8e/lA+qfijeP2hfe6axYsiuYKH6sb0qB0A/wcM/isznDa L5hdmKVYdryk0TSbgEbHpz4IhaWx+zdHdj9ULi7G8bZhq3qF/raNrrm32bSS5y8j Uroq8BlAVOKGUxOQqHdlwsnj2wZpJrTStWbt7eYrUOi7okv6VTc5ye9oGo37T9WS 9nh27DsOPfNzJHMA3sDjTUEM7tI84awpG/4oSAlveQTQI26xE2ziqXOWhF4kzJOc IKEv+22ikjsxMIlbCLu5ECfYpsFqq2KMhEIikAUcAUfV7tMl1/cOjAL37yXyC9JU ABlFUYJ6lYbQQDKnnT/icsXeTOLioyV3ZixdqTE12bJY25IMeftLlWENqyTTFCDa 5bH1qkNgPbzRrosBm3Y6GO4w5YEVIskbASXFCASGVGFzU+Iz43fFQtQC2e3iQWdr rvX2xzMIUvQQwEmKucJHsyCcxgQRX0whsSegDNJ7vjNYiq3UBLhPLs78+EKVOaBI BoBQwUTWN80zcnJUz9g6 =tWdH -----END PGP SIGNATURE----- --Apple-Mail=_5A80BF58-FCAC-4A55-8550-F708A28358CB-- From owner-freebsd-mips@FreeBSD.ORG Tue Jan 6 03:47:20 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E04457BE; Tue, 6 Jan 2015 03:47:19 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82B9B25C2; Tue, 6 Jan 2015 03:47:19 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so5320355wib.3; Mon, 05 Jan 2015 19:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QMO/5WC2dCTls3MpZJLlJY1VzVT+Tag0Qdz8p1v6LSA=; b=HlYTWvjReaLYsnF7hg7JdN+rTsHOlYurT2I9O3fS1aFdy0JCcwWhaVVa3OG2EOd6sZ EiKc60SLVBI2Vl2ZyHVBmerqCALlHBGnjScP0++Dp/IuQZy5o3T22hyvdUAHVcvpa3Ar 3Kv0INa22j9WCTXkTp4zJnXLZFr9efWD6zXo0sumQRimxek/8Cmn7fj6uU+WeEFN5n/U g8CcSw54vCO1uwVlLfc3iTOCkCT0WAaNr1vkQexetkSWJy5oyxADmirilOWjmJekH6uA yVk8CxDvMjAHlLRh6kJPbPEYq64NQQvJ9RiBrXjVfGDo+JwlhTnhcQgknxM6W9sRFd0B LtUg== MIME-Version: 1.0 X-Received: by 10.180.20.6 with SMTP id j6mr31705715wie.59.1420516037881; Mon, 05 Jan 2015 19:47:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 19:47:17 -0800 (PST) In-Reply-To: <3AB1B833-6D17-44C4-B588-8CEAB0CA4A42@bsdimp.com> References: <5F7CBB50-6C91-49C9-BF69-301496DDE792@bsdimp.com> <9F6D585C-7590-4D25-879B-A76D8A959E01@bsdimp.com> <1420514079.14601.7.camel@freebsd.org> <3AB1B833-6D17-44C4-B588-8CEAB0CA4A42@bsdimp.com> Date: Mon, 5 Jan 2015 19:47:17 -0800 X-Google-Sender-Auth: Gu-iSiXPCDhwYAdjE4uuRd_GFiI Message-ID: Subject: Re: interrupt muxes, bus memory space and other fun amusing things From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Warner Losh , John Baldwin , Ian Lepore , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:47:20 -0000 Well i'm happy to do it in two pieces: * do whatever to get it up and working so I can do the rest of the qca mips bringups so we get access to like 50 new routers that are out there right now; * take the mips, ppc and arm bits and drive home the unified front, now that we have all the pieces in place and things work. -adrian On 5 January 2015 at 19:26, Warner Losh wrote: > >> On Jan 5, 2015, at 8:14 PM, Ian Lepore wrote: >> >> On Mon, 2015-01-05 at 20:10 -0700, Warner Losh wrote: >>>> On Jan 5, 2015, at 1:31 PM, Adrian Chadd wrote: >>>> >>>> On 5 January 2015 at 08:41, Warner Losh wrote: >>>>> >>>>>> So if I were Linux, I'd just implement a mux that pretends to trigge= r >>>>>> interrupts in a much bigger IRQ space. Ie, they map IP0..IP7 to >>>>>> irq0..7, then they pick another IRQ range for the AHB interrupts, an= d >>>>>> another IRQ range for the IP2/IP3 interrupt mux. They have a >>>>>> hard-coded mux that takes care of triggering the software IRQ based = on >>>>>> the hardware interrupt and mux register contents. >>>>>> >>>>>> So, how should I approach this? >>>>> >>>>> Same way. You=E2=80=99d create an interrupt device that registers an = interrupt >>>>> for the mux, then farms it out based on the contents of the registers= . >>>>> The MIPS interrupt handler might need some work (arm did) to >>>>> allow this to happen, but it isn=E2=80=99t super difficult (though II= Rc it is tedious). >>>> >>>> Ok. So I can do that, but then devices hang off of which bus? nexus0? >>>> Or this mux? >>>> >>>> Can I create a mux bus to hang things off of that just pass all the >>>> memory region requests up to the parent bus (nexus in this case) ? >>> >>> The hard part is mapping an interrupt provided by a mux to a resource >>> number. However, we already do this for the =E2=80=98hard wired=E2=80= =99 interrupts >>> that are muxed through APIC or PIC controllers on x86. I fail to see ho= w >>> this is any different, apart (perhaps) from the need to do things dynam= ically >>> in some way. >>> >>> Warner >>> >> >> It sounds like mips is ready for intrng. Which would then give us ppc, >> arm, and mips all with a conceptually-similar intrng-like layer for >> handling non-hierarchical interrupt sources and controllers and mapping >> between rman and hardware ideas of interrupt number. Hmmm. This would >> be the time to argue for a nice shiny new MI intrng implementation... >> except that we can't quite drive even the arm-only version to >> completion. > > Maybe now=E2=80=99s the time? > > Warner From owner-freebsd-mips@FreeBSD.ORG Thu Jan 8 01:03:04 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F9D9A5F for ; Thu, 8 Jan 2015 01:03:04 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2626CBC9 for ; Thu, 8 Jan 2015 01:03:04 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id q59so2196775wes.8 for ; Wed, 07 Jan 2015 17:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=IBZeRYMKyI412MVwHAVyTB1xpIaD+xKvMmw2fkGdw8o=; b=RSBTWu8ieLfATcd6CtJKfmKzMHC3+JjF27NjvIWMk5Ic5P/h5ah5xIX530wabY4z1b rrxA2smo9hWYUzu73ImAN6mtYcDoKmr31uql9RwWNPnqNuxvfD4c8DFYOL5Z63tVOo7k DB4U9rE2uXT7Dq4qg/sEAOrkjkKxUiqNruBak9bNF60PYBGy9JUh1TnUDakaLC3+IBXV RVrcMrXjUmS6gsZ+9upZ+5ahuwDQ2EoSE6EvFHMT9DT9VyhvLU3nKtogTD+I4vauvqVv iY4Ol8j3LhHSNNjASQV3W/stxz0T6aP3Yw1p86DU3DaEM/tT1lIJuzoIohQvPLZT5xPu TSng== MIME-Version: 1.0 X-Received: by 10.180.91.193 with SMTP id cg1mr2508643wib.26.1420678982642; Wed, 07 Jan 2015 17:03:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Wed, 7 Jan 2015 17:03:01 -0800 (PST) Date: Wed, 7 Jan 2015 17:03:01 -0800 X-Google-Sender-Auth: i4NgaFm8QHqYpJkX_VuC-k0iIQs Message-ID: Subject: RFC: figuring out bus behaviour on these mips32r2 chips From: Adrian Chadd To: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:03:04 -0000 Hi, I found that the new QCA955x chip (and some of the QCA934x things in shipping products versus what I have on my desk at home) behave poorly unless I do ye olde "write to register; read from register to flush" paradigm. In this specific instance, it's the MDIO controller on each MAC - if I do a read-after-write to those registers, everything is peachy. Without it - and even with a call to wmb() - it still barfs. Now, I went digging through the mips code, and wmb() -> mips_sync() -> just a sync operation. It doesn't do any other kind of barrier. So - what's the mips32r2 spec require us to do for ensuring device IO has made it out to devices and we enforce ordering? Are we missing something in our mips_sync() implementation? -adrian From owner-freebsd-mips@FreeBSD.ORG Thu Jan 8 22:55:29 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B34C2671 for ; Thu, 8 Jan 2015 22:55:29 +0000 (UTC) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C2097F7 for ; Thu, 8 Jan 2015 22:55:29 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id z60so5376742qgd.9 for ; Thu, 08 Jan 2015 14:55:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=313xK05858N0p0v6OY+Tk2s8ql0HWA9yXYrEHwsenbI=; b=Iyo68l54574uLZvB+l5T/QsmjZ3y9a+1itAYW/jYphUl6wcz6lUJfTdHf4TXOOyVwI 4C98+sTR3ecVjvzsV61nHMK0/r2fJPGiS9kKcRFzWZkL0/ZfceSawAY5Z54PZwJ0dNQR ts8U/dPxZjFHjBfgy31DVzmv/18rqG3rjGIcUAG5WFeMoVxuHtpRrHLNYZQHvwM+7ZS+ dpsytNWMS0/jQ6GchRD8PqJWg2nO8wvKia0vzPQijMguZeN0qzR77TF8x8duxz0PXZ9M UZF5ajYqoTIf1u//eaWoCxY28v3oqAb/rerAZaBtSkfFsqKBAqAt42aN7uXa4stKnd+d kifg== X-Gm-Message-State: ALoCoQk9B7AODGyrWqRQW1w8c931bu7zSdP4VQMeSaBUzk9QHiTsoNpp4Bik7iK9M0lhZh6oEcsB X-Received: by 10.224.73.135 with SMTP id q7mr21029271qaj.6.1420757722028; Thu, 08 Jan 2015 14:55:22 -0800 (PST) Received: from [10.64.26.233] ([69.53.236.236]) by mx.google.com with ESMTPSA id j3sm5319003qas.19.2015.01.08.14.55.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 14:55:21 -0800 (PST) Sender: Warner Losh Subject: Re: RFC: figuring out bus behaviour on these mips32r2 chips Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4C9D7E15-07E5-4239-9CA4-E0C2B2C7DEB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Thu, 8 Jan 2015 15:55:18 -0700 Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:55:29 -0000 --Apple-Mail=_4C9D7E15-07E5-4239-9CA4-E0C2B2C7DEB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 7, 2015, at 6:03 PM, Adrian Chadd wrote: >=20 > Hi, >=20 > I found that the new QCA955x chip (and some of the QCA934x things in > shipping products versus what I have on my desk at home) behave poorly > unless I do ye olde "write to register; read from register to flush" > paradigm. >=20 > In this specific instance, it's the MDIO controller on each MAC - if I > do a read-after-write to those registers, everything is peachy. > Without it - and even with a call to wmb() - it still barfs. >=20 > Now, I went digging through the mips code, and wmb() -> mips_sync() -> > just a sync operation. It doesn't do any other kind of barrier. >=20 > So - what's the mips32r2 spec require us to do for ensuring device IO > has made it out to devices and we enforce ordering? Are we missing > something in our mips_sync() implementation? SYNC is supposed to be SYNC. An absolute barrier, but that may have = weakened to being merely a strong ordering instruction such that all = writes before it happen before all writes after it. Warner --Apple-Mail=_4C9D7E15-07E5-4239-9CA4-E0C2B2C7DEB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUrwrWAAoJEGwc0Sh9sBEA0UcP+welGEUTosfVgi0nsAu2D3Bj lQblfrMKBXaQRUI9z05WoXaEmdEQCuemlK78HAM79ELKohsa8NUd2FS1ZhtbRhGQ OGln8OWIZ/8FxMRN7zDRgo0X4EqVHU2jXSrqxDCdnzmcypWE68KOpGjCWSux6k3N bdVez32dkqWkaa9Xv+azdqHfQPFWmNrIXxJFJMlSaviWusd4d+ZuCLzjNGlpELr1 7dSLzXMoxIv7Kor1zd2AQ1MSVmUd/niSVcKBG5+X1Ci/PD+Gz/v25Po/jqh19SHW 2Y0YD78r0mJeEVhkMdpQ2Yg607usyoOkTd4F1GNkEEdJFd8MTB8LGHVh7N2JzCNA xZg2Bq6KNwOlgLlpx3dVHjnnNoBc52B8d4GCoCEf/kcV5e7drfAlYkvaw1H/EZl3 P5Gl40em9fmX81Lx7QHwimXJwCdH4M4WEdT4jn5KFcvKGKPX+uXceNn8CuMa0ONi 6ZwMITz824yOsCR59oVcl619c3Y6O64ZKBz1aW+PrfK2MyLze+t6BHQdR9HzHLLN cyAKfhBLIrtdZ7hFOYo3GBY9M92vUOsAZTgrxJ56SlSAwCjRqZiy0nGypBRyMc2x LmR3H1jjyNy9FluSa78glc1JSMFZ2sm1g0cxZYOtJsP9J8sY5baOwFsUb3qzVH7O bB/JFVCBbUc3Fpert57M =vWA2 -----END PGP SIGNATURE----- --Apple-Mail=_4C9D7E15-07E5-4239-9CA4-E0C2B2C7DEB8-- From owner-freebsd-mips@FreeBSD.ORG Thu Jan 8 22:59:24 2015 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D41C56F9; Thu, 8 Jan 2015 22:59:24 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0140.outbound.protection.outlook.com [157.56.111.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43934825; Thu, 8 Jan 2015 22:59:23 +0000 (UTC) Received: from BY1PR0501MB1607.namprd05.prod.outlook.com (25.160.203.156) by BY1PR0501MB1605.namprd05.prod.outlook.com (25.160.203.154) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 8 Jan 2015 22:59:06 +0000 Received: from BY1PR0501MB1607.namprd05.prod.outlook.com ([25.160.203.156]) by BY1PR0501MB1607.namprd05.prod.outlook.com ([25.160.203.156]) with mapi id 15.01.0053.000; Thu, 8 Jan 2015 22:59:06 +0000 From: Andrew Duane To: Warner Losh , Adrian Chadd Subject: RE: RFC: figuring out bus behaviour on these mips32r2 chips Thread-Topic: RFC: figuring out bus behaviour on these mips32r2 chips Thread-Index: AQHQKt7fGlPSzxSDoEOGN9thcyi3b5y21poAgAAAfRA= Date: Thu, 8 Jan 2015 22:59:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=aduane@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1605; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1605; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(199003)(51704005)(64706001)(20776003)(31966008)(97736003)(122556002)(40100003)(4396001)(120916001)(19580395003)(99396003)(46102003)(19580405001)(86362001)(33656002)(54206007)(101416001)(2656002)(92566001)(66066001)(54606007)(54356999)(76176999)(50986999)(87936001)(62966003)(106356001)(21056001)(2900100001)(77156002)(105586002)(107046002)(102836002)(68736005)(74316001)(99286002)(2950100001)(106116001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1605; H:BY1PR0501MB1607.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 22:59:06.3144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1605 Cc: "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:59:25 -0000 Warner is right: from a memory operation ordering perspective, SYNC should = do it. That said, I have in my day encountered hardware registers (or hardw= are itself) that requires the extra memory accesses to insure its own inter= nal operation ordering. Many of these have been on MIPS-architecture SoC sy= stems. .................................... Andrew L. Duane AT&T Technical Lead m=A0=A0=A0+1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net -----Original Message----- From: owner-freebsd-mips@freebsd.org [mailto:owner-freebsd-mips@freebsd.org= ] On Behalf Of Warner Losh Sent: Thursday, January 08, 2015 5:55 PM To: Adrian Chadd Cc: freebsd-mips@freebsd.org Subject: Re: RFC: figuring out bus behaviour on these mips32r2 chips > On Jan 7, 2015, at 6:03 PM, Adrian Chadd wrote: >=20 > Hi, >=20 > I found that the new QCA955x chip (and some of the QCA934x things in=20 > shipping products versus what I have on my desk at home) behave poorly=20 > unless I do ye olde "write to register; read from register to flush" > paradigm. >=20 > In this specific instance, it's the MDIO controller on each MAC - if I=20 > do a read-after-write to those registers, everything is peachy. > Without it - and even with a call to wmb() - it still barfs. >=20 > Now, I went digging through the mips code, and wmb() -> mips_sync() ->=20 > just a sync operation. It doesn't do any other kind of barrier. >=20 > So - what's the mips32r2 spec require us to do for ensuring device IO=20 > has made it out to devices and we enforce ordering? Are we missing=20 > something in our mips_sync() implementation? SYNC is supposed to be SYNC. An absolute barrier, but that may have weakene= d to being merely a strong ordering instruction such that all writes before= it happen before all writes after it. Warner From owner-freebsd-mips@FreeBSD.ORG Sat Jan 10 10:21:50 2015 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C92100 for ; Sat, 10 Jan 2015 10:21:50 +0000 (UTC) Received: from mx1.webcast129.com (mx1.webcast129.com [50.30.42.208]) by mx1.freebsd.org (Postfix) with SMTP id CEF9D17F for ; Sat, 10 Jan 2015 10:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; s=s1024;d=webcast129.com; h=message-id:from:to:subject:date:mime-version:content-type; bh=PEOrk7NRH1A/AXrEL8fvgukx6gw=; b=dGe/LYShZPIldgmLgD7DBM1gt6hXJh97xOscwaR5BTPbCltIZ10nSXKYX7GcYUv76Evgcw+Kwe8jZte9eV4wQxW85RxvmXoB+oOEm/QS9Uk541vICJBQnFLpaQyJiF7LRHBMs2c/4cgXA3MOzF+8ZemX0ZcyunqZ2yYYv0y/OvU= DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s1024;d=webcast129.com; h=message-id:from:to:subject:date:mime-version:content-type; b=aWvg/LW0zs/j2fJoL9YK5psxKqFYLTiY3+r0N3JeOQdT4NQ9Tv+jYvyxKuNNxQ7sgsXXBl0ahAkhBhWcE7mCJ+rd4Mgm/8Vhm9o8xHTvr2fu13lW7O3nKbfdZsdYYM5ms07z/Um7l3QwWLZAustmuzWakbLCtgl4OKjweRrYUhY= Received: from mx1.webcast129.com ([50.30.42.208]) by mx1.webcast129.com ([50.30.42.208]) with SMTPSVC 75095277; Sat, 10 Jan 2015 15:51:39 +0500 Message-ID: Reply-To: From: "Himsan Polymer" To: Subject: =?utf-8?B?U0lMSUNPTkUgVFVCSU5HLCBCUkFJREVEIEhPU0VTLCBHQVNLRVRTLA==?= =?utf-8?B?U0hFRVRTIEFORCBGQkQgR0FTS0VUUyAoRkRBIDIxIENGUiAxNzcuMg==?= =?utf-8?B?NjAwKSBBUFBST1ZFRCk=?= Date: Sat, 10 Jan 2015 15:51:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 10:21:50 -0000 Respected Sir, Sub. : Silicone & Viton Rubber Products for Food, = Pharma & Medical, Textile and Allied Industrial Applications We wish = to introduce ourselves as leading supplier of Silicon & Viton Rubber = Products for Food, Pharma & Medical Application with distinguished = characteristic as follows. We are one of the leading manufacturers of = Silicon Rubber Products in INDIA. We are supplying our products to Pharma = Machinery manufacturers & suppliers, Pharmaceutical & Biotech = Industries, Thermal Power Stations, Chemical Plants and Heavy Engineering = Sectors in all over world. Himsan Polymer (An ISO 9001:2008 Certified = Company)(1) A Destination to Endless diversities CATEGORIES:- TUBINGS, = BRAIDED HOSES, O RINGS, FBD INFLATABLE GASKETS, EXTRUDED DOOR GASKETS, = RUBBER SHEETS, AUTO CLAVE DOOR GASKETS, RUBBER EXPANSION BELLOW, = COMPRESSION BELLOW, DIAPHRAGMS, SQUARE, RECTANGULAR & ROUND CORDS, = ENVELOPE GASKETS, GLAND PACKING ROPES, SHIFTER GASKETS, RMG GASKETS MOC:- = SILICONE,VITON, EPDM, NEOPRENE, NITRILE(NBR), BUTYL, POLY BUTADINE, = HYPALON, SBR, NATURAL, PTFE, PVC, NYLON (2) In-house Testing facility = We have got in house well =E2=80=93 equipped testing facility, and our = each supply accomplishes our own Testing certificates. Our products are as = per FDA standard. Non Toxic and safety designed for Food =E2=80=93 Pharma = =E2=80=93 Medical Application. Thanking you and looking forward to your = fruitful business association with us. Humbly waiting your kind feedback. = Thanks & Regards, Sreesanth Saruvil Himsan Polymer (An ISO 9001:2008 = Certified Company) CORPORATE OFFICE:- R-1,SAI KRUPA NIWAS, OPP. KAMLAKAR = BHANDARI HOUSE, CHARKOP VILLAGE, KANDIVALI WEST-400067 FACTORY:- B/1, = VISHAL INDL. ESTATE, PANCHAL, NEAR HP GAS GODOWN, BHAYANDER (E)-401105 = EMAIL:- sales@himsanpolymer.com MOB:- +91-7738363930 / +91-7715871508 / = 09/ 10 www.himsanpolymer.com FACEBOOK:- = facebook.com/himsanpolymer TWITTER:- www.twitter.com/HimsanPolymer = LINKEDIN:- in.linkedin.com/in/himsanpolymer WHATSAPP:- = +91-7738363930 / +91-7715871510Himsan Polymer (An ISO 9001:2008 Certified = Company) Silicone Transparent Tubings (Platinum Cured & Peroxide = Cured) 1) Made from medical grade Silicone Rubber which complies With = USP class VI requirement & FDA 21 CFR 177.2600 2) Suitable for = Peristaltic Pump applications. 3) Temperature resistance = from-80=C2=B0C to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) = Sterilisable by steam, dry heat, ethylene oxide (ETO) and gamma radiation. = 5) Available in sizes ranging from 0.3 mm ID to 98 mm ID 6) Food = - Pharma - Medical Grade and Complies with USP class VI requirement & = FDA 21 CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified Company) = Silicone Braided Hoses (Platinum Cured & Peroxide Cured) 1) Made = from medical grade Silicone Rubber which complies With USP class VI = requirement & FDA 21 CFR 177.2600 2) Suitable for Peristaltic = Pump applications. 3) Temperature resistance from-80=C2=B0C = to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) Sterilisable by steam, = dry heat, ethylene oxide (ETO) and gamma radiation. 5) Available in = sizes ranging from 1/4=E2=80=9D ID to 2=E2=80=9D ID 6) Food - Pharma = - Medical Grade and Complies with USP class VI requirement & FDA 21 = CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified Company) = Silicone SS Braided Hoses (Platinum Cured & Peroxide Cured) 1) = Made from medical grade Silicone Rubber which complies With USP class VI = requirement & FDA 21 CFR 177.2600 2) Suitable for Peristaltic = Pump applications. 3) Temperature resistance from-80=C2=B0C = to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) Sterilisable by steam, = dry heat, ethylene oxide (ETO) and gamma radiation. 5) Available in = sizes ranging from 1/2=E2=80=9D ID to 1.5=E2=80=9D ID 6) Food - = Pharma - Medical Grade and Complies with USP class VI requirement & = FDA 21 CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified = Company)Inflatable Gaskets For FBD / FBE / FBC & Sterilizers Our = FBD Inflatable Gasket functions like a cycle tube. When inflated, it seals = the bowl and ensures proper sealing. It is being made up of Food-Pharma = Grade white Neoprene Rubber. This Gasket is inflated by 10 mm to 12 mm = when 2 to 4kg pressure is applied. There basically three gaskets in fluid = bed dryer:- 1) PC-Top Bowl Sealing Gasket. (40mm x 22mm) 2) PC-Bottom = Sealing Gasket. (40mm x 22mm) 3) Fitter Press Bag Sealing Gasket. (50mm x = 20mm) Himsan Polymer (An ISO 9001:2008 Certified Company) Tri-Clover = (T/C) Gaskets 1) Made from medical grade Silicone Rubber which = complies With USP class VI requirement & FDA 21 CFR 177.2600 2) = Available in sizes ranging from 1/2=E2=80=9D ID to 1.5=E2=80=9D ID 3) = Sizes Available are 1/4", 3/8", 1/2", 1", 1.5", = 2", 2.5",3=E2=80=9D,4=E2=80=9D,6=E2=80=9D & Any Other Custom = sizes. Himsan Polymer (An ISO 9001:2008 Certified Company)Silicone = Autoclave & Sterilizer Door Gasket (Non-Inflatable) We offer its = wide range of Sillicone Autoclave Gasket in more than 1000 different = shapes and designs. We also offer soft Sillicone Sponge Gasket (Hardness = range from Shore A15 to 30) to Solid silicone Gasket (Hardness range from = Shore A 35 to 85). These Gaskets are being made from Food-Pharma Grade = Sillicone Rubber. It easily withstands a temperature range of -80=C2=B0C = to + 300=C2=B0C. These gaskets are available in square cross sections = like 20mm x 20mm, 25mm x 25mm x 25mm with central hole of 10mm Dia etc. = These gaskets are available in Red, White, Orange or any other colour as = per customer's requirement. Himsan Polymer (An ISO 9001:2008 Certified = Company) Silicone, Neoprene,Viton & PTFE Rubber Sheets Size = available from 1 feet x 1 feet up to maximum 1200 MM x 10 MTR Thickness = ranges from 1mm, 2mm to 20mm Transparent Silicone Sheet is also made = available which is of Highest Quality Standard (FDA 21CFR 177.2600) = Himsan Polymer (An ISO 9001:2008 Certified Company) Rubber O Rings We = offer it's wide range of 'O' Ring from ID 2.0mm to 600mm from it's 500 = single piece moulds. We have also successfully developed Viton 'O' Rings = of ID upto 3000mm. These 'O' Rings are manufactured on a Hydraulic Press = with tightly controlled temperature and time and ensures accurate = dimension, excellent finish, invisible flash line, properly post cured and = absolutely defect free. Himsan Polymer (An ISO 9001:2008 Certified = Company)Silicone Sponge & Solid Gaskets 1) Available in Round Square = and Rectangular Cross Section. 2) Colours are available in White, Red, = Grey, Green & Orange. 3) Complies to FDA 21 CFR 177.2600. Himsan = Polymer (An ISO 9001:2008 Certified Company) Viton, Nitrile, EPDM & = PTFE Tubes 1) Designed for various applications 2) Complies to FDA 21 = CER 177.2600. 3) Sizes are available as per customer=E2=80=99s = requirement. Thanks & Regards, Sreesanth Saruvil Himsan Polymer = (An ISO 9001:2008 Certified Company) CORPORATE OFFICE:- R-1,SAI KRUPA = NIWAS, OPP. KAMLAKAR BHANDARI HOUSE, CHARKOP VILLAGE, KANDIVALI = WEST-400067 FACTORY:- B/1, VISHAL INDL. ESTATE, PANCHAL, NEAR HP GAS = GODOWN, BHAYANDER (E)-401105 EMAIL:- sales@himsanpolymer.com MOB:- = +91-7738363930 / +91-7715871508 / 09/ 10 www.himsanpolymer.com = FACEBOOK:- facebook.com/himsanpolymer TWITTER:- = www.twitter.com/HimsanPolymer LINKEDIN:- = in.linkedin.com/in/himsanpolymer WHATSAPP:- +91-7738363930 / = +91-7715871510 Himsan Polymer (An ISO 9001:2008 Certified Company) =09 =09 =09 =09 This email was sent from himsanpolymer@yahoo.com to = freebsd-mips@FreeBSD.org =09 =09 Forward Mail Click here =09 =09 To unsubscribe from this list please Click here webcast129.com=20 =09 =09 To report an abuse complaint or for problem resolution please Click = here