From: Youngmin Nam <youngmin.nam@samsung.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: will@kernel.org, mark.rutland@arm.com, daniel.lezcano@linaro.org,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, pullip.cho@samsung.com,
hoony.yu@samsung.com, hajun.sung@samsung.com,
myung-su.cha@samsung.com, kgene@kernel.org
Subject: Re: [PATCH v2 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC
Date: Wed, 3 Nov 2021 18:24:45 +0900 [thread overview]
Message-ID: <20211103092444.GA7013@perf> (raw)
In-Reply-To: <83f6574b-bbab-f0c3-7198-f773c3dcfc63@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 3985 bytes --]
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:
> >>> Exynos MCT version 2 is composed of 1 FRC and 12 comparators.
> >>> There are no global timer and local timer anymore.
> >>> The 1 of 64bit FRC serves as "up-counter"(not "comparators").
> >>> The 12 comaprators(not "counter") can be used as per-cpu event timer
> >>> so that it can support upto 12 cores.
> >>> And a RTC source can be used as backup clock source.
> >>
> >> [...]
> >>
> >>> +static int exynos_mct_starting_cpu(unsigned int cpu)
> >>> +{
> >>> + struct mct_clock_event_device *mevt = per_cpu_ptr(&percpu_mct_tick, cpu);
> >>> + struct clock_event_device *evt = &mevt->evt;
> >>> +
> >>> + snprintf(mevt->name, sizeof(mevt->name), "mct_comp%d", cpu);
> >>> +
> >>> + evt->name = mevt->name;
> >>> + evt->cpumask = cpumask_of(cpu);
> >>> + evt->set_next_event = exynos_comp_set_next_event;
> >>> + evt->set_state_periodic = mct_set_state_periodic;
> >>> + evt->set_state_shutdown = mct_set_state_shutdown;
> >>> + evt->set_state_oneshot = mct_set_state_shutdown;
> >>> + evt->set_state_oneshot_stopped = mct_set_state_shutdown;
> >>> + evt->tick_resume = mct_set_state_shutdown;
> >>> + evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
> >>> + 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
> >>
> >> There are a bunch of things that depend on the architected timer working
> >> as a clocksource (e.g. vdso, kvm), and it *should* work as a lock
> >> clockevent_device if configured correctly, and it's much more consistent
> >> with *everyone else* to use the arhcitected timer by default.
> >>
> >> Please try as Will suggested above, so that this works from day one.
> >>
> >> Thanks,
> >> Mark.
> >>
> >
> > 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.
> > But that is for performance not functionality.
> > 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.
>
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.
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-03 8:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20211101234449epcas2p385cd5133ff8ed3a248649b4134bc0113@epcas2p3.samsung.com>
2021-11-02 0:11 ` [PATCH v2 0/2] Indroduce Exynos Multi Core Timer version 2 Youngmin Nam
2021-11-02 0:11 ` [PATCH v2 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC Youngmin Nam
2021-11-02 10:28 ` Mark Rutland
2021-11-03 0:09 ` Youngmin Nam
2021-11-03 8:18 ` Krzysztof Kozlowski
2021-11-03 9:24 ` Youngmin Nam [this message]
2021-11-03 9:04 ` Krzysztof Kozlowski
2021-11-03 9:57 ` Youngmin Nam
2021-11-03 10:04 ` Mark Rutland
2021-11-04 0:21 ` Youngmin Nam
2021-11-04 9:44 ` Mark Rutland
2021-11-05 0:46 ` Youngmin Nam
2021-11-05 9:31 ` Will Deacon
2021-11-02 0:11 ` [PATCH v2 2/2] dt-bindings: timer: samsung,s5e99xx-mct: Document s5e99xx-mct bindings Youngmin Nam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211103092444.GA7013@perf \
--to=youngmin.nam@samsung.com \
--cc=daniel.lezcano@linaro.org \
--cc=hajun.sung@samsung.com \
--cc=hoony.yu@samsung.com \
--cc=kgene@kernel.org \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=myung-su.cha@samsung.com \
--cc=pullip.cho@samsung.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).