On 5/7/21 2:35 AM, Michal Simek wrote: > > > On 5/6/21 11:10 PM, Sean Anderson wrote: >> >> >> On 5/6/21 5:05 PM, Rob Herring wrote: >>> On Tue, May 04, 2021 at 02:49:24PM -0400, Sean Anderson wrote: >>>> This adds a binding for the Xilinx LogiCORE IP AXI Timer. This device is >>>> a "soft" block, so it has many 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 properties >>>> must be kept as they are. >>>> >>>> Signed-off-by: Sean Anderson <sean.anderson@xxxxxxxx> >>>> --- >>>> >>>> Changes in v2: >>>> - Use 32-bit addresses for example binding >>>> >>>> .../bindings/pwm/xlnx,axi-timer.yaml | 91 +++++++++++++++++++ >>>> 1 file changed, 91 insertions(+) >>>> create mode 100644 >> Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml >>>> >>>> diff --git >> a/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml >> b/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml >>>> new file mode 100644 >>>> index 000000000000..bd014134c322 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml >>>> @@ -0,0 +1,91 @@ >>>> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/pwm/xlnx,axi-timer.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Xilinx LogiCORE IP AXI Timer Device Tree Binding >>>> + >>>> +maintainers: >>>> + - Sean Anderson <sean.anderson@xxxxxxxx> >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - const: xlnx,axi-timer-2.0 >>>> + - const: xlnx,xps-timer-1.00.a >>>> + >>>> + clocks: >>>> + maxItems: 1 >>>> + >>>> + clock-names: >>>> + const: s_axi_aclk >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + xlnx,count-width: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + minimum: 8 >>>> + maximum: 32 >>>> + description: >>>> + The width of the counters, in bits. >>>> + >>>> + xlnx,gen0-assert: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [ 0, 1 ] >>>> + description: >>>> + The polarity of the generateout0 signal. 0 for active-low, 1 >> for active-high. >>>> + >>>> + xlnx,gen1-assert: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [ 0, 1 ] >>>> + description: >>>> + The polarity of the generateout1 signal. 0 for active-low, 1 >> for active-high. >>>> + >>>> + xlnx,one-timer-only: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [ 0, 1 ] >>>> + description: >>>> + Whether only one timer is present in this block. >>>> + >>>> + xlnx,trig0-assert: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [ 0, 1 ] >>>> + description: >>>> + The polarity of the capturetrig0 signal. 0 for active-low, 1 >> for active-high. >>>> + >>>> + xlnx,trig1-assert: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + enum: [ 0, 1 ] >>>> + description: >>>> + The polarity of the capturetrig1 signal. 0 for active-low, 1 >> for active-high. >>> >>> Can't all these be boolean? >> >> They could, but >> >>> This binding is usually automatically generated by Xilinx's tools, so >>> the names and values of properties must be kept as they are. >> >> Because this is a soft device, the binding may be (very conveniently) >> auto-generated. I am not opposed to adding additional properties which >> could be used by new code, but we should still accept this auto-generated >> output. > > I think in this case you should described what it is used by current > driver in Microblaze and these options are required. The rest are by > design optional. > If you want to change them to different value then current binding > should be deprecated and have any transition time with code alignment. Well, every single one of these is in the microblaze devicetree since 2009. And fundamentally, all of these are required for a complete driver implementation. They are generally not discoverable from hardware (though I think it might be possible for one-timer-only or perhaps counter-width by inspecting whether register writes stick). However, the signal polarity properties are required to determine whether PWM mode is possible, and to determine the polarity of PWM capture (if that is implemented in the future). I think allowing more conventional usage of devicetree is a good idea. E.g. we could accept both something like 'xlnx,gen0-assert = <0>;' and 'xlnx,gen0-active-low;'. But I think we should still parse older devicetree properties, given the (likely extensive) amount of existing devicetrees with this binding. And this would also require Xilinx to adopt whatever we decide on, and update their devicetree generators accordingly. --Sean
