| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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.
|
|
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.
|
|
|
|
|
|
Probably I misunderstood the usage of this register, as it will always
show the same value, regardless of having a crt connected to the "vga"
port or not. Only difference is that while the detect bit is set,
the crt will be blank. This patch should be more of a placeholder for
a possible correction, but it should not cause any side effects, unless
the data field can be zero on a valid situation.
In my test computer, this field, in base 2 is always 1000000010000100,
what doesn't really look like data in rgb 8:8:8...
|
|
Use "local memory" field of mmio 0x010 and not "system memory", as
it uses system memory values whenever there is a choice (just sets
bits to zero).
|
|
It is mean't to be a fallback option, that as long as kernel boots
in framebuffer mode, the X Server should also work.
Correct incorrect value being checked when printing state of Dualhead
option.
The M value when programming PLL3 is actually an 8 bits integer,
so correct it and comments about it.
|
|
If Dualhead is set, it will attempt to use setups that allow different
outputs with different contents, instead of crt always cloning panel.
Still not fully functional.
|
|
Correct wrong clock calculation for the 501 clock setting, that is used
for pre 502 panel interface and crt.
Adds a few new programmable fields to MSOCRegRec:crt_display_ctl.
Call SMI501_CrtcAdjustFrame() after adjusting a mode, instead of
before changing registers.
|
|
Also add more complete description of programmable clocks.
|
|
Also print the value of sm502 registers (should be a noop on sm501).
Added the frequency field to the MSOCRegRec's misc_ctl, as it is
a read/write registers, and changing bit 24 may change the logic
of pll3 programming (needs clarification with SMI).
|
|
Moved most of the Lynx-specific code out of the main
functions at smi_driver.c to some new files: smilynx_hw.c
(With CRTC-independent code like global hardware initialization and
mode saving/restoring), smilynx_crtc.c (With the CRTC-local
procedures) and smilynx_output.c (Output power management, DDC and
monitor detection, currently).
Done something similar with the SMI501 code: split
SMI501_ModeInit in three separate functions: SMI501_HWInit that does
the global initialization, and the CRTC mode_set callbacks
SMI501_ModeSet_crt and SMI501_ModeSet_lcd at smi501_crtc.c.
The SMI501_ModeSet code is divided into SMI501_WriteMode_common,
SMI501_WriteMode_lcd and SMI501_WriteMode_crt, each one updates a
different register set in the hardware.
Inside smi_crtc.c, there is mainly hardware independent
code... Initial CRT controller allocation, shadows, rotation and
framebuffer resizing code.
The shadow code currently relies on EXA... I'm not sure what are the
problems of the EXA implementation in MSOC. Does it work?
I think it would be a good thing to get rid of XAA soon: The next
thing I'll be working on will be EXA Composite... I hope it's possible
to get EXA acceleration working at least as fast as the current
XAA. (Although Teddy Wang confirmed me that the SMI720 DMA engine is
broken...)
So, the patch adds some features like new Lynx dualhead modesetting
code, but it probably breaks some other things:
* Video Overlay: I suppose it does work with EXA activated. It seems
it is also possible to have simultaneous overlays in both CRTCs with the
Lynx hardware (I have some code for this, but still work in progress).
* Hardware Cursor (It needs more integration in the CRTC interfaces).
* The old Shadow FB / rotation code, which we should probably drop.
These are in my TODO list... Along with some more cleaning and other
minor issues in the modesetting code.
About the SMI501 RandR1.2 implementation... I suppose it's specially
lacking per-output DPMS (The DPMS field in the System Control register
only affects the CRT, doesn't it?).
|
|
|
|
Also remove extra includes that were not used.
|
|
The new code is based on the file SM502Clock.pdf provide by SMI engineers
(many thanks). And now it is expected to work correctly. The few remaining
details that are unclear (for the extended 502 modesetting mode) should be
resolved soon, and those are:
* MMIO:0x74:bit15 (PLL Output Divided by 2)
0: Disable.
1: Enable.
(does this mean it can use a 12MHz clock instead of 24? or anything else?)
* Should bit 31 of "current clock" always be set when using the alternate
mode setting for the 502? The alternate modesetting allows a very closer
pixel clock programming option, usually with 0 difference from the
xf86 mode.
I will ask SMI to make SM502Clock.pdf also available in the ftp site, it
is just 3 pages, or possibly even better, an update for the existing
documentation.
|
|
Now access to bitfields looks like:
record->register.f.field
instead of:
field(record->register, field)
what should be easier to read and understand.
|
|
The 502 is a superset of the 501, also recognized as PCI_CHIP_SMI501.
The driver is only known to work with smi_501 chipset
"SM501 VoyagerGX Rev. AA (rev c0)".
|
|
This allows using alternate MSOCRegRec structures to set a mode.
This should be useful to restore the initial mode.
|
|
Colors should be correctly set, but most output using Render is not
properly drawn, i.e. anti aliased fonts, etc. Need to investigate
further, but it should be a general problem, not exclusive to the
driver.
|
|
Rename fields pci_burst and NoPCIRetry to PCIBurst and PCIRetry,
to match field names case usage, and updated logic for the removal
of "No" from the pci retry option.
Pci retry and pci burst greatly increase video playback speed,
allowing smooth video play on the SMI 501.
|
|
The previous version was dependant on kernel framebuffer, as it was
just failing a test if not having a modeline defined, and in the test
case, it is running at 1024x600.
Now it properly programs the video hardware, and the procedure is
expected to be very well documented.
|
|
Functions renamed were setDPMS -> SMI501_SetDPMS,
regRead32 -> SMI501_Read32 and regWrite32 -> SMI501_Write32.
Also moved SMI_SetDPMS to start of smi_501.c to have extern
functions at start of the file.
|
|
Code compiled with:
gcc -Wall -Wbad-function-cast -Wdeclaration-after-statement \
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs \
-fno-strict-aliasing -Wold-style-definition -Wpointer-arith \
-Wstrict-prototypes
This patch also makes most smi_501.c functions static, as they are not
called from anywhere else.
Also removed prototypes for non existent functions in smi_501.h.
|
|
This patch add the new files and basic required definitions.
|
