On Wed, May 21, 2014 at 6:24 AM, Kukjin Kim <[email protected]> wrote: > Doug Anderson wrote: >> >> Kukjin, >> > Hi Doug, > >> On Fri, May 16, 2014 at 5:02 PM, Kukjin Kim <[email protected]> wrote: >> > On 05/17/14 07:56, Chirantan Ekbote wrote: >> >>>>> >> >>>>> Anyway, I'm by no means opposed to switching to arch timers. They >> >>>>> provide a well designed, generic interface and drivers shared by >> >>>>> multiple platforms, which means more code sharing and possibly more >> >>>>> eyes >> >>>>> looking at the code, which is always good. However if they don't >> >>>>> support >> >>>>> low power states correctly, we can't just remove MCT. >> >>>> >> >>>> >> >>>> I think low power states aren't in mainline (right?). >> >>>> >> >>>> One solution that might work could be to leave the device tree entry >> >>>> alone but change the MCT init code to simply act as a no-op if it sees >> >>>> an arch timer is in the device tree and enabled. Then when/if someone >> >>>> got the low power states enabled we could just change source code >> >>>> rather than dts files. >> >>>> >> >> >> >> Doug and I were talking about this and we think we may have a way to >> >> have the mct and arch timers co-exist. The main issue is that the mct >> >> (and therefore arch timer) gets cleared once during boot and every >> >> time we do a suspend / resume. This happens in >> >> exynos4_mct_frc_start() but it's not immediately clear to us why the >> >> counter needs to be reset at all. If we remove the lines that clear >> >> the counter then there is no longer an issue with having both the mct >> >> and the arch timers on at the same time. >> >> >> >> Alternately, if there is some code that depends on the mct being reset >> >> we could store an offset instead of clearing the counter and then >> >> subtract that offset every time something reads it. Doug has a patch >> >> that does this at >> >> https://chromium-review.googlesource.com/#/c/200298/. Effectively the >> >> visible behavior will not change. Would either of these options work? >> >> >> > Hi all, >> > >> > Even though I've heard something about the behavior of mct and arch >> > timer...but I couldn't finish the talk to h/w guys yet. I need to talk >> again >> > in next week then I could provide some useful information. Sorry for late >> > and can you please wait a minute before deciding whatever. >> >> I think we could wait a few days. Note however, that Chirantan's >> latest proposal keeps all existing functionality (can use both MCT and >> arch timers). It merely removes the unnecessary bit of the MCT init >> code setting the timer. No functionality is affected by that. >> > Let me explain the behavior of MCT and arch timer. > > Basically the two blocks are connected and the arch timer uses the count > value from MCT for reference on exynos5250 so following in this mail thread > is expected and it's true. > > * If you read the MCT and the arch timer, they give the same value. > > And as you know, usually the access to arch timer is faster than MCT because > of APB bus access...but using MCT has some benefits sometimes it depends on > use case of power management though. BTW, since exynos5260, exynos5420 and > exynos5800 doesn't support arch timer, we have been using MCT on exynos5 SoCs.
This I don't understand. What, _exactly_ are the benefits of MCT. You've been vague on this several times now and it is not helping us understand why Samsung (and you personally) prefer MCT. Details, please. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
