Messages in this thread | | | Date | Thu, 17 Mar 2022 15:26:28 +0000 | Subject | Re: [PATCH 2/3] spi: tegra210-quad: Add wait polling support | From | Jon Hunter <> |
| |
On 17/03/2022 09:44, Jon Hunter wrote: > > On 17/03/2022 09:02, Krishna Yarlagadda wrote: >>> -----Original Message----- >>> From: Jonathan Hunter <jonathanh@nvidia.com> >>> Sent: 17 March 2022 14:25 >>> To: Krishna Yarlagadda <kyarlagadda@nvidia.com>; broonie@kernel.org; >>> thierry.reding@gmail.com; linux-spi@vger.kernel.org; linux- >>> tegra@vger.kernel.org; Ashish Singhal <ashishsingha@nvidia.com> >>> Cc: Sowjanya Komatineni <skomatineni@nvidia.com>; Laxman Dewangan >>> <ldewangan@nvidia.com>; robh+dt@kernel.org; >>> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org >>> Subject: Re: [PATCH 2/3] spi: tegra210-quad: Add wait polling support >>> >>> >>> On 17/03/2022 01:20, Krishna Yarlagadda wrote: >>>> Controller can poll for wait state inserted by TPM device and >>>> handle it. >>>> >>>> Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com> >>>> --- >>>> drivers/spi/spi-tegra210-quad.c | 31 +++++++++++++++++++++++++++++++ >>>> 1 file changed, 31 insertions(+) >>>> >>>> diff --git a/drivers/spi/spi-tegra210-quad.c >>>> b/drivers/spi/spi-tegra210-quad.c >>>> index a2e225e8f7f0..ecf171bfcdce 100644 >>>> --- a/drivers/spi/spi-tegra210-quad.c >>>> +++ b/drivers/spi/spi-tegra210-quad.c >>>> @@ -142,6 +142,7 @@ >>>> >>>> #define QSPI_GLOBAL_CONFIG 0X1a4 >>>> #define QSPI_CMB_SEQ_EN BIT(0) >>>> +#define QSPI_TPM_WAIT_POLL_EN BIT(1) >>>> >>>> #define QSPI_CMB_SEQ_ADDR 0x1a8 >>>> #define QSPI_ADDRESS_VALUE_SET(X) (((x) & 0xFFFF) << 0) >>>> @@ -165,11 +166,13 @@ struct tegra_qspi_soc_data { >>>> bool has_dma; >>>> bool cmb_xfer_capable; >>>> bool cs_count; >>>> + bool has_wait_polling; >>>> }; >>>> >>>> struct tegra_qspi_client_data { >>>> int tx_clk_tap_delay; >>>> int rx_clk_tap_delay; >>>> + bool wait_polling; >>>> }; >>>> >>>> struct tegra_qspi { >>>> @@ -833,6 +836,11 @@ static u32 tegra_qspi_setup_transfer_one(struct >>>> spi_device *spi, struct spi_tran >>>> else >>>> command1 |= QSPI_CONTROL_MODE_0; >>>> >>>> + if (tqspi->soc_data->cmb_xfer_capable) >>>> + command1 &= ~QSPI_CS_SW_HW; >>>> + else >>>> + command1 |= QSPI_CS_SW_HW; >>>> + >>>> if (spi->mode & SPI_CS_HIGH) >>>> command1 |= QSPI_CS_SW_VAL; >>>> else >>>> @@ -917,6 +925,7 @@ static int tegra_qspi_start_transfer_one(struct >>>> spi_device *spi, >>>> >>>> static struct tegra_qspi_client_data >>>> *tegra_qspi_parse_cdata_dt(struct spi_device *spi) >>>> { >>>> + struct tegra_qspi *tqspi = spi_master_get_devdata(spi->master); >>>> struct tegra_qspi_client_data *cdata; >>>> >>>> cdata = devm_kzalloc(&spi->dev, sizeof(*cdata), GFP_KERNEL); >>>> @@ -927,6 +936,11 @@ static struct tegra_qspi_client_data >>>> *tegra_qspi_parse_cdata_dt(struct spi_devic >>>> &cdata->tx_clk_tap_delay); >>>> device_property_read_u32(&spi->dev, "nvidia,rx-clk-tap-delay", >>>> &cdata->rx_clk_tap_delay); >>>> + if (tqspi->soc_data->has_wait_polling) >>>> + cdata->wait_polling = device_property_read_bool >>>> + (&spi->dev, >>>> + "nvidia,wait-polling"); >>>> + >>> >>> >>> This looks odd. Why do we need this device-tree property if it is >>> already specified in the SoC data? >> Soc data specifies chip is capable of wait-polling. >> Wait polling still has to be selected on slave devices that can >> support it. >> I will add one line description for the properties in next version. > > > I can't say I am familiar with this, but it seems that the ideal > solution would be able to detect if this needs to be enabled depending > on the device connected. Is that not possible?
Also, given that Grace supports 4 chip-selects per device, how does this work if there is TPM connected to one chip-select and something else connected to another?
Jon
-- nvpublic
| |