fetching calibration data from flash

fetching calibration data from flash

[Sven Schnelle]

Hi List,

currently ath10k fetches calibration data from the board.bin file
via request_firmware(). Usually HW manufactures are using one
flash partition for the calibration data (see ath9k for example).
So we would end up reading the file from flash, and writing it into
a ramdisk so that ath10k can fetch it.

I would prefer to add support to ath10k to fetch that data directly from
flash. IMHO there are two options to do so:

a) Use platform data, like ath9k does.

b) add a module option to ath10k, and let ath10k fetch the files via mtd 
API.
     Has the downside of requiring MTD (maybe add a config option to 
disable that?),
     but i like that more than the ath9k way of reading an arbitrary 
memory region and
     circumventing the MTD layer.

Any thoughts? I can prepare a patch if needed.

Sven

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Sven Schnelle <svens@stackframe.org> writes:

> currently ath10k fetches calibration data from the board.bin file via
> request_firmware(). Usually HW manufactures are using one flash
> partition for the calibration data (see ath9k for example). So we
> would end up reading the file from flash, and writing it into a
> ramdisk so that ath10k can fetch it.
>
> I would prefer to add support to ath10k to fetch that data directly
> from flash. IMHO there are two options to do so:
>
> a) Use platform data, like ath9k does.

I prefer this option.

> b) add a module option to ath10k, and let ath10k fetch the files via
> mtd API. Has the downside of requiring MTD (maybe add a config option
> to disable that?)

This sounds like a hack to me. How to specify the exact location? Are we
sure devices will only use MTD to store the calibration data?

> but i like that more than the ath9k way of reading an arbitrary memory
> region and circumventing the MTD layer.

Sorry, I didn't quite understand this comment. What do you mean exactly
with an arbitrary region? The memory location should be defined by the
platform data from which ath10k just copies data to the target.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Sven Schnelle]

Am 10.06.2014 10:28, schrieb Kalle Valo:
> Sven Schnelle <svens@stackframe.org> writes:
>
>> currently ath10k fetches calibration data from the board.bin file via
>> request_firmware(). Usually HW manufactures are using one flash
>> partition for the calibration data (see ath9k for example). So we
>> would end up reading the file from flash, and writing it into a
>> ramdisk so that ath10k can fetch it.
>>
>> I would prefer to add support to ath10k to fetch that data directly
>> from flash. IMHO there are two options to do so:
>>
>> a) Use platform data, like ath9k does.
> I prefer this option.
>
>> b) add a module option to ath10k, and let ath10k fetch the files via
>> mtd API. Has the downside of requiring MTD (maybe add a config option
>> to disable that?)
> This sounds like a hack to me. How to specify the exact location? Are we
> sure devices will only use MTD to store the calibration data?
>
>> but i like that more than the ath9k way of reading an arbitrary memory
>> region and circumventing the MTD layer.
> Sorry, I didn't quite understand this comment. What do you mean exactly
> with an arbitrary region? The memory location should be defined by the
> platform data from which ath10k just copies data to the target.
>

Ok, let's do the first option. Ignore that comment - i'm fine with using 
platform data.

Sven

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Re: fetching calibration data from flash

[Matti Laakso]

> Hi List,
>
> currently ath10k fetches calibration data from the board.bin file
> via request_firmware(). Usually HW manufactures are using one
> flash partition for the calibration data (see ath9k for example).
> So we would end up reading the file from flash, and writing it into
> a ramdisk so that ath10k can fetch it.
>
> I would prefer to add support to ath10k to fetch that data directly from
> flash. IMHO there are two options to do so:
>
> a) Use platform data, like ath9k does.
>
> b) add a module option to ath10k, and let ath10k fetch the files via mtd 
> API.
>      Has the downside of requiring MTD (maybe add a config option to 
> disable that?),
>      but i like that more than the ath9k way of reading an arbitrary 
> memory region and
>      circumventing the MTD layer.
>
> Any thoughts? I can prepare a patch if needed.
>
> Sven

There's yet another method: Use platform data to provide only a file
name and then use request_firmware to load it from a file under
/lib/firmware. Then it is up to the platform support code to get the
data there. This is used in OpenWrt by rt2x00 drivers.

Matti

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Matti Laakso <malaakso@elisanet.fi> writes:

>> a) Use platform data, like ath9k does.
>>
>> b) add a module option to ath10k, and let ath10k fetch the files via mtd 
>> API.
>>      Has the downside of requiring MTD (maybe add a config option to 
>> disable that?),
>>      but i like that more than the ath9k way of reading an arbitrary 
>> memory region and
>>      circumventing the MTD layer.
>>
>> Any thoughts? I can prepare a patch if needed.
>
> There's yet another method: Use platform data to provide only a file
> name and then use request_firmware to load it from a file under
> /lib/firmware. Then it is up to the platform support code to get the
> data there. This is used in OpenWrt by rt2x00 drivers.

That's true. Now that you mention this, I remember that this was also
suggested in linux-wireless list for wl1251 (a long time ago when I was
still working on that driver). And there doesn't even need to a real
file in the filesystem, it's possible to implement a udev script which
does what it ever needs to feed the data to the kernel, be it reading
from MTD partition or whatever.

But why let the user name provide the file name? Why cannot it be a
fixed name, like "cal.bin"?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Matti Laakso]

On 10.06.2014 10:54, Kalle Valo wrote:
> Matti Laakso <malaakso@elisanet.fi> writes:
>
>>> a) Use platform data, like ath9k does.
>>>
>>> b) add a module option to ath10k, and let ath10k fetch the files via mtd 
>>> API.
>>>      Has the downside of requiring MTD (maybe add a config option to 
>>> disable that?),
>>>      but i like that more than the ath9k way of reading an arbitrary 
>>> memory region and
>>>      circumventing the MTD layer.
>>>
>>> Any thoughts? I can prepare a patch if needed.
>> There's yet another method: Use platform data to provide only a file
>> name and then use request_firmware to load it from a file under
>> /lib/firmware. Then it is up to the platform support code to get the
>> data there. This is used in OpenWrt by rt2x00 drivers.
> That's true. Now that you mention this, I remember that this was also
> suggested in linux-wireless list for wl1251 (a long time ago when I was
> still working on that driver). And there doesn't even need to a real
> file in the filesystem, it's possible to implement a udev script which
> does what it ever needs to feed the data to the kernel, be it reading
> from MTD partition or whatever.
>
> But why let the user name provide the file name? Why cannot it be a
> fixed name, like "cal.bin"?
>

If there are multiple WNICs each with its own calibration data?

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Matti Laakso <malaakso@elisanet.fi> writes:

>> But why let the user name provide the file name? Why cannot it be a
>> fixed name, like "cal.bin"?

s/user name/user space/

> If there are multiple WNICs each with its own calibration data?

Ah, of course.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Ben Greear]

On 06/10/2014 02:03 AM, Kalle Valo wrote:
> Matti Laakso <malaakso@elisanet.fi> writes:
> 
>>> But why let the user name provide the file name? Why cannot it be a
>>> fixed name, like "cal.bin"?
> 
> s/user name/user space/
> 
>> If there are multiple WNICs each with its own calibration data?
> 
> Ah, of course.


Another nice feature would be to allow configuring the number of
vdevs, peers, etc per NIC.  That way, you could have one NIC
tuned to be one big AP with lots of peers, and a second could
be several small APs with fewer peers and some stations, etc.

Maybe this could be a separate file, or maybe it would be worth
adding this to a TLV type file with cal.bin being part of the
data?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Ben Greear <greearb@candelatech.com> writes:

> Another nice feature would be to allow configuring the number of
> vdevs, peers, etc per NIC.  That way, you could have one NIC
> tuned to be one big AP with lots of peers, and a second could
> be several small APs with fewer peers and some stations, etc.
>
> Maybe this could be a separate file, or maybe it would be worth
> adding this to a TLV type file with cal.bin being part of the
> data?

So basically you want a configuration (".ini") file for ath10k, right? I
have seen those in out-of-tree drivers, but not in upstream drivers.

If I'm guessing right what these configuration items would do in ath10k,
I think instead of static configuration it would be much more flexible
to have this stuff configurable dynamically. But how, that's the
question. A sysfs file to set different profiles (or modes) was the
first one which came to my mind, but that's ugly.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Ben Greear]

On 06/11/2014 01:38 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> Another nice feature would be to allow configuring the number of
>> vdevs, peers, etc per NIC.  That way, you could have one NIC
>> tuned to be one big AP with lots of peers, and a second could
>> be several small APs with fewer peers and some stations, etc.
>>
>> Maybe this could be a separate file, or maybe it would be worth
>> adding this to a TLV type file with cal.bin being part of the
>> data?
>
> So basically you want a configuration (".ini") file for ath10k, right? I
> have seen those in out-of-tree drivers, but not in upstream drivers.
>
> If I'm guessing right what these configuration items would do in ath10k,
> I think instead of static configuration it would be much more flexible
> to have this stuff configurable dynamically. But how, that's the
> question. A sysfs file to set different profiles (or modes) was the
> first one which came to my mind, but that's ugly.

You also need this info before you do the initial firmware configuration,
otherwise you are going to have to restart firmware again later to apply
the new config (and advertise different interface combinations up the
stack, etc).

Maybe a kernel module option to point to a file-name would work
(with some way to give different options to different nics in the
same system).

It's easy to get combinations that crash the firmware, so the driver
will still have to sanity-check any incoming 'suggestions'.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Ben Greear <greearb@candelatech.com> writes:

> On 06/11/2014 01:38 AM, Kalle Valo wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>> Another nice feature would be to allow configuring the number of
>>> vdevs, peers, etc per NIC.  That way, you could have one NIC
>>> tuned to be one big AP with lots of peers, and a second could
>>> be several small APs with fewer peers and some stations, etc.
>>>
>>> Maybe this could be a separate file, or maybe it would be worth
>>> adding this to a TLV type file with cal.bin being part of the
>>> data?
>>
>> So basically you want a configuration (".ini") file for ath10k, right? I
>> have seen those in out-of-tree drivers, but not in upstream drivers.
>>
>> If I'm guessing right what these configuration items would do in ath10k,
>> I think instead of static configuration it would be much more flexible
>> to have this stuff configurable dynamically. But how, that's the
>> question. A sysfs file to set different profiles (or modes) was the
>> first one which came to my mind, but that's ugly.
>
> You also need this info before you do the initial firmware configuration,
> otherwise you are going to have to restart firmware again later to apply
> the new config (and advertise different interface combinations up the
> stack, etc).

Ok.

> Maybe a kernel module option to point to a file-name would work
> (with some way to give different options to different nics in the
> same system).

Over years I have seen these .ini suggestions few times and I never have
been very fund of the idea. For example, that would mean yet another
layer of configuration and more things to support. I would prefer to
find a more automatic way of doing the same.

And I'm not sure if kernel maintainers would even accept this.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Ben Greear]

On 06/16/2014 05:24 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 06/11/2014 01:38 AM, Kalle Valo wrote:
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>> Another nice feature would be to allow configuring the number of
>>>> vdevs, peers, etc per NIC.  That way, you could have one NIC
>>>> tuned to be one big AP with lots of peers, and a second could
>>>> be several small APs with fewer peers and some stations, etc.
>>>>
>>>> Maybe this could be a separate file, or maybe it would be worth
>>>> adding this to a TLV type file with cal.bin being part of the
>>>> data?
>>>
>>> So basically you want a configuration (".ini") file for ath10k, right? I
>>> have seen those in out-of-tree drivers, but not in upstream drivers.
>>>
>>> If I'm guessing right what these configuration items would do in ath10k,
>>> I think instead of static configuration it would be much more flexible
>>> to have this stuff configurable dynamically. But how, that's the
>>> question. A sysfs file to set different profiles (or modes) was the
>>> first one which came to my mind, but that's ugly.
>>
>> You also need this info before you do the initial firmware configuration,
>> otherwise you are going to have to restart firmware again later to apply
>> the new config (and advertise different interface combinations up the
>> stack, etc).
>
> Ok.
>
>> Maybe a kernel module option to point to a file-name would work
>> (with some way to give different options to different nics in the
>> same system).
>
> Over years I have seen these .ini suggestions few times and I never have
> been very fund of the idea. For example, that would mean yet another
> layer of configuration and more things to support. I would prefer to
> find a more automatic way of doing the same.
>
> And I'm not sure if kernel maintainers would even accept this.

I think you could do a decent job of inferring most values with
a single module-param that requests the number of vdevs to support.
This is more of a hack though, and will not satisfy all needs I
think.

I also think that we will want to be able to configure firmware on
a per-nic basis instead of per-machine.  If we did that, we could poke
any special config into the firmware images using the existing meta-data
api.  Should be easy enough to write a small program that prepended
the config to a generic firmware..then those that care can create their
own customized firmware images quickly and easily.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Kalle Valo]

Ben Greear <greearb@candelatech.com> writes:

> I also think that we will want to be able to configure firmware on
> a per-nic basis instead of per-machine.  If we did that, we could poke
> any special config into the firmware images using the existing meta-data
> api.  Should be easy enough to write a small program that prepended
> the config to a generic firmware..then those that care can create their
> own customized firmware images quickly and easily.

That's still essentially an ini file, just using a binary format hidden
inside the firmware image. The firmware meta data is for advertising
capabilities of the firmware binary so that ath10k choose correct
settings to run the binary, not for delivering configuration settings
from user space.

If we would start providing driver settings from firmware binaries that
would just confuse anyone.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: fetching calibration data from flash

[Ben Greear]

On 06/16/2014 08:28 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
>> I also think that we will want to be able to configure firmware on
>> a per-nic basis instead of per-machine.  If we did that, we could poke
>> any special config into the firmware images using the existing meta-data
>> api.  Should be easy enough to write a small program that prepended
>> the config to a generic firmware..then those that care can create their
>> own customized firmware images quickly and easily.
> 
> That's still essentially an ini file, just using a binary format hidden
> inside the firmware image. The firmware meta data is for advertising
> capabilities of the firmware binary so that ath10k choose correct
> settings to run the binary, not for delivering configuration settings
> from user space.
> 
> If we would start providing driver settings from firmware binaries that
> would just confuse anyone.

Ok.  I'll post to netdev to see if anyone else has figured out
a good way to configure info before loading firmware.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k