From: Jon Hunter <jonathanh@nvidia.com>
To: Krishna Yarlagadda <kyarlagadda@nvidia.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"linux-tegra@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" <robh+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] spi: tegra210-quad: Add wait polling support
Date: Thu, 17 Mar 2022 09:44:34 +0000 [thread overview]
Message-ID: <edcae0c1-a576-1560-5ecb-9dcf08d8ead3@nvidia.com> (raw)
In-Reply-To: <DM4PR12MB57692EB17ABCA36E0515412EC3129@DM4PR12MB5769.namprd12.prod.outlook.com>
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?
Jon
--
nvpublic
next prev parent reply other threads:[~2022-03-17 9:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 1:20 [PATCH 0/3] spi: tegra quad: Add Tegra Grace features Krishna Yarlagadda
2022-03-17 1:20 ` [PATCH 1/3] spi: tegra210-quad: Multi-cs support Krishna Yarlagadda
2022-03-17 15:00 ` kernel test robot
2022-03-17 1:20 ` [PATCH 2/3] spi: tegra210-quad: Add wait polling support Krishna Yarlagadda
2022-03-17 8:54 ` Jon Hunter
2022-03-17 9:02 ` Krishna Yarlagadda
2022-03-17 9:44 ` Jon Hunter [this message]
2022-03-17 15:26 ` Jon Hunter
2022-03-17 18:00 ` Krishna Yarlagadda
2022-03-17 18:09 ` Mark Brown
2022-03-17 9:31 ` Jon Hunter
2022-03-17 1:20 ` [PATCH 3/3] spi: dt-bindings: Add wait state polling flag Krishna Yarlagadda
2022-03-17 8:42 ` Mikko Perttunen
2022-03-17 9:03 ` Krishna Yarlagadda
2022-03-23 20:13 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edcae0c1-a576-1560-5ecb-9dcf08d8ead3@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=ashishsingha@nvidia.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kyarlagadda@nvidia.com \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=skomatineni@nvidia.com \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.