Ardelean, Alexandru
unread,Dec 4, 2019, 2:18:23 AM12/4/19Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Jonathan...@huawei.com, bro...@kernel.org, kerne...@googlegroups.com, de...@driverdev.osuosl.org, linu...@vger.kernel.org, devic...@vger.kernel.org, gre...@linuxfoundation.org, ji...@kernel.org, la...@metafoo.de, Hennerich, Michael, pme...@pmeerw.net, Popa, Stefan Serban, rodri...@gmail.com, linux-...@vger.kernel.org, knaa...@gmx.de
There might be a few other options, which would require some SPI OF change.
One example (for spi-cpha):
if (of_property_read_u32(nc, "spi-cpha", &tmp) == 0) {
spi->mode |= SPI_CPHA_OVERRIDE;
if (tmp)
spi->mode |= SPI_CPHA;
} else
if (of_property_read_bool(nc, "spi-cpha"))
spi->mode |= SPI_CPHA;
Or another option could be:
if (of_property_read_bool(nc, "spi-cpha-override")) {
spi->mode |= SPI_CPHA_OVERRIDE;
if
(of_property_read_bool(nc, "spi-cpha"))
spi->mode |= SPI_CPHA;
Naturally, this would require that spi_setup() checks SPI_CPHA_OVERRIDE and
doesn't set SPI_CPHA if SPI_CPHA_OVERRIDE is set.
Or maybe, a more complete solution would be an "spi-mode-conv" driver.
Similar to the fixed-factor-clock clk driver, which just does a computation
based on values from the DT.
To tell the truth, this would be a great idea, because we have something
like a passive 3-wire-to-4-wire HDL converter. This requires that the
driver be configured in 3-wire mode, the SPI controller in normal 4-wire.
That's because the SPI framework does a validation of the supported modes
(for the SPI controller) and invalidates what the device wants (which is
very reasonable).
An "spi-mode-conv" driver would also handle this 3-wire-4-wire dance, and
the level inversions, and other (similar) things.
Thoughts?
Alex
>
> Jonathan
>
>