[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2337f45f-c513-1b10-ccfc-766363c5fd02@loongson.cn>
Date: Thu, 23 Mar 2023 20:46:19 +0800
From: zhuyinbo <zhuyinbo@...ngson.cn>
To: Mark Brown <broonie@...nel.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Jianmin Lv <lvjianmin@...ngson.cn>,
wanghongliang@...ngson.cn, Liu Peibao <liupeibao@...ngson.cn>,
loongson-kernel@...ts.loongnix.cn, zhuyinbo@...ngson.cn
Subject: Re: [PATCH v2 2/2] spi: loongson: add bus driver for the loongson spi
controller
在 2023/3/21 下午8:08, Mark Brown 写道:
> On Tue, Mar 21, 2023 at 10:54:32AM +0800, zhuyinbo wrote:
>> 在 2023/3/20 下午8:52, Mark Brown 写道:
>>> No, that doesn't help if setup() reconfigures the controller while it's
>>> doing a transfer. The issue is that the controller might be put into
>>> the wrong mode or run at the wrong speed.
>> sorry, I don't got that why cpu still can call setup's critical region when
>> cpu call transfer_one to transfer spi data.
>> when I added a spin_lock for setup and transfer_one then setup and
>> transfer_one's critical region cann't be called
>> simultaneously as I know, because the their lock was same lock.
> Think what happens if the two SPI devices have different configurations
> - for example, a different SPI mode. The register state won't be
> corrupted but the devices will still end up seeing misconfigured SPI
> transfers.
I think add following change and that issue what you said will can be
fixed, in addition, the spin_lock
was also not needed. Do you think so?
@@ -101,8 +101,10 @@ static int loongson_spi_setup(struct spi_device *spi)
if (spi->chip_select >= spi->master->num_chipselect)
return -EINVAL;
+ loongson_spi->hz = 0;
+ loongson_spi->mode &= SPI_NO_CS;
+
spin_lock(&loongson_spi->lock);
- loongson_spi_update_state(loongson_spi, spi, NULL);
loongson_spi_set_cs(spi, 1);
Powered by blists - more mailing lists