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

[H. Nikolaus Schaller]

Hi Paul,

> Am 20.12.2020 um 18:01 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Sunday, 20 December 2020 15:26:46 CET H. Nikolaus Schaller wrote:
>>> Am 20.12.2020 um 13:59 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>>                      pins = "PC0", "PC2", "PA21";
>> 
>> just for completeness, removing PA21 here doesn't improve anything.
>> 
>> New register dump (regs-5.10b.txt) is attached so that you can check if it
>> did have any significant effect. (I think 10010030 has changed from
>> 2000007f -> 2000003f but I am not sure if this is relevant).
> 
> What I can see is...
> 
> 0x10010000 - PAGPDR (port A data) has bit 28 cleared in the 5.10b dump 
> compared to the 5.10 dump. This is one of the USB pins.

Ok, may be random.

> 
> 0x10010004 - PAGPDIR (port A direction) still has bit 21 set to 0 (input).

Ok.

> 0x1001000c - PAGPPUR (port A pull-up) has bit 21 set in the 5.10b dump, 
> enabling the PA21 pull-up. So, this at least means that the bias-disable 
> property is no longer applying to the pin.

Ok!

> 0x10010030 - PBGPDR (port B data) has bit 7 cleared in this new dump. This is 
> one of the MMC peripheral pins.

Well, my adapter card is no card and hence it does not pull-up signals
internally.

> 
>> Next I tried to change the gpio 21 from ACTIVE_LOW to ACTIVE_HIGH
>> (regs-5.10c.txt where 10010030 is back to 2000007f). No difference in mmc
>> detection :/
> 
> Yes, PAGPDR bit 21 is set in these 5.10 dumps, meaning that the power is 
> disabled as far as the driver is concerned. In the 2.6 dump, with the register 
> value of 0x7a9e12ff it is cleared, meaning that the power is enabled.

Obviously, the key seems to be the pin direction.

> 
>> And I have checked the schematics. CD and WP have external 47kΩ pullups and
>> are active low. UART3_TXD/GP21 goes as SD_EN# to a SD-VDD-switching
>> transistor (AO3401) powered from 3.3V. So active low should be correct.
> 
> Useful to know about the CD and WP pull-ups meaning that bias-disable could be 
> applied to those pins in the SoC, although this may be the default, anyway.
> 
>> Are we sure that the GP21 gets configured as GPIO and not as UART3?
> 
> That would be controlled by PAGPAUR (port A function upper, for pins 16 to 31) 
> at 0x10010014. Pin 21 would be controlled by bits 10 and 11 which appear to 
> yield 0 meaning GPIO. So I am fairly sure that it is configured correctly.

Ok. Just to be sure...

> One thing I didn't look at yesterday was the difference in MMC/MSC 
> configuration. I see that the 5.10 dumps show that...
> 
> 0x10021004 - STAT (status) has bit 8 (clock enable) set in the 5.10 dumps.
> 
> 0x10021008 - CLKRT (clock rate) has a value of 6 in bits 0 to 2, causing a 
> clock division of 64, as previously noted.
> 
> 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.

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

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

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

BR,
Nikolaus