From: Tim Schumacher <tim@timakro.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
pher1989@hotmail.com
Subject: Re: Black screen while resuming a SDXC (UHS) card (_mmc_sd_resume)
Date: Thu, 23 Jan 2020 11:40:47 +0100 [thread overview]
Message-ID: <20200123104047.GA1254@impa> (raw)
In-Reply-To: <CAPDyKFqo-LecRE5R4T+vrGgNs83WFmQr84oaieEUTCjLFOLXoA@mail.gmail.com>
On 2019-09-06, Ulf Hansson wrote:
> On Thu, 5 Sep 2019 at 22:01, Tim Schumacher <tim@timakro.de> wrote:
> >
> > Hi,
> >
> > I'm sending this old bug by mail since a lot of developers don't use
> > bugzilla.
> >
> > Original bug report on bugzilla by Pedro Rodrigues from 2019-01-30:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=202459
> >
> > > This bug can be found on a Lenovo Miix 320-10ICR
> > >
> > > When using a SDXC (UHS) card, the screen becomes black if
> > > _mmc_sd_resume() is called. After some investigation, I found that an
> > > UHS card uses 1.8 V for signalling while a normal SD card uses 3.3 V. By
> > > forcing the SDXC to use 3.3 V the black screen does not appear. It seems
> > > that during a _mmc_sd_resume function call, while claiming the host, an
> > > I2C resume function is called based on an existing supplier link between
> > > the I2C bus and the card device. The problem is that if the signalling
> > > voltage is configured to 1.8 V, during the I2C resume call, the screen
> > > turns black. I was able to fix this issue by setting the initial signal
> > > voltage (3.3 V) before suspending the card, so that when the card is
> > > resumed, the voltage is in the original state. To do this I added a
> > > function call to mmc_set_initial_signal_voltage() during mmc_power_off
> > > routine (drivers/mmc/core/core.c). As I’m not an expert on Linux, I’m
> > > posting the issue and possible solution so that it could be implemented
> > > on a future release.
> > >
> > > Please, share your thoughts :)
> >
> > I can't provide further insight but I'm interested if this is possibly
> > the cause for the general issues people are having with the SD card
> > reader on Lenovo Miix 320 devices.
> >
> > Those issues described in posts like
> >
> > https://vincent-ventures.com/2018/12/arch-linux-on-lenovo-ideapad-miix-320/
> > https://esc.sh/blog/linux-on-lenovo-miix-320/
> >
> > are (1) black screen when booting with an SD card installed and (2) when
> > inserting an SD card after booting it shows up but upon trying to access
> > it the screen turns black until the card is removed again.
> >
> > I can confirm (1) on my Lenovo Miix 320-10ICR with kernel version
> > 5.2.11. I can also confirm that only SDXC cards are affected, SD and
> > SDHC cards work as expected.
>
> For the mmc community to help, you need to provide some kernel logs,
> output from lspci, figure out what mmc host driver that is being used,
> etc - in general collect more data. Then re-post the data to
> linux-mmc, me and a potential mmc host driver maintainer (if there is
> one). Yes, we can look into bugzilla as well, but first we need some
> more overall info in an email.
>
> Most likely, if there is any response, you will be asked to test
> patches. So you need to be able build and boot a new kernel, but I
> guess you already know that part.
>
> Kind regards
> Uffe
>
Hi, I'm coming back to this issue now. The issue is still present in
kernel version 5.4.8.
Kernel logs from boot with SD card and black screen: https://termbin.com/outp
Kernel logs from boot without SD card: https://termbin.com/dc2y
I couldn't find anything conspicuous in there, the card is working as
expected. Only issue is the black screen (I'm doing these tests via SSH).
lspci output: https://termbin.com/x452
How do I figure out which mmc host driver is in use? I assume I'm
looking for one of these https://github.com/torvalds/linux/tree/master/drivers/mmc/host
I couldn't find anything like it in the kernel logs or from lsmod.
Please read the original bug report by Pedro Rodrigues quoted above.
He got to the technical core of the problem already and proposed a fix
I assume could be understood, sanity checked and implemented by a mmc
maintainer.
Regards
Tim
next parent reply other threads:[~2020-01-23 10:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190905200138.GA19037@impa.localdomain>
[not found] ` <CAPDyKFqo-LecRE5R4T+vrGgNs83WFmQr84oaieEUTCjLFOLXoA@mail.gmail.com>
2020-01-23 10:40 ` Tim Schumacher [this message]
2020-01-27 11:37 ` Black screen while resuming a SDXC (UHS) card (_mmc_sd_resume) Ulf Hansson
2020-01-27 11:57 ` Adrian Hunter
2020-01-27 14:08 ` 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=20200123104047.GA1254@impa \
--to=tim@timakro.de \
--cc=linux-mmc@vger.kernel.org \
--cc=pher1989@hotmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox