| Age | Commit message (Collapse) | Author |
|---|
|
Found by using:
codespell --builtin clear,rare,usage,informal,code,names
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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.
|
|
Restoring the registers "without need" caused some instability, with
random locks.
|
|
|
|
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...
|
|
Slightly change clock selection code to start using 501 compatible values,
before checking 502 values, if it is a 502.
DPMS for the VGA/second output was being set with bits inverted, that is
dpms-on was programmed as dpms-off and vice versa. This was one of the
reasons of dual head not working.
Corrected wrong vsync programming for the crt. Cut&paste/typo caused
programming vsync with hsync values, and thus, never getting the crt
to accept the mode being programmed.
If adding:
Option "Dualhead" "True"
to xorg.conf, now you should be able to do things like:
$ DISPLAY=:0.0 xrandr --output VGA --right-of LVDS
$ DISPLAY=:0.0 xrandr --output VGA --below LVDS
and so on.
*Iff* there is some way to not have any limitations for video playback,
this option should be made default or automatically configured.
|
|
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).
|
|
Double value must be truncated when calculating the difference from the
possible clock and requested clock.
|
|
The "prototype" computer no longer locks, and only "missing feature"
from before the patch is that video and Xaa don't work (only with Exa).
For the moment, just force crt as not connected, and set the proper
registers to make the secondary output clone the panel.
|
|
Also correct printing information about MCLK in the smi501/502, it
should print M2CLK (aka M1CLK o the 502) as it is the clock that
controls video engine/memory.
|
|
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?).
|
|
Instead of using a fixed 24Mhz input frequency, as "unofficially"
specified by SMI, a guess of using a 12 multiplier was used, and it
corrects the screen flicker problem as well as make a secondary output
work again.
|
|
It is not in the specs, so don't use it on chipsets older then the 502.
Some review should be done in SMI501_FindPLLClock() as when hardcoding it
to use the clock selection code for older chips, it appears to choose a
better refresh rate (no flicking at 1024x600).
|
|
|
|
|
|
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 causes instabilities, and there was also a bug where it would
tell the crt to not select panel data (due to removing the "else").
|
|
Add missing divide by 1000 in smi_501.c, as well as a FIXME comment
about a crash, and possible cause as well as possible ways to program
other clocks.
|
|
Previous patch wasn't fully correct, just that the values were generating
the same register dump as the smi 2.2.5 driver version.
When correcting it to not mix Mhz and Khz in the math, the problems
returned.... Anyway, it just works when selecting the highest clock, and
the attached CRT will display the panel image. This is illogical, so maybe
the specs are outdated... The previous code has been #ifdef'ed out in
"CALC_CLOCK".
Note that it still changes the boot default clock, from the default
288Mhz to 336Mhz, and in this patch, it also always sets both, panel and
crt clocks (what happens here, is that most likely, by doing this, it
forces the hardware to "somehow" autoconfigure itself; will try to get
some information from SMI about this, but this is the boot default,
and what smi sources do...).
|
|
The clock that should be programmed is the bandwidth, and not the pixel
clock itself. Based on analysis of register contents, after "importing"
a slightly modified version of xf86ModeBandwidth() and properly converting
values, now it properly programs both, the LCD and a "clone" CRT or just
a secondary panel.
Modes generated by either gtf or cvt correctly works.
A (hopefully temporary) fallback was also added, and if the option
"UseFBDev" is used, the driver will not attempt to set/modify the
current video mode.
TODO: Generate a modeline "on the fly", based on monitor configured
specs, or some set of defaults, so that it should not be required to
specify a modeline in xorg.conf.
|
|
One clock must be changed at a time, first setting the pll value,
then waiting for 16ms (one vsync), then setting the divider/shift
values, and again waiting 16ms.
Code was working after split of SMI501_ModeInit(), because some
clocks were already using system boot default, but would most likely
cause a crash when actually changing values (currently only p2_xxx
or v2_xxx is changed, but it would cause problems on some system where
the initial values don't match the ones set by the driver).
TODO: Either don't change m2clk and mclk or ensure other values
work correctly (don't change because the kernel should already
have set those if a value other then the boot default should be
used).
|
|
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.
|
