[PATCH v3] spi: orion.c: Add direct access mode

Mark Brown broonie at kernel.org
Tue Apr 12 12:27:36 PDT 2016


On Tue, Apr 12, 2016 at 01:43:27PM +0200, Stefan Roese wrote:
> On 11.04.2016 12:57, Mark Brown wrote:
> > On Thu, Apr 07, 2016 at 02:06:51PM +0200, Stefan Roese wrote:

> >> +		if (count > da->size) {
> >> +			dev_err(&spi->dev,
> >> +				"max transfer size exceeded (%d > %d)\n",
> >> +				count, da->size);
> >> +			return 0;
> >> +		}

> > This seems obviously broken, we're neither returning an error nor
> > falling back to PIO here but instead silently ignoring the transfer.

> Its not silently ignored (dev_err above) but I agree, we should be
> able to fall back to PIO mode in this condition. I'll change this in
> v4.

Logging is not useful error handling, software doesn't see it and will
continue on potentially corrupting data.

> > Do bidirectional transfers work properly with this method (how much
> > incoming data can we queue up, is there memory backing the whole
> > region?), and are we guaranteed that the transfer finished by the time
> > we return?

> Frankly, I have no idea if bidirectional transfers work properly.
> I have no means to test it. As stated in the commit text, this 
> direct mode is only tested for TX as this is the mode that I'm using
> for the FPGA bitstream programming. So its perhaps best to remove the
> RX path completely from the direct mode for now. It can be added
> once someone has a board / platform that can make use of this direct
> RX mode.

That seems a lot safer since if recieve doesn't work that's likely to
upset things like flashes.

> >> +               spi->direct_access[cs].vaddr = devm_ioremap_resource(&pdev->dev,
> >> +                                                                    r);
> >> +               if (IS_ERR(spi->direct_access[cs].vaddr)) {

> > I seem to be missing where we configure the hardware to connect the
> > windows to the chip selects.  We just seem to map the windows but never
> > otherwise interact with the hardware.

> The connection between the CS and the window is done in the DT. All
> is now implemented as Arnd has suggested:

Writing something in the DT won't magically configure anything in the
hardware which is (as I said) the bit I'm missing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160412/2896a43e/attachment.sig>


More information about the linux-arm-kernel mailing list