Re: Wireless Module: Carl9170 driver and firmware communication

Re: Wireless Module: Carl9170 driver and firmware communication

[Ashkan Parcham Kashani]

Dear linux-wireless mailing list,

I'm working on a project where I need to communicate some additional
control information between the carl9170 driver and firmware. I am not
exactly sure where the best place to add this extra information would be. I
assumed that the DMA might work if I can extend it and reserve some
space for the controls. I only need a few bytes for the communication.

I also considered using device registers for this, but it's hard to
find documentation of which registers may be free to use.

It would be great to get some opinions on the best way to do this;
would you have any advice?

If the DMA is a possible way to go, how would I go about extending it?
To my understanding, the firmware sets the needed sizes, and the
driver allocates the DMA accorting to specification.

I'm also wondering how one would go about interrupting the firmware.
At times, the driver will need to interrupt the firmware, in which
case the firmware should stop transmitting any packets it is currently
transmitting.

Any help would be much appreciated. Thanks so much!
--
Ashkan Kashani
ashkan.parchamkashani@mail.utoronto.ca
4th year Engineering Science | Universtiy of Toronto

Re: Wireless Module: Carl9170 driver and firmware communication

[Christian Lamparter]

Hello,

On Tue, Mar 31, 2015 at 2:40 AM, Ashkan Parcham Kashani
<ashkan.parchamkashani@mail.utoronto.ca> wrote:
> I'm working on a project where I need to communicate some additional
> control information between the carl9170 driver and firmware. I am not
> exactly sure where the best place to add this extra information would be.
> I assumed that the DMA might work if I can extend it and reserve some
> space for the controls. I only need a few bytes for the communication.

Should be doable. Add your fields to the "_carl9170_tx_superdesc"
and "carl9170_tx_superdesc" for both the driver and the firmware
and recompile. Watch out: the size of the structs should be a
multiple of 4. (Note: this is only for TX!)

> I also considered using device registers for this, but it's hard to
> find documentation of which registers may be free to use.
This is way easier, as the modified firmware will continue to work
with the standard driver and vice versa. The driver can directly
write into and read from the program/data ram of the firmware.
Add your fields to the firmware_context_struct in carlfw/include/carl9170.h
and add a handle_mywork() into main_loop() in carlfw/src/main.c.

> I'm also wondering how one would go about interrupting the firmware.
> At times, the driver will need to interrupt the firmware, in which
> case the firmware should stop transmitting any packets it is currently
> transmitting.
Depends on how you implement it. There's a watchdog that needs to
be serviced. If you don't want to deal with the dog, you can set (stops
TX) or clear (resumes TX) the AR9170_MAC_VIRTUAL_CCA_QX bits
in the "AR9170_MAC_REG_QOS_PRIORITY_VIRTUAL_CCA" register.

Note: The firmware doesn't have any real interrupt handling.

Regards,
   Christian

Wireless Module: Carl9170 driver and firmware communication

[Ashkan Parcham Kashani]

Hello,

I'm working on a project where I need to communicate some additional
control information between the carl9170 driver and firmware. I am not
exactly sure where the best place to add this information would be. I
assumed that the DMA might work if I can extend it and reserve some
space for the controls. I only need a few bytes for the communication.

I also considered using device registers for this, but it's hard to
find documentation of which registers may be free to use.

It would be great to get some opinions on the best way to do this;
would you have any advice?

If the DMA is a possible way to go, how would I go about extending it?
To my understanding, the firmware sets the needed sizes, and the
driver allocates the DMA accorting to specification.

I'm also wondering how one would go about interrupting the firmware.
At times, the driver will need to interrupt the firmware, in which
case the firmware should stop transmitting any packets it is currently
transmitting.

Any help would be much appreciated. Thanks so much!
--
Ashkan Kashani
ashkan.parchamkashani@mail.utoronto.ca