Messages in this thread | | | Date | Fri, 1 Jul 2022 18:36:48 -0400 | From | Nícolas F. R. A. Prado <> | Subject | Re: [PATCH 05/11] arm64: dts: mediatek: cherry: Add support for internal eMMC storage |
| |
On Thu, Jun 30, 2022 at 05:33:10PM +0200, AngeloGioacchino Del Regno wrote: > Add mtk-sd controller and pin configuration to enable the internal > eMMC storage: now it is possible to mount a rootfs located at the > internal storage. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../boot/dts/mediatek/mt8195-cherry.dtsi | 87 +++++++++++++++++++ > 1 file changed, 87 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > index 091338f7d5ff..8c4b492f774f 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi > @@ -9,6 +9,7 @@ > > / { > aliases { > + mmc0 = &mmc0;
There was this discussion about adding aliases on dtsi's or not [1]. The case in favor of adding them in the dtsi seemed stronger, but it wasn't conclusive... Anyway, I guess it's fine.
[1] https://lore.kernel.org/all/CAD=FV=Wi9xTnWTPbakSnf9rKkiT+4AT=3db-uwhww1bdLKjv9g@mail.gmail.com/
> serial0 = &uart0; > }; [..] > +&pio { > + mmc0_pins_default: mmc0-default-pins { > + pins-cmd-dat { > + pinmux = <PINMUX_GPIO126__FUNC_MSDC0_DAT0>, > + <PINMUX_GPIO125__FUNC_MSDC0_DAT1>, > + <PINMUX_GPIO124__FUNC_MSDC0_DAT2>, > + <PINMUX_GPIO123__FUNC_MSDC0_DAT3>, > + <PINMUX_GPIO119__FUNC_MSDC0_DAT4>, > + <PINMUX_GPIO118__FUNC_MSDC0_DAT5>, > + <PINMUX_GPIO117__FUNC_MSDC0_DAT6>, > + <PINMUX_GPIO116__FUNC_MSDC0_DAT7>, > + <PINMUX_GPIO121__FUNC_MSDC0_CMD>; > + input-enable; > + drive-strength = <MTK_DRIVE_6mA>;
These MTK_DRIVE_*mA macros map directly to the values, and the drive-strength property is already standard and defined to take values in mA, so it's better to use the value directly:
drive-strength = <6>;
(Likewise below and in some other patches)
Otherwise,
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Thanks, Nícolas
| |