Lenovo t440p RTS5227 problem

[vddrnnr]

Hi Cholonam,

While trying to use your kext with t440p although it loads and detects the card reader it does not detect properly inserting/removing cards. I've looked at the debug output and it seems it's detecting inserting when we remove the card and removing when we insert. Here is the debug output from dmesg. Can you look into this I'll be happy to help you test any fixes.

Best regards, voidRunner

• Inserting

rtsx: Sinetek_rtsx_openbsd_c: [LOOP] tsleep_nsec ret = 1 (THREAD_TIME_OUT) rtsx: rtsx_wait_intr : [LOOP] WAITED 1001079/1000000 us (MMC_APP_CMD) (TIMEOUT!) rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset

rtsx: sdmmc_dump_command : sdmmc: cmd 55 (MMC_APP_CMD) arg=0 data=0 dlen=0 flags=0x1c01 proc="" (error 60)

rtsx: sdmmc_mem_send_op_cond: [DEF] c_resp[0]=0x00000000 i=0 error=60 rtsx: rtsx_exec_command : [DEF] rtsx: executing cmd hu

rtsx: Sinetek_rtsx_openbsd_c: [LOOP] rtsxintr: tsleep_nsec called (1000 ms, havelock=1)

• Removing

rtsx: Sinetek_rtsx_openbsd_c: [LOOP] tsleep_nsec ret = 1 (THREAD_TIME_OUT) rtsx: rtsx_wait_intr : [LOOP] WAITED 1001113/1000000 us (MMC_SEND_OP_COND) (TIMEOUT!) rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset

rtsx: sdmmc_dump_command : sdmmc: cmd 1 (MMC_SEND_OP_COND) arg=0x40000000 data=0 dlen=0 flags=0x1031 proc="" (error 60)

rtsx: sdmmc_mem_send_op_cond: [DEF] c_resp[0]=0x00000000 i=0 error=60 rtsx: sdmmc_mem_enable : sdmmc: can't read memory OCR

rtsx: rtsx_bus_clock : [DEF] Setting bus clock = 0 KHz rtsx: rtsx_bus_power : [DEF] rtsx: voltage change ocr=0x0

rtsx: rtsx_host_reset : [DEF] rtsx: host reset

rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset

rtsx: sdmmc_card_attach : sdmmc: can't enable card

rtsx: rtsx_bus_clock : [DEF] Setting bus clock = 0 KHz rtsx: rtsx_bus_power : [DEF] rtsx: voltage change ocr=0x0

rtsx: rtsx_host_reset : [DEF] rtsx: host reset

rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset

rtsx: Sinetek_rtsx_openbsd_c: [LOOP] mmctsk: tsleep_nsec called (18446744073709 ms, havelock=1)

[cholonam]

Hello @vddrnnr,

RTS5227 has been reported to work with boot flag rtsx_sleep_wake_delay_ms=1000 (see #18). Other than that, since you seem to be getting timeout errors, I'd try increasing timeouts (rtsx_timeout_shift=2). Sometimes this is due to a bad-behaving card, so I would try with a different card too, just in case.

If that doesn't work, you can play also with other boot arguments (-rtsx_mimic_linux, -rtsx_no_adma, and so on, it's in the REDAME). Unfortunately it's a matter of trial and error. Also, use read-only mode if you have important data in the card until reading is working and stable (particularly if you use sleep).

If you get lucky, please let me know what you did and I'll update the REAME.

[vddrnnr]

Hi Cholonam,

I've been looking into this issue and found some references regarding some Lenovo laptops where it is mentioned that card detection is inverted. Take a look at the folowing repo

https://github.com/hlh-restart/rtsx

So I now have rts5227 in lenovo t440p working by changing in rtsx.c in rtsx_intr the detection of the insertion so it detects the card inserting when a new card is inserted. As I mentioned before in my case I was detecting ejects when inserting and vice versa.

if (!(status & RTSX_SD_EXIST))

I also needed to change the behaviour of the driver making it work as a rts5229 as I've found that for openbsd the driver seems to be the same. I needed to make this change in Sinetek_rtsx.cpp so it sets flags to RTSX_F_5229 in rtsx_pci_attach

case PCI_PRODUCT_REALTEK_RTS5227: flags = RTSX_F_5229; break;

PS. I forgot to mention that for now I have disabled detecting cards already inserted.

PS2. Attaching and using the first time after a reboot/startup works ok. Dettaching by removing the card directly removes also the mount from the system and I get an macos error notification about removing the card without unmounting/ejecting first. When inserting the card again I get the following error.

rtsx: Sinetek_rtsx_openbsd_c: [LOOP] wakeup called (havelock=0) rtsx: Sinetek_rtsx_openbsd_c: [LOOP] wakeup returns rtsx: Sinetek_rtsx_openbsd_c: [LOOP] tsleep_nsec ret = 0 (THREAD_AWAKENED) rtsx: rtsx_wait_intr : [LOOP] WAITED 1638/1000000 us (SD_APP_OP_COND) rtsx: sdmmc_dump_command : [CMD] sdmmc: cmd 41 (SD_APP_OP_COND) arg=0x403c0000 data=0 dlen=0 flags=0x1031 (OK) => [0x00ff8000] rtsx: sdmmc_mem_send_op_cond: [DEF] c_resp[0]=0x00ff8000 i=100 error=60 rtsx: sdmmc_mem_enable : sdmmc: can't send memory OCR rtsx: rtsx_bus_clock : [DEF] Setting bus clock = 0 KHz rtsx: rtsx_bus_power : [DEF] rtsx: voltage change ocr=0x0 rtsx: rtsx_host_reset : [DEF] rtsx: host reset rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset rtsx: sdmmc_card_attach : sdmmc: can't enable card rtsx: rtsx_bus_clock : [DEF] Setting bus clock = 0 KHz rtsx: rtsx_bus_power : [DEF] rtsx: voltage change ocr=0x0 rtsx: rtsx_host_reset : [DEF] rtsx: host reset rtsx: rtsx_soft_reset : [DEF] rtsx: soft reset rtsx: Sinetek_rtsx_openbsd_c: [LOOP] mmctsk: tsleep_nsec called (18446744073709 ms, havelock=1)

Best regards, voidRunner

[cholonam]

Thanks for the effort looking into this, I'll reopen this issue until I have some time to look into it too. I warn you it may take long, since I'm going to be quite busy for the time being..

I did look a bit into the Linux kernel driver (here and here) and I can't see it doing any flag inversion, so maybe it's a matter of properly initializing the chip on boot/wake, rather than using the flag inverted.

If you can submit a pull request with the changes that are working for your, that would be very helpful (I'm afraid of breaking other chips which are working now, but I could add a boot flag at least, with the inversion option, if there is no cleaner way).

Also, if you have time to test wether your chip works properly on Linux, that'd help too (I'm pretty sure it will, but just in case).

[Sniki]

That’s a nice discovery. Just the fact that we have sleep/wake and the cards still working is amazing, that was the main PITA.

However regarding boot-args i feel like the best way would’ve been to have those as DeviceProperties.

All Acidanthera kexts have these functions (functional) already as the boot-arg method is more for troubleshooting and testing and not the best long term solution.