On Wed, Nov 03, 2021 at 10:04:18AM +0000, Mark Rutland wrote: > On Wed, Nov 03, 2021 at 06:57:28PM +0900, Youngmin Nam wrote: > > On Wed, Nov 03, 2021 at 10:04:36AM +0100, Krzysztof Kozlowski wrote: > > > On 03/11/2021 10:24, Youngmin Nam wrote: > > > > On Wed, Nov 03, 2021 at 09:18:07AM +0100, Krzysztof Kozlowski wrote: > > > >> On 03/11/2021 01:09, Youngmin Nam wrote: > > > >>> On Tue, Nov 02, 2021 at 10:28:10AM +0000, Mark Rutland wrote: > > > >>>> On Tue, Nov 02, 2021 at 09:11:21AM +0900, Youngmin Nam wrote: > > > > >>>>> + evt->rating = 500; /* use value higher than ARM arch timer */ > > > >>>> > > > >>>> Previously Will asked you to try CLOCK_EVT_FEAT_PERCPU here, and to set > > > >>>> the C3STOP flag on the arch timer via the DT when necessary, rather than > > > >>>> trying to override the arch timer like this: > > > >>>> > > > >>>> https://protect2.fireeye.com/v1/url?k=72526080-2dc9598b-7253ebcf-002590f5b904-ca603717c6462908&q=1&e=be56aa83-dbac-4639-913d-d388620fe3fc&u=https%3A%2F%2Flore.kernel.org%2Fr%2F20211027073458.GA22231%40willie-the-truck > > > > >>> Hi Mark. > > > >>> It looks like you missed my previous mail. > > > >>> https://protect2.fireeye.com/v1/url?k=ab15817a-cbf71c27-ab140a35-000babd9f1ba-123b7f313b1b1ccc&q=1&e=34c8716e-6d2e-4d8e-82fe-04777ebc5eb3&u=https%3A%2F%2Flore.kernel.org%2Fall%2F20211029035422.GA30523%40perf%2F%23t > > > >>> > > > >>> Yes, I believe Will's suggestion definitely will work. > > Then please do so. > > > > >>> But that is for performance not functionality. > > No; it's about *consistency*, and avoiding unnecssary special cases. The > whole point is that marking the generic timer as C3STOP *accurately* > describes how the timer behaves on your platform, and marking the MCTv2 > as a percpu timer which *can* act as a back-up also aligns with that. > > That approach leaves the policy in the kernel, and we can play about > with that later without functional breakage. > > > > >>> As a driver for new H/W IP I would like to confirm functionality first. > > > >>> We need more time to test this feature with our exynos core power down feature. > > > >>> And we need to do a various regression test whether there is another corner case or not. > > > >>> So, how about we apply Will's suggetion later after the current patchset is merged first? > > > >>> After doing our regression test with our exynos core power down feature, we can confirm this. > > > >> > > > >> Not really, because once it is merged there is no incentive to fix it or > > > >> simply changing it can be forgotten. Also similarly to commit > > > >> 6282edb72bed ("clocksource/drivers/exynos_mct: Increase priority over > > > >> ARM arch timer"), there should be a valid and serious reason to > > > >> prioritize Exynos MCT. > > It's also worth nothing that the case described for 6282edb72bed is > really a system design erratum, since the counter is supposed to be in > an always-on power domain and should be counting well before a regular > OS kernel boots. The arm64 kernel requires the architected counter to be > running before it is entered, or there will be subtle breakage. > > > > > No, it's not. I also want to decrease MCTv2 timer rating so that we want to use arm arch timer as a default. > > > > But this feature has to be confirmed with core power down feature enabled. > > > > Without core power down feature, we can't comfirm this. > > > > Ater that we need to check whether there is regression or not related power, stability, and so on. > > > > I'm not saying I will not apply Will's suggestion but I just want to apply later after some hard test. > > > > > > You repeat the same argument, the same words. Nothing new. Repeating the > > > same won't change it, use the lower priority. This is a patch for new > > > kernel, so there is a plenty of time to test it and it won't affect your > > > production environment. > > > > > So, how about we control timer rating value with DT ? > > Of course the default rating value should be lower than arm arch timer's. > > Do you agree with this? > > No; placing a rating value in the DT is a hack. That should *not* live > in the DT because it's linux-internal detail and not a description of > the HW. > So, how do we use MCTv2 only for clock event device if there are some limitations caused by SoC design implemention ? > Thanks, > Mark. >
