From: <conor.dooley@microchip.com>
To: <u.kleine-koenig@pengutronix.de>
Cc: <a.zummo@towertech.it>, <alexandre.belloni@bootlin.com>,
<aou@eecs.berkeley.edu>, <atishp@rivosinc.com>,
<bin.meng@windriver.com>, <brgl@bgdev.pl>,
<conor.dooley@microchip.com>, <daire.mcnamara@microchip.com>,
<devicetree@vger.kernel.org>, <geert@linux-m68k.org>,
<heiko@sntech.de>, <ivan.griffin@microchip.com>,
<jassisinghbrar@gmail.com>, <krzysztof.kozlowski@canonical.com>,
<lee.jones@linaro.org>, <lewis.hanly@microchip.com>,
<linus.walleij@linaro.org>, <linux-gpio@vger.kernel.org>,
<linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-pwm@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<linux-rtc@vger.kernel.org>, <palmer@dabbelt.com>,
<paul.walmsley@sifive.com>, <robh+dt@kernel.org>,
<robh@kernel.org>, <thierry.reding@gmail.com>
Subject: Re: [PATCH v5 06/12] dt-bindings: pwm: add microchip corepwm binding
Date: Wed, 2 Feb 2022 12:35:44 +0000 [thread overview]
Message-ID: <20220202123542.3721512-1-conor.dooley@microchip.com> (raw)
In-Reply-To: <20220201075824.aixrvkvmjde2ihxx@pengutronix.de>
>On 01/02/2022 07:58, Uwe Kleine-König wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> On Mon, Jan 31, 2022 at 11:47:21AM +0000, conor.dooley@microchip.com wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> Add device tree bindings for the Microchip fpga fabric based "core" PWM
>> controller.
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>> ---
>> .../bindings/pwm/microchip,corepwm.yaml | 75 +++++++++++++++++++
<snip>
>> + microchip,sync-update:
>> + description: |
>> + In synchronous mode, all channels are updated at the beginning of the PWM period.
>> + Asynchronous mode is relevant to applications such as LED control, where
>> + synchronous updates are not required. Asynchronous mode lowers the area size,
>> + reducing shadow register requirements. This can be set at run time, provided
>> + SHADOW_REG_EN is asserted. SHADOW_REG_EN is set by the FPGA bitstream programmed
>> + to the device.
>> + Each bit corresponds to a PWM channel & represents whether synchronous mode is
>> + possible for the PWM channel.
>> +
>> + $ref: /schemas/types.yaml#/definitions/uint16
>> + default: 0
>
>I'm not sure I understand this correctly. This is a soft-core and you
>can synthesize it either with or without the ability to do synchronous
>updates or not, right? All 16 channels share the same period length and
>in the simple implementation changing the duty cycle is done at once
>(maybe introducing a glitch) and in the more expensive implementation
>there is a register to implement both variants?
Correct. If the IP is instantiated with SHADOW_REG_ENx=1, both
registers that control the duty cycle for channel x have a second
"shadow reg" synthesised. At runtime a bit wide register exposed to
APB can be used to toggle on/off synchronised mode for all channels
it has been synthesised for.
I will reword this description since it is not clear.
>> + microchip,dac-mode:
>> + description: |
>> + Optional, per-channel Low Ripple DAC mode is possible on this IP core. It creates
>> + a minimum period pulse train whose High/Low average is that of the chosen duty
>> + cycle. This "DAC" will have far better bandwidth and ripple performance than the
>> + standard PWM algorithm can achieve.
>> + Each bit corresponds to a PWM channel & represents whether dac mode is enabled
>> + that PWM channel.
>
>In the last sentence a "for" is missing?
It is missing, thanks.
>These two properties are not detectable in software?
Unfortunately not. THe configuration for these options are only
accessible in the fpga design. You make a good point however & they
really should be visible to software. I'll suggest that for future
revisions of this IP that both configurations are accessible over APB
Thanks,
Conor.
next prev parent reply other threads:[~2022-02-02 12:33 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 11:47 [PATCH v5 00/12] Update the Icicle Kit device tree conor.dooley
2022-01-31 11:47 ` [PATCH v5 01/12] dt-bindings: soc/microchip: update syscontroller compatibles conor.dooley
2022-02-04 22:39 ` Rob Herring
2022-01-31 11:47 ` [PATCH v5 02/12] dt-bindings: soc/microchip: add services as children of sys ctrlr conor.dooley
2022-02-04 22:42 ` Rob Herring
2022-01-31 11:47 ` [PATCH v5 03/12] dt-bindings: i2c: add bindings for microchip mpfs i2c conor.dooley
2022-01-31 13:37 ` Rob Herring
2022-01-31 15:39 ` Rob Herring
2022-01-31 15:55 ` Conor.Dooley
2022-02-04 22:45 ` Rob Herring
2022-02-05 11:53 ` Conor Dooley
2022-01-31 11:47 ` [PATCH v5 04/12] dt-bindings: rtc: add bindings for microchip mpfs rtc conor.dooley
2022-01-31 13:37 ` Rob Herring
2022-02-04 22:46 ` Rob Herring
2022-01-31 11:47 ` [PATCH v5 05/12] dt-bindings: gpio: add bindings for microchip mpfs gpio conor.dooley
2022-01-31 13:37 ` Rob Herring
2022-01-31 11:47 ` [PATCH v5 06/12] dt-bindings: pwm: add microchip corepwm binding conor.dooley
2022-01-31 13:37 ` Rob Herring
2022-02-01 7:58 ` Uwe Kleine-König
2022-02-02 12:35 ` conor.dooley [this message]
2022-02-02 13:28 ` Geert Uytterhoeven
2022-02-02 13:46 ` Conor.Dooley
2022-02-02 14:02 ` Geert Uytterhoeven
2022-02-02 14:37 ` Conor.Dooley
2022-02-05 12:48 ` Conor Dooley
2022-01-31 11:47 ` [PATCH v5 07/12] riscv: dts: microchip: use clk defines for icicle kit conor.dooley
2022-01-31 11:47 ` [PATCH v5 08/12] riscv: dts: microchip: add fpga fabric section to " conor.dooley
2022-01-31 11:47 ` [PATCH v5 09/12] riscv: dts: microchip: refactor icicle kit device tree conor.dooley
2022-01-31 11:47 ` [PATCH v5 10/12] riscv: dts: microchip: update peripherals in " conor.dooley
2022-01-31 11:47 ` [PATCH v5 11/12] riscv: dts: microchip: add new peripherals to " conor.dooley
2022-01-31 11:47 ` [PATCH v5 12/12] MAINTAINERS: update riscv/microchip entry conor.dooley
2022-02-04 18:09 ` [PATCH v5 00/12] Update the Icicle Kit device tree Palmer Dabbelt
2022-02-04 18:47 ` Conor Dooley
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=20220202123542.3721512-1-conor.dooley@microchip.com \
--to=conor.dooley@microchip.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@rivosinc.com \
--cc=bin.meng@windriver.com \
--cc=brgl@bgdev.pl \
--cc=daire.mcnamara@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=heiko@sntech.de \
--cc=ivan.griffin@microchip.com \
--cc=jassisinghbrar@gmail.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=lee.jones@linaro.org \
--cc=lewis.hanly@microchip.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.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).