- 03 Sep, 2009 3 commits
-
-
Jean Delvare authored
and make the code harder to read. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Petr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Jean Delvare authored
and make the code harder to read. Signed-off-by:
-
Jean Delvare authored
always enable it. There are many reasons for doing this: * CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it definitely works or we would know by now. * Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set results in the following build warning: drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open': drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release': drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' This is nothing to be worried about, the driver will work fine, but build warnings are still annoying. * The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD, which is described in the config help text, no longer works: you can't load the same kernel module more than once. * I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code significantly slower, contrary to what the help text says. A few extra parameters on the stack here and there can't really slow things down in comaprison to the rest of the code, and register access. * The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%. * One less configuration option makes things simpler. We add options all the time, being able to remove one for once is nice. It improves testing coverage. And I don't think the Matrox adapters are still popular enough to warrant overdetailed configuration settings. * We should be able to unobfuscate the driver code quite a bit after this change (patches follow.) Signed-off-by:
-
- 22 Aug, 2009 1 commit
-
-
Florian Tobias Schandinat authored
code in fb_set_par. Until now it would be silently ignored by fbmem.c and fbcon.c. This patch fixes fbmem.c to return the error code and restore var on error. But it is not clear in which video mode the device is when fb_set_par fails. It would be good and reasonable if it were in the old state but there is no guarantee that this is true for all existing drivers. Additionally print a message if a failing fb_set_par is detected in fbmem.c or fbcon.c. Although most errors should be caught by the previous fb_check_var some errors can't as they are dynamic (memory allocations, ...) and can only be detected while performing the operations which is forbidden in fb_check_var. This patch shouldn't have a negative impact on normal operation as all drivers return 0 on success. The impact in case of error depends heavily on the driver and caller but it's expected to be better than before. Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
- 20 Aug, 2009 2 commits
-
-
Ben Dooks authored
divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with a rounding error if the result is odd. Change to using DIV_ROUND_UP() to ensure that we always choose a higher divisor and thus a lower frequency. Signed-off-by:
Ben Dooks <ben@simtec.co.uk> Signed-off-by:
-
Jiri Slaby authored
the code more readable and consistent (sometimes there were shifts, sometimes divs). There is no change on the assembly level (compilers should do the right job). Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
- 06 Aug, 2009 1 commit
-
-
Florian Tobias Schandinat authored
invalid values (very high ones that can occur if an app tries to move further up/left than 0,0) as the check uses the unknown values for calculation so that an overflow can occur. To fix this it is sufficient to move the calculation to the right side to use only trusted values. Kai Jiang detected this problem and proposed an initial patch. Signed-off-by:
-
- 03 Aug, 2009 2 commits
-
-
Andrew Morton authored
Cc: Julia Lawall <julia@diku.dk> Cc: Ming Lei <tom.leiming@gmail.com> Signed-off-by: -
Julia Lawall authored
functions. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression *x; identifier f; constant char *C; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ... when != x == NULL when != x != NULL when != (x || ...) ( kfree(x) | f(...,C,...,x,...) | *f(...,x,...) | *x->f ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
- 31 Jul, 2009 1 commit
-
-
Roel Kluin authored
required because linetable[] are unsigned shorts. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
- 09 Sep, 2009 7 commits
-
-
Florian Tobias Schandinat authored
The previous method of mode parsing wrote to the strings resulting in truncated mode strings in the sysfs. Signed-off-by:
-
Harald Welte authored
completely unused. Signed-off-by:
Harald Welte <HaraldWelte@viatech.com> Signed-off-by:
-
Harald Welte authored
Signed-off-by:
-
Florian Tobias Schandinat authored
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 authored
and bpp with fix.line_length which already contains the pitch and does not add any constrains for the virtual resolution. Also add a bit to the second pitch which the documentation mentions but which was ignored by the driver. Although it is a bit unclear what the right pitch for some LCD modes is this patch should have no negative runtime impact. Signed-off-by:
-
Florian Tobias Schandinat authored
The most notable change is that it no longer buffers the values in viacursor but uses the ones in cursor instead as they are guaranteed to be always valid. Furthermore it uses local instead global variables where possible, moves the cursor variable in shared as only one hardware cursor is supported and returns an error if memory allocation fails. Last but not least it fixes a too small buffer (as u32 has only 4 and not 32 bytes) but this did not produce any known problems. This is mostly a code cleanup, no negative runtime changes are expected. Signed-off-by:
-
Alexey Dobriyan authored
Acked-by:
-
- 05 Sep, 2009 1 commit
-
-
Florian Tobias Schandinat authored
- add raster operation code conversion and checking Signed-off-by:
-
- 03 Sep, 2009 1 commit
-
-
Florian Tobias Schandinat authored
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:
-
- 27 Aug, 2009 3 commits
-
-
Florian Tobias Schandinat authored
transition to use it. viafb_shared should contain all general, non-surface specific data that should be shared along all viafb framebuffers while viafb_par should only contain things that are specific to each surface or in other words extend fb_info. This change is intended to clean the dual/multi framebuffer handling up. This removes the annoyance that viafbinfo1->par points to a different structure than viaparinfo1. As the last change is fundamental it is difficult to ensure that all parts of the driver do not depend on the previous brokenness but the chance of regressions is very low. Signed-off-by:
-
Florian Tobias Schandinat authored
used variables mmio_base and mmio_len in favor to use directly the fb_info variables. This is a code cleanup only, no runtime change expected. Signed-off-by:
-
Florian Tobias Schandinat authored
the register are written with reserved values. This makes the display go white in some configurations and not usable until the framebuffer is removed. It's better to not initialize it as it allows to use a previously (by BIOS) correctly configured display. This patch makes some displays work but might cause problems on others. This is bad but can not be easily avoided. If this causes some regressions it's probably the best to fix it in the 'active' display setup code. Signed-off-by:
-
- 22 Aug, 2009 1 commit
-
-
Florian Tobias Schandinat authored
influence the driver operation. This patch does change the userspace behaviour as it removes two IOCTLs and one module parameter. But this is good as it removes useless stuff and helps the user to figure out the options that do affect the driver behaviour (which are still too many). Signed-off-by:
-
- 20 Aug, 2009 4 commits
-
-
Florian Tobias Schandinat authored
were made: info->screen_base - viafb_FB_MM (VRAM offset calculation) was replaced by info->fix.smem_start - viafbinfo->fix.smem_start which is essentially the same calculation but done with physical instead virtual addresses. *->fbmem_virt was replaced by viafbinfo->screen_base This is true for viafbinfo and viafbinfo1 as the par pointers are equal. An early initialization of viafbinfo1->fix.smem* was removed as done later in viafb_setup_fixinfo. This patch highlights that the only usage of the ioremapped video memory in the driver is for hardware cursor handling. Even if it has to hold the used virtual screen mapped for old-fashioned read/write calls (vs. mmap'ed) a lot virtual memory could be saved by only ioremapping on demand. Code cleanup, no runtime changes expected. Signed-off-by:
-
Florian Tobias Schandinat authored
the only place where it is used. This is a code cleanup only, no runtime change expected. Signed-off-by:
-
Florian Tobias Schandinat authored
instead. This is possible because horizontal and vertical address are the same as horizontal and vertical resolution. The reduced blanking modes in the table are no problem because they have a higher index than the normal modes and therefore always the normal modes are selected just as the old behaviour. Signed-off-by:
-
Florian Tobias Schandinat authored
maintainable by evaluating the array size in the file the array exist in and exporting it via variables. This removes the need to keep the array size in the header in sync with the real array size. Signed-off-by:
-
- 15 Aug, 2009 1 commit
-
-
Florian Tobias Schandinat authored
Introduce error handling for remapping MMIO register address space to avoid a NULL pointer dereference. Disable hardware acceleration if remapping MMIO register address space failed as those registers are only used for hardware acceleration. Signed-off-by:
-
- 06 Aug, 2009 2 commits
-
-
Florian Tobias Schandinat authored
viafb_set_secondary_address and make it more flexible to reuse it for panning. Using central functions makes it easier to follow HW manipulations. Remove crt locking as it should be only needed for timing manipulation. Move iga_path manipulation to via_pci_probe. Remove memset for screen cleaning as it is currently done only for the second screen. This is not needed for normal operation but has a little chance of causing unwanted display artifacts. This can be fixed later more consistent and more efficient (using viafb_fillrect) if needed. This is a code clenup, no notable runtime changes expected. Signed-off-by:
-
Florian Tobias Schandinat authored
data in viafb_par. Use the relevant data of fb_info instead. On the way it removes an inconsistency in handling a second framebuffer which only worked because viafbinfo1->par is modified to point to the same viafb_par as viafbinfo->par. Code cleanup only, no runtime change expected. Signed-off-by:
-
- 31 Jul, 2009 2 commits
-
-
Florian Tobias Schandinat authored
viafb_setmode is called. This is not done consistently along graphic cores and not even the whole address but often only parts of it. On top of that it seems useless as the real/final address will be set by viafb_set_start_addr a few lines later. Remove this superfluous initalization to shrink register initalization and as a start to decouple primary and secondary display. Code cleanup, no notable runtime change expected. Signed-off-by:
-
Florian Tobias Schandinat authored
missing break as discovered by Harald Welte. As CX700 and VX800 have exactly the same register initialization we can use one for both to avoid duplicated code. As this is a pure code cleanup no measurable runtime effects are expected. Signed-off-by:
-
- 25 Jul, 2009 1 commit
-
-
Ryan Mallon authored
Signed-off-by:
Ryan Mallon <ryan@bluewatersys.com> Acked-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Daniele Venzano <linux@brownhat.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
- 24 Aug, 2009 1 commit
-
-
Ryan Mallon authored
Acked-by:
-
- 31 Jul, 2009 1 commit
-
-
Ryan Mallon authored
Acked-by:
-
- 25 Jul, 2009 1 commit
-
-
Roel Kluin authored
sisfb_vrate[-1].refresh. Signed-off-by:
-
- 31 Jul, 2009 1 commit
-
-
Sudhakar Rajashekhara authored
a. An if loop check while returning from lcd_disable_raster() function has been removed. b. "invert_pxl_clock" variable has been renamed as "invert_pxl_clk" and moved from lcd_ctrl_config structure in include/video/da8xx-fb.h file to da8xx_panel structure in drivers/video/da8xx-fb.c file. Appropriate changes in source code as a result of moving this variable has also been done. Signed-off-by:Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Pavel Kiryukhin <pkiryukhin@ru.mvista.com> Cc: Steve Chen <schen@mvista.com> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by:
-
- 24 Jul, 2009 2 commits
-
-
Andrew Morton authored
Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Pavel Kiryukhin <pkiryukhin@ru.mvista.com> Cc: Steve Chen <schen@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: -
Sudhakar Rajashekhara authored
modified. Signed-off-by:
Pavel Kiryukhin <pkiryukhin@ru.mvista.com> Signed-off-by:
Steve Chen <schen@mvista.com> Acked-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by:
-
- 24 Aug, 2009 1 commit
-
-
Sudhakar Rajashekhara authored
LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by:
-
