linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Framebuffer with banked memory

[Antonino D. <ad...@po...>]

On Thu, 2002-10-31 at 12:02, alain volmat wrote:
> 
> What about adding fb_write / fb_read function in the
> framebuffer (device dependant) driver. The same way as
> for fb_mmap. I saw that at the beginning of fb_mmap in
> fbmem.c, there is a test to see if the device driver
> contains its own fb_mmap function, if so the device
> driver fb_mmap will be used instead of the "generic"
> fb_mmap. What about doing the same thing for fb_write
> / fb_read.
> 
I've seen a post by James sometimes ago about adding fb_write and
fb_read to info->fbops.  

Tony

[Linux-fbdev-devel] Re: [BK console] console updates.

[Svetoslav S. <ga...@st...>]

Quoting Andreas Schuldei <an...@sc...>:

> > 3) Multi-desktop systems. Already done this. The current code in BK
> >    doesn't support this just yet as I have a few bug to beat out for
> >    single headed systems. It will take about one more week to get
> this
> >    ready.
> 
> this is something i know several people are interested in. and it
> does not touch core code to add, does it?
> 
> This is my personal-favorit-must-go-in-above-all-else-feature.
> 

My too,
except may be working lvm and soft-raid

Re: [Linux-fbdev-devel] request_mem_region problem ...

[Sven L. <lu...@dp...>]

On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote:
> On Wed, 2002-10-30 at 21:00, Sven Luther wrote:
> > Hello, ...
> > 
> > I have begun porting pm3fb to the new api, well, more exactly i am
> > adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
> > as i need them.
> > 
> > I have a problem when loading pm3fb as a module, and that is that
> > request_mem_region fails. I know that pm3_fix.mmio_start and
> > pm3_fix.mmio_len are correct, but request_mem_region still fails.
> > 
> > I am still searching the definition of request_mem_region in the source,
> > but any help would be most welcome.
> > 
> > Note, this is with stock 2.5.44.
> > 
> Try doing a pci_enable_device() before request_mem_region, maybe that
> will help.

I already solutioned this problem.

BTW, i don't understand how the tdfxfb does not have this problem, as it
is from there that i tried to sole this.

The problem was that i did :

        /* Find the mmio register area */
	pm3_fix.mmio_start = pci_resource_start(pdev, 0);
	pm3_fix.mmio_len = pci_resource_len(pdev, 0);

And later :

	if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ...

Changing this to :

	if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ...

Solved the problem, so it seems that the pci_resource_ functions can be
called only one time. Is this true ?

Now, i seem to have everything fine, but it still hangs in
register_framebuffer, a bit of searching has it that it is when
register_framebuffer calls take_over_console. I didn't have time for
looking into it more yesterday.

Still the screen is black, and i see a small (underscore) blinking
cursor at the bottom left of the screen. The machine was dead though :

Oct 30 23:15:53 iliana kernel:  printing eip:
Oct 30 23:15:53 iliana kernel: c023affc
Oct 30 23:15:53 iliana kernel: Oops: 0000
Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx
Oct 30 23:15:53 iliana kernel: CPU:    0
Oct 30 23:15:53 iliana kernel: EIP:    0060:[fbcon_cursor+108/480] Not tainted
Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246
Oct 30 23:15:53 iliana kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c1143240
Oct 30 23:15:53 iliana kernel: esi: c042d280   edi: 00000002   ebp: 00000018   esp: c4dcbc10
Oct 30 23:15:53 iliana kernel: ds: 0068   es: 0068   ss: 0068
Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040)
Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000
Oct 30 23:15:53 iliana kernel:        c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30
Oct 30 23:15:53 iliana kernel:        00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf

How, well, maybe i should wait for the new patches from James to be
accepted into the linus tree.

Notice, maybe this is due to me not having defined yet any of the
check_var, set_par, blank, ... functions, but my idea, for the howto
afterward, was to write first the most minimal working fbdev.

BTW, should i work on james BK tree directly ? Is there an howto on how
to do that ? Or could it be possible to get a patch against 2.5.44 ?

> > Also, if i register the framebuffer, without defining any of the
> > fillrect, copyarea and imageblit functions (even the generic ones) i
> > suppose it is normal i only get a black screen, isn't it ?
> > 
> Yes.

Ok, as i thought, still :

when i try to use the cfb_xxx functions, it does not work. i copied the
neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx
objects, but it does not work. When loading the cfbxxx.o object files as
modules, insmod complains about lack of version in them, so i guess they
are not modules. Still, they don't get linked with the pm3fb.o (and
neither with the neofb.o when i tried it), and when loading pm3fb.o, i
get a message about missing symbols cfb_xxx.

So, does the cfb_xxx generic accel stuff get linked correctly when
building as modules or am i missing something ?

Anyway, thanks for your help.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Framebuffer with banked memory

[<av...@ya...>]

> The safest solution is to create custom fb_write?
> and fb_read? routines.
> Maybe James will add these hooks for hardware like
> yours.
> Then disallow mmap's except probably for the MMIO
> regions.
> 

What about adding fb_write / fb_read function in the
framebuffer (device dependant) driver. The same way as
for fb_mmap. I saw that at the beginning of fb_mmap in
fbmem.c, there is a test to see if the device driver
contains its own fb_mmap function, if so the device
driver fb_mmap will be used instead of the "generic"
fb_mmap. What about doing the same thing for fb_write
/ fb_read.

> PS:  What's your hardware?
Well actually it's a custom chip.

Alain

 --- Antonino Daplas <ad...@po...> a écrit : > On
Wed, 2002-10-30 at 18:49, alain volmat wrote:
> > Hi,
> > 
> > As I said the video card I am now writing a
> > framebuffer for, doesn't have linear memory, which
> > means that I can only access a small part of the
> > memory at a time and then set offset registers in
> > order to access another part of the memory.
> > 
> > I would like to know if there is such case in
> current
> > framebuffer drivers ?? If so, what is the common
> > solution to do that ??
> None in the current drivers.  
> 
> > 
> > In fact the problem remains in the case of mmap
> (which
> > is the most common ;( of course), since the memory
> > seams to be accessed directly by pointer, there
> might
> > be no wait to detect if we need to set or not an
> > offset. In case of fb_read fb_write, it is
> possible to
> > do that before the actual write at the end (even
> if it
> > is not sooo beautiful ... ).
> The safest solution is to create custom fb_write?
> and fb_read? routines.
> Maybe James will add these hooks for hardware like
> yours.
> Then disallow mmap's except probably for the MMIO
> regions.
> 
> Creating a bank-switching mechanism, besides
> entailing a lot of work, is
> not entirely safe.
> 
> Tony
> 
> PS:  What's your hardware?
> 
> 
> 


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: [Linux-fbdev-devel] Framebuffer with banked memory

[Antonino D. <ad...@po...>]

On Wed, 2002-10-30 at 18:49, alain volmat wrote:
> Hi,
> 
> As I said the video card I am now writing a
> framebuffer for, doesn't have linear memory, which
> means that I can only access a small part of the
> memory at a time and then set offset registers in
> order to access another part of the memory.
> 
> I would like to know if there is such case in current
> framebuffer drivers ?? If so, what is the common
> solution to do that ??
None in the current drivers.  

> 
> In fact the problem remains in the case of mmap (which
> is the most common ;( of course), since the memory
> seams to be accessed directly by pointer, there might
> be no wait to detect if we need to set or not an
> offset. In case of fb_read fb_write, it is possible to
> do that before the actual write at the end (even if it
> is not sooo beautiful ... ).
The safest solution is to create custom fb_write? and fb_read? routines.
Maybe James will add these hooks for hardware like yours.
Then disallow mmap's except probably for the MMIO regions.

Creating a bank-switching mechanism, besides entailing a lot of work, is
not entirely safe.

Tony

PS:  What's your hardware?

Re: [Linux-fbdev-devel] request_mem_region problem ...

[Antonino D. <ad...@po...>]

On Wed, 2002-10-30 at 21:00, Sven Luther wrote:
> Hello, ...
> 
> I have begun porting pm3fb to the new api, well, more exactly i am
> adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
> as i need them.
> 
> I have a problem when loading pm3fb as a module, and that is that
> request_mem_region fails. I know that pm3_fix.mmio_start and
> pm3_fix.mmio_len are correct, but request_mem_region still fails.
> 
> I am still searching the definition of request_mem_region in the source,
> but any help would be most welcome.
> 
> Note, this is with stock 2.5.44.
> 
Try doing a pci_enable_device() before request_mem_region, maybe that
will help.

> Also, if i register the framebuffer, without defining any of the
> fillrect, copyarea and imageblit functions (even the generic ones) i
> suppose it is normal i only get a black screen, isn't it ?
> 
Yes.

Tony

[Linux-fbdev-devel] Re: [BK console] console updates.

[Martin J. B. <mb...@ar...>]

> * Skip Ford <ski...@ve...> on Wed, Oct 30, 2002:
> 
>> James Simmons wrote:
>> > 
>> > bk://linuxconsole.bkbits.net
>> > 
>> > BTW I will make patches avaiable as soon as 2.5.45 comes out.
>> 
>> Don't even bother posting to the list without a patch.  Saying you want
>> testers and not providing a patch is just rediculous.
>> 
> 
> Not knowing where/how to stay current is also a bit ridiculous.
> 
> http://sf.net/projects/linuxconsole/.  Click on "CVS".

Yeah, of course ... his psychic power must be weakening, he 
should have magically been able to guess that because ....

That's not a patch, it's a CVS tree. Just mail out a normal
patch, like everyone else.

M.

[Linux-fbdev-devel] Re: [BK console] console updates.

[M. R. B. <mr...@0x...>]

* Skip Ford <ski...@ve...> on Wed, Oct 30, 2002:

> James Simmons wrote:
> >=20
> > bk://linuxconsole.bkbits.net
> >=20
> > BTW I will make patches avaiable as soon as 2.5.45 comes out.
>=20
> Don't even bother posting to the list without a patch.  Saying you want
> testers and not providing a patch is just rediculous.
>=20

Not knowing where/how to stay current is also a bit ridiculous.

http://sf.net/projects/linuxconsole/.  Click on "CVS".

M. R.

[Linux-fbdev-devel] Re: [BK console] console updates.

[Skip F. <ski...@ve...>]

James Simmons wrote:
> 
> bk://linuxconsole.bkbits.net
> 
> BTW I will make patches avaiable as soon as 2.5.45 comes out.

Don't even bother posting to the list without a patch.  Saying you want
testers and not providing a patch is just rediculous.

-- 
Skip

[Linux-fbdev-devel] Re: [BK console] console updates.

[Andreas S. <an...@sc...>]

> 3) Multi-desktop systems. Already done this. The current code in BK
>    doesn't support this just yet as I have a few bug to beat out for
>    single headed systems. It will take about one more week to get this
>    ready.

this is something i know several people are interested in. and it
does not touch core code to add, does it?

This is my personal-favorit-must-go-in-above-all-else-feature.

[Linux-fbdev-devel] Re: [BK fbdev updates]

[Russell K. <rm...@ar...>]

On Wed, Oct 30, 2002 at 01:42:21PM -0800, James Simmons wrote:
>   The latest changes to the framebuffer layer are avaiable to be merged.
> The changes include the final removal of all console related code in the
> low level drivers. This allows for a very simple api. Also with this
> design is to possible to run a test/debug a fbdev driver without the
> framebuffer console. We can use another console system to see the results
> of what we have done. This will allow greater speed at developing a new
> driver because of the new simple api and the new approaches at
> debugging them. Please merge with your tree.
> 
> bk://fbdev.bkbits.net/fbdev-2.5

I'm getting sick to death of asking this.

D I F F S T A T.

G N U P A T C H.

Why can't you make a script that automatically generates these for you?

What do we need to do to you to make you do this?

If you're not willing to do your part, don't be surprised when people
ignore you when maintaining their framebuffer drivers.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Re: [BK console] console updates.

[Christoph H. <hc...@in...>]

On Wed, Oct 30, 2002 at 01:56:38PM -0800, James Simmons wrote:
> I doubt this code will go into 2.5.X but it is avaiable for anyone to play
> with it.

Why?  I don't want to live another release with the old, crappy console,
and you've been working on this during almost all of 2.4 now..

RE: [Linux-fbdev-devel] Framebuffer with banked memory

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

Alain,
   I worked on an i810 driver that would use the banked memory instead =
of
requiring agp to be functioning at boot time (See the other thread =
going on
now).  Basically the i810 can use banked memory OR have agpgart.
  The short answer to your problem is that, sadly, much of the 2.4
framebuffer is badly implemented, allowing device independent code to
directly access device memory etc. Some of this is cleaned up for 2.5, =
but
as I've not looked at it lately I'm not sure how much.  Here are some
pointers as to what is required for 2.4.

#1 The Boot penguin code directly accesses your video memory. If you =
have
banked memory this will likely fall off the end of a pointer and oops =
the
kernel or worse.

#2 Read/Write Access video memory directly. I had added a read/write
handler to the fb_ops to hook these out and switch banks.=20
Read/write are also incorrect if your pitch !=3D width.

#3 Memory map can't be done. I had coded up a working version that =
would
map a single back and page fault in the banks as necessary. This worked
but would get hung up on unaligned accesses where one instruction =
accessed
two memory banks at the same time. So memory map isn't possible.

 The jist was that I could disable memory map. Implement character =
drawing
with bank switching. Implement read/write handlers that did bank =
switching,
then make the read/write fops use the handlers. Then lastly redo the
penguin drawing code to use the write handler rather than direct =
access.
All this to get a console... and not much else.

-Matt



-----Original Message-----
From: alain volmat [mailto:av...@ya...]
Sent: Wednesday, October 30, 2002 2:49 AM
To: lin...@li...
Subject: [Linux-fbdev-devel] Framebuffer with banked memory


Hi,

I've been searching on the mailing list concerning the
case of writing a framebuffer for a video card which
DOESN'T have linear video memory. Actually I didn't
found any reply to my question.
(well this might means that there is no solution to my
problem .. but in that case I would like
confirmation).

As I said the video card I am now writing a
framebuffer for, doesn't have linear memory, which
means that I can only access a small part of the
memory at a time and then set offset registers in
order to access another part of the memory.

I would like to know if there is such case in current
framebuffer drivers ?? If so, what is the common
solution to do that ??

In fact the problem remains in the case of mmap (which
is the most common ;( of course), since the memory
seams to be accessed directly by pointer, there might
be no wait to detect if we need to set or not an
offset. In case of fb_read fb_write, it is possible to
do that before the actual write at the end (even if it
is not sooo beautiful ... ).

Anyway, it would be very helpful to me if I could get
an answer to this question.
Thanks by advance.

Alain Volmat

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais !
Yahoo! Mail : http://fr.mail.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future=20
of Java(TM) technology. Join the Java Community=20
Process(SM) (JCP(SM)) program now.=20
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Linux-fbdev-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] [BK console] console updates.

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

Hi folks!!!

   Along with the new fbdev api I also have rewritten the console layer.
The goals are:

1) The idea here was to move alot of the basic functionaly present in
   alot of low level drivers into the the higher layers thus making the
   low level drivers smaller and cleaner. A good example is using the
   /dev/fb interface to resize a VC. That is just plain dumb.

2) The second goal was to seperate out the terminal emulation to allow
   for a light weight printk. Also the idea was to make the VT console
   system modular. On embedded devices then we can insmod the VT
   console system. This is partially done.

3) Multi-desktop systems. Already done this. The current code in BK
   doesn't support this just yet as I have a few bug to beat out for
   single headed systems. It will take about one more week to get this
   ready.


I doubt this code will go into 2.5.X but it is avaiable for anyone to play
with it.

bk://linuxconsole.bkbits.net

BTW I will make patches avaiable as soon as 2.5.45 comes out.

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

RE: [Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

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

I made quite a large effort to work out a mechanism for enabling the i810
before the AGP but I was just never happy with any of the solutions. As
Tony et all mentioned, the cleanest way is to just let the gart driver come
up before the Framebuffer.

 -Matt


-----Original Message-----
From: Antonino Daplas [mailto:ad...@po...]
Sent: Tuesday, October 29, 2002 9:33 PM
To: James Simmons
Cc: Dave Jones; Linux Kernel Mailing List; Linux Fbdev development list
Subject: [Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.


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 





-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Linux-fbdev-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] [BK fbdev updates]

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

Hi!

  The latest changes to the framebuffer layer are avaiable to be merged.
The changes include the final removal of all console related code in the
low level drivers. This allows for a very simple api. Also with this
design is to possible to run a test/debug a fbdev driver without the
framebuffer console. We can use another console system to see the results
of what we have done. This will allow greater speed at developing a new
driver because of the new simple api and the new approaches at
debugging them. Please merge with your tree.

bk://fbdev.bkbits.net/fbdev-2.5


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

[Linux-fbdev-devel] request_mem_region problem ...

[Sven L. <lu...@dp...>]

Hello, ...

I have begun porting pm3fb to the new api, well, more exactly i am
adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
as i need them.

I have a problem when loading pm3fb as a module, and that is that
request_mem_region fails. I know that pm3_fix.mmio_start and
pm3_fix.mmio_len are correct, but request_mem_region still fails.

I am still searching the definition of request_mem_region in the source,
but any help would be most welcome.

Note, this is with stock 2.5.44.

Also, if i register the framebuffer, without defining any of the
fillrect, copyarea and imageblit functions (even the generic ones) i
suppose it is normal i only get a black screen, isn't it ?

Friendly,

Sven Luther

[Linux-fbdev-devel] Framebuffer with banked memory

[<av...@ya...>]

Hi,

I've been searching on the mailing list concerning the
case of writing a framebuffer for a video card which
DOESN'T have linear video memory. Actually I didn't
found any reply to my question.
(well this might means that there is no solution to my
problem .. but in that case I would like
confirmation).

As I said the video card I am now writing a
framebuffer for, doesn't have linear memory, which
means that I can only access a small part of the
memory at a time and then set offset registers in
order to access another part of the memory.

I would like to know if there is such case in current
framebuffer drivers ?? If so, what is the common
solution to do that ??

In fact the problem remains in the case of mmap (which
is the most common ;( of course), since the memory
seams to be accessed directly by pointer, there might
be no wait to detect if we need to set or not an
offset. In case of fb_read fb_write, it is possible to
do that before the actual write at the end (even if it
is not sooo beautiful ... ).

Anyway, it would be very helpful to me if I could get
an answer to this question.
Thanks by advance.

Alain Volmat

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

[Antonino D. <ad...@po...>]

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 

[Linux-fbdev-devel] [BK fbdev changes]

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

Okay until the issue of AGP handling is solved I moved the drm and agp
code back into drivers/char. Just teh fbdev changes are in drivers/video.
Can you pull them. Thank you.

bk://fbdev.bkbits.net/fbdev-2.5

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

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

[Alan C. <al...@lx...>]

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

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

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

> 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.

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

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

> > > 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 :-)

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

[Christoph H. <hc...@in...>]

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.

[Linux-fbdev-devel] Re: [BK updates] fbdev changes updates.

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

> 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.