On Tue, Feb 23, 2016 at 09:30:40PM +0100, Leif Liddy wrote:
> I'm beginning to understand how this is meant to work.
>
> spi_pxa2xx_platform should by itself be able to setup the SPI controller.
> **it has the ACPI ID for it
> { "INT33C1", LPSS_LPT_SSP }
>
> When I modprobe spi_pxa2xx_platform
> pxa2xx_spi_probe never gets called, there must be an issue with:
> acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match)
That's fine - the device is a PCI device and does not require ACPI ID.
However, the PCI part of the driver creates this platform device for
spi_pxa2xx_platform.
> Ok, so I've installed Ismo's one line patch
>
> dmesg log of "modprobe spi_pxa2xx_pci"
>
> pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0
> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors
> dmaengine: __dma_request_channel: success (dma0chan0)
> pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1
> dmaengine: private_candidate: dma0chan0 busy
> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors
> dmaengine: __dma_request_channel: success (dma0chan1)
Difference is that with Ismo's patch you actually have ACPI handle for
the device so it tries to use ACPI to look for the DMA channels.
> without the patch:
>
> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors
> dmaengine: __dma_request_channel: success (dma0chan0)
> dmaengine: private_candidate: dma0chan0 busy
> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors
> dmaengine: __dma_request_channel: success (dma0chan1)
Here it uses hardcoded indices instead. In both cases result is the
same.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
