All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions
Date: Tue, 11 Jun 2019 12:04:04 +0200	[thread overview]
Message-ID: <722b00d2-f1d2-3382-9e6c-41d1e4aa5f20@gmail.com> (raw)
In-Reply-To: <39df182a-dbc8-b688-fa5a-43907bffc5a3@ti.com>

On 6/11/19 10:12 AM, Faiz Abbas wrote:
> Peng, Marek,
> 
> On 11/06/19 6:47 AM, Peng Fan wrote:
>>> partitions
>>>
>>> On 6/10/19 7:59 AM, Peng Fan wrote:
>>>>> Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing
>>>>> boot partitions
>>>>>
>>>>> Hi Marek, Peng,
>>>>>
>>>>> On 03/06/19 12:04 PM, Peng Fan wrote:
>>>>>>
>>>>>>> Subject: [PATCH] mmc: Avoid HS400 mode when accessing boot
>>>>>>> partitions
>>>>>>>
>>>>>>> According to JEDEC JESD84-B51.pdf section 6.3.3 Boot operation ,
>>>>>>> HS200 & HS400 mode is not supported during boot operation. The
>>>>>>> U-Boot code currently only applies this restriction to HS200 mode,
>>>>>>> extend this to
>>>>>>> HS400 mode as well.
>>>>> The spec in section 6.3.3 (according to my understanding) is talking
>>>>> about "boot operation" which is a way of getting data from the the
>>>>> eMMC without going through the Device identification mode (Section
>>>>> 6.4.4) i.e. without sending any commands. All the host has to do is
>>>>> hold the command line low in Pre-Idle mode to automatically receive
>>>>> data at the preconfigured frequency and bus width.
>>>>>
>>>>> When U-boot is accessing the partition, it has already gone through
>>>>> the Device identification mode and is in data transfer mode (i.e. it
>>>>> needs to send commands for read/write to happen). In this case, we
>>>>> need to switch the partition in Extended CSD to access the boot
>>>>> partition (Section 6.2.5). The spec doesn't say anything about HS200 and
>>> HS400 not being supported here.
>>>>
>>>> Yes, the spec does not mention this. It only mentions HS200/400 not
>>>> supported during boot operation.
>>>>
>>>>>
>>>>> Also, I don't see linux kernel switching down speed when trying to
>>>>> access a boot partition (unless its being very sneaky about it). So
>>>>> if you are seeing issues with accessing boot partitions at
>>>>> HS200/HS400 then you should probably look at how linux code is working
>>> instead.
>>>>
>>>> There might be bug in U-Boot code.
>>>
>>> So are we gonna leave this inconsistency in for current release or what's it
>>> gonna be ? Like I said, we're in rc3, it's fine to do bigger changes in next
>>> release, but we should at least fix this in current release.
>>
>> I'll pick up your patch in this release.
>>
> 
> The issue that Marek is facing is not a regression, is it? Are we really
> going to merge something that we know to be wrong just so we are
> consistently wrong?

First of all, you established this is "wrong" without any real backing
except for your interpretation of the specification. I would still like
to hear from Jean the real reason why he added this filtering in the
first place.

That said, we're in rc4 , the release is just around the corner. I would
like to avoid big changes in the MMC subsystem , or any subsystem for
that matter. That's for next release , and if you have a patch for next,
please post it, I am happy to test it on the hardware I have available.

Also note that this patch does not have any impact on general use case,
the regular bulk of the eMMC can be accessed at HS200/HS400, it's just
the boot partitions which are accessed in HS52 or lower.

However, right now, the behavior is not consistent between HS200 and
HS400 modes, and I would very much like to have it consistent in the
upcoming release.

> Marek, I understand you do not want to debug this right now but this
> patch will 1) Mislead people into thinking that we know what we are
> doing (two patches went in with pretty confident patch descriptions) and
> 2) Mask issues for people who could take the time to help debug this.

Wrong, I want to debug this, I just don't want to do big changes in the
upcoming release this late in the release cycle. But if you propose a
patch for next, I am happy to test it on the hardware I have available.
Can you send such a patch ?

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2019-06-11 10:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31 13:22 [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions Marek Vasut
2019-06-03  6:34 ` Peng Fan
2019-06-04 11:22   ` Faiz Abbas
2019-06-04 13:26     ` Marek Vasut
2019-06-04 13:34       ` Faiz Abbas
2019-06-04 13:38         ` Marek Vasut
2019-06-07  7:53           ` Faiz Abbas
2019-06-07 19:05             ` Marek Vasut
2019-06-10  5:59     ` Peng Fan
2019-06-10 11:33       ` Marek Vasut
2019-06-11  1:17         ` Peng Fan
2019-06-11  3:01           ` Marek Vasut
2019-06-11  8:12           ` Faiz Abbas
2019-06-11 10:04             ` Marek Vasut [this message]
2019-06-11 15:59               ` Faiz Abbas
2019-06-14 15:27                 ` Jean-Jacques Hiblot
2019-06-15 15:15                   ` Marek Vasut
2019-06-17  9:09                     ` Jean-Jacques Hiblot
2019-06-17 10:34                       ` Marek Vasut
2019-06-17 14:46                         ` Jean-Jacques Hiblot
2019-06-17 15:47                           ` Marek Vasut
2019-06-18  5:03                             ` Peng Fan
2019-06-18  6:35                               ` Faiz Abbas
2019-06-19  5:42                                 ` Peng Fan
2019-06-18 10:55                               ` Marek Vasut
2019-06-18 14:38                               ` Jean-Jacques Hiblot
2019-06-15 15:12                 ` Marek Vasut
2019-06-11 15:25         ` Jean-Jacques Hiblot
2019-06-11 20:51           ` Marek Vasut

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=722b00d2-f1d2-3382-9e6c-41d1e4aa5f20@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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.