Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Kalle Valo]

"John Willis" <John.Willis@Distant-earth.com> writes:

> Gents,
>
> Attached are some very hacky (even after a quick cleanup) patches that add
> something like support for reading the EEPROM NVS calibration data into the
> WL1251 driver. It seems just good enough to get the driver up and playing
> nicely. 

Thanks a lot, this is good stuff. Now we have all hardware
configurations (known by me) supported in wl1251: SPI, SDIO, without
EEPROM and with EEPROM.

> I quickly rebased the patches on the top of wireless-testing, with any luck
> they still work however I can't test as there is something badly borked for
> OMAP3 in the mainline tree feeding WT at the moment. I have left out a lot
> of my development chaff and rubbish from the patches.

In cases like this I usually merge linux-omap to wireless-testing,
it's quite simple and fast thing to do. That way I get the omap
hardware booting with latest wireless stuff.

> They have only been tested on OMAP3 OpenPandora boards using SDIO. I still
> think timing needs tweaking but I have not had a chance to look into that.

I have few comments about the patch. I think it's better to configure
EEPROM support runtime and not via Kconfig. Also I don't like
hungarian notation :)

Is it okay if I clean it up a bit and then send it to John Linville?
Better to have the patch in the tree as early as possible, as long as it
doesn't break existing functionality. We can always fix it later if
there's something broken.

Thanks again for your patches and please keep on sending them :)

-- 
Kalle Valo

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Bob Copeland]

On Thu, Oct 15, 2009 at 04:51:49PM +0100, John Willis wrote:
> The patches are not yet complete but they do work for me (tm) so I would be
> very interested in seeing if these hacks also allow us to use the EEPROM on
> the HTC Dream (Bob, can you try that?, no rush however).

Yeah, I'll give it a spin.  It'd be really nice if people don't need to
use the NVS file.  Do you know the structure of the EEPROM data?

-- 
Bob Copeland %% www.bobcopeland.com

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Kalle Valo]

Bob Copeland <me@bobcopeland.com> writes:

> On Thu, Oct 15, 2009 at 04:51:49PM +0100, John Willis wrote:
>> The patches are not yet complete but they do work for me (tm) so I would be
>> very interested in seeing if these hacks also allow us to use the EEPROM on
>> the HTC Dream (Bob, can you try that?, no rush however).
>
> Yeah, I'll give it a spin.  It'd be really nice if people don't need to
> use the NVS file.

Didn't HTC Dream store the NVS file in the main flash memory? AFAIK
the EEPROM support in wl1251 needs a separate chip for the EEPROM, so
if someone has stored the NVS file to the main flash memory I really
doubt that they would still use EEPROM with wl1251. So the NVS file is
stored either to somewhere outside wl1251 or to the EEPROM, but not
both.

-- 
Kalle Valo

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Kalle Valo]

"John Willis" <John.Willis@Distant-earth.com> writes:

>> Didn't HTC Dream store the NVS file in the main flash memory? AFAIK
>> the EEPROM support in wl1251 needs a separate chip for the EEPROM, so
>> if someone has stored the NVS file to the main flash memory I really
>> doubt that they would still use EEPROM with wl1251. So the NVS file is
>> stored either to somewhere outside wl1251 or to the EEPROM, but not
>> both.
>
> Yep, the NVS on the MSM HTC devices I have seen have been stored in the main
> NAND flash at a given offset outside of the main rootfs 'but' I was sure
> someone had mentioned that the G1 also featured an EEPROM attached to the
> WL1251 as we have on the Pandora.

Ah, ok. Then your patch is really needed for those devices.

> Mea culpa, I could well be wrong on that one. I assumed that the HTC
> platform maintained both as some odd hangover to the Windows CE
> software roots of the platform (it would not be the 1st time ;-)).

Yeah, usually it's like that :)

> I guess that raises another point then, maybe should we look at another
> method of getting the NVS from NAND if the platform gives it's offsets? No
> idea how that would work in a clean way however but something to consider as
> the HTC devices will make up a chunk of the long term userbase.

I think it's better do this in user space, doing this from kernel in a
portable way is too complicated. In earlier discussions the conclusion
has been to use request_firmware() interface and a modified udev
script which retrieves the calibration data from NAND/NOR/whatever and
pushes it to kernel. 

To my knowledge nobody hasn't implemented this yet, but I think that's
the way to go. But as always, I'm open for suggestions.

-- 
Kalle Valo

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Kalle Valo]

"John Willis" <John.Willis@Distant-earth.com> writes:

> Gents,

Hi John,

> Attached are some very hacky (even after a quick cleanup) patches that add
> something like support for reading the EEPROM NVS calibration data into the
> WL1251 driver. It seems just good enough to get the driver up and playing
> nicely. 

Sorry, but I found time to work on this patch only now. Busy schedules
etc :/

Now I noticed that the Signed-off-by line is missing, can you please
send that also? A reply to this email is enough.

-- 
Kalle Valo

Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver

[Kalle Valo]

"John Willis" <John.Willis@Distant-earth.com> writes:

>> Now I noticed that the Signed-off-by line is missing, can you please
>> send that also? A reply to this email is enough.
>
> The initial plan was for an RFC not a commit so I left off the signed off
> but as the patch has been reworked consider.

Actually it's a good idea to always include the signed off line, that
way anyone can freely work on the patch. Tagging the patch as RFC
should be enough to make it sure that it's not applied.

> Signed-off-by: David-John Willis <John.Willis@Distant-earth.com>

Thanks!

-- 
Kalle Valo