On Wed, Jan 18, 2017 at 12:14:08AM +0100, Paul Cercueil wrote: [...] > One problem still unresolved: the pinctrl framework does not allow us to > configure each pin on demand (someone please prove me wrong), when the > various PWM channels are requested or released. For instance, the PWM > channels can be configured from sysfs, which would require all PWM pins > to be configured properly beforehand for the PWM function, eventually > causing conflicts with other platform or board drivers. Still catching up on a lot of email, so I haven't gone through the entire series. But I don't think the above is true. My understanding is that you can have separate pin groups for each pin (provided the hardware supports that) and then control each of these groups dynamically at runtime. That is you could have the PWM driver's ->request() and ->free() call into the pinctrl framework to select the correct pinmux configuration as necessary. > The proper solution here would be to modify the pwm-jz4740 driver to > handle only one PWM channel, and create an instance of this driver > for each one of the 8 PWM channels. Then, it could use the pinctrl > framework to dynamically configure the PWM pin it controls. That could probably work. From only looking at the JZ4740 PWM driver there's no separate IP block to deal with the PWM outputs, but they are merely GPIOs controller via a timer, so one instance per GPIO seems like a fine solution to me. > Until this can be done, the only jz4740 board supported upstream > (Qi lb60) could configure all of its connected PWM pins in PWM function > mode, if those are not used by other drivers nor by GPIOs on the > board. The only jz4780 board upstream (CI20) does not yet support the > PWM driver. Typically all of the pinmux is pre-determined by the board design. That is if you've got 8 pins that can be driven by a PWM signal, not all of those might be exposed by the design. If, say, only 0-4 and 6 expose the PWM signal while 5 and 7 expose a different function then you can simply use a static pinmux configuration and ignore PWMs 5 and 7. Even if someone were to configure them, the signal would simply go nowhere. Of course you'd have to check that your hardware actually matches those assumptions. They certainly apply to many SoCs that I've come across. Thierry
Attachment:
signature.asc
Description: PGP signature
