linux-kernel - Re: [PATCH v5 06/12] dt-bindings: pwm: add microchip corepwm binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220201075824.aixrvkvmjde2ihxx@pengutronix.de>
Date:   Tue, 1 Feb 2022 08:58:24 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     conor.dooley@...rochip.com
Cc:     linus.walleij@...aro.org, brgl@...ev.pl, robh+dt@...nel.org,
        jassisinghbrar@...il.com, thierry.reding@...il.com,
        lee.jones@...aro.org, a.zummo@...ertech.it,
        alexandre.belloni@...tlin.com, paul.walmsley@...ive.com,
        palmer@...belt.com, aou@...s.berkeley.edu, geert@...ux-m68k.org,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-pwm@...r.kernel.org, linux-rtc@...r.kernel.org,
        linux-riscv@...ts.infradead.org, krzysztof.kozlowski@...onical.com,
        bin.meng@...driver.com, heiko@...ech.de, lewis.hanly@...rochip.com,
        daire.mcnamara@...rochip.com, ivan.griffin@...rochip.com,
        atishp@...osinc.com, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v5 06/12] dt-bindings: pwm: add microchip corepwm binding

On Mon, Jan 31, 2022 at 11:47:21AM +0000, conor.dooley@...rochip.com wrote:
> From: Conor Dooley <conor.dooley@...rochip.com>
> 
> Add device tree bindings for the Microchip fpga fabric based "core" PWM
> controller.
> 
> Reviewed-by: Rob Herring <robh@...nel.org>
> 
> Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
> ---
>  .../bindings/pwm/microchip,corepwm.yaml       | 75 +++++++++++++++++++
>  1 file changed, 75 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
> new file mode 100644
> index 000000000000..26a77cde2465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/microchip,corepwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip ip core PWM controller bindings
> +
> +maintainers:
> +  - Conor Dooley <conor.dooley@...rochip.com>
> +
> +description: |
> +  corePWM is an 16 channel pulse width modulator FPGA IP
> +
> +  https://www.microsemi.com/existing-parts/parts/152118
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: microchip,corepwm-rtl-v4
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  "#pwm-cells":
> +    const: 2
> +
> +  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?


> +  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?

These two properties are not detectable in software?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)