All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jaehoon Chung" <jh80.chung@samsung.com>
To: "'Quentin Schulz'" <quentin.schulz@theobroma-systems.com>,
	"'Jonas Karlman'" <jonas@kwiboo.se>,
	"'Peng Fan'" <peng.fan@nxp.com>,
	"'Tom Rini'" <trini@konsulko.com>
Cc: <u-boot@lists.denx.de>
Subject: RE: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Date: Wed, 17 Apr 2024 08:23:54 +0900	[thread overview]
Message-ID: <000801da9055$2641fe50$72c5faf0$@samsung.com> (raw)
In-Reply-To: <496013c1-7a57-4d12-bf31-c5257f35ee8c@theobroma-systems.com>

Hi,

> -----Original Message-----
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> Sent: Wednesday, April 10, 2024 12:27 AM
> To: Jonas Karlman <jonas@kwiboo.se>; Peng Fan <peng.fan@nxp.com>; Jaehoon Chung
> <jh80.chung@samsung.com>; Tom Rini <trini@konsulko.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
> 
> Hi Jonas,
> 
> On 4/8/24 23:06, Jonas Karlman wrote:
> > eMMC nodes in linux device tree files typically only contain a mmc-hs400
> > prop to signal support for both HS400 and HS200. However, U-Boot require
> > an explicit mmc-hs200 prop to signal support for the HS200 mode.
> >  > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled
> > using a mmc-hs400 prop.
> >
> 
> Technically speaking, the DT binding should be the one and only source
> of truth and should be implementation-agnostic.
> 
> There it says:
> """
>    mmc-hs400-1_2v:
>      $ref: /schemas/types.yaml#/definitions/flag
>      description:
>        eMMC HS400 mode (1.2V I/O) is supported.
> 
>    mmc-hs400-1_8v:
>      $ref: /schemas/types.yaml#/definitions/flag
>      description:
>        eMMC HS400 mode (1.8V I/O) is supported.
> """
> 
> So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it
> makes sense.
> 
> The point of the DT/DT binding is to be system-agnostic and
> representative of the **HW** implementation. At least that's what the DT
> people want it to be.
> 
> If the eMMC standard doesn't allow to have HS400 without HS200, then I
> think this change is acceptable as is, because it is the reality of the
> HW standard. Couldn't find this implied in the standard though (but I
> just skimmed through).
> 
> It's also quite surprising, as it's not because the eMMC works with
> HS400 that it necessarily does with HS200 or that it's desired (EMI,
> signal integrity/stability, etc...)?
> 
> Now, it wouldn't be the first time U-Boot follows whatever is done in
> Linux, so... up to you/the maintainers :)

I want to follow the linux kernel. 

> 
> Reviewed-by: Quentin Schulz <quentin.schulz@theobrma-systems.com>

Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

Best Regards,
Jaehoon Chung

> 
> Cheers,
> Quentin


      parent reply	other threads:[~2024-04-16 23:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 21:06 [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux Jonas Karlman
2024-04-08 21:06 ` [PATCH 2/2] mmc: Add support for the no-mmc-hs400 prop Jonas Karlman
2024-04-08 21:17   ` Dragan Simic
2024-04-16 23:34   ` Jaehoon Chung
2024-04-08 21:17 ` [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux Dragan Simic
2024-04-09 15:27 ` Quentin Schulz
2024-04-09 15:58   ` Jonas Karlman
2024-04-09 16:02     ` Quentin Schulz
2024-04-09 16:30       ` Jonas Karlman
2024-04-09 19:30         ` Dragan Simic
2024-04-10  8:47           ` Quentin Schulz
2024-04-10  9:24             ` Dragan Simic
2024-04-09 19:28       ` Dragan Simic
2024-04-10  8:56         ` Quentin Schulz
2024-04-10  9:22           ` Dragan Simic
2024-04-16 23:33           ` Jaehoon Chung
2024-04-17  1:28             ` Dragan Simic
2024-04-16 23:23   ` Jaehoon Chung [this message]

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='000801da9055$2641fe50$72c5faf0$@samsung.com' \
    --to=jh80.chung@samsung.com \
    --cc=jonas@kwiboo.se \
    --cc=peng.fan@nxp.com \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=trini@konsulko.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.