ping6 doesn't use at86rf230 driver

ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

Hi,

Following is how I configure the network:
modprobe at86rf230
iwpan phy wpan-phy0 interface add wpan0 type node
iwpan dev wpan0 set pan_id 0xbeef
ip link set wpan0 up
ip link add link wpan0 name lowpan0 type lowpan
ip link set lowpan0 up

Then I try to ping6 my second board with:
ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1

I'm observing no changes over the SPI between my board and the
at86rf230. But if I change the channel with:
iwpan phy wpan-phy0 set channel 0 0
I observe the changes over SPI.

So I'm wondering why ping6 doesn't seem to use the transceiver?
Where am I wrong?

Regards,

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
> Hi,
> 
> Following is how I configure the network:
> modprobe at86rf230
> iwpan phy wpan-phy0 interface add wpan0 type node
> iwpan dev wpan0 set pan_id 0xbeef
> ip link set wpan0 up
> ip link add link wpan0 name lowpan0 type lowpan
> ip link set lowpan0 up
> 
> Then I try to ping6 my second board with:
> ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
> 
> I'm observing no changes over the SPI between my board and the
> at86rf230. But if I change the channel with:
> iwpan phy wpan-phy0 set channel 0 0

this change should not be possible with the at86rf230.

> I observe the changes over SPI.
> 

Do you have maybe the fakelb driver running? Please look for that, if
yes you have more than one phy. try "iwpan phy".

- Alex

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
> > Hi,
> > 
> > Following is how I configure the network:
> > modprobe at86rf230
> > iwpan phy wpan-phy0 interface add wpan0 type node
> > iwpan dev wpan0 set pan_id 0xbeef
> > ip link set wpan0 up
> > ip link add link wpan0 name lowpan0 type lowpan
> > ip link set lowpan0 up
> > 
> > Then I try to ping6 my second board with:
> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
> > 
> > I'm observing no changes over the SPI between my board and the
> > at86rf230. But if I change the channel with:
> > iwpan phy wpan-phy0 set channel 0 0
> 
> this change should not be possible with the at86rf230.
> 

ah, with the at86rf212 it's possible to set page/channel to 0. But I
have still no idea why you having this issues right now.

Everything which you did seems to be correct. Which kernel version do
you use and why you do a:

iwpan phy wpan-phy0 interface add wpan0 type node

there should be a wpan0 node interface by default.

- Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-25 19:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
>> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
>> > Hi,
>> >
>> > Following is how I configure the network:
>> > modprobe at86rf230
>> > iwpan phy wpan-phy0 interface add wpan0 type node
>> > iwpan dev wpan0 set pan_id 0xbeef
>> > ip link set wpan0 up
>> > ip link add link wpan0 name lowpan0 type lowpan
>> > ip link set lowpan0 up
>> >
>> > Then I try to ping6 my second board with:
>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>> >
>> > I'm observing no changes over the SPI between my board and the
>> > at86rf230. But if I change the channel with:
>> > iwpan phy wpan-phy0 set channel 0 0
>>
>> this change should not be possible with the at86rf230.
>>
>
> ah, with the at86rf212 it's possible to set page/channel to 0. But I
> have still no idea why you having this issues right now.

Yes I use the at86rf212B so 0 is available to use 868.3MHz.

>
> Everything which you did seems to be correct. Which kernel version do
> you use
Linux 4.0.4, should I use bluetooth-next or wpan-next? (Which is the
difference btw?)


and why you do a:
>
> iwpan phy wpan-phy0 interface add wpan0 type node

It's to create wpan0 in order to be able to create lowpan0 afterwards.

>
> there should be a wpan0 node interface by default.

After the modprobe at86rf230, I have neither wpan0 or lowpan0 created.
(ifconfig)

And wpan-phy0 is created.
root@OpenWrt:/# iwpan list
wpan_phy wpan-phy0
supported channels:
        page 0: 0,1,2,3,4,5,6,7,8,9,10
        page 2: 0,1,2,3,4,5,6,7,8,9,10
current_page: 0
current_channel: 5
cca_mode: 1
tx_power: 0

-- 
Baptiste


>
> - Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-26 9:17 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-06-25 19:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
>>> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
>>> > Hi,
>>> >
>>> > Following is how I configure the network:
>>> > modprobe at86rf230
>>> > iwpan phy wpan-phy0 interface add wpan0 type node
>>> > iwpan dev wpan0 set pan_id 0xbeef
>>> > ip link set wpan0 up
>>> > ip link add link wpan0 name lowpan0 type lowpan
>>> > ip link set lowpan0 up
>>> >
>>> > Then I try to ping6 my second board with:
>>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>>> >
>>> > I'm observing no changes over the SPI between my board and the
>>> > at86rf230. But if I change the channel with:
>>> > iwpan phy wpan-phy0 set channel 0 0
>>>
>>> this change should not be possible with the at86rf230.
>>>
>>
>> ah, with the at86rf212 it's possible to set page/channel to 0. But I
>> have still no idea why you having this issues right now.
>
> Yes I use the at86rf212B so 0 is available to use 868.3MHz.
>
>>
>> Everything which you did seems to be correct. Which kernel version do
>> you use
> Linux 4.0.4, should I use bluetooth-next or wpan-next? (Which is the
> difference btw?)
>
>
> and why you do a:
>>
>> iwpan phy wpan-phy0 interface add wpan0 type node
>
> It's to create wpan0 in order to be able to create lowpan0 afterwards.
>
>>
>> there should be a wpan0 node interface by default.
>
> After the modprobe at86rf230, I have neither wpan0 or lowpan0 created.
> (ifconfig)
>
> And wpan-phy0 is created.
> root@OpenWrt:/# iwpan list
> wpan_phy wpan-phy0
> supported channels:
>         page 0: 0,1,2,3,4,5,6,7,8,9,10
>         page 2: 0,1,2,3,4,5,6,7,8,9,10
> current_page: 0
> current_channel: 5
> cca_mode: 1
> tx_power: 0
>
> --
> Baptiste
>
>
>>
>> - Alex


>Do you have maybe the fakelb driver running? Please look for that, if
>yes you have more than one phy. try "iwpan phy".
fakelb? I'm running this one:
/*
 * AT86RF230/RF231 driver
 * .....
 *
 * Written by:
 * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
 * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
 * Alexander Aring <aar@pengutronix.de>
 */

iwpan phy return one phy as mentioned above.

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Fri, Jun 26, 2015 at 09:20:14AM +0200, Baptiste Clenet wrote:
> 2015-06-26 9:17 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > 2015-06-25 19:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
> >>> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
> >>> > Hi,
> >>> >
> >>> > Following is how I configure the network:
> >>> > modprobe at86rf230
> >>> > iwpan phy wpan-phy0 interface add wpan0 type node
> >>> > iwpan dev wpan0 set pan_id 0xbeef
> >>> > ip link set wpan0 up
> >>> > ip link add link wpan0 name lowpan0 type lowpan
> >>> > ip link set lowpan0 up
> >>> >
> >>> > Then I try to ping6 my second board with:
> >>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
> >>> >
> >>> > I'm observing no changes over the SPI between my board and the
> >>> > at86rf230. But if I change the channel with:
> >>> > iwpan phy wpan-phy0 set channel 0 0
> >>>
> >>> this change should not be possible with the at86rf230.
> >>>
> >>
> >> ah, with the at86rf212 it's possible to set page/channel to 0. But I
> >> have still no idea why you having this issues right now.
> >
> > Yes I use the at86rf212B so 0 is available to use 868.3MHz.
> >

ok.

> >>
> >> Everything which you did seems to be correct. Which kernel version do
> >> you use
> > Linux 4.0.4, should I use bluetooth-next or wpan-next? (Which is the
> > difference btw?)
> >
> >

Use bluetooth-next, the wpan-next ist just some development branch
currently.

> > and why you do a:
> >>
> >> iwpan phy wpan-phy0 interface add wpan0 type node
> >
> > It's to create wpan0 in order to be able to create lowpan0 afterwards.
> >
> >>
> >> there should be a wpan0 node interface by default.
> >
> > After the modprobe at86rf230, I have neither wpan0 or lowpan0 created.
> > (ifconfig)
> >
> > And wpan-phy0 is created.
> > root@OpenWrt:/# iwpan list
> > wpan_phy wpan-phy0
> > supported channels:
> >         page 0: 0,1,2,3,4,5,6,7,8,9,10
> >         page 2: 0,1,2,3,4,5,6,7,8,9,10
> > current_page: 0
> > current_channel: 5
> > cca_mode: 1
> > tx_power: 0
> >

On kernel 4.0 a default interface registration should be available.
Don't know why you have not a default wpan0 interface by default. :-/

> 
> >Do you have maybe the fakelb driver running? Please look for that, if
> >yes you have more than one phy. try "iwpan phy".
> fakelb? I'm running this one:
> /*
>  * AT86RF230/RF231 driver
>  * .....
>  *
>  * Written by:
>  * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>  * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
>  * Alexander Aring <aar@pengutronix.de>
>  */
> 
> iwpan phy return one phy as mentioned above.
> 

Yea, I just thought about that you having more than just one phy and
wpan0 was some interface on the fakelb phy's. This could be the reason
why you didn't see any traffic on the spi bus.

Try to use bluetooth-next and see if you still having the issues.

- Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-26 10:03 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jun 26, 2015 at 09:20:14AM +0200, Baptiste Clenet wrote:
>> 2015-06-26 9:17 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> > 2015-06-25 19:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
>> >>> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
>> >>> > Hi,
>> >>> >
>> >>> > Following is how I configure the network:
>> >>> > modprobe at86rf230
>> >>> > iwpan phy wpan-phy0 interface add wpan0 type node
>> >>> > iwpan dev wpan0 set pan_id 0xbeef
>> >>> > ip link set wpan0 up
>> >>> > ip link add link wpan0 name lowpan0 type lowpan
>> >>> > ip link set lowpan0 up
>> >>> >
>> >>> > Then I try to ping6 my second board with:
>> >>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>> >>> >
>> >>> > I'm observing no changes over the SPI between my board and the
>> >>> > at86rf230. But if I change the channel with:
>> >>> > iwpan phy wpan-phy0 set channel 0 0
>> >>>
>> >>> this change should not be possible with the at86rf230.
>> >>>
>> >>
>> >> ah, with the at86rf212 it's possible to set page/channel to 0. But I
>> >> have still no idea why you having this issues right now.
>> >
>> > Yes I use the at86rf212B so 0 is available to use 868.3MHz.
>> >
>
> ok.
>
>> >>
>> >> Everything which you did seems to be correct. Which kernel version do
>> >> you use
>> > Linux 4.0.4, should I use bluetooth-next or wpan-next? (Which is the
>> > difference btw?)
>> >
>> >
>
> Use bluetooth-next, the wpan-next ist just some development branch
> currently.
>
>> > and why you do a:
>> >>
>> >> iwpan phy wpan-phy0 interface add wpan0 type node
>> >
>> > It's to create wpan0 in order to be able to create lowpan0 afterwards.
>> >
>> >>
>> >> there should be a wpan0 node interface by default.
>> >
>> > After the modprobe at86rf230, I have neither wpan0 or lowpan0 created.
>> > (ifconfig)
>> >
>> > And wpan-phy0 is created.
>> > root@OpenWrt:/# iwpan list
>> > wpan_phy wpan-phy0
>> > supported channels:
>> >         page 0: 0,1,2,3,4,5,6,7,8,9,10
>> >         page 2: 0,1,2,3,4,5,6,7,8,9,10
>> > current_page: 0
>> > current_channel: 5
>> > cca_mode: 1
>> > tx_power: 0
>> >
>
> On kernel 4.0 a default interface registration should be available.
> Don't know why you have not a default wpan0 interface by default. :-/
>
>>
>> >Do you have maybe the fakelb driver running? Please look for that, if
>> >yes you have more than one phy. try "iwpan phy".
>> fakelb? I'm running this one:
>> /*
>>  * AT86RF230/RF231 driver
>>  * .....
>>  *
>>  * Written by:
>>  * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>  * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
>>  * Alexander Aring <aar@pengutronix.de>
>>  */
>>
>> iwpan phy return one phy as mentioned above.
>>
>
> Yea, I just thought about that you having more than just one phy and
> wpan0 was some interface on the fakelb phy's. This could be the reason
> why you didn't see any traffic on the spi bus.
>
> Try to use bluetooth-next and see if you still having the issues.
>
> - Alex

Might be OPENWRT on top of it which doesn't create the default
interface wpan. I'll try with bluetooth-next as soon as it is DL.

Thanks,

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-26 10:24 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-06-26 10:03 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> On Fri, Jun 26, 2015 at 09:20:14AM +0200, Baptiste Clenet wrote:
>>> 2015-06-26 9:17 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>> > 2015-06-25 19:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> >> On Thu, Jun 25, 2015 at 07:15:57PM +0200, Alexander Aring wrote:
>>> >>> On Thu, Jun 25, 2015 at 06:52:35PM +0200, Baptiste Clenet wrote:
>>> >>> > Hi,
>>> >>> >
>>> >>> > Following is how I configure the network:
>>> >>> > modprobe at86rf230
>>> >>> > iwpan phy wpan-phy0 interface add wpan0 type node
>>> >>> > iwpan dev wpan0 set pan_id 0xbeef
>>> >>> > ip link set wpan0 up
>>> >>> > ip link add link wpan0 name lowpan0 type lowpan
>>> >>> > ip link set lowpan0 up
>>> >>> >
>>> >>> > Then I try to ping6 my second board with:
>>> >>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>>> >>> >
>>> >>> > I'm observing no changes over the SPI between my board and the
>>> >>> > at86rf230. But if I change the channel with:
>>> >>> > iwpan phy wpan-phy0 set channel 0 0
>>> >>>
>>> >>> this change should not be possible with the at86rf230.
>>> >>>
>>> >>
>>> >> ah, with the at86rf212 it's possible to set page/channel to 0. But I
>>> >> have still no idea why you having this issues right now.
>>> >
>>> > Yes I use the at86rf212B so 0 is available to use 868.3MHz.
>>> >
>>
>> ok.
>>
>>> >>
>>> >> Everything which you did seems to be correct. Which kernel version do
>>> >> you use
>>> > Linux 4.0.4, should I use bluetooth-next or wpan-next? (Which is the
>>> > difference btw?)
>>> >
>>> >
>>
>> Use bluetooth-next, the wpan-next ist just some development branch
>> currently.
>>
>>> > and why you do a:
>>> >>
>>> >> iwpan phy wpan-phy0 interface add wpan0 type node
>>> >
>>> > It's to create wpan0 in order to be able to create lowpan0 afterwards.
>>> >
>>> >>
>>> >> there should be a wpan0 node interface by default.
>>> >
>>> > After the modprobe at86rf230, I have neither wpan0 or lowpan0 created.
>>> > (ifconfig)
>>> >
>>> > And wpan-phy0 is created.
>>> > root@OpenWrt:/# iwpan list
>>> > wpan_phy wpan-phy0
>>> > supported channels:
>>> >         page 0: 0,1,2,3,4,5,6,7,8,9,10
>>> >         page 2: 0,1,2,3,4,5,6,7,8,9,10
>>> > current_page: 0
>>> > current_channel: 5
>>> > cca_mode: 1
>>> > tx_power: 0
>>> >
>>
>> On kernel 4.0 a default interface registration should be available.
>> Don't know why you have not a default wpan0 interface by default. :-/
>>
>>>
>>> >Do you have maybe the fakelb driver running? Please look for that, if
>>> >yes you have more than one phy. try "iwpan phy".
>>> fakelb? I'm running this one:
>>> /*
>>>  * AT86RF230/RF231 driver
>>>  * .....
>>>  *
>>>  * Written by:
>>>  * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>>  * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
>>>  * Alexander Aring <aar@pengutronix.de>
>>>  */
>>>
>>> iwpan phy return one phy as mentioned above.
>>>
>>
>> Yea, I just thought about that you having more than just one phy and
>> wpan0 was some interface on the fakelb phy's. This could be the reason
>> why you didn't see any traffic on the spi bus.
>>
>> Try to use bluetooth-next and see if you still having the issues.
>>
>> - Alex
>
> Might be OPENWRT on top of it which doesn't create the default
> interface wpan. I'll try with bluetooth-next as soon as it is DL.
>
> Thanks,
>
> --
> Baptiste

Alexander, which version of Linux bluetooth-next tree is based on?

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

> 
> Alexander, which version of Linux bluetooth-next tree is based on?

4.1.0-rc4-01278-gfbb12f9-dirty

this is currently in my development branch. Alternative you can check
the Makefile of linux-kernel [0].

VERSION = 4
PATCHLEVEL = 1
SUBLEVEL = 0
EXTRAVERSION = -rc4
NAME = Hurr durr I'ma sheep



I really have no idea why you don't have a wpan interface by default.
You can delete interfaces from nl802154, but then openwrt need to speak
to this netlink interface and I don't believe that it does that. :-)

Also I know users which use 3.9.x 4.0.x successfully, but it's not
recommended.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/Makefile#n1

Re: ping6 doesn't use at86rf230 driver

[Varka Bhadram]

On 06/29/2015 01:39 PM, Alexander Aring wrote:
>> Alexander, which version of Linux bluetooth-next tree is based on?
> 4.1.0-rc4-01278-gfbb12f9-dirty
>
> this is currently in my development branch. Alternative you can check
> the Makefile of linux-kernel [0].
>
> VERSION = 4
> PATCHLEVEL = 1
> SUBLEVEL = 0
> EXTRAVERSION = -rc4
> NAME = Hurr durr I'ma sheep
>
>
>
> I really have no idea why you don't have a wpan interface by default.

May be the wpan interface is down  :-).

can you please check with: *ifconfig -a*

> You can delete interfaces from nl802154, but then openwrt need to speak
> to this netlink interface and I don't believe that it does that. :-)

Speaking to the netlink interface in OpenWRT is same as in case of bare
Linux kernel compiled for specific target. There is no difference.
So we can use the wpan-tools [1] to speak to the netlink interface.

[1]: http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/network/utils/wpan-tools/Makefile;h=87a5fb1461121407f685e960b64315661aacc9bf;hb=HEAD

-- 
Varka Bhadram.

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-29 11:13 GMT+02:00 Varka Bhadram <varkabhadram@gmail.com>:
> On 06/29/2015 01:39 PM, Alexander Aring wrote:
>>>
>>> Alexander, which version of Linux bluetooth-next tree is based on?
>>
>> 4.1.0-rc4-01278-gfbb12f9-dirty
>>
>> this is currently in my development branch. Alternative you can check
>> the Makefile of linux-kernel [0].
>>
>> VERSION = 4
>> PATCHLEVEL = 1
>> SUBLEVEL = 0
>> EXTRAVERSION = -rc4
>> NAME = Hurr durr I'ma sheep
>>
>>
>>
>> I really have no idea why you don't have a wpan interface by default.
>
>
> May be the wpan interface is down  :-).
>
> can you please check with: *ifconfig -a*

Varka, you were right:
root@OpenWrt:/# ifconfig -a
br-lan    Link encap:Ethernet  HWaddr A6:3E:F6:19:6C:F7
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd35:d27a:3a36::1/60 Scope:Global
          inet6 addr: fe80::a43e:f6ff:fe19:6cf7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:598 (598.0 B)  TX bytes:1230 (1.2 KiB)

eth0      Link encap:Ethernet  HWaddr 2E:81:C8:13:EF:44
          inet6 addr: fe80::2c81:c8ff:fe13:ef44/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1216 (1.1 KiB)  TX bytes:7418 (7.2 KiB)
          Interrupt:5

eth0.1    Link encap:Ethernet  HWaddr 2E:81:C8:13:EF:44
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:874 (874.0 B)  TX bytes:2319 (2.2 KiB)

eth0.2    Link encap:Ethernet  HWaddr A6:3E:F6:19:6C:F8
          inet6 addr: fe80::a43e:f6ff:fe19:6cf8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:3257 (3.1 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:48 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3936 (3.8 KiB)  TX bytes:3936 (3.8 KiB)

wpan0     Link encap:UNSPEC  HWaddr
0E-49-D3-CD-5E-7D-3E-8C-00-00-00-00-00-00-00-00
          BROADCAST NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

'ip link set wpan0 up' sets it up.

>
>> You can delete interfaces from nl802154, but then openwrt need to speak
>> to this netlink interface and I don't believe that it does that. :-)
>
>
> Speaking to the netlink interface in OpenWRT is same as in case of bare
> Linux kernel compiled for specific target. There is no difference.
> So we can use the wpan-tools [1] to speak to the netlink interface.
>
> [1]:
> http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/network/utils/wpan-tools/Makefile;h=87a5fb1461121407f685e960b64315661aacc9bf;hb=HEAD
>
> --
> Varka Bhadram.
>

I'm going to search deeper why ping6 doesn't want to communicate with SPI.

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-29 11:44 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-06-29 11:13 GMT+02:00 Varka Bhadram <varkabhadram@gmail.com>:
>> On 06/29/2015 01:39 PM, Alexander Aring wrote:
>>>>
>>>> Alexander, which version of Linux bluetooth-next tree is based on?
>>>
>>> 4.1.0-rc4-01278-gfbb12f9-dirty
>>>
>>> this is currently in my development branch. Alternative you can check
>>> the Makefile of linux-kernel [0].
>>>
>>> VERSION = 4
>>> PATCHLEVEL = 1
>>> SUBLEVEL = 0
>>> EXTRAVERSION = -rc4
>>> NAME = Hurr durr I'ma sheep
>>>
>>>
>>>
>>> I really have no idea why you don't have a wpan interface by default.
>>
>>
>> May be the wpan interface is down  :-).
>>
>> can you please check with: *ifconfig -a*
>
> Varka, you were right:
> root@OpenWrt:/# ifconfig -a
> br-lan    Link encap:Ethernet  HWaddr A6:3E:F6:19:6C:F7
>           inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
>           inet6 addr: fd35:d27a:3a36::1/60 Scope:Global
>           inet6 addr: fe80::a43e:f6ff:fe19:6cf7/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:13 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:598 (598.0 B)  TX bytes:1230 (1.2 KiB)
>
> eth0      Link encap:Ethernet  HWaddr 2E:81:C8:13:EF:44
>           inet6 addr: fe80::2c81:c8ff:fe13:ef44/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:19 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:1216 (1.1 KiB)  TX bytes:7418 (7.2 KiB)
>           Interrupt:5
>
> eth0.1    Link encap:Ethernet  HWaddr 2E:81:C8:13:EF:44
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:19 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:874 (874.0 B)  TX bytes:2319 (2.2 KiB)
>
> eth0.2    Link encap:Ethernet  HWaddr A6:3E:F6:19:6C:F8
>           inet6 addr: fe80::a43e:f6ff:fe19:6cf8/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:3257 (3.1 KiB)
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:48 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:3936 (3.8 KiB)  TX bytes:3936 (3.8 KiB)
>
> wpan0     Link encap:UNSPEC  HWaddr
> 0E-49-D3-CD-5E-7D-3E-8C-00-00-00-00-00-00-00-00
>           BROADCAST NOARP  MTU:127  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:300
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> 'ip link set wpan0 up' sets it up.
>
>>
>>> You can delete interfaces from nl802154, but then openwrt need to speak
>>> to this netlink interface and I don't believe that it does that. :-)
>>
>>
>> Speaking to the netlink interface in OpenWRT is same as in case of bare
>> Linux kernel compiled for specific target. There is no difference.
>> So we can use the wpan-tools [1] to speak to the netlink interface.
>>
>> [1]:
>> http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/network/utils/wpan-tools/Makefile;h=87a5fb1461121407f685e960b64315661aacc9bf;hb=HEAD
>>
>> --
>> Varka Bhadram.
>>
>
> I'm going to search deeper why ping6 doesn't want to communicate with SPI.
>
> --
> Baptiste

Every time I set lowpan interface up, I get an error:

root@OpenWrt:/# ip link add link wpan0 name lowpan0 type lowpan
root@OpenWrt:/# ip link set lowpan0 up
root@OpenWrt:/# [ 6950.140000] at86rf230 spi32766.1: unexcept state
change from 0x00 to 0x09. Actual state: 0x00
[ 6950.150000] ------------[ cut here ]------------
[ 6950.160000] WARNING: CPU: 0 PID: 175 at
drivers/spi/spi-mt7621.c:146
mt7621_spi_transfer_one_message+0x158/0x3b4()
[ 6950.180000] Modules linked in: at86rf230 pppoe ppp_async
iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6
nf_conntrack_ipv4 iph
[ 6950.390000] CPU: 0 PID: 175 Comm: spi32766 Not tainted 4.0.4 #20
[ 6950.400000] Stack : 00000000 00000000 00000001 00000000 802b86d4
80311de3 000000af 8035342c
          818ee570 819a2388 00010000 00000000 00000000 80049318
00000003 802bd674
          00000092 819a2388 802bbc78 819bbd7c 00000000 8004785c
00000000 00000000
          00000001 00000000 00000000 00000000 00000000 00000000
00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
          ...
[ 6950.470000] Call Trace:
[ 6950.480000] [<8001475c>] show_stack+0x48/0x70
[ 6950.490000] [<80025260>] warn_slowpath_common+0xa0/0xd0
[ 6950.500000] [<80025318>] warn_slowpath_null+0x18/0x24
[ 6950.510000] [<801b7ee8>] mt7621_spi_transfer_one_message+0x158/0x3b4
[ 6950.520000] [<801b6e4c>] __spi_pump_messages+0x404/0x464
[ 6950.530000] [<8003ad80>] kthread_worker_fn+0xa8/0xf4
[ 6950.540000] [<8003aea4>] kthread+0xd8/0xe4
[ 6950.550000] [<80004878>] ret_from_kernel_thread+0x14/0x1c
[ 6950.560000]
[ 6950.560000] ---[ end trace d93d9398d7e8323c ]---

Is that normal?

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

Hi,

On Mon, Jun 29, 2015 at 01:44:42PM +0200, Baptiste Clenet wrote:
> 2015-06-29 11:44 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > 2015-06-29 11:13 GMT+02:00 Varka Bhadram <varkabhadram@gmail.com>:
> >> On 06/29/2015 01:39 PM, Alexander Aring wrote:
> >>>>
> >>>> Alexander, which version of Linux bluetooth-next tree is based on?
> >>>
> >>> 4.1.0-rc4-01278-gfbb12f9-dirty
> >>>
> >>> this is currently in my development branch. Alternative you can check
> >>> the Makefile of linux-kernel [0].
> >>>
> >>> VERSION = 4
> >>> PATCHLEVEL = 1
> >>> SUBLEVEL = 0
> >>> EXTRAVERSION = -rc4
> >>> NAME = Hurr durr I'ma sheep
> >>>
> >>>
> >>>
> >>> I really have no idea why you don't have a wpan interface by default.
> >>
> >>
> >> May be the wpan interface is down  :-).
> >>
> >> can you please check with: *ifconfig -a*
...
> 
> Every time I set lowpan interface up, I get an error:
> 
> root@OpenWrt:/# ip link add link wpan0 name lowpan0 type lowpan
> root@OpenWrt:/# ip link set lowpan0 up
> root@OpenWrt:/# [ 6950.140000] at86rf230 spi32766.1: unexcept state
> change from 0x00 to 0x09. Actual state: 0x00
> [ 6950.150000] ------------[ cut here ]------------
> [ 6950.160000] WARNING: CPU: 0 PID: 175 at
> drivers/spi/spi-mt7621.c:146
> mt7621_spi_transfer_one_message+0x158/0x3b4()
> [ 6950.180000] Modules linked in: at86rf230 pppoe ppp_async
> iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6
> nf_conntrack_ipv4 iph
> [ 6950.390000] CPU: 0 PID: 175 Comm: spi32766 Not tainted 4.0.4 #20
> [ 6950.400000] Stack : 00000000 00000000 00000001 00000000 802b86d4
> 80311de3 000000af 8035342c
>           818ee570 819a2388 00010000 00000000 00000000 80049318
> 00000003 802bd674
>           00000092 819a2388 802bbc78 819bbd7c 00000000 8004785c
> 00000000 00000000
>           00000001 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
>           00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
>           ...
> [ 6950.470000] Call Trace:
> [ 6950.480000] [<8001475c>] show_stack+0x48/0x70
> [ 6950.490000] [<80025260>] warn_slowpath_common+0xa0/0xd0
> [ 6950.500000] [<80025318>] warn_slowpath_null+0x18/0x24
> [ 6950.510000] [<801b7ee8>] mt7621_spi_transfer_one_message+0x158/0x3b4
> [ 6950.520000] [<801b6e4c>] __spi_pump_messages+0x404/0x464
> [ 6950.530000] [<8003ad80>] kthread_worker_fn+0xa8/0xf4
> [ 6950.540000] [<8003aea4>] kthread+0xd8/0xe4
> [ 6950.550000] [<80004878>] ret_from_kernel_thread+0x14/0x1c
> [ 6950.560000]
> [ 6950.560000] ---[ end trace d93d9398d7e8323c ]---
> 
> Is that normal?
> 

No. When the lowpan interface cames up, the IPv6 stack sends some ndisc
messages (you can capture that over wireshark/tcpdump). This means the
transceiver driver tries to send some frames.

The warning:

"[ 6950.140000] at86rf230 spi32766.1: unexcept state change from 0x00 to
 0x09. Actual state: 0x00"

smells like you reading zeros on the bus. It wonders me how the driver
survived the probing, because it will read some ID registers.

Does the probing working well on your side, look in dmesg if the
transceiver was right detected.

More details about the messages is:

You try to chenges from state 0x00 (was readed from register) to 0x09
(TX_ON, not readed from any register. It's set by the transceiver). It
fails and detected you are in state 0x00 (readed from register). So it
smells like you reading zeros only.

Try to check the spi bus and chipselect, also check the slp_tr pin.
Otherwise I have no idea why you reading zeros only.

- Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-06-30 0:09 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> On Mon, Jun 29, 2015 at 01:44:42PM +0200, Baptiste Clenet wrote:
>> 2015-06-29 11:44 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> > 2015-06-29 11:13 GMT+02:00 Varka Bhadram <varkabhadram@gmail.com>:
>> >> On 06/29/2015 01:39 PM, Alexander Aring wrote:
>> >>>>
>> >>>> Alexander, which version of Linux bluetooth-next tree is based on?
>> >>>
>> >>> 4.1.0-rc4-01278-gfbb12f9-dirty
>> >>>
>> >>> this is currently in my development branch. Alternative you can check
>> >>> the Makefile of linux-kernel [0].
>> >>>
>> >>> VERSION = 4
>> >>> PATCHLEVEL = 1
>> >>> SUBLEVEL = 0
>> >>> EXTRAVERSION = -rc4
>> >>> NAME = Hurr durr I'ma sheep
>> >>>
>> >>>
>> >>>
>> >>> I really have no idea why you don't have a wpan interface by default.
>> >>
>> >>
>> >> May be the wpan interface is down  :-).
>> >>
>> >> can you please check with: *ifconfig -a*
> ...
>>
>> Every time I set lowpan interface up, I get an error:
>>
>> root@OpenWrt:/# ip link add link wpan0 name lowpan0 type lowpan
>> root@OpenWrt:/# ip link set lowpan0 up
>> root@OpenWrt:/# [ 6950.140000] at86rf230 spi32766.1: unexcept state
>> change from 0x00 to 0x09. Actual state: 0x00
>> [ 6950.150000] ------------[ cut here ]------------
>> [ 6950.160000] WARNING: CPU: 0 PID: 175 at
>> drivers/spi/spi-mt7621.c:146
>> mt7621_spi_transfer_one_message+0x158/0x3b4()
>> [ 6950.180000] Modules linked in: at86rf230 pppoe ppp_async
>> iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6
>> nf_conntrack_ipv4 iph
>> [ 6950.390000] CPU: 0 PID: 175 Comm: spi32766 Not tainted 4.0.4 #20
>> [ 6950.400000] Stack : 00000000 00000000 00000001 00000000 802b86d4
>> 80311de3 000000af 8035342c
>>           818ee570 819a2388 00010000 00000000 00000000 80049318
>> 00000003 802bd674
>>           00000092 819a2388 802bbc78 819bbd7c 00000000 8004785c
>> 00000000 00000000
>>           00000001 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000
>>           00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000
>>           ...
>> [ 6950.470000] Call Trace:
>> [ 6950.480000] [<8001475c>] show_stack+0x48/0x70
>> [ 6950.490000] [<80025260>] warn_slowpath_common+0xa0/0xd0
>> [ 6950.500000] [<80025318>] warn_slowpath_null+0x18/0x24
>> [ 6950.510000] [<801b7ee8>] mt7621_spi_transfer_one_message+0x158/0x3b4
>> [ 6950.520000] [<801b6e4c>] __spi_pump_messages+0x404/0x464
>> [ 6950.530000] [<8003ad80>] kthread_worker_fn+0xa8/0xf4
>> [ 6950.540000] [<8003aea4>] kthread+0xd8/0xe4
>> [ 6950.550000] [<80004878>] ret_from_kernel_thread+0x14/0x1c
>> [ 6950.560000]
>> [ 6950.560000] ---[ end trace d93d9398d7e8323c ]---
>>
>> Is that normal?
>>
>
> No. When the lowpan interface cames up, the IPv6 stack sends some ndisc
> messages (you can capture that over wireshark/tcpdump). This means the
> transceiver driver tries to send some frames.
>
> The warning:
>
> "[ 6950.140000] at86rf230 spi32766.1: unexcept state change from 0x00 to
>  0x09. Actual state: 0x00"
>
> smells like you reading zeros on the bus. It wonders me how the driver
> survived the probing, because it will read some ID registers.
>
> Does the probing working well on your side, look in dmesg if the
> transceiver was right detected.
>
> More details about the messages is:
>
> You try to chenges from state 0x00 (was readed from register) to 0x09
> (TX_ON, not readed from any register. It's set by the transceiver). It
> fails and detected you are in state 0x00 (readed from register). So it
> smells like you reading zeros only.
>
> Try to check the spi bus and chipselect, also check the slp_tr pin.
> Otherwise I have no idea why you reading zeros only.
>
> - Alex

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

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[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

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> 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
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

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>
> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > 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
> 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.
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>;
          reset-gpio = <&gpio0 16 1>;
          sleep-gpio = <&gpio0 17 1>;
          spi-max-frequency = <1000000>;
      };


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?

Good luck for your exam through :-)
-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-01 11:45 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>
>> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > 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
>> 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.
> 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>;
>           reset-gpio = <&gpio0 16 1>;
>           sleep-gpio = <&gpio0 17 1>;
>           spi-max-frequency = <1000000>;
>       };
>
>
> 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?
>
> Good luck for your exam through :-)
> --
> Baptiste

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)


-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

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@gmail.com>:
> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >>
> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> > 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

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> 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@gmail.com>:
>> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> >>
>> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> > 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

Hi!

Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
I've looked at every single exchange over SPI for the AT86RF230, I
better understand the functioning and how your driver initializes it.
(I've worked ont the 212B on another platform)

Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
state change from 0x00 to 0x08. Actual state: 0x00"
0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
When setting up the transceiver, it goes to TRX_OFF which is the
default state after starting. Why is it unexpected?

I don't really understand all the functions related to state change
and async ... If you've got some time to explain me that and it will
be maybe easier for me to debug this part and see why there is an
unexpected change.

Concerning the interrupt, I will check after having resolved the
"unexcept state change ..." Btw, which function (in at86rf230.c) is
called when an interrupt is raised?

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-02 17:02 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> 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@gmail.com>:
>>> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>> >>
>>> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> >> > 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
>
> Hi!
>
> Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
> I've looked at every single exchange over SPI for the AT86RF230, I
> better understand the functioning and how your driver initializes it.
> (I've worked ont the 212B on another platform)
>
> Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
> state change from 0x00 to 0x08. Actual state: 0x00"
> 0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
> When setting up the transceiver, it goes to TRX_OFF which is the
> default state after starting. Why is it unexpected?
>
> I don't really understand all the functions related to state change
> and async ... If you've got some time to explain me that and it will
> be maybe easier for me to debug this part and see why there is an
> unexpected change.
And how do you define the Actual State? What should it be? Because
0x08 is the current state (value read from remap) Why is that wrong
then?
>
> Concerning the interrupt, I will check after having resolved the
> "unexcept state change ..." Btw, which function (in at86rf230.c) is
> called when an interrupt is raised?
>
> --
> Baptiste



-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Thu, Jul 02, 2015 at 05:02:00PM +0200, Baptiste Clenet wrote:
> 2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > 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@gmail.com>:
> >> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >> >>
> >> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> >> > 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
> 
> Hi!
> 
> Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
> I've looked at every single exchange over SPI for the AT86RF230, I
> better understand the functioning and how your driver initializes it.
> (I've worked ont the 212B on another platform)
> 

The transceiver is after reset inside the RESET state, look "Extended
Operation Mode" inside at86rf212 datasheet.

On probing for init the hw we going into TRX_OFF state.

> Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
> state change from 0x00 to 0x08. Actual state: 0x00"
> 0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
> When setting up the transceiver, it goes to TRX_OFF which is the
> default state after starting. Why is it unexpected?
> 

On probing we need to "wait until the state change is done" while
hw_init. This is why we introduced the SYNCED state_change function. It
blocks while it is done. See [0].

This synced mechanism is build above the async state change. It does:

1. wait_for_completion_timeout which completes until somebody called a
   "complete"
2. in the complete handler of at86rf230_async_state_change we call the
   complete -> this lets wait_for_completion_timeout unblock.

This is the big difference between the async and synced framework of
state change.

sync -> blocks until it's done.
async -> it does not block and have a complete handler.

In some context of linux, of course in hard/soft irqs. We can't call
synced operations because it will run some scheduling and blocks the
function. You don't want that, if you do that you will get some "BUG -
scheduling while atomic".

We have one callback "xmit_async" which is called in such context ->
soft irq. Or the isr routine -> hard irq.

I hope until now it's all correct what I tell you. I am also not 100%
sure of this, but this is my point of view.

> I don't really understand all the functions related to state change
> and async ... If you've got some time to explain me that and it will
> be maybe easier for me to debug this part and see why there is an
> unexpected change.
> 

For the state change calls we don't using the regmap framework, we using
the lowlevel spi_async calls. We use volatile registers there which are
not used by the regmap framework (except dumping the register values
over debugfs).

If regmap dumping works for you maybe then spi_async calls doesn't work
for you? We can't also use regmap for everything, we need to load the
data into the frame buffer and regmap is only for register settings, not
huge payload of data.


I don't know why you reading zeros only on your spi bus, I would check
if the chipselect is right when calling spi_async. Did you changed
something according the chipselect handling? Again, note when we change
the state we don't using at86rf230_write/read/_*reg functions, we use
lowlevel spi calls.

- Alex

[0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L749

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-02 18:12 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Thu, Jul 02, 2015 at 05:02:00PM +0200, Baptiste Clenet wrote:
>> 2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > 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@gmail.com>:
>> >> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> >> >>
>> >> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> >> > 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
>>
>> Hi!
>>
>> Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
>> I've looked at every single exchange over SPI for the AT86RF230, I
>> better understand the functioning and how your driver initializes it.
>> (I've worked ont the 212B on another platform)
>>
>
> The transceiver is after reset inside the RESET state, look "Extended
> Operation Mode" inside at86rf212 datasheet.
>
> On probing for init the hw we going into TRX_OFF state.
>
>> Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
>> state change from 0x00 to 0x08. Actual state: 0x00"
>> 0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
>> When setting up the transceiver, it goes to TRX_OFF which is the
>> default state after starting. Why is it unexpected?
>>
>
> On probing we need to "wait until the state change is done" while
> hw_init. This is why we introduced the SYNCED state_change function. It
> blocks while it is done. See [0].
>
> This synced mechanism is build above the async state change. It does:
>
> 1. wait_for_completion_timeout which completes until somebody called a
>    "complete"
> 2. in the complete handler of at86rf230_async_state_change we call the
>    complete -> this lets wait_for_completion_timeout unblock.
>
> This is the big difference between the async and synced framework of
> state change.
>
> sync -> blocks until it's done.
> async -> it does not block and have a complete handler.
>
> In some context of linux, of course in hard/soft irqs. We can't call
> synced operations because it will run some scheduling and blocks the
> function. You don't want that, if you do that you will get some "BUG -
> scheduling while atomic".
>
> We have one callback "xmit_async" which is called in such context ->
> soft irq. Or the isr routine -> hard irq.
>
> I hope until now it's all correct what I tell you. I am also not 100%
> sure of this, but this is my point of view.
>
>> I don't really understand all the functions related to state change
>> and async ... If you've got some time to explain me that and it will
>> be maybe easier for me to debug this part and see why there is an
>> unexpected change.
>>
>
> For the state change calls we don't using the regmap framework, we using
> the lowlevel spi_async calls. We use volatile registers there which are
> not used by the regmap framework (except dumping the register values
> over debugfs).
>
> If regmap dumping works for you maybe then spi_async calls doesn't work
> for you? We can't also use regmap for everything, we need to load the
> data into the frame buffer and regmap is only for register settings, not
> huge payload of data.
>
>
> I don't know why you reading zeros only on your spi bus, I would check
> if the chipselect is right when calling spi_async. Did you changed
> something according the chipselect handling? Again, note when we change
> the state we don't using at86rf230_write/read/_*reg functions, we use
> lowlevel spi calls.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L749


That was a very clear and complete answer, thanks!

I've gone through the process of changing the states. Effectively
spi_async() has got a problem (in comparaison to regmap call). I found
some problems (they're maybe only dependent on my board (spi driver)).
These errors happen at hw_init, here is the process:
hw_init:
    at86rf230_sync_state_change(lp, STATE_FORCE_TRX_OFF);

    at86rf230_async_state_change(lp, &lp->state, state,
at86rf230_sync_state_change_complete, false);

    at86rf230_async_read_reg(lp, RG_TRX_STATUS, ctx,
at86rf230_async_state_change_start, irq_enable);
       spi_async(lp->spi, &ctx->msg);
           (->go to 'at86rf230_async_state_change_start' on callback)


    at86rf230_async_state_change_start
    if (trx_state == ctx->to_state) go to 'at86rf230_sync_state_change_complete'
     else {
        spi_async(lp->spi, &ctx->msg);
            (->go to 'at86rf230_async_state_delay' on callback)


- in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
readings (for me)! The transceiver returns 0
---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.

-- in at86rf230_async_state_change_start, we check if (trx_state ==
ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
are we checking if ctx->to_state 3? Because it's impossible to get 3
in TRX_STATUS, isn't it? So we should check for a 8 here?

This is where I am now :-)


-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-03 15:24 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-02 18:12 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> On Thu, Jul 02, 2015 at 05:02:00PM +0200, Baptiste Clenet wrote:
>>> 2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> > 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@gmail.com>:
>>> >> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>> >> >>
>>> >> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> >> >> > 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
>>>
>>> Hi!
>>>
>>> Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
>>> I've looked at every single exchange over SPI for the AT86RF230, I
>>> better understand the functioning and how your driver initializes it.
>>> (I've worked ont the 212B on another platform)
>>>
>>
>> The transceiver is after reset inside the RESET state, look "Extended
>> Operation Mode" inside at86rf212 datasheet.
>>
>> On probing for init the hw we going into TRX_OFF state.
>>
>>> Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
>>> state change from 0x00 to 0x08. Actual state: 0x00"
>>> 0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
>>> When setting up the transceiver, it goes to TRX_OFF which is the
>>> default state after starting. Why is it unexpected?
>>>
>>
>> On probing we need to "wait until the state change is done" while
>> hw_init. This is why we introduced the SYNCED state_change function. It
>> blocks while it is done. See [0].
>>
>> This synced mechanism is build above the async state change. It does:
>>
>> 1. wait_for_completion_timeout which completes until somebody called a
>>    "complete"
>> 2. in the complete handler of at86rf230_async_state_change we call the
>>    complete -> this lets wait_for_completion_timeout unblock.
>>
>> This is the big difference between the async and synced framework of
>> state change.
>>
>> sync -> blocks until it's done.
>> async -> it does not block and have a complete handler.
>>
>> In some context of linux, of course in hard/soft irqs. We can't call
>> synced operations because it will run some scheduling and blocks the
>> function. You don't want that, if you do that you will get some "BUG -
>> scheduling while atomic".
>>
>> We have one callback "xmit_async" which is called in such context ->
>> soft irq. Or the isr routine -> hard irq.
>>
>> I hope until now it's all correct what I tell you. I am also not 100%
>> sure of this, but this is my point of view.
>>
>>> I don't really understand all the functions related to state change
>>> and async ... If you've got some time to explain me that and it will
>>> be maybe easier for me to debug this part and see why there is an
>>> unexpected change.
>>>
>>
>> For the state change calls we don't using the regmap framework, we using
>> the lowlevel spi_async calls. We use volatile registers there which are
>> not used by the regmap framework (except dumping the register values
>> over debugfs).
>>
>> If regmap dumping works for you maybe then spi_async calls doesn't work
>> for you? We can't also use regmap for everything, we need to load the
>> data into the frame buffer and regmap is only for register settings, not
>> huge payload of data.
>>
>>
>> I don't know why you reading zeros only on your spi bus, I would check
>> if the chipselect is right when calling spi_async. Did you changed
>> something according the chipselect handling? Again, note when we change
>> the state we don't using at86rf230_write/read/_*reg functions, we use
>> lowlevel spi calls.
>>
>> - Alex
>>
>> [0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L749
>
>
> That was a very clear and complete answer, thanks!
>
> I've gone through the process of changing the states. Effectively
> spi_async() has got a problem (in comparaison to regmap call). I found
> some problems (they're maybe only dependent on my board (spi driver)).
> These errors happen at hw_init, here is the process:
> hw_init:
>     at86rf230_sync_state_change(lp, STATE_FORCE_TRX_OFF);
>
>     at86rf230_async_state_change(lp, &lp->state, state,
> at86rf230_sync_state_change_complete, false);
>
>     at86rf230_async_read_reg(lp, RG_TRX_STATUS, ctx,
> at86rf230_async_state_change_start, irq_enable);
>        spi_async(lp->spi, &ctx->msg);
>            (->go to 'at86rf230_async_state_change_start' on callback)
>
>
>     at86rf230_async_state_change_start
>     if (trx_state == ctx->to_state) go to 'at86rf230_sync_state_change_complete'
>      else {
>         spi_async(lp->spi, &ctx->msg);
>             (->go to 'at86rf230_async_state_delay' on callback)
>
>
> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
> readings (for me)! The transceiver returns 0
> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
>
> -- in at86rf230_async_state_change_start,
By the way, in at86rf230_async_state_change_start, const u8 trx_state
= buf[1] & TRX_STATE_MASK; but for my spi driver store the value in
buf[0] instead of buf[1], I needed to change it.
>we check if (trx_state ==
> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
> are we checking if ctx->to_state 3? Because it's impossible to get 3
> in TRX_STATUS, isn't it? So we should check for a 8 here?
>
> This is where I am now :-)
>
>
> --
> Baptiste



-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-03 15:37 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-03 15:24 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> 2015-07-02 18:12 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> On Thu, Jul 02, 2015 at 05:02:00PM +0200, Baptiste Clenet wrote:
>>>> 2015-07-01 17:16 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>> > 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@gmail.com>:
>>>> >> > 2015-07-01 11:22 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>>> >> >>
>>>> >> >> 2015-07-01 10:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>> >> >> > 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
>>>>
>>>> Hi!
>>>>
>>>> Thanks a lot Alex for the clarification! Regmap is clear for me now :-)
>>>> I've looked at every single exchange over SPI for the AT86RF230, I
>>>> better understand the functioning and how your driver initializes it.
>>>> (I've worked ont the 212B on another platform)
>>>>
>>>
>>> The transceiver is after reset inside the RESET state, look "Extended
>>> Operation Mode" inside at86rf212 datasheet.
>>>
>>> On probing for init the hw we going into TRX_OFF state.
>>>
>>>> Everything seems fine apart from the "at86rf230 spi32766.1: unexcept
>>>> state change from 0x00 to 0x08. Actual state: 0x00"
>>>> 0x01 (RG_TRX_STATUS) is volatile so the value in regmap is up to date.
>>>> When setting up the transceiver, it goes to TRX_OFF which is the
>>>> default state after starting. Why is it unexpected?
>>>>
>>>
>>> On probing we need to "wait until the state change is done" while
>>> hw_init. This is why we introduced the SYNCED state_change function. It
>>> blocks while it is done. See [0].
>>>
>>> This synced mechanism is build above the async state change. It does:
>>>
>>> 1. wait_for_completion_timeout which completes until somebody called a
>>>    "complete"
>>> 2. in the complete handler of at86rf230_async_state_change we call the
>>>    complete -> this lets wait_for_completion_timeout unblock.
>>>
>>> This is the big difference between the async and synced framework of
>>> state change.
>>>
>>> sync -> blocks until it's done.
>>> async -> it does not block and have a complete handler.
>>>
>>> In some context of linux, of course in hard/soft irqs. We can't call
>>> synced operations because it will run some scheduling and blocks the
>>> function. You don't want that, if you do that you will get some "BUG -
>>> scheduling while atomic".
>>>
>>> We have one callback "xmit_async" which is called in such context ->
>>> soft irq. Or the isr routine -> hard irq.
>>>
>>> I hope until now it's all correct what I tell you. I am also not 100%
>>> sure of this, but this is my point of view.
>>>
>>>> I don't really understand all the functions related to state change
>>>> and async ... If you've got some time to explain me that and it will
>>>> be maybe easier for me to debug this part and see why there is an
>>>> unexpected change.
>>>>
>>>
>>> For the state change calls we don't using the regmap framework, we using
>>> the lowlevel spi_async calls. We use volatile registers there which are
>>> not used by the regmap framework (except dumping the register values
>>> over debugfs).
>>>
>>> If regmap dumping works for you maybe then spi_async calls doesn't work
>>> for you? We can't also use regmap for everything, we need to load the
>>> data into the frame buffer and regmap is only for register settings, not
>>> huge payload of data.
>>>
>>>
>>> I don't know why you reading zeros only on your spi bus, I would check
>>> if the chipselect is right when calling spi_async. Did you changed
>>> something according the chipselect handling? Again, note when we change
>>> the state we don't using at86rf230_write/read/_*reg functions, we use
>>> lowlevel spi calls.
>>>
>>> - Alex
>>>
>>> [0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L749
>>
>>
>> That was a very clear and complete answer, thanks!
>>
>> I've gone through the process of changing the states. Effectively
>> spi_async() has got a problem (in comparaison to regmap call). I found
>> some problems (they're maybe only dependent on my board (spi driver)).
>> These errors happen at hw_init, here is the process:
>> hw_init:
>>     at86rf230_sync_state_change(lp, STATE_FORCE_TRX_OFF);
>>
>>     at86rf230_async_state_change(lp, &lp->state, state,
>> at86rf230_sync_state_change_complete, false);
>>
>>     at86rf230_async_read_reg(lp, RG_TRX_STATUS, ctx,
>> at86rf230_async_state_change_start, irq_enable);
>>        spi_async(lp->spi, &ctx->msg);
>>            (->go to 'at86rf230_async_state_change_start' on callback)
>>
>>
>>     at86rf230_async_state_change_start
>>     if (trx_state == ctx->to_state) go to 'at86rf230_sync_state_change_complete'
>>      else {
>>         spi_async(lp->spi, &ctx->msg);
>>             (->go to 'at86rf230_async_state_delay' on callback)
>>

I see in [0] that this process have been changed .... I'm not sure I
can easily use the last version (Bluetooth-next) on Linux 4.1.0, I see
many changes on the last version :\

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/drivers/net/ieee802154/at86rf230.c

>>
>> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
>> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
>> readings (for me)! The transceiver returns 0
>> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
>>
>> -- in at86rf230_async_state_change_start,
> By the way, in at86rf230_async_state_change_start, const u8 trx_state
> = buf[1] & TRX_STATE_MASK; but for my spi driver store the value in
> buf[0] instead of buf[1], I needed to change it.
>>we check if (trx_state ==
>> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
>> are we checking if ctx->to_state 3? Because it's impossible to get 3
>> in TRX_STATUS, isn't it? So we should check for a 8 here?
>>
>> This is where I am now :-)
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Fri, Jul 03, 2015 at 03:24:17PM +0200, Baptiste Clenet wrote:
...
> 
> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
> readings (for me)! The transceiver returns 0
> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
> 

mhhhh, our buffer for spi_async messages for tx and rx are the same. If
you now look in datasheet [0] at page 18.

Look at Register Read Access.

This is always two bytes. On MOSI there is at first byte the
READ_COMMAND then follows on MISO the READ DATA.


NOTE:
Now when you spi controller supports full duplex of MISO/MOSI then the
first byte is overwritten by PHY_STATUS.

You can setup PHY_STATUS at SPI_CMD_MODE which is defaults to "empy, all
bits zero".

We don't using the PHY_STATUS thing in the driver, because this required
that the spi controller supports full duplex.

If you say now making ctx->trx.len = 1 solved some issue then I think
the READ_COMMAND will be overwritten by READ DATA. But READ DATA should
be placed after READ_COMMAND (inside the buffer).

I think regmap uses the same behaviour also because, we set:

.reg_bits = 8,
.val_bits = 8,

This exactly means some buffer [ READ_COMMAND (reg_bits) | READ DATA (val_bits)].
Don't know why it works for regmap and not for spi_async then. For me it
looks like that the first byte which is READ_COMMAND will be overwritten
by READ DATA, but READ DATA should be after READ_COMMAND.

> -- in at86rf230_async_state_change_start, we check if (trx_state ==
> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
> are we checking if ctx->to_state 3? Because it's impossible to get 3
> in TRX_STATUS, isn't it? So we should check for a 8 here?
> 

Where do we check on to_state 3 which is STATE_FORCE_TRX_OFF.

- Alex

[0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-03 17:47 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 03, 2015 at 03:24:17PM +0200, Baptiste Clenet wrote:
> ...
>>
>> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
>> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
>> readings (for me)! The transceiver returns 0
>> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
>>
>
> mhhhh, our buffer for spi_async messages for tx and rx are the same. If
> you now look in datasheet [0] at page 18.
>
> Look at Register Read Access.
>
> This is always two bytes. On MOSI there is at first byte the
> READ_COMMAND then follows on MISO the READ DATA.
>
>
> NOTE:
> Now when you spi controller supports full duplex of MISO/MOSI then the
> first byte is overwritten by PHY_STATUS.
>
> You can setup PHY_STATUS at SPI_CMD_MODE which is defaults to "empy, all
> bits zero".
>
> We don't using the PHY_STATUS thing in the driver, because this required
> that the spi controller supports full duplex.
>
> If you say now making ctx->trx.len = 1 solved some issue then I think
> the READ_COMMAND will be overwritten by READ DATA. But READ DATA should
> be placed after READ_COMMAND (inside the buffer).
>
> I think regmap uses the same behaviour also because, we set:
>
> .reg_bits = 8,
> .val_bits = 8,
>
> This exactly means some buffer [ READ_COMMAND (reg_bits) | READ DATA (val_bits)].

I definitely agree with all of that and I'm wondering why the spi
driver behaves like this (spi-mt7621)

> Don't know why it works for regmap and not for spi_async then. For me it
> looks like that the first byte which is READ_COMMAND will be overwritten
> by READ DATA, but READ DATA should be after READ_COMMAND.
>
>> -- in at86rf230_async_state_change_start, we check if (trx_state ==
>> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
>> are we checking if ctx->to_state 3? Because it's impossible to get 3
>> in TRX_STATUS, isn't it? So we should check for a 8 here?
>>
>
> Where do we check on to_state 3 which is STATE_FORCE_TRX_OFF.

My bad, I didn't see that we change it in at86rf230_async_state_delay:
case STATE_FORCE_TRX_OFF:
    ctx->to_state = STATE_TRX_OFF;

>
> - Alex
>
> [0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf

I solved my problem by replacing:
1:
const u8 trx_state = buf[1] & TRX_STATE_MASK;
-->
const u8 trx_state = buf[0] & TRX_STATE_MASK;
in at86rf230_async_state_assert and
at86rf230_async_state_change_start(void *context)

2: add
- ctx->trx.len = 1; before ctx->msg.complete = complete; in
at86rf230_async_read_reg
- ctx->trx.len = 2; before buf[0] = (RG_TRX_STATE & CMD_REG_MASK) |
CMD_REG | CMD_WRITE; in at86rf230_async_state_change_start

I don't get the "unexcept state change from ..." now.

First problem seems solved (it's weird but it works, if I've got more
time, will debug deeper)

My last problem is when I set the lowpan interface up!
The spi driver complains because the message seems too big! The spi
driver has got 8 registers of 32 bytes as buffer but the ndisc
messages are bigger than that so spi driver raises WARN_ON
-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Fri, Jul 03, 2015 at 06:33:01PM +0200, Baptiste Clenet wrote:
> 2015-07-03 17:47 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Fri, Jul 03, 2015 at 03:24:17PM +0200, Baptiste Clenet wrote:
> > ...
> >>
> >> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
> >> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
> >> readings (for me)! The transceiver returns 0
> >> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
> >>
> >
> > mhhhh, our buffer for spi_async messages for tx and rx are the same. If
> > you now look in datasheet [0] at page 18.
> >
> > Look at Register Read Access.
> >
> > This is always two bytes. On MOSI there is at first byte the
> > READ_COMMAND then follows on MISO the READ DATA.
> >
> >
> > NOTE:
> > Now when you spi controller supports full duplex of MISO/MOSI then the
> > first byte is overwritten by PHY_STATUS.
> >
> > You can setup PHY_STATUS at SPI_CMD_MODE which is defaults to "empy, all
> > bits zero".
> >
> > We don't using the PHY_STATUS thing in the driver, because this required
> > that the spi controller supports full duplex.
> >
> > If you say now making ctx->trx.len = 1 solved some issue then I think
> > the READ_COMMAND will be overwritten by READ DATA. But READ DATA should
> > be placed after READ_COMMAND (inside the buffer).
> >
> > I think regmap uses the same behaviour also because, we set:
> >
> > .reg_bits = 8,
> > .val_bits = 8,
> >
> > This exactly means some buffer [ READ_COMMAND (reg_bits) | READ DATA (val_bits)].
> 
> I definitely agree with all of that and I'm wondering why the spi
> driver behaves like this (spi-mt7621)
> 
> > Don't know why it works for regmap and not for spi_async then. For me it
> > looks like that the first byte which is READ_COMMAND will be overwritten
> > by READ DATA, but READ DATA should be after READ_COMMAND.
> >
> >> -- in at86rf230_async_state_change_start, we check if (trx_state ==
> >> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
> >> are we checking if ctx->to_state 3? Because it's impossible to get 3
> >> in TRX_STATUS, isn't it? So we should check for a 8 here?
> >>
> >
> > Where do we check on to_state 3 which is STATE_FORCE_TRX_OFF.
> 
> My bad, I didn't see that we change it in at86rf230_async_state_delay:
> case STATE_FORCE_TRX_OFF:
>     ctx->to_state = STATE_TRX_OFF;
> 

This is only for make some splitting into one state change define. The
state status register doesn't know "FORCE_STATE". Only the TRX_CMD to
initiate the state change knows "doing it with a force change".

> >
> > - Alex
> >
> > [0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf
> 
> I solved my problem by replacing:
> 1:
> const u8 trx_state = buf[1] & TRX_STATE_MASK;
> -->
> const u8 trx_state = buf[0] & TRX_STATE_MASK;
> in at86rf230_async_state_assert and
> at86rf230_async_state_change_start(void *context)
> 
> 2: add
> - ctx->trx.len = 1; before ctx->msg.complete = complete; in
> at86rf230_async_read_reg
> - ctx->trx.len = 2; before buf[0] = (RG_TRX_STATE & CMD_REG_MASK) |
> CMD_REG | CMD_WRITE; in at86rf230_async_state_change_start

Ok. I would check all spi_async calls, to read out the IRQ status
register we use spi_async as well there, not for state change only.

> 
> I don't get the "unexcept state change from ..." now.
> 
> First problem seems solved (it's weird but it works, if I've got more
> time, will debug deeper)
> 
ok.

> My last problem is when I set the lowpan interface up!
> The spi driver complains because the message seems too big! The spi
> driver has got 8 registers of 32 bytes as buffer but the ndisc
> messages are bigger than that so spi driver raises WARN_ON

What's the spi driver now? You mean spi-mt7621? Your spi controller
driver? Which WARN_ON do you mean?

If this is you spi controller driver and you cannot send a spi transfer
messages above 32 bytes -> this is really bad because you need to write
into the framebuffer of at86rf2xx which is at least (127+3) bytes long
and I think you cannot write fragments of frames, means start with the
first, then second, third ... last, which is 32 bytes long (at maximum).

- Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-03 19:37 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 03, 2015 at 06:33:01PM +0200, Baptiste Clenet wrote:
>> 2015-07-03 17:47 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Fri, Jul 03, 2015 at 03:24:17PM +0200, Baptiste Clenet wrote:
>> > ...
>> >>
>> >> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
>> >> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
>> >> readings (for me)! The transceiver returns 0
>> >> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
>> >>
>> >
>> > mhhhh, our buffer for spi_async messages for tx and rx are the same. If
>> > you now look in datasheet [0] at page 18.
>> >
>> > Look at Register Read Access.
>> >
>> > This is always two bytes. On MOSI there is at first byte the
>> > READ_COMMAND then follows on MISO the READ DATA.
>> >
>> >
>> > NOTE:
>> > Now when you spi controller supports full duplex of MISO/MOSI then the
>> > first byte is overwritten by PHY_STATUS.
>> >
>> > You can setup PHY_STATUS at SPI_CMD_MODE which is defaults to "empy, all
>> > bits zero".
>> >
>> > We don't using the PHY_STATUS thing in the driver, because this required
>> > that the spi controller supports full duplex.
>> >
>> > If you say now making ctx->trx.len = 1 solved some issue then I think
>> > the READ_COMMAND will be overwritten by READ DATA. But READ DATA should
>> > be placed after READ_COMMAND (inside the buffer).
>> >
>> > I think regmap uses the same behaviour also because, we set:
>> >
>> > .reg_bits = 8,
>> > .val_bits = 8,
>> >
>> > This exactly means some buffer [ READ_COMMAND (reg_bits) | READ DATA (val_bits)].
>>
>> I definitely agree with all of that and I'm wondering why the spi
>> driver behaves like this (spi-mt7621)
>>
>> > Don't know why it works for regmap and not for spi_async then. For me it
>> > looks like that the first byte which is READ_COMMAND will be overwritten
>> > by READ DATA, but READ DATA should be after READ_COMMAND.
>> >
>> >> -- in at86rf230_async_state_change_start, we check if (trx_state ==
>> >> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
>> >> are we checking if ctx->to_state 3? Because it's impossible to get 3
>> >> in TRX_STATUS, isn't it? So we should check for a 8 here?
>> >>
>> >
>> > Where do we check on to_state 3 which is STATE_FORCE_TRX_OFF.
>>
>> My bad, I didn't see that we change it in at86rf230_async_state_delay:
>> case STATE_FORCE_TRX_OFF:
>>     ctx->to_state = STATE_TRX_OFF;
>>
>
> This is only for make some splitting into one state change define. The
> state status register doesn't know "FORCE_STATE". Only the TRX_CMD to
> initiate the state change knows "doing it with a force change".
>
>> >
>> > - Alex
>> >
>> > [0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf
>>
>> I solved my problem by replacing:
>> 1:
>> const u8 trx_state = buf[1] & TRX_STATE_MASK;
>> -->
>> const u8 trx_state = buf[0] & TRX_STATE_MASK;
>> in at86rf230_async_state_assert and
>> at86rf230_async_state_change_start(void *context)
>>
>> 2: add
>> - ctx->trx.len = 1; before ctx->msg.complete = complete; in
>> at86rf230_async_read_reg
>> - ctx->trx.len = 2; before buf[0] = (RG_TRX_STATE & CMD_REG_MASK) |
>> CMD_REG | CMD_WRITE; in at86rf230_async_state_change_start
>
> Ok. I would check all spi_async calls, to read out the IRQ status
> register we use spi_async as well there, not for state change only.

Sure will check that as well!
>
>>
>> I don't get the "unexcept state change from ..." now.
>>
>> First problem seems solved (it's weird but it works, if I've got more
>> time, will debug deeper)
>>
> ok.
>
>> My last problem is when I set the lowpan interface up!
>> The spi driver complains because the message seems too big! The spi
>> driver has got 8 registers of 32 bytes as buffer but the ndisc
>> messages are bigger than that so spi driver raises WARN_ON
>
> What's the spi driver now? You mean spi-mt7621? Your spi controller
> driver? Which WARN_ON do you mean?
>
> If this is you spi controller driver and you cannot send a spi transfer
> messages above 32 bytes -> this is really bad because you need to write
> into the framebuffer of at86rf2xx which is at least (127+3) bytes long
> and I think you cannot write fragments of frames, means start with the
> first, then second, third ... last, which is 32 bytes long (at maximum).
>
> - Alex

Yes spi-mt7621. Warning at line 146 concerning the length of the message [0].
I think I will have to rewrite a bit the driver in order to send more
than 32 Bytes. I think I just need to keep CS pin for the transceiver
low and send all messages in a loop. Will try that on Monday. I will
let you know how it goes.


[0]
https://dev.openwrt.org/browser/trunk/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch

Here is the warning:
[  193.320000] ------------[ cut here ]------------
[  193.330000] WARNING: CPU: 0 PID: 175 at
drivers/spi/spi-mt7621.c:146
mt7621_spi_transfer_one_message+0x134/0x448()
[  193.350000] Modules linked in: at86rf230 pppoe ppp_async
iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6
nf_conntrack_ipv4 iph
[  193.560000] CPU: 0 PID: 175 Comm: spi32766 Not tainted 4.0.4 #22
[  193.570000] Stack : 00000000 00000000 00000001 00000000 802b86d4
80311de3 000000af 8035342c
          818ee570 819a2388 819a2200 00000004 80ea450c 80049318
00000003 802bd674
          00000094 819a2388 802bbc78 819bbd7c 80ea450c 8004785c
00000000 00000004
          00000001 00000000 00000000 00000000 00000000 00000000
00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
          ...
[  193.650000] Call Trace:
[  193.650000] [<8001475c>] show_stack+0x48/0x70
[  193.660000] [<80025260>] warn_slowpath_common+0xa0/0xd0
[  193.670000] [<80025318>] warn_slowpath_null+0x18/0x24
[  193.680000] [<801b7ec4>] mt7621_spi_transfer_one_message+0x134/0x448
[  193.690000] [<801b6e4c>] __spi_pump_messages+0x404/0x464
[  193.700000] [<8003ad80>] kthread_worker_fn+0xa8/0xf4
[  193.710000] [<8003aea4>] kthread+0xd8/0xe4
[  193.720000] [<80004878>] ret_from_kernel_thread+0x14/0x1c
[  193.730000]
[  193.730000] ---[ end trace 0d3b96d7ce28c6fc ]---

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Alexander Aring]

On Sat, Jul 04, 2015 at 12:13:53AM +0200, Baptiste Clenet wrote:
...
> 
> Yes spi-mt7621. Warning at line 146 concerning the length of the message [0].
> I think I will have to rewrite a bit the driver in order to send more
> than 32 Bytes. I think I just need to keep CS pin for the transceiver
> low and send all messages in a loop. Will try that on Monday. I will
> let you know how it goes.
> 
> 
> [0]
> https://dev.openwrt.org/browser/trunk/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch

Not sure what I should say now here but the spi-mt7621 isn't mainline. I
think you need to ask the openwrt people which is actual the state of
this spi controller driver.

In my opinions it has some limitations and why the hell isn't this
driver mainline? Maybe there exists already known issues with this
driver which are also related to the spi_async receiving buffer issue.

I can't help you at this point to fix the spi controller driver.

- Alex

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

2015-07-04 17:36 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Sat, Jul 04, 2015 at 12:13:53AM +0200, Baptiste Clenet wrote:
> ...
>>
>> Yes spi-mt7621. Warning at line 146 concerning the length of the message [0].
>> I think I will have to rewrite a bit the driver in order to send more
>> than 32 Bytes. I think I just need to keep CS pin for the transceiver
>> low and send all messages in a loop. Will try that on Monday. I will
>> let you know how it goes.
>>
>>
>> [0]
>> https://dev.openwrt.org/browser/trunk/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
>
> Not sure what I should say now here but the spi-mt7621 isn't mainline
> I think you need to ask the openwrt people which is actual the state of
> this spi controller driver.
>
> In my opinions it has some limitations and why the hell isn't this
> driver mainline? Maybe there exists already known issues with this
> driver which are also related to the spi_async receiving buffer issue.
>
> I can't help you at this point to fix the spi controller driver.
>
> - Alex

Yeah sure, I don't know neither. Anyway, you gave me lot of help on
the at86rf230 driver, thank you!
I found out how to rewrite the driver, I will do my test tomorrow and
I think I know why the driver wrote on buf[0] instead of buf[1] which
will mean that I won't need to edit your driver because it is right!
But I need the board to try so let's wait tomorrow. :-)

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

Finally, I won't be able to use the spi driver spi-mt7621 since it is
not a spi core but a serial flash core ... so I'm able 32 Bytes at
once but not more.
The last solution is to use a gpio-drived spi. One is provided, I'm
able to create a device but I'm wondering how to connect the at86rf230
to the simulated spi?

Before, I declared the at86rf230 in my dts under the spi bus.

-- 
Baptiste

Re: ping6 doesn't use at86rf230 driver

[Baptiste Clenet]

Update status; the at86rf230 works completely now! (just need to
receive a message to ensure that the IRQ works)

I'm coming back to my first question now:
Using
ping6 -I lowpan0 fe80::b120:cfb8:7913:a051

with
root@OpenWrt:/# ifconfig lowpan0
lowpan0   Link encap:UNSPEC  HWaddr
B3-20-CF-B8-79-13-A0-50-00-00-00-00-00-00-00-00
          inet6 addr: fe80::b120:cfb8:7913:a050/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

doesn't use the at86rf230 driver

Linux 4.1.0

-- 
Baptiste