Messages in this thread | | | From | Sean Anderson <> | Subject | Re: [PATCH v4 1/3] dt-bindings: pwm: Add Xilinx AXI Timer | Date | Fri, 2 Jul 2021 13:31:54 -0400 |
| |
On 7/2/21 8:40 AM, Michal Simek wrote: > > > 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@seco.com> >>>> --- >>>> >>>> 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.
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
| |