On Wed, Oct 27, 2021 at 10:38:37AM +0900, Youngmin Nam wrote: > On Tue, Oct 26, 2021 at 01:00:51PM +0200, Krzysztof Kozlowski wrote: > > On 26/10/2021 12:45, Youngmin Nam wrote: > > > On Tue, Oct 26, 2021 at 09:10:28AM +0200, Krzysztof Kozlowski wrote: > > >> On 26/10/2021 03:47, Youngmin Nam wrote: > > >>>> If everyone added a new driver to avoid integrating with existing code, > > >>>> we would have huge kernel with thousands of duplicated solutions. The > > >>>> kernel also would be unmaintained. > > >>>> > > >>>> Such arguments were brought before several times - "I don't want to > > >>>> integrating with existing code", "My use case is different", "I would > > >>>> need to test the other cases", "It's complicated for me". > > >>>> > > >>>> Instead of pushing a new vendor driver you should integrate it with > > >>>> existing code. > > >>>> > > >>> Let me ask you one question. > > >>> If we maintain as one driver, how can people who don't have the new MCT test the new driver? > > >> > > >> I assume you talk about a case when someone else later changes something > > >> in the driver. Such person doesn't necessarily have to test it. The same > > >> as in all other cases (Exynos MCT is not special here): just ask for > > >> testing on platform one doesn't have. > > >> > > >> Even if you submit this as separate driver, there is the exact same > > >> problem. People will change the MCTv2 driver without access to hardware. > > >> > > > Yes, I can test the new MCT driver if someone ask for testing after modifying the new driver. > > > But in this case, we don't need to test the previous MCT driver. We have only to test the new MCT driver. > > > > Like with everything in Linux kernel. We merge instead of duplicate. > > It's not an argument. > > > > >> None of these differ for Exynos MCT from other drivers, e.g. mentioned > > >> Samsung PMIC drivers, recently modified (by Will and Sam) the SoC clock > > >> drivers or the ChipID drivers (changed by Chanho). > > > From HW point of view, the previous MCT is almost 10-year-old IP without any major change and > > > it will not be used on next new Exynos SoC. > > > MCTv2 is the totally newly designed IP and it will replace the Exynos system timer. > > > Device driver would be dependent with H/W. We are going to apply a lot of changes for this new MCT. > > > For maintenance, I think we should separate the new MCT driver for maintenance. > > > > > > > There are several similarities which actually suggest that you > > exaggerate the differences. > > > > The number of interrupts is the same (4+8 in older one, 12 in new one...). > > I didn't "exaggerate" at all. > The numer of interrups is the same. But their usage is completely different. > The type of each timer is different. > And previous MCT can only support upto 8 cores. > > * MCTv1 (Let me call previous MCT as MCTv1) > - 4 global timer + 8 local timer > - Global timer and local timer are totally different. > - 4 global timer have only one 64bit FRC that serves as the "up-counter" with 4 "comparators" > - 8 local timer have 8 of 32bit FRC that serves as the "down-counter" without any "comparators".(just expire timer) > - local timer can be used as per-cpu event timer, so it can only support upto 8 cores. > > * MCTv2 > - There are no global timer and local timer anymore. > - 1 of 64bit FRC that serves as "up-counter" (just counter without "comparators") > - 12 comaprators (These are not "counter") can be used as per-cpu event timer so that it can support upto 12 cores. > - RTC source can be used as backup source. > > > You assign the MCT priority also as higher than Architected Timer > > (+Cc Will and Mark - is it ok for you?) > > evt->rating = 500; /* use value higher than ARM arch timer * > > > Yes, this is absolutely correct on event timer. > We cannot use arm arch timer which is operating based on PPI as per-cpu event timer because of poewr mode. You should be able to now that I've added support for per-cpu wakeup timers. As long as the Arm arch timer is marked as C3STOP (e.g. by sticking the "local-timer-stop" property in the DT notes), then the MCT will be used as the wakeup source if you set the CLOCK_EVT_FEAT_PERCPU feature flag. Give it a try. Will
