On Thu, Mar 22, 2018 at 02:53:16PM +0100, Alvaro Gamez Machado wrote: > This patch adds support for the IP core provided by Xilinx. > This IP core can function as a two independent timers, but also use both > counters as values for period and duty cycle of a PWM output. > > There can be many instances of this IP in a design, but the first one of > them will be used to generate system's clock. If we were to use this driver > against the first timer instance found on the DT, we would expose it as a > PWM controller, and reconfiguring it will break the clock. > > To avoid this we add an attribute pwm-outputs to this device declaration. > This new driver will fail to probe when pwm-outputs is different than 1. > > We could use a boolean, but future versions of this IP core could implement > several PWM and counters, so when (if) this happens, we would only have to > adjust the pwm-outputs comparison to allow more than one PWM devices. > > Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@xxxxxxxxxx> > --- > > This is the second proposal on getting AXI Timer PWM capability into Linux. > The other alternative, which was sent un June past year, didn't look for > pwm-output attribute, so in order not to kidnap control from > arch/microblaze/kernel/timer.c it used a different compatible string. That's > not wrong per se, but raises the question: can one piece of hardware have > two compatible strings depending on its intended use, rather than on the > nature of the hardware itself? > > If there's interest in mainlining this or the proposal I sent last year, I'd > be grateful to hear from the devicetree maintainers and maybe approve or > suggest any different aproach. > > Best regards > > drivers/pwm/Kconfig | 9 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-axi-timer.c | 204 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 214 insertions(+) > create mode 100644 drivers/pwm/pwm-axi-timer.c Did any discussion regarding the above-mentioned issues ever ensue? How do you want to proceed? At the very least we'll need some sort of device tree binding for this driver, so perhaps start with a DT binding proposal and take it from there? Thierry
Attachment:
signature.asc
Description: PGP signature
