NXP imx6ull nonalignment buffer question
Bough Chen
haibo.chen at nxp.com
Tue Feb 28 01:15:44 PST 2023
> -----Original Message-----
> From: Michael Nazzareno Trimarchi <michael at amarulasolutions.com>
> Sent: 2023年2月28日 15:43
> To: Bough Chen <haibo.chen at nxp.com>
> Cc: Shawn Guo <shawnguo at kernel.org>; Fabio Estevam
> <festevam at gmail.com>; LKML <linux-kernel at vger.kernel.org>;
> linux-arm-kernel <linux-arm-kernel at lists.infradead.org>;
> linux-mmc at vger.kernel.org; Ulf Hansson <ulf.hansson at linaro.org>
> Subject: Re: NXP imx6ull nonalignment buffer question
>
> Hi
>
> On Tue, Feb 28, 2023 at 8:25 AM Bough Chen <haibo.chen at nxp.com> wrote:
> >
> > > -----Original Message-----
> > > From: Michael Nazzareno Trimarchi <michael at amarulasolutions.com>
> > > Sent: 2023年2月27日 19:22
> > > To: Bough Chen <haibo.chen at nxp.com>
> > > Cc: Shawn Guo <shawnguo at kernel.org>; Fabio Estevam
> > > <festevam at gmail.com>; LKML <linux-kernel at vger.kernel.org>;
> > > linux-arm-kernel <linux-arm-kernel at lists.infradead.org>;
> > > linux-mmc at vger.kernel.org; Ulf Hansson <ulf.hansson at linaro.org>
> > > Subject: Re: NXP imx6ull nonalignment buffer question
> > >
> > > Hi Bough
> > >
> > > On Fri, Jan 13, 2023 at 8:19 AM Michael Nazzareno Trimarchi
> > > <michael at amarulasolutions.com> wrote:
> > > >
> > > > Hi
> > > >
> > > > On Fri, Jan 13, 2023 at 4:30 AM Bough Chen <haibo.chen at nxp.com>
> wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Michael Nazzareno Trimarchi
> > > > > > <michael at amarulasolutions.com>
> > > > > > Sent: 2023年1月9日 21:02
> > > > > > To: Bough Chen <haibo.chen at nxp.com>; Shawn Guo
> > > > > > <shawnguo at kernel.org>; Fabio Estevam <festevam at gmail.com>;
> > > > > > LKML <linux-kernel at vger.kernel.org>
> > > > > > Cc: linux-arm-kernel <linux-arm-kernel at lists.infradead.org>;
> > > > > > linux-mmc at vger.kernel.org; Ulf Hansson
> > > > > > <ulf.hansson at linaro.org>
> > > > > > Subject: NXP imx6ull nonalignment buffer question
> > > > > >
> > > > > > Hi Haibo
> > > > > >
> > > > > > Working on imx6ulz design and found that if I send a sdio
> > > > > > packet using the sdio_writesb the adma driver tries to handle
> > > > > > it with two dma descriptors. The first one filled with the
> > > > > > bytes up to 3 to cover the misalign and then another buffer
> > > > > > descriptor
> > > > > >
> > > > > > offset = (SDHCI_ADMA2_ALIGN - (addr & SDHCI_ADMA2_MASK)) &
> > > > > > SDHCI_ADMA2_MASK;
> > > > > > if (offset) {
> > > > > > if (data->flags & MMC_DATA_WRITE) {
> > > > > > buffer =
> sdhci_kmap_atomic(sg);
> > > > > > memcpy(align, buffer, offset);
> > > > > >
> sdhci_kunmap_atomic(buffer);
> > > > > > }
> > > > > >
> > > > > > /* tran, valid */
> > > > > > __sdhci_adma_write_desc(host, &desc,
> > > > > > align_addr,
> > > > > > offset,
> > > > > > ADMA2_TRAN_VALID);
> > > > > >
> > > > > > BUG_ON(offset > 65536);
> > > > > >
> > > > > > align += SDHCI_ADMA2_ALIGN;
> > > > > > align_addr += SDHCI_ADMA2_ALIGN;
> > > > > >
> > > > > > addr += offset;
> > > > > > len -= offset;
> > > > > > }
> > > > > >
> > > > > > In 48.7.4 Data Length Setting
> > > > > > For either ADMA (ADMA1 or ADMA2) transfer, the data in the
> > > > > > data buffer must be word aligned, so the data length set in
> > > > > > the descriptor must
> > > be a multiple of 4.
> > > > > > I have noticed that this code does not work as expected.
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > My understanding is: for the sentence " the data in the data
> > > > > buffer must be
> > > word aligned", this means the start address of the data must be word
> > > aligned, but not limit the data length.
> > > > >
> > > >
> > > > Ok. My specific problem is that this seems not working on imx6ulz,
> > > > I found the problem working on a wifi chipset, if the request gets
> > > > split for no-alignment of the data in two dma descriptors, the
> > > > chipset does not reply to me.
> > > > Anyway, I will retest it with the upstream kernel again. I will
> > > > check better and I will follow up if any more question
> > > >
> > >
> > > I have done some tests and I need this quirk
> > > SDHCI_QUIRK_32BIT_ADMA_SIZE on imx6ulz cpu and I think that it applies
> even on imx6ull.
> > > Wifi can work only if the data on the sdio are aligned or we use
> > > interrupt mode for no-alignment data. I did not find an errata and I
> > > can not add as a quirk without a confirmation
> > >
> >
> > Hi Michael,
> >
> > If use the quirk SDHCI_QUIRK_32BIT_ADMA_SIZE, for the length
> > no-alignment data, it will change to use PIO mode.
> >
> > Here, can you give some more details about this issue? When the dma
> > descriptor contain the no-alignment length of data, is there any
> > register dump on the console? Or meet any timeout? Or there any ADMA
> length mismatch happen?
>
> I don't have a logic analyzer or oscilloscope but from the point of view of the wifi,
> the data does not arrive or the transaction is not complete. Anyway I will check
> back again on 6.2
>
> diff --git a/drivers/net/wireless/ti/wl18xx/wl18xx.h
> b/drivers/net/wireless/ti/wl18xx/wl18xx.h
> index b642e0c437bb..97cd41a75762 100644
> --- a/drivers/net/wireless/ti/wl18xx/wl18xx.h
> +++ b/drivers/net/wireless/ti/wl18xx/wl18xx.h
> @@ -32,14 +32,14 @@
> #define WL18XX_MAX_LINKS 16
>
> struct wl18xx_priv {
> - /* buffer for sending commands to FW */
> - u8 cmd_buf[WL18XX_CMD_MAX_SIZE];
> -
> struct wl18xx_priv_conf conf;
>
> /* Index of last released Tx desc in FW */
> u8 last_fw_rls_idx;
>
> + /* buffer for sending commands to FW */
> + u8 cmd_buf[WL18XX_CMD_MAX_SIZE];
> +
> /* number of keys requiring extra spare mem-blocks */
> int extra_spare_key_count;
> };
>
> One way to try on some wifi is to move this buffer. As the code is done this
> section is kmalloc and data is copied to the buffer from cmd side.
> After I retest I will send an RFC patch
>
> Michael
Hi Michael，
Can you add the following change and test again? This change only use DMA mode, disable ADMA mode.
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 58f042fdd4f4..95dfbb6cb3d5 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -282,7 +282,7 @@ static const struct esdhc_soc_data usdhc_imx6sx_data = {
static const struct esdhc_soc_data usdhc_imx6ull_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
- | ESDHC_FLAG_ERR010450
+ | ESDHC_FLAG_ERR010450 | ESDHC_FLAG_ERR004536
| ESDHC_FLAG_STATE_LOST_IN_LPMODE,
};
Haibo Chen
>
>
> >
> > Besides, did you try DMA mode instead of the ADMA mode? Can DMA mode
> work for your case?
> >
> > Best Regards
> > Haibo Chen
> >
> > > Michael
>
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> michael at amarulasolutions.com
> __________________________________
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172
> info at amarulasolutions.com
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ama
> rulasolutions.com%2F&data=05%7C01%7Chaibo.chen%40nxp.com%7C50cbd90
> 99dcf4b4931fe08db195f6cdd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C638131669856911217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=YaqpFLQzTZn%2Fgo%2BNOCsTedJFq7%2F%2F2YGwQxvxJsI4Wyc%
> 3D&reserved=0
More information about the linux-arm-kernel
mailing list