from:"BOUGH CHEN"

RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

2021-01-26 Thread Bough Chen

> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: 2021年1月21日 21:26
> To: Wang, Xiaolei ; Fabio Estevam
> ; Bough Chen 
> Cc: Pali Rohár ; Lee Jones ;
> linux-...@vger.kernel.org; Linux Kernel Mailing List
> 
> Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> 
> + Fabio, Haibo
> 
> On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei 
> wrote:
> >
> > Hi
> >
> > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > >Can you elaborate more what happens?
> >
> > When I use the mkfs.f2fs tool to format the eMMC file system on the
> > imx8qxp board, because mkfs.f2fs will use secdiscard first, when
> > entering mmc_blk_issue_secdiscard_rq erase, once the parameters are
> passed into MMC_SECURE_TRIM1_ARG, this function will take a long time to
> return .
> > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> >
> > I compared the mkfs.ext4 tool to format the file system. Because it
> > directly uses mmc_blk_issue_discard_rq, this is a normal formatting
> phenomenon.
> >
> > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just
> different commands and parameters sent by the host as a bus.
> >  I did not see the description of trim in the data sheet. Could the host 
> > driver
> cause this problem?
> 
> Yes, it can - and we have had issues like these before. So before adding a 
> card
> quirk, I think we need to make sure this isn't the case.
> 
> When using MMC_SECURE_TRIM1_ARG, it's very likely that the request takes
> longer to complete.
> 
> The mmc host is responsible for either dealing with busy detection with the
> help of its HW/controller - or if that can't be supported, the mmc core falls 
> back
> to polling the card for busy with a CMD13.
> 
> See mmc_do_erase() in /drivers/mmc/core/core.c
> 
> >
> > Note:
> > The host driver I use is sdhci-esdhc-imx.c
> 
> Alright, I have looped in Fabio and Haibo that knows this driver, let's see 
> if they
> can help.
> 

Hi Ulf and Xiaolei,

I use the mkfs.f2fs tool format a partition on one Sandisk eMMC chip on imx8 
platform, do not meet issue.
I add some log, confirm mkfs.f2fs call the mmc_blk_issue_secdiscard_rq(), and 
the arg is MMC_SECURE_TRIM1_ARG.
For the busy detection, imx usdhc has one register bit represent the dat0 
signal level. So for your mmc device, it should be the mmc device trim feature 
problem.

Best Regards
Haibo
> >
> > Thanks
> > Xiaolei
> 
> Kind regards
> Uffe
> 
> >
> > -Original Message-
> > From: Ulf Hansson 
> > Sent: Wednesday, January 20, 2021 9:41 PM
> > To: Wang, Xiaolei 
> > Cc: Pali Rohár ; Lee Jones ;
> > linux-...@vger.kernel.org; Linux Kernel Mailing List
> > 
> > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> >
> > [Please note this e-mail is from an EXTERNAL e-mail address]
> >
> > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang 
> wrote:
> > >
> > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > function, but this function does not work properly, the SDIO bus
> > > does not respond, and the IO has been waiting so set quirks to skip
> > > trim
> >
> > Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > Can you elaborate more what happens?
> >
> > Kind regards
> > Uffe
> >
> > >
> > > Signed-off-by: Xiaolei Wang 
> > > ---
> > >  drivers/mmc/core/quirks.h | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > index d68e6e513a4f..63e02391c133 100644
> > > --- a/drivers/mmc/core/quirks.h
> > > +++ b/drivers/mmc/core/quirks.h
> > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > >   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG,
> CID_OEMID_ANY, add_quirk_mmc,
> > >   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > +   MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > >
> > > /*
> > >  *  On Some Kingston eMMCs, performing trim can result in
> @@
> > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > >   MMC_QUIRK_TRIM_BROKEN),
> > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON,
> CID_OEMID_ANY, add_quirk_mmc,
> > >   MMC_QUIRK_TRIM_BROKEN),
> > > +   MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_TRIM_BROKEN),
> > >
> > > END_FIXUP
> > >  };
> > > --
> > > 2.25.1
> > >

RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

2021-01-25 Thread Bough Chen

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2021年1月25日 18:47
> To: Ulf Hansson 
> Cc: Wang, Xiaolei ; Bough Chen
> ; Pali Rohár ; Lee Jones
> ; linux-...@vger.kernel.org; Linux Kernel Mailing List
> 
> Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> 
> Hi Haibo,
> 
> Could you please take a look?

I will look into this issue this week.

Haibo Chen
> 
> Thanks
> 
> On Thu, Jan 21, 2021 at 10:26 AM Ulf Hansson 
> wrote:
> >
> > + Fabio, Haibo
> >
> > On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei 
> wrote:
> > >
> > > Hi
> > >
> > > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> > >
> > > >Can you elaborate more what happens?
> > >
> > > When I use the mkfs.f2fs tool to format the eMMC file system on the
> > > imx8qxp board, because mkfs.f2fs will use secdiscard first, when
> > > entering mmc_blk_issue_secdiscard_rq erase, once the parameters are
> passed into MMC_SECURE_TRIM1_ARG, this function will take a long time to
> return .
> > > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> > >
> > > I compared the mkfs.ext4 tool to format the file system. Because it
> > > directly uses mmc_blk_issue_discard_rq, this is a normal formatting
> phenomenon.
> > >
> > > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just
> different commands and parameters sent by the host as a bus.
> > >  I did not see the description of trim in the data sheet. Could the host
> driver cause this problem?
> >
> > Yes, it can - and we have had issues like these before. So before
> > adding a card quirk, I think we need to make sure this isn't the case.
> >
> > When using MMC_SECURE_TRIM1_ARG, it's very likely that the request
> > takes longer to complete.
> >
> > The mmc host is responsible for either dealing with busy detection
> > with the help of its HW/controller - or if that can't be supported,
> > the mmc core falls back to polling the card for busy with a CMD13.
> >
> > See mmc_do_erase() in /drivers/mmc/core/core.c
> >
> > >
> > > Note:
> > > The host driver I use is sdhci-esdhc-imx.c
> >
> > Alright, I have looped in Fabio and Haibo that knows this driver,
> > let's see if they can help.
> >
> > >
> > > Thanks
> > > Xiaolei
> >
> > Kind regards
> > Uffe
> >
> > >
> > > -Original Message-
> > > From: Ulf Hansson 
> > > Sent: Wednesday, January 20, 2021 9:41 PM
> > > To: Wang, Xiaolei 
> > > Cc: Pali Rohár ; Lee Jones ;
> > > linux-...@vger.kernel.org; Linux Kernel Mailing List
> > > 
> > > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> > >
> > > [Please note this e-mail is from an EXTERNAL e-mail address]
> > >
> > > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang 
> wrote:
> > > >
> > > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > > function, but this function does not work properly, the SDIO bus
> > > > does not respond, and the IO has been waiting so set quirks to
> > > > skip trim
> > >
> > > Are you sure this is an eMMC problem and not a mmc host driver issue?
> > >
> > > Can you elaborate more what happens?
> > >
> > > Kind regards
> > > Uffe
> > >
> > > >
> > > > Signed-off-by: Xiaolei Wang 
> > > > ---
> > > >  drivers/mmc/core/quirks.h | 4 
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > > index d68e6e513a4f..63e02391c133 100644
> > > > --- a/drivers/mmc/core/quirks.h
> > > > +++ b/drivers/mmc/core/quirks.h
> > > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > >   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > > MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG,
> CID_OEMID_ANY, add_quirk_mmc,
> > > >   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > > +   MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > > + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > >
> > > > /*
> > > >  *  On Some Kingston eMMCs, performing trim can result in
> > > > @@
> > > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > >   MMC_QUIRK_TRIM_BROKEN),
> > > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > >   MMC_QUIRK_TRIM_BROKEN),
> > > > +   MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > > + MMC_QUIRK_TRIM_BROKEN),
> > > >
> > > > END_FIXUP
> > > >  };
> > > > --
> > > > 2.25.1
> > > >

RE: [PATCH 05/15] input: touchscreen: imx6ul_tsc: Remove set but unused variable 'value'

2020-11-12 Thread Bough Chen

> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: 2020年11月12日 19:02
> To: lee.jo...@linaro.org
> Cc: linux-kernel@vger.kernel.org; Dmitry Torokhov
> ; Shawn Guo ; Sascha
> Hauer ; Pengutronix Kernel Team
> ; Fabio Estevam ;
> dl-linux-imx ; Haibo Chen ;
> linux-in...@vger.kernel.org
> Subject: [PATCH 05/15] input: touchscreen: imx6ul_tsc: Remove set but unused
> variable 'value'
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/input/touchscreen/imx6ul_tsc.c: In function ‘adc_irq_fn’:
>  drivers/input/touchscreen/imx6ul_tsc.c:307:6: warning: variable ‘value’ set
> but not used [-Wunused-but-set-variable]
> 
> Cc: Dmitry Torokhov 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Pengutronix Kernel Team 
> Cc: Fabio Estevam 
> Cc: NXP Linux Team 
> Cc: Haibo Chen 
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/input/touchscreen/imx6ul_tsc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> b/drivers/input/touchscreen/imx6ul_tsc.c
> index cd369f9ac5e60..e1852f7d4d31e 100644
> --- a/drivers/input/touchscreen/imx6ul_tsc.c
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -304,11 +304,10 @@ static irqreturn_t adc_irq_fn(int irq, void *dev_id)
> {
>   struct imx6ul_tsc *tsc = dev_id;
>   u32 coco;
> - u32 value;
> 
>   coco = readl(tsc->adc_regs + REG_ADC_HS);
>   if (coco & 0x01) {
> - value = readl(tsc->adc_regs + REG_ADC_R0);
> + readl(tsc->adc_regs + REG_ADC_R0);
>   complete(>completion);
>   }
> 

Reviewed-by: Haibo Chen 

> --
> 2.25.1

RE: [RFC PATCH v3.1 03/27] mmc: core: UHS-II support, skip set_chip_select()

2020-11-09 Thread Bough Chen

> -Original Message-
> From: AKASHI Takahiro [mailto:takahiro.aka...@linaro.org]
> Sent: 2020年11月6日 10:27
> To: ulf.hans...@linaro.org; adrian.hun...@intel.com
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ben.chu...@genesyslogic.com.tw; greg...@genesyslogic.com.tw; AKASHI
> Takahiro 
> Subject: [RFC PATCH v3.1 03/27] mmc: core: UHS-II support, skip
> set_chip_select()
> 
> mmc_set_chip_select() should be called only in UHS-II mode, and not for UHS-II
> mode.

Typo, only in UHS-I mode.

Regards
Haibo Chen
> 
> Signed-off-by: Ben Chuang 
> Signed-off-by: AKASHI Takahiro 
> ---
>  drivers/mmc/core/core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
> 5541ed956c4d..4e12bd98fc08 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -898,8 +898,10 @@ static inline void mmc_set_ios(struct mmc_host
> *host)
>   */
>  void mmc_set_chip_select(struct mmc_host *host, int mode)  {
> - host->ios.chip_select = mode;
> - mmc_set_ios(host);
> + if (!(host->flags & MMC_UHS2_INITIALIZED)) {
> + host->ios.chip_select = mode;
> + mmc_set_ios(host);
> + }
>  }
> 
>  /*
> --
> 2.28.0

RE: [PATCH 21/22] arm64: dts: imx8qxp: Remove i.MX7 compatible from USDHC

2020-08-24 Thread Bough Chen

> -Original Message-
> From: Dong Aisheng [mailto:donga...@gmail.com]
> Sent: 2020年8月24日 17:45
> To: Krzysztof Kozlowski 
> Cc: Aisheng Dong ; devicet...@vger.kernel.org;
> linux-ser...@vger.kernel.org; Anson Huang ;
> linux-g...@vger.kernel.org; Fabio Estevam ; Linus
> Walleij ; linux...@vger.kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org; Bartosz Golaszewski
> ; Rob Herring ;
> linux-...@lists.infradead.org; dl-linux-imx ; Pengutronix
> Kernel Team ; Thierry Reding
> ; Shawn Guo ; Sascha
> Hauer ; linux-arm-ker...@lists.infradead.org;
> linux-watch...@vger.kernel.org; Bough Chen 
> Subject: Re: [PATCH 21/22] arm64: dts: imx8qxp: Remove i.MX7 compatible
> from USDHC
> 
> On Mon, Aug 24, 2020 at 5:15 PM Krzysztof Kozlowski 
> wrote:
> >
> > On Mon, Aug 24, 2020 at 09:00:19AM +, Aisheng Dong wrote:
> > > > From: Krzysztof Kozlowski 
> > > > Sent: Monday, August 24, 2020 12:16 AM
> > > >
> > > > The USDHC on i.MX 8QXP has its own compatible described in
> > > > bindings and used in the driver (with its own quirks).  Remove
> > > > additional fsl,imx7d-usdhc compatible to fix dtbs_check warnings like:
> > > >
> > > >   arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml:
> mmc@5b01:
> > > > compatible: ['fsl,imx8qxp-usdhc', 'fsl,imx7d-usdhc'] is too long
> > > > From schema:
> > > > /ocumentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > > >
> > > >   arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml:
> mmc@5b01:
> > > > compatible: Additional items are not allowed
> > > > ('fsl,imx7d-usdhc' was
> > > > unexpected)
> > > >
> > > > Signed-off-by: Krzysztof Kozlowski 
> > >
> > > For Patch 19-22, I think we should fix dt binding doc.
> >
> > Are you sure that these USDHC controllers are compatible with i.MX 7D?
> > Could they really run with fsl,imx7d-usdhc compatible?
> 
> AFAIK uSDHC on QXP is derived from the former platforms with adding a few
> more new features. e.g. HS400ES/CMDQ.
> Let me loop in uSDHC driver owner Haibo Chen to double confirm.

Yes, usdhc of imx8qxp can work by using the compatible "fsl, imx7d-usdhc", but 
will not support HS400ES/Command Queue any more. Also imx8qxp support Auto 
CMD23, but imx7d not.
And imx8qxp need to re-config the clock rate after system PM, imx7d do not need 
to do this.


> 
> Regards
> Aisheng
> 
> > The implementation (Linux kernel driver) is different, I guess on
> > purpose...
> >
> > Best regards,
> > Krzysztof
> >
> > >
> > > Regards
> > > Aisheng
> > >
> > > > ---
> > > >  arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > > index 61bccb69f09e..26c4fcdfe290 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > > @@ -362,7 +362,7 @@
> > > > };
> > > >
> > > > usdhc1: mmc@5b01 {
> > > > -   compatible = "fsl,imx8qxp-usdhc",
> "fsl,imx7d-usdhc";
> > > > +   compatible = "fsl,imx8qxp-usdhc";
> > > > interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> > > > reg = <0x5b01 0x1>;
> > > > clocks = <_lpcg
> > > > IMX_CONN_LPCG_SDHC0_IPG_CLK>, @@
> > > > -374,7 +374,7 @@
> > > > };
> > > >
> > > > usdhc2: mmc@5b02 {
> > > > -   compatible = "fsl,imx8qxp-usdhc",
> "fsl,imx7d-usdhc";
> > > > +   compatible = "fsl,imx8qxp-usdhc";
> > > > interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> > > > reg = <0x5b02 0x1>;
> > > > clocks = <_lpcg
> > > > IMX_CONN_LPCG_SDHC1_IPG_CLK>, @@
> > > > -388,7 +388,7 @@
> > > > };
> > > >
> > > > usdhc3: mmc@5b03 {
> > > > -   compatible = "fsl,imx8qxp-usdhc",
> "fsl,imx7d-usdhc";
> > > > +   compatible = "fsl,imx8qxp-usdhc";
> > > > interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> > > > reg = <0x5b03 0x1>;
> > > > clocks = <_lpcg
> > > > IMX_CONN_LPCG_SDHC2_IPG_CLK>,
> > > > --
> > > > 2.17.1
> > >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kerneldata=02%7
> C0
> >
> 1%7Chaibo.chen%40nxp.com%7C25d35969a5904d2cd49e08d848148b49%7C6
> 86ea1d3
> >
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637338600398740888sdata
> =OVryLd
> > 4q7LvEoSl6dqQhbR4VWgi6TqBYE%2BS9bI1M6ZY%3Dreserved=0

RE: [PATCH v9 0/5] Add MMC software queue support

2020-06-14 Thread BOUGH CHEN


> -Original Message-
> From: Baolin Wang [mailto:baolin.wa...@gmail.com]
> Sent: 2020年6月15日 7:26
> To: BOUGH CHEN 
> Cc: Ulf Hansson ; Adrian Hunter
> ; Asutosh Das ; Orson
> Zhai ; Chunyan Zhang ; Arnd
> Bergmann ; Linus Walleij ; Baolin
> Wang ; linux-...@vger.kernel.org; Linux Kernel
> Mailing List ; dl-linux-imx 
> Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> 
> On Sun, Jun 14, 2020 at 11:05 PM Baolin Wang 
> wrote:
> >
> > On Wed, Jun 10, 2020 at 10:26 AM BOUGH CHEN 
> wrote:
> > >
> > > > -Original Message-
> > > > From: Baolin Wang [mailto:baolin.wa...@gmail.com]
> > > > Sent: 2020年6月8日 19:54
> > > > To: BOUGH CHEN 
> > > > Cc: Ulf Hansson ; Adrian Hunter
> > > > ; Asutosh Das ;
> > > > Orson Zhai ; Chunyan Zhang
> > > > ; Arnd Bergmann ; Linus
> > > > Walleij ; Baolin Wang
> > > > ; linux-...@vger.kernel.org; Linux Kernel
> > > > Mailing List ; dl-linux-imx
> > > > 
> > > > Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> > > >
> > > > Hi Haibo.
> > > >
> > > > On Mon, Jun 8, 2020 at 2:35 PM BOUGH CHEN 
> wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: linux-mmc-ow...@vger.kernel.org
> > > > > > [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Baolin
> > > > > > Wang
> > > > > > Sent: 2020年2月19日 9:35
> > > > > > To: Ulf Hansson 
> > > > > > Cc: Adrian Hunter ; Asutosh Das
> > > > > > ; Orson Zhai ;
> > > > Chunyan
> > > > > > Zhang ; Arnd Bergmann ;
> > > > > > Linus Walleij ; Baolin Wang
> > > > > > ; linux-...@vger.kernel.org; Linux
> > > > > > Kernel Mailing List 
> > > > > > Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> > > > > >
> > > > > > On Wed, Feb 19, 2020 at 7:38 AM Ulf Hansson
> > > > > > 
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, 12 Feb 2020 at 05:14, Baolin Wang
> > > > > > > 
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > Now the MMC read/write stack will always wait for previous
> > > > > > > > request is completed by mmc_blk_rw_wait(), before sending
> > > > > > > > a new request to hardware, or queue a work to complete
> > > > > > > > request, that will bring context switching overhead,
> > > > > > > > especially for high I/O per second rates, to affect the IO
> performance.
> > > > > > > >
> > > > > > > > Thus this patch set will introduce the MMC software
> > > > > > > > command queue support based on command queue engine's
> > > > > > > > interfaces, and set the queue depth as 64 to allow more
> > > > > > > > requests can be be prepared, merged and inserted into IO
> > > > > > > > scheduler, but we only allow 2 requests in flight, that is
> > > > > > > > enough to let the irq handler always trigger the next
> > > > > > > > request without a context switch, as
> > > > well as avoiding a long latency.
> > > > > > > >
> > > > > > > > Moreover we can expand the MMC software queue interface to
> > > > > > > > support MMC packed request or packed command instead of
> > > > > > > > adding new interfaces, according to previosus discussion.
> > > > > > > >
> > > > > > > > Below are some comparison data with fio tool. The fio
> > > > > > > > command I used is like below with changing the '--rw'
> > > > > > > > parameter and enabling the direct IO flag to measure the
> > > > > > > > actual hardware transfer speed in 4K block
> > > > > > size.
> > > > > > > >
> > > > > > > > ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20
> > > > > > > > --rw=read --bs=4K --size=1G --group_reporting --numjobs=20
> > > > > > > > --name=test_read
> > >

RE: [PATCH v9 0/5] Add MMC software queue support

2020-06-09 Thread BOUGH CHEN

> -Original Message-
> From: Baolin Wang [mailto:baolin.wa...@gmail.com]
> Sent: 2020年6月8日 19:54
> To: BOUGH CHEN 
> Cc: Ulf Hansson ; Adrian Hunter
> ; Asutosh Das ; Orson
> Zhai ; Chunyan Zhang ; Arnd
> Bergmann ; Linus Walleij ; Baolin
> Wang ; linux-...@vger.kernel.org; Linux Kernel
> Mailing List ; dl-linux-imx 
> Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> 
> Hi Haibo.
> 
> On Mon, Jun 8, 2020 at 2:35 PM BOUGH CHEN  wrote:
> >
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org
> > > [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Baolin Wang
> > > Sent: 2020年2月19日 9:35
> > > To: Ulf Hansson 
> > > Cc: Adrian Hunter ; Asutosh Das
> > > ; Orson Zhai ;
> Chunyan
> > > Zhang ; Arnd Bergmann ; Linus
> > > Walleij ; Baolin Wang
> > > ; linux-...@vger.kernel.org; Linux Kernel
> > > Mailing List 
> > > Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> > >
> > > On Wed, Feb 19, 2020 at 7:38 AM Ulf Hansson 
> > > wrote:
> > > >
> > > > On Wed, 12 Feb 2020 at 05:14, Baolin Wang 
> > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > Now the MMC read/write stack will always wait for previous
> > > > > request is completed by mmc_blk_rw_wait(), before sending a new
> > > > > request to hardware, or queue a work to complete request, that
> > > > > will bring context switching overhead, especially for high I/O
> > > > > per second rates, to affect the IO performance.
> > > > >
> > > > > Thus this patch set will introduce the MMC software command
> > > > > queue support based on command queue engine's interfaces, and
> > > > > set the queue depth as 64 to allow more requests can be be
> > > > > prepared, merged and inserted into IO scheduler, but we only
> > > > > allow 2 requests in flight, that is enough to let the irq
> > > > > handler always trigger the next request without a context switch, as
> well as avoiding a long latency.
> > > > >
> > > > > Moreover we can expand the MMC software queue interface to
> > > > > support MMC packed request or packed command instead of adding
> > > > > new interfaces, according to previosus discussion.
> > > > >
> > > > > Below are some comparison data with fio tool. The fio command I
> > > > > used is like below with changing the '--rw' parameter and
> > > > > enabling the direct IO flag to measure the actual hardware
> > > > > transfer speed in 4K block
> > > size.
> > > > >
> > > > > ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20
> > > > > --rw=read --bs=4K --size=1G --group_reporting --numjobs=20
> > > > > --name=test_read
> > > > >
> > > > > My eMMC card working at HS400 Enhanced strobe mode:
> > > > > [2.229856] mmc0: new HS400 Enhanced strobe MMC card at
> address
> > > 0001
> > > > > [2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB
> > > > > [2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00
> MiB
> > > > > [2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00
> MiB
> > > > > [2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00
> MiB,
> > > chardev (248:0)
> > > > >
> > > > > 1. Without MMC software queue
> > > > > I tested 5 times for each case and output a average speed.
> > > > >
> > > > > 1) Sequential read:
> > > > > Speed: 59.4MiB/s, 63.4MiB/s, 57.5MiB/s, 57.2MiB/s, 60.8MiB/s
> > > > > Average
> > > > > speed: 59.66MiB/s
> > > > >
> > > > > 2) Random read:
> > > > > Speed: 26.9MiB/s, 26.9MiB/s, 27.1MiB/s, 27.1MiB/s, 27.2MiB/s
> > > > > Average
> > > > > speed: 27.04MiB/s
> > > > >
> > > > > 3) Sequential write:
> > > > > Speed: 71.6MiB/s, 72.5MiB/s, 72.2MiB/s, 64.6MiB/s, 67.5MiB/s
> > > > > Average
> > > > > speed: 69.68MiB/s
> > > > >
> > > > > 4) Random write:
> > > > > Speed: 36.3MiB/s, 35.4MiB/s, 38.6MiB/s, 34MiB/s, 35.5MiB/s
> > > > > Average
> > > > > speed: 35.96MiB/s
> > > > >
> > > > >

RE: [PATCH v9 0/5] Add MMC software queue support

2020-06-08 Thread BOUGH CHEN

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: 2020年2月19日 9:35
> To: Ulf Hansson 
> Cc: Adrian Hunter ; Asutosh Das
> ; Orson Zhai ; Chunyan
> Zhang ; Arnd Bergmann ; Linus
> Walleij ; Baolin Wang ;
> linux-...@vger.kernel.org; Linux Kernel Mailing List
> 
> Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> 
> On Wed, Feb 19, 2020 at 7:38 AM Ulf Hansson 
> wrote:
> >
> > On Wed, 12 Feb 2020 at 05:14, Baolin Wang 
> wrote:
> > >
> > > Hi All,
> > >
> > > Now the MMC read/write stack will always wait for previous request
> > > is completed by mmc_blk_rw_wait(), before sending a new request to
> > > hardware, or queue a work to complete request, that will bring
> > > context switching overhead, especially for high I/O per second
> > > rates, to affect the IO performance.
> > >
> > > Thus this patch set will introduce the MMC software command queue
> > > support based on command queue engine's interfaces, and set the
> > > queue depth as 64 to allow more requests can be be prepared, merged
> > > and inserted into IO scheduler, but we only allow 2 requests in
> > > flight, that is enough to let the irq handler always trigger the
> > > next request without a context switch, as well as avoiding a long latency.
> > >
> > > Moreover we can expand the MMC software queue interface to support
> > > MMC packed request or packed command instead of adding new
> > > interfaces, according to previosus discussion.
> > >
> > > Below are some comparison data with fio tool. The fio command I used
> > > is like below with changing the '--rw' parameter and enabling the
> > > direct IO flag to measure the actual hardware transfer speed in 4K block
> size.
> > >
> > > ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20 --rw=read
> > > --bs=4K --size=1G --group_reporting --numjobs=20 --name=test_read
> > >
> > > My eMMC card working at HS400 Enhanced strobe mode:
> > > [2.229856] mmc0: new HS400 Enhanced strobe MMC card at address
> 0001
> > > [2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB
> > > [2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB
> > > [2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB
> > > [2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00 MiB,
> chardev (248:0)
> > >
> > > 1. Without MMC software queue
> > > I tested 5 times for each case and output a average speed.
> > >
> > > 1) Sequential read:
> > > Speed: 59.4MiB/s, 63.4MiB/s, 57.5MiB/s, 57.2MiB/s, 60.8MiB/s Average
> > > speed: 59.66MiB/s
> > >
> > > 2) Random read:
> > > Speed: 26.9MiB/s, 26.9MiB/s, 27.1MiB/s, 27.1MiB/s, 27.2MiB/s Average
> > > speed: 27.04MiB/s
> > >
> > > 3) Sequential write:
> > > Speed: 71.6MiB/s, 72.5MiB/s, 72.2MiB/s, 64.6MiB/s, 67.5MiB/s Average
> > > speed: 69.68MiB/s
> > >
> > > 4) Random write:
> > > Speed: 36.3MiB/s, 35.4MiB/s, 38.6MiB/s, 34MiB/s, 35.5MiB/s Average
> > > speed: 35.96MiB/s
> > >
> > > 2. With MMC software queue
> > > I tested 5 times for each case and output a average speed.
> > >
> > > 1) Sequential read:
> > > Speed: 59.2MiB/s, 60.4MiB/s, 63.6MiB/s, 60.3MiB/s, 59.9MiB/s Average
> > > speed: 60.68MiB/s
> > >
> > > 2) Random read:
> > > Speed: 31.3MiB/s, 31.4MiB/s, 31.5MiB/s, 31.3MiB/s, 31.3MiB/s Average
> > > speed: 31.36MiB/s
> > >
> > > 3) Sequential write:
> > > Speed: 71MiB/s, 71.8MiB/s, 72.3MiB/s, 72.2MiB/s, 71MiB/s Average
> > > speed: 71.66MiB/s
> > >
> > > 4) Random write:
> > > Speed: 68.9MiB/s, 68.7MiB/s, 68.8MiB/s, 68.6MiB/s, 68.8MiB/s Average
> > > speed: 68.76MiB/s
> > >
> > > Form above data, we can see the MMC software queue can help to
> > > improve some performance obviously for random read and write, though
> > > no obvious improvement for sequential read and write.
> > >
> > > Any comments are welcome. Thanks a lot.
> > >

Hi Baolin,

I refer to your code, and add the software queue support on i.MX based on the 
Linux next-20200602, but unfortunately, I see an obvious performance drop when 
change to use software queue.
I test on our imx850-evk board, with eMMC soldered.
From the result listing below, only random write has a little performance 
improve, for others, seems performance drop a lot.
I noticed that, this software queue need no-removable card, any other 
limitation? For host?
From the code logic, software queue complete the request in irq handler, seems 
no other change, I do not figure out why this will trigger a performance drop 
on my platform. Any comment would be appreciate! 
 
Without software queue, normal read/write method:
Sequential read: 56MB/s
Random read: 23.5MB/s
Sequential write: 43.7MB/s
Random write: 19MB/s

With mmc software queue:
Sequential read: 33.5MB/s
Random read: 18.7 MB/s
Sequential write: 37.7MB/s
Random write: 19.8MB/s


Here, I also list my change code to support software queue 

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index eb85237bf2d6..996b8cc5c381 100644
---

RE: [PATCH] Document: dt: binding: imx: Fix PAD_CTL_DSE_X*

2019-03-06 Thread BOUGH CHEN


> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月5日 11:35
> To: Stefan Agner ; BOUGH CHEN 
> Cc: Christina Quast ; feste...@gmail.com;
> shawn...@kernel.org; ker...@pengutronix.de; linus.wall...@linaro.org;
> robh...@kernel.org; mark.rutl...@arm.com; linux-g...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; BOUGH CHEN
> 
> Subject: RE: [PATCH] Document: dt: binding: imx: Fix PAD_CTL_DSE_X*
> 
> + Haibo
> 
> > From: Stefan Agner [mailto:ste...@agner.ch]
> > Sent: Tuesday, February 26, 2019 9:22 PM
> >
> > On 26.02.2019 13:21, Aisheng Dong wrote:
> > >> From: Christina Quast [mailto:cqu...@hanoverdisplays.com]
> > >> Sent: Saturday, February 23, 2019 1:01 AM
> > >>
> > >> In the iMX7d datasheet, the PAD_CTL_DSE_X* values are different
> > >> from the documentation.
> > >>
> > >
> > > It's a doc problem.
> > > Latest RM seems got updated.
> > >
> > > As here it's a reference definition in binding doc and device tree
> > > actually does not use it (IMX Pinctrl use raw data to set pad
> > > configuration). So it won't cause any compatibility issue to me.
> > >
> > > Please update the patch title to:
> > > dt-bindings: pinctrl: imx7d: x
> > >
> > > Otherwise:
> > > Ack-by: Dong Aisheng 
> >
> > Btw, I saw that imx7d-sdb.dts (and probably other i.MX 7 boards too)
> > use three different settings for usdhc pinctrl: 0x59, 0x5a and 0x5b
> > (for default, 100MHz and 200MHz respectively). One would expect that
> > higher frequency use higher driver strength (and this is the case for i.MX 
> > 6).
> > But with this new/corrected pad values this means we use x4, x2 and x6
> > for default, 100MHz and 200MHz respectively. This hardly seems right..?
> > Probably needs fixing too?
> >
> 
> Yes, that's true.
> Especially 100Mhz setting should be updated.
> 
> Haibo,
> Can you please help double check if X2 for 50Mhz and X4 for 100Mhz can work
> stably on MX7D SDB?
> If yes, we'd like to update the pad setting according to new RM version.
> 

X2 for high speed and x4 for ddr50/ddr52 can work stable on MX7D SDB.
I think all the 7D related dts need to fix this. Not sure whether 7S need this 
fix, can you confirm?

Best Regards
Haibo Chen
> Regards
> Dong Aisheng
> 
> > --
> > Stefan
> >
> >
> > >
> > > Regards
> > > Dong Aisheng
> > >
> > >> Signed-off-by: Christina Quast 
> > >> ---
> > >>  .../devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt   | 6 +++---
> > >>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git
> > >> a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> > >> b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> > >> index 277c3acb..8ac1d0851a0f 100644
> > >> ---
> > >> a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> > >> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.t
> > >> +++ xt
> > >> @@ -48,9 +48,9 @@ PAD_CTL_HYS (1 << 3)
> > >>  PAD_CTL_SRE_SLOW(1 << 2)
> > >>  PAD_CTL_SRE_FAST(0 << 2)
> > >>  PAD_CTL_DSE_X1  (0 << 0)
> > >> -PAD_CTL_DSE_X2  (1 << 0)
> > >> -PAD_CTL_DSE_X3  (2 << 0)
> > >> -PAD_CTL_DSE_X4  (3 << 0)
> > >> +PAD_CTL_DSE_X4  (1 << 0)
> > >> +PAD_CTL_DSE_X2  (2 << 0)
> > >> +PAD_CTL_DSE_X6  (3 << 0)
> > >>
> > >
> > >
> > >>  Examples:
> > >>  While iomuxc-lpsr is intended to be used by dedicated peripherals
> > >> to take
> > >> --
> > >> 2.20.1
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Please consider the environment before printing this email
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> The information transmitted is intended only for the person or
> > >> entity to which it is addressed and may contain confidential and/or
> > >> privileged material. Any review, retransmission, dissemination or
> > >> other use of, or taking of any action in reliance upon, this
> > >> information by persons or entities other than the intended
> > >> recipient is
> > prohibited.
> > >> If you received this in error, please contact the sender or
> > >> postmaster
> > >> (postmas...@hanoverdisplays.com) and delete the material from any
> > >> computer.
> > >> Although we routinely screen for viruses, addressees should check
> > >> this e-mail and any attachment for viruses. We make no warranty as
> > >> to absence of viruses in this e-mail or any attachments.
> > >> Our Company's email policy is to permit incidental personal use. If
> > >> this email is of a personal nature, it must not be relied upon as
> > >> expressing the views or opinions of the company.

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

2018-10-09 Thread Bough Chen

Hi Adam

Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!

Best Regards
Bough Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux Kernel Mailing List
> ; A.s. Dong ;
> haibo.c...@freescale.com; Fabio Estevam 
> Subject: Pinmuxing and SDHC speeds on sdhci-esdhc-imx
> 
> I have a question regarding the pinstate and the corresponding uhs_signaling.
> 
> The uhs_signaling shows a variety of timing options,
> 
>  MMC_TIMING_UHS_SDR12,  MMC_TIMING_UHS_SDR25:,
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104,
> MMC_TIMING_MMC_HS200,  MMC_TIMING_UHS_DDR50,
> MMC_TIMING_MMC_DDR52,  MMC_TIMING_MMC_HS400, and
> MMC_TIMING_LEGACY
> 
> However the esdhc_change_pinstate function only lists
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_DDR50,
> MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, and
> MMC_TIMING_MMC_HS40, and a defaut.
> 
> From what I can tell, this means that  MMC_TIMING_MMC_DDR52 uses the
> default pinmux.  I am wondering if it should use pins_100mhz.  We have an
> eMMC part that we want to operate at this point and it seems like it missing.
> If so, I can submit a patch.
> 
> It also seems like that SDR12, SDR25 use the default.  I assume this is OK.
> 
> adam

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

2018-10-09 Thread Bough Chen

Hi Adam

Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!

Best Regards
Bough Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux Kernel Mailing List
> ; A.s. Dong ;
> haibo.c...@freescale.com; Fabio Estevam 
> Subject: Pinmuxing and SDHC speeds on sdhci-esdhc-imx
> 
> I have a question regarding the pinstate and the corresponding uhs_signaling.
> 
> The uhs_signaling shows a variety of timing options,
> 
>  MMC_TIMING_UHS_SDR12,  MMC_TIMING_UHS_SDR25:,
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104,
> MMC_TIMING_MMC_HS200,  MMC_TIMING_UHS_DDR50,
> MMC_TIMING_MMC_DDR52,  MMC_TIMING_MMC_HS400, and
> MMC_TIMING_LEGACY
> 
> However the esdhc_change_pinstate function only lists
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_DDR50,
> MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, and
> MMC_TIMING_MMC_HS40, and a defaut.
> 
> From what I can tell, this means that  MMC_TIMING_MMC_DDR52 uses the
> default pinmux.  I am wondering if it should use pins_100mhz.  We have an
> eMMC part that we want to operate at this point and it seems like it missing.
> If so, I can submit a patch.
> 
> It also seems like that SDR12, SDR25 use the default.  I assume this is OK.
> 
> adam

RE: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled host

2017-09-24 Thread Bough Chen

> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, September 22, 2017 8:37 PM
> To: Ulf Hansson <ulf.hans...@linaro.org>
> Cc: linux-mmc <linux-...@vger.kernel.org>; linux-block  bl...@vger.kernel.org>; linux-kernel <linux-kernel@vger.kernel.org>; Bough
> Chen <haibo.c...@nxp.com>; Alex Lemberg <alex.lemb...@sandisk.com>;
> Mateusz Nowak <mateusz.no...@intel.com>; Yuliy Izrailov
> <yuliy.izrai...@sandisk.com>; Jaehoon Chung <jh80.ch...@samsung.com>;
> Dong Aisheng <donga...@gmail.com>; Das Asutosh
> <asuto...@codeaurora.org>; Zhangfei Gao <zhangfei@gmail.com>;
> Sahitya Tummala <stumm...@codeaurora.org>; Harjani Ritesh
> <rite...@codeaurora.org>; Venu Byravarasu <vbyravar...@nvidia.com>;
> Linus Walleij <linus.wall...@linaro.org>; Shawn Lin <shawn.lin@rock-
> chips.com>; Christoph Hellwig <h...@lst.de>
> Subject: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled
> host
> 
> From: Venkat Gopalakrishnan <venk...@codeaurora.org>
> 
> This patch adds CMDQ support for command-queue compatible hosts.
> 
> Command queue is added in eMMC-5.1 specification. This enables the
> controller to process upto 32 requests at a time.
> 
> Adrian Hunter contributed renaming to cqhci, recovery, suspend and resume,
> cqhci_off, cqhci_wait_for_idle, and external timeout handling.
> 
> Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
> Signed-off-by: Sujit Reddy Thumma <sthu...@codeaurora.org>
> Signed-off-by: Konstantin Dorfman <kdorf...@codeaurora.org>
> Signed-off-by: Venkat Gopalakrishnan <venk...@codeaurora.org>
> Signed-off-by: Subhash Jadavani <subha...@codeaurora.org>
> Signed-off-by: Ritesh Harjani <rite...@codeaurora.org>
> Signed-off-by: Adrian Hunter <adrian.hun...@intel.com>
> ---
>  drivers/mmc/host/Kconfig  |   13 +
>  drivers/mmc/host/Makefile |1 +
>  drivers/mmc/host/cqhci.c  | 1154
> +
>  drivers/mmc/host/cqhci.h  |  240 ++
>  4 files changed, 1408 insertions(+)
>  create mode 100644 drivers/mmc/host/cqhci.c  create mode 100644
> drivers/mmc/host/cqhci.h
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index
> 17afe1ad3a03..f2751465bc54 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -843,6 +843,19 @@ config MMC_SUNXI
> This selects support for the SD/MMC Host Controller on
> Allwinner sunxi SoCs.
> 
> +config MMC_CQHCI
> + tristate "Command Queue Host Controller Interface support"
> + depends on HAS_DMA
> + help
> +   This selects the Command Queue Host Controller Interface (CQHCI)
> +   support present in host controllers of Qualcomm Technologies, Inc
> +   amongst others.
> +   This controller supports eMMC devices with command queue support.
> +
> +   If you have a controller with this interface, say Y or M here.
> +
> +   If unsure, say N.
> +
>  config MMC_TOSHIBA_PCI
>   tristate "Toshiba Type A SD/MMC Card Interface Driver"
>   depends on PCI
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile index
> 2b5a8133948d..f01d9915304d 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -90,6 +90,7 @@ obj-$(CONFIG_MMC_SDHCI_ST)  += sdhci-st.o
>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)  += sdhci-pic32.o
>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB)  += sdhci-brcmstb.o
>  obj-$(CONFIG_MMC_SDHCI_OMAP) += sdhci-omap.o
> +obj-$(CONFIG_MMC_CQHCI)  += cqhci.o
> 
>  ifeq ($(CONFIG_CB710_DEBUG),y)
>   CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c new file
> mode 100644 index ..eb3c1695b0c7
> --- /dev/null
> +++ b/drivers/mmc/host/cqhci.c
> @@ -0,0 +1,1154 @@
> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>

RE: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled host

2017-09-24 Thread Bough Chen

> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, September 22, 2017 8:37 PM
> To: Ulf Hansson 
> Cc: linux-mmc ; linux-block  bl...@vger.kernel.org>; linux-kernel ; Bough
> Chen ; Alex Lemberg ;
> Mateusz Nowak ; Yuliy Izrailov
> ; Jaehoon Chung ;
> Dong Aisheng ; Das Asutosh
> ; Zhangfei Gao ;
> Sahitya Tummala ; Harjani Ritesh
> ; Venu Byravarasu ;
> Linus Walleij ; Shawn Lin  chips.com>; Christoph Hellwig 
> Subject: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled
> host
> 
> From: Venkat Gopalakrishnan 
> 
> This patch adds CMDQ support for command-queue compatible hosts.
> 
> Command queue is added in eMMC-5.1 specification. This enables the
> controller to process upto 32 requests at a time.
> 
> Adrian Hunter contributed renaming to cqhci, recovery, suspend and resume,
> cqhci_off, cqhci_wait_for_idle, and external timeout handling.
> 
> Signed-off-by: Asutosh Das 
> Signed-off-by: Sujit Reddy Thumma 
> Signed-off-by: Konstantin Dorfman 
> Signed-off-by: Venkat Gopalakrishnan 
> Signed-off-by: Subhash Jadavani 
> Signed-off-by: Ritesh Harjani 
> Signed-off-by: Adrian Hunter 
> ---
>  drivers/mmc/host/Kconfig  |   13 +
>  drivers/mmc/host/Makefile |1 +
>  drivers/mmc/host/cqhci.c  | 1154
> +
>  drivers/mmc/host/cqhci.h  |  240 ++
>  4 files changed, 1408 insertions(+)
>  create mode 100644 drivers/mmc/host/cqhci.c  create mode 100644
> drivers/mmc/host/cqhci.h
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index
> 17afe1ad3a03..f2751465bc54 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -843,6 +843,19 @@ config MMC_SUNXI
> This selects support for the SD/MMC Host Controller on
> Allwinner sunxi SoCs.
> 
> +config MMC_CQHCI
> + tristate "Command Queue Host Controller Interface support"
> + depends on HAS_DMA
> + help
> +   This selects the Command Queue Host Controller Interface (CQHCI)
> +   support present in host controllers of Qualcomm Technologies, Inc
> +   amongst others.
> +   This controller supports eMMC devices with command queue support.
> +
> +   If you have a controller with this interface, say Y or M here.
> +
> +   If unsure, say N.
> +
>  config MMC_TOSHIBA_PCI
>   tristate "Toshiba Type A SD/MMC Card Interface Driver"
>   depends on PCI
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile index
> 2b5a8133948d..f01d9915304d 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -90,6 +90,7 @@ obj-$(CONFIG_MMC_SDHCI_ST)  += sdhci-st.o
>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)  += sdhci-pic32.o
>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB)  += sdhci-brcmstb.o
>  obj-$(CONFIG_MMC_SDHCI_OMAP) += sdhci-omap.o
> +obj-$(CONFIG_MMC_CQHCI)  += cqhci.o
> 
>  ifeq ($(CONFIG_CB710_DEBUG),y)
>   CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c new file
> mode 100644 index ..eb3c1695b0c7
> --- /dev/null
> +++ b/drivers/mmc/host/cqhci.c
> @@ -0,0 +1,1154 @@
> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "cqhci.h"
> +
> +#define DCMD_SLOT 31
> +#define NUM_SLOTS 32
> +
> +struct cqhci_slot {
> + struct mmc_request *mrq;
> + unsigned int flags;
> +#define CQHCI_EXTERNAL_TIMEOUT   BIT(0)
> +#define CQHCI_COMPLETED  BIT(1)
> +#define CQHCI_HOST_CRC   BIT(2)
> +#define CQHCI_HOST_TIMEOUT   BIT(3)
> +#define CQHCI_HOST_OTHER BIT(4)
> +};
> +
> +static inline u8 *get_desc(struct cqhci_host *cq_host, u8 tag) {
> + return cq_host->desc_base + (tag * cq_host->slot_sz); }
> +
> +static inline u8 *get_link_desc(struct cqhci_host *cq_host, u8 tag) {
> + u8 *desc

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-15 Thread Bough Chen

> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Friday, January 13, 2017 7:23 PM
> To: Bough Chen <haibo.c...@nxp.com>
> Cc: Shawn Lin <shawn@rock-chips.com>; Clemens Gruber
> <clemens.gru...@pqgruber.com>; linux-...@vger.kernel.org; Linus Walleij
> <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
> Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Gary Bisson
> <gary.bis...@boundarydevices.com>; Fabio Estevam <feste...@gmail.com>;
> Shawn Guo <shawn...@kernel.org>
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> [...]
> 
> > Hi Ulf and Shawn,
> >
> > Aisheng and I debug this issue these days, and we find the root cause.
> > There are two things to describe.
> >
> > 1) voltage switch issue.  The properity "no-1-8-v" do not work for
> MMC_TIMING_MMC_DDR52.
> > This is another bug, we need to fix, but has no relation with the current 
> > bug.
> 
> I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
> corresponding DT binding "mmc-ddr-3_3v".
> Give me a day or so, then I will post it.
> 
> Likely it should help to resolve your issue, don't you think?

Seems Yes, I will test the patch when you post.

Best Regards,
Haibo Chen

> 
> [...]
> 
> Kind regards
> Uffe

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-15 Thread Bough Chen

> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Friday, January 13, 2017 7:23 PM
> To: Bough Chen 
> Cc: Shawn Lin ; Clemens Gruber
> ; linux-...@vger.kernel.org; Linus Walleij
> ; Adrian Hunter ; A.S.
> Dong ; linux-kernel@vger.kernel.org; Gary Bisson
> ; Fabio Estevam ;
> Shawn Guo 
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> [...]
> 
> > Hi Ulf and Shawn,
> >
> > Aisheng and I debug this issue these days, and we find the root cause.
> > There are two things to describe.
> >
> > 1) voltage switch issue.  The properity "no-1-8-v" do not work for
> MMC_TIMING_MMC_DDR52.
> > This is another bug, we need to fix, but has no relation with the current 
> > bug.
> 
> I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
> corresponding DT binding "mmc-ddr-3_3v".
> Give me a day or so, then I will post it.
> 
> Likely it should help to resolve your issue, don't you think?

Seems Yes, I will test the patch when you post.

Best Regards,
Haibo Chen

> 
> [...]
> 
> Kind regards
> Uffe

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-12 Thread Bough Chen

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, January 13, 2017 10:11 AM
> To: Ulf Hansson <ulf.hans...@linaro.org>; Clemens Gruber
> <clemens.gru...@pqgruber.com>
> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
> <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
> Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Bough Chen
> <haibo.c...@nxp.com>; Gary Bisson <gary.bis...@boundarydevices.com>;
> Fabio Estevam <feste...@gmail.com>; Shawn Guo <shawn...@kernel.org>
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Clemens Gruber
> <clemens.gru...@pqgruber.com> wrote:
> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>>> Hi,
> >>>>
> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
> >>>> from the eMMC on my i.MX6Q board.
> >>>>
> >>>> Details:
> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>>> supports eMMC 4.41 features and we did not implement voltage
> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>>> of the mmc-ddr or mmc-hs
> >>>> options) to the device tree. The bus-width is 8.
> >>>>
> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>>> tree, I get the following (repeating) errors at boot:
> >>>>
> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   14.569619] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>
> >>> it shows you always fail to get resp of sending status within the
> >>> expected period of time.
> >>>
> >>>
> >>>> [   14.639682] sdhci: Host ctl2: 0x
> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>>> [   14.649447] sdhci:
> ===
> >>>>
> >>>> This repeats a few times, then more information is shown at the bottom:
> >>>>
> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   86.899615] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>> [   86.969668] sdhci: Host ctl2: 0x
> >>>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-12 Thread Bough Chen

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, January 13, 2017 10:11 AM
> To: Ulf Hansson ; Clemens Gruber
> 
> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
> ; Adrian Hunter ; A.S.
> Dong ; linux-kernel@vger.kernel.org; Bough Chen
> ; Gary Bisson ;
> Fabio Estevam ; Shawn Guo 
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Clemens Gruber
>  wrote:
> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>>> Hi,
> >>>>
> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
> >>>> from the eMMC on my i.MX6Q board.
> >>>>
> >>>> Details:
> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>>> supports eMMC 4.41 features and we did not implement voltage
> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>>> of the mmc-ddr or mmc-hs
> >>>> options) to the device tree. The bus-width is 8.
> >>>>
> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>>> tree, I get the following (repeating) errors at boot:
> >>>>
> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   14.569619] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>
> >>> it shows you always fail to get resp of sending status within the
> >>> expected period of time.
> >>>
> >>>
> >>>> [   14.639682] sdhci: Host ctl2: 0x
> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>>> [   14.649447] sdhci:
> ===
> >>>>
> >>>> This repeats a few times, then more information is shown at the bottom:
> >>>>
> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   86.899615] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>> [   86.969668] sdhci: Host ctl2: 0x
> >>>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>>> [   86.979433] sdhci:
> ===
> >>>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>>> [   97.773859] m

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-10 Thread Bough Chen


> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Shawn Lin
> Sent: Monday, January 09, 2017 3:10 PM
> To: Clemens Gruber ; Shawn Lin
> ; linux-...@vger.kernel.org
> Cc: shawn@rock-chips.com; Ulf Hansson ; Linus
> Walleij ; Adrian Hunter ;
> A.S. Dong ; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>> Hi,
> >>>
> >>> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> >>> the eMMC on my i.MX6Q board.
> >>>
> >>> Details:
> >>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>> supports eMMC 4.41 features and we did not implement voltage
> >>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>> of the mmc-ddr or mmc-hs
> >>> options) to the device tree. The bus-width is 8.
> >>>
> >>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>> tree, I get the following (repeating) errors at boot:
> >>>
> >>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>
> >> it shows you always fail to get resp of sending status within the
> >> expected period of time.
> >>
> >>
> >>> [   14.639682] sdhci: Host ctl2: 0x
> >>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>> [   14.649447] sdhci:
> ===
> >>>
> >>> This repeats a few times, then more information is shown at the bottom:
> >>>
> >>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>> [   86.969668] sdhci: Host ctl2: 0x
> >>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>> [   86.979433] sdhci:
> ===
> >>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>
> >>> --
> >>>
> >>> After looking through the latest commits to mmc/core, I found the
> >>> culprit:
> >>> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> >>> CMD13 polling policy when switch to HS DDR mode")
> >>>
> >>> Reverting it fixes the problem. But I am unsure if that's the right
> >>> course of action?
> >>>
> >>> Feel free to send me patches for testing!
> >>
> >> By looking the changes itself, it should be good from the view of spec.
> >> Maybe you could try the patch below, but don't beat me if that
> >> doesn't help at all. :)
> >>
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card
> *card)
> >>EXT_CSD_BUS_WIDTH,
> >>ext_csd_bits,
> >>card->ext_csd.generic_cmd6_time,
> >> -  MMC_TIMING_MMC_DDR52,

RE: eMMC boot problem: switch to bus width 8 ddr failed

2017-01-10 Thread Bough Chen


> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Shawn Lin
> Sent: Monday, January 09, 2017 3:10 PM
> To: Clemens Gruber ; Shawn Lin
> ; linux-...@vger.kernel.org
> Cc: shawn@rock-chips.com; Ulf Hansson ; Linus
> Walleij ; Adrian Hunter ;
> A.S. Dong ; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>> Hi,
> >>>
> >>> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> >>> the eMMC on my i.MX6Q board.
> >>>
> >>> Details:
> >>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>> supports eMMC 4.41 features and we did not implement voltage
> >>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>> of the mmc-ddr or mmc-hs
> >>> options) to the device tree. The bus-width is 8.
> >>>
> >>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>> tree, I get the following (repeating) errors at boot:
> >>>
> >>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>
> >> it shows you always fail to get resp of sending status within the
> >> expected period of time.
> >>
> >>
> >>> [   14.639682] sdhci: Host ctl2: 0x
> >>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>> [   14.649447] sdhci:
> ===
> >>>
> >>> This repeats a few times, then more information is shown at the bottom:
> >>>
> >>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>> [   86.969668] sdhci: Host ctl2: 0x
> >>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>> [   86.979433] sdhci:
> ===
> >>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>
> >>> --
> >>>
> >>> After looking through the latest commits to mmc/core, I found the
> >>> culprit:
> >>> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> >>> CMD13 polling policy when switch to HS DDR mode")
> >>>
> >>> Reverting it fixes the problem. But I am unsure if that's the right
> >>> course of action?
> >>>
> >>> Feel free to send me patches for testing!
> >>
> >> By looking the changes itself, it should be good from the view of spec.
> >> Maybe you could try the patch below, but don't beat me if that
> >> doesn't help at all. :)
> >>
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card
> *card)
> >>EXT_CSD_BUS_WIDTH,
> >>ext_csd_bits,
> >>card->ext_csd.generic_cmd6_time,
> >> -  MMC_TIMING_MMC_DDR52,
> >> +  0,
> >>true, true, true);
> >> if (err) {
> >> pr_err("%s: switch

RE: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.

2016-11-02 Thread Bough Chen

+Aisheng.

Best Regards
Haibo Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Leonardo G. Veiga
> Sent: Tuesday, November 01, 2016 11:58 PM
> To: ulf.hans...@linaro.org
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ste...@agner.ch; raul.mu...@toradex.com; leonardo.ve...@toradex.com
> Subject: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
> 
> From: Leonardo Graboski Veiga 
> 
> The 1-bit operation mode, enabled by seeting the 'bus-width' property of the
> device tree 'esdhc' node to <1>, not work while using SD card.
> 
> The behavior is only noticed when only the data pin 0 is connected to the
> hardware. A series of kernel errors are printed to the console, all of them
> returning the following error message followed by some explanation:
> mmcblk0: error -84 transferring data
> 
> If four data lines are connected, it ignores the device-tree property and 
> works
> in 4-bit mode of operation without errors. The hardware used for testing does
> not support 8-bit mode.
> 
> Check the 'bus-width' property and if set to <1>, enable the
> SDHCI_QUIRK_FORCE_1_BIT_DATA quirk.
> 
> Signed-off-by: Leonardo Graboski Veiga 
> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-
> esdhc-imx.c
> index c9fbc4c3..88d7d22 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1003,6 +1003,10 @@ sdhci_esdhc_imx_probe_dt(struct platform_device
> *pdev,
>   host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>   }
> 
> + if (!of_property_read_u32(np, "bus-width", 
> >max_bus_width)
> + && boarddata->max_bus_width == 1)
> + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
> +
>   /* call to generic mmc_of_parse to support additional capabilities */
>   ret = mmc_of_parse(host->mmc);
>   if (ret)
> --
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.

2016-11-02 Thread Bough Chen

+Aisheng.

Best Regards
Haibo Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Leonardo G. Veiga
> Sent: Tuesday, November 01, 2016 11:58 PM
> To: ulf.hans...@linaro.org
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ste...@agner.ch; raul.mu...@toradex.com; leonardo.ve...@toradex.com
> Subject: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
> 
> From: Leonardo Graboski Veiga 
> 
> The 1-bit operation mode, enabled by seeting the 'bus-width' property of the
> device tree 'esdhc' node to <1>, not work while using SD card.
> 
> The behavior is only noticed when only the data pin 0 is connected to the
> hardware. A series of kernel errors are printed to the console, all of them
> returning the following error message followed by some explanation:
> mmcblk0: error -84 transferring data
> 
> If four data lines are connected, it ignores the device-tree property and 
> works
> in 4-bit mode of operation without errors. The hardware used for testing does
> not support 8-bit mode.
> 
> Check the 'bus-width' property and if set to <1>, enable the
> SDHCI_QUIRK_FORCE_1_BIT_DATA quirk.
> 
> Signed-off-by: Leonardo Graboski Veiga 
> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-
> esdhc-imx.c
> index c9fbc4c3..88d7d22 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1003,6 +1003,10 @@ sdhci_esdhc_imx_probe_dt(struct platform_device
> *pdev,
>   host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>   }
> 
> + if (!of_property_read_u32(np, "bus-width", 
> >max_bus_width)
> + && boarddata->max_bus_width == 1)
> + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
> +
>   /* call to generic mmc_of_parse to support additional capabilities */
>   ret = mmc_of_parse(host->mmc);
>   if (ret)
> --
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

RE: [PATCH 05/15] input: touchscreen: imx6ul_tsc: Remove set but unused variable 'value'

RE: [RFC PATCH v3.1 03/27] mmc: core: UHS-II support, skip set_chip_select()

RE: [PATCH 21/22] arm64: dts: imx8qxp: Remove i.MX7 compatible from USDHC

RE: [PATCH v9 0/5] Add MMC software queue support

RE: [PATCH v9 0/5] Add MMC software queue support

RE: [PATCH v9 0/5] Add MMC software queue support

RE: [PATCH] Document: dt: binding: imx: Fix PAD_CTL_DSE_X*

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

RE: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled host

RE: [PATCH V9 14/15] mmc: cqhci: support for command queue enabled host

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: eMMC boot problem: switch to bus width 8 ddr failed

RE: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.

RE: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.

21 matches

Site Navigation

Mail list logo

Footer information