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

[H. Nikolaus Schaller]

Hi Paul,

> Am 19.12.2020 um 17:18 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Saturday, 19 December 2020 11:56:35 CET H. Nikolaus Schaller wrote:
>> 
>> This time there are more differences. Anyways shouldn't they be the same
>> right after completing probe? No communication should have taken place and
>> the controller should be idling here. Unless some other thread has already
>> started.
> 
> It is difficult to say. In theory, things should be the same, but we aren't 
> dealing with particularly transparent and straightforward software systems 
> here. Still, there is much to be said for precisely reproducing as much of the 
> hardware configuration as possible.
> 
> [...]
> 
>> If I remember correctly it has a positive effect but the card never left
>> busy state remains. Are there any gpio or other cgu or even intc settings
>> involved?
>> 
>> Attached are the new register dumps.
> 
> Thanks!
> 
> Some differences in CPM:
> 
> 0x10000000 - CFCR (clock control) has bit 12 differing, CFCR.LFR (LCD divider) 
> is 2 in the new kernel, 3 in the old, meaning a clock division of 3 in the 
> new, 4 in the old. (We'll surely get to the issue of the LCD controller 
> eventually.)
> 
> 0x1000000c - not a known register.
> 
> In INTC:
> 
> 0x10001004 - IMR (interrupt mask) has bits 1, 9, 15, 22, 23, 27, 28 (I2C, 
> UART0, RTC, OST2, OST1, GPIO1, GPIO0) cleared in the new kernel compared to 
> the old kernel, and bits 13 and 30 (UHC, LCD) masked compared to the old 
> kernel.
> 
> In OST:
> 
> 0x10002000 - TER (timer enable) has bits 0 and 1 set in the new kernel, 
> compared to bit 0 in the old. This just means that OST1 is enabled in the new 
> kernel for some reason.
> 
> 0x10002010 - TRDR (reload/limit) for channel 0 differs, being 0x8fff in the 
> new kernel but 0x9000 in the old, which is a small difference maybe indicating 
> a slight calculation discrepancy.
> 
> 0x10002014 - TCNT (counter) for channel 0 differs, as one might expect.
> 
> 0x1000201c - TCRB for channel 0 differs, but the nature of this register is 
> not known.
> 
> 0x10002030 - TRDR (reload/limit) for channel 1 differs, being 0xffff in the 
> new kernel and 0xffffffff in the old, but this probably just shows that this 
> counter is initialised in the new kernel...
> 
> 0x10002034 - TCNT (counter) for channel 1 differs, as one might expect (it is 
> 0xffffffff in the old kernel, indicating a lack of activity).
> 
> 0x10002038 - TCSR (status) for channel 1 differs, with bits 0, 2 and 6 being 
> set in the new kernel. Bits 0 and 2 give the value 5 for the input clock field 
> (CKS) indicating EXCLK, and bit 6 is the IRQ flag bit.
> 
> In RTC:
> 
> 0x10003004 - RSR (seconds) differs by 4089, perhaps indicating the time 
> between your tests!

Well, 4000 seconds would be more than one hour but I think it was less
than 10 minutes. But that is a don't care at the moment :)

> 
> In WDT:
> 
> 0x10004004 - TCNT (counter) is set to 0xffffffdf in the new kernel, zero in 
> the old. This is just a counter, however.
> 
> In GPIO:
> 
> 0x10010000 - PAGDPR (port A data) differs, with bit 9 cleared in the new 
> kernel, and bits 21 and 24 set. Bit 21 corresponds to the MMC power pin which 
> should be 0 if power is enabled.
> 
> 0x10010004 - PAGPDIR (port A direction) differs, with bits 21, 24 and 29 
> cleared in the new kernel. Since bit 21 corresponds to the MMC power pin and a 
> bit value of 0 corresponds to input, this seems to be wrong.
> 
> 0x1001000c - PAGPPUR (port A pull-up) differs, with pins 1 to 7, 21 cleared 
> and 25 set. Here, bit 21 is again of concern, with the bit value of 0 
> indicating no pull-up, but since this should be an output, I think this is 
> just a consequence of the pin being configured for input.
> 
> So, it appears that the mechanism for configuring the power pin is not 
> working. I see that the device tree has a regulator that employs this pin:
> 
>        vmmc_reg: regulator at 1 {
>                compatible = "regulator-fixed";
>                regulator-name = "vmmc";
> 
>                regulator-min-microvolt = <3300000>;
>                regulator-max-microvolt = <3300000>;
>                gpio = <&gpa 21 GPIO_ACTIVE_LOW>;
>        };
> 
> Although the MMC peripheral references this regulator, and I imagine that this 
> is then meant to activate the regulator somehow when the MMC peripheral is 
> enabled,

especially since I see

[    0.648725] vmmc: disabling

after the timeouts.

>  perhaps the remark I made earlier about pinctrl is pertinent. That 
> the pinctrl definition for the MMC peripheral doesn't need to include the 
> control pins, or at least does not need to include the power pin:
> 
>        pins_mmc: mmc {
>                mmc {
>                        function = "mmc";
>                        groups = "mmc-1bit", "mmc-4bit";
>                };
> 
>                mmc_ctrl {
>                        function = "mmc";
>                        pins = "PC0", "PC2", "PA21";
>                        bias-disable;
>                };
>        };

Hm. This would mean that the regulator or goip driver does pinmux?

> 
> To me, it seems possible that the presence of PA21 overrides the configuration 
> in the regulator, and as a result the pin is configured as an input pin with 
> no pull-up rather than as an output pin.

Ah, ok. That is likely that as soon as pins_mmc is requested, the PA21
becomes activated. What I don#t know is how the ingenic pinmux defines
input/output etc. OMAP always has pin control registers with bit patterns
defining input (capability)/output/pullup/down and function.

> 
> Continuing briefly to check GPIO port C where the other pins are involved:
> 
> 0x10010060 - PCGDPR (port C data) differs, with bits 4 and 16 set and bits 5, 
> 15 and 30 cleared. This doesn't seem to involve the pins of interest (at bits 
> 0 and 2).
> 
> 0x10010064 - PCGPDIR (port C direction) differs, but only involving bits 4 to 
> 7, 30 and 31. Importantly, bits 0 and 2 are cleared, meaning that they are 
> inputs.
> 
> 0x1001006c - PCGPPUR (port C pull-up) differs, with bits 0 and 2 being 
> cleared. This indicates that pull-ups are disabled for the CD and WP pins, 
> which is requested by the above pinctrl definition.
> 
> Considering this last discovery, I do wonder whether this is desirable: when a 
> card is not present, will the circuit not be "open" and thus prone to spurious 
> logic level fluctuations?

Well, there should be pull-ups. They may exist in hardware (would have to look
into the schematics) or the pull-ups in the jz4730.

> Although I could continue through the GPIO banks and look more closely (but 
> the functions for the MMC-related pins do seem to be correct), I think that 
> the above two discoveries are worth further investigation:
> 
> * The pin configuration affecting the regulator
> * The pull-up configuration of the CD and WP pins (PC0 and PC2)
> 
> If the MMC power is not enabled, that alone would cause some obvious 
> difficulties!

I did remember that I had designed a special SD-JTAG adapter for the Pyra
(because it is possible to do JTAG on the OMAP5 through the SD card pins).
I had to search a while until I found my reference sample (all others did go
to developers with JTAG experience).

So I was able to measure the VDD at the SD slot of the Minibook.

It goes up to ca. 2.5V after power-on (maybe the regulator can't be turned
off completely and my adapter draws no current). Then if I boot the NAND
image it takes a while until the kernel starts and it goes to 3.3V for some
moments.

If I press Shift+Fn boot fails of course (my adapter has no file system :)
but the Voltage also jumps to 3.3V while it tries to read from the SD card.

Finally I booted from my v5.10 SD card, but did extract and swap the card
with the adapter as fast as possible, before the register dump from mmc_probe
starts).

No change of SD card voltage from 2.5V. And after a while I get the
"vmmc: disabling".

So your theory seems to be right that the regulator isn't controlled
properly.

BR,
Nikolaus