[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <718b9d6b-bef3-a344-dce2-1086dad23b29@loongson.cn>
Date: Thu, 20 Apr 2023 15:27:24 +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 v8 2/2] spi: loongson: add bus driver for the loongson spi
controller
在 2023/4/19 下午8:36, Mark Brown 写道:
> On Wed, Apr 19, 2023 at 02:22:02PM +0800, Yinbo Zhu wrote:
>
>> + clk = devm_clk_get(dev, NULL);
>> + if (!IS_ERR(clk))
>> + spi->clk_rate = clk_get_rate(clk);
>
> I notice we never actually enable this clock. I guess it's some system
> clock which is needed for basic system functionality which is always on
> and we just need the rate but it looks a bit off.
The 2k1000 SoC's spi clock was used boot clock, which boot clock
was gain from system clock(ref clk) that by division and dobuling.
Currently, the spi clock was enabled in firmware, so driver doesn't need
to enable it.
>
>> +static int __maybe_unused loongson_spi_suspend(struct device *dev)
>> +{
>> + struct loongson_spi *loongson_spi;
>> + struct spi_master *master;
>> +
>> + master = dev_get_drvdata(dev);
>> + loongson_spi = spi_master_get_devdata(master);
>> +
>> + loongson_spi->spcr = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_SPCR_REG);
>> + loongson_spi->sper = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_SPER_REG);
>> + loongson_spi->spsr = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_SPSR_REG);
>> + loongson_spi->para = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_PARA_REG);
>> + loongson_spi->sfcs = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_SFCS_REG);
>> + loongson_spi->timi = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_TIMI_REG);
>> +
>> + spi_master_suspend(master);
>
> This saves the register state before suspending at the SPI level but
> that means that if there were any transfers in progress then the
> register state might be changed by the active transfers after we've
> saved the state, meaning we might restore a state for an active
> transfer. The spi_master_suspend() should go first, then save the
> register state. The resume is OK, it's just the suspend.
okay, I got it.
Thanks.
>
Powered by blists - more mailing lists