>> >> + val = img_pwm_readl(pwm_chip, CR_PWM_CTRL_CFG); >> >> + val |= BIT(pwm->hwpwm); >> >> + img_pwm_writel(pwm_chip, CR_PWM_CTRL_CFG, val); >> >> + >> >> + regmap_update_bits(pwm_chip->periph_regs, CR_PERIP_PWM_PDM_CONTROL, >> >> + CR_PERIP_PWM_PDM_CONTROL_CH_MASK << >> >> + CR_PERIP_PWM_PDM_CONTROL_CH_SHIFT(pwm->hwpwm), 0); >> >> > This smells like pinmux and should probably be a separate driver. >> >> Hope you are suggesting us to have a separate driver for pin muxing (might already have one for Pistachio) >> and call the pin muxing driver APIs from here. >> >> Please correct me if my understanding is wrong? > > I don't think you need to call the pinmux API from here. Rather I'll > assume that the muxing is fixed on a given board, so this configuration > would be part of the static board-level pinmux so it will automatically > be applied at boot time. The issue here is that this register does not belong to the pinmux/pinctrl block on this SoC and instead is part of the "peripheral control" block which primarily provides system interface gate clocks and resets (for which I was planning to write a clock provider driver), but also has a bunch of control registers for various IP blocks thrown together (like this one) which we're using syscon to access. I'm not sure it makes sense to create a pinmux driver for these 4 bits, but I'll defer to others on that... Another option would be to have the main pinctrl driver for Pistachio control these bits, but that doesn't seem quite right since these bits are completely separate from the pinctrl block. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
