On 7/2/21 8:40 AM, Michal Simek wrote:

On 7/1/21 5:32 PM, Sean Anderson wrote:

quoted

On 6/30/21 9:47 AM, Michal Simek wrote:

quoted

On 5/28/21 11:45 PM, Sean Anderson wrote:

quoted

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 <redacted>
---

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

quoted

quoted

diff --git

a/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml
b/Documentation/devicetree/bindings/pwm/xlnx,axi-timer.yaml

quoted

quoted

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.

quoted

And sort of curious if you look at

https://www.xilinx.com/support/documentation/ip_documentation/axi_timer/v2_0/pg079-axi-timer.pdf

quoted

( 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.

As I understand it, the samsung PWM/timer has 5 timers, four of which
may be independently configured as PWMs. To contrast, this device has at
most two timers, both of which must be used for a single PWM output.
Because of this, it is sufficient to have a single property whose
presence indicates that the device is to be configured as a PWM.

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.

This is not done by the current driver. The first timer in the system
always binds itself to CPU 0.

--Sean