diff options
| author | Russell King (Oracle) <rmk+kernel@armlinux.org.uk> | 2023-06-27 14:17:19 +0100 |
|---|---|---|
| committer | Russell King (Oracle) <rmk+kernel@armlinux.org.uk> | 2023-06-27 14:17:19 +0100 |
| commit | 53ae158f6ddc14df5c44d62c06e33fdb66de1196 (patch) | |
| tree | d0d0485f5f614e0070bab6ff1b53d56aec7c2d8e /drivers/video/fbdev/vfb.c | |
| parent | ac9a78681b921877518763ba0e89202254349d1b (diff) | |
| parent | 47ba5f39eab3c2a9a1ba878159a6050f2bbfc0e2 (diff) | |
Merge tag 'arm-vfp-refactor-for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux into devel-stabledevel-stable
Refactor VFP support code and reimplement in C
The VFP related changes to permit kernel mode NEON in softirq context
resulted in some issues regarding en/disabling of sofirqs from asm code,
and this made it clear that it would be better to handle more of it from
C code.
Given that we already have infrastructure that associates undefined
instruction exceptions with handler code based on value/mask pairs, we
can easily move the dispatch of VFP and NEON instructions to C code once
we reimplement the actual VFP support routine (which reasons about how
to deal with the exception and whether any emulation is needed) in C
code first.
With those out of the way, we can drop the partial decoding logic in asm
that reasons about which ISA is being used by user space, as the
remaining cases are all 32-bit ARM only. This leaves a FPE specific
routine with some iWMMXT logic that is easily duplicated in C as well,
allowing us to move the FPE asm code into the FPE asm source file, and
out of the shared entry code.
Diffstat (limited to 'drivers/video/fbdev/vfb.c')
| -rw-r--r-- | drivers/video/fbdev/vfb.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c index a94573997d15..6f1990969361 100644 --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -111,7 +111,7 @@ static u_long get_line_length(int xres_virtual, int bpp) * First part, xxxfb_check_var, must not write anything * to hardware, it should only verify and adjust var. * This means it doesn't alter par but it does use hardware - * data from it to check this var. + * data from it to check this var. */ static int vfb_check_var(struct fb_var_screeninfo *var, @@ -169,7 +169,7 @@ static int vfb_check_var(struct fb_var_screeninfo *var, /* * Now that we checked it we alter var. The reason being is that the video - * mode passed in might not work but slight changes to it might make it + * mode passed in might not work but slight changes to it might make it * work. This way we let the user know what is acceptable. */ switch (var->bits_per_pixel) { @@ -235,8 +235,8 @@ static int vfb_check_var(struct fb_var_screeninfo *var, } /* This routine actually sets the video mode. It's in here where we - * the hardware state info->par and fix which can be affected by the - * change in par. For this driver it doesn't do much. + * the hardware state info->par and fix which can be affected by the + * change in par. For this driver it doesn't do much. */ static int vfb_set_par(struct fb_info *info) { @@ -379,7 +379,7 @@ static int vfb_pan_display(struct fb_var_screeninfo *var, } /* - * Most drivers don't need their own mmap function + * Most drivers don't need their own mmap function */ static int vfb_mmap(struct fb_info *info, |