| Message ID | 1557810235-16401-2-git-send-email-skomatineni@nvidia.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | additional features to Tegra SPI | expand |
On 14/05/2019 06:03, Sowjanya Komatineni wrote: > This patch adds support for GPIO based CS control through SPI core > function spi_set_cs. > > Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Can you elaborate on the use-case where this is needed? I am curious what platforms are using this and why they would not use the dedicated CS signals. Cheers Jon
> Subject: Re: [PATCH V5 1/4] spi: tegra114: add support for gpio based CS > On 14/05/2019 06:03, Sowjanya Komatineni wrote: > > This patch adds support for GPIO based CS control through SPI core > > function spi_set_cs. > > > > Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> > Can you elaborate on the use-case where this is needed? I am curious what platforms are using this and why they would not use the dedicated CS signals. > > Cheers > Jon Tegra SPI doesn’t support inter byte delay directly to meet some SPI slave requirements. So we use GPIO control CS in parallel with a dummy HW CS and use inactive cycles delay of SPI controller to mimic inter byte delay. Currently we don’t have specific SPI slave on upstream supported platforms but considering raspberry PI header where SPI I/F is exposed to pins it allows user to connect any SPI slave and this helps for some slaves that need specific inter byte delay. Thanks sowjanya
On 14/05/2019 18:18, Sowjanya Komatineni wrote: >> Subject: Re: [PATCH V5 1/4] spi: tegra114: add support for gpio based CS > >> On 14/05/2019 06:03, Sowjanya Komatineni wrote: >>> This patch adds support for GPIO based CS control through SPI core >>> function spi_set_cs. >>> >>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >> Can you elaborate on the use-case where this is needed? I am curious what platforms are using this and why they would not use the dedicated CS signals. >> >> Cheers >> Jon > > Tegra SPI doesn’t support inter byte delay directly to meet some SPI slave requirements. > So we use GPIO control CS in parallel with a dummy HW CS and use inactive cycles delay of SPI controller to mimic inter byte delay. > > Currently we don’t have specific SPI slave on upstream supported platforms but considering raspberry PI header where SPI I/F is exposed to pins it allows user to connect any SPI slave and this helps for some slaves that need specific inter byte delay. Maybe add these details to the commit message so that it is clear what the motivation for this is. Thanks Jon
On Tue, May 14, 2019 at 05:18:48PM +0000, Sowjanya Komatineni wrote: > Tegra SPI doesn’t support inter byte delay directly to meet some SPI slave requirements. > So we use GPIO control CS in parallel with a dummy HW CS and use inactive cycles delay of SPI controller to mimic inter byte delay. Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. Please don't ignore review comments, people are generally making them for a reason and are likely to have the same concerns if issues remain unaddressed. Having to repeat the same comments can get repetitive and make people question the value of time spent reviewing. If you disagree with the review comments that's fine but you need to reply and discuss your concerns so that the reviewer can understand your decisions.
> > Tegra SPI doesn’t support inter byte delay directly to meet some SPI slave requirements. > > So we use GPIO control CS in parallel with a dummy HW CS and use inactive cycles delay of SPI controller to mimic inter byte delay. > Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. I did changed but looks like it didn't made diff. Will try with different email client. > Please don't ignore review comments, people are generally making them for a reason and are likely to have the same concerns if issues remain unaddressed. Having to repeat the same comments can get repetitive and make people question the value of time spent reviewing. If you disagree with the review comments that's fine but you need to reply and discuss your concerns so that the reviewer can understand your decisions. If you are referring to comment from Jon on updating commit, I didn't ignored. I am just waiting if any more comments from you or others before posting updated patch. But I see you applied patch now. So how should I post with updated commit?
On Wed, May 15, 2019 at 11:24:22AM +0000, Sowjanya Komatineni wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. > I did changed but looks like it didn't made diff. Will try with different email client. Yeah, the behaviour is exactly the same - it's not only not wrapping your content but also reflowing quoted content. > > Please don't ignore review comments, people are generally making them > for a reason and are likely to have the same concerns if issues remain > unaddressed. Having to repeat the same comments can get repetitive and > make people question the value of time spent reviewing. If you disagree > with the review comments that's fine but you need to reply and discuss > your concerns so that the reviewer can understand your decisions. > If you are referring to comment from Jon on updating commit, I didn't ignored. I am just waiting if any more comments from you or others before posting updated patch. That was more about the continuing issues with mail formatting. > But I see you applied patch now. So how should I post with updated commit? No, it's fine. It would have been better to have a clearer commit message but I think the usage makes it reasonably clear in the final code why that was done and honestly "the hardware doesn't support all the features we need to properly control devices" is an extremely common reason for using GPIO chip selects even when hardware support is available.
On Wed, May 15, 2019 at 11:40:41AM +0000, Sowjanya Komatineni wrote: > I tried few settings before sending V5 too but didn't made diff. > Will try with different email client. > > What email client are you using? I personally use mutt. I know people also use things like Thunderbird and Evolution successfully. There should be other people at nVidia you can ask about how they get things set up I guess?
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c index b1f31bb16659..f47417dd9edb 100644 --- a/drivers/spi/spi-tegra114.c +++ b/drivers/spi/spi-tegra114.c @@ -776,6 +776,10 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device *spi, } else tegra_spi_writel(tspi, command1, SPI_COMMAND1); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 1); + command1 |= SPI_CS_SW_HW; if (spi->mode & SPI_CS_HIGH) command1 |= SPI_CS_SW_VAL; @@ -864,6 +868,10 @@ static int tegra_spi_setup(struct spi_device *spi) } spin_lock_irqsave(&tspi->lock, flags); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + val = tspi->def_command1_reg; if (spi->mode & SPI_CS_HIGH) val &= ~SPI_CS_POL_INACTIVE(spi->chip_select); @@ -893,6 +901,10 @@ static void tegra_spi_transfer_end(struct spi_device *spi) struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master); int cs_val = (spi->mode & SPI_CS_HIGH) ? 0 : 1; + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + if (cs_val) tspi->command1_reg |= SPI_CS_SW_VAL; else @@ -1199,6 +1211,7 @@ static int tegra_spi_probe(struct platform_device *pdev) master->max_speed_hz = 25000000; /* 25MHz */ /* the spi->mode bits understood by this driver: */ + master->use_gpio_descriptors = true; master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST | SPI_TX_DUAL | SPI_RX_DUAL | SPI_3WIRE; master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
This patch adds support for GPIO based CS control through SPI core function spi_set_cs. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> --- drivers/spi/spi-tegra114.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)