On Wed, 2019-12-04 at 17:00 +0000, Mark Brown wrote:
> On Wed, Dec 04, 2019 at 07:18:15AM +0000, Ardelean, Alexandru wrote:
>
> > 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;
>
> We could also do this with a separate flag saying that the wire
> format is forced from DT rather than having one per setting.
>
I will admit that [since you seem to incline towards this approach], I am
also inclined to consider it over the spi-mode-conv driver.
And also since you're saying that the driver would be harder to achieve.
I'll see about an implementation for this flag and come back for a review
[on it].
[Until then] I also owe you some more "delay_usecs" cleanup in other
subsystems.
Thanks
Alex
> > 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).
>
> This is harder to achieve here because we don't have drivers for
> random bits of the wire format...
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
