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

[Paul Boddie]

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!

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, 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;
                };
        };

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.

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?

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!

Paul