From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17497C18E7D for ; Wed, 22 May 2019 10:10:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E334020863 for ; Wed, 22 May 2019 10:10:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729122AbfEVKKp (ORCPT ); Wed, 22 May 2019 06:10:45 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:55723 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728424AbfEVKKo (ORCPT ); Wed, 22 May 2019 06:10:44 -0400 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1hTOCd-0003cl-Ks; Wed, 22 May 2019 12:10:31 +0200 Message-ID: <1558519829.2624.40.camel@pengutronix.de> Subject: Re: [PATCH v4 00/14] add ecspi ERR009165 for i.mx6/7 soc family From: Lucas Stach To: Robin Gong , "robh@kernel.org" , "broonie@kernel.org" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "festevam@gmail.com" , "mark.rutland@arm.com" , "vkoul@kernel.org" , "dan.j.williams@intel.com" , "u.kleine-koenig@pengutronix.de" , "plyatov@gmail.com" , "catalin.marinas@arm.com" Cc: "linux-spi@vger.kernel.org" , dl-linux-imx , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , "devicetree@vger.kernel.org" , "kernel@pengutronix.de" Date: Wed, 22 May 2019 12:10:29 +0200 In-Reply-To: <1558548188-1155-1-git-send-email-yibin.gong@nxp.com> References: <1558548188-1155-1-git-send-email-yibin.gong@nxp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: dmaengine@vger.kernel.org Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Hi Robin, Am Mittwoch, den 22.05.2019, 09:59 +0000 schrieb Robin Gong: >   There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO > transfer to be send twice in DMA mode. Please get more information from: > https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding > new sdma ram script which works in XCH  mode as PIO inside sdma instead > of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be > exist on all legacy i.mx6/7 soc family before i.mx6ul. > NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/ > 6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips > still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi' > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata > or not. >   The first two reverted patches should be the same issue, though, it > seems 'fixed' by changing to other shp script. Hope Sean or Sascha could > have the chance to test this patch set if could fix their issues. >   Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work > on i.mx8mm because the event id is zero. > > PS: >   Please get sdma firmware from below linux-firmware and copy it to your > local rootfs /lib/firmware/imx/sdma. > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma I haven't tested this so asking the obvious question: what happens when this series is applied without the RAM script being present on the system? Will it render SPI unusable? I guess so since it changes the flow between the SPI core and DMA controller. Can we somehow detect that SDMA isn't using the correct RAM script and fall back to PIO mode in the SPI driver in that case? Currently using the RAM script is not an option in a lot of use-cases, as it still breaks serial DMA support. The fix for the serial issue really needs to be remove the broken serial script from the RAM firmware, not change the serial driver to deal with the broken behavior introduced by the RAM script. Regards, Lucas