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

[H. Nikolaus Schaller]

Hi Paul,

> Am 05.12.2020 um 17:56 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Saturday, 5 December 2020 16:58:49 CET H. Nikolaus Schaller wrote:
>> 
>> With this setup I can boot from SD into the kernel. And all my helper tools
>> to create images for
>> 
>> 	https://download.goldelico.com/letux-u-boot/Mipsbook400/
>> 	https://download.goldelico.com/letux-kernel/latest-l400/
>> 
>> are working so that I can (re)generate any SD card through 'makesd' and
>> combine with my prebuilt Debian rootfs flavors within minutes. That is
>> important for kernel development to have a short turnaround time between
>> compile and boot/test.
>> 
>> BTW: I have also git committed the source code for the NAND U-Boot 1.1.6 for
>> easier reference:
>> https://git.goldelico.com/?p=letux-uboot.git;a=shortlog;h=refs/heads/old/mi
>> psbook-u-boot-1.1.6
> 
> Great work, Nikolaus and Lubomir!
> 
> [...]
> 
>> [    0.025852] clocksource: jiffies: mask: 0xffffffff max_cycles:
>> 0xffffffff, max_idle_ns: 19112604462750000 ns
> 
> I guess this is without the TCU/OST clock source, which needs updating to 
> handle those timers as 32-bit values, as noted earlier. I imagine that this 
> uses the built-in MIPS timer/counter register instead. Maybe the TCU stuff is 
> not important after all, at least to get things working.

Well, it seems as if the current setup requires to have
"clocksource=jiffies clk_ignore_unused " in the cmdline which is something
we should get rid of.

But for the moment it seems to work.

> 
> [...]
> 
>> [    0.035805] jz4780-dma 10020000.dma: failed to get I/O memory
>> [    0.036100] jz4780-dma: probe of 10020000.dma failed with error -22
> 
> I think this might have been noted earlier.

Is likely a wrong or overlapping reg = <> entry

> 
>> [    0.186320] jz4740-wdt: probe of 10004000.watchdog failed with error -22
> 
> This might be a problem with the TCU driver.

And likely something for later.

> 
>> [    0.198276] pinctrl-ingenic 10010000.pin-controller: invalid group "PC0"
>> for function "mmc"
>> [    0.189815] pinctrl-ingenic 10010000.pin-controller: invalid group "PC2"
>> for function "mmc"
>> [    0.198635] pinctrl-ingenic 10010000.pin-controller: invalid group "PA21"
>> for function "mmc"
> 
> A review of pinctrl might be needed to fix any group details.
> 
> [...]

I have tried to understand this. Basically these groups appear in

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

in mipsbook.dts.

The qi_lb60.dts has something similar with PD0 and PD2.

I have checked with drivers/pinctrl/pinctrl-ingenic.c but such things are nowhere
defined. I think they refer to some generic GPIOs. USB also refers to pins = "PA29";

Ah, now I get it better. These are references by pins = and not groups = so these
are not defined in the group tables. Rather there should be some code to evaluate
the pins = property.

This is obviously done reversed by creating a name table:

		jzpc->pdesc[i].name = kasprintf(GFP_KERNEL, "P%c%d",
						'A' + (i / PINS_PER_GPIO_CHIP),
						i % PINS_PER_GPIO_CHIP);

It looks as if something goes wrong with looking up the GPIO descriptors.

Maybe it is the reason why the SD card is not found.

> 
>> [    0.199384] jz4740-mmc 10021000.mmc: Looking up vqmmc-supply property in
>> node /mmc at 10021000 failed
> 
> A device tree issue, perhaps?

Yes. For SDHC there is a separation of SD card vmmc and the bus voltage vqmmc.
This means that a controller can potentially control two regulators.
Well, we have no SDHC but drivers/mmc/host/regulator.c assumes.

It seems to be harmless if a regulator is not found and I hope that it is
like on other boards that a simple dummy regulator is substituted.

In any case we just have to add:

	vmmc-supply = <&vmmc_reg>;
	vqmmc-supply = <&vmmc_reg>;

to mipsbook_400.dts

> 
>> [    0.200425] ledtrig-cpu: registered to indicate activity on CPUs
>> [    0.196419] jz4740-mmc 10021000.mmc: Failed to get dma_tx channel
> 
> Probably a consequence of the DMA driver failure.

Yes. And the main reason why we have no MMC/SD.

> 
> So, the MMC problem might be due to the DMA and pinctrl failures that preceded 
> it.

Yes, I agree.

Now let's look why the DMA fails in first place. I'll take a look at that now.

Yes, it is adjacent to the mmc controller:

	mmc: mmc at 10021000 {
		compatible = "ingenic,jz4740-mmc";
		reg = <0x10021000 0x100>;

	dma: dma at 10020000 {
		compatible = "ingenic,jz4730-dma";
		reg = <0x10020000 0x100>;

BTW: we should sort the DT nodes for increasing addresses. This makes it
easier to find the subsystems. Seems to be the rule for other CPU DTSI.

BR and thanks,
Nikolaus