Thread (23 messages) flat view 23 messages, 5 authors, 2016-11-18

Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs

From: Marek Vasut <marex@denx.de>
Date: 2016-11-09 18:48:09
Also in: linux-spi, lkml

On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
On 09/11/16 05:01, Marek Vasut wrote:
quoted
On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
quoted
quoted
quoted
quoted
On the whole, I don't think the zero-length transfers are too
egregiously bad, and all the alternatives seem worse to me.
So why not turn the CS line into GPIO and just toggle the GPIO?
Does that work with *all* SPI controllers?
It does not - no. See my other email.
And is that line an actual CS of that lattice chip or a generic input
which almost works like CS?
I mean a generic output vs. a special CS output built into the SPI
master of the application processor. Take a look at how spi_set_cs(..)
works:
No. I am asking whether the signal which is INPUT on the iCE40 side is
really a chipselect signal for the SPI bus OR something which mostly
behaves/looks like a chipselect but is not really a chipselect.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c?id=refs/tags/v4.9-rc4#n695


static void spi_set_cs(struct spi_device *spi, bool enable)
{
    if (spi->mode & SPI_CS_HIGH)
        enable = !enable;

    if (gpio_is_valid(spi->cs_gpio))
        gpio_set_value(spi->cs_gpio, !enable);
    else if (spi->master->set_cs)
        spi->master->set_cs(spi, !enable);
}

So on some SPI masters, spi->master->set_cs is handled separately from
normal GPIOs. Hence why I want to use this machinery, rather than doing
it with a GPIO.
This is not relevant. FYI: using separate GPIO as a SPI chip select has
it's own problems.

-- 
Best regards,
Marek Vasut
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help