| Message ID | 20211102225701.98944-12-Mr.Bossman075@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add initial support for the i.MXRTxxxx SoC family starting from i.IMXRT1050 SoC. | expand |
Hi Jesse, On 11/2/21 11:56 PM, Jesse Taube wrote: > From: Jesse Taube <mr.bossman075@gmail.com> > > Add support for i.MXRT1050's sdhc. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>--- Here the 3 dashes are missing(---) Best regards
On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > static struct esdhc_soc_data usdhc_imx8qxp_data = { > .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING > @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { > { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, > { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, > { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, > + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, I thought Rob suggested to use the SoC name, so this would be: { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, }, The same applies to the other bindings in the series. This way it would be possible to differentiate between future supported i.MX RT devices.
On 11/2/21 19:17, Fabio Estevam wrote: > On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > >> static struct esdhc_soc_data usdhc_imx8qxp_data = { >> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING >> @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { >> { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, >> { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, >> { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, >> + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, > > I thought Rob suggested to use the SoC name, so this would be: > Uh i think that may have been for the UART. > { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, }, > > The same applies to the other bindings in the series. > > This way it would be possible to differentiate between future > supported i.MX RT devices. > This makes sense will do in V3.
Hi Fabio, Jesse, All, On 11/3/21 12:25 AM, Jesse Taube wrote: > > > On 11/2/21 19:17, Fabio Estevam wrote: >> On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >> >>> static struct esdhc_soc_data usdhc_imx8qxp_data = { >>> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING >>> @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { >>> { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, >>> { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, >>> { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, >>> + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, >> >> I thought Rob suggested to use the SoC name, so this would be: >> > Uh i think that may have been for the UART. >> { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, }, >> >> The same applies to the other bindings in the series. >> >> This way it would be possible to differentiate between future >> supported i.MX RT devices. >> > This makes sense will do in V3. > If we add every SoC we will end up having a long list for every device driver. At the moment it would be 7 parts: 1) imxrt1020 2) imxrt1024 . . . 7) imxrt1170 Is it ok anyway? Best regards
> -----Original Message----- > From: Jesse Taube [mailto:mr.bossman075@gmail.com] > Sent: 2021年11月3日 6:57 > To: dl-linux-imx <linux-imx@nxp.com> > Cc: mturquette@baylibre.com; sboyd@kernel.org; robh+dt@kernel.org; > shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de; > festevam@gmail.com; ulf.hansson@linaro.org; Aisheng Dong > <aisheng.dong@nxp.com>; stefan@agner.ch; linus.walleij@linaro.org; > gregkh@linuxfoundation.org; arnd@arndb.de; olof@lixom.net; > soc@kernel.org; linux@armlinux.org.uk; Abel Vesa <abel.vesa@nxp.com>; > adrian.hunter@intel.com; jirislaby@kernel.org; > giulio.benetti@benettiengineering.com; nobuhiro1.iwamatsu@toshiba.co.jp; > Mr.Bossman075@gmail.com; linux-clk@vger.kernel.org; > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; linux-mmc@vger.kernel.org; > linux-gpio@vger.kernel.org; linux-serial@vger.kernel.org; Jesse Taube > <mr.bossman075@gmail.com> > Subject: [PATCH v2 11/13] mmc: sdhci-esdhc-imx: Add sdhc support for i.MXRT > series > > From: Jesse Taube <mr.bossman075@gmail.com> > > Add support for i.MXRT1050's sdhc. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>--- > V1->V2: > * Nothing done > --- > drivers/mmc/host/sdhci-esdhc-imx.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c > b/drivers/mmc/host/sdhci-esdhc-imx.c > index afaf33707d46..c852a6df5611 100644 > --- a/drivers/mmc/host/sdhci-esdhc-imx.c > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > @@ -305,6 +305,12 @@ static struct esdhc_soc_data usdhc_imx7ulp_data = { > | ESDHC_FLAG_PMQOS | ESDHC_FLAG_HS400 > | ESDHC_FLAG_STATE_LOST_IN_LPMODE, > }; > +static struct esdhc_soc_data usdhc_imxrt_data = { > + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING > + | ESDHC_FLAG_HS200 | ESDHC_FLAG_ERR004536 > + | ESDHC_FLAG_BROKEN_AUTO_CMD23, > +}; > + Hi Jesse, I have few question here. Why only use manual tuning here? Does this usdhc don't support standard tuning? or meet any issue when use standard tuning? Please also double check why not use ADMA in default? Any issue found? Best Regards Haibo Chen > > static struct esdhc_soc_data usdhc_imx8qxp_data = { > .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING @@ -357,6 > +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { > { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, > { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, > { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, > + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, > { .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, }, > { /* sentinel */ } > }; > -- > 2.33.1
Hi Giulio, On Tue, Nov 2, 2021 at 8:30 PM Giulio Benetti <giulio.benetti@benettiengineering.com> wrote: > If we add every SoC we will end up having a long list for every device > driver. At the moment it would be 7 parts: > 1) imxrt1020 > 2) imxrt1024 > . > . > . > 7) imxrt1170 > > Is it ok anyway? As this patch adds the support for imxrt1050, I would go with "fsl,imxrt1050-usdhc" for now.
Hi Fabio, Jesse, Rob, All, On 11/3/21 6:51 PM, Fabio Estevam wrote: > Hi Giulio, > > On Tue, Nov 2, 2021 at 8:30 PM Giulio Benetti > <giulio.benetti@benettiengineering.com> wrote: > >> If we add every SoC we will end up having a long list for every device >> driver. At the moment it would be 7 parts: >> 1) imxrt1020 >> 2) imxrt1024 >> . >> . >> . >> 7) imxrt1170 >> >> Is it ok anyway? > > As this patch adds the support for imxrt1050, I would go with > "fsl,imxrt1050-usdhc" for now. > Ok, then it's the same as pointed by Rob for lpuart[1]; @Jesse: we will do the same for all peripherals(more or less) since it seems there are little differences in the i.MXRT family. [1]: https://lore.kernel.org/lkml/D0A3E11F-FEDE-4B2D-90AB-63DFC245A935@benettiengineering.com/T/ Thanks a lot Best regards
On Wed, Nov 03, 2021 at 12:30:17AM +0100, Giulio Benetti wrote: > Hi Fabio, Jesse, All, > > On 11/3/21 12:25 AM, Jesse Taube wrote: > > > > > > On 11/2/21 19:17, Fabio Estevam wrote: > > > On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > > > > > > > static struct esdhc_soc_data usdhc_imx8qxp_data = { > > > > .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING > > > > @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { > > > > { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, > > > > { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, > > > > { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, > > > > + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, > > > > > > I thought Rob suggested to use the SoC name, so this would be: > > > > > Uh i think that may have been for the UART. > > > { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, }, > > > > > > The same applies to the other bindings in the series. > > > > > > This way it would be possible to differentiate between future > > > supported i.MX RT devices. > > > > > This makes sense will do in V3. > > > > If we add every SoC we will end up having a long list for every device > driver. At the moment it would be 7 parts: > 1) imxrt1020 > 2) imxrt1024 > . > . > . > 7) imxrt1170 You don't need a driver update if you use a fallback. When you add the 2nd chip, if you think it is 'the same', then you do: compatible = "fsl,imxrt1024-usdhc", "fsl,imxrt1050-usdhc"; That requires no driver update until the driver needs to handle some difference. And when there is a difference, you don't need a DT update. You could make "fsl,imxrt-usdhc" the fallback from the start if you are adverse to the first way. Rob
Hello Rob, Jesse, All, > Il giorno 4 nov 2021, alle ore 02:05, Rob Herring <robh@kernel.org> ha scritto: > > On Wed, Nov 03, 2021 at 12:30:17AM +0100, Giulio Benetti wrote: >> Hi Fabio, Jesse, All, >> >>> On 11/3/21 12:25 AM, Jesse Taube wrote: >>> >>> >>> On 11/2/21 19:17, Fabio Estevam wrote: >>>> On Tue, Nov 2, 2021 at 7:57 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >>>> >>>>> static struct esdhc_soc_data usdhc_imx8qxp_data = { >>>>> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING >>>>> @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { >>>>> { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, >>>>> { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, >>>>> { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, >>>>> + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, >>>> >>>> I thought Rob suggested to use the SoC name, so this would be: >>>> >>> Uh i think that may have been for the UART. >>>> { .compatible = "fsl,imxrt1050-usdhc", .data = &usdhc_imxrt1050_data, }, >>>> >>>> The same applies to the other bindings in the series. >>>> >>>> This way it would be possible to differentiate between future >>>> supported i.MX RT devices. >>>> >>> This makes sense will do in V3. >>> >> >> If we add every SoC we will end up having a long list for every device >> driver. At the moment it would be 7 parts: >> 1) imxrt1020 >> 2) imxrt1024 >> . >> . >> . >> 7) imxrt1170 > > You don't need a driver update if you use a fallback. When you add > the 2nd chip, if you think it is 'the same', then you do: > > compatible = "fsl,imxrt1024-usdhc", "fsl,imxrt1050-usdhc"; > > That requires no driver update until the driver needs to handle some > difference. And when there is a difference, you don't need a DT update. This solution is pretty fine, we’re going with that then, for this and every driver involved. Thank you for pointing us. Best regards Giulio Benetti Benetti Engineering sas > > You could make "fsl,imxrt-usdhc" the fallback from the start if you are > adverse to the first way. > > Rob
On 11/2/21 22:19, Bough Chen wrote: >> -----Original Message----- >> From: Jesse Taube [mailto:mr.bossman075@gmail.com] >> Sent: 2021年11月3日 6:57 >> To: dl-linux-imx <linux-imx@nxp.com> >> Cc: mturquette@baylibre.com; sboyd@kernel.org; robh+dt@kernel.org; >> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de; >> festevam@gmail.com; ulf.hansson@linaro.org; Aisheng Dong >> <aisheng.dong@nxp.com>; stefan@agner.ch; linus.walleij@linaro.org; >> gregkh@linuxfoundation.org; arnd@arndb.de; olof@lixom.net; >> soc@kernel.org; linux@armlinux.org.uk; Abel Vesa <abel.vesa@nxp.com>; >> adrian.hunter@intel.com; jirislaby@kernel.org; >> giulio.benetti@benettiengineering.com; nobuhiro1.iwamatsu@toshiba.co.jp; >> Mr.Bossman075@gmail.com; linux-clk@vger.kernel.org; >> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; >> linux-kernel@vger.kernel.org; linux-mmc@vger.kernel.org; >> linux-gpio@vger.kernel.org; linux-serial@vger.kernel.org; Jesse Taube >> <mr.bossman075@gmail.com> >> Subject: [PATCH v2 11/13] mmc: sdhci-esdhc-imx: Add sdhc support for > i.MXRT >> series >> >> From: Jesse Taube <mr.bossman075@gmail.com> >> >> Add support for i.MXRT1050's sdhc. >> >> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> >> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>--- >> V1->V2: >> * Nothing done >> --- >> drivers/mmc/host/sdhci-esdhc-imx.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c >> b/drivers/mmc/host/sdhci-esdhc-imx.c >> index afaf33707d46..c852a6df5611 100644 >> --- a/drivers/mmc/host/sdhci-esdhc-imx.c >> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c >> @@ -305,6 +305,12 @@ static struct esdhc_soc_data usdhc_imx7ulp_data = { >> | ESDHC_FLAG_PMQOS | ESDHC_FLAG_HS400 >> | ESDHC_FLAG_STATE_LOST_IN_LPMODE, >> }; >> +static struct esdhc_soc_data usdhc_imxrt_data = { >> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING >> + | ESDHC_FLAG_HS200 | ESDHC_FLAG_ERR004536 >> + | ESDHC_FLAG_BROKEN_AUTO_CMD23, >> +}; >> + > > Hi Jesse, > I have few question here. > Why only use manual tuning here? Does this usdhc don't support > standard tuning? or meet any issue when use standard tuning? No std tuning works, so does cmd23, i changed it to use them. > Please also double check why not use ADMA in default? Any issue > found? Yes this is the output with ADMA: [0.00] mmc0: Unable to allocate ADMA buffers - falling back to standard DMA NOTE: I did not look into why this occurs. > > > Best Regards > Haibo Chen >> >> static struct esdhc_soc_data usdhc_imx8qxp_data = { >> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING @@ -357,6 >> +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { >> { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, >> { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, >> { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, >> + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, >> { .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, }, >> { /* sentinel */ } >> }; >> -- >> 2.33.1 >
> -----Original Message----- > From: Jesse Taube [mailto:mr.bossman075@gmail.com] > Sent: 2021年11月23日 11:14 > To: Bough Chen <haibo.chen@nxp.com>; dl-linux-imx <linux-imx@nxp.com> > Cc: mturquette@baylibre.com; sboyd@kernel.org; robh+dt@kernel.org; > shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de; > festevam@gmail.com; ulf.hansson@linaro.org; Aisheng Dong > <aisheng.dong@nxp.com>; stefan@agner.ch; linus.walleij@linaro.org; > gregkh@linuxfoundation.org; arnd@arndb.de; olof@lixom.net; > soc@kernel.org; linux@armlinux.org.uk; Abel Vesa <abel.vesa@nxp.com>; > adrian.hunter@intel.com; jirislaby@kernel.org; > giulio.benetti@benettiengineering.com; nobuhiro1.iwamatsu@toshiba.co.jp; > linux-clk@vger.kernel.org; devicetree@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > linux-mmc@vger.kernel.org; linux-gpio@vger.kernel.org; > linux-serial@vger.kernel.org > Subject: Re: [PATCH v2 11/13] mmc: sdhci-esdhc-imx: Add sdhc support for > i.MXRT series > > > > On 11/2/21 22:19, Bough Chen wrote: > >> -----Original Message----- > >> From: Jesse Taube [mailto:mr.bossman075@gmail.com] > >> Sent: 2021年11月3日 6:57 > >> To: dl-linux-imx <linux-imx@nxp.com> > >> Cc: mturquette@baylibre.com; sboyd@kernel.org; robh+dt@kernel.org; > >> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de; > >> festevam@gmail.com; ulf.hansson@linaro.org; Aisheng Dong > >> <aisheng.dong@nxp.com>; stefan@agner.ch; linus.walleij@linaro.org; > >> gregkh@linuxfoundation.org; arnd@arndb.de; olof@lixom.net; > >> soc@kernel.org; linux@armlinux.org.uk; Abel Vesa <abel.vesa@nxp.com>; > >> adrian.hunter@intel.com; jirislaby@kernel.org; > >> giulio.benetti@benettiengineering.com; > >> nobuhiro1.iwamatsu@toshiba.co.jp; Mr.Bossman075@gmail.com; > >> linux-clk@vger.kernel.org; devicetree@vger.kernel.org; > >> linux-arm-kernel@lists.infradead.org; > >> linux-kernel@vger.kernel.org; linux-mmc@vger.kernel.org; > >> linux-gpio@vger.kernel.org; linux-serial@vger.kernel.org; Jesse Taube > >> <mr.bossman075@gmail.com> > >> Subject: [PATCH v2 11/13] mmc: sdhci-esdhc-imx: Add sdhc support for > > i.MXRT > >> series > >> > >> From: Jesse Taube <mr.bossman075@gmail.com> > >> > >> Add support for i.MXRT1050's sdhc. > >> > >> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > >> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>--- > >> V1->V2: > >> * Nothing done > >> --- > >> drivers/mmc/host/sdhci-esdhc-imx.c | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c > >> b/drivers/mmc/host/sdhci-esdhc-imx.c > >> index afaf33707d46..c852a6df5611 100644 > >> --- a/drivers/mmc/host/sdhci-esdhc-imx.c > >> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > >> @@ -305,6 +305,12 @@ static struct esdhc_soc_data usdhc_imx7ulp_data > = { > >> | ESDHC_FLAG_PMQOS | ESDHC_FLAG_HS400 > >> | ESDHC_FLAG_STATE_LOST_IN_LPMODE, > >> }; > >> +static struct esdhc_soc_data usdhc_imxrt_data = { > >> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING > >> + | ESDHC_FLAG_HS200 | ESDHC_FLAG_ERR004536 > >> + | ESDHC_FLAG_BROKEN_AUTO_CMD23, > >> +}; > >> + > > > > Hi Jesse, > > I have few question here. > > Why only use manual tuning here? Does this usdhc don't support > > standard tuning? or meet any issue when use standard tuning? > No std tuning works, so does cmd23, i changed it to use them. Okay. > > Please also double check why not use ADMA in default? Any issue > > found? > Yes this is the output with ADMA: > [0.00] mmc0: Unable to allocate ADMA buffers - falling back to standard DMA > NOTE: I did not look into why this occurs. If you config enough space for CMA or DMA pool, I think dma_alloc_corherent() should not meet issue. ADMA descriptor do not large than one page(4KB). This is not big. Seems strange. Please double check this. If this is really a limitation on imxRT, I'm okay to use SDMA as default. Best Regards Haibo chen > > > > > > Best Regards > > Haibo Chen > >> > >> static struct esdhc_soc_data usdhc_imx8qxp_data = { > >> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING @@ > -357,6 > >> +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { > >> { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, > >> { .compatible = "fsl,imx8qxp-usdhc", .data = > &usdhc_imx8qxp_data, }, > >> { .compatible = "fsl,imx8mm-usdhc", .data = > &usdhc_imx8mm_data, }, > >> + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, > >> { .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, }, > >> { /* sentinel */ } > >> }; > >> -- > >> 2.33.1 > >
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c index afaf33707d46..c852a6df5611 100644 --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -305,6 +305,12 @@ static struct esdhc_soc_data usdhc_imx7ulp_data = { | ESDHC_FLAG_PMQOS | ESDHC_FLAG_HS400 | ESDHC_FLAG_STATE_LOST_IN_LPMODE, }; +static struct esdhc_soc_data usdhc_imxrt_data = { + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING + | ESDHC_FLAG_HS200 | ESDHC_FLAG_ERR004536 + | ESDHC_FLAG_BROKEN_AUTO_CMD23, +}; + static struct esdhc_soc_data usdhc_imx8qxp_data = { .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING @@ -357,6 +363,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = { { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, }, { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, }, { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, }, + { .compatible = "fsl,imxrt-usdhc", .data = &usdhc_imxrt_data, }, { .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, }, { /* sentinel */ } };