replace dma_mmap_attrs() with dma_mmap_coherent() kindly. BTW, fix indentation. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Helge Deller <deller@gmx.de>
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. This does not cover all drivers; some actually modify the fbops struct, for example to adjust for different configurations, and others do more involved things that I'd rather not touch in practically obsolete drivers. Mostly this is the low hanging fruit where we can add "const" and be done with it. v3: - un-constify atyfb, mb862xx, nvidia and uvesabf (0day) v2: - fix typo (Christophe de Dinechin) - use "static const" instead of "const static" in mx3fb.c - also constify smscufx.c Cc: linux-fbdev@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com
au1200fb allocates DMA memory using DMA_ATTR_NON_CONSISTENT, but never calls dma_cache_sync to synchronize the memory between the CPU and the device. If it was use on a not cache coherent bus that would be fatal, but as far as I can tell from the naming and the mips platform implementation it always is used in cache coherent systems. Remove the DMA_ATTR_NON_CONSISTENT flag, which is a no-op in that case. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190625121321.10197-1-hch@lst.de
Virtual addresses return from dma(m)_alloc_attrs are opaque in what backs then, and drivers must not poke into them. Similarly caching modes are not supposed to be directly set by the driver. Switch the driver to use the generic DMA API mmap helper to avoid these problems. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Trivial fix to spelling mistake in error messages. Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Markus Elfring <elfring@users.sourceforge.net> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Style clean-up. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
We should propagate the error code returned by 'fb_alloc_cmap()' instead of returning -EFAULT. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
There is no need to shut gcc up. It should not complain. Axe 'fbdev', it is never used in this function. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Rewrite the exit path based on 'au1200fb_drv_remove()'. We can safely iterate for all already handled planes. Even if not completely initialized, the functions that are called will silently accept the 'fb_info' structure that is passed. As soon as we find a NULL in the '_au1200fb_infos' array, we know that we have released all what we needed to release. So we can 'break'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
'au1200fb_drv_probe()' can not fail after a successful call to
'request_irq()'. So there is no point to call 'free_irq()' in the error
handling path.
Moreover, the hard coded AU1200_LCD_INT looks boggus since
commit 1630d85a8312 ("au1200fb: fix hardcoded IRQ").
So, remove it.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Tejun Heo <tj@kernel.org>
[b.zolnierkie: patch summary and description fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>