Message-ID: <0a88491b-7ccf-affe-32b7-ff7eea9726d5@seco.com>
Date:   Mon, 20 Sep 2021 12:23:20 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Linux PWM List <linux-pwm@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        Alvaro Gamez <alvaro.gamez@...ent.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Lee Jones <lee.jones@...aro.org>,
        Michal Simek <michal.simek@...inx.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/3] dt-bindings: pwm: Add Xilinx AXI Timer




On 9/20/21 8:35 AM, Rob Herring wrote:
> On Thu, Sep 16, 2021 at 12:58 PM Sean Anderson <sean.anderson@...o.com> wrote:
>>
>>
>>
>> On 8/31/21 4:11 PM, Rob Herring wrote:
>> > On Thu, Aug 26, 2021 at 05:18:28PM -0400, Sean Anderson wrote:
>> >> This adds a binding for the Xilinx LogiCORE IP AXI Timer. This device is a
>> >> "soft" block, so it has some parameters which would not be configurable in
>> >> most hardware. This binding is usually automatically generated by Xilinx's
>> >> tools, so the names and values of some properties should be kept as they
>> >> are, if possible. In addition, this binding is already in the kernel at
>> >> arch/microblaze/boot/dts/system.dts, and in user software such as QEMU.
>> >>
>> >> The existing driver uses the clock-frequency property, or alternatively the
>> >> /cpus/timebase-frequency property as its frequency input. Because these
>> >> properties are deprecated, they have not been included with this schema.
>> >> All new bindings should use the clocks/clock-names properties to specify
>> >> the parent clock.
>> >>
>> >> Because we need to init timer devices so early in boot, we determine if we
>> >> should use the PWM driver or the clocksource/clockevent driver by the
>> >> presence/absence, respectively, of #pwm-cells. Because both counters are
>> >> used by the PWM, there is no need for a separate property specifying which
>> >> counters are to be used for the PWM.
>> >>
>> >> Signed-off-by: Sean Anderson <sean.anderson@...o.com>
>> >> ---
>> >>
>> >> Changes in v6:
>> >> - Fix incorrect schema id
>> >> - Enumerate possible counter widths
>> >>
>> >> Changes in v5:
>> >> - Update commit message to reflect revisions
>> >> - Fix indentation lint
>> >> - Add example for timer binding
>> >> - Remove xlnx,axi-timer-2.0 compatible string
>> >> - Move schema into the timer directory
>> >>
>> >> Changes in v4:
>> >> - Remove references to generate polarity so this can get merged
>> >> - Predicate PWM driver on the presence of #pwm-cells
>> >> - Make some properties optional for clocksource drivers
>> >>
>> >> Changes in v3:
>> >> - Mark all boolean-as-int properties as deprecated
>> >> - Add xlnx,pwm and xlnx,gen?-active-low properties.
>> >> - Make newer replacement properties mutually-exclusive with what they
>> >>   replace
>> >> - Add an example with non-deprecated properties only.
>> >>
>> >> Changes in v2:
>> >> - Use 32-bit addresses for example binding
>> >>
>> >>  .../bindings/timer/xlnx,xps-timer.yaml        | 90 +++++++++++++++++++
>> >>  1 file changed, 90 insertions(+)
>> >>  create mode 100644 Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
>> >> new file mode 100644
>> >> index 000000000000..5be353a642aa
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
>> >> @@ -0,0 +1,90 @@
>> >> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
>> >> +%YAML 1.2
>> >> +---
>> >> +$id: http://devicetree.org/schemas/timer/xlnx,xps-timer.yaml#
>> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> >> +
>> >> +title: Xilinx LogiCORE IP AXI Timer Device Tree Binding
>> >> +
>> >> +maintainers:
>> >> +  - Sean Anderson <sean.anderson@...o.com>
>> >> +
>> >> +properties:
>> >> +  compatible:
>> >> +    contains:
>> >> +      const: xlnx,xps-timer-1.00.a
>> >> +
>> >> +  clocks:
>> >> +    maxItems: 1
>> >> +
>> >> +  clock-names:
>> >> +    const: s_axi_aclk
>> >> +
>> >> +  interrupts:
>> >> +    maxItems: 1
>> >> +
>> >> +  reg:
>> >> +    maxItems: 1
>> >> +
>> >> +  xlnx,count-width:
>> >> +    $ref: /schemas/types.yaml#/definitions/uint32
>> >> +    enum: [8, 16, 32]
>> >> +    default: 32
>> >> +    description:
>> >> +      The width of the counter(s), in bits.
>> >> +
>> >> +  xlnx,one-timer-only:
>> >> +    $ref: /schemas/types.yaml#/definitions/uint32
>> >> +    enum: [ 0, 1 ]
>> >> +    description:
>> >> +      Whether only one timer is present in this block.
>> >> +
>> >> +required:
>> >> +  - compatible
>> >> +  - reg
>> >> +  - xlnx,one-timer-only
>> >> +
>> >> +allOf:
>> >> +  - if:
>> >> +      required:
>> >> +        - '#pwm-cells'
>> >> +    then:
>> >> +      allOf:
>> >> +        - required:
>> >> +            - clocks
>> >> +        - properties:
>> >> +            xlnx,one-timer-only:
>> >> +              const: 0
>> >> +    else:
>> >> +      required:
>> >> +        - interrupts
>> >> +  - if:
>> >> +      required:
>> >> +        - clocks
>> >> +    then:
>> >> +      required:
>> >> +        - clock-names
>> >> +
>> >> +additionalProperties: true
>> >
>> > This needs to be false. What else do you expect to be present?
>>
>> I am going to leave this as true for the next revision to avoid the following error:
>>
>> arch/microblaze/boot/dts/system.dt.yaml: timer@...00000: 'xlnx,family', 'xlnx,gen0-assert', 'xlnx,gen1-assert', 'xlnx,trig0-assert', 'xlnx,trig1-assert' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> If I wasn't clear: NAK
>
> All properties must be documented or removed from .dts files if not needed.

I am more than fine to document xlnx,trig?-assert, as they are necessary
for implementing capture support in the future. The xlnx,gen?-assert
should really be documented as well, as it provides a good sanity check
for PWM support. However, Micheal has in the past voiced his opinion
that these properties should not be included (despite specifying
information which cannot be determined by probing the hardware...).

xlnx,family can probably be removed, as I don't believe this device has
any differences across FPGA families.

--Sean

Powered by blists - more mailing lists