Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Wolfram Sang <wsa+renesas@sang-engineering.com>,
        linux-renesas-soc@vger.kernel.org
Cc:     Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
        Wolfram Sang <wsa+renesas@sang-engineering.com>,
        Daniel Lezcano <daniel.lezcano@linaro.org>,
        Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clocksource/drivers/sh_cmt: access registers according
 to spec
In-Reply-To: <20221130210609.7718-1-wsa+renesas@sang-engineering.com>
References: <20221130210609.7718-1-wsa+renesas@sang-engineering.com>
Date:   Thu, 01 Dec 2022 11:55:40 +0100
Message-ID: <87pmd3s89f.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Wolfram!

On Wed, Nov 30 2022 at 22:06, Wolfram Sang wrote:
> Documentation for most CMTs say that we need to wait two input clocks
> before changes propagate to the timer. This is especially relevant when
> we stop the timer to change further settings. Implement the delays
> according to the spec. To avoid unnecessary delays in atomic mode, we
> also check if the to-be-written value actually differs. CMCNT is a bit
> special because testing showed that we need to wait 3 cycles instead.
> AFAIU, this is also true for all CMTs. Also, the WRFLAG needs to be
> checked before writing. This fixes "cannot clear CMCNT" messages which
> occur often on R-Car Gen4 SoCs, but only very rarely on older SoCs for
> some reason.

https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog

I fixed it up for you this time...

> Fixes: 81b3b2711072 ("clocksource: sh_cmt: Add support for multiple channels per device")
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Changes since RFC v2:
> * use DIV_ROUND_UP also for caluclating cmcnt_delay
> * remove a FIXME comment
>
> There were no further comments, so I dropped the RFC status and send
> this as a regular patch. Here again the introduction from RFC v1:

Instead of quoting, it would have been helpful to have the lore links
for RFC v1/v2....

Thanks,

        tglx