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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47E60C54FB9 for ; Mon, 20 Nov 2023 10:18:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233057AbjKTKSG (ORCPT ); Mon, 20 Nov 2023 05:18:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232565AbjKTKSF (ORCPT ); Mon, 20 Nov 2023 05:18:05 -0500 Received: from mail11.truemail.it (mail11.truemail.it [IPv6:2001:4b7e:0:8::81]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBE14A7; Mon, 20 Nov 2023 02:18:01 -0800 (PST) Received: from francesco-nb.int.toradex.com (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id 2B1E4207FD; Mon, 20 Nov 2023 11:18:00 +0100 (CET) Date: Mon, 20 Nov 2023 11:17:56 +0100 From: Francesco Dolcini To: linux@bigler.io Cc: Francesco Dolcini , Stefan Moring , Linux regressions mailing list , Mark Brown , linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org Subject: Re: spi: imx: Increase imx51 ecspi burst length fails on imx6dl and imx8mm Message-ID: References: <8a415902c751cdbb4b20ce76569216ed@mail.infomaniak.com> <2fcdd99eee9ee4f5d34fa1abab2f51bb@mail.infomaniak.com> <86566391db9c5044f1a082bc8ec697a2@mail.infomaniak.com> <6322fd4c1967a518310140c35ab34f65@mail.infomaniak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6322fd4c1967a518310140c35ab34f65@mail.infomaniak.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 20, 2023 at 10:33:38AM +0100, linux@bigler.io wrote: > I run the test and it worked fine. The transmitted data matches with > the recived data, no diff. ok, thanks for confirming. At least we are on the same page. > BUT!!! on the MDIO it is completly different !!! > When I request to send 4kB Data I measure on the line 16384Byte. > > The data is again 3Dummy Bytes followed by the databyte. > So the error symetic on send and recive ok, that's annoying. I wonder if the loopback test could be improved to spot such kind of issues, maybe we could verify if the execution time is reasonable given the SPI clock frequency and the payload size ... Francesco