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

[Kalle Valo <kalle.valo@iki.fi>]

"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