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.
--
Kalle Valo
Dan Williams <[email protected]> writes:
>> 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.
> 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.
> 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.
--
Kalle Valo
On Tue, 2009-02-10 at 18:23 +0200, Kalle Valo wrote:
> Dan Williams <[email protected]> writes:
>
> >> 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.
>
> > 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?
> > 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
ext Dan Williams <[email protected]> writes:
> On Tue, 2009-02-10 at 18:23 +0200, Kalle Valo wrote:
>> Dan Williams <[email protected]> writes:
>>
>> >> 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.
>>
>> > 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.
--
Kalle Valo
"Valo Kalle (Nokia-D/Tampere)" <[email protected]> writes:
> 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.
[...]
> http://www.valot.fi/kalle/tmp/wl12xx/wl12xx-2.6.28-1.patch
[...]
> 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 :)
--
Kalle Valo
On Tue, 2009-02-10 at 12:32 +0200, Kalle Valo wrote:
> 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.
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