Re: [PATCH v2] clk: Add PWM clock driver

["Janusz Użycki" <j.uzycki@elproma.com.pl>]

Hi,

W dniu 2014-11-03 o 10:31, Philipp Zabel pisze:
> Some board designers, when running out of clock output pads, decide to
> (mis)use PWM output pads to provide a clock to external components.
> This driver supports this practice by providing an adapter between the
> PWM and clock bindings in the device tree. As the PWM bindings specify
> the period in the device tree, this is a fixed clock.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> I'm resending this because last time the linux-pwm list was not in Cc:
> So far I have not received any comments on the patch itself. I have used
> it on a BoundaryDevices Nitrogen6X board to produce a master clock for
> the OV5640 MIPI CSI-2 camera module.
>
> Changes since v1:
>   - none (rebased onto v3.18-rc3)
> ---
>   .../devicetree/bindings/clock/pwm-clock.txt        |  23 +++++
>   drivers/clk/Kconfig                                |   7 ++
>   drivers/clk/Makefile                               |   1 +
>   drivers/clk/clk-pwm.c                              | 110 +++++++++++++++++++++
>   4 files changed, 141 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/clock/pwm-clock.txt
>   create mode 100644 drivers/clk/clk-pwm.c
>
> diff --git a/Documentation/devicetree/bindings/clock/pwm-clock.txt b/Documentation/devicetree/bindings/clock/pwm-clock.txt
> new file mode 100644
> index 0000000..d127d17
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/pwm-clock.txt
> @@ -0,0 +1,23 @@
> +Binding for an external clock signal driven by a PWM pin.
> +
> +This binding uses the common clock binding[1] and the common PWM binding[2].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/pwm/pwm.txt
> +
> +Required properties:
> +- compatible : shall be "pwm-clock".
> +- #clock-cells : from common clock binding; shall be set to 0.
> +- pwms : from common PWM binding; this determines the clock frequency
> +  via the PWM period given in the pwm-specifier.
> +
> +Optional properties:
> +- clock-output-names : From common clock binding.
> +
> +Example:
> +	clock {
> +		compatible = "pwm-clock";
> +		#clock-cells = <0>;
> +		clock-output-names = "mipi_mclk";
> +		pwms = <&pwm2 0 40>; /* 1 / 40 ns = 25 MHz */

Before I asked about [MHz/kHz] <-> [ns] conversion problem but I didn't 
noticed
you've just used [ns] in dt. As Thierry wrote:
"Also the PWM chips will most likely use the concept of period and 
duty-cycle
internally anyway, so it will convert back from Hz/percentage to nanoseconds
and fall victim to similar rounding effects."

Unfortunately I discovered that many pwm drivers are buggy around upper 
freqs limit.
The example is pwm-mxs.c. PWM has 24MHz clock. There is no problem to set
registers directly for 12MHz 50% output (period_cycles=2-1=1, 
inactive_c=1, active_c=0).

When I set pwm-mxs period to 83ns / duty to 42ns the output is low because
it sets inactive_c=0!
For 125ns/63ns I got about 6MHz instead of 8MHz, and +width=42ns.
When I set 42ns/42ns I got 12MHz 50%.
It means new patches for pwms...

I will test the patch backported to 3.14 using the mxs platform.
However as I wrote I  need to patch pwm-mxs first.

> [...]
>
> +static struct platform_driver clk_pwm_driver = {
> +	.probe = clk_pwm_probe,
> +	.driver = {
> +		.name = "pwm-clock",
> +		.owner = THIS_MODULE,

AFAIR new drivers don't need to set .owner.

thanks
Janusz

> +		.of_match_table = of_match_ptr(clk_pwm_dt_ids),
> +	},
> +};
> +
> +module_platform_driver(clk_pwm_driver);