Nice! Seems it may solve the problem like we have in dwmmc where some generic methods get overridden with device-specific actions.
May 14 2021
Dec 18 2020
Nov 4 2020
Nov 3 2020
- Address reviewer comments
Oct 30 2020
Thank you SOOOOOOOOOOO MUCH!!!!
If this builds, commit it! It'll help a lot!
Add actual content here.
Oct 24 2020
Sep 1 2020
At the first glance I don't see anything weird wrt MMCCAM intergration; I agree that MMCCAM-related problems should be fixed in the follow-up commits and not here.
Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.
Aug 4 2020
- Remove excessive printf
Jul 28 2020
The support for this has been merged in -HEAD through other commits.
Some last bits are coming in https://reviews.freebsd.org/D25843.
Jul 24 2020
Nov 28 2019
Updated to output an error message if various allocation functions failed. Also, revert to using alloc_ccb() from alloc_ccb_nowait() since it's pretty fine to wait in the contexts where start_discovery() is executed.
Nov 26 2019
Nov 1 2019
Oct 30 2019
May 28 2019
LGTM with a couple of tiny comments. Thanks!
Apr 10 2019
Addressed reviewer's comment about magic constant, added more comments.
- Move new fields to the end
Apr 7 2019
Updated to use MMC_DATA_BLOCK_SIZE.
- Implement CMD53 block mode support for SDHCI and AllWinner-based boards
- Use the new MMC_DATA_BLOCK_SIZE
- Put blank before colon when printing command args
Reupload the change.
Apr 5 2019
Updated; please take a look.
Killed CMD53-related changes, leaving only field changes.
Apr 1 2019
IF you jhust added the block count and block size to the end, there's no need to rebuild camcontrol...
Added (hopefully) missing files.
This is missing files I think. The mmcreg.h structure changes are missing from this one. This won't compile.
Generally LGTM with a few nits.
Mar 22 2019
I haven't convinced myself yet that these two extra fields are actually needed but meanwhile this is needed (independently). I'll put it into a proper review later tonight.Properly zero mmc_data structures in mmc_da.c With upcoming MMCCAM changes extra fields will otherwise contain garbage and yield unexpected or unhelpful results (hanging controllers and the like). diff --git a/sys/cam/mmc/mmc_da.c b/sys/cam/mmc/mmc_da.c index a2dbf949b40..6ec73a46050 100644 --- a/sys/cam/mmc/mmc_da.c +++ b/sys/cam/mmc/mmc_da.c @@ -843,6 +843,7 @@ mmc_send_ext_csd(struct cam_periph *periph, union ccb *ccb, struct mmc_data d; KASSERT(buf_len == 512, ("Buffer for ext csd must be 512 bytes")); + memset(&d, 0, sizeof(d)); d.data = rawextcsd; d.len = buf_len; d.flags = MMC_DATA_READ; @@ -988,6 +989,7 @@ mmc_sd_switch(struct cam_periph *periph, union ccb *ccb, struct mmc_data mmc_d; uint32_t arg; + memset(&mmc_d, 0, sizeof(mmc_d)); memset(res, 0, 64); mmc_d.len = 64; mmc_d.data = res; '''
- Use SDHCI_MAKE_BLKSZ() for calculating block size
- Initialize new fields of mmc_data properly
- Make block mode work
Mar 21 2019
The correct solution is implementing proper card insertion detection. This is, however, out of scope for this change. I'm just replicating the way it's implemented for mmc(4) in this driver, for now.
Yes and that's what I don't like, this is not the correct solution for this problem.
Ok, stupid me, has two questions:
(a) what would be proper card insertion detection here for this one? (I am battling a similar issue elsewhere currently)
(b) if the API gets changed, so it works without the aw_mmc_softc, the function gets put into a central place outside this driver, and then gets called, is that what you are asking @manu ?
Mar 20 2019
Address comments from bz@
Mar 19 2019
addressed reviewer comments
- locking fix for D15955
Quoting myself :
20:51 < manu> I'm not sure this is the right solution
20:52 < manu> it seems that it's cam only code
20:52 < manu__> so I don't understand why it's not in a generic function
Jun 21 2018
Jun 20 2018
Jun 19 2018
This looks okay for me except one comment.
But due to the fact that I/We had a lot of problems with different revision of the hardware IP let me test on different SoC before commiting.
Also I won't set this review as accepted as I don't know anything about CAM.