Hi,
On Wed, Jul 01, 2015 at 01:59:58PM +0200, Baptiste Clenet wrote:
> 2015-07-01 11:45 GMT+02:00 Baptiste Clenet <bapclenet@xxxxxxxxx>:
> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@xxxxxxxxx>:
> >>
> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>:
> >> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
