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

[H. Nikolaus Schaller]

Hi Paul,

> Am 12.12.2020 um 23:22 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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.

I think I had compared with jz4740 (not 4780) and it seems to be sane.

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

Haven't tried that, but what I have done is to add many printk to drivers/mmc.

Many function are called:

mmc_wait_for_cmd
mmc_send_op_cond
__mmc_start_req
mmc_wait_for_req_done
mmc_wait_done

ending in 

[    1.421813] mmc0: card never left busy state
[    1.426328] mmc0: error -145 whilst initialising SD card

So this part of the subsystem works. Well, we can assume that it works since
thousands of other boards use it.

But it seems to prove that card detection works (at least it may be ignored).

The problem is either communication of the driver with the mmc controller or
the controller with the card due to wrong setup.

I think I should add printk to the jz4740-mmc driver...

First inspection shows that there is some code path dependency on

host->version

but it is very likely that the jz4730 is similar to jz4740 and not jz4725 and
later.

Anyways it is much fun to experiment with latest kernels and Lubomir's u-boot.

BR,
Nikolaus