
From: Levin Du djw@t-chip.com.cn Date: Fri, 14 Jun 2019 17:09:43 +0800
Hi all,
I try U-Boot v2019.04 on the Firefly-RK3399 board and the kernel failed during loading. After doing some `git bisect`, I find the commit e7ae4cf27a6d5837cb5e868712cdaa61d3ceb5e0 (which is adding common rockchip pinctrl driver) is where the problem starts to emerge.
After some trial and error, it seems that the new pinctrl driver has got rid of the request op. But in board/rockchip/evb_rk3399/evb-rk3399.c:
/* Enable pwm0 for panel backlight */ ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0); if (ret) { debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret); goto out; } >
The pinctrl_request_noflags call will fail and end, skiping the regulator operations in normal flow.
Adding a dummy request function (return 0) to rockchip_pinctrl_ops solves the kernel hang:
+static int rockchip_pinctrl_request(struct udevice *dev, int func, int flags) +{
struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
debug("%s: func=%x, flags=%x\n", __func__, func, flags);
return 0;
+}
const struct pinctrl_ops rockchip_pinctrl_ops = {
.request = rockchip_pinctrl_request, .set_state = rockchip_pinctrl_set_state, .get_gpio_mux = rockchip_pinctrl_get_gpio_mux,
};
But I wonder why no other RK3399 boards experience the same problem. If I'd like to write a patch to address this, a dummy request function is not proper IMO. I'm seeking your advice. Thanks in advance.
Thanks for tracking this down! I had noticed that something broke but I didn't find the time to track this down yet.
I suspect that since CONFIG_PINCTRL_FULL is enabled all the pinctrl_request() and pinctrl_request_noflags() calls are no longer necessary and should probably be removed. Hopefully somebody who is more knowledgeable in this area can confirm?