Page MenuHomeFreeBSD

mmc_da: restore HS200 support that was present in MMCCAM branch
AbandonedPublic

Authored by avg on Apr 14 2021, 9:55 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 21 2024, 12:32 PM
Unknown Object (File)
Dec 30 2023, 12:09 AM
Unknown Object (File)
Dec 1 2023, 7:39 AM
Unknown Object (File)
Oct 8 2023, 1:40 PM
Unknown Object (File)
Aug 25 2023, 7:16 AM
Unknown Object (File)
Jun 20 2023, 9:50 PM
Unknown Object (File)
May 29 2023, 8:22 PM
Unknown Object (File)
May 12 2023, 2:15 AM
Subscribers

Details

Reviewers
manu
kibab
bz
Group Reviewers
cam
Summary

Without HS200 support DDR52 timings were used and I was unable to boot
from eMMC on Orange Pi PC Plus board.
There was a constant stream of these errors:

aw_mmc2: error rint: 0x00000006
AW_MMC_INT_RESP_ERR

I am sure that there can be problems with the proposed change,
but it works for me.

Test Plan

Tested with SD and eMMC on Orange Pi PC Plus board.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 38570
Build 35459: arc lint + arc unit

Event Timeline

avg requested review of this revision.Apr 14 2021, 9:55 AM

What is the resulting chosen mode ? You can query with camcontrol
I have no problem with DDR52 on all my boards and I don't remember if anything else was missing to have proper hs200 on all Allwinner boards.

Is this the information you asked for?

# camcontrol devlist -v       
scbus0 on aw_mmc_sim0 bus 0:
scbus1 on aw_mmc_sim1 bus 0:
<SDIO card>                        at scbus1 target 0 lun 0 (sdiob0,pass1)
scbus2 on aw_mmc_sim2 bus 0:
<MMCHC 8GME4R 0.1 SN 4DAD8E5D MFG 09/200>  at scbus2 target 0 lun 0 (sdda0,pass0)
scbus-1 on xpt0 bus 0:
<>                                 at scbus-1 target -1 lun ffffffff (xpt0)

# camcontrol mmcsdcmd 2:0:0 -I
Host controller information
Host OCR: 0x300000
Min frequency: 400 KHz
Max frequency: 52 MHz
Supported bus width:
 4 bit
 8 bit
Supported operating modes:
 Can do High Speed transfers
Supported VCCQ voltages:
 3.3V
Current settings:
 Bus width: 8 bit
 Freq: 52.000 MHz (high-speed timing)
 VCCQ: 1.2V
In D29758#667519, @avg wrote:

Is this the information you asked for?

# camcontrol devlist -v       
scbus0 on aw_mmc_sim0 bus 0:
scbus1 on aw_mmc_sim1 bus 0:
<SDIO card>                        at scbus1 target 0 lun 0 (sdiob0,pass1)
scbus2 on aw_mmc_sim2 bus 0:
<MMCHC 8GME4R 0.1 SN 4DAD8E5D MFG 09/200>  at scbus2 target 0 lun 0 (sdda0,pass0)
scbus-1 on xpt0 bus 0:
<>                                 at scbus-1 target -1 lun ffffffff (xpt0)

# camcontrol mmcsdcmd 2:0:0 -I
Host controller information
Host OCR: 0x300000
Min frequency: 400 KHz
Max frequency: 52 MHz
Supported bus width:
 4 bit
 8 bit
Supported operating modes:
 Can do High Speed transfers
Supported VCCQ voltages:
 3.3V
Current settings:
 Bus width: 8 bit
 Freq: 52.000 MHz (high-speed timing)
 VCCQ: 1.2V

Yes, and I see that it's working at 52Mhz ...
We also report VCCQ to 1.2V which seems weird as the reported supported voltage list only contain 3.3V (and the DTS shows that it's using the 3.3V regulator).
So maybe the problem is elsewhere ?

Yes, most likely.

The inconsistency in the camcontrol output is very puzzling.
Also, I've just now realized that the timing selection loop in sdda_start_init is not really a loop.
Its structure is:

for (timing = xxx; timing > bus_timing_normal; timing--) {
  if (...) {
    ...
    break;
  } else if(...) {
    ...
    break;
  } else {
    ...
    break;
  }
}

So, obviously one of the branches is always taken (because of the final catch-all 'else') and, thus, the first iteration is always the last too.

Having said that, I fail to see how my change could make any difference at all.
Yet it did.

There must be some thing like uninitialized memory or something.

For the 1.2V report it's probably the same problem as the one fixed by 1a96c1434f4b4487126f13ede29e67ad44a8776a

In D29758#667600, @manu wrote:

For the 1.2V report it's probably the same problem as the one fixed by 1a96c1434f4b4487126f13ede29e67ad44a8776a

Yeah, I was about to comment that 'another observation is that aw_mmc seems to ignore MMC_VCCQ' when I saw this followup.

Also, I should have clarified that I really needed this change in November 2020.
I recently upgraded to the latest main (beginning of April) and just carried over the change.
I never tested if it's actually still needed with the latest main.
I will.

And in fact, it seems that I do not need that change anymore.

I think that I needed that patch because earlier I had a lot of bits from https://github.com/kibab/freebsd/tree/mmccam-current in my tree and now I don't.
Specifically, @kibab's mmc_set_timing supports a lot more timings and so on.

@kibab , you still may want to fix this pseudo-loop: https://github.com/kibab/freebsd/blob/mmccam-current/sys/cam/mmc/mmc_da.c#L1638
Maybe the last 'else' was supposed to be 'else if' ?