Hi,

On 08/08/2019 13:10, Christoph Hellwig wrote:

The omapfb platform devices does not have a DMA mask set. The traditional arm DMA code ignores, but the generic dma-direct/swiotlb has stricter checks and thus fails mappings without a DMA mask. As we use swiotlb for arm with LPAE now, omap needs to catch up and actually set a DMA mask.

Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs") Reported-by: "H. Nikolaus Schaller" hns@goldelico.com Tested-by: "H. Nikolaus Schaller" hns@goldelico.com Signed-off-by: Christoph Hellwig hch@lst.de

---

drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 561c4812545b..2c8abf07e617 100644 --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c @@ -232,6 +232,8 @@ void omap_fbdev_init(struct drm_device *dev) if (!priv->num_pipes) return;

• dma_coerce_mask_and_coherent(dev->dev, DMA_BIT_MASK(32));
• fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL); if (!fbdev) goto fail;

We do call dma_set_coherent_mask() in omapdrm's probe() (in omap_drv.c), but apparently that's not enough anymore. Changing that call to dma_coerce_mask_and_coherent() removes the WARN. I can create a patch for that, or Christoph can respin this one.

I am not too familiar with the dma mask handling, so maybe someone can educate:

dma_coerce_mask_and_coherent() overwrites dev->dma_mask. Isn't that a bad thing? What if the platform has set dev->dma_mask, and the driver overwrites it with its value? Or who is supposed to set dev->dma_mask?

Tomi