From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f45.google.com ([74.125.82.45]:33511 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753787AbbGAPRC (ORCPT ); Wed, 1 Jul 2015 11:17:02 -0400 Received: by wgck11 with SMTP id k11so39811695wgc.0 for ; Wed, 01 Jul 2015 08:17:01 -0700 (PDT) Date: Wed, 1 Jul 2015 17:16:54 +0200 From: Alexander Aring Subject: Re: ping6 doesn't use at86rf230 driver Message-ID: <20150701151653.GA969@omega> References: <20150629080937.GA1674@omega> <55910C2F.3070601@gmail.com> <20150629220929.GB1165@omega> <20150701082130.GA1834@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-wpan-owner@vger.kernel.org List-ID: To: Baptiste Clenet Cc: Varka Bhadram , linux-wpan@vger.kernel.org Hi, On Wed, Jul 01, 2015 at 01:59:58PM +0200, Baptiste Clenet wrote: > 2015-07-01 11:45 GMT+02:00 Baptiste Clenet : > > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet : > >> > >> 2015-07-01 10:21 GMT+02:00 Alexander Aring : > >> > Hi, > >> > > >> > On Tue, Jun 30, 2015 at 11:12:36AM +0200, Baptiste Clenet wrote: > >> > .... > >> >> > >> >> root@OpenWrt:/# dmesg | grep at86rf230 > >> >> [ 94.820000] at86rf230 spi32766.1: Detected at86rf212 chip version 3 > >> >> [ 94.830000] at86rf230 spi32766.1: unexcept state change from 0x00 > >> >> to 0x08. Actual state: 0x00 > >> >> > >> >> It detects the chip but yes definitely, there is problem to read the state. > >> >> Will check the pins > >> >> > >> > > >> > if you have debugfs support and mounted it, then you could dump all > >> > register settings by doing something similar like: > >> > > >> > cat /sys/kernel/debug/regmap/spi1.0/registers > >> > > >> > result would be some $REGISTER <-> $VALUE mapping. > >> > > >> > Note: > >> > > >> > One interface of the 802.15.4 phy should be up for this development method, > >> > because the transceiver isn't in sleep mode then. > >> > > >> > - Alex > >> > >> The mapping: > >> > >> root@OpenWrt:/# cat /sys/kernel/debug/regmap/spi32766.1/registers > >> 01: 16 this looks good, because 01 is a volatile register. Means it can be changed during runtime by the transceiver and regmap _always_ get the current register values when we send a get request. And it looks good, because you don't reading zeros on this register. > >> 02: f6 > >> 03: 10 > >> 04: 20 > >> 05: 60 > >> 06: 80 > >> 07: 2c > >> 08: 25 > >> 09: 77 > >> 0a: 17 > >> 0b: a7 > >> 0c: a4 > >> 0d: 01 > >> 0e: 08 > >> 10: 44 > >> 11: a2 > >> 12: f0 > >> 15: 00 > >> 17: 00 > >> 18: 50 > >> 1a: 47 > >> 1b: 54 > >> 1c: 07 > >> 1d: 03 > >> 1e: 1f > >> 1f: 00 > >> 20: ff > >> 21: ff > >> 22: ef > >> 23: be > >> 24: 05 > >> 25: 45 > >> 26: 92 > >> 27: 92 > >> 28: 1e > >> 29: 52 > >> 2a: e4 > >> 2b: d0 > >> 2c: 38 > >> 2d: 98 > >> 2e: 42 > >> 2f: 53 > >> > >> > >> -- > >> Baptiste > > > > > > > > I can set a different channel and see the difference in the regmap, > > I'm definitely able to communicate with the transceiver. Don't trust change on registers which are not volatile. Regmap will do some caching after the frist GET request of a register. If the value is changed, regmap will not do a get request before again the first one. The cached value will be used and then we do some bit magic on the cached values and send a set register value command on the bus. This will reduce some traffic on the bus for configuration setting only, which are done by regmap. When you want to look if the value for channel settings is really changed, then simple add the "RG_PHY_CC_CCA" value to the volatile function, see [1]. Otherwise the value is cached. btw: For transmit/receive handling we use lowlevel spi_async calls on registers which are volatile. > > I'm not sure about my interrupt pin definition in my dts. That might > > be the problem. > > > > in palmbus > > spi > > at86rf212@0 { > > compatible = "atmel,at86rf212"; > > reg = <1>; > > interrupt-parent = <&gpio0>; > > interrupts = <15 1>; Please use "interrupts = <15 4>;" here, 4 indicates high-level triggered interrupt and I experience on some systems deadlocks (on newer driver versions you will get a warning about that). The reason is that we need to protect some irq resources and we do a disable_irq and enable_irq path. See [0]. On _some_ architectures while edge-triggered while irq is disabled, the irq won't fire after enable_irq. In other hand high-level triggered irq will fire after enable_irq. > > reset-gpio = <&gpio0 16 1>; > > sleep-gpio = <&gpio0 17 1>; > > spi-max-frequency = <1000000>; Maybe try there 4-5 Mhz? > > }; > > > > > > and gpio > > gpio@600 { > > #address-cells = <1>; > > #size-cells = <0>; > > interrupt-parent = <&intc>; > > interrupts = <6>; > > > > compatible = "mtk,mt7628-gpio", "mtk,mt7621-gpio"; > > reg = <0x600 0x100>; > > > > gpio0: bank@0 { > > reg = <0>; > > ... > > > > > > I define pin 15 as the interrupt pin here but how can I check it while > > OpenWRT is running? I can only review the at86rf212 entry, don't know how to mux your pins on your architecture correctly. You could try to make a "cat /proc/interrupts", this will show all interrupts and check if the interrupt is increased, but the interrupt should only increased by receiving and transmit complete. ... > > I'm wondering how regmap works. the at86rf230 write and read functions > call regmap functions. I suppose regmap communicates with spi? > > Are values displayed by 'cat > /sys/kernel/debug/regmap/spi32766.1/registers' read from the > transceiver? (updated every time) or is it in the flash of my board > and change one by one when it is required? > > When I change the channel, it obviously changes the regmap but how may > I check that at86rf230 channel is really edited? (calling spi > function) > See my above comments about "how regmap works" there are registers which are cached, but also some registers which can't be cached -> volatile registers. For testing you could add the RG_PHY_CC_CCA register to the volatile function. - Alex [0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L930 [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L422