On Wed, Apr 12, 2023 at 09:36:43PM +0100, Daniel Golle wrote: > Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and > related functions") changed the logic deciding to set R0 and R1 > registers for V1 devices. > > Before: > /* Also set PUPD/R0/R1 if the pin has them */ > err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup); > if (err != -EINVAL) { > mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0); > mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1); > } > > After: > /* try pupd_r1_r0 if pullen_pullsel return error */ > err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup, > val); > if (err) > return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable, > pullup, val); > > Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function > always either returns 0 in case of success or -EINVAL in case any error > has occurred. Hence the logic responsible of the decision to program R0 > and R1 has been inverted. > > This leads to problems on BananaPi R2 (MT7623N) when booting from > SDMMC, it turns out accessing eMMC no longer works since > U-Boot 2022.07: > > MT7623> mmc dev 0 > Card did not respond to voltage select! : -110 > > The problem wasn't detected for a long time as both eMMC and SDMMC work > fine if they are used to boot from, and hence R0 and R1 were already > setup by the bootrom and/or preloader. > > Fix the logic to restore the originally intended and correct behavior > and also change the descriptive comment accordingly. > > Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related > functions") > Signed-off-by: Daniel Golle <dan...@makrotopia.org> > Tested-By: Frank Wunderlich <fran...@public-files.de>
Applied to u-boot/master, thanks! -- Tom
signature.asc
Description: PGP signature