08:22 <nomis> robmur01: oh great.

12:57 <nomis> robmur01: *sigh* it still doesn't help me here.

12:57 <nomis> I see the 400khz clock on the clock pin, but no trace at all from the 100MHz clock.

13:06 <robmur01> boo... still, no output at all is curious. My initial thoughts there would be something off in the clock tree, or possibly something related to 3V/1.8V switching

13:07 <robmur01> what if you remove any UHS caps and just let it run in high-speed mode? (50MHz@3V)

13:13 <robmur01> and `git send-email ... @~1` is just beyond the edge of my comfort zone most of the time :)

13:17 <nomis> robmur01: the thing is, it works with the rockchip kernel. I don't think there is any hardware related possibility.

13:20 <nomis> and I've been surveying all the clock specifications. Maybe I just fail to see an obvious difference, but that all reads sane to me.

13:24 <nomis> [ 4.026965] dwmmc_rockchip ff5f0000.dwmmc: All phases bad!

13:24 <nomis> [ 4.027874] mmc2: error -5 whilst initialising SDIO card

13:24 <nomis> [ 4.027470] mmc2: tuning execution failed: -5

13:24 <nomis> the android kernel ends up with a phase of 135

13:43 <robmur01> if it's not the clock itself, it could be that the I/O voltage disappears or the IOVSEL gets out-of-sync if the mode involves a nominal voltage switch. Do the vqmmc_supply for the module and the vccio6_supply for the I/O domain line up, and does the regulator match reality in terms of voltage and enable pins?

13:48 <nomis> phew, not sure I understand the question or know where to check that.

13:50 <robmur01> come to think of it, I think the data lines idle high, so just verifying the voltage there against regulator_summary before and after the probe attempt ought to show up any mismatch

13:51 <nomis> the datalines seem to sit at 1.8V

13:51 <robmur01> OK, so if the I/O domain ends up in 3.3V mode it can't 'hear' the module respond

13:51 <nomis> and testing the phases seems to fail for mmc_send_tuning returning -EILSEQ

13:52 <nomis> robmur01: but the clock pin should be driven by the CPU, right? I should at least see a hint of the high frequency while the driver tries to increase the speed, or?

14:12 <robmur01> I don't really know the protocol details, but I'd assume the tuning commands have to be sent at the target clock rate

14:16 <robmur01> I'm still inclined to rule out any signal level issues first - you should have CONFIG_ROCKCHIP_IODOMAIN enabled and an io_domains node enabled in your DT with, among others, a vccio6-supply property pointing at a regulator; what's that regulator?

14:21 <nomis> robmur01: ok, that might have dropped out of my device tree. *groan*

14:35 <nomis> I guess I should have another run at the devicetree comparison between the rockchip-kernel and my kernel - this time not ignoring the stuff I don't understand.

14:35 <nomis> (currently rebuilding the image, results in a few minutes...)

14:45 <nomis> robmur01: ok, I've enabled the io-domains-Node and have set vccio6-supply to &vccio_1v8_reg (which seems to what is used in the other device tree. Unfortunately it does not seem to help with the tuning execution.

15:05 <nomis> Wait. I messed up.

15:09 <nomis> it is too easy to use references wrong. There is a huge difference between "... = &someting" and "... = <&something>"

15:16 <nomis> [ 1.535741] mmc2: new ultra high speed SDR104 SDIO card at address 0001

15:16 <nomis> robmur01: I owe you something. I'd never have found that.

15:19 <robmur01> heh, at least it looked like the communication problem that it was. The "failed to reset DMA" or whatever it is you get with the wrong GMAC I/O voltage was far more of a headscratcher ;)

15:36 <nomis> robmur01: just for my own understanding: Is this io_domains relevant for configuring the logic-level thresholds for certain pins?

15:46 <robmur01> yup, in most cases the power for the actual I/O pads comes in from outside, so logic high is "whatever the supply is", and there's a switch between nominal 3.3V and 1.8V modes for input threshold.