[Letux-kernel] [PATCH] mxc_epdc_fb: Fix build on LPAE kernels

[Andreas Kemnade]

On Sat, 12 Dec 2020 10:28:15 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> > Am 12.12.2020 um 10:07 schrieb Andreas Kemnade <andreas at kemnade.info>:
> > 
> > On Sat, 12 Dec 2020 09:00:19 +0000
> > David Shah <dave at ds0.me> wrote:
> >   
> >> This fixes mixing between u32 and dma_addr_t. I don't have hardware to
> >> test this on, so I can only confirm it builds.
> >> 
> >> Signed-off-by: David Shah <dave at ds0.me>
> >> ---
> >> drivers/video/fbdev/mxc/mxc_epdc_fb.c | 12 ++++++++----
> >> 1 file changed, 8 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/video/fbdev/mxc/mxc_epdc_fb.c b/drivers/video/fbdev/mxc/mxc_epdc_fb.c
> >> index 005e276eb5da1..77df5ddf740c8 100644
> >> --- a/drivers/video/fbdev/mxc/mxc_epdc_fb.c
> >> +++ b/drivers/video/fbdev/mxc/mxc_epdc_fb.c
> >> @@ -4720,6 +4720,7 @@ static void mxc_epdc_fb_fw_handler(const struct firmware *fw,
> >> 	struct clk *epdc_parent;
> >> 	unsigned long rounded_parent_rate, epdc_pix_rate,
> >> 			rounded_pix_clk, target_pix_clk;
> >> +	dma_addr_t temp_addr;
> >> 
> >> 	if (fw == NULL) {
> >> 		/* If default FW file load failed, we give up */
> >> @@ -4762,8 +4763,9 @@ static void mxc_epdc_fb_fw_handler(const struct firmware *fw,
> >> 	/* Allocate memory for waveform data */
> >> 	fb_data->waveform_buffer_virt = dma_alloc_coherent(fb_data->dev,
> >> 						fb_data->waveform_buffer_size,
> >> -						&fb_data->waveform_buffer_phys,
> >> -						GFP_DMA | GFP_KERNEL);
> >> +						&temp_addr,
> >> +						GFP_DMA32 | GFP_KERNEL);
> >> +	fb_data->waveform_buffer_phys = temp_addr;  
> > 
> > use dma_addr_t for waveform_buffer_phys. I thought it was already
> > patched long ago. No need for temp_addr.  
> 
> Seems to be missing (also in letux-current).
> 
ah, we have only
commit 76f16ad2e9d32d8ca23b3117a48b1fc699e12766
Author: Andreas Kemnade <andreas at kemnade.info>
Date:   Tue Aug 18 22:32:04 2020 +0200

    epdc_v2: fix dma types
    
    most phys_addr stuff already was dma_addr_t but at some places
    u32 was used which is problematic if dma_addr_t is u64.
    
    Signed-off-by: Andreas Kemnade <andreas at kemnade.info>

.. but not v1.

Regards,
Andreas