[Openchrome-devel] xf86-video-openchrome: src/via_display.c src/via_driver.h
Luc Verhaegen
libv at skynet.be
Sat Jan 7 17:13:38 UTC 2017
On Fri, Jan 06, 2017 at 10:18:24AM +0000, Kevin Brace wrote:
> src/via_display.c | 244 ++++++++++++++++++++++++++++++++++++++++++++----------
> src/via_driver.h | 3
> 2 files changed, 203 insertions(+), 44 deletions(-)
>
> New commits:
> commit f8551e0e07366a70cf6aa8c3801d2965a86e170f
> Author: Kevin Brace <kevinbrace at gmx.com>
> Date: Fri Jan 6 04:17:32 2017 -0600
>
> Preparation for the partial fix of save / restore functions
>
> Signed-off-by: Kevin Brace <kevinbrace at gmx.com>
>
> diff --git a/src/via_display.c b/src/via_display.c
> index a405ce2..9f3920a 100644
> --- a/src/via_display.c
> +++ b/src/via_display.c
> @@ -3342,41 +3342,111 @@ viaIGA2Save(ScrnInfoPtr pScrn)
> DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> "Saving IGA2 registers.\n"));
>
> -/* Unlock and save extended registers. */
> + /* Unlock extended registers. */
> hwp->writeSeq(hwp, 0x10, 0x01);
>
> - /* Save LCD control registers (from CR 0x50 to 0x93). */
> - for (i = 0; i < 68; i++)
> - Regs->CRTCRegs[i] = hwp->readCrtc(hwp, i + 0x50);
> -
> - if (pVia->Chipset != VIA_CLE266 && pVia->Chipset != VIA_KM400) {
> - /* LVDS Channel 2 Function Select 0 / DVI Function Select */
> - Regs->CR97 = hwp->readCrtc(hwp, 0x97);
> - /* LVDS Channel 1 Function Select 0 */
> - Regs->CR99 = hwp->readCrtc(hwp, 0x99);
> - /* Digital Video Port 1 Function Select 0 */
> - Regs->CR9B = hwp->readCrtc(hwp, 0x9B);
> - /* Power Now Control 4 */
> - Regs->CR9F = hwp->readCrtc(hwp, 0x9F);
> -
> - /* Horizontal Scaling Initial Value */
> - Regs->CRA0 = hwp->readCrtc(hwp, 0xA0);
> - /* Vertical Scaling Initial Value */
> - Regs->CRA1 = hwp->readCrtc(hwp, 0xA1);
> - /* Scaling Enable Bit */
> - Regs->CRA2 = hwp->readCrtc(hwp, 0xA2);
> + for (i = 0; i < (0x88 - 0x50 + 1); i++) {
> + Regs->CR[i + 0x50] = hwp->readCrtc(hwp, i + 0x50);
> + }
> +
> + for (i = 0; i < (0x92 - 0x8A + 1); i++) {
> + Regs->CR[i + 0x8A] = hwp->readCrtc(hwp, i + 0x8A);
> + }
> +
> + for (i = 0; i < (0xA3 - 0x94 + 1); i++) {
> + Regs->CR[i + 0x94] = hwp->readCrtc(hwp, i + 0x94);
> }
This is a mistake, and a very slippery slope you started. I had some
very good reasons for not doing tables for save/restore.
1) Direct typed registers requires you to think very carefully about
which registers to restore. They require you to have very acute
knowledge of the display engine you are working with. Direct type
register names do not allow you to take shortcuts.
2) Synchronicity with a the real modesetting code. A missed register
in save/restore will usually also mean a missed register in the proper
modeset. Direct typed forces you to think about things more in depth and
makes it more natural to keep both the save/restore as the actual
modeset in sync.
2) what about timing and ordering? How are you going to deal with that
with the next abstraction step after you've introduced a table?
The fact that you missed CR6A/6B clearly shows that you missed something
big in save/restore. What did you do to stop saving restoring these
registers, which are very ordering critical.
My most recent customer was using register tables both in the capture
chip setup and for their poor excuse for a bootloader. In 2016. It was
amazing. Besides the fact that they were poor developers who couldn't
find or fix anything without JTAG, it also made it impossible for proper
developers to see the forest through the trees, or to try to use logic
to figure things out, and it was impossible to try to fix (apart from
the fact that the poor developers would have to change their idiotic
ways, which is impossible in itself).
Luc Verhaegen.
More information about the Openchrome-devel
mailing list