[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c032b7f7-ccea-4e3d-a3fc-d772d034b195@opensynergy.com>
Date: Fri, 20 Oct 2023 17:41:49 +0200
From: Peter Hilber <peter.hilber@...nsynergy.com>
To: Thomas Gleixner <tglx@...utronix.de>, lakshmi.sowjanya.d@...el.com,
jstultz@...gle.com, giometti@...eenne.com, corbet@....net,
linux-kernel@...r.kernel.org
Cc: x86@...nel.org, linux-doc@...r.kernel.org,
andriy.shevchenko@...ux.intel.com, eddie.dong@...el.com,
christopher.s.hall@...el.com, pandith.n@...el.com,
mallikarjunappa.sangannavar@...el.com, thejesh.reddy.t.r@...el.com
Subject: Re: [PATCH v1 4/6] pps: generators: Add PPS Generator TIO Driver
On 17.10.23 18:27, Thomas Gleixner wrote:
> On Tue, Oct 17 2023 at 10:54, lakshmi.sowjanya.d@...el.com wrote:
>> + guard(spinlock_irqsave)(&tio->lock);
>> + if (enable && !tio->enabled) {
>> + if (!is_current_clocksource_art_related()) {
>> + dev_err(tio->dev, "PPS cannot be started as clock is not related to ART");
>> + return -EPERM;
>> + }
>
> Ah. Here is the usecase for this magic patch 3/6 hackery. Again, it's
> the wrong abstraction. You want something like:
>
> timekeeping_clocksource_has_base(CSID_X86_ART);
>
> or something like this, which can be handled completely in the core
> code.
>
> All of this needs some serious rework. See the below disfunctional
> mockup patch for illustration.
>
> There is also a patch series, which tried to replace the clocksource
> pointer in system_counterval_t with a clocksource ID:
>
> https://lore.kernel.org/all/20230818011256.211078-1-peter.hilber@opensynergy.com
>
> That went nowhere, but has some valid points. I took some of Peter's (cc'ed)
> ideas into the mockup, but did it slightly different to make all of this
> indirection mess go away.
>
> There are certainly bugs and thinkos in that mockup. If you find them,
> you can keep and fix them :)
>
Hi Sowjanya,
I am working on another iteration of the patch series cited by Thomas,
which would implement part of the mockup. But the scope of the original
patch series would remain, so no changes to ART conversion code, no
introduction of the clocksource_base concept... The patch series should
still be compatible with Thomas' proposal, though.
I was wondering if it would make sense to coordinate the posting of my
patch series. I planned to post the series sometime in November along with
other stuff, but I could potentially post it earlier if this could help to
align.
In case of interest in aligning, I uploaded an unverified preview for the
upcoming series to [1].
Best regards,
Peter
[1] https://github.com/OpenSynergy/linux.git clocksource-id-for-get_device_system_crosststamp-v2-preview
Powered by blists - more mailing lists