Messages in this thread | | | Date | Mon, 15 Jun 2020 16:55:49 +0530 | From | Vinod Koul <> | Subject | Re: [PATCH v1 RFC 1/2] spi: introduce fallback to pio |
| |
Hi Robin,
On 15-06-20, 08:59, Robin Gong wrote: > On 2020/06/15 15:20 Vinod Koul <vkoul@kernel.org> wrote:
> > > Yes, but both assume spi controller driver could detect such dma > > > failure before dmaengine_prep_*(). Let's wait Vinod's comment for that > > > if dmaengine_slave_config could keep direction. > > > > The direction is already in the prep_ call, so sending in dmaengine_slave_config > > is not required, pls pass it in the prep_ call > Hi Vinod, > Is there any way to let the device driver to know dma controller is ready > (in sdma case is sdma firmware loaded or not)before prep_call? Hence, spi core > could map dma buffer or not. Prep_call is too late for spi core since the buffers > have been already mapped.
Can you use .device_alloc_chan_resources for that? This is where all the resource allocation for a channel should happen...
> From my view, seems dmaengine_slave_config is the only one...Further, > sdma need direction in dmaengine_slave_config phase, because currently > what's the tx/rx script used on sdma channel is decided not only peripheral_type > but also direction. For example, spi tx dma is running ram script to workaround > ecspi ERR009165 while rx dma is running rom script, so only spi tx dma channel > depends on sdma firmware loaded(now that could be detect by ' load_address > < 0' in sdma_load_context() and prep_ call finally). > I knew direction is deprecated in dmaengine_slave_config, but that's really > very useful for sdma to check if firmware loaded and spi core could get it earlier > before prep_call(fallback to PIO if dma is not ready).
I think that is wrong expectation, dmaengine_slave_config should pass the slave_config to driver and nothing else. The relevant action should be taken in respective prep_ calls here, so that should be fixed as well
-- ~Vinod
| |