[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[Paul Boddie]

On Sunday, 20 December 2020 19:11:39 CET H. Nikolaus Schaller wrote:
> 
> Am 20.12.2020 um 18:01 schrieb Paul Boddie <paul at boddie.org.uk>:
> > 
> > Maybe we need to find a way of configuring PA21 as an output, although I
> > would have thought that the regulator would do this itself.
> 
> Well, the regulator uses gpiolib to control a gpio. Nothing else. Basically
> it is a transformator between regulator requests and gpio_set_value().
> 
> So the regulator driver doesn't care about pinmuxing.
> 
> Now the gpiolib IMHO doesn't either.
> 
> So nobody is setting the gpio to output - unless it is different from how
> it works on the OMAP. There we have to explicitly add some pinmux for
> every SoC pad which also tells if they are input or output. I haven't
> looked into the CI20 device tree if this is the same for JZ.

I guess that device trees like this one show how this is done for OMAP:

arch/arm/boot/dts/omap5-uevm+pyra4.dts

> It may of course be different, e.g. that the first call to gpio_set_value()
> should make it an output.

It seems to me that the pinctrl driver never sets the pin direction, meaning 
that for plain GPIO pins, the default direction of input is always used. Of 
course, for configuration using the pin groups, the pin being used here would 
not be configured at all since it only ever appears in a group for the UART3 
peripheral.

What we would want to happen is that something claims the pin as a GPIO and 
sets the direction to output. This would need to be done using the 
gpio_set_direction operation via pinctrl/pinmux.

> 
> > Do we not need to
> > indicate this property on the MMC regulator...?
> > 
> > vin-supply = <&vcc>;
> > 
> > I don't know whether an absence of such a declaration would be a problem,
> > though.
> 
> Regulators can have such a chain regulator. So that enabling a given
> regulator also enables the parent regulator. If it is not provided the
> worst thing that can happen is a warning that a dummy regulator is
> provided. Otherwise it should be ignored. Especially for fixed-regulators
> which come from "nowhere"...

OK, I just wondered if the regulator might not get set up if there was no link 
back to an unconditional power source.

> But all this brings me a new idea.
> 
> What do you think about using ioremap to read PAGPDIR, set bit 21 and write
> it back at the end of mmc_probe (where my register dump takes place)?
> 
> At least for checking if this is the issue. If it works and we can boot with
> this hack it becomes even easier to debug the kernel from a shell command
> line...

Short of figuring out the right way, I think that the way to go would be to 
call gpio_set_direction so that the regulator can bring the level low. Since 
it is not immediately obvious to me how to do this via pinctrl/pinmux, a quick 
and dirty equivalent way of doing so might be easiest.

Paul