From: Conor Dooley <conor.dooley@microchip.com>
To: "Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Daire McNamara <daire.mcnamara@microchip.com>,
<linux-kernel@vger.kernel.org>, <linux-pwm@vger.kernel.org>,
<linux-riscv@lists.infradead.org>,
Conor Dooley <conor.dooley@microchip.com>
Subject: [PATCH v18 0/2] Microchip Soft IP corePWM driver
Date: Thu, 18 May 2023 13:29:19 +0100 [thread overview]
Message-ID: <20230518-reactive-nursing-23b7fe093048@wendy> (raw)
Hello,
Another version, although a lot smaller of a range-diff than previously!
All you get this time is the one change requested by Uwe on v17, along
with a rebase on -rc1.
Thanks,
Conor.
Changes since v17:
- Explicitly cast around integer promotion on 32-bit archs
- rebase on v6.4-rc1
Changes since v16:
- only write out the period immediately before the duty cycle to avoid
potentially racing against the period counter resetting
- update some comments that had bitrotted
- use Uwe's simple method for calculating period/duty & reject any
period for which tmp < 255
Changes since v15:
- calculate prescale modulus without using %
Changes since v14:
- change period_steps calculation logic to correctly handle the cases
where tmp % (254 + 1) == 0, by swapping implicit truncation for
explicit rounding upwards and subtracting zero
- special case periods < 1/clk_rate & add a note in limitations about
this, although I think this issue wasn't present prior to v15's
changes
- check for smaller suitable values of prescale, which picks the "more
correct" value in about half of all cases, particularly those where
tmp is large.
- explain what I mean by the "optimal" values for prescale/period steps
re-fix use of defines
- add a comment about how sync_upd mode works
- make the use of period_steps and prescale consistently refer to the
register values rather than, in comments, using these to mean the
resulting values after 1 has been added
- drop the PREG_TO_VAL() macro, as most of its users are now gone & it
only added to the register value versus "real" value problem
- report pwmchip_add() failures
Changes since v13:
- couple bits of cleanup to apply_locked(), suggested by Uwe
- move the overhead waiting for a change to be applied, for channels
with shadow registers, to subsequent calls to apply(). This has the
benefit of only waiting when two calls to apply() are close in time
rather than eating the delay in every call.
Changes since v11:
- swap a "bare" multiply & divide for the corresponding helper to
prevent overflow
- factor out duplicate clk rate acquisition & period calculation
- make the period calculation return void by checking the validity of
the clock rate in the caller
- drop the binding & dt patch, they're on-track for v6.2 via my tree
Changes since v10:
- reword some comments
- try to assign the period if a disable is requested
- drop a cast around a u8 -> u16 conversion
- fix a check on period_steps that should be on the hw_ variant
- split up the period calculation in get_state() to fix the result on
32 bit
- add a rate variable in get_state() to only call get_rate() once
- redo the locking as suggested to make it more straightforward.
- stop checking for enablement in get_state() that was working around
intended behaviour of the sysfs interface
Changes since v9:
- fixed the missing unlock that Dan reported
Changes since v8:
- fixed a(nother) raw 64 bit division (& built it for riscv32!)
- added a check to make sure we don't try to sleep for 0 us
Changes since v7:
- rebased on 6.0-rc1
- reworded comments you highlighted in v7
- fixed the overkill sleeping
- removed the unused variables in calc_duty
- added some extra comments to explain behaviours you questioned in v7
- make the mutexes un-interruptible
- fixed added the 1s you suggested for the if(period_locked) logic
- added setup of the channel_enabled shadowing
- fixed the period reporting for the negedge == posedge case in
get_state() I had to add the enabled check, as otherwise it broke
setting the period for the first time out of reset.
- added a test for invalid PERIOD_STEPS values, in which case we abort
if we cannot fix the period
Changes from v6:
- Dropped an unused variable that I'd missed
- Actually check the return values of the mutex lock()s
- Re-rebased on -next for the MAINTAINERS patch (again...)
Changes from v5:
- switched to a mutex b/c we must sleep with the lock taken
- simplified the locking in apply() and added locking to get_state()
- reworked apply() as requested
- removed the loop in the period calculation (thanks Uwe!)
- add a copy of the enable registers in the driver to save on reads.
- remove the second (useless) write to sync_update
- added some missing rounding in get_state()
- couple other minor cleanups as requested in:
https://lore.kernel.org/linux-riscv/20220709160206.cw5luo7kxdshoiua@pengutronix.de/
Changes from v4:
- dropped some accidentally added files
Changes before v4:
https://lore.kernel.org/linux-pwm/20220721172109.941900-1-mail@conchuod.ie
Conor Dooley (2):
pwm: add microchip soft ip corePWM driver
MAINTAINERS: add pwm to PolarFire SoC entry
MAINTAINERS | 1 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-microchip-core.c | 507 +++++++++++++++++++++++++++++++
4 files changed, 519 insertions(+)
create mode 100644 drivers/pwm/pwm-microchip-core.c
--
2.39.2
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2023-05-18 12:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 12:29 Conor Dooley [this message]
2023-05-18 12:29 ` [PATCH v18 1/2] pwm: add microchip soft ip corePWM driver Conor Dooley
2023-05-18 15:14 ` Uwe Kleine-König
2023-05-18 21:15 ` Conor Dooley
2023-05-18 12:29 ` [PATCH v18 2/2] MAINTAINERS: add pwm to PolarFire SoC entry Conor Dooley
2023-05-18 15:15 ` Uwe Kleine-König
2023-06-23 14:51 ` [PATCH v18 0/2] Microchip Soft IP corePWM driver Thierry Reding
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=20230518-reactive-nursing-23b7fe093048@wendy \
--to=conor.dooley@microchip.com \
--cc=daire.mcnamara@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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).