[coreboot-gerrit] Change in ...coreboot[master]: drivers: Add eMMC reset driver

[Richard Spiegel (Code Review)]

Richard Spiegel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/30225 )

Change subject: drivers: Add eMMC reset driver
......................................................................


Patch Set 3:

(5 comments)

https://review.coreboot.org/#/c/30225/1//COMMIT_MSG 
Commit Message:

https://review.coreboot.org/#/c/30225/1//COMMIT_MSG@14 
PS1, Line 14: second time). This might save up to 100 milliseconds (exact value TBD).
> I agree with Nico.  It's not like we'd want to wait in coreboot if the reset hasn't finished. […]
Ok, will remove ramstage section.


https://review.coreboot.org/#/c/30225/1/src/drivers/emmc/emmc_rom.c 
File src/drivers/emmc/emmc_rom.c:

https://review.coreboot.org/#/c/30225/1/src/drivers/emmc/emmc_rom.c@40 
PS1, Line 40: 	byte = 0; /* preclear */
> You mean the assignment in the next line might fail? wouldn't that violate C?
I was thinking more in the sense of a HW failure... butt that would probably be caught by EMMC_STATUS_INVALID_ADDR. Will remove.


https://review.coreboot.org/#/c/30225/1/src/drivers/emmc/emmc_rom.c@43 
PS1, Line 43: 		pinfo->status = EMMC_CONFIRMED_RESET_ACCEPTED;
> Can you point me to documentation / a datasheet where this behaviour […]
It's not a public datasheet. And it's the reason why this code is being implemented... depthcharge can't do anything until the bit is cleared. So that depthcharge don't have to wait.


https://review.coreboot.org/#/c/30225/1/src/include/device/emmc.h 
File src/include/device/emmc.h:

https://review.coreboot.org/#/c/30225/1/src/include/device/emmc.h@23 
PS1, Line 23: #define EMMC_RESET_COMPLETED		4
> AFAICS, all you need to do in coreboot is to set EMMC_RESET_ALL and notify […]
Ok, I started of from a wrong idea... I'll only send the reset and have payload check it.


https://review.coreboot.org/#/c/30225/1/src/include/device/emmc.h@51 
PS1, Line 51:  */
> Why should other code use the same cbmem id? It seems to me you are extending […]
Basically because Intel was already defining (though not yet merged) the same cbmemid and I thought it would be wrong to have 2 cbmemid for the same purpose. As I did not know what Intel is planing it to, I created a method to differentiate between Intel's one and mine. Intel's code is going after sending CMD0 and CMD1, so it's cbmem use will probably be different.



-- 
To view, visit https://review.coreboot.org/c/coreboot/+/30225
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings

Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4bb55fde23e3b70da1cca76e5672e880317b8bd2
Gerrit-Change-Number: 30225
Gerrit-PatchSet: 3
Gerrit-Owner: Richard Spiegel <richard.spiegel at silverbackltd.com>
Gerrit-Reviewer: Daniel Kurtz <djkurtz at google.com>
Gerrit-Reviewer: Martin Roth <martinroth at google.com>
Gerrit-Reviewer: Patrick Georgi <pgeorgi at google.com>
Gerrit-Reviewer: Patrick Rudolph <siro at das-labor.org>
Gerrit-Reviewer: Raul Rangel <rrangel at chromium.org>
Gerrit-Reviewer: Richard Spiegel <richard.spiegel at silverbackltd.com>
Gerrit-Reviewer: Simon Glass <sjg at chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply at coreboot.org>
Gerrit-CC: Nico Huber <nico.h at gmx.de>
Gerrit-Comment-Date: Tue, 18 Dec 2018 18:10:13 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Richard Spiegel <richard.spiegel at silverbackltd.com>
Comment-In-Reply-To: Nico Huber <nico.h at gmx.de>
Comment-In-Reply-To: Martin Roth <martinroth at google.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot-gerrit/attachments/20181218/10b27ee4/attachment.html>