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

[H. Nikolaus Schaller]

Hi Paul,

> Am 20.12.2020 um 19:37 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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

Yes.

> 
>> 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.

Yes.

> 
>> 
>>> 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.

I have tried and now I have

[    0.183531] reg: 10010004: 08200200

instead of e.g.

[    0.197738] reg: 10010004: 08000200

And now I can see the VDD of the SD card jump to 3.3V for a short moment.
But the mmc driver is still waiting for the SD card.

So our problem is the GPIO direction register. Maybe it is a general problem...

I have now tried to understand, and yes it is very different from OMAP.
I had expected some drivers/gpio/ingenic or similar. But it uses
pinctrl/pinctrl-ingenic.c

There we have a mix of pinmux and gpio control. But all things are in
place like ingenic_gpio_direction_output(), ingenic_gpio_get(), ingenic_gpio_set().

What I can imagine is that in one of these functions our JZ4730 specific offset
calculations are wrong.

Maybe some printk here and there will help to identify...

BR,
Nikolaus