Skip to contentSkip to conversation

wl12xx: driver for TI wl1251 chipset

DISCUSSION Kalle Valo 2 participants 6 messages Feb 10, 2009 – Feb 19, 2009

lore
Share & tools
lore

Kalle Valo

author
#0 lore raw

Hello all,

in Nokia we have been working on a mac80211 driver for TI wl1251 chipset. We named it as wl12xx, and in the future we are planning to add wl1271 support to the driver as well.

wl1251 is a chipset for embedded devices, supporting both SDIO and SPI busses. Currently the driver supports only SPI. Adding support 1253 (the 5 GHz version) should be relatively easy. More information here:

http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4711&navigationId=12494&templateId=6123

Because the patch is over 200 KB, the driver is temporarily available from my server:

http://www.valot.fi/kalle/tmp/wl12xx/wl12xx-2.6.28-1.patch

The patch is against linux-2.6.28-omap1 tag available here:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0ec95b96fd77036a13398c66901e11cd301190d0

Currently known issues:

o short slot and preamble support missing
o rts/cts and cts-to-self missing
o no proper bitrate control support
o using deprecated omap_get_config(), need to convert to use platform_data
o firmware wakeup not working, deepest sleep state in firmware not yet enabled

Also the driver has a netlink interface which is used for running production line tests and pushing the calibration data from user space.

All comments and review is greatly appreciated. After receiving all the comments, I will port the driver to the wireless-testing tree and submit a version for the possible inclusion.

TI has given us technical support while developing the driver, big thanks to them.

Signature · 1 line
Kalle Valo
#1 lore raw
Quoted 30 lines · Kalle Valo

Hello all,

in Nokia we have been working on a mac80211 driver for TI wl1251 chipset. We named it as wl12xx, and in the future we are planning to add wl1271 support to the driver as well.

wl1251 is a chipset for embedded devices, supporting both SDIO and SPI busses. Currently the driver supports only SPI. Adding support 1253 (the 5 GHz version) should be relatively easy. More information here:

http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4711&navigationId=12494&templateId=6123

Because the patch is over 200 KB, the driver is temporarily available from my server:

http://www.valot.fi/kalle/tmp/wl12xx/wl12xx-2.6.28-1.patch

The patch is against linux-2.6.28-omap1 tag available here:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0ec95b96fd77036a13398c66901e11cd301190d0

Currently known issues:

o short slot and preamble support missing
o rts/cts and cts-to-self missing
o no proper bitrate control support
o using deprecated omap_get_config(), need to convert to use platform_data
o firmware wakeup not working, deepest sleep state in firmware not yet enabled

Quoted 3 lines

Also the driver has a netlink interface which is used for running production line tests and pushing the calibration data from user space.

When is the calibration data required, and is it likely to change at runtime? What I really mean is, if the calibration data isn't required to change while the interface is up, maybe use request_firmware() and load it at device open time or something?

Dan

author
#2 lore raw
Quoted 4 lines · Dan Williams
Quoted 2 lines

production line tests and pushing the calibration data from user space.

When is the calibration data required

When we boot the firmware, that is during interface up.

Quoted 1 line

and is it likely to change at runtime?

It's device specific. Each device is calibrated in the factory and the calibration data is stored to a special partition in the device.

Quoted 3 lines

What I really mean is, if the calibration data isn't required to change while the interface is up, maybe use request_firmware() and load it at device open time or something?

request_firmware() has access only to the rootfs which the user can flash anytime he wants. So we would have to create the calibration file during every boot, or something like that. I guess it's doable but a bit ugly.

Signature · 1 line
Kalle Valo
#3 lore raw
Quoted 5 lines · Kalle Valo
Quoted 3 lines · Dan Williams
Quoted 2 lines

production line tests and pushing the calibration data from user space.

Quoted 8 lines
Quoted 1 line

When is the calibration data required

When we boot the firmware, that is during interface up.

Quoted 1 line

and is it likely to change at runtime?

It's device specific. Each device is calibrated in the factory and the calibration data is stored to a special partition in the device.

By "special partition", you mean a filesystem? Or something else?

Quoted 8 lines
Quoted 3 lines

What I really mean is, if the calibration data isn't required to change while the interface is up, maybe use request_firmware() and load it at device open time or something?

request_firmware() has access only to the rootfs which the user can flash anytime he wants. So we would have to create the calibration file during every boot, or something like that. I guess it's doable but a bit ugly.

Yeah, that's somewhat ugly then.

Dan

author
#4 lore raw
Quoted 8 lines · ext Dan Williams
Quoted 7 lines · Kalle Valo
Quoted 4 lines · Dan Williams
Quoted 2 lines

production line tests and pushing the calibration data from user space.

When is the calibration data required

Quoted 8 lines
Quoted 6 lines

When we boot the firmware, that is during interface up.

Quoted 1 line

and is it likely to change at runtime?

It's device specific. Each device is calibrated in the factory and the calibration data is stored to a special partition in the device.

By "special partition", you mean a filesystem? Or something else?

A proprietary binary format in a mtd partition basically.

Signature · 1 line
Kalle Valo
author
#5 lore raw
In reply to Kalle Valo
Quoted 5 lines · Valo Kalle (Nokia-D/Tampere)

Hello all,

in Nokia we have been working on a mac80211 driver for TI wl1251 chipset. We named it as wl12xx, and in the future we are planning to add wl1271 support to the driver as well.

[...]

Quoted 1 line

http://www.valot.fi/kalle/tmp/wl12xx/wl12xx-2.6.28-1.patch

[...]

Quoted 8 lines

Currently known issues:

o short slot and preamble support missing
o rts/cts and cts-to-self missing
o no proper bitrate control support
o using deprecated omap_get_config(), need to convert to use platform_data
o firmware wakeup not working, deepest sleep state in firmware not yet enabled

I received few comments, I'll list them here so that I don't forget them:

o netlink interface might create problems, I'll remove netlink. cfor now but will revisit it later
o wl12xx_80211.h is, well, ugly
o fragmentation in the hardware might not be worth the trouble
o "*fc &= ~IEEE80211_FCTL_PROTECTED;" shouldn't be necessary, just set the status properly
o get_tsf() doesn't need to be atomic anymore, ad-hoc tsf hack can be removed

If anyone has more comments, please send them soon. I'm planning to prepare a patch for adding wl12xx to wireless-testing next week. Let's see if John takes it :)

Signature · 1 line
Kalle Valo