Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
On 07/29/15 08:29, Doug Anderson wrote: > Hi, > Hi, > On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov wrote: >> Hi Doug, >> >> On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson wrote: >>> Alexey, >>> >>> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov >>> wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? >>> >>> I hate to burst your bubble here, but... >>> >>> ...I think it would be a bad idea to use the cp15 counter on exynos >>> 5422. According to Samsung, there are issues where using cp15 could >>> sometimes return the wrong value, especially if you happen to read it >>> while on an A7 instead of an A15. It will tend to work pretty well, >>> but Samsung claimed that it might not work right on some CPUs or at >>> some temperatures. >> >> I think this is right time when I can say "If only I had known about >> it before!". > > Yeah, we spent a whole lot of time on this too before giving up after > we found out it was not possible to use. > > >> That's quite interesting especially about temperature issues. >> Maybe it's worth to insert comments in driver/docs about this. > > Maybe not a bad idea. Depends if you think someone else will try to > do this... ...and if they do, will they check mailing list traffic. > > >>> Generally I'd say that if the arch timer works for you: use the arch >>> timer. If the arch timer doesn't work for you, use the MCT. >>> One more thing, if you change it for your own private platform, it's up to you but if not, i.e., for mass product, please don't change it. Because it's not guaranteed even you haven't seen its failure... >>> -Doug >> >> I possess no knowledge if there're any different hw revisions of >> odroid-xu3 on the field >> but looks like arch timer works fine for me on odroid-xu3 Exynos5422 >> SoC with upstream kernel. > > Well, it looked like it worked for us too. In fact, I never saw a > failure. All I know is that Samsung said: don't do this, it's not a > good idea. The performance gain wasn't enough to go against that... > That's when I started trying to optimize the MCT a little bit. ;) > Yeah and it was tough time for me when I discussed about that with hardware designer at that time ... haha... Thanks, Doug. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Hi, On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov wrote: > Hi Doug, > > On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson wrote: >> Alexey, >> >> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov >> wrote: >>> Hi all, >>> >>> year(s) ago it was discovered that MCT timer and ARM architectured >>> timer >>> are the same hardware with different interface. Here [1]. >>> >>> I followed mail-list discussions about removing MCT and using arch >>> timer for Exynos5-based SoCs but things aren't moving at least latest >>> upstream kernel on odroid-xu3 will use MCT as default timers. >>> Maybe the reason are some power-management related things that very >>> specific to Samsung. I don't know. >>> >>> >>> Idea of this draft patchset comes from Doug patches when he tried to >>> optimize read of 64-bit counter located in mmio. [2] >>> Why not using cp15 counter instead if possible? >> >> I hate to burst your bubble here, but... >> >> ...I think it would be a bad idea to use the cp15 counter on exynos >> 5422. According to Samsung, there are issues where using cp15 could >> sometimes return the wrong value, especially if you happen to read it >> while on an A7 instead of an A15. It will tend to work pretty well, >> but Samsung claimed that it might not work right on some CPUs or at >> some temperatures. > > I think this is right time when I can say "If only I had known about > it before!". Yeah, we spent a whole lot of time on this too before giving up after we found out it was not possible to use. > That's quite interesting especially about temperature issues. > Maybe it's worth to insert comments in driver/docs about this. Maybe not a bad idea. Depends if you think someone else will try to do this... ...and if they do, will they check mailing list traffic. >> Generally I'd say that if the arch timer works for you: use the arch >> timer. If the arch timer doesn't work for you, use the MCT. >> >> -Doug > > I possess no knowledge if there're any different hw revisions of > odroid-xu3 on the field > but looks like arch timer works fine for me on odroid-xu3 Exynos5422 > SoC with upstream kernel. Well, it looked like it worked for us too. In fact, I never saw a failure. All I know is that Samsung said: don't do this, it's not a good idea. The performance gain wasn't enough to go against that... That's when I started trying to optimize the MCT a little bit. ;) -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Hi Doug, On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson wrote: > Alexey, > > On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov wrote: >> Hi all, >> >> year(s) ago it was discovered that MCT timer and ARM architectured >> timer >> are the same hardware with different interface. Here [1]. >> >> I followed mail-list discussions about removing MCT and using arch >> timer for Exynos5-based SoCs but things aren't moving at least latest >> upstream kernel on odroid-xu3 will use MCT as default timers. >> Maybe the reason are some power-management related things that very >> specific to Samsung. I don't know. >> >> >> Idea of this draft patchset comes from Doug patches when he tried to >> optimize read of 64-bit counter located in mmio. [2] >> Why not using cp15 counter instead if possible? > > I hate to burst your bubble here, but... > > ...I think it would be a bad idea to use the cp15 counter on exynos > 5422. According to Samsung, there are issues where using cp15 could > sometimes return the wrong value, especially if you happen to read it > while on an A7 instead of an A15. It will tend to work pretty well, > but Samsung claimed that it might not work right on some CPUs or at > some temperatures. I think this is right time when I can say "If only I had known about it before!". That's quite interesting especially about temperature issues. Maybe it's worth to insert comments in driver/docs about this. > I've added Alim who provided this information to me (in the private > http://crosbug.com/p/29556). He may be able to elaborate more. Alim, could you please add details if any? > Generally I'd say that if the arch timer works for you: use the arch > timer. If the arch timer doesn't work for you, use the MCT. > > -Doug I possess no knowledge if there're any different hw revisions of odroid-xu3 on the field but looks like arch timer works fine for me on odroid-xu3 Exynos5422 SoC with upstream kernel. Is it right direction to switch xu3 to arch timer? Do you have any info or ideas about enabling MCT G_TCON register to start arch timer and what's the best way to do it? Thanks. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Alexey, On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov wrote: > Hi all, > > year(s) ago it was discovered that MCT timer and ARM architectured > timer > are the same hardware with different interface. Here [1]. > > I followed mail-list discussions about removing MCT and using arch > timer for Exynos5-based SoCs but things aren't moving at least latest > upstream kernel on odroid-xu3 will use MCT as default timers. > Maybe the reason are some power-management related things that very > specific to Samsung. I don't know. > > > Idea of this draft patchset comes from Doug patches when he tried to > optimize read of 64-bit counter located in mmio. [2] > Why not using cp15 counter instead if possible? I hate to burst your bubble here, but... ...I think it would be a bad idea to use the cp15 counter on exynos 5422. According to Samsung, there are issues where using cp15 could sometimes return the wrong value, especially if you happen to read it while on an A7 instead of an A15. It will tend to work pretty well, but Samsung claimed that it might not work right on some CPUs or at some temperatures. I've added Alim who provided this information to me (in the private http://crosbug.com/p/29556). He may be able to elaborate more. Generally I'd say that if the arch timer works for you: use the arch timer. If the arch timer doesn't work for you, use the MCT. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
On Tue, Jul 28, 2015 at 4:02 PM, Mark Rutland wrote: > On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote: >> Hi all, >> >> year(s) ago it was discovered that MCT timer and ARM architectured >> timer >> are the same hardware with different interface. Here [1]. > > Are they actually interfaces to the same timer, or are they just fed by > the same system counter? Good question goes to Samsung maintainers. I can find unanswered mail thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/258576.html Let me quote Kukjin: " Basically the two blocks are connected and the arch timer uses the count value from MCT for reference" >> I followed mail-list discussions about removing MCT and using arch >> timer for Exynos5-based SoCs but things aren't moving at least latest >> upstream kernel on odroid-xu3 will use MCT as default timers. >> Maybe the reason are some power-management related things that very >> specific to Samsung. I don't know. >> >> >> Idea of this draft patchset comes from Doug patches when he tried to >> optimize read of 64-bit counter located in mmio. [2] >> Why not using cp15 counter instead if possible? > > If they're the same device, then you can simply use the architected > timer, and gain all the benefits without additional code. That could > give you additional benefits (e.g. VDSO support). Right. I like the idea to use arch_timer. Odroid-xu3 works fine with it. Looks like Samsung have some games with power management stuff that can't be opened/told and they use MCT that works well for their needs. This draft patchset is only about little speedup of MCT operations that still here and used. To start arch timer we may need to initialize G_TCON register in MCT like it's done in Xen: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/platforms/exynos5.c;h=79e3a5faf9fa6f37d99040f85c6dccbd9312c856;hb=HEAD in exynos5_init_time(). I guess not all bootloaders properly initialize MCT on Exynos5 boards. If addition of similar platform callback and enable of arch_timer are steps in right direction I can take a look on it. Or as suggested in one mail thread: if MCT is present in DT then MCT driver lookup arch_timer in dt, find it, initialize G_TCON reg and gives up to allow arch_timer to do it job (in that case we need to init MCT before arch timer). >> Previous numbers for 100 gettimeofday() calls from userspace >> are about 1 ms. With this patches we have 0.5 ms or even better. >> So twice as fast. >> >> Just as matter of interest i tried to perform 200 sched_yield() >> calls from userspace. I see around 20% speedup with patches applied. >> >> I tried to use hackbench but it's hard to feel the difference, maybe >> speedup is 0.5% but with bad fluctuation. >> >> Everything is tested on odroid-xu3. >> Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't >> have arch timer. >> >> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014 >> -May/256943.html >> [2] https://lkml.org/lkml/2014/6/20/431 >> >> >> >> Current code created with such assumptions: >> -- don't want to insert huge refactoring in MCT code; >> -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit >> mode so i don't want to build described functionality on ARM64. > > For arm64 the generic timer is mandatory, and I can't imagine a case > where we wouldn't use it in preference. Yep. That's why probably MCT isn't used on arm64. >> Currently i'm trying to patch odroid-xu3 DT only. >> -- firmware on odroid-xu3 is broken and secondary cores start >> in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode; >> -- in addition instead of DT property I may parse PFR regs and find >> Generic Timer Extension there. > > ID_PFR1.GenTimer only tells you whether or not the generic timer is > implemented in the CPU, not how it's wired up (e.g. whether it shares > the system counter with the MCT), so I don't think it tells you anything > useful. > > Thanks, > Mark. Yep, just only one of the initial points to understand is it any use trying. Thanks. Best regards, Klimov Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote: > Hi all, > > year(s) ago it was discovered that MCT timer and ARM architectured > timer > are the same hardware with different interface. Here [1]. Are they actually interfaces to the same timer, or are they just fed by the same system counter? > I followed mail-list discussions about removing MCT and using arch > timer for Exynos5-based SoCs but things aren't moving at least latest > upstream kernel on odroid-xu3 will use MCT as default timers. > Maybe the reason are some power-management related things that very > specific to Samsung. I don't know. > > > Idea of this draft patchset comes from Doug patches when he tried to > optimize read of 64-bit counter located in mmio. [2] > Why not using cp15 counter instead if possible? If they're the same device, then you can simply use the architected timer, and gain all the benefits without additional code. That could give you additional benefits (e.g. VDSO support). > Previous numbers for 100 gettimeofday() calls from userspace > are about 1 ms. With this patches we have 0.5 ms or even better. > So twice as fast. > > Just as matter of interest i tried to perform 200 sched_yield() > calls from userspace. I see around 20% speedup with patches applied. > > I tried to use hackbench but it's hard to feel the difference, maybe > speedup is 0.5% but with bad fluctuation. > > Everything is tested on odroid-xu3. > Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't > have arch timer. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014 > -May/256943.html > [2] https://lkml.org/lkml/2014/6/20/431 > > > > Current code created with such assumptions: > -- don't want to insert huge refactoring in MCT code; > -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit > mode so i don't want to build described functionality on ARM64. For arm64 the generic timer is mandatory, and I can't imagine a case where we wouldn't use it in preference. > Currently i'm trying to patch odroid-xu3 DT only. > -- firmware on odroid-xu3 is broken and secondary cores start > in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode; > -- in addition instead of DT property I may parse PFR regs and find > Generic Timer Extension there. ID_PFR1.GenTimer only tells you whether or not the generic timer is implemented in the CPU, not how it's wired up (e.g. whether it shares the system counter with the MCT), so I don't think it tells you anything useful. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? Previous numbers for 100 gettimeofday() calls from userspace are about 1 ms. With this patches we have 0.5 ms or even better. So twice as fast. Just as matter of interest i tried to perform 200 sched_yield() calls from userspace. I see around 20% speedup with patches applied. I tried to use hackbench but it's hard to feel the difference, maybe speedup is 0.5% but with bad fluctuation. Everything is tested on odroid-xu3. Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't have arch timer. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014 -May/256943.html [2] https://lkml.org/lkml/2014/6/20/431 Current code created with such assumptions: -- don't want to insert huge refactoring in MCT code; -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit mode so i don't want to build described functionality on ARM64. Currently i'm trying to patch odroid-xu3 DT only. -- firmware on odroid-xu3 is broken and secondary cores start in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode; -- in addition instead of DT property I may parse PFR regs and find Generic Timer Extension there. I hope you are not getting bored reading to me. Current code is a little bit draft so comments and ideas are welcome. Best regards, Alexey Klimov -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html