linuxconsole-dev

Re: [linux-fbdev] New api again

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

> what if i wanted to write a fbdev for, for example, the 3Dlabs Oxygen GVX420
> board ? 
> 
> For you information this board contains 3 different chip, A gamma 2 chip,
> acting as agp bridge and T&L engine, and 2 Permedia4 chips, doing 3D setup and
> rasterization. They can be configuredto be shared for rasterizing the same
> framebuffer, splitting the scanline between them, or to support dual head.

I assume T&L is texture and lighting engine. 

> Each Pm4 has one pipeline, i think.

First a pipeline is a collect of pipes. Each pipe takes data and changes
it a certain way. This occurs until we reach the end of the pipeline when
we get the final desired rastered image.

Well that depends. Can data be processed by one Pm4 chip and then passed
to the second Pm4 chip to be processed by another stage? A good example
would be say a triangle strip was passed to the the first chip to say be
rotated. Then that data is passed onto the second chip to be tranformed to
give the appearance of a prespective view. In this case their is one
pipeline with 2 pipes. Now if this doesn't occur and each chip processes
data independent of each other then their is two pipelines with one pipe
each. This is of course assuming each GPU, the Pm4's, can't handle more
than one graphics command at a time. Is the T&L shared between both
GPU's. I really have to look at the hardware specs to say exactly. As you
can see for a mor advance card like the Oxygen things get more a bit more
complex. 

> The additional problem, is that you can address the rasterizer chip either
> directly (they have FB and Command register pci aperture, and a separate pci
> id) or trough the Gamma chip, for example, for when doing 3D, you send command
> to the gamma, which process them (T&L) and then forward the low level commands
> to one or both Permedia4 chip. If you want ot use one or both accesses, you
> would need to synchronize correctly between them.

Okay I'm taking a shot in the dark since I don't have the specs but I'm 
assuming the Gamma chip is for DMA, especially since you mentioned that 
it manages the agp port, and the Command register space is for MMIO
programming. Yes you do you have to manage access to both of them. 
Internal to the fbdev driver this is pretty simple. When userland wants to
play around with this stuff then you need a RRM (rendering resource
manager) to balance access. As 2.4.X stands right now you can't use the 
DMA with fbcon but I will be working on this problem right now. 

Re: [linux-fbdev] New api again

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

Thanks for the bitplanes info. I'm going to figure out some routines to
do a rectfill, copyarea, and a imageblit.

> > Yes but for the standard packed pixel non accelerated graphics cards we
> > have cfbrectfill, cfbcopyarea, and cfbimageblit to use. If the driver
> > doesn't provide these functions then we use these cfb* functions. I even
> > stored each function in a seperate file just in case we run into cards
> > that support one or two of the three accelerated functions.
> 
> Wouldn't it be better to let the driver always fill in the pointers, even if it
> needs the cfb* ops?

The reason I was thinking this was just in case we end up with ioctls for
these 3 accel functions. We wouldn't want userland to be able to call them
if they could be done in userland using software emulation.

Re: console spin_lock

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

Andrew Morton writes:
> The subtler problem will be interrupt-capable drivers which
> do a bare spin_lock() to serialise wrt their interrupt routines,
> relying upon interrupts being disabled.  They'll be deadlocky
> and will need changing.  That's trivial to find and fix though.

Uhh, what if you have this situation:

interrupt (level triggered)
 enter interrupt handler
   printk (can re-enable interrupts?)
     enter interrupt handler
       printk (can re-enable interrupts?)
         enter interrupt handler
           printk (can re-enable interrupts?)
             ....

So surely this isn't a new problem?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rm...@ar...      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

Re: inputattach on sa1100

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

> > Okay. We already have one touch screen driver (Gunze AHL-51S) to use as a
> > example. The framebuffer code needs alot of work.
> 
> I might do the touchscreen next - its quite simple I think.

Cool :-)

> I fixed it. It was mostly my stupidity and modules misconfigured...

What did you so maybe it can be put into a FAQ ? 

Re: [linux-fbdev] New api again

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

About this pipeline business :

what if i wanted to write a fbdev for, for example, the 3Dlabs Oxygen GVX420
board ? 

For you information this board contains 3 different chip, A gamma 2 chip,
acting as agp bridge and T&L engine, and 2 Permedia4 chips, doing 3D setup and
rasterization. They can be configuredto be shared for rasterizing the same
framebuffer, splitting the scanline between them, or to support dual head.

Each Pm4 has one pipeline, i think.

The additional problem, is that you can address the rasterizer chip either
directly (they have FB and Command register pci aperture, and a separate pci
id) or trough the Gamma chip, for example, for when doing 3D, you send command
to the gamma, which process them (T&L) and then forward the low level commands
to one or both Permedia4 chip. If you want ot use one or both accesses, you
would need to synchronize correctly between them.

Friendly,

Sven Luther

Re: console spin_lock

[Andrew M. <an...@uo...>]

James Simmons wrote:
> ...
> By you saying couldn't be acquired from interrupt context do you mean
> from a process context or do you mean it failed to aquire it while in
> the interrupt context?

Actually, printk() must always use __down_trylock().

> > - Get rid of console_tasklet.  Do it in process context callback
> >   or just do it synchronously.
> 
> What about multidesktop systems? I have vgacon and mdacon working fine
> along each other. Each one has their own tasklet to allow them to work
> independent of each other. Meaning no race condition when both VC switch
> at the same time.

Ah.  Thanks. That stuff was actually design-from-memory :)  I'll take
a closer look when I have something other than a clockwork computer.
 
> > Assumption:
> > - Once the system is up and running, it's always safe to
> >   call down() when in_interrupt() returns false - probably
> >   not the case in parts of the exit path - tough.
> 
> Don't forget the idle_task case as well. exit path?

This statement of mine was grade-A bollocks.  printk cannot of
course call down().  It needs to use __down_trylock and buffer
it up if it fails. (faster, too!)

The subtler problem will be interrupt-capable drivers which
do a bare spin_lock() to serialise wrt their interrupt routines,
relying upon interrupts being disabled.  They'll be deadlocky
and will need changing.  That's trivial to find and fix though.

Anyway, this was just a heads-up that I'll be looking at
this stuff.  Please allow me a week or so to provide
some substance.  I read that the fbdev developers have
been seeking a fix for this for some time, so it seems
worth some effort.

Re: [linux-fbdev] New api again

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

On Wed, 17 Jan 2001, James Simmons wrote:
>   I never did figure out how Amiga interleaved bitplanes are layed out. How 
> do you fill in one pixel of some color to the display? Once I have that
> figured out I can write a really fast rectfill, copyarea, and imageblit
> for it. 

OK, I'll tell you how the Amiga display hardware works. Amiga always uses
bitplanes (1-8)

  - You have 8 bitplane pointers (bplpt[8]), through which display data is
    fetched (with auto-increment), one for each bitplane.
  - You have 2 bitplane modulo registers (bpl1mod and bpl2mod), which are added
    to the even resp. odd bitplane pointers at the end of each scanline (FYI:
    You have 2 of them to support `dual playfield mode', in which you have 2
    independent playfields formed by the even and odd bitplanes. This is not
    supported by amifb).

This provides quite some flexibility, since you can store individual bitplanes
in memory wherever you want.

For `normal bitplanes' (all bitplanes stored in memory after each other,
handled by `fbcon-afb'), you set:

    bplpt[i] = start+i*(width*height/8);
    bpl1mod = bpl2mod = 0;

For `interleaved bitplanes' (all bitplanes for one scanline are stored after
each other, followed by the bitplanes for the next scanline, and so on), you
set:

    bplpt[i] = start+i*width/8;
    bpl1mod = bpl2mod = width/8*(depth-1);

The advantage of ilbm over afb is that you can copy and clear rectangular areas
using only one blit (= copy of a rectangular area in memory), while for afb you
need as many blits as you have bitplanes, so you need less blitter setup.
Furthermore you see less artefacts during scrolling. The disadvantage is that
XF68_FBDev is quite buggy for ilbm.

It should be possible to merge fbcon-afb and fbcon-ilbm. The only difference is
the value you have to add to go to the next scanline or the next bitplane.

> > > 	fb_pan_display:	xxxfb_pan_display,
> > > 	fb_rectfill:	xxxfb_rectfill,  /* optional */
> > > 	fb_copyarea:	xxxfb_copyarea,  /* optional */
> > > 	fb_imageblit:	xxxfb_imageblit, /* optional */
> > > 	fb_ioctl:       xxxfb_ioctl,     /* optional */
> > > 	fb_mmap:	xxxfb_mmap,      /* optional */	
> > > };
> > 
> > Aren't xxxfb_{rectfill,copyarea,imageblit} mandatory, because fbcon-* will go
> > away?
> 
> Yes but for the standard packed pixel non accelerated graphics cards we
> have cfbrectfill, cfbcopyarea, and cfbimageblit to use. If the driver
> doesn't provide these functions then we use these cfb* functions. I even
> stored each function in a seperate file just in case we run into cards
> that support one or two of the three accelerated functions.

Wouldn't it be better to let the driver always fill in the pointers, even if it
needs the cfb* ops?

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: inputattach on sa1100

[Justin C. <jp...@do...>]

> Okay. We already have one touch screen driver (Gunze AHL-51S) to use as a
> example. The framebuffer code needs alot of work.

I might do the touchscreen next - its quite simple I think.


> > > What is the exact error you are getting? What serial device are you using?
> > > Are they modular or built in?
> > 
> > modular. spaceorb or newtonkbd. I'll do more debugging today and find out whats
> > going on exactly.
> 
> I only have a serial mouse which worked fine. All my joysticks are USB
> and regular joystick port based. I do have a few commodore 64 and atari
> josyticks but those only work if you plug them into the parallel port,
> with a special adapter. Vojtech do you have a serial port based joysticks?

I fixed it. It was mostly my stupidity and modules misconfigured...

Justin

The time has come for me to move on

[Eric S. R. <es...@th...>]

I think it's time for me to resign from co-maintainership of this project.
James Simmons has been doing the heavy lifting; if he's going to have
a partner as project admin, it ought not to be a silent one.

As you may know, I have been inactive for many months now.  We got the
part I was interested in -- cleaning up and refactoring the console's
ANSI emulation -- done almost a year ago.  And the truth is I have almost
no interest in low-level video interface hacking.

Accordingly, I haven't even really kept track of what the project is doing.
The project web page is badly out of date and needs to be revised by
someone closer to the action.

I'm still willing to spend time and expertise on issues relating to the
emulation code.  Possibly also on documentation.
--
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand

Re: console spin_lock

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

> heh.
> 
> I'm actually planning on grabbing console_lock and thoroughly strangling
> it

Ha Ha!!

> - Use a semaphore for serialisation.

I think this would be the best solution as well.

> - For printk in interrupt context, grab the
>   semaphore (yes, you can do this).

Don't forget about the idle task also. How is this done? By reintializing
the semaphore.

> - If it couldn't be acquired from interrupt context,
>   buffer the text in the log buffer and return.  The text will be
>   printed by whoever holds the semaphore before they
>   drop it.

By you saying couldn't be acquired from interrupt context do you mean
from a process context or do you mean it failed to aquire it while in 
the interrupt context?

> - Special "system booting" mode which bypasses all this
>   stuff.

This wouldn't be to hard to do for VTs using the fact that keybaords 
are not initialized right away. As for serial consoles well that is
another story. Of course we could have this flag set/cleared in
start_kernel. 

> - Special "oops in progress" mode which just
>   punches through everything.

You already developed the framework for this.

> - Get rid of the special printk buffer - share the
>   log buffer.  (Implies writes to console
>   devices will be broken into two writes when they
>   wrap around).
> - Teach vsprintf to print into a circular buffer
>   (snprintf thus comes for free).

> - Get rid of all the printk deadlock opportunities (fourth
>   attempt).

Good luck.

> - Get rid of console_tasklet.  Do it in process context callback
>   or just do it synchronously.

What about multidesktop systems? I have vgacon and mdacon working fine 
along each other. Each one has their own tasklet to allow them to work
independent of each other. Meaning no race condition when both VC switch
at the same time.  
 
> Assumption:
> - Once the system is up and running, it's always safe to
>   call down() when in_interrupt() returns false - probably
>   not the case in parts of the exit path - tough.

Don't forget the idle_task case as well. exit path?

Re: inputattach on sa1100

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

> > Arm :-) How does ruby work on it?
> 
> Sorry, doesnt. Yet. :-(

 These are the standard kernel js drivers, but they are
> the same as the ruby ones. There are several input drivers (touchscreen etc)
> to convert to tuby plus the framebuffer code - will work on it gradually.

Okay. We already have one touch screen driver (Gunze AHL-51S) to use as a
example. The framebuffer code needs alot of work.

> > Could the patch been sent are way once you are done?
> 
> oh yes.

Thanks.

> > What is the exact error you are getting? What serial device are you using?
> > Are they modular or built in?
> 
> modular. spaceorb or newtonkbd. I'll do more debugging today and find out whats
> going on exactly.

I only have a serial mouse which worked fine. All my joysticks are USB
and regular joystick port based. I do have a few commodore 64 and atari
josyticks but those only work if you plug them into the parallel port,
with a special adapter. Vojtech do you have a serial port based joysticks?

Re: [linux-fbdev] New api again

[Petr V. <VAN...@vc...>]

On 17 Jan 01 at 12:11, James Simmons wrote:
> Okay. This answered my previous question. It pretty much comes down to
> choosing between xxxfb_setcolreg or xxxfb_set_cmap. Their are pros and
> cons to having each:
>                   
> xxxfb_setcolreg  
> PRO:         can change a individual register without having to monkey
>              with the entire CLUT. 
> 
> CONS:        Hardware designs. Some hardware require vsync when changing
>          the color palette.
> 
> xxxfb_set_cmap
> PRO:         More flexiable with bizarre hardware. Also works nice with 
>          hardware that has more than one CLUT. In this case we can
>          cache a bunch of color maps and switch the index around.      
>                      
> CONS:        Can't change a subset of teh CLUT table easily. 

Adding 'CMAP_FIRST' and 'CMAP_MORE' bits as additional setcolreg
argument? And set CMAP_FIRST for first entry of cmap, and CMAP_MORE
if it is not last entry? So VGA could do:

  if (flags & CMAP_FIRST) {
    outb(reg, 0x3C8);
  }
  outb(red, 0x3C9);
  outb(green, 0x3C9);
  outb(blue, 0x3C9);
  
I have no idea whether someone really needs CMAP_MORE. Maybe if you
must enable legacy VGA I/O region for doing palette changes... Or if
you must switch DAC back to 6bit mode for legacy apps.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...

Re: [linux-fbdev] New api again

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

> On 1/17/01 2:33 AM, Geert Uytterhoeven wrote:
> 
> > On Tue, 16 Jan 2001, Takashi Oe wrote:
> >> Could there be a multiple color version as well?  For 2.4, I have my own
> >> fb_set_cmap to do that since a cmap access requires a synchronization with
> >> vsync for the first one on my machine, and I don't want to do the
> >> synchronization for every cmap change.
> >> 
> [...]
> > Can't you buffer the xxxfb_setcolreg() calls and execute them in the vsync
> > interrupt handler? Busy waiting until vsync is a bad idea.
> 
> Yes, the vsync irq handler is the way it's done currently for one fb.
> Howerver, there is another regrettably more popular fb with the same
> requirement without the vsync irq routed to cpu; that is, the busy waiting
> seems to be the only way....

Okay. This answered my previous question. It pretty much comes down to
choosing between xxxfb_setcolreg or xxxfb_set_cmap. Their are pros and
cons to having each:
                  
xxxfb_setcolreg  
PRO:         can change a individual register without having to monkey
             with the entire CLUT. 

CONS:        Hardware designs. Some hardware require vsync when changing
	     the color palette.

xxxfb_set_cmap
PRO:	     More flexiable with bizarre hardware. Also works nice with 
	     hardware that has more than one CLUT. In this case we can
	     cache a bunch of color maps and switch the index around. 	   
            	     
CONS:        Can't change a subset of teh CLUT table easily. 

Re: [linux-fbdev] New api again

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

> > If there is a way to override fb_set_cmap (or a new api's equivalent)
> > calling setcolreg, that would be okay, too.
> 
> Can't you buffer the xxxfb_setcolreg() calls and execute them in the vsync
> interrupt handler? Busy waiting until vsync is a bad idea.

This is a good idea but what if we run into hardware where you have to
poll a bit for a vbl that requires this :-(  Does such hardware exist?   

> > > info.pseudo_palette = xxxfb_pseudo_palette;
> > 
> > How is this psuedo_palette used for new api?
> 
> I'm wondering as well. Fbcon-* is going away in favor of the `accels', right?

It should be going away. We need a cleaner way to translate from VT
emulated psuedo palette to native color handling.

Re: [linux-fbdev] New api again

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

> > static void xxxfb_set_par(struct fb_info *info)
> > {
> >     /*
> >      *  xxx_fb_check_var tested the mode we want to set the hardware to.
> >      *  If it passes it then is set to info->var. Now we set the hardware
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Who sets this? fbmem.c? Or is there a var argument missing for this function?

From fbmem.c :

int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
    int err, oldbpp;

    if (memcmp(&info->var, var, sizeof(var))) {
        if ((err = info->fbops->fb_check_var(var, info)))
                return err;

        if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
                oldbpp = info->var.bits_per_pixel;
		info->var = *var;
                info->fbops->fb_set_par(info);

                if (oldbpp != var->bits_per_pixel) {
                        if ((err = fb_set_cmap(&info->cmap, 1, info)))
                                return err;
                }
        }
        var->activate = 0;
    }
    return 0;
}

With this generic set_var function we compare the passed in var with the
current var in info. We check if the hardware can handle the mode using
par in info but we don't alter par. Once check_var approves AND we want to
set the video mode we set info->var to the passed in var and then call
set_par. The reason I don't have a par in set_var and pass it to check_var
is because I felt it was a waste to create a new par and then throw it
away if we just want to check the video mode. Also par could be a array
of data structures representing different hardware states the graphics
card could be in. The bonus is for fb_find_mode we can just call
fbops->fb_check_var directly.   

> I think it's still safer to use one function for both testing and setting,
> since for multi-headed cards both heads depend on each other:
> 
>     check_and_test(var, info, test_only)
>     {
> 	get_lock() /* multi-headed cards only */
> 	... do test ...
> 
> 	if (test_only) {
> 	    release_lock() /* multi-headed cards only */
> 	    return;
> 	}
> 
> 	... do set ...
> 	release_lock() /* multi-headed cards only */
>     }

This is fb_set_var in a nutshell minus the locking which we need. In the
case of multi-head cards we have more than one fb_info but have one par
which is shared between them. If one attempts to change it resolution we
can used the values in par to see if it is possible. The one thing we have
to be extra careful with is if two processes try to change both
resolutions on each display at the same time. The other question is what
to do in the following situation:

display A in mode a  display B in mode b
       VC switch
display A in mode c  
                     display B in mode d  
                       

When we change to mode c it is acceptable to mode b but not to mode d. 
Do we disallow the VT switch?

> > void xxxfb_imageblit(struct fb_info *p, unsigned int width,
> >                      unsigned int height, unsigned long *image,
> >                      int image_depth, int dx, int dy)
> > {
> > }
> 
> I still like to have the possibility to blit an array of images, for drawing
> multiple characters (fbcon_putcs()). Drawing individual characters is too slow
> on some hardware (e.g. Amiga bitplanes: each 8-pixel wide character needs to
> access 1 byte in each plane, while drawing 4 (AGA, 32-bit wide bus) or 2 (ECS,
> 16-bit wide bus) characters needs the same number of memory accesses.

I agree. fbcon_putcs would have to be smart in how to construct a image to
pass to the blit function.  The blit function can take in any size image. 
That is why the width and height fields. If done right you can draw huge
images to the display in very short time. For the generic packed pixel
case I word align the data and then transfer unsigned long size data at a
time to the graphics card. On a 32 bit machine in 8 bpp then means 4
pixels are drawn in one cycle. I'm sure we can do the same thing for Amiga
interleaved bitplanes. I also figured out really fast really fast
rectfill and copyarea for ilbm. Since each plane is a 0 or 1 at position X
in the pixel and each plane comes afetr each other in video memory we can
for each plane work with a bunch of 0s or just a bunch of 1s.

P.S
  I never did figure out how Amiga interleaved bitplanes are layed out. How 
do you fill in one pixel of some color to the display? Once I have that
figured out I can write a really fast rectfill, copyarea, and imageblit
for it. 

> >     /* This should give a reasonable default video mode */
> >     if (!mode_option)
> > 	mode_option = "640x480@60";	 	
> 
> Not needed. fb_find_mode() will do this automagically if mode_option is NULL.

Okay. Updated. 

> > 	fb_pan_display:	xxxfb_pan_display,
> > 	fb_rectfill:	xxxfb_rectfill,  /* optional */
> > 	fb_copyarea:	xxxfb_copyarea,  /* optional */
> > 	fb_imageblit:	xxxfb_imageblit, /* optional */
> > 	fb_ioctl:       xxxfb_ioctl,     /* optional */
> > 	fb_mmap:	xxxfb_mmap,      /* optional */	
> > };
> 
> Aren't xxxfb_{rectfill,copyarea,imageblit} mandatory, because fbcon-* will go
> away?

Yes but for the standard packed pixel non accelerated graphics cards we
have cfbrectfill, cfbcopyarea, and cfbimageblit to use. If the driver
doesn't provide these functions then we use these cfb* functions. I even
stored each function in a seperate file just in case we run into cards
that support one or two of the three accelerated functions.

Re: console spin_lock

[Roman Z. <zi...@fh...>]

Hi,

On Thu, 18 Jan 2001, Andrew Morton wrote:

> - Get rid of the special printk buffer - share the
>   log buffer.  (Implies writes to console
>   devices will be broken into two writes when they
>   wrap around).
> - Teach vsprintf to print into a circular buffer
>   (snprintf thus comes for free).

I have a different vsprintf variant - vpprintf(). It takes a function and
a data pointer, this function is called with the print buffer and within
that function you can take care of the locking. The only problem is that
%n doesn't work anymore, but it's not used anyway in the kernel (as far as
I can grep :) ).

bye, Roman

Re: [linux-fbdev] New api again

[Takashi Oe <to...@un...>]

On 1/17/01 2:33 AM, Geert Uytterhoeven wrote:

> On Tue, 16 Jan 2001, Takashi Oe wrote:
>> Could there be a multiple color version as well?  For 2.4, I have my own
>> fb_set_cmap to do that since a cmap access requires a synchronization with
>> vsync for the first one on my machine, and I don't want to do the
>> synchronization for every cmap change.
>> 
[...]
> Can't you buffer the xxxfb_setcolreg() calls and execute them in the vsync
> interrupt handler? Busy waiting until vsync is a bad idea.

Yes, the vsync irq handler is the way it's done currently for one fb.
Howerver, there is another regrettably more popular fb with the same
requirement without the vsync irq routed to cpu; that is, the busy waiting
seems to be the only way....


Takashi Oe

Re: console spin_lock

[Andrew M. <an...@uo...>]

James Simmons wrote:
> 
> Some time ago a intel i810 framebuffer driver was written. It only worked
> for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
> console system. Sooner or later we are going to run into the situtation
> where we will have graphics hardware which has no vga core and wih be
> purely DMA/irq based (i.e i810). In this case using the current
> console_lock will block the driver itself. I have thought about a
> possible solution. A semaphore can't be used since their is a spin_lock
> in the console_softirq. Since this is in a interrupt context a
> semaphore can't be used. Another idea was to do a
> 
> void get_vc_lock(void)
> {
>         while (test_and_set_bit(0, &vc_var))
>                 ;
> }
> 
> Any better ideas?
> 

heh.

I'm actually planning on grabbing console_lock and thoroughly strangling
it
next week.  It can block interrupts for up to a second. That just isn't
civil.

- Use a semaphore for serialisation.
- For printk in interrupt context, grab the
  semaphore (yes, you can do this).
- If it couldn't be acquired from interrupt context,
  buffer the text in the log buffer and return.  The text will be
  printed by whoever holds the semaphore before they
  drop it.
- Special "system booting" mode which bypasses all this
  stuff.
- Special "oops in progress" mode which just
  punches through everything.
- Get rid of the special printk buffer - share the
  log buffer.  (Implies writes to console
  devices will be broken into two writes when they
  wrap around).
- Teach vsprintf to print into a circular buffer
  (snprintf thus comes for free).
- Get rid of all the printk deadlock opportunities (fourth
  attempt).
- Get rid of console_tasklet.  Do it in process context callback
  or just do it synchronously.

Assumption:
- Once the system is up and running, it's always safe to
  call down() when in_interrupt() returns false - probably
  not the case in parts of the exit path - tough.


Anyway, that's the thoughtware.  Sound sane?

-

Re: inputattach on sa1100

[Justin C. <jp...@do...>]

> 
> 
> On Tue, 16 Jan 2001, Justin Cormack wrote:
> 
> > Trying to get the input drivers working on Arm (sa1100), and having
> > problems with inputattach. 
> 
> Arm :-) How does ruby work on it?

Sorry, doesnt. Yet. These are the standard kernel js drivers, but they are
the same as the ruby ones. There are several input drivers (touchscreen etc)
to convert to tuby plus the framebuffer code - will work on it gradually.

> > First is that it isnt dropping RTS to reset
> > the devices. Someone else is working on that - it doesnt matter for all
> > devices anyway. 
> 
> Could the patch been sent are way once you are done?

oh yes.

> > However I am getting a failure in
> > 
> >         devt = SERIO_RS232 | input_types[type].type | (input_types[type].extra << 16);
> > 
> >         if(ioctl(fd, SPIOCSTYPE, &devt)) {
> >                 fprintf(stderr, "inputattach: can't set device type\n");
> >                 return 1;
> >         }
> 
> What is the exact error you are getting? What serial device are you using?
> Are they modular or built in?

modular. spaceorb or newtonkbd. I'll do more debugging today and find out whats
going on exactly.

Justin

Re: [linux-fbdev] New api again

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

On Tue, 16 Jan 2001, James Simmons wrote:
> > How is this psuedo_palette used for new api?
> 
> It is actually for the higher up fbcon layer. Traditional VTs only had
> psuedocolor modes so we have to fake it for video modes that don't have 
> color maps. We can do things like:
> 
> bgx = ((u16 *)p->dispsw_data)[attr_bgcol_ec(p, conp)];
                ^^^^^^^^^^^^^^
		info->pseudo_palette
> 
> Personally I hate it and wish their was another way around this.

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] New api again

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

On Tue, 16 Jan 2001, Takashi Oe wrote:
> On 1/16/01 1:23 PM, James Simmons wrote:
> > Since 2.4 is now out and the new console system is becoming stable its
> > time to discuss the new api for fbcon again. I updated skeletonfb for a
> > example and posted here. Feel free to addd input to the design.
> 
> [...]
> > /*
> > *  Set a single color register. The values supplied have a 16 bit
> > *  magnitude. Return != 0 for invalid regno. This routine assumes
> > *  your graphics hardware is packed pixel based (most are :-).
> > *  Return != 0 for invalid regno.
> > */
> > static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
> > unsigned blue, unsigned transp,
> > const struct fb_info *info)
> 
> Could there be a multiple color version as well?  For 2.4, I have my own
> fb_set_cmap to do that since a cmap access requires a synchronization with
> vsync for the first one on my machine, and I don't want to do the
> synchronization for every cmap change.
> 
> Want to do:
> - vsync
> - multiple cmap change
> rather than:
> - vsync
> - a cmap change
> - vsync
> - a cmap change
> - ....
> 
> If there is a way to override fb_set_cmap (or a new api's equivalent)
> calling setcolreg, that would be okay, too.

Can't you buffer the xxxfb_setcolreg() calls and execute them in the vsync
interrupt handler? Busy waiting until vsync is a bad idea.

> > info.pseudo_palette = xxxfb_pseudo_palette;
> 
> How is this psuedo_palette used for new api?

I'm wondering as well. Fbcon-* is going away in favor of the `accels', right?

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] New api again

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

On Tue, 16 Jan 2001, James Simmons wrote:
>     Since 2.4 is now out and the new console system is becoming stable its
> time to discuss the new api for fbcon again. I updated skeletonfb for a
> example and posted here. Feel free to addd input to the design.
> 
> /*
>  * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
>  *
>  *  Modified to new api Jan 2001 by James Simmons (jsi...@li...)
>  *
>  *  Created 28 Dec 1997 by Geert Uytterhoeven
>  *
>  * This file is subject to the terms and conditions of the GNU General Public
>  * License.  See the file COPYING in the main directory of this archive
>  * for more details.
>  */
> 
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> #include <linux/string.h>
> #include <linux/mm.h>
> #include <linux/tty.h>
> #include <linux/malloc.h>
> #include <linux/delay.h>
> #include <linux/fb.h>
> #include <linux/init.h>
> 
> /* This header contains struct xxx_par for your graphics card */
> #include <video/skeletion.h>
> 
>     /*
>      *  This is just simple sample code.
>      *
>      *  No warranty that it actually compiles.
>      *  Even less warranty that it actually works :-)
>      */
> 
> static struct fb_fix_screeninfo xxxfb_fix __initdata = {
>     "FB's name", (unsigned long) NULL, 0, FB_TYPE_PACKED_PIXELS, 0,
>     FB_VISUAL_PSEUDOCOLOR, 1, 1, 1, 0, (unsigned long) NULL, 0, FB_ACCEL_NONE
> };
> 
>     /*
>      * 	Modern graphical hardware not only supports pipelines but some 
>      *  also support multiple monitors where each display can have its  
>      *  its own unique data. In this case each display could be  
>      *  represented by a seperate framebuffer device thus a seperate 
>      *  struct fb_info. In this case all of the par structures for the
>      *  graphics card would be shared between each struct fb_info. This
>      *  allows when one display changes it video resolution (info->var) 
>      *  the other displays know instantly. Each display can always be
>      *  aware of the entire hardware state that affects it. I hope this 
>      *  covers every possible hardware design. If not feel free to send 
>      *  me more design types. 
>      */
> 
>     /*
>      *  If your driver supports multiple boards, you should make these  
>      *  arrays, or allocate them dynamically (using kmalloc()). 
>      */ 
> static struct fb_info info;
>     /* 
>      * This struct represents the state of a rendering pipe. A modern 
>      * graphics card can have more than one pipe per card depending 
>      * on the hardware design. So the same holds true if you have
>      * multiple pipes. Use arrays or allocate them dynamically.
>      *
>      * Read video/skeleton.h for more information about graphics pipes. 
>      */
> static struct xxx_par __initdata current_par;
> 
> static u32 xxxfb_pseudo_palette[17];
> static int inverse = 0;
> 
> int xxxfb_init(void);
> int xxxfb_setup(char*);
> 
> /* ------------------- chipset specific functions -------------------------- */
> 
> static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
> {
>     const struct xxx_par *par = (const struct xxx_par *) info->par;
>     /* 
>      * We test to see if the hardware can support var. Struct xxx_par will
>      * have the information needed to see if it does. Note we don't change
>      * par nor info->var. This function can be called on its own if we
>      * intent to only test a mode and not set it. Return 0 if it is a
>      * acceptable mode.
>      */
> 
>     /* ... */
>     return 0;	   	
> }
> 
> static void xxxfb_set_par(struct fb_info *info)
> {
>     /*
>      *  xxx_fb_check_var tested the mode we want to set the hardware to.
>      *  If it passes it then is set to info->var. Now we set the hardware
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Who sets this? fbmem.c? Or is there a var argument missing for this function?

>      *  (and struct par) according to info->var.
>      */
> 
>     /* ... */
> }

I think it's still safer to use one function for both testing and setting,
since for multi-headed cards both heads depend on each other:

    check_and_test(var, info, test_only)
    {
	get_lock() /* multi-headed cards only */
	... do test ...

	if (test_only) {
	    release_lock() /* multi-headed cards only */
	    return;
	}

	... do set ...
	release_lock() /* multi-headed cards only */
    }

> void xxxfb_imageblit(struct fb_info *p, unsigned int width,
>                      unsigned int height, unsigned long *image,
>                      int image_depth, int dx, int dy)
> {
> }

I still like to have the possibility to blit an array of images, for drawing
multiple characters (fbcon_putcs()). Drawing individual characters is too slow
on some hardware (e.g. Amiga bitplanes: each 8-pixel wide character needs to
access 1 byte in each plane, while drawing 4 (AGA, 32-bit wide bus) or 2 (ECS,
16-bit wide bus) characters needs the same number of memory accesses.

>     /* This should give a reasonable default video mode */
>     if (!mode_option)
> 	mode_option = "640x480@60";	 	

Not needed. fb_find_mode() will do this automagically if mode_option is NULL.

> static struct fb_ops xxxfb_ops = {
> 	owner:		THIS_MODULE,
> 	fb_open:	xxxfb_open,    /* only if you need it to do something */
> 	fb_release:	xxxfb_release, /* only if you need it to do something */
> 	fb_check_var:	xxxfb_check_var,
> 	fb_set_par:	xxxfb_set_par,
> 	fb_setcolreg:	xxxfb_setcolreg,
> 	fb_blank:	xxxfb_blank,
> 	fb_pan_display:	xxxfb_pan_display,
> 	fb_rectfill:	xxxfb_rectfill,  /* optional */
> 	fb_copyarea:	xxxfb_copyarea,  /* optional */
> 	fb_imageblit:	xxxfb_imageblit, /* optional */
> 	fb_ioctl:       xxxfb_ioctl,     /* optional */
> 	fb_mmap:	xxxfb_mmap,      /* optional */	
> };

Aren't xxxfb_{rectfill,copyarea,imageblit} mandatory, because fbcon-* will go
away?

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

console spin_lock

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

Some time ago a intel i810 framebuffer driver was written. It only worked
for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
console system. Sooner or later we are going to run into the situtation
where we will have graphics hardware which has no vga core and wih be
purely DMA/irq based (i.e i810). In this case using the current
console_lock will block the driver itself. I have thought about a
possible solution. A semaphore can't be used since their is a spin_lock 
in the console_softirq. Since this is in a interrupt context a
semaphore can't be used. Another idea was to do a 

void get_vc_lock(void)
{
        while (test_and_set_bit(0, &vc_var))
                ;
}

Any better ideas?

Re: inputattach on sa1100

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

On Tue, 16 Jan 2001, Justin Cormack wrote:

> Trying to get the input drivers working on Arm (sa1100), and having
> problems with inputattach. 

Arm :-) How does ruby work on it?

> First is that it isnt dropping RTS to reset
> the devices. Someone else is working on that - it doesnt matter for all
> devices anyway. 

Could the patch been sent are way once you are done?

> However I am getting a failure in
> 
>         devt = SERIO_RS232 | input_types[type].type | (input_types[type].extra << 16);
> 
>         if(ioctl(fd, SPIOCSTYPE, &devt)) {
>                 fprintf(stderr, "inputattach: can't set device type\n");
>                 return 1;
>         }

What is the exact error you are getting? What serial device are you using?
Are they modular or built in?
 

Re: [linux-fbdev] New api again

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

> > /*
> > *  Set a single color register. The values supplied have a 16 bit
> > *  magnitude. Return != 0 for invalid regno. This routine assumes
> > *  your graphics hardware is packed pixel based (most are :-).
> > *  Return != 0 for invalid regno.
> > */
> > static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
> > unsigned blue, unsigned transp,
> > const struct fb_info *info)
> 
> Could there be a multiple color version as well?  For 2.4, I have my own
> fb_set_cmap to do that since a cmap access requires a synchronization with
> vsync for the first one on my machine, and I don't want to do the
> synchronization for every cmap change.
> 
> Want to do:
> - vsync
> - multiple cmap change
> rather than:
> - vsync
> - a cmap change
> - vsync
> - a cmap change
> - ....
>
> If there is a way to override fb_set_cmap (or a new api's equilvalent)
> calling setcolreg, that would be okay, too.

Hum. I would prefere a setcolreg solution more. fb_set_cmap in fbcmap.c is
more for grabbing the info from userland then setting the hardware.

> [...]
> > info.pseudo_palette = xxxfb_pseudo_palette;
> 
> How is this psuedo_palette used for new api?

It is actually for the higher up fbcon layer. Traditional VTs only had
psuedocolor modes so we have to fake it for video modes that don't have 
color maps. We can do things like:

bgx = ((u16 *)p->dispsw_data)[attr_bgcol_ec(p, conp)];

Personally I hate it and wish their was another way around this.