[PATCH v3] arm64: defconfig: Enable GPIO_SYSCON

[Diederik de Haas]

On Wednesday, 19 July 2023 12:24:27 CET Jagan Teki wrote:
> roc-rk3328-cc board has vcc_sdio regulator controlled by a special
> output only gpio pin. This special pin can now be reference as
> <&grf_gpio 0> via gpio-syscon driver, as mentioned in below commit.
> 
> commit <99165b93dafe> ("arm64: dts: rockchip: add sdmmc UHS support for
> roc-rk3328-cc")
> 
> So, enable bydefault on the defconfig.
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 6cbf6eb59378..70cffd87aa36 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -619,6 +619,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
>  CONFIG_GPIO_BD9571MWV=m
>  CONFIG_GPIO_MAX77620=y
>  CONFIG_GPIO_SL28CPLD=m
> +CONFIG_GPIO_SYSCON=y
>  CONFIG_POWER_RESET_MSM=y
>  CONFIG_POWER_RESET_QCOM_PON=m
>  CONFIG_POWER_RESET_XGENE=y

On my Rock64 (rk3328-rock64) I was getting the following error message:
gpio-syscon ff100000.syscon:gpio: can't read the data register offset!

Doing a `git bisect` led me to this commit. I can show the `git bisect`
log, but I don't think it adds any value. This commit didn't cause the
error ofc, but merely exposed an existing issue.

I did see that rk3328-roc-cc.dts has an `vcc_sdio: sdmmcio-regulator`
node which rk3328-rock64.dts doesn't have, but I have no idea if that
should be added to Rock64's dts file.
(Or how this issue can/should be fixed in general)

For a long time I thought that the following error (in `dmesg`) is
connected to it, as they (initially) show up together, but I'm not sure
anymore. The compatible string which made me propose to add GPIO_SYSCON
to Debian's kernel, is close to the `power-domain at RK3328_PD_HEVC` node
in rk3328.dtsi. But after building a kernel without GPIO_SYSCON enabled,
I still got (at least 1 time) the following error message:

rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220

This error doesn't always show up, so maybe there's a timing issue
involved?

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231125/51154e50/attachment.sig>