From owner-freebsd-arm@freebsd.org Tue Jul 26 08:50:08 2016 Return-Path: Delivered-To: freebsd-arm@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 29084BA3001 for ; Tue, 26 Jul 2016 08:50:08 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh602-vm6.bullet.mail.ssk.yahoo.co.jp (nh602-vm6.bullet.mail.ssk.yahoo.co.jp [182.22.90.31]) by mx1.freebsd.org (Postfix) with SMTP id A641A1F55 for ; Tue, 26 Jul 2016 08:50:07 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.106] by nh602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 Received: from [182.22.91.131] by t604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 26 Jul 2016 08:50:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 567796.20617.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 52762 invoked by uid 60001); 26 Jul 2016 08:50:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1469523002; bh=7Q43vmBmvJkJMn0qPtJfu5XLqZQy0fInvYBAkC5wkIs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gLUf19emYdIL32IdePOFzh6E6wVGuIekxo397JI6YBKISYntaR1oKzKiCYCUo0awzIvxEnxHkIHPbEE7CBuKK5MTESSbRZRxqUpvvu/KUZmgB6OwSxs1HNJ4U4L1b2S+cUaSPUaigobANKCse/wOGj4Lo2fHC5trlpPJNKmYQ4U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=e3pQaY7jm86mmMNMpagEC5kMuC+51jHeYQ51zOlsUgDGFH0EtmulubJFTMxaRLbu1pasqqpUzJGontiaZsEjZMVoXWQX2Tv6kTwsJUKU32kx/jpO8Iyez064UYMOhQwWzEYHKHxkoQVNeqHz12f0almYUSy08zkUAsoiPpsnXuQ=; Message-ID: <308695.46813.qm@web101704.mail.ssk.yahoo.co.jp> X-YMail-OSG: AkM6QDIVM1kKTcZ3cWkmMdocXvmawIMoNCUHjfXnXsmR_1_9REMx3DnECFUqNlPiBuPPE86kr3ZqQyF5mDATtIkKFVo8kMP5VDAh3uG2PygAbNlUSAasyT.f2cEwbs7Ystv9qwnfm0hOIlj8P4URVcnKqu3Wjhfqg7ylr.XPZnoEr.GCmSH2KKGhB_LJu_x_6p7iKCmS4bTYiS3S327NqYDeIp84pjsDQx7wN10dRv4xP78aKACQwjvwHNjbyhBt7Lw94mLyA5gfk9VGrC4hwadsFQYp0ShI0NPxKlkp.5yLodPAdLslxIeDrFNgdihQD6cto7jB_f5RKyGVrtKSezX_Pt5CvjD7bhxJo415..MoYdDpIbwo7.6NFe1VFOGzJpGl9yEGOf.BKyXErdzc8qpBRVCEFt1LGsy0B.MLDmSGN64RDFHzEMPvKRSV3gVoLpDpFWRMVkRIs2VeMhQcI7czjHhpsB.Jzw9FIEmryMYiEpkW8H1L0URmow8L85IGBFS_f8AQW8R7WxthHVwwtFOY8t2Fd9QfSqQY5F0YNqv2LR5M568ck4Y- Received: from [110.134.196.53] by web101704.mail.ssk.yahoo.co.jp via HTTP; Tue, 26 Jul 2016 17:50:01 JST X-Mailer: YahooMailWebService/0.8.111_69 X-YMail-JAS: iH3PmLIVM1njCgbBUJ3ml.htQIKa6MQqihq2pJYc80Ow0RAuiIY09uvqIiIR4WTEXEvuFvZOp.eUpT7YFOClvlt_M08z2uAGrJwHc1eKgX._WS1Vk_R2cVWYYfjTFUFSRW9S Date: Tue, 26 Jul 2016 17:50:01 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: hang up at cns11xx To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 08:50:08 -0000 Hi.=0A=0AI try to cns11xx use gcc. I add EventTimer,FTD,INTRNG.=A0=0A=0AI h= ave hang up problem. I seem uart read is trigger at hang up.=0A=0AI can't u= se break.=0A=0AThis is hang up by single user sh input.=0A=0Ahttps://gist.g= ithub.com/yamori813/ae047a28a825aac255e436fd8ccaf785=0A=0A=0AHow to debug i= n this case...=0A=0AIf you have advice, please let me know.=0A=0AI spend ma= ny time this target. Because of I love vintage soc. :)=0A=0AThanks.=0A=0AHi= roki Mori From owner-freebsd-arm@freebsd.org Tue Jul 26 13:41:04 2016 Return-Path: Delivered-To: freebsd-arm@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 59B47BA593C; Tue, 26 Jul 2016 13:41:04 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 147FA1A92; Tue, 26 Jul 2016 13:41:03 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id C93E63AC81; Tue, 26 Jul 2016 15:40:55 +0200 (CEST) Subject: Re: INTRNG (Was: svn commit: r301453....) To: Nathan Whitehorn References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> Cc: Svatopluk Kraus , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <57976867.6080705@FreeBSD.org> Date: Tue, 26 Jul 2016 15:40:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Tue, 26 Jul 2016 15:40:55 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:41:04 -0000 Dne 26.07.2016 v 7:41 Nathan Whitehorn napsal(a): > > > On 07/25/16 21:24, Warner Losh wrote: >> On Mon, Jul 25, 2016 at 10:48 AM, Nathan Whitehorn >> wrote: >>> >>> On 07/25/16 09:32, Warner Losh wrote: >>>> On Mon, Jul 25, 2016 at 8:05 AM, Nathan Whitehorn >>>> wrote: >>>>> That wasn't my question. Are these particular device drivers >>>>> allocating >>>>> interrupts both on the GPIOs in their "interrupts" property (which >>>>> are >>>>> entirely GPIOs in this example) *and* on the GPIOs listed as >>>>> resources >>>>> but >>>>> not listed as interrupts? If they are, then you need a switching >>>>> mechanism, >>>>> but that seems pretty unlikely given the names of the >>>>> non-interrupt GPIOs >>>>> (they look like outputs). It would also be a somewhat deranged way >>>>> to set >>>>> up >>>>> a device tree -- not that that rules it out or anything. >>>> On Atmel, there's a situation that this covers, I think. >>>> >>>> The MCI device has an interrupt in the core: >>>> >>>> mmc0: mmc@fffa8000 { >>>> compatible = "atmel,hsmci"; >>>> reg = <0xfffa8000 0x600>; >>>> interrupts = <9 >>>> IRQ_TYPE_LEVEL_HIGH 0>; >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> pinctrl-names = "default"; >>>> clocks = <&mci0_clk>; >>>> clock-names = "mci_clk"; >>>> status = "disabled"; >>>> }; >>>> >>>> and in other places wires in GPIO interrupts for things like card >>>> eject / insertion. >>>> >>>> mmc0: mmc@f0008000 { >>>> pinctrl-0 = < >>>> &pinctrl_board_mmc0 >>>> >>>> &pinctrl_mmc0_slot0_clk_cmd_dat0 >>>> &pinctrl_mmc0_slot0_dat1_3>; >>>> status = "okay"; >>>> slot@0 { >>>> reg = <0>; >>>> bus-width = <4>; >>>> cd-gpios = <&pioD 15 >>>> GPIO_ACTIVE_HIGH>; >>>> }; >>>> }; >>>> >>>> an interrupt is registered on the cd-gpios pin for when the card >>>> changes. >>>> At >>>> least in linux, FreeBSD doesn't (yet) implement this, but will >>>> someday if >>>> I get >>>> back to the armv6 atmel work I started (see at91-cosino.dts for >>>> example, >>>> there's >>>> others). >>>> >>>> I think this is an example of what you are asking about, or did I get >>>> lost in the >>>> twisty maze of conversation zigs and zags... >>>> >>>> Warner >>>> >>> Where we would run into (minor) problems is if the interrupt parent >>> for the >>> first mmc0 is the GPIO controller. More generally, if &pioD has >>> interrupt >>> children specified in some way that is not a >> high/whatever> >>> tuple somewhere else in the tree then you would have to have methods to >>> parse both interrupt specifiers >>> as-obtained-from-interrupts-properties (or >>> equivalent) and specifiers as-obtained-from-gpio-properties. If the >>> tree >>> picks one format and sticks with it, you can get away with just the >>> one. >>> Glancing through the DTS source for this board, that doesn't appear >>> to be >>> the case and the property formatting is uniform, but I might have >>> missed >>> something in one of the many #includes. >> Interrupts and GPIO specifiers are different in subtle ways. The >> interrupt >> parent for mmc0 is an AIC, which is also the ultimate parent of the GPIO >> controller. > > That is what it looked like. > >> But the properties for the GPIO pins that act as interrupts and >> the interrupt specifiers are different. > > So there are devices with both interrupts = , > #interrupt-parent = <&gpio> and gpios = <&gpio bleh baz> where "Bleh > baz" is formatted different than "foo bar" and both are meant to be > treated as interrupts? > > It's fine if there are, but I haven't seen any such device trees yet. I think that yes, but I'm not ready to search all 1372 Linux DT files only for explicit example. But your question is invalid from beginning. 1) Format of each single 'interrupts' and '*-gpios' property is different because each single one are defined differently. 2) The question should not be 'Are there device' but 'Is this combination valid' Moreover, I'm curious why you want OFW property for gpio interrupts at all, given gpio can be instantiated by other entity (PCIe, USB). Please see: https://svnweb.freebsd.org/base/head/sys/dev/gpio/gpiobus.c?revision=301539&view=markup#l92 and, for example this one controller https://svnweb.freebsd.org/base/head/sys/arm/nvidia/tegra_gpio.c?revision=300149&view=markup#l575 > >>> As a general point, GPIO weirdness would be easy enough case to >>> handle if it >>> did come up (add some mapping method, as above) that I think we >>> shouldn't >>> worry too much about it from an architectural point of view. If a board >>> appears that is set up this way, we can roll with the punches at >>> that point >>> and add whatever small amount of shim code that is required. It >>> would be >>> annoyance, sure, but not a real complication. >> I suspect that either I don't understand the issue, or we'll have >> such boards >> very quickly. The Atmel design is fairly clean in comparison to other >> franken-horrors >> I've seen... > > People do weird things for sure. My point is just that the details of > how (implicit) GPIO interrupts are formatted just isn't that > important. It's easy enough to add special code for devices that are > set up in bizarre ways as they are spotted in the wild and that > special code is so minor that it doesn't matter for the design of the > API. This is a point I was just curious about, since I had never > actually seen device trees set up that way. > > The issue with this patch is, at its core, whether you have an > architecture that relies on the newbus hierarchy (like r301453) or > that allows links outside of that hierarchy that can cross branches or > go the "wrong" way, like the previously existing code. OK. The r301453 : - it removes unnecessary idea of virtual IRQs. I gave you some examples where virtual IRQ concept fails. Also, both variants needs attached PIC at bus_alloc_resource() time, so timing wasn't been changed. - it implements new BUS_MAP_INTR(). As I understand it, this is problematic for you, and I'm ready to change it. But I need more details than "it's fundamentally broken". > There are some other differences, of varying degrees of importance, > but that's the really fundamental one. I haven't seen any cases where > r301453 provides functionality absent in the already existing system, > but there seem to be a large number of cases (see the first email I > sent to freebsd-arch or > https://wiki.freebsd.org/Complicated_Interrupts) that the API in > r301453 cannot accommodate and that are needed to support a variety of > hardware. Which single feature has been removed by r301453? Michal > Since having two APIs will be a significant maintenance burden, if > there are cases the existing code can't handle, I would like to know > about them; otherwise, I think we should back out r301453 and stick to > the standard device tree interrupt mapping mechanism on ARM instead. > I'm happy to help implement any necessary enhancements there (for > example, dealing with weirdly-encoded GPIOs). > -Nathan > >> >> Warner >> >