Hi Sebastian, Pavel,
On 12/12/2021 02:26, Merlijn Wajer wrote:
> <snip>
>
> So it sounds like setting the dev->dma_mask in the driver is the right
> fix, as Pavel suggested. The commit returns an error when the mask is
> NULL and that is probably what causes the oops later on. I'll try look
> at fixing this soon, unless someone beats me to it. I suppose we'll want
> this potential fix in the stable trees as well.
Looking at this again I wonder if DMA just wasn't working already.
Reverting commit f959dcd6ddfd29235030e8026471ac1b022ad2b0 /
4e57482e8440fac7137832629109730ea4b267aa ("dma-direct: Fix potential
NULL pointer dereference") just makes the ssi driver fall back to pio
calls, as far as I can tell, and perhaps the dma_capable change of the
commit causes ssi to now actually use DMA, which fails.
I've tried to set the dma mask in ssi_start_dma but all that goes is rid
of the first warning:
> diff --git a/drivers/hsi/controllers/omap_ssi_port.c b/drivers/hsi/controllers/omap_ssi_port.c
> index a0cb5be246e1..db2df77d79f6 100644
> --- a/drivers/hsi/controllers/omap_ssi_port.c
> +++ b/drivers/hsi/controllers/omap_ssi_port.c
> @@ -227,6 +227,8 @@ static int ssi_start_dma(struct hsi_msg *msg, int lch)
> return -EREMOTEIO;
> }
>
> + dma_set_mask_and_coherent(&ssi->device, DMA_BIT_MASK(32));
All the other problems remain (no one cared about the irq and NULL
pointer). Perhaps some IRQ is not set up for DMA completion (just
guessing here?)
However, looking at the omap3-n900.dts it looks to me that the ssi_pins
definition suggests that it should use pio, rather than DMA.
Does either of you recall if DMA was ever used on the N900, or does the
offending commit just cause DMA to be used by accident?
Regards,
Merlijn
