[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHh=Yk8jNbhYp3goxu3zvdatz_tivcK_JocvFXDRL2ZCKELAag@mail.gmail.com>
Date: Mon, 31 Mar 2025 22:15:04 +0800
From: Nylon Chen <nylon.chen@...ive.com>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
devicetree@...r.kernel.org, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Samuel Holland <samuel.holland@...ive.com>, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v10 0/3] Change PWM-controlled LED pin active mode and algorithm
Uwe Kleine-König <u.kleine-koenig@...libre.com> 於 2025年3月28日 週五 下午6:27寫道:
>
> On Fri, Mar 28, 2025 at 05:41:37PM +0800, Nylon Chen wrote:
> > * (T) period.
> > > > The `frac` variable is pulse "inactive" time so we need to invert it.
> > >
> > > I'm trying to understand that. You're saying that the PWMCMP register
> > > holds the inactive time. Looking at the logic diagram (Figure 29) of
> > > "SiFive FU740-C000 Manual v1p6" that is because pwms is feed into the
> > > comparator after going through that XNOR where the lower input is always
> > > 0 (as pwmcmpXcenter is always 0) and so effectively counts backwards,
> > > right?
> > > In that case the sentence "The output of each comparator is high
> > > whenever the value of pwms is greater than or equal to the corresponding
> > > pwmcmpX." from the description of the Compare Registers is wrong.
> > >
> > Hi Uwe, I've contacted the spec's author, and he is willing to correct
> > the spec-related error.
> >
> > Based on your suggestions, I think we have two approaches
> > 1. First add comments explaining where the spec and implementation
> > don't match, then after the spec is corrected, submit another patch to
> > remove the comments
> > 2. No need to add this error explanation part, because the spec will
> > be corrected later.
> >
> > I don't have a preference, so I wanted to check with you - do you lean
> > more toward option 1 or option 2
>
> I would go for 1, mentioning the version of the broken documenatation
> and the expectation that this will be fixed in later revisions. So there
> is no confusion when the documenatation is fixed but the comments not
> removed yet.
Hi Uwe, thanks for the feedback
I understand. I'll proceed with option one to handle the patch for the
next version.
>
> Best regards
> Uwe
Powered by blists - more mailing lists