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.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 6687BC433DF for ; Tue, 9 Jun 2020 10:04:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 390CB207C3 for ; Tue, 9 Jun 2020 10:04:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DeVu3eS3"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="sIUaJN5w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 390CB207C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date: In-Reply-To:Subject:To:From:References:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=hoBiQEbKL0xC+on65mKxPdcUxWvLqsZq/unyCzm79iI=; b=DeVu3eS3DtF1J8IKkxiPrQMtF7 xc5eAHZyg6OBIUgM5McoQWsQ8fo3J1ABD0I6rmo36tSLUelyxaFjYkKli7pOiUBcEUYzTXi3qXzdy LkC4J+8X3Eo2tLH0hiyN3jRl4QTFqKQoG9Zx5pLugb7nPk1s7QU+51LmVr8wMV5PaIYfIzvMVp1Be LIVrUIIELNmGuMteZ5ornYDX2Q7Fg3wlPqJ8eobNs3BFPiT8U75A7ySN6CMcX0H4ZX5f8iSWBCuYe BUpttkWX4P0Smk1oj4ed7J00nnPe9EY0xKYSWFdODnrhAmk0PSMpsc0HM1p7xuBiD8vkt9R5tw5KS HgFC+6CQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jib7h-0004Tc-QE; Tue, 09 Jun 2020 10:04:49 +0000 Received: from esa5.microchip.iphmx.com ([216.71.150.166]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jib7e-0004Sb-IH for linux-arm-kernel@lists.infradead.org; Tue, 09 Jun 2020 10:04:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1591697086; x=1623233086; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=ZmXV2xgrfpgFum+8pnc7CH3E62B5WGtZ4Qsdsa4m4hg=; b=sIUaJN5wDMP/ZTqCtezfhWgNgt4zFMW8i1wEgiWDwMVGkUlA9hb8RSDv i1NNXOa6NqkhiEzgHnz2HjD3r1kklQtPXaWetboaaDQmLAxBoQvYttd2c oRvnZxjwkMyDOT1/Ztn48oY+Okaj6BmlxWinTNZDqHseuzD3kuotZPJE/ rcNncgyQDl00sePnyV+hF5LmE02LpiP69renXrMT1CQvSPQfKnrl+yQ9b Hl9TaYGFUBs/YOm2dv7u+zC02xUy66DyPb4FWhQ7L6XVUShRbpS2XSOS7 h2gauNniRAXbgb3chIL1xOSEcVKS4lxOg10xhteg1lz7nQvomtNzYHdbT A==; IronPort-SDR: YwfQayJCWJ5disVGuhwB4XgBX+zV/UTIpQhysY2EftvltOzRimEwGnDy+nJvg4FaXL9vJQMnsc ktp1x/nn09CZPLehYdvFL4WVtfV7y2ABqp9XNiZryYISfbPH88po1cGe/BbrTQ3zI3Ak12Nv5i kxx0bEYX8xoDsK+3WnyOrDZpiKp7a+VdMfwFrSzw/3kzHF2FdIJ2IHHF0wyBaAqgWKfHJSaNrT CTNV1D0DVAyrDjNYKu4fatvQkVC1YCHrmGiMYOS7DpHv6WCcxuyRcptny0Sj0N2S0b5D2pIMfG rTw= X-IronPort-AV: E=Sophos;i="5.73,491,1583218800"; d="scan'208";a="78721100" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa5.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 09 Jun 2020 03:04:35 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 9 Jun 2020 03:04:30 -0700 Received: from soft-dev15.microsemi.net.microchip.com (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 9 Jun 2020 03:04:27 -0700 References: <20200513140031.25633-1-lars.povlsen@microchip.com> <20200513140031.25633-3-lars.povlsen@microchip.com> <20200602193931.vl36k3c6uyiaizah@mobilestation> From: Lars Povlsen To: Serge Semin Subject: Re: [PATCH 02/10] spi: dw: Add support for RX sample delay register In-Reply-To: <20200602193931.vl36k3c6uyiaizah@mobilestation> Date: Tue, 9 Jun 2020 12:04:26 +0200 Message-ID: <87k10gimhh.fsf@soft-dev15.microsemi.net> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200609_030446_620913_FA59B0F7 X-CRM114-Status: GOOD ( 19.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Cc: devicetree@vger.kernel.org, Alexandre Belloni , linux-kernel@vger.kernel.org, Serge Semin , linux-spi@vger.kernel.org, SoC Team , Mark Brown , linux-arm-kernel@lists.infradead.org, Microchip Linux Driver Support , Lars Povlsen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Serge Semin writes: > On Wed, May 13, 2020 at 04:00:23PM +0200, Lars Povlsen wrote: >> This add support for the RX_SAMPLE_DLY register. If enabled in the >> Designware IP, it allows tuning of the rx data signal by means of an >> internal rx sample fifo. >> >> The register is located at offset 0xf0, and if the option is not >> enabled in the IP, changing the register will have no effect. >> >> Reviewed-by: Alexandre Belloni >> Signed-off-by: Lars Povlsen >> --- >> drivers/spi/spi-dw.c | 7 +++++++ >> drivers/spi/spi-dw.h | 2 ++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c >> index e572eb34a3c1a..32997f28fa5bb 100644 >> --- a/drivers/spi/spi-dw.c >> +++ b/drivers/spi/spi-dw.c >> @@ -81,6 +81,9 @@ static ssize_t dw_spi_show_regs(struct file *file, char __user *user_buf, >> "DMATDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMATDLR)); >> len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len, >> "DMARDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMARDLR)); > >> + len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len, >> + "RX_SAMPLE_DLY: \t0x%08x\n", >> + dw_readl(dws, DW_SPI_RX_SAMPLE_DLY)); > > debugfs_reg32 interface is now utilized in the driver to dump the registers > state. So this will have to be converted to just a new entry in the > dw_spi_dbgfs_regs array. > Ok, I'll have a look at this. >> len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len, >> "=================================\n"); >> >> @@ -315,6 +318,10 @@ static int dw_spi_transfer_one(struct spi_controller *master, >> spi_set_clk(dws, chip->clk_div); >> } >> > >> + /* Apply RX sample delay, iff requested (nonzero) */ > > s/iff/if > >> + if (dws->rx_sample_dly) >> + dw_writel(dws, DW_SPI_RX_SAMPLE_DLY, dws->rx_sample_dly); >> + >> dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE); >> dws->dma_width = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE); >> >> diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h >> index 1bf5713e047d3..ed6e47b3f50da 100644 >> --- a/drivers/spi/spi-dw.h >> +++ b/drivers/spi/spi-dw.h >> @@ -31,6 +31,7 @@ >> #define DW_SPI_IDR 0x58 >> #define DW_SPI_VERSION 0x5c >> #define DW_SPI_DR 0x60 >> +#define DW_SPI_RX_SAMPLE_DLY 0xf0 >> #define DW_SPI_CS_OVERRIDE 0xf4 >> >> /* Bit fields in CTRLR0 */ >> @@ -111,6 +112,7 @@ struct dw_spi { >> >> int cs_override; >> u32 reg_io_width; /* DR I/O width in bytes */ > >> + u8 rx_sample_dly; /* RX fifo tuning (option) */ > > This doesn't seem like a good place for this parameter. The sample delay is > SPI-slave specific. So as I see it, the parameter should be moved to the > chip_data. > Yes, I got that in other comments, and you are right I guess. I will apply that approach of having rx_sample_dly per SPI slave. ---Lars > -Sergey > >> u16 bus_num; >> u16 num_cs; /* supported slave numbers */ >> void (*set_cs)(struct spi_device *spi, bool enable); >> -- >> 2.26.2 >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Lars Povlsen, Microchip _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel