linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Re: PPC scr_{read,write}w() cleanup (fwd)
       [not found] <19991028215345.A13930@chimaera.ppc.kernel.org>
@ 1999-10-29  7:22 ` Geert Uytterhoeven
  1999-10-29  7:58   ` Cort Dougan
  0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 1999-10-29  7:22 UTC (permalink / raw)
  To: Cort Dougan
  Cc: Linux Frame Buffer Device Development, Linux/PPC Development,
	Jeff Garzik, Martin Mares


On Thu, 28 Oct 1999, Cort Dougan wrote:
> The problem here is with the common build where we build in both vgacon and
> fb.

What's the problem there? If vgacon is enabled, scr_write() will be writew(),
i.e. little endian. But since scr_readw() == readw() is little endian as well,
it'll work fine.

Or am I missing something?

> I'm willing to switch PReP to fb entirely if it's reasonable that it will
> work on all PReP boxes.  Any suggestions?

I don't think it will work on all PReP boxes yet. There's no frame buffer
device for S3 [89]6[48] yet :-(

> } Does this work on your boxes? I really like to have this fixed.
> } 
> } Finally I found some time to sort out the PPC scr_{read,write}w() mess.
> } Now scr_{read,write}w() always swaps bytes if {vga,mda}con was compiled in,
> } while we did a runtime check before.
> } 
> } This patch matters specifically for people with PReP boxes, who may want to use
> } vgacon on one head and a real frame buffer device on either a second head or on
> } the first head after boot up (insmod *fb.o takes over vgacon).

    [...]

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PPC scr_{read,write}w() cleanup (fwd)
  1999-10-29  7:22 ` PPC scr_{read,write}w() cleanup (fwd) Geert Uytterhoeven
@ 1999-10-29  7:58   ` Cort Dougan
  1999-10-29  8:48     ` Geert Uytterhoeven
  0 siblings, 1 reply; 3+ messages in thread
From: Cort Dougan @ 1999-10-29  7:58 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linux Frame Buffer Device Development, Linux/PPC Development,
	Jeff Garzik, Martin Mares


Maybe I'm confused.  If so, point out where I'm wrong here:

We build in VGA_CONSOLE and FB for a common build.  We end up getting the
wrong scr_read/write if we end up using the wrong one (through
vt_buffer.h).

Will vt_buffer.h "do the right thing" in this case?

} What's the problem there? If vgacon is enabled, scr_write() will be writew(),
} i.e. little endian. But since scr_readw() == readw() is little endian as well,
} it'll work fine.
} 
} Or am I missing something?
} 
} > I'm willing to switch PReP to fb entirely if it's reasonable that it will
} > work on all PReP boxes.  Any suggestions?
} 
} I don't think it will work on all PReP boxes yet. There's no frame buffer
} device for S3 [89]6[48] yet :-(
} 
} > } Does this work on your boxes? I really like to have this fixed.
} > } 
} > } Finally I found some time to sort out the PPC scr_{read,write}w() mess.
} > } Now scr_{read,write}w() always swaps bytes if {vga,mda}con was compiled in,
} > } while we did a runtime check before.
} > } 
} > } This patch matters specifically for people with PReP boxes, who may want to use
} > } vgacon on one head and a real frame buffer device on either a second head or on
} > } the first head after boot up (insmod *fb.o takes over vgacon).
} 
}     [...]
} 
} Gr{oetje,eeting}s,
} 
} 						Geert
} 
} --
} Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
} Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
} Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PPC scr_{read,write}w() cleanup (fwd)
  1999-10-29  7:58   ` Cort Dougan
@ 1999-10-29  8:48     ` Geert Uytterhoeven
  0 siblings, 0 replies; 3+ messages in thread
From: Geert Uytterhoeven @ 1999-10-29  8:48 UTC (permalink / raw)
  To: Cort Dougan
  Cc: Linux Frame Buffer Device Development, Linux/PPC Development,
	Jeff Garzik, Martin Mares


On Fri, 29 Oct 1999, Cort Dougan wrote:
> Maybe I'm confused.  If so, point out where I'm wrong here:
> 
> We build in VGA_CONSOLE and FB for a common build.  We end up getting the
> wrong scr_read/write if we end up using the wrong one (through
> vt_buffer.h).
> 
> Will vt_buffer.h "do the right thing" in this case?

I think so: vt_buffer.h includes asm/vga.h first if CONFIG_VGA_CONSOLE or
CONFIG_MDA_CONSOLE are set.

> } What's the problem there? If vgacon is enabled, scr_write() will be writew(),
> } i.e. little endian. But since scr_readw() == readw() is little endian as well,
> } it'll work fine.
> } 
> } Or am I missing something?
> } 
> } > I'm willing to switch PReP to fb entirely if it's reasonable that it will
> } > work on all PReP boxes.  Any suggestions?
> } 
> } I don't think it will work on all PReP boxes yet. There's no frame buffer
> } device for S3 [89]6[48] yet :-(
> } 
> } > } Does this work on your boxes? I really like to have this fixed.
> } > } 
> } > } Finally I found some time to sort out the PPC scr_{read,write}w() mess.
> } > } Now scr_{read,write}w() always swaps bytes if {vga,mda}con was compiled in,
> } > } while we did a runtime check before.
> } > } 
> } > } This patch matters specifically for people with PReP boxes, who may want to use
> } > } vgacon on one head and a real frame buffer device on either a second head or on
> } > } the first head after boot up (insmod *fb.o takes over vgacon).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-10-29  8:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <19991028215345.A13930@chimaera.ppc.kernel.org>
1999-10-29  7:22 ` PPC scr_{read,write}w() cleanup (fwd) Geert Uytterhoeven
1999-10-29  7:58   ` Cort Dougan
1999-10-29  8:48     ` Geert Uytterhoeven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).