On 7/1/21 5:32 PM, Sean Anderson wrote: > > > On 6/30/21 9:47 AM, Michal Simek wrote: >> >> >> On 5/28/21 11:45 PM, 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 some properties >>> must be kept as they are. Replacement properties have been provided for >>> new device trees. >>> >>> Because we need to init timer devices so early in boot, the easiest way >>> to configure things is to use a device tree property. For the moment >>> this is 'xlnx,pwm', but this could be extended/renamed/etc. in the >>> future if these is a need for a generic property. >>> >>> Signed-off-by: Sean Anderson <sean.anderson@xxxxxxxx> >>> --- >>> >>> 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/pwm/xlnx,axi-timer.yaml | 85 +++++++++++++++++++ >>> 1 file changed, 85 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..48a280f96e63 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml >> >> I don't think this is the right location for this. >> >> I have done some grepping and I think this should be done in a different >> way. I pretty much like solution around "ti,omap3430-timer" which is >> calling dmtimer_systimer_select_best() and later dmtimer_is_preferred() >> which in this case would allow us to get rid of cases which are not >> suitable for clocksource and clockevent. >> >> And there is drivers/pwm/pwm-omap-dmtimer.c which has link to timer >> which is providing functions for it's functionality. >> >> I have also looked at >> Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml which is also >> the same device. > > Ok, I will move this under bindings/timer. > >> >> And sort of curious if you look at >> > https://www.xilinx.com/support/documentation/ip_documentation/axi_timer/v2_0/pg079-axi-timer.pdf > >> ( Figure 1-1) >> that PWM is taking input from generate out 0 and generate out 1 which is >> maybe can be modeled is any output and pwm driver can register inputs >> for pwm driver. > > I don't think that is a good model, since several bits (GENERATE, PWM, > etc) need to be set in the TCSR, and we need to coordinate changes > between timers closely to keep our contract for apply_state(). Although > that is how the hardware is organized, the requirements of the > clocksource and pwm subsystems are very different. There is another upstream solution done by samsung. Where they use samsung,pwm-outputs property to identify PWMs. I think that make sense to consider to identify which timer should be clocksource/clockevent because with MB SMP this has to be done to pair timer with cpu for clockevents. You can see drivers here. drivers/clocksource/smasung_pwm_timer.c drivers/pwm/pwm-samsung.c Uwe: How does it sound to you? Thanks, Michal