kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/video/fbdev/via/accel.c

533 lines
14 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 50 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 or at your option any later version this program is distributed in the hope that it will be useful but without any warranties or representations without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 43 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190520170858.826676366@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-20 19:08:15 +02:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: move some include files to include/linux These are the files which should be available to subdevices compiled outside of drivers/video/via. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-05-05 14:44:55 -06:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: Unify duplicated set_bpp() code As suggested by Florian: make both mode-setting paths use the same code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-09 14:06:16 -06:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: Unify duplicated set_bpp() code As suggested by Florian: make both mode-setting paths use the same code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-09 14:06:16 -06:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: Unify duplicated set_bpp() code As suggested by Florian: make both mode-setting paths use the same code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-09 14:06:16 -06:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2 There are some actions with value 'tmp' but 'dst_addr' is checked instead. It is obvious that a copy-paste error was made here and the value of variable 'tmp' should be checked here. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Aleksandr Burakov <a.burakov@rosalinux.ru> Signed-off-by: Helge Deller <deller@gmx.de>
2024-03-01 14:35:43 +03:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: fix acceleration for some chips Fix a regression in hardware acceleration which made the accelerated framebuffer unusable on some chips. These need extra initialization and an extra flag which is no longer needed/available on current chips. Signed-off-by: Erik-Jan Post <ej.lfs@xs4all.nl> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-01-15 17:01:06 -08:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: Retain GEMODE reserved bits Commit c3e25673843153ea75fda79a47cf12f10a25ca37 (viafb: 2D engine rewrite) changed the setting of the GEMODE register so that the reserved bits are no longer preserved. Fix that; at the same time, move this code to its own function and restore the use of symbolic constants. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 12:14:52 -06:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: Retain GEMODE reserved bits Commit c3e25673843153ea75fda79a47cf12f10a25ca37 (viafb: 2D engine rewrite) changed the setting of the GEMODE register so that the reserved bits are no longer preserved. Fix that; at the same time, move this code to its own function and restore the use of symbolic constants. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 12:14:52 -06:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2 There are some actions with value 'tmp' but 'dst_addr' is checked instead. It is obvious that a copy-paste error was made here and the value of variable 'tmp' should be checked here. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Aleksandr Burakov <a.burakov@rosalinux.ru> Signed-off-by: Helge Deller <deller@gmx.de>
2024-03-01 14:35:43 +03:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: use proper register for colour when doing fill ops The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Daniel Drake <dsd@laptop.org> Cc: Jon Nettleton <jon.nettleton@gmail.com> Cc: stable@kernel.org
2010-09-22 02:33:52 +00:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: use proper register for colour when doing fill ops The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Daniel Drake <dsd@laptop.org> Cc: Jon Nettleton <jon.nettleton@gmail.com> Cc: stable@kernel.org
2010-09-22 02:33:52 +00:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: fix hardware acceleration for suspend & resume This patch splits the acceleration initialization in two parts: The first is only called during probe and is used to allocate resources. The second part is also called on resume to reinitalize the 2D engine. This should fix all acceleration issues after resume most notable an "invisible" cursor and as we do nothing special it is reasonable to assume that it works on all supported IGPs. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: Joseph Chan <JosephChan@via.com.tw>
2010-04-26 17:31:03 +00:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: fix hardware acceleration for suspend & resume This patch splits the acceleration initialization in two parts: The first is only called during probe and is used to allocate resources. The second part is also called on resume to reinitalize the 2D engine. This should fix all acceleration issues after resume most notable an "invisible" cursor and as we do nothing special it is reasonable to assume that it works on all supported IGPs. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: Joseph Chan <JosephChan@via.com.tw>
2010-04-26 17:31:03 +00:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: choose acceleration engine for VX855 Enable 2D hardware acceleration on VX855 for copyarea, imageblit and fillrect by selecting the correct engine which is the same as in VX800. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:36 -07:00
viafb: add initial VX900 support This patch adds basic support for the new VX900 IGP. Almost everything that was implemented for other IGPs is expected to work also on VX900 after this patch. The only known issue is that on the CRT output mode setting does not always work. It is clear that the possibility for regressions is zero. A big thanks to VIA Technologies for making this possible and supporting this work. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Jonathan Corbet <corbet@lwn.net>
2010-10-24 04:02:14 +00:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: 2D engine rewrite This patch is a completly rewritten 2D engine. The engine is no longer in a default state but reinitialized every time to allow usage for both framebuffers regardless of their settings. The whole engine handling is concentrated in a big function which takes 16 parameters. Although the number of parameters is worryingly it is good to have a single funtion to deal with this stuff as it allows to easily support different engines and avoids some code duplication. On the way support for the new 2D engine in VX800 was added. As the with less code duplication but it is probably better to duplicate the code as this way is easier to walk if VIA ever decides to release a new engine which changes anything the driver touches. The engine support for VX800 gives a notable boost in speed. There are no known regressions but as this patch changes paths I do neither have the hardware nor documentation to check and has the possibility to put the system in a critical state heavy testing is appreciated. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:26 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
fbdev: Use IS_ENABLED() instead of checking for built-in or module The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either built-in or as a module, use that macro instead of open coding the same. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-11 11:59:23 -04:00
viafb: Reserve framebuffer memory for the upcoming camera driver The camera engine captures to framebuffer memory, so we need to set some aside for that purpose. There is no proper memory allocator for fbmem; instead, accel.c just trims some space off the top. Alas, without creating that proper memory allocator, the only way to make this work is to hack it into the same bit of code in accel.c. The allocation must happen *after* the others (some code, including user-space XV stuff, makes assumptions on where the cursor space is), and before the rest of the framebuffer is set up. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-23 10:31:13 -06:00
viafb: fix hardware acceleration for suspend & resume This patch splits the acceleration initialization in two parts: The first is only called during probe and is used to allocate resources. The second part is also called on resume to reinitalize the 2D engine. This should fix all acceleration issues after resume most notable an "invisible" cursor and as we do nothing special it is reasonable to assume that it works on all supported IGPs. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: Joseph Chan <JosephChan@via.com.tw>
2010-04-26 17:31:03 +00:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: complete support for VX800/VX855 accelerated framebuffer This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled so far. This merge tries to preserve Harald's changes in the framework of the much-changed 2.6.34 viafb code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 13:08:23 -06:00
viafb: add initial VX900 support This patch adds basic support for the new VX900 IGP. Almost everything that was implemented for other IGPs is expected to work also on VX900 after this patch. The only known issue is that on the CRT output mode setting does not always work. It is clear that the possibility for regressions is zero. A big thanks to VIA Technologies for making this possible and supporting this work. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Jonathan Corbet <corbet@lwn.net>
2010-10-24 04:02:14 +00:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: complete support for VX800/VX855 accelerated framebuffer This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled so far. This merge tries to preserve Harald's changes in the framework of the much-changed 2.6.34 viafb code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 13:08:23 -06:00
viafb: add initial VX900 support This patch adds basic support for the new VX900 IGP. Almost everything that was implemented for other IGPs is expected to work also on VX900 after this patch. The only known issue is that on the CRT output mode setting does not always work. It is clear that the possibility for regressions is zero. A big thanks to VIA Technologies for making this possible and supporting this work. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Jonathan Corbet <corbet@lwn.net>
2010-10-24 04:02:14 +00:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: fix hardware acceleration for suspend & resume This patch splits the acceleration initialization in two parts: The first is only called during probe and is used to allocate resources. The second part is also called on resume to reinitalize the 2D engine. This should fix all acceleration issues after resume most notable an "invisible" cursor and as we do nothing special it is reasonable to assume that it works on all supported IGPs. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: Joseph Chan <JosephChan@via.com.tw>
2010-04-26 17:31:03 +00:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: complete support for VX800/VX855 accelerated framebuffer This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled so far. This merge tries to preserve Harald's changes in the framework of the much-changed 2.6.34 viafb code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 13:08:23 -06:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: complete support for VX800/VX855 accelerated framebuffer This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled so far. This merge tries to preserve Harald's changes in the framework of the much-changed 2.6.34 viafb code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 13:08:23 -06:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: complete support for VX800/VX855 accelerated framebuffer This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled so far. This merge tries to preserve Harald's changes in the framework of the much-changed 2.6.34 viafb code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-03-27 13:08:23 -06:00
viafb: returns 0 two too early Otherwise this will already return 0 if iteration MAXLOOP-2 occurs in the first loop. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-31 15:25:36 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: Separate global and fb-specific data This patch moves data of interest into a new viafb_dev structure which describes the device as a whole; the idea here is to create a separation between what all devices may need and what the framebuffer device in particular needs. I've also made some small steps toward thinning out the global.h mess. Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Cc: Harald Welte <laforge@gnumonks.org> Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2010-04-22 13:48:09 -06:00
viafb: returns 0 two too early Otherwise this will already return 0 if iteration MAXLOOP-2 occurs in the first loop. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-31 15:25:36 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: returns 0 two too early Otherwise this will already return 0 if iteration MAXLOOP-2 occurs in the first loop. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-31 15:25:36 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00
viafb: hardware acceleration initialization cleanup The main motivation of this patch was to merge the three initialization functions in one and clean it up. However as some changes in other code areas where needed to do it right some small other changes were made. Changes to viafb_par: io_virt renamed as engine_mmio and moved to shared VQ_start renamed as vq_vram_addr and moved to shared VQ_end removed as it is easily recalculatable vq_vram_addr is not strictly needed but keep it to track where we allocated video memory. The memory allocated for the virtual queue was shrunk to VQ_SIZE as VQ_SIZE+CURSOR_SIZE looked like a bug to me. But to be honest I don't have the faintest idea what virtual queues are for in the graphic hardware and whether the driver needs them in any way. I only know that they aren't directly accessed by the driver and so the only potential current use would be as hardware internal buffers. For now keep them to avoid regressions and only remove the double cursor allocation. The most changes were caused by renames and the mentioned structure changes so the chance of regressions is pretty low. The meaning of viafb_accel changed slightly as previously it was changed back and forth in the code and allowed to enable the hardware acceleration by software if previously disabled. The new behaviour is that viafb_accel=0 always prevents hardware acceleration. With viafb_accel!=0 the acceleration can be freely choosen by set_var. This means viafb_accel is a diagnostic tool and if someone has to use viafb_accel=0 the driver needs to be fixed. As this is mostly a code cleanup no regressions beside the slightly change of viafb_accel is expected. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Harald Welte <laforge@gnumonks.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-22 16:47:31 -07:00
viafb: accel.c, accel.h 2D and HW cursor stuff of viafb driver. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joseph Chan <josephchan@via.com.tw> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:21 -07:00