On Mon, 2015-07-13 at 16:04 +0100, Leif Lindholm wrote: > Thanks Haojian, > > A few comments below. It looks sane to me, but the patches to > individual platforms may need some testing. > > As a note to my future self, I should go through these platforms and > delete the default timer period from the platform-specific config > files and get it from a central config file instead. > > / > Leif > > On Mon, Jul 13, 2015 at 10:25:12PM +0800, Haojian Zhuang wrote: > > Fix PcdTimerPeriod from 100,000 to 10,000. Since the unit base of > > PcdTimerPeriod is 100ns. > > > > 100,000 * 100ns = 10ms (interval of hardware timer interrupt) > > 10,1000 * 100ns = 1ms (interval of hardware timer interrupt) > 10,000 >
Thanks for catching it. I'll deliver the next version to fix it. > > In GRUB, the required timer granularity is only 1ms. If interval of > > hardware timer interrupt is 10ms in UEFI, GRUB will only get all > > timer granularity >= 10ms. At least, the timeout of boot menu in > > GRUB is much slower. Only the interval of hardware timer interrupt > > is 1ms in UEFI, the timeout of boot menu in GRUB works well. > > I would add that this is something that needs to be better handled in > GRUB as well (which I'm working on), but changing the default solves > the problem in the current versions of GRUB (and a 1ms timer > granularity is nice to have anyway). After thinking a while, I think that we needn't to handle it in GRUB. Aarch64 requires generic timer at least 1MHz. And SP804 is always working in 1MHz in UEFI. 1 / 1MHz = 1us 1 / 1ms = 1KHz And in current embedded SoC solutions, the lowest frequency of hardware timer is 32.768KHz. So all of them could meet the requirement of timer granularity = 1ms. > > Contributions to EDK2 must contain a contributed-under tag - like so: > Contributed-under: TianoCore Contribution Agreement 1.0 > Thanks. I'll append them. > > Signed-off-by: Haojian Zhuang <haojian.zhu...@linaro.org> > > --- > > Also, since EDK2 coding style mandates DOS-style line endings, these > get corrupted when sending a patch inline in an email. This is still > my preferred way of doing it, for reviewing purposes. But it can be > helpful to also put (after the ---) a link to the patch or patch > series in your personal git tree - so that people can access an > uncorrupted version of your patch. > I'll append the link. Regards Haojian ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
