lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <VE1PR04MB6638D7886CBADAFF47E5497C89190@VE1PR04MB6638.eurprd04.prod.outlook.com>
Date:   Mon, 10 Feb 2020 12:28:43 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Schrempf Frieder <frieder.schrempf@...tron.de>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: RE: [PATCH v5 11/15] dmaengine: imx-sdma: fix ecspi1 rx dma not work
 on i.mx8mm

On 2020/02/06 Schrempf Frieder <frieder.schrempf@...tron.de> wrote:
> 
> Hi,
> On 27.09.19 03:55, Robin Gong wrote:
> > On 2019-9-25 22:53 Schrempf Frieder <frieder.schrempf@...tron.de> wrote:
> >> On 25.09.19 13:26, Robin Gong wrote:
> >>> On 2019-9-24 21:28 Schrempf Frieder <frieder.schrempf@...tron.de>
> >> wrote:
> >>>>
> >>>> Hi Robin,
> >>>>
> >>>>> From: Robin Gong <yibin.gong at nxp.com>
> >>>>>
> >>>>> Because the number of ecspi1 rx event on i.mx8mm is 0, the
> >>>>> condition check ignore such special case without dma channel
> >>>>> enabled, which caused
> >>>>> ecspi1 rx works failed. Actually, no need to check
> >>>>> event_id0/event_id1 and replace checking 'event_id1' with
> >>>>> 'DMA_DEV_TO_DEV', so that configure
> >>>>> event_id1 only in case DEV_TO_DEV.
> >>>>>
> >>>>> Signed-off-by: Robin Gong <yibin.gong at nxp.com>
> >>>>> Acked-by: Vinod Koul <vkoul at kernel.org>
> >>>>
> >>>> I have a custom board with i.MX8MM and SPI flash on ecspi1. I'm
> >>>> currently testing with v5.3 and as SPI didn't work, I tried two
> >>>> different
> >> things:
> >>>>
> >>>> 1. Removing 'dmas' and 'dma-names' from the ecspi1 node in
> >> imx8mm.dtsi,
> >>>>       to use PIO instead of DMA. This works as expected and the driver
> >>>>       boots with the following messages:
> >>>>
> >>>>           spi_imx 30820000.spi: dma setup error -19, use pio
> >>>>           m25p80 spi0.0: mx25v8035f (1024 Kbytes)
> >>>>           spi_imx 30820000.spi: probed
> >>>>
> >>>> 2. Applying your patchset and use DMA. In this case, the flash also
> >>>>       works fine, but there are some error messages printed while
> >> booting:
> >>>>
> >>>>           spi_master spi0: I/O Error in DMA RX
> >>>>           m25p80 spi0.0: SPI transfer failed: -110
> >>>>           spi_master spi0: failed to transfer one message from queue
> >>>>           m25p80 spi0.0: mx25v8035f (1024 Kbytes)
> >>>>           spi_imx 30820000.spi: probed
> >>>>
> >>>> It would be great to get your patches merged and fix SPI + DMA, but
> >>>> for i.MX8MM, we need to get rid of the error messages. Do you have
> >>>> an idea, what's wrong?
> >>
> >>> Could you check if the length of spi message is bigger than
> >>> fifo_size during spi_nor probe? If yes, at that time maybe sdma firmware
> not loaded.
> >>> if (transfer->len < spi_imx->devtype_data->fifo_size)
> >>
> >> Indeed, most of the transfers triggered by the SPI NOR dirver are
> >> below fifo_size and work fine, but some are bigger. The transfers
> >> therefore try to use DMA, but the firmware is not loaded yet.
> >>
> >> How is this supposed to work? Shouldn't all transfers use PIO as long
> >> as the SDMA firmware is not loaded yet?
> > Yes, for ecspi should work with ram script, it's better check if sdma
> > firmware is ready in spi_imx_dma_configure(), need modification in sdma
> driver too.
> > I'll create another patch after this patch set accepted.
> 
> This still seems to be broken upstream. Is anyone working on fixing SPI
> + DMA for i.MX8MM? Otherwise I will send a patch that removes the DMA
> from the ecspi nodes in the devicetree.
Sorry, Frieder, my patch set has been blocked for so long time because I revert
some patches and need get commit from patch owner, unfortunately, I didn't
get any feedback from them although I got ACK from maintainer. I'll pick up
them, rebase and resend it these days, then could address your issue later.  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ