All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	Chris Ball <chris@printf.net>,
	linux-mmc <linux-mmc@vger.kernel.org>
Subject: Help needed: Enabling HPI causes some eMMC devices to stop working
Date: Wed, 18 Feb 2015 20:15:11 +0100	[thread overview]
Message-ID: <54E4E4BF.3090507@redhat.com> (raw)

Hi,

As part of the Linux Allwinner SoC support work I do in my
spare time, I'm working on getting stock Linux running on
the Utoo P66 Allwinner A13 based tablet.

This tablet is interesting because it uses an eMMC rather then
raw nand as is typically seen on Allwinner tablets.

It has taken me a while to get the kernel to talk to the eMMC,
in the end the following hack does the trick:


From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 18 Feb 2015 20:04:03 +0100
Subject: [PATCH] mmc: HACK: disable HPI

HACK: trying to enable HPI breaks EMMC access on the Utoo P66 tablet I'm
trying to get supported, so disable it. FIXME: come up with a proper fix.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
  drivers/mmc/core/mmc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 1d41e85..b343587 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1418,7 +1418,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
         /*
          * Enable HPI feature (if supported)
          */
-       if (card->ext_csd.hpi) {
+       if (0 && card->ext_csd.hpi) {
                 err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
                                 EXT_CSD_HPI_MGMT, 1,
                                 card->ext_csd.generic_cmd6_time);

This patch has one good thing going for it, which it is that it makes
the eMMC work, without this talking to the eMMC fails as soon as the
kernel tries to read the partition table, with response-timeout errors
when doing a mmc command 18 to read sector 0.

So this is as far as I've come, and beyond this my mmc knowledge is simply
not good enough. Could this be a controller specific problem ? IOW do
we need a controller flag to not enable HPi, like we've
MMC_CAP2_BOOTPART_NOACC ? Or is this likely more something specific to the eMMC
used.

Assuming for now it is something specific to the eMMC used, how do we fix this?

Is there maybe some way to figure out that enabling HPI is not a good idea on
this eMMC?

Or do we need a quirk for this in devicetree? Now a days we can tie info to an sdio
slave device in devicetree, so that is an option too.

Thanks & Regards,

Hans

             reply	other threads:[~2015-02-18 19:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18 19:15 Hans de Goede [this message]
2015-02-25 11:44 ` Help needed: Enabling HPI causes some eMMC devices to stop working Jaehoon Chung
2015-02-25 14:41   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E4E4BF.3090507@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=chris@printf.net \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.