| Message ID | 1540996688-23681-10-git-send-email-aisheng.dong@nxp.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ARM: imx: add imx7ulp support | expand |
Hi Dong, On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> wrote: > + reg_vsd_3v3: regulator-vsd-3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "VSD_3V3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_usdhc0_rst>; > + gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>; > + enable-active-high; You model this as a regulator... > +&usdhc0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_usdhc0>; > + cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>; > + vmmc-supply = <®_vsd_3v3>; but as this pins controls the reset of the SD port it seems that using mmc-pwrseq would be more appropriate. This way you could pass 'reset-gpios' inside the pwrseq node, which would describe the hardware more accurately.
On Thu, Nov 1, 2018 at 7:28 AM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Dong, > > On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> wrote: > > > + reg_vsd_3v3: regulator-vsd-3v3 { > > + compatible = "regulator-fixed"; > > + regulator-name = "VSD_3V3"; > > + regulator-min-microvolt = <3300000>; > > + regulator-max-microvolt = <3300000>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_usdhc0_rst>; > > + gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>; > > + enable-active-high; > > You model this as a regulator... > > > +&usdhc0 { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_usdhc0>; > > + cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>; > > + vmmc-supply = <®_vsd_3v3>; > > but as this pins controls the reset of the SD port it seems that using > mmc-pwrseq would be more appropriate. > > This way you could pass 'reset-gpios' inside the pwrseq node, which > would describe the hardware more accurately. Just looked at the schematics and the SD0_nRST signals is only used when the eMMC is populated. As you are only defining SD0_DATA0-DATA3 it means you are using the microSD option (option 1 as per the schematics). In the microSD option the SD0_nRST is not used, so better not to describe it in device tree.
> -----Original Message----- > From: Fabio Estevam [mailto:festevam@gmail.com] > Sent: Thursday, November 1, 2018 6:28 PM [...] > Hi Dong, > > On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> > wrote: > > > + reg_vsd_3v3: regulator-vsd-3v3 { > > + compatible = "regulator-fixed"; > > + regulator-name = "VSD_3V3"; > > + regulator-min-microvolt = <3300000>; > > + regulator-max-microvolt = <3300000>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_usdhc0_rst>; > > + gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>; > > + enable-active-high; > > You model this as a regulator... > > > +&usdhc0 { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_usdhc0>; > > + cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>; > > + vmmc-supply = <®_vsd_3v3>; > > but as this pins controls the reset of the SD port it seems that using > mmc-pwrseq would be more appropriate. > > This way you could pass 'reset-gpios' inside the pwrseq node, which would > describe the hardware more accurately. This seems a bit confusing to me. That GPIO is used to control the SD card power on/off. So it's naturally a GPIO regulator. Looking at exist IMX dts, you will find all similar board doing like this. Pwrseq seems more like to be used for WiFi/eMMC card. Am I missed something? Regards Dong Aisheg
> -----Original Message----- > From: Fabio Estevam [mailto:festevam@gmail.com] > Sent: Thursday, November 1, 2018 6:36 PM [...] > > On Thu, Nov 1, 2018 at 7:28 AM Fabio Estevam <festevam@gmail.com> > wrote: > > > > Hi Dong, > > > > On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> > wrote: > > > > > + reg_vsd_3v3: regulator-vsd-3v3 { > > > + compatible = "regulator-fixed"; > > > + regulator-name = "VSD_3V3"; > > > + regulator-min-microvolt = <3300000>; > > > + regulator-max-microvolt = <3300000>; > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&pinctrl_usdhc0_rst>; > > > + gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>; > > > + enable-active-high; > > > > You model this as a regulator... > > > > > +&usdhc0 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&pinctrl_usdhc0>; > > > + cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>; > > > + vmmc-supply = <®_vsd_3v3>; > > > > but as this pins controls the reset of the SD port it seems that using > > mmc-pwrseq would be more appropriate. > > > > This way you could pass 'reset-gpios' inside the pwrseq node, which > > would describe the hardware more accurately. > > Just looked at the schematics and the SD0_nRST signals is only used when the > eMMC is populated. > > As you are only defining SD0_DATA0-DATA3 it means you are using the > microSD option (option 1 as per the schematics). > > In the microSD option the SD0_nRST is not used, so better not to describe it in > device tree. Can you tell which version were you looking at? From my version SPF-29163_A1, it's populated by default. Regards Dong Aisheng
On Thu, Nov 1, 2018 at 12:49 PM A.s. Dong <aisheng.dong@nxp.com> wrote: > This seems a bit confusing to me. > That GPIO is used to control the SD card power on/off. So it's naturally a > GPIO regulator. Looking at exist IMX dts, you will find all similar board doing > like this. Pwrseq seems more like to be used for WiFi/eMMC card. > Am I missed something? As per the board schematics the name of the signal is SD0_nRST, where RST means "reset". There is even this note in the schematics: "ROM Code will reset the SD power during boot up through SD_RST". eMMC reset is better handled by 'reset-gpios' property from pwrseq.
On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com> wrote: > Can you tell which version were you looking at? > From my version SPF-29163_A1, it's populated by default. Mine is sch-29163-b and it shows both micro SD card and eMMC on the schematics. On my board I see only the micro SD card populated, not the eMMC. Also, if you are describing the eMMC then why do you pass the card detect property and only 4 data lines? SD0_nRST is only connected to the eMMC card. eMMC does not have card detect signal and it uses 8 data lines, so clearly there is something inconsistent in your dts. What exactly do you want to describe: the SD card or the eMMC?
> -----Original Message----- > From: Fabio Estevam [mailto:festevam@gmail.com] > Sent: Thursday, November 1, 2018 11:57 PM [...] > > On Thu, Nov 1, 2018 at 12:49 PM A.s. Dong <aisheng.dong@nxp.com> wrote: > > > This seems a bit confusing to me. > > That GPIO is used to control the SD card power on/off. So it's > > naturally a GPIO regulator. Looking at exist IMX dts, you will find > > all similar board doing like this. Pwrseq seems more like to be used for > WiFi/eMMC card. > > Am I missed something? > > As per the board schematics the name of the signal is SD0_nRST, where RST > means "reset". > I guess you may also notice that circuit name above that signal is " Power Switch for SD3.0". > There is even this note in the schematics: "ROM Code will reset the SD power > during boot up through SD_RST". > Yes, but it's more like a RESET. > eMMC reset is better handled by 'reset-gpios' property from pwrseq. It's not eMMC. Let's see more in binding doc: Required properties: - compatible : contains "mmc-pwrseq-simple". Optional properties: - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted at initialization and prior we start the power up procedure of the card. They will be de-asserted right after the power has been provided to the card. That looks more like an auxiliary GPIO reset pin which is used along with normal power up process (see. mmc_power_up ()) which may be commonly used for WiFi cards. But for SD card with a single supply, GPIO regulator seems enough to me. That's also the using in past years. Are things changed? Regards Dong Aisheng
> -----Original Message----- > From: Fabio Estevam [mailto:festevam@gmail.com] > Sent: Friday, November 2, 2018 12:01 AM [...] > > On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com> wrote: > > > Can you tell which version were you looking at? > > From my version SPF-29163_A1, it's populated by default. > > Mine is sch-29163-b and it shows both micro SD card and eMMC on the > schematics. > I will check it later. But Rev B may be supported later if changed. > On my board I see only the micro SD card populated, not the eMMC. > > Also, if you are describing the eMMC then why do you pass the card detect > property and only 4 data lines? > > SD0_nRST is only connected to the eMMC card. > > eMMC does not have card detect signal and it uses 8 data lines, so clearly > there is something inconsistent in your dts. > > What exactly do you want to describe: the SD card or the eMMC? I guess we're talking about different schematic versions. The patch is supposed to support Rev A. Regards Dong Aisheng
[...] > > -----Original Message----- > > From: Fabio Estevam [mailto:festevam@gmail.com] > > Sent: Friday, November 2, 2018 12:01 AM > [...] > > > > On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com> > wrote: > > > > > Can you tell which version were you looking at? > > > From my version SPF-29163_A1, it's populated by default. > > > > Mine is sch-29163-b and it shows both micro SD card and eMMC on the > > schematics. > > > > I will check it later. But Rev B may be supported later if changed. > > > On my board I see only the micro SD card populated, not the eMMC. > > > > Also, if you are describing the eMMC then why do you pass the card > > detect property and only 4 data lines? > > > > SD0_nRST is only connected to the eMMC card. > > > > eMMC does not have card detect signal and it uses 8 data lines, so > > clearly there is something inconsistent in your dts. > > > > What exactly do you want to describe: the SD card or the eMMC? > > I guess we're talking about different schematic versions. > The patch is supposed to support Rev A. > I just checked RevB schematic and SD card circuit seems the same as Rev A that SD0_nRST is used to control the SD power and there's CD pin. So the SD binding should work for both. Regards Dong Aisheng
On Thu, Nov 1, 2018 at 1:21 PM A.s. Dong <aisheng.dong@nxp.com> wrote: > But for SD card with a single supply, GPIO regulator seems enough to me. > That's also the using in past years. Are things changed? Ok, now it clear you are describing the micro SD port and not the eMMC, so: Reviewed-by: Fabio Estevam <festevam@gmail.com>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index d7268ae..39eac9c 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -573,6 +573,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \ imx7d-sdb-sht11.dtb \ imx7s-colibri-eval-v3.dtb \ imx7s-warp.dtb +dtb-$(CONFIG_SOC_IMX7ULP) += \ + imx7ulp-evk.dtb dtb-$(CONFIG_SOC_LS1021A) += \ ls1021a-moxa-uc-8410a.dtb \ ls1021a-qds.dtb \ diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts b/arch/arm/boot/dts/imx7ulp-evk.dts new file mode 100644 index 0000000..07796f3 --- /dev/null +++ b/arch/arm/boot/dts/imx7ulp-evk.dts @@ -0,0 +1,77 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2016 Freescale Semiconductor, Inc. + * Copyright 2017-2018 NXP + * Dong Aisheng <aisheng.dong@nxp.com> + */ + +/dts-v1/; + +#include "imx7ulp.dtsi" + +/ { + model = "NXP i.MX7ULP EVK"; + compatible = "fsl,imx7ulp-evk", "fsl,imx7ulp"; + + chosen { + stdout-path = &lpuart4; + }; + + memory@60000000 { + device_type = "memory"; + reg = <0x60000000 0x40000000>; + }; + + reg_vsd_3v3: regulator-vsd-3v3 { + compatible = "regulator-fixed"; + regulator-name = "VSD_3V3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc0_rst>; + gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; +}; + +&lpuart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_lpuart4>; + status = "okay"; +}; + +&usdhc0 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc0>; + cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>; + vmmc-supply = <®_vsd_3v3>; + status = "okay"; +}; + +&iomuxc1 { + pinctrl_lpuart4: lpuart4grp { + fsl,pins = < + IMX7ULP_PAD_PTC3__LPUART4_RX 0x1 + IMX7ULP_PAD_PTC2__LPUART4_TX 0x1 + >; + bias-pull-up; + }; + + pinctrl_usdhc0: usdhc0grp { + fsl,pins = < + IMX7ULP_PAD_PTD1__SDHC0_CMD 0x41 + IMX7ULP_PAD_PTD2__SDHC0_CLK 0x40 + IMX7ULP_PAD_PTD7__SDHC0_D3 0x41 + IMX7ULP_PAD_PTD8__SDHC0_D2 0x41 + IMX7ULP_PAD_PTD9__SDHC0_D1 0x41 + IMX7ULP_PAD_PTD10__SDHC0_D0 0x41 + IMX7ULP_PAD_PTC10__PTC10 0x1 /* CD */ + >; + }; + + pinctrl_usdhc0_rst: usdhc0-gpio-rst-grp { + fsl,pins = < + IMX7ULP_PAD_PTD0__PTD0 0x1 + >; + }; +};
The NXP i.MX 7ULP Evaluation Kit (EVK) provides a platform for rapid evaluation of the i.MX 7ULP, which features NXP's advanced implementation of the Arm Cortex-A7 core, the Arm Cortex-M4 core, as well as a 3D and 2D Graphics Processing Units (GPUs). The EVK enables HDMI output for simple out-of-the-box to bring up but allows reconfiguration for MIPI displays. The EVK is designed as a System-On-Module(SOM) board that connects to an associated baseboard. The SOM provides 1 GB LPDDR3, 8 MB Quad SPI flash, Micro SD 3.0 card socket, WiFi/ Bluetooth capability, USB 2.0 OTG with Type C connector and an NXP PF1550 power management IC (PMIC). The baseboard provides additional capabilities including a full SD/MMC 3.0 card socket, audio codec, multiple sensors, an HDMI connector, and an alternate MIPI display connector. Additionally, the EVK facilitates software development with the ultimate goal of faster time to market through the support of both Linux OS and AndroidTM rich operating systems, as well as FreeRTOS. This patch aims to support the preliminary booting up features as follows: GPIO LPUART FEC SD/MMC See more board details: https://www.nxp.com/products/processors-and-microcontrollers/ arm-based-processors-and-mcus/i.mx-applications-processors/ i.mx-7-processors/evaluation-kit-for-the-i.mx-7ulp-applications -processor:MCIMX7ULP-EVK Cc: Rob Herring <robh+dt@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: devicetree@vger.kernel.org Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> --- ChangeLog: v2->v3: * remove "Generic DT based system" * add device_type property for memory node * back to old pinctrl binding according to SoC maintainer's suggestions v1->v2: * switch to SPDX license * pad name update * fix Character '_' not recommended in node name * separate from soc.dtsi file --- arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/imx7ulp-evk.dts | 77 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+) create mode 100644 arch/arm/boot/dts/imx7ulp-evk.dts