On 17 March 2015 at 16:08, Mark Rutland mark.rutland@arm.com wrote:
On Tue, Mar 17, 2015 at 02:20:48PM +0000, Jorge Ramirez-Ortiz wrote:
On 03/17/2015 09:34 AM, Mark Rutland wrote:
On Tue, Mar 17, 2015 at 08:59:10AM +0000, Haojian Zhuang wrote:
If mmc controler is accessed in bootloader, it's required to execute disable boot before resetting the controller & enabling the clock in kernel driver.
Signed-off-by: Haojian Zhuang haojian.zhuang@linaro.org
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 7 +++++ drivers/mmc/host/dw_mmc-k3.c | 33 ++++++++++++++++++++++ drivers/mmc/host/dw_mmc.h | 1 + 3 files changed, 41 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index 3b35449..cf12cfa 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -14,6 +14,13 @@ Required Properties:
- compatible: should be one of the following.
- "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
+Optional Properties:
+* "hisilicon,disable-boot"
- Disable boot before reseting mmc controller and enabling clocks. It's
- required on Hisilicon Hi6220 SoC if the mmc controller is accessed in
- bootloader.
I don't follow. Why do we need another property?
What exactly does this cause to happen at the MMC controller prior to the reset, why exactly is this necessary,
are you asking for documentation about the controller?
I'm asking for the semantics associated with this property rather than for a full TRM.
Realistically what I'd like to know is why this is necessary prior to the reset of the controller mentioned in the property description. From the sounds of things we're not actually resetting the controller.
I also suspect that "disable boot" is a misnomer both in the proeprty and code.
and why can we not always do this regardless?
+1
That patch looks like we're poking the device prior to resetting it, which seems completely backwards.
yes, some background info can be found here https://github.com/96boards/bugs/issues/19
it seems that UEFI accesses during boot might have left the device in an unsuitable state for the kernel. this commit aims at correcting that.
It would be nice to know what that state is.
There's code elsewhere in the hikey kernel to poke at dwmmc reset: https://github.com/96boards/linux/commit/6d790cc68afd5f65eb6ab4f20e635158d3c...
That writel() is needed to make the disable-boot patches work.