By capturing some logs from io_trace_full branch, I can confirm the camera switches to 48 MHz, this a part from the log captured by Canon 700D:
It shows SD UHS default registers in 48 MHz same as 5D3 values, the overclocking was working @ 240MHz before the switch:
1.639.422 Fwrite:ff337a90:MMIO : [0xC040062C] <- 0x00000001
1.639.432 Fwrite:ff3377a0:MMIO : [0xC040046C] <- 0x00000001
1.639.435 Fwrite:ff33790c:MMIO : [0xC0400600] <- 0x00000003
1.639.438 Fwrite:ff337914:MMIO : [0xC0400610] <- 0x00000009
1.639.439 Fwrite:ff33791c:MMIO : [0xC0400614] <- 0x1D000601
1.639.441 Fwrite:ff337920:MMIO : [0xC0400618] <- 0x00000000
1.639.445 Fwrite:ff337950:MMIO : [0xC0400624] <- 0x00000504
1.639.446 Fwrite:ff337954:MMIO : [0xC0400628] <- 0x00000504
1.639.447 Fwrite:ff337958:MMIO : [0xC040061C] <- 0x00000100
1.639.448 Fwrite:ff3378e0:MMIO : [0xC0400620] <- 0x00000009
1.639.450 Fwrite:ff3378e4:MMIO : [0xC0400604] <- 0x00000003
It starts with sdSoftReset( 0 )
1.483.311 Fwrite:ff74aea0:23:01: sdSoftReset( 0 )
1.483.324 Fwrite:ff337a90:MMIO : [0xC040062C] <- 0x00000001
1.483.335 Fwrite:ff3377a0:MMIO : [0xC040046C] <- 0x00000001
1.483.341 Fwrite:ff3377ec:MMIO : [0xC0400600] <- 0x00000008
1.483.343 Fwrite:ff3377f4:MMIO : [0xC0400610] <- 0x0000017F
1.483.344 Fwrite:ff3377fc:MMIO : [0xC0400614] <- 0x1D004101
1.483.347 Fwrite:ff337800:MMIO : [0xC0400618] <- 0x00000000
1.483.348 Fwrite:ff337808:MMIO : [0xC0400624] <- 0x0000403F
1.483.350 Fwrite:ff33780c:MMIO : [0xC0400628] <- 0x0000403F
1.483.352 Fwrite:ff337814:MMIO : [0xC040061C] <- 0x0000007F
1.483.354 Fwrite:ff337818:MMIO : [0xC0400620] <- 0x0000007F
1.483.356 Fwrite:ff33781c:MMIO : [0xC0400604] <- 0x00000000
Then it goes with multiple commands from Canon (same as when the camera initialize the SD card during startup, e.g in
5D3 startup log)
sdSoftReset SUCCESS
sdTrySendCommand1 Start
sdSoftReset( 0 )
sdSoftReset SUCCESS
sdIdentifyDrive Start
sdSendIFCondition Start
sdSendIFCondition End
sdSendOCR Start
sdSendIFCondition End
sdSendOCR Start
sdSendOCR End
sdAllSendCID Start
sdAllSendCID End
sdSendRelativeAddress Start
sdSendRelativeAddress End
sdSendCSD Start
sdSendCSD End
sdSendCID Start
sdSendCID: MID = 0x03, PDN = 0x534c
sdSendCID End
sdSelectDeselectCard Start
.... etc
But I noticed it doesn't switch the frequency directly to 48 MHz or 96 MHz, it goes from multiple mods from the lowest frequency to the highest desired one (a1ex figured out this and he wrote the settings in sd_uhs.c 5D3 Mode 0 .. etc)
So I tried to start from the first values during SD card initialization to the next one to 24 MHz , 48 MHz , 96 MHz , 160 MHz and 240 MHz using sd_uhs.mo, I wrote it in order to emulate what Canon does . . . aaand . . . same result it switch back to 48 MHz

Sorry it didn't work
I don't know if we should call sdSoftReset or others commands, but also I got something
maybe the
problem from sd_uhs module itself, Because after Canon switch back to 48 MHz, theoretically I should able to run sd_uhs overclock again and get back 240 MHz overclocked values, but It doesn't patch the settings again only after a startup, and this problem from sd_uhs module (maybe) so if we could e.g. clear ROM patches by switching off sd_uhs like adtg_gui, or simply force the overclocked values and disable Canon patching (I think this type of code is used in crop_rec.c and adtg_gui.c)
I am not sure if this a good way, or even if it will work, maybe I messing
Good news: SDR104 @ 240 MHz is stable when it's working, the write speeds doesn't drops when recording and, it's constant and there is no corrupted frames or corrupted data, but I noticed the card and SD card door got warm but not too hot, my PC USB card reader gets a lot hotter when writing @ 90 MB/s
700D Logs:How I made the tests:
LOG 0: Overclocked values to 240 MHz then I took a photo in Photo Mode, after taking the picture it starts to switch to 48 MHz mode.
LOG 1: Without Overclocking, I got into Photo Mode and took a picture, everything is normal in this LOG.
Note: DebugMsg (io_trace_full build) didn't capture the overclocked values @240 MHz correctly instead it showing like this:
1.009.343 Fwrite:00af7544:MMIO : [0xC0400600] <- 0xEEEEEEEE
1.009.345 Fwrite:00af7544:MMIO : [0xC0400604] <- 0xEEEEEEEE
1.009.346 Fwrite:00af7544:MMIO : [0xC0400610] <- 0xEEEEEEEE
1.009.347 Fwrite:00af7544:MMIO : [0xC0400614] <- 0xEEEEEEEE
1.009.349 Fwrite:00af7544:MMIO : [0xC0400618] <- 0xEEEEEEEE
1.009.350 Fwrite:00af7544:MMIO : [0xC0400624] <- 0xEEEEEEEE
1.009.352 Fwrite:00af7544:MMIO : [0xC0400628] <- 0xEEEEEEEE
1.009.353 Fwrite:00af7544:MMIO : [0xC040061C] <- 0xEEEEEEEE
1.009.354 Fwrite:00af7544:MMIO : [0xC0400620] <- 0xEEEEEEEE
Same as when making overclock @ 160 MHz it also shows 0xEEEEEEEE, so this a bug from io_full_trace as I think, 0xEEEEEEEE value represents these registers have patched by ML.
It took me many hours to make sd_uhs work in io_trace_full since it's working in top of crop_rec_4k branches, io_trace_full not supported.