linux-fbdev-devel

[Linux-fbdev-devel] On i810/i815 fb issues

[Sottek, M. J <mat...@in...>]

I've read over some of the discussion of the i810/i815
framebuffer discussion, and given the code a cursory look. I
currently work for an embedded development group at Intel
and I've been doing X work for quite a while on these
chipsets, so I thought I would jump into the conversation.

First, looking at the code it seems the main reason this
fb driver hasn't received more support is due to the
competition between X and the fb driver for the gart
resources. Why don't we just make a version of this driver
that makes use of stolen memory only (1MB) and does not use
the ringbuffer. This would give us all modes under 1MB in
size (10x7 at 8bit, 8x6 at 16bit) which is the way the
chipset is supported in all non AGP environments. (OS2, Dos
etc.) This would remove all competition between X and the
fb driver for resources...makes everyone's life easier.

The major need for a framebuffer driver that my customers have
is for graphical booting, and very basic embedded output like
near-static displays. Almost all embedded devices that need
acceleration are doing so via X and only need the framebuffer
during bootup.

Other applications that wish to allocate a ringbuffer and
a larger framebuffer could do so with a (not default) option
such that the vast majority of users can have their boot
penguin and X too.  I think we could even get blits working
without the ringbuffer by programming the part directly, but
that has limited use anyway.

 I don't want to discourage use of the acceleration for the
devices that may need it, but I don't really want to see
lots of problems arise from people trying to use fbdev and
X at the same time to no avail.

please cc me on replies,
-Matt
 

Re: [Linux-fbdev-devel] On i810/i815 fb issues

[tea a. <th...@ag...>]

Thanks Matthew for your statement!

First I have to correct a link I yesterday sent. This should work now:

http://www.visuelle-maschinen.de/ctfb/i810/i810fb_XFree_Issue

It contains answers to this problem given by Jeff Hartmann, Sottek, Matthew J 
and Anda MuniReddy.

The main issue from my point of view was mentioned by Anda MuniReddy:

"Agpgart doesn't have a interface so that any driver can ask for X amount of 
graphics memory. It assumes that only one client is using and he knows where 
he binded the memory."

From my point of view we need to solve that. All other thinks are just 
workarounds. 

I use XF86_FBDev on top of i810fb as a temporary solution.

By the way: i810fb seems to have a problem with 8 bpp. I guess it is caused 
by wrong values in the first 16 colors in cmap in that mode.

Thomas

Am Tuesday 10 July 2001 03:03, schrieb Sottek, Matthew J: / On Tuesday 10 
July 2001 03:03, Sottek, Matthew J wrote:
> I've read over some of the discussion of the i810/i815
> framebuffer discussion, and given the code a cursory look. I
> currently work for an embedded development group at Intel
> and I've been doing X work for quite a while on these
> chipsets, so I thought I would jump into the conversation.
>
> First, looking at the code it seems the main reason this
> fb driver hasn't received more support is due to the
> competition between X and the fb driver for the gart
> resources. Why don't we just make a version of this driver
> that makes use of stolen memory only (1MB) and does not use
> the ringbuffer. This would give us all modes under 1MB in
> size (10x7 at 8bit, 8x6 at 16bit) which is the way the
> chipset is supported in all non AGP environments. (OS2, Dos
> etc.) This would remove all competition between X and the
> fb driver for resources...makes everyone's life easier.
>
> The major need for a framebuffer driver that my customers have
> is for graphical booting, and very basic embedded output like
> near-static displays. Almost all embedded devices that need
> acceleration are doing so via X and only need the framebuffer
> during bootup.
>
> Other applications that wish to allocate a ringbuffer and
> a larger framebuffer could do so with a (not default) option
> such that the vast majority of users can have their boot
> penguin and X too.  I think we could even get blits working
> without the ringbuffer by programming the part directly, but
> that has limited use anyway.
>
>  I don't want to discourage use of the acceleration for the
> devices that may need it, but I don't really want to see
> lots of problems arise from people trying to use fbdev and
> X at the same time to no avail.
>
> please cc me on replies,
> -Matt
>
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Xpert]Re: [Linux-fbdev-devel] On i810/i815 fb issues

[tea a. <th...@vi...>]

Concerning the licence I agree from my point of view with GNU. But the author 
of i810fb is Anda MuniReddy.

Today I uploaded version 1.07 of i810fb. It contains the i810e patch from 
Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor 
changes regarding the hint from Geert Uytterhoeven (not all ID's are define 
in pci_ids.h!).

Pleas check the following link:

http://www.visuelle-maschinen.de/ctfb/i810/

Concerning the issue discussion I like the idea of Jeff Hartmann. I still 
think Sottek, Matthew J's solution is just a workaround. Also I prefer high 
resolutions on the console. 

Please, who knows how to put the i180fb source into a public CVS, or better 
into the kernel sources, if the licence question is clear.

Here is some of the discussion again, because not all mails went also to the 
Linux-fbdev-devel list:
-----------------------------------------------------------------------------------------------------------------
Jeff Hartmann wrote:

>
> The only way to properly solve that is to have some sort of mechanism in
> the Xserver which tells the fbdriver to release agpgart and unbind its
> memory during Xserver initialization.  Then at VT switch and Xserver
> close we can call fbdev telling it that it can use the memory again.  If
> someone gives me an interface to do this, I will add it to the Xserver
> code.  I know nothing about the fbdev API, so if it already has this
> sort of thing, then enlighten me.
>
> I will not make the agpgart driver into a general allocation API, it
> just adds cruft to the kernel, and wastes memory which can not be
> swapped out.  Its the wrong solution.  Any generalized allocator belongs
> in user space, not in the kernel.
>

Sottek, Matthew J wrote:

>>> I've read over some of the discussion of the i810/i815
>>> framebuffer discussion, and given the code a cursory look. I
>>> currently work for an embedded development group at Intel
>>> and I've been doing X work for quite a while on these
>>> chipsets, so I thought I would jump into the conversation.
>>> 
>>> First, looking at the code it seems the main reason this
>>> fb driver hasn't received more support is due to the
>>> competition between X and the fb driver for the gart
>>> resources. Why don't we just make a version of this driver
>>> that makes use of stolen memory only (1MB) and does not use
>>> the ringbuffer. This would give us all modes under 1MB in
>>> size (10x7 at 8bit, 8x6 at 16bit) which is the way the
>>> chipset is supported in all non AGP environments. (OS2, Dos
>>> etc.) This would remove all competition between X and the
>>> fb driver for resources...makes everyone's life easier.
>>> 

Jeff Hartmann wrote:

>> I think this is also a more then satisfactory solution.  
>> Anyone want to 
>> implement it?

Sottek, Matthew J wrote:

> I'll look at it as soon as I get a spare second. I think the
> current driver is probably pretty close already.
> 
> Jeff, do you remember what the current status of the Stolen
> memory is? Do you map it into the Gtt or just leave it alone?


Jeff Hartmann wrote:

> The I810/I815 drivers don't touch stolen memory at this time.
 

Re: [Xpert]Re: [Linux-fbdev-devel] On i810/i815 fb issues

[Geert U. <ge...@li...>]

On Wed, 11 Jul 2001, tea age wrote:
> Today I uploaded version 1.07 of i810fb. It contains the i810e patch from 
> Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor 

The readme is not accessible.

> changes regarding the hint from Geert Uytterhoeven (not all ID's are define 
> in pci_ids.h!).

Then add them to pci_ids.h.

If you want your driver to work with or without a newer pci_ids.h, use a scheme
like this in your driver:

#ifndef DEFINE_THAT_MAY_BE_MISSING
#define DEFINE_THAT_MAY_BE_MISSING	VALUE
#endif

> Please, who knows how to put the i180fb source into a public CVS, or better 
> into the kernel sources, if the licence question is clear.

We can put it at http://sourceforge.net/projects/linux-fbdev/. Just register
for a SourceForge account and tell James, Brad or me your ID, so we can add you
to the project.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] On i810/i815 fb issues

[James S. <jsi...@tr...>]

> "Agpgart doesn't have a interface so that any driver can ask for X amount of 
> graphics memory. It assumes that only one client is using and he knows where 
> he binded the memory."

From all the emails I have seen it is really strange how the system for
agp is setup. On IRIX systems each OpenGL client allocates memory and uses
a seperate library (udma) to lock down the memory. Then the OpenGL driver 
for the card sends the kernel driver what memory to use. The driver sets
it up and data is tranfered. Once done the client frees the memory.

Re: [Linux-fbdev-devel] On i810/i815 fb issues

[Jeff H. <jha...@va...>]

James Simmons wrote:

>> "Agpgart doesn't have a interface so that any driver can ask for X amount of 
>> graphics memory. It assumes that only one client is using and he knows where 
>> he binded the memory."
> 
> 
> >From all the emails I have seen it is really strange how the system for
> agp is setup. On IRIX systems each OpenGL client allocates memory and uses
> a seperate library (udma) to lock down the memory. Then the OpenGL driver 
> for the card sends the kernel driver what memory to use. The driver sets
> it up and data is tranfered. Once done the client frees the memory.
> 
> 
> 
The IRIX implementers had access to much different hardware, agp is not 
as flexible as some of the uma stuff in SGI hardware.

Inserting random pieces of memory into the agp aperture requires a cache 
flush because of the use of write combining memory.  You want to avoid 
swapping memory in and out of cached and ucwc spaces, its terribly 
expensive.  Also if the client accesses the memory through its normal 
mappings while it is mapped into ucwc space, things will go boom.  This 
means that you have to invalidate the original mappings when you lock 
down the memory.  All this is feasible to handle with PAT, but it will 
perform like shit on an x86.  This sort of interface does not make sense 
for agp.  It should also be noted that removing pieces of memory from 
the agp aperture will normally require a graphics pipeline flush, so we 
don't want drivers doing that sort of operation too often.

Basically the agp interface has been well thought out, and I believe 
that it is the best solution considering all the problems and the fact 
that PAT isn't shipping with 2.4.  I'm sure some people might want a 
malloc type interface, but I don't want to be responsible for creating a 
driver which keeps tons of mm book keeping in the kernel where it can't 
be swapped.

-Jeff