Hi, Frans,
> Alright, I was just wondering. Seems like a waste to be waiting for something that's already finished ;-).
> There's of course a risk that times may fluctuate between firmware versions. Did you take that into account in the code?
> Or is there a hard maximum time for these operations defined for the firmware?
Thanks for your reminding.
After I check with the firmware guy, I will change the value of delay.
What we do here is to read the data from flash and calculate their checksum and
will cost about 6ms for 1024 bytes. So there is a delay for 10 ms per 1024 bytes.
But in some situation, the controller will change it's running frequency(like do noise immunity),
10ms could be too margin.
Hn.chen
-----Original Message-----
From: Frans Klaver [mailto:[email protected]]
Sent: Tuesday, June 02, 2015 2:18 AM
To: Hn Chen
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH v5] Fix the resolution issue in ChromeOS
On Tue, Jun 02, 2015 at 12:39:13AM +0800, Hn Chen wrote:
> Hi, Klaver,
>
> Sorry for replying late and thanks for your opinion !
>
> About the patch descrition, I will follow your suggestion and
Ok. More on this is in Documentation/SubmittingPatches.
> maybe add more commemts between codes to be easy to read.
Only where really necessary. If you do, explain _why_ you do stuff, rather than how. The how is already in the code. If how isn't clear enough, clear up the code instead.
> >Are these (and other) delay times based on datasheet values?
> The time consuming is about the computing power of WDT87xx's controller.
> The value is from the algorithm/firmware engineer of wdt87xx.
> They think it is reasonable value to wait the controller to finish the computing.
Alright, I was just wondering. Seems like a waste to be waiting for something that's already finished ;-). There's of course a risk that times may fluctuate between firmware versions. Did you take that into account in the code? Or is there a hard maximum time for these operations defined for the firmware?
> For the rest parts, I'll just follow your opinion to modify them.
>
> Best Regards,
> hn.chen
>
Thanks,
Frans
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Wed, Jun 10, 2015 at 4:51 PM, Hn Chen <[email protected]> wrote:
> Hi, Frans,
>
>> Alright, I was just wondering. Seems like a waste to be waiting for something that's already finished ;-).
>> There's of course a risk that times may fluctuate between firmware versions. Did you take that into account in the code?
>> Or is there a hard maximum time for these operations defined for the firmware?
> Thanks for your reminding.
> After I check with the firmware guy, I will change the value of delay.
> What we do here is to read the data from flash and calculate their checksum and
> will cost about 6ms for 1024 bytes. So there is a delay for 10 ms per 1024 bytes.
> But in some situation, the controller will change it's running frequency(like do noise immunity),
> 10ms could be too margin.
Any chance this sort of thing could be detected?