Hi Ulf,
On 26/05/14 22:38, Srinivas Kandagatla wrote:
2 files changed, 28 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 17e7f6a..6434f5b1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -185,6 +185,10 @@ static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
+ .clkreg_enable = MCI_QCOM_CLK_FLOWENA |
+ MCI_QCOM_CLK_FEEDBACK_CLK,
Obviously I don't have the in-depth knowledge about the Qcom variant,
but comparing the ST variant here made me think.
Using the feeback clock internal logic in the ST variant, requires the
corresponding feedback clock pin signal on the board, to be
routed/connected. Typically we used this for SD cards, which involved
using an external level shifter circuit.
Is it correct to enable this bit for all cases, including eMMC?
You are correct, FBCLK should specific to the board, and I will try to
do something on the same lines as ST variant in next version.
I get lot of I/O errors when I remove this flag for test.
I rechecked schematics and datasheet, the feedback clk that we refer
here is the the feedback clk from CLK pad, there is no separate input
pad for fbclk. So I think this is internally feedbacked clk.
This selection is configuring bits to latch data and command coming in
using feedback clock from CLK pad.
I will make sure that the macro is named more appropriately to reflect
the same.
thanks,
srini
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
