Hi, > -----Original Message----- > From: Quentin Schulz <quentin.sch...@theobroma-systems.com> > Sent: Wednesday, April 10, 2024 12:27 AM > To: Jonas Karlman <jo...@kwiboo.se>; Peng Fan <peng....@nxp.com>; Jaehoon > Chung > <jh80.ch...@samsung.com>; Tom Rini <tr...@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.sch...@theobrma-systems.com> Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com> Best Regards, Jaehoon Chung > > Cheers, > Quentin
