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. I've been bitten by loaders leaving devices on with DMA active, and it would be nice to know that something like that isn't the case here -- it can be tricky to detect until it's too late.
I was under the impression that UEFI drivers were meant to leave devices in some quiescent state. Sepending on the precise state the HW is left it, this may still be a UEFI bug regardless of whether it's possible for the kernel to fix things up, and if that's the case we should fix the UEFI port regardless of whether we also modify the kernel to handle that state.
Mark.