RF231 transceiver on at91sam9g20ek board

Hi folks,

I'm the developer of the IEEE 802.15.4 kernel branch, and currently
I've faced with the problem regarding mach-at91 arch and hope you can
advise me.

I've been working with at86rf231 transceiver (RF231 extender)
connected via SPI to at91sam9g20ek board. The driver works and tested
for kernels up to 3.1 version (versions 3.2-latest haven't ever been
tested yet).
Several days ago I've ported the IEEE802.15.4 stack to the latest
kernel and see some strange things: RF231 interrupt handler is
permanently pulled right after driver's probe method (the RF231 chip
is in disabled mode, so it can't generate interrupts at that moment).
Also I've noticed that each ENTER key pressing in minicom generates a
new interrupt. It looks like somebody else uses the same pin/pins for
its needs...

Do you have any ideas what can be changed since 3.1 kernel that this
problem arose.

Thanks a lot for your time!

The driver code is in the attachments.
The platform RF231 code is following:

diff --git a/arch/arm/mach-at91/board-sam9g20ek.c

b/arch/arm/mach-at91/board-sam9g20ek.c
index 8923ec9..b2126e0 100644

--- a/arch/arm/mach-at91/board-sam9g20ek.c
+++ b/arch/arm/mach-at91/board-sam9g20ek.c

@@ -25,6 +25,7 @@
 #include <linux/platform_device.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/at73c213.h>
+#include <linux/spi/at86rf230.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/clk.h>

@@ -102,6 +103,12 @@ static struct at91_udc_data __initdata ek_udc_data = {
 /*
  * SPI devices.
  */
+static struct at86rf230_platform_data rf230_pdata = {
+       .rstn   = AT91_PIN_PB10,
+       .slp_tr = AT91_PIN_PB11,
+       .dig2   = AT91_PIN_PB12,
+};
+
 static struct spi_board_info ek_spi_devices[] = {
 #if !(defined(CONFIG_MMC_ATMELMCI) || defined(CONFIG_MMC_AT91))
        {       /* DataFlash chip */

@@ -118,6 +125,16 @@ static struct spi_board_info ek_spi_devices[] = {
                .bus_num        = 0,
        },
 #endif
+#if defined(CONFIG_IEEE802154_AT86RF230)
+       {
+               .modalias       = "at86rf230",
+               .chip_select    = 3,
+               .max_speed_hz   = 3 * 1000 * 1000,
+               .bus_num        = 1,
+               .irq            = AT91_PIN_PB13,
+               .platform_data  = &rf230_pdata,
+       },
+#endif
 #endif
 };

With best regards,
Alexander Smirnov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: at86rf230.c
Type: text/x-csrc
Size: 23107 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120620/a7d3ec16/attachment-0001.bin>

On Wednesday 20 June 2012, Alexander Smirnov wrote:

I'm the developer of the IEEE 802.15.4 kernel branch, and currently
I've faced with the problem regarding mach-at91 arch and hope you can
advise me.

I've been working with at86rf231 transceiver (RF231 extender)
connected via SPI to at91sam9g20ek board. The driver works and tested
for kernels up to 3.1 version (versions 3.2-latest haven't ever been
tested yet).
Several days ago I've ported the IEEE802.15.4 stack to the latest
kernel and see some strange things: RF231 interrupt handler is
permanently pulled right after driver's probe method (the RF231 chip
is in disabled mode, so it can't generate interrupts at that moment).
Also I've noticed that each ENTER key pressing in minicom generates a
new interrupt. It looks like somebody else uses the same pin/pins for
its needs...

Do you have any ideas what can be changed since 3.1 kernel that this
problem arose.

It might not be the problem you are faced with but note that at91
is moving towards probing all devices using the device tree, so
starting with linux-3.4 you should be defining the device in the
at91sam9g20ek.dts file for your board and use the generic
board-dt.c file. The platform_data gets replaced with
calls to of_get_gpio() in that case.

	Arnd

Hi,

2012/6/22 Arnd Bergmann [off-list ref]:

On Wednesday 20 June 2012, Alexander Smirnov wrote:

quoted

I'm the developer of the IEEE 802.15.4 kernel branch, and currently
I've faced with the problem regarding mach-at91 arch and hope you can
advise me.

I've been working with at86rf231 transceiver (RF231 extender)
connected via SPI to at91sam9g20ek board. The driver works and tested
for kernels up to 3.1 version (versions 3.2-latest haven't ever been
tested yet).
Several days ago I've ported the IEEE802.15.4 stack to the latest
kernel and see some strange things: RF231 interrupt handler is
permanently pulled right after driver's probe method (the RF231 chip
is in disabled mode, so it can't generate interrupts at that moment).
Also I've noticed that each ENTER key pressing in minicom generates a
new interrupt. It looks like somebody else uses the same pin/pins for
its needs...

Do you have any ideas what can be changed since 3.1 kernel that this
problem arose.

It might not be the problem you are faced with but note that at91
is moving towards probing all devices using the device tree, so
starting with linux-3.4 you should be defining the device in the
at91sam9g20ek.dts file for your board and use the generic
board-dt.c file. The platform_data gets replaced with
calls to of_get_gpio() in that case.

Thank you for the reply!

Are you going to add SPI section to the device tree in the nearest
future or I can do it by myself and send you the patch? The reason is
that this week I merged at86rf230 driver to the 'net-next' tree, but
it won't work without platform data.

Alex

? ? ? ?Arnd

On Thursday 28 June 2012, Alexander Smirnov wrote:

quoted

It might not be the problem you are faced with but note that at91
is moving towards probing all devices using the device tree, so
starting with linux-3.4 you should be defining the device in the
at91sam9g20ek.dts file for your board and use the generic
board-dt.c file. The platform_data gets replaced with
calls to of_get_gpio() in that case.

Thank you for the reply!

Are you going to add SPI section to the device tree in the nearest
future or I can do it by myself and send you the patch? The reason is
that this week I merged at86rf230 driver to the 'net-next' tree, but
it won't work without platform data.

Jean-Christophe or Nicolas might now what the status is for atmel-spi.
It seems like it would be trivial to just add the compatible string in
the atmel-spi driver, which would let us probe all of its child devices
using DT.

	Arnd

On 06/28/2012 04:30 PM, Arnd Bergmann :

On Thursday 28 June 2012, Alexander Smirnov wrote:

quoted

quoted

It might not be the problem you are faced with but note that at91
is moving towards probing all devices using the device tree, so
starting with linux-3.4 you should be defining the device in the
at91sam9g20ek.dts file for your board and use the generic
board-dt.c file. The platform_data gets replaced with
calls to of_get_gpio() in that case.

Thank you for the reply!

Are you going to add SPI section to the device tree in the nearest
future or I can do it by myself and send you the patch? The reason is
that this week I merged at86rf230 driver to the 'net-next' tree, but
it won't work without platform data.

Jean-Christophe or Nicolas might now what the status is for atmel-spi.
It seems like it would be trivial to just add the compatible string in
the atmel-spi driver, which would let us probe all of its child devices
using DT.

Dear Alexander,

There has been an attempt to move the spi-atmel.c driver to device tree.
You can check the status of the discussion in by searching the message
subjects:

[PATCH 1/4 v4] of_spi: add generic binding support to specify cs gpio
[PATCH 1/4 v5] of_spi: add generic binding support to specify cs gpio

I guess that you can take these patches as examples for moving to device
tree on your AT91 based board (beware you should set pin muxing in your
bootloader).

There is a "work in progress" snapshot of this work in at91 git tree/branch:
git://github.com/at91linux/linux-at91.git   ghnew/j/for-3.5-wip

commit: 5f31f2573e7e9369500118e1b8fd026392fc0982
commit: 93fd57e73502656a139879518b397711cc305c6a

Best regards,
-- 
Nicolas Ferre

Dear Alexander,

There has been an attempt to move the spi-atmel.c driver to device tree.
You can check the status of the discussion in by searching the message
subjects:

[PATCH 1/4 v4] of_spi: add generic binding support to specify cs gpio
[PATCH 1/4 v5] of_spi: add generic binding support to specify cs gpio

I guess that you can take these patches as examples for moving to device
tree on your AT91 based board (beware you should set pin muxing in your
bootloader).

There is a "work in progress" snapshot of this work in at91 git tree/branch:
git://github.com/at91linux/linux-at91.git ? ghnew/j/for-3.5-wip

commit: 5f31f2573e7e9369500118e1b8fd026392fc0982
commit: 93fd57e73502656a139879518b397711cc305c6a

Dear at91 team,

thank you very much for the hints!

Alex

Best regards,
--
Nicolas Ferre