Re: [PATCH 0/2] Enable GPIO and I2C configs for TI's J721e platform

[Tero Kristo]

On 08/10/2020 12:40, Faiz Abbas wrote:
> Tero,
>
> On 08/10/20 2:49 pm, Tero Kristo wrote:
> > On 08/10/2020 11:59, Faiz Abbas wrote:
> > > Tero,
> > >
> > > On 06/10/20 6:40 pm, Tero Kristo wrote:
> > > > On 06/10/2020 16:03, Faiz Abbas wrote:
> > > > > Hi Tero,
> > > > >
> > > > > On 06/10/20 5:21 pm, Tero Kristo wrote:
> > > > > > On 02/10/2020 19:45, Faiz Abbas wrote:
> > > > > > > The following patches enable configs in the arm64 defconfig to support
> > > > > > > GPIO and I2C support on TI's J721e platform.
> > > > > > >
> > > > > > > Faiz Abbas (2):
> > > > > > >       arm64: defconfig: Enable OMAP I2C driver
> > > > > > >       arm64: defconfig: Enable DAVINCI_GPIO driver
> > > > > > >
> > > > > > >      arch/arm64/configs/defconfig | 2 ++
> > > > > > >      1 file changed, 2 insertions(+)
> > > > > >
> > > > > > Why are you enabling these?
> > > > > >
> > > > > > Are they required for booting the board?
> > > > > >
> > > > > > If not, they shall not be enabled, as it just clutters the arm64 defconfig unnecessarily.
> > > > >
> > > > > They are required because the SD card regulators need gpio over i2c expander and also
> > > > > soc gpio support to come up in UHS modes.
> > > >
> > > > Is that needed for boot support? If it is only needed with UHS cards, that does not seem important enough for me. We can already boot the board via other means.
> > >
> > > Without these configs, the regulator drivers keep EPROBE_DEFERing waiting for their gpio drivers
> > > to probe and SD card never comes up. This configuration happens before any UHS capabilities are detected.
> > >
> > > [    1.326654] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
> > > [    1.333651] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
> > > [    1.340693] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
> > > [    1.489088] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
> > > [    1.496067] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
> > > [    1.510392] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
> > > [    1.543210] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
> > > [    1.550186] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
> > > [    1.568134] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
> >
> > This happens because you have merged/enabled UHS support or? This sounds like a regression as I haven't seen this happen before.
>
> Thats right. The EPROBE_DEFERs will happen if my patches enabling UHS modes here are merged. I need to repost them for v5.11-rc1:
> https://lore.kernel.org/linux-arm-kernel/20201001190541.6364-1-faiz_abbas@xxxxxx/

Ok I think that would be good enough reason to enable these by default 
as the MMC as boot media won't work anymore without them, and carrying 
the DTS patches would be just silly.

Acked-by: Tero Kristo <t-kristo@xxxxxx>

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki