Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2638177rwb; Fri, 9 Dec 2022 04:46:17 -0800 (PST) X-Google-Smtp-Source: AA0mqf5fuCo+Q55UDsHgw/2oSqwaeLVB4aKLSVK6N3fP+TeD4VFR+JbNb3Gms59HQ9RXKrLuUwcK X-Received: by 2002:a05:6402:1bc5:b0:46b:ecb8:6862 with SMTP id ch5-20020a0564021bc500b0046becb86862mr4950518edb.20.1670589977376; Fri, 09 Dec 2022 04:46:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670589977; cv=none; d=google.com; s=arc-20160816; b=I8w0OSq25hY/VTFTxB3qdwfVFpiaFkLsyAu1/9j44+ut03f9t5xKtVVr8apXHBUAq8 ZwD1hQtgnu3Fu01iH73wxsxyPGWbi20Rxm66Dw2ylAI46ITNTKtdKoPL0YL97Zq5Ykst VDMqkBp1tW4Onc52emJT5SrcWqjFGd7ZABFouyqhU73f9xAmJhbutFBlzhJzlsT2Cu9E sGlU5qRKw1I/w4EaTY8OSaKSSyiPYfiXhyYKqQJ5SVLTWwq8RjXKCqafO+griT6SsNwK zwWVYs56hynCwbPcOnenjnCzRD91s8TSIUZrhRuHA/tULHgFr4Hf+xuAIEljOYU7RRx7 F3Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=5KTzAWLXF9/p8Tke756CXgEY9F/IXvsOASPCVMdqayw=; b=k19ezMsy5EAx4VjS3aYrQRDoz06dxcqG48OXqkKFtz1wUT50ie5Pvkj4Di2oVC3uhc yMkQggkggE05whpZAGfEN8sXjPV4vuBaX8moHWvD10FlBsKGv6C6e1ltc1a+vhwPF4+x 0vHGv4utdZX5ThFdm8vxAaVlZb5X/lqHHXyF/Gklel8//icyIUUQPqPm/NgHABKhlozL K6fsY5QKom+ZyMSKtH5L1G5Gpiw0lArJ3Rdkmj3t4dj+8AMOQcbiMMn1w7QhReiL+AeU Ltgq9XBdaV8SUYVYjQjs1E7F7OEc+j922tvOfSk/3ANVy2hxXmTXw5tYIAfn/3sgyrjy g5VA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j7-20020a05640211c700b0046c0137c466si1827724edw.293.2022.12.09.04.45.56; Fri, 09 Dec 2022 04:46:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229762AbiLIMOB (ORCPT + 75 others); Fri, 9 Dec 2022 07:14:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229568AbiLIMOA (ORCPT ); Fri, 9 Dec 2022 07:14:00 -0500 Received: from mx1.emlix.com (mx1.emlix.com [136.243.223.33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59BCF43848; Fri, 9 Dec 2022 04:13:57 -0800 (PST) Received: from mailer.emlix.com (p5098be52.dip0.t-ipconnect.de [80.152.190.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.emlix.com (Postfix) with ESMTPS id 279FB63F3C; Fri, 9 Dec 2022 13:13:55 +0100 (CET) Date: Fri, 9 Dec 2022 13:13:54 +0100 From: Edmund Berenson To: Serge Semin Cc: Lukasz Zemla , Mark Brown , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] spi: dw: select SS0 when gpio cs is used Message-ID: <20221209121354.fcpwh54khx4y5g7q@emlix.com> References: <20221202094859.7869-1-edmund.berenson@emlix.com> <20221209114625.32ww2laxfr72uqnb@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221209114625.32ww2laxfr72uqnb@mobilestation> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Serge, On Fri, Dec 09, 2022 at 02:46:25PM +0300, Serge Semin wrote: > Hello Edmund > > On Fri, Dec 02, 2022 at 10:48:59AM +0100, Edmund Berenson wrote: > > SER register contains only 4-bit bit-field for enabling 4 SPI chip selects. > > If gpio cs are used the cs number may be >= 4. To ensure we do not write > > outside of the valid area, we choose SS0 in case of gpio cs to start > > spi transfer. > > Next time please don't forget to add me to the whole series Cc-list. I > am missing the patch #2 in my inbox. > I am sorry, I probably made some mistake when sending the mail. I forwarded you patch 2 as well. > > > > Co-developed-by: Lukasz Zemla > > Signed-off-by: Lukasz Zemla > > Signed-off-by: Edmund Berenson > > --- > > drivers/spi/spi-dw-core.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/spi/spi-dw-core.c b/drivers/spi/spi-dw-core.c > > index 99edddf9958b..57c9e384d6d4 100644 > > --- a/drivers/spi/spi-dw-core.c > > +++ b/drivers/spi/spi-dw-core.c > > @@ -94,6 +94,10 @@ void dw_spi_set_cs(struct spi_device *spi, bool enable) > > { > > struct dw_spi *dws = spi_controller_get_devdata(spi->controller); > > bool cs_high = !!(spi->mode & SPI_CS_HIGH); > > + u8 enable_cs = 0; > > + > > + if (!spi->cs_gpiod) > > + enable_cs = spi->chip_select; > > > > /* > > * DW SPI controller demands any native CS being set in order to > > @@ -103,7 +107,7 @@ void dw_spi_set_cs(struct spi_device *spi, bool enable) > > * support active-high or active-low CS level. > > */ > > if (cs_high == enable) > > > - dw_writel(dws, DW_SPI_SER, BIT(spi->chip_select)); > > + dw_writel(dws, DW_SPI_SER, BIT(enable_cs)); > > No, it's not that easy. By applying this patch we'll get a regression > for the platforms which make use of both the GPIO-based and native > chip-selects. Consider the next platform setup: > +--------------+ > | SoC X | > | | +-------------+ > | DW SSI CS0-+----+ SPI-slave 0 | > | | +-------------+ > | | +-------------+ > | GPIOn-+----+ SPI-slave 1 | > | | +-------------+ > +--------------+ > > If we apply this patch then the communications targeted to the > SPI-slave 1 will also reach the SPI-slave 0 device, which isn't what > we'd want. > > That's why currently the DW SSI driver activates the native CS line > with the corresponding ID irrespective whether it is a GPIO-based > CS or a native one. Okay that is actually true... but we will have to guard against CS>4 as only two bits are reserved for cs in the register. If both gpio and native cs are used at least one native cs has to be empty otherwise we will have at least one double activation. I am not sure if there is a "clean" way to determine which native cs is unused inside the driver. Do you think it would be an acceptable workaround to add an entry to the device tree like native-gpio cs? > > -Serge(y) > > > else > > dw_writel(dws, DW_SPI_SER, 0); > > } > > -- > > 2.37.4 > >