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

[Paul Boddie]

On Tuesday, 15 December 2020 18:06:28 CET H. Nikolaus Schaller wrote:
> 
> So either the bits of the controller do not match.
> This is a little more unlikely after this test because
> we can see interrupts.
> 
> It is a little more likely pinmux or communication between
> the controller and the card (or regulator?).
> 
> But doesn't it just use those from U-Boot if there is no
> new setup in the kernel?

I would think so. Incidentally, I did look at U-Boot's MMC support for the 
JZ4740 and it seems to be fairly basic with no DMA, just polling.

> Unfortunately we can't boot to some shell or I could inspect
> the pinmux registers through devmem2... If I remember correctly
> I did this for the CI20 to compare the working vendor setup
> with what our DWC and HDMI code was doing until they were
> equivalent.

Yes, that was very helpful.

> Hm.
> 
> A complex but doable approach: add code to jz4740_mmc_probe
> to printk mmc controller registers and pinmux registers and
> perhaps also gpio controller (for cd, wp, SD power).
> 
> And hack the same into the 2.6 kernel which we can boot.
> 
> What I would need help for is a list of register addresses to
> ioremap and readw/readl and printk. This would work without
> shell and devmem2.

I can try and write these up.

> PS: can it be that there is no card-detect interrupt?
> The variable jz4740_mmc_host->card_detect_irq in jz4740_mmc.c
> is nowhere used. (BTW: there is a similarly stale definition in
> include/linux/platform_data/mmc-omap.h)

That does look very suspicious. The legacy kernel does actually request an IRQ 
for the card detect signal (or "hotplug" as it calls it), and the condition 
causes a variable to change value in the driver.

Looking a bit more closely at the current kernel, I can't see how it actually 
tests for the card detect signal at all. The "cd-gpios" property is only 
supported in three drivers:

drivers/mmc/host/mxcmmc.c
drivers/mmc/host/atmel-mci.c
drivers/mmc/host/sdhci-s3c.c

The most helpful one of these (to me) is the Atmel one. Here, they obtain the 
pin details:

pdata->slot[slot_id].detect_pin = of_get_named_gpio(cnp, "cd-gpios", 0);

Then, they provide a function for the get_cd "slot" in the mmc_host_ops which 
tests the pin. They also register an interrupt for the pin and presumably 
service that when it occurs.

However, it might be the case that we really want to define a "cd" property 
instead. The core functionality in drivers/mmc/core/host.c contains the 
following in the mmc_of_parse function that parses the device tree structure:

ret = mmc_gpiod_request_cd(host, "cd", 0, false,
                           cd_debounce_delay_ms * 1000);
if (!ret)
        dev_info(host->parent, "Got CD GPIO\n");

I don't know how that interacts with any interrupt mechanism, though. But 
maybe replacing "cd-gpios" with "cd" might help.

Paul