Re: [PATCH] drivers/net/ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154

[Michael Hennerich <michael.hennerich@analog.com>]

On 12/07/2015 01:02 PM, Stefan Schmidt wrote:
> Hello.
>
> I found some time at the weekend hooking it up on my raspberry pi.
>
> On 04/12/15 13:07, Stefan Schmidt wrote:
>> Hello.
>>
>> On 04/12/15 10:09, michael.hennerich@analog.com wrote:
>>
>>> The ADF7242 requires an add-on firmware for the automatic IEEE 802.15.4
>>> operating modes. The firmware file is currently made available on the
>>> ADF7242 wiki page here [1]
>>
>> Just being curious here. Is there any way to get the firmware source
>> and/or compile your own? Its the first hardware for IEEE 802.15.4 I
>> have seen that have a special firmware for this which triggers my
>> curiosity. :)


Unfortunately No - We don't release the firmware assembly code.
Or the required compiler.


>>
>> Anyway, this has not that much to do with the driver review here as it
>> can obviously go in with the binary firmware. We just need to make
>> sure to also bring the firmware into the linux-firmware repo in time.
>>
>>> [1]
>>> http://wiki.analog.com/resources/tools-software/linux-drivers/networking-mac802154/adf7242
>>>
>
> There are two firmware zip files listed:
> ram_lab_7242_2_0_ieee15dot4_full_r5.zip
> <https://wiki.analog.com/_media/resources/tools-software/linux-drivers/networking-mac802154/ram_lab_7242_2_0_ieee15dot4_full_r5.zip>
>
> rom_ram_7242_2_0_ieee15dot4_full_r3.zip
> <https://wiki.analog.com/_media/resources/tools-software/linux-drivers/networking-mac802154/rom_ram_7242_2_0_ieee15dot4_full_r3.zip>
>
>
> Both contain a adf7242_firmware.bin file but also some different data
> file. Which one is the correct one here? Some explanation would be helpful.

Please use the latest R5 release file. I'll remove the old one soon.
The older firmware had problems with the back-off exponent randomization.


>
>
>>> [2]
>>> http://sourceforge.net/p/linux-zigbee/kernel/ci/devel/tree/drivers/ieee802154/adf7242.c
>>>
>>>
>>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>>> ---
>>>   .../devicetree/bindings/net/ieee802154/adf7242.txt |   18 +
>>>   drivers/net/ieee802154/Kconfig                     |    5 +
>>>   drivers/net/ieee802154/Makefile                    |    1 +
>>>   drivers/net/ieee802154/adf7242.c                   | 1183
>>> ++++++++++++++++++++
>>>   4 files changed, 1207 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
>>>   create mode 100644 drivers/net/ieee802154/adf7242.c
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
>>> b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
>>> new file mode 100644
>>> index 0000000..dea5124
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
>>> @@ -0,0 +1,18 @@
>>> +* ADF7242 IEEE 802.15.4 *
>>> +
>>> +Required properties:
>>> +  - compatible:        should be "adi,adf7242"
>>> +  - spi-max-frequency:    maximal bus speed (12.5 MHz)
>>> +  - reg:        the chipselect index
>>> +  - interrupts:        the interrupt generated by the device via pin
>>> IRQ1.
>>> +            IRQ_TYPE_LEVEL_HIGH (4) or IRQ_TYPE_EDGE_FALLING (1)
>
>
> IRQ1 would be pin7 on the interface connector, right? I'm using this one
> but I have trouble when transmitting

Yes IRQ1 is Pin7 on the PMOD connector.

>
> adf7242 spi32766.0: Error xmit: Retry count exceeded Status=0x3


That's failure NOACK. Is there a node on the same channel/PAN which 
could response?
reading proc/interrupts should show some interrupts in this case...

>
> and I was wondering if this comes from trouble setting the IRQ up
> correctly. The driver comes up fine, loads the firmware and I can
> configure it with iwpan. Device tree config looks like this, which is
> the same SPI port and IRQ I successfully use for two other transceivers:
>
> &spi {
>      status = "okay";
>      adf7242@0 {
>          compatible = "adi,adf7242";
>          spi-max-frequency = <6000000>;
>          reg = <0>;
>          interrupts = <23 4>;
>          interrupt-parent = <&gpio>;
>      };
> };
>
>
>>
>>
>>> diff --git a/drivers/net/ieee802154/Makefile
>>> b/drivers/net/ieee802154/Makefile
>>> index cf1d2a6..3a923d3 100644
>>> --- a/drivers/net/ieee802154/Makefile
>>> +++ b/drivers/net/ieee802154/Makefile
>>> @@ -3,3 +3,4 @@ obj-$(CONFIG_IEEE802154_AT86RF230) += at86rf230.o
>>>   obj-$(CONFIG_IEEE802154_MRF24J40) += mrf24j40.o
>>>   obj-$(CONFIG_IEEE802154_CC2520) += cc2520.o
>>>   obj-$(CONFIG_IEEE802154_ATUSB) += atusb.o
>>> +obj-$(CONFIG_IEEE802154_ADF7242) += adf7242.o
>>> diff --git a/drivers/net/ieee802154/adf7242.c
>>> b/drivers/net/ieee802154/adf7242.c
>>> new file mode 100644
>>> index 0000000..48268b1
>>> --- /dev/null
>>> +++ b/drivers/net/ieee802154/adf7242.c
>>> @@ -0,0 +1,1183 @@
>>> +/*
>>> + * Analog Devices ADF7242 Low-Power IEEE 802.15.4 Transceiver
>>> + *
>>> + * Copyright 2009-2015 Analog Devices Inc.
>>> + *
>>
>> Personally I like having a link to the actual data sheet inside the
>> driver header. This makes only sense if it is a stable URI.
>>
>
> The one I found and looking at is this one:
> http://www.analog.com/media/en/technical-documentation/data-sheets/ADF7242.pdf


This one is pretty static.
We can also use the short link:
www.analog.com/ADF7242 which brings you to the product page.
the datasheet is right below the block diagram.


>
>
>
>>> +static int adf7242_hw_init(struct adf7242_local *lp)
>>> +{
>>> +    int ret;
>>> +    const struct firmware *fw;
>>> +
>>> +    adf7242_cmd(lp, CMD_RC_RESET);
>>> +    adf7242_cmd(lp, CMD_RC_IDLE);
>>> +
>>> +    /* get ADF7242 addon firmware
>>> +     * build this driver as module
>>
>> Hmm, this brings up the question if the firmware is also fetched if
>> the driver is built into the kernel directly?
>
> Let me answer this myself here. If you build everything into the kernel
> you might run into trouble when the drivers is initialised before the fs
> system is up. That way the driver has no access to the fs and is unable
> to load the firmware. You can either switch this driver to a module or
> you can supply the kernel with the needed firmware during compile so it
> will be inside the kernel binary. Copy the file into the firmware
> directory inside your kernel tree and use these options:
>
> CONFIG_EXTRA_FIRMWARE="adf7242_firmware.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
>
> That way the firmware loading worked for me for a kernel with everything
> build into big blob.

That's what I do.

>
> regards
> Stefan Schmidt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif