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

[Paul Boddie]

On Saturday, 12 December 2020 16:20:12 CET H. Nikolaus Schaller wrote:
> 
> Ok, I see. With our bugs in the device tree and the dma driver we always got
> ret == -EPROBE_DEFER and didn't get mmc.
> 
> Now we get ret == 0 and use_dma is active.
> 
> So the solution is simple: make jz4740_mmc_acquire_dma_channels() return
> e.g. -EINVAL. Or overwrite host->use_dma = false;

Not if we eventually want to use DMA, but I understand what your strategy is. 
:-)

[...]

> Some observations:
> 1. mmc_gpio_get_cd returns 1 which seems to be ok
> 2. there is now an error -145 (ETIMEDOUT) - i.e. the card does not respond
> 3. driver tries reset - which may indicate some power problem
> 4. this is tried 4 times
> 5. ejecting and reinserting the card does not seem to trigger an irq
> (although I have a printk for it)

I did wonder whether the pinctrl section for the extra pins was working. In 
the CI20's device tree, this is done to assign the pin, but there is no 
incorporation of this pin into pins_mmc0:

&mmc0 {
        ...
        pinctrl-0 = <&pins_mmc0>;

        cd-gpios = <&gpf 20 GPIO_ACTIVE_LOW>;
};

This is what the CI20's pins_mmc0 looks like:

        pins_mmc0: mmc0 {
                function = "mmc0";
                groups = "mmc0-1bit-e", "mmc0-4bit-e";
                bias-disable;
        };

The two groups merely cover the six MMC pins, not the extra CD pin.

Since the Minibook has this instead:

&mmc0 {
        ...
        cd-gpios = <&gpc 0 GPIO_ACTIVE_LOW>;
        wp-gpios = <&gpc 2 GPIO_ACTIVE_LOW>;
        ...
        pinctrl-0 = <&pins_mmc>;
};

Maybe we want to drop the CD, WP and (maybe) power pins from pins_mmc, which 
is currently this:

        pins_mmc: mmc {
                mmc {
                        function = "mmc";
                        groups = "mmc-1bit", "mmc-4bit";
                };

                mmc_ctrl {
                        function = "mmc";
                        pins = "PC0", "PC2", "PA21";
                        bias-disable;
                };
        };

But this is just speculation about conflicting definitions. Perhaps it is not 
a problem at all.

> 6. I can type on the console - i.e. the kernel is not stuck but just waiting
> for a root device
> 7. what is strange is the [    0.984047]
>    that was not 0.9 seconds after boot boot but ca. 20
>    so our system timer runs at wrong speed

Yes, I guess the frequency assumptions are wrong. If the TCU/OST were 
responsible for timekeeping, I might suggest that the assigned-clock-parents 
attributes are the problem:

&tcu {
        assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>,
                          <&tcu TCU_CLK_TIMER2>;
        assigned-clock-parents = <&cgu JZ4730_CLK_EXT>, <&cgu JZ4730_CLK_EXT>,
                                 <&cgu JZ4730_CLK_EXT>;
};

I'd have to think about this a bit more.

> 8. the rs-gpio is not requested since we do not define it anywhere (neither
> does qi_lb60) and calls to mmc_gpio_set_rshave no effect (which likely is
> ok)
> 
> So we know
> - communication with the card does not work even or especially w/o DMA
> - CD interrupts don't work
> - time scale is not real time
> 
> maybe Lubomir can find something through his JTAG?

I hope so. More observations might be useful.

Paul