[Letux-kernel] X1600 / LX16 support - here: adding MMC

[Paul Boddie]

On Saturday, 10 February 2024 14:58:45 CET H. Nikolaus Schaller wrote:
> 
> So someone calls jz4740_mmc_clock_disable() after doing jz4740_mmc_reset()
> and that resets the IS_RESETTING flag.
> 
> But what does that exactly mean?
> 
> BTW: clock_disable loops until JZ_MMC_STATUS_CLK_EN is 0.
> But it already is...

As I noted before, the U-Boot code for setting up the MMC/SD controller on the 
X1600 and other newer SoCs doesn't test IS_RESETTING. Here it is slightly 
reformatted:

#if defined(CONFIG_M200) || defined(CONFIG_X1000) || defined(CONFIG_X1630) \
        || defined(CONFIG_X1830) || defined(CONFIG_X1800) \
        || defined(CONFIG_X1520) || defined(CONFIG_T31) \
        || defined(CONFIG_X1021) || defined(CONFIG_X1521) \
        || defined(CONFIG_X1600)

        int tmp;
        tmp = jz_mmc_readl(priv, MSC_STRPCL);
        tmp &= ~MSC_STRPCL_RESET;
        jz_mmc_writel(tmp, priv, MSC_STRPCL);
#else
        while (jz_mmc_readl(priv, MSC_STAT) & MSC_STAT_IS_RESETTING);
#endif

So, I imagine that the hardware behaviour changed after the JZ4780. I can 
confirm that the above trick gets past the resetting obstacle. It seems likely 
that such a workaround might be necessary, and it is hardly worse than the 
ubiquitous timeout loops in all the Linux drivers.

I have also spent a lot of time trying to get the peripheral to work 
independently of Linux and U-Boot, as previously noted, including much time 
trying to get data transfer to work. I aim to apply some of the lessons from 
this activity to the Linux driver.

Other things that will be checked include the clock support, where I didn't 
manage to finish off the divider computation, and any pinctrl anomalies. My 
parallel development efforts should be able to inform these areas because I am 
quite able to configure the clocks and utilise a range of peripherals given my 
own understanding of the hardware.

Hopefully, I will be able to look into this tomorrow.

Paul