On Tue, Jan 13, 2015 at 3:42 AM, Andrew Lunn <[email protected]> wrote:
> So i thought about this some more. What would an MFD based solution
> look like?
>
> First issue is backwards compatibility. There are currently around 90
> .dts files using this gpio driver. I could imagine a few of these
> being changed to make use of an MFD based driver to make us of the new
> features, but the rest expect backwards compatibility.
Good point.
> I think the only sensible way to achieve this is that the gpio driver
> keeps its existing binding.
Yup.
> This does not really describe the hardware. The hardware is more like:
>
> gpio: gpio {
> compatible = "marvell,orion-gpio";
> reg = <0xd0018100 0x40>;
> ngpios = <32>;
> gio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> interrupts = <16>, <17>, <18>, <19>;
> clocks = <&coreclk 0>;
>
> pwm: pwm {
> compatible = "marvell,armada-pwm";
> reg = <0xd00181c0 0x08>;
> #pwm-cells = <2>;
> clocks = <&coreclk 0>;
> };
> };
>
> but i don't think MFD supports that sort of structure?
No it would have to be some custom DT code in the GPIO driver
spawning the PWM platform device.
I think it's better if we either go with the first solution of a combined
GPIO+PWM node (it's also elegant in a way, and perfectly
OK with device tree I think) but I want the PWM maintainer to
say if it's OK to have a PWM driver inside a GPIO driver.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-pwm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
