Re: [PATCH v12 1/2] pwm: add microchip soft ip corePWM driver

From: Conor Dooley <conor@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Daire McNamara <daire.mcnamara@microchip.com>,
	linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v12 1/2] pwm: add microchip soft ip corePWM driver
Date: Mon, 5 Dec 2022 17:13:42 +0000	[thread overview]
Message-ID: <Y44mxp9Wr/aEdaxE@spud> (raw)
In-Reply-To: <20221205160328.wn4rcs6uxuuaxftd@pengutronix.de>

[-- Attachment #1.1: Type: text/plain, Size: 2486 bytes --]

On Mon, Dec 05, 2022 at 05:03:28PM +0100, Uwe Kleine-König wrote:
> Hello Conor,
> 
> On Mon, Dec 05, 2022 at 03:21:55PM +0000, Conor Dooley wrote:
> > I came into work today thinking that I could just rebase on top of your
> > patchset and send out a v13, but that was unfortunately not the case :/
> > 
> > So uh, it turns out that I was wrong about the behaviour of the
> > sync_update register's bit.
> > It turns out that that bit holds it's value until the IP block is reset,
> > and /does not/ get cleared at the start of the next period.
> > I'm really not sure how it worked when I tested the other week [0], so I
> > spent the first half of the day trying to figure out what on earth had
> > happened to my FPGA image. I must've picked the wrong image when I went
> > to test it the other week that had the wrong configuration somehow.
> > 
> > As a result, I've gone and hacked up another way of transferring the
> > burden of waiting - setting a timer for the period, backed by a
> > completion. get_state() and apply() now both check for the completion
> > and time out otherwise. I'm half tempted to tack RFC back onto the
> > series as I have not really messed with timers at all before and may
> > have done something off the wall.
> > 
> > I pushed it out (see [1] in case you'd like to look) so that the bots
> > can have a play with it, since it'll be a few weeks before I'll have a
> > chance to properly test that I've broken nothing with this.
> 
> I didn't look, but I'm convinced you don't need a timer. Something like
> the following should work, shouldn't it?:

Yeah & I did think of something along these lines. I was torn between
something that seemed heavy handed (timers) and calculating if enough
time had elapsed, which seemed a bit hacky.

Figured I was better off doing something quickly & asking rather than
polishing only to find out it was disliked ;)

> 
>  - in .apply() check the current time, add the current period and store
>    the result to ddata->updatetimestamp
>  - in .get_state do:
>      if (current_time >= ddata->updatetimestamp)
>        process fine
>      else:
>        timeout (or wait until ddata->updatetimestamp?)
> 
> Actually I'd prefer to wait instead of -ETIMEOUT.

Prefer to wait in get_state() or in both it & apply()?
Depending on how far away updatetimestamp is, would we still not want to
time out if it is going to be a long time, no?

Thanks again Uwe,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv