Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@in...> - 2002-10-29 19:52:03
|
Hi!!!
Here are the last series of fbdev changes. The console layer code has
been removed from the low level drivers. This it is possible to run fbdev
without the VT console system or with it using a different driver. I did
this with the VESA fbdev driver and MDA con!!!! This will save so much
time testing future fbdev drivers.
I also moved the agp and drm code over to drivers/video. The reason I
did this was to support fbdev drivers that will be strickly DMA/AGP
based. The reason for this is we will see in the future embedded ix86
boards with things like i810 framebuffers with NO vga core. In this case
we will need a fbdev driver for a graphical console. Thus the agp code
must be started before the fbdev layer.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@us...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: James S. <jsi...@in...> - 2002-10-29 19:53:05
|
OOps. Forgot the link. bk://fbdev.bkbits.net/fbdev-2.5 Thank you. |
|
From: Christoph H. <hc...@in...> - 2002-10-29 20:55:42
|
On Tue, Oct 29, 2002 at 12:46:16PM -0800, James Simmons wrote: > > OOps. Forgot the link. > > bk://fbdev.bkbits.net/fbdev-2.5 Does it still contain the random file movearounds? |
|
From: James S. <jsi...@in...> - 2002-10-29 21:15:30
|
> On Tue, Oct 29, 2002 at 12:46:16PM -0800, James Simmons wrote: > > > > OOps. Forgot the link. > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > Does it still contain the random file movearounds? The reason I did this was to prevent adding another chuck of agp code. The current work around for AGP fbdev drivers to have there OWN AGP code. So we can leave the agp drivers where they are at or the framebuffer layer can have its own AGP code for itself. Which way do you think it should be done? 1) Fbdev layer has it own AGP layer 2) Use already existing AGP layer code. |
|
From: Christoph H. <hc...@in...> - 2002-10-29 21:18:08
|
On Tue, Oct 29, 2002 at 02:08:37PM -0800, James Simmons wrote: > > > On Tue, Oct 29, 2002 at 12:46:16PM -0800, James Simmons wrote: > > > > > > OOps. Forgot the link. > > > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > > > Does it still contain the random file movearounds? > > The reason I did this was to prevent adding another chuck of agp code. The > current work around for AGP fbdev drivers to have there OWN AGP code. So > we can leave the agp drivers where they are at or the framebuffer layer > can have its own AGP code for itself. Which way do you think it should be > done? > > 1) Fbdev layer has it own AGP layer > > 2) Use already existing AGP layer code. Well, I'd be very happy if you could separate different things abit. Everyone wants the console fixes in, but code placement is a bit more of a policy issue and wants more discussion.. Even when they are in different directories the drm drivers can always call into the fbdev drivers as "base modules", like sis currently does. |
|
From: James S. <jsi...@in...> - 2002-10-29 21:30:30
|
> > > On Tue, Oct 29, 2002 at 12:46:16PM -0800, James Simmons wrote: > > > > > > > > OOps. Forgot the link. > > > > > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > > > > > Does it still contain the random file movearounds? > > > > The reason I did this was to prevent adding another chuck of agp code. The > > current work around for AGP fbdev drivers to have there OWN AGP code. So > > we can leave the agp drivers where they are at or the framebuffer layer > > can have its own AGP code for itself. Which way do you think it should be > > done? > > > > 1) Fbdev layer has it own AGP layer > > > > 2) Use already existing AGP layer code. > > Well, I'd be very happy if you could separate different things abit. > Everyone wants the console fixes in, but code placement is a bit more of a > policy issue and wants more discussion.. Even when they are in different > directories the drm drivers can always call into the fbdev drivers as "base > modules", like sis currently does. Fair enough. I'm moving agp and dri back to drivers/char. I would like to discuss a solution to how to initialize the AGP code quicker :-) |
|
From: Dave J. <da...@co...> - 2002-10-29 20:09:53
|
On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > The reason for this is we will see in the future embedded ix86 > boards with things like i810 framebuffers with NO vga core. In this case > we will need a fbdev driver for a graphical console. Thus the agp code > must be started before the fbdev layer. Can you explain exactly what the agpgart code is doing that needs to be done earlier than framebuffer ? I don't see any reason for this change. There should be no GART mappings until we've booted userspace (except for the case of IOMMU) Dave -- | Dave Jones. http://www.codemonkey.org.uk |
|
From: James S. <jsi...@in...> - 2002-10-29 21:14:50
|
> On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > > The reason for this is we will see in the future embedded ix86 > > boards with things like i810 framebuffers with NO vga core. In this case > > we will need a fbdev driver for a graphical console. Thus the agp code > > must be started before the fbdev layer. > > Can you explain exactly what the agpgart code is doing that needs > to be done earlier than framebuffer ? I don't see any reason for this > change. There should be no GART mappings until we've booted userspace > (except for the case of IOMMU) The reason I did this was to prevent adding another chuck of agp code. The current work around for AGP fbdev drivers to have there OWN AGP code. So we can leave the agp drivers where they are at or the framebuffer layer can have its own AGP code for itself. Which way do you think it should be done? 1) Fbdev layer has it own AGP layer 2) Use already existing AGP layer code. |
|
From: James S. <jsi...@in...> - 2002-10-29 21:45:46
|
> On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > > The reason for this is we will see in the future embedded ix86 > > boards with things like i810 framebuffers with NO vga core. In this case > > we will need a fbdev driver for a graphical console. Thus the agp code > > must be started before the fbdev layer. > > Can you explain exactly what the agpgart code is doing that needs > to be done earlier than framebuffer ? I don't see any reason for this > change. There should be no GART mappings until we've booted userspace > (except for the case of IOMMU) Best to ask the author of the i810 framebuffer driver. He can tell you his need for AGP stuff. I CC. |
|
From: Antonino D. <ad...@po...> - 2002-10-30 05:37:22
|
On Wed, 2002-10-30 at 06:38, James Simmons wrote: > > > On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > > > The reason for this is we will see in the future embedded ix86 > > > boards with things like i810 framebuffers with NO vga core. In this case > > > we will need a fbdev driver for a graphical console. Thus the agp code > > > must be started before the fbdev layer. > > > > Can you explain exactly what the agpgart code is doing that needs > > to be done earlier than framebuffer ? I don't see any reason for this > > change. There should be no GART mappings until we've booted userspace > > (except for the case of IOMMU) > > Best to ask the author of the i810 framebuffer driver. He can tell you his > need for AGP stuff. I CC. > > Hi, James is right, I have been tackling with this for ages. I have an i810 driver (http://i810fb.sourceforge.net) that's been "ready" for some time now, but never submitted it for kernel inclusion precisely because of this issue. The i810/1815 has no video memory of it's own, except for memory stolen from system RAM (512 to 1024K). Unfortunately, entire memory is accessible only through bank switching and is primarily used for legacy VGA. Linear memory is availably only through GART mappings. I've seen/done/been thinking of the following approaches: 1. Do custom GART mappings only - abandoned 2. Fake a linear framebuffer by bank switching the 'stolen memory' - this idea is by Matt Sottek, but he might have some problems with this 3. Force loading of agpgart before the console/framebuffer - my current approach in 2.4 4. Do custom GART mappings, wait for agpgart to be available, then use kernel GART mapping routines - my current approach for 2.5 5. Create a fake framebuffer from System RAM, wait for agpgart to be loaded, then map the GART - been toying with this idea The easiest solution for me is to initialize the agpgart ahead of the framebuffer. Since I'm not a kernel hacker, I don't really get a clear picture of the issues involved and I'll be grateful for any input. Thanks Tony |
|
From: Alan C. <al...@lx...> - 2002-10-29 22:11:59
|
On Tue, 2002-10-29 at 20:08, Dave Jones wrote: > On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > > The reason for this is we will see in the future embedded ix86 > > boards with things like i810 framebuffers with NO vga core. In this case > > we will need a fbdev driver for a graphical console. Thus the agp code > > must be started before the fbdev layer. > > Can you explain exactly what the agpgart code is doing that needs > to be done earlier than framebuffer ? I don't see any reason for this > change. There should be no GART mappings until we've booted userspace > (except for the case of IOMMU) The i8xx draws the frame buffer memory from AGP as well as the texture mappings and other goodies. The practical impact of that is that if you want any useful video mode you need AGP initialized first. For UMA video devices its an extremely neat way of avoiding pre-allocation of fixed size frame buffers before the OS boots |
Thanks for helping keep SourceForge clean.
X