Age | Commit message (Collapse) | Author |
|
This should allow using a SM502 as secondary display
device (bug 21810).
|
|
|
|
Set it to 3MHz so that the pixel clock frequency is overridden
when it's found to be 49MHz, which is reported to be unstable.
|
|
|
|
In some cases the BIOS hasn't filled in the "scratchpad registers"
(SR71) with the right amount of memory installed (e.g. MIPS
platform). There seems to be no other way to do it than to test it.
This should fix bug 21528.
|
|
|
|
The default MCLK setting was higher than the clock limit, and it
failed.
|
|
The databook says nothing about it, and it doesn't work.
|
|
Clearing this bit causes an OQO 01+ w/SMI720 to power down the LCD,
leave it alone.
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Due to checking if SMI501_CLI_DEBUG is defined, some debugging will
be enabled if SMI501_CLI_DEBUG is set to 0. A single #if should be
used instead. Some debugging code already does this.
Signed-off-by: Niels de Vos <niels.devos@wincor-nixdorf.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
|
|
|
|
|
|
Probably this makes dualhead mode more useful because it makes
possible displaying video on the LCD as long as the CRT output is
disabled or cloned.
|
|
|
|
|
|
This driver supports smi 50x chipsets, randr 1.2, exa, dual head,
etc.
Special thanks to Teddy Wang <teddy.wang AT siliconmotion.com.cn>
for support and help in responding and/or triaging hardware related
questions.
|
|
Also correct only compilation warning about possibly
uninitialized variable.
|
|
FOURCC_YV12 and FOURCC_I420 handling also was buggy. First it was
doing a noop by swapping offset2 and offset3 values twice, and second,
swap is not required when using smi 501/502 CSC video.
Changed SMI_DisplayVideo0501_CSC() to not set static values to
registers in a possible loop, if there is clipping.
|
|
* Program the MCLK to 157MHz on startup.
* Adjust the requested pixel clock if it's near one of the known
stable frequencies.
* Prefer the clock alternative with post scalar turned on when the
denominator is even.
|
|
|
|
After the RandR1.2 implementation the "UseBIOS" option wasn't actually
programming the hardware through VESA BIOS, this brings back that
functionality.
|
|
|
|
|
|
Save some registers not previously tracked, and use pSmi->mode instead
of continuously reading the hardware state.
|
|
|
|
To enable it, set SMI501_CLI_DEBUG to 1 in smi.h, and use
Option "AcellMethod "EXA"
in the Device section of /etc/X11/xorg.conf
This code is enabled mainly for debug purposes. To make if have an
actual performance gain (like when using a sm50x with a "low profile"
"main" processor") it should be required to actually do busy loops
in kernel mode (and hope the costs of context switch will pay it).
In kernel mode it is possible to wait for an interrupt being triggered
when the command list is processed, or when the 2d engine is idle.
This commit should be functional, but, mainly due to debug messages,
should be significantly slower then a build with MI501_CLI_DEBUG
defined to 0.
|
|
This also changes some bit operations to use a "bitfield" equivalent
one, with named fields, that should make it easier to understand what
is being tested.
The enum smi_cli_cmd_code in smi_501.h is code that was added to a
experimental smi_drm.h, but the hardware only supports basic 2d accel,
and to compensate for the extra overhead for maintaining a command
list (assuming it worked correctly) it would be required to have a
special handling, like calling an ioctl to do the "busy loop" in the
kernel (that is, should wait for an irq or a timeout).
The problem is that even if waiting for a idle engine before crafting
a command, and waiting again after submitting the command, there would
be corruption on screen after some time. So, the "busy loop" in the
kernel would only be useful if still using direct writes to mmio
registers.
|
|
Call ModifyPixmapHeader on SMI_EnterVT to update the screen pixmap
address tracked by EXA.
Set memoryBase in the ExaDriverRec to NULL when switching out: some
pixmap could get allocated near the former aperture address and it
could be erroneously considered as being in offscreen memory.
|
|
Set UseBIOS to off by default for SM720. Some improvements on the
debugging output.
|
|
|
|
|
|
This fixes 1280x1024 modes on the VGA output with dual head on.
Also, solve a build problem when using -DSMI_DEBUG, as pointed by
Richard Schwarting.
|
|
|
|
o Define HAVE_XMODES in config.h.
o Correct the LEAVE() macro declaration when SMI_DEBUG is defined.
o Remove prototype for SMI_DGAInit() if HAVE_XMODES is not defined.
o Properly scale value read from sm501 CURRENT_CLOCK register, to
print an appropriate message on startup.
|
|
The option set_mclck was renamed to just MCLK, and a new MXCLCK option
was added for smi501/502 chips.
Note that previously, on MSOC chips, the set_mclck option actually
changed mxclck, what is now done by the MXCLK option.
The manpage was also update to reflect the options usage.
A new SMI501_FindMemClock() function was added, as a possible
placeholder for choosing alternate clocks when programming MMIO 0x68.
But it should be noted that the smi 501 databook says:
Miscellaneous Timing
Read/Write MMIO_base + 0x000068
Power-on Default 0x00000000
[...]
5:4 Divider Output Frequency Selection for Second PLL.
00: 336 MHz.
01: 288 MHz.
10: 240 MHz.
11: 192 MHz.
while the 502 databook says:
Miscellaneous Timing
Read/Write MMIO_base + 0x000068
Power-on Default 0b0000.00xx.0000.1001.0000.1001.0000.0000
[...]
5:4 Reserved These bits are reserved.
but still tells to refer to those bits.
|
|
The current kernel framebuffer module expects accelerations registers
in the default boot state, otherwise, it will display some corruption,
or not correctly clear the screen, among other side effects.
Now it should be restoring everything the kernel framebuffer relies
on not being modified.
|
|
|
|
DGA was also not being properly test to not enable the pSmi fields,
but since the dga implementation is very basic, it is better to just
remove it (if compiling the sources on pre 1.4 X Server, DGA will be
disabled).
The polylines code in xmi_xaa.c was already if 0'ed for some time,
but it may be reinstantiated to accelerate (back) xaa rotated modes.
Currently only randr+exa accelerates rotated modes.
|
|
At least in the smi501/502, it may even completely lock in some special
cases (like when there is a browser playing some youtube video).
The code in SMI_CloseScreen() was almost identical to SMI_LeaveVT(),
so it now just call SMI_Leave() if required.
|
|
The LEAVE() macro, when debug is disabled, now is defined as:
<hash>define LEAVE(...) return __VA_ARGS__
This avoids the requirement of a return statement after the LEAVE()
macro call, what can be confusing.
|
|
|
|
Use the same logic for offscreen memory management as used in
smi_video.c. This also makes the functions SMI_AllocateMemory and
SMI_FreeMemory no longer static in smi_video.c.
|
|
The smi 501/502 cannot rotate-blt more than 32 bytes at a time.
Patch based on smi's sample smi_shadow.c.
XAA + randr + rotated mode currently not supported.
|
|
On the MSOC, the hardware cursor was remaining on screen, when using
EXA and a randr rotated mode.
|
|
Besides reducing driver size, this should make DGA+EXA accelerated.
|
|
Commit 0870d46718fe4e01953efd63cec46c54140b20f9 broke the clipping
code. That has been corrected in this patch. Anyway, the hardware color
space conversion should not be hidden down in the driver code, instead
it should be usable by external programs as well, instead of having
some applications doing it by software.
|
|
The kernel framebuffer module uses the hw cursor for the console cursor,
so the driver must ensure it is hidden when setting a video mode.
|