Re: RE: [Dri-devel] Memory management of AGP and VRAM

Re: RE: [Dri-devel] Memory management of AGP and VRAM

[Ian Romanick]

Egbert Eich wrote:

> However chipset probing/display device probing and mode setting isn't
> required to live in kernel space. Portability and system stability 
> arguments speak against it. In fact only Apple MAC users seem to
> advocate this idea to be able to an initial video mode on their
> systems.

Allow me to speak up for users of IBM pSeries hardware or Sun SPARC 
hardware.  Users of those systems face exactly the same issues as Mac 
users.  I imagine most embedded systems will be in the same boat.  Being 
forced to use a serial console for early boot messages is so 1980's. ;)

The kernel doesn't need to have support for everything, but I think it's 
important to have at least minimal support.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: RE: [Dri-devel] Memory management of AGP and VRAM

[Jon Smirl]

Can you run grub or lilo on these machines?

Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
computations moved to user space. When you add up that code there is about 40K
of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers
start probing for multiple heads, TV support, etc that code is going to get even
larger. Since the code is used only rarely (in kernel terms) this code should be
in user space instead of the driver.

I've also proposed that if you really, really want to you could do the DDC
probing the in driver at boot and mark all of the code _init. Then the user
space code would take over after that. Note that I'm talking about early
userspace (initrd) timeframe, not normal user space.

--- Ian Romanick <idr@us.ibm.com> wrote:
> Egbert Eich wrote:
> 
> > However chipset probing/display device probing and mode setting isn't
> > required to live in kernel space. Portability and system stability 
> > arguments speak against it. In fact only Apple MAC users seem to
> > advocate this idea to be able to an initial video mode on their
> > systems.
> 
> Allow me to speak up for users of IBM pSeries hardware or Sun SPARC 
> hardware.  Users of those systems face exactly the same issues as Mac 
> users.  I imagine most embedded systems will be in the same boat.  Being 
> forced to use a serial console for early boot messages is so 1980's. ;)
> 
> The kernel doesn't need to have support for everything, but I think it's 
> important to have at least minimal support.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: RE: [Dri-devel] Memory management of AGP and VRAM

[Holger Waechtler]

Jon Smirl wrote:
> Can you run grub or lilo on these machines?

The equivalent loader is called MILO for SPARC and Yaboot for PowerPC. 
The BIOS equivalent is called OpenFirmware and provides a helper API for 
mode setting and graphics card initialisation.

There are comments in the drivers which mark other than the default 
modes as TODO (e.g. 'these are somewhat sane defaults for Mac boards, we 
will need to find a good way of getting these from OpenFirmware'), I 
don't know whether they are rooted in missing docs or in technical 
troubles communicating with the OpenFirmware.

Holger


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: RE: [Dri-devel] Memory management of AGP and VRAM

[Holger Waechtler]

Holger Waechtler wrote:
> Jon Smirl wrote:
> 
>> Can you run grub or lilo on these machines?
> 
> 
> The equivalent loader is called MILO for SPARC and Yaboot for PowerPC. 

oops -- the SPARC image loader was called SILO. MILO was the mini image 
loader for Alpha.

sorry for confusion,

Holger


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Mesa3d-dev] RE: [Dri-devel] Memory management of AGP and VRAM

[Alan Cox]

On Sul, 2004-05-09 at 17:45, Jon Smirl wrote:
> Also, these is no rule saying a device driver can't have several tables of _init
> register values that can be used to set the mode on a primary monitor at boot. I
> would just like to see all of the code that does DDC decoding and modeline
> computations moved to user space.

But there should also be no rule that says it cannot be in kernel space.
Lets take the Voodoo2 again, the mode computation is *tiny*.
Or many embedded devices where the modes are very simple to set up.

The API at user space for the driver modules has to leave the question
of *who* does what private to the driver.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Re: RE: [Dri-devel] Memory management of AGP and VRAM

[James Simmons]

> Also, these is no rule saying a device driver can't have several tables of _init
> register values that can be used to set the mode on a primary monitor at boot. I
> would just like to see all of the code that does DDC decoding and modeline
> computations moved to user space. When you add up that code there is about 40K
> of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers
> start probing for multiple heads, TV support, etc that code is going to get even
> larger. Since the code is used only rarely (in kernel terms) this code should be
> in user space instead of the driver.
> 
> I've also proposed that if you really, really want to you could do the DDC
> probing the in driver at boot and mark all of the code _init. Then the user
> space code would take over after that. Note that I'm talking about early
> userspace (initrd) timeframe, not normal user space.

DDC probing is still new. I doubt it will be that large in the long run. I 
bet we will see redudency in the drivers that we seperate out. Give me 
time and I can show that it will be minimum code.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: RE: [Dri-devel] Memory management of AGP and VRAM

[Egbert Eich]

Jon Smirl writes:
 > Can you run grub or lilo on these machines?
 > 
 > Also, these is no rule saying a device driver can't have several tables of _init
 > register values that can be used to set the mode on a primary monitor at boot. I
 > would just like to see all of the code that does DDC decoding and modeline
 > computations moved to user space. When you add up that code there is about 40K
 > of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers
 > start probing for multiple heads, TV support, etc that code is going to get even
 > larger. Since the code is used only rarely (in kernel terms) this code should be
 > in user space instead of the driver.
 > 
 > I've also proposed that if you really, really want to you could do the DDC
 > probing the in driver at boot and mark all of the code _init. Then the user
 > space code would take over after that. Note that I'm talking about early
 > userspace (initrd) timeframe, not normal user space.

Wouldn't it be the job of the kernel bootstrap process to do this initial setup?
This bootstrap code would be wiped once the kernel starts up.

 > 
 > > 
 > > Allow me to speak up for users of IBM pSeries hardware or Sun SPARC 
 > > hardware.  Users of those systems face exactly the same issues as Mac 
 > > users.  I imagine most embedded systems will be in the same boat.  Being 
 > > forced to use a serial console for early boot messages is so 1980's. ;)
 > > 
 > > The kernel doesn't need to have support for everything, but I think it's 
 > > important to have at least minimal support.
 > > 

I'm not speaking about a text mode. 
I would think on most systems the firmware would provide some reasonable
initial mode that the kernel can use. If there is no such firmware one 
would expect there is some preboot software that is used to bootstrap the
kernel that could do such a setup - using a number of fixed modes hard
coded in tables. (It is a pain to debug, though).

Cheers,
	Egbert.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Re: RE: [Dri-devel] Memory management of AGP and VRAM

[James Simmons]

> I'm not speaking about a text mode. 
> I would think on most systems the firmware would provide some reasonable
> initial mode that the kernel can use. If there is no such firmware one 
> would expect there is some preboot software that is used to bootstrap the
> kernel that could do such a setup - using a number of fixed modes hard
> coded in tables. (It is a pain to debug, though).

   You haven't done to work much with embedded hardware. So instead of one 
graphics driver initailzing the hardware for every platform we need to 
force all the embedded companies out there to add code to there boot 
setups to initialize the different possible graphics cards out there. 
That is alot of duplicated work for nothing.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3