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

H. Nikolaus Schaller hns at goldelico.com
Fri Feb 9 15:14:11 CET 2024


Paul,

> Am 09.02.2024 um 13:14 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Friday, 9 February 2024 07:58:33 CET H. Nikolaus Schaller wrote:
>> 
>>> Eeasons for our issues could be:
>>> 1. clocks
>>> 2. DMA (if DMA used for single byte reads like the OCR?)
>>> 3. pinctrl (pullup/down?)
>>> 4. subtle msc controller differences to ingenic,jz4780-mmc (it was a pure assumption that they are the same based on same I/O address 0x13450000/0x13460000 and we have not yet checked)
>>> 5. something else (but what?)
>> 
>> I've compared the programming manuals (hypothesis 4.)
>> 
>> jz4780 has 3 MSC and x1600 has 2 but that is handled by DTS nodes.
> 
> I was trying to get the MSC peripheral working in my L4Re system yesterday and 
> had to deal with apparent differences in behaviour.
> 
>> MSC_LPM (low power mode) the same
> 
> This appeared to be set when my code started up, and it seems that the LPM 
> (low power mode) bit is set. So I cloned your letux-uboot repository and 
> examined the ingenic-x1600 branch. Sure enough, the authors have set that bit, 
> which might have an impact on clock operations because those operations are 
> not supposed to work (or to be used) in low power mode.
> 
> Actually, what was holding me up for quite some time was the errant behaviour 
> trying to reset the peripheral. In the Linux driver, they do the usual timeout 
> if something didn't seem to work, but after setting the reset bit in the 
> control register, the resetting bit in the status register would not clear 
> itself. Again, looking at the U-Boot code and there is a section specific to 
> the X1600 and newer SoCs clearing the reset bit after setting it.
> 
> So, there are definitely functional differences that are not communicated in 
> the manual.

So we have to study code...

And the 5.10.y kernel.

I did boot the LX16 with it. CLK frequency is 50 MHz (!), much more than the
3.5 MHz I had seen before. Of course it is expected that clock rate is up-regulated
if the card properties have been properly negotiated.

But: on the mmc1 interface I could see an almost steady 200kHz (!) CLK when no
card is inserted. This is much slower than the 3.5 MHz I had seen on mmc0.

Next I rebooted with our work-6.8 kernel because I hadn't ever looked at MMC1.
And there is no CLK at all on MSC1! Despite driver telling

[    0.000201] mmc1: Card stuck being busy! __mmc_poll_for_busy
[    0.000201] mmc1: error -22 whilst initialising SDIO card

which should involve some communication with the card.

BTW: this __mmc_poll_for_busy happens only for mmc1 which corresponds to completely
missing CLK.

This makes me currently favour a combination of theory 1. and 3.

Unfortunately we can't look into /sys/kernel/debug...

Therefore, I reviewed the DTS, ingenic,x1600-cgu.h, and drivers//clk/ingenic/x1600-cgu.c
- even the .div entry - with the PM and didn't find any obvious issue :(

This seems to exclude a clock issue - unless it is in the .parents definition
or divisor calculation. Maybe we can debug that now with printk() working!

And, we can printk the dividers and MSC register block e.g. in mmc_rescan_try_freq(),
even before and after mmc_power_up() or mmc_hw_reset_for_init().

An alternative theory might be that U-Boot is initializing MSC0 but not MSC1
and I see "leftovers" from this on the scope.

Finally I looked into drivers/mmc/host/jz4740_mmc.c and although there is a reset
function it does not address the "forbidden" RTS_EN pin, but simply resets the MSC
controller.

Interestingly the last register definition is JZ_REG_MMC_DMAC, i.e. registers
MSC_DMANDA, MSC_DMADA, MSC_DMALEN, MSC_DMACMD, MSC_RTCNT and the MSC_CTRL2 (where
RTS_EN is located) are not touched by the upstream jz4740 driver. And not on
jz4780 (which works).

So it will indeed be interesting to see how the MSC registers are initialized.
And clock dividers and registers. And pinctrl. Will just need a little time
for hacking this into the kernel code.

BR,
Nikolaus


More information about the Letux-kernel mailing list