[PATCH] fbdev updates.

[PATCH] fbdev updates.

[James Simmons]

Here are the latest updates to the framebuffer layer. Please test it outso
I can push it as soon as possible to Linus. Here is what has changes. The
* are tested drivers. As a note there are a few issues with a few of the
drivers but time is running out so I need to push the changes then fix any
remaining bugs. Links to the chnages are:

BK:            http://www.fbdev.bkbits.net/fbdev-2.5

diff:		http://www.transvirtual.com/~jsimmons/fbdev.diff.gz


P.S
       Note I removed the old fbgen stuff so some drivers are going to
break. Well with time running out I need to push ahead. Sorry but I have
to choose.


 Documentation/fb/README-sstfb.txt     |   87
 arch/i386/boot/video.S                |    4    *
 arch/ppc/Config.help                  |    6
 arch/ppc/config.in                    |    3
 drivers/char/vt.c                     |   66    *
 drivers/video/Config.help             |   22    *
 drivers/video/Config.in               |   80    *
 drivers/video/Makefile                |   15    *
 drivers/video/S3triofb.c              |   19
 drivers/video/acornfb.c               |    3
 drivers/video/amifb.c                 |   81
 drivers/video/atafb.c                 |  376 ++-
 drivers/video/aty/atyfb.h             |   18               *
 drivers/video/aty/atyfb_base.c        |  348 +--           *
 drivers/video/aty/mach64.h            | 1158 ------------  *
 drivers/video/aty/mach64_accel.c      |    2               *
 drivers/video/aty/mach64_ct.c         |    4 		    *
 drivers/video/aty/mach64_cursor.c     |   12               *
 drivers/video/aty/mach64_gx.c         |    2 		    *
 drivers/video/aty128.h                |  352 ---	    *
 drivers/video/aty128fb.c              | 3272
++++++++++++++-------------------- *
 drivers/video/chipsfb.c               |   29
 drivers/video/controlfb.c             |   21
 drivers/video/dnfb.c                  |   19
 drivers/video/fbcon-mac.c             |  483 -----
 drivers/video/fbcon-vga.c             |  213 --
 drivers/video/fbcon.c                 |    2                	*
 drivers/video/fbgen.c                 |  347 ---		*
 drivers/video/fbmem.c                 |    2 			*
 drivers/video/fm2fb.c                 |    3
 drivers/video/fonts.c                 |    4
 drivers/video/hpfb.c                  |    3
 drivers/video/imsttfb.c               |   56
 drivers/video/macfb.c                 |  463 +---
 drivers/video/macmodes.c              |  171 -
 drivers/video/matrox/matroxfb_base.c  |   43
 drivers/video/matrox/matroxfb_base.h  |    6
 drivers/video/matrox/matroxfb_crtc2.c |   19
 drivers/video/modedb.c                |    4
 drivers/video/neofb.c                 |    7 			*
 drivers/video/offb.c                  | 1130 ++++-------
 drivers/video/platinumfb.c            |   26
 drivers/video/q40fb.c                 |    8
 drivers/video/retz3fb.c               |    4
 drivers/video/riva/Makefile           |    2 			*
 drivers/video/riva/accel.c            |  427 ----		*
 drivers/video/riva/fbdev.c            | 1531 ++++++---------	*
 drivers/video/riva/riva_hw.c          |   38 			*
 drivers/video/riva/riva_hw.h          |    2 			*
 drivers/video/riva/rivafb.h           |   60 			*
 drivers/video/sa1100fb.c              |  813 ++------		*
 drivers/video/sa1100fb.h              |   17 			*
 drivers/video/sgivwfb.c               | 1432 ++++++--------
 drivers/video/sgivwfb.h               |  660 ------
 drivers/video/sstfb.c                 |  958 +++++----
 drivers/video/sstfb.h                 |   73
 drivers/video/tdfxfb.c                |   55 			*
 drivers/video/tx3912fb.c              |    2
 drivers/video/valkyriefb.c            |   26
 drivers/video/vesafb.c                |   12 			*
 drivers/video/vfb.c                   |    4
 include/asm-ppc/vc_ioctl.h            |   46
 include/asm-ppc64/vc_ioctl.h          |   50
 include/linux/fb.h                    |   52
 include/linux/pci_ids.h               |    1
 include/linux/tty.h                   |    3
 include/video/aty128.h                |  419 ++++
 include/video/mach64.h                | 1158 ++++++++++++
 include/video/sgivw.h                 |  660 ++++++
 70 files changed, 6886 insertions(+), 10608 deletions(-)

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[Jani Monoses]

On Mon, 1 Jul 2002 10:48:41 -0700 (PDT)
James Simmons <jsimmons@transvirtual.com> wrote:

> P.S
>        Note I removed the old fbgen stuff so some drivers are going to
> break. Well with time running out I need to push ahead. Sorry but I have
> to choose.

That's OK as long as we know that the drivers which are converted are 100% converted
and can be taken as an example.I prefer this approach instead of having to figure out
which incremental step towards the new api conversion was last taken and try to follow it.
So break the drivers and whatever else it takes so more people can confidently go on
and finally port their drivers.

Jani.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[James Simmons]

> That's OK as long as we know that the drivers which are converted are 100%
> converted and can be taken as an example.

Okay. I will push the changes tomorrow. Take a look at skeletonfb.c for
info :-0



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[Russell King]

On Mon, Jul 01, 2002 at 10:48:41AM -0700, James Simmons wrote:
> Here are the latest updates to the framebuffer layer. Please test it outso
> I can push it as soon as possible to Linus.

The following comments are from a first review of sa1100fb.[ch] changes.

1. It would appear to break sa1100 inverse colourmap stuff.  There are LCD
   panels out there where it is a rather fundamental requirement to write
   the palette with "inverted" colourmap values.

2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
   looks like noise to me.

3. I think you replaced "fbi" too many times:
	+/* Fake monspecs to fill in infonfo structure */

4. You're also merging in cpufreq changes from my tree in this patch;
   however I was going to send these to Linus along with the cpufreq
   submission so no problem.

5. I strongly disagree with your apparant decision to make the cpufreq
   part of the generic framebuffer core (by apparantly adding the notifier
   block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
   by not including the relevant definition in fb_info (ok, so cpufreq
   stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
   framebuffers require; its only required on SoC devices where the hardware
   designers have been stingy.  As such, we should NOT penalise the x86
   people by adding random useless garbage to structures that they're never
   going to use.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[James Simmons]

> 1. It would appear to break sa1100 inverse colourmap stuff.  There are LCD
>    panels out there where it is a rather fundamental requirement to write
>    the palette with "inverted" colourmap values.

Okay. Fixed.

> 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
>    looks like noise to me.

Ah the idea of a par and using generic struct fb_info. A few reasons. One
I noticed people having fields inside their struct xxxfb_info that was
already there in the generic struct fb_info. By making a strick rule I
hope to avoid that ugly mess. The second reason is eventually I like to
combine DRI and the fbdev layer. This was both interfaces could use the
same struct xxx_par. That is a 2.7 thing but I like to prepare now for
this. For the SA1100 this is not really needed but I still like to enforce
this rule and we still can take advantage of the nice generic functions in
fbgen.c.

> 3. I think you replaced "fbi" too many times:
> 	+/* Fake monspecs to fill in infonfo structure */

Fixed.

> 4. You're also merging in cpufreq changes from my tree in this patch;
>    however I was going to send these to Linus along with the cpufreq
>    submission so no problem.

Just what was in sa1100fb.c. I grabbed that version of the driver from
your tree sinc ethe stuff in Linus tree didn't compile at the time.

> 5. I strongly disagree with your apparant decision to make the cpufreq
>    part of the generic framebuffer core (by apparantly adding the notifier
>    block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
>    by not including the relevant definition in fb_info (ok, so cpufreq
>    stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
>    framebuffers require; its only required on SoC devices where the hardware
>    designers have been stingy.  As such, we should NOT penalise the x86
>    people by adding random useless garbage to structures that they're never
>    going to use.

I completely agree. I'm going to remove that. Originally I thought about
making it generic for everyone because I have seen other platforms
(Mips Au1000 with Epson 1385 framebuffers) do something similar. Then I
realized not everyone needs it and also it is possible that devices with
more than one framebuffer might use the same pixclock frequency. Dumb but
I have seen alot of cards share the accel engine and/or CRTC registers
between two different framebuffers on the same piece of hardware. So it
belongs in par.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[Russell King]

On Thu, Jul 04, 2002 at 09:05:40PM -0700, James Simmons wrote:
> > 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
> >    looks like noise to me.
> 
> Ah the idea of a par and using generic struct fb_info. A few reasons. One
> I noticed people having fields inside their struct xxxfb_info that was
> already there in the generic struct fb_info. By making a strick rule I
> hope to avoid that ugly mess. The second reason is eventually I like to
> combine DRI and the fbdev layer. This was both interfaces could use the
> same struct xxx_par. That is a 2.7 thing but I like to prepare now for
> this. For the SA1100 this is not really needed but I still like to enforce
> this rule and we still can take advantage of the nice generic functions in
> fbgen.c.

First, I detest the idea of "fix", "var", "par" and "info".  Specifically
the "par" crap.  Intensely.  "par" and "info" should be combined IMO,
which my framebuffer drivers do.

Secondly, I think you're completely confused above.  lccr0 and lccr3 have
nothing to do with some "generic struct fb_info".  They hold the base
register values for two of the SA1100 control registers.

Thirdly, you didn't delete them.  You _moved_ them within the structure.
They therefore served zero functional purpose.

Fourthly, nothing but the sa1100fb driver has any business accessing the
elements around these two both before and after the move.

In total, the change serves ZERO purpose and is therefore noise.

> > 5. I strongly disagree with your apparant decision to make the cpufreq
> >    part of the generic framebuffer core (by apparantly adding the notifier
> >    block to the core fb_info structure).  Firstly, you've broken sa1100fb.c
> >    by not including the relevant definition in fb_info (ok, so cpufreq
> >    stuff isn't in Linus' tree yet).  Secondly, it isn't something that all
> >    framebuffers require; its only required on SoC devices where the hardware
> >    designers have been stingy.  As such, we should NOT penalise the x86
> >    people by adding random useless garbage to structures that they're never
> >    going to use.
> 
> I completely agree. I'm going to remove that. Originally I thought about
> making it generic for everyone because I have seen other platforms
> (Mips Au1000 with Epson 1385 framebuffers) do something similar. Then I
> realized not everyone needs it and also it is possible that devices with
> more than one framebuffer might use the same pixclock frequency.

Ehh?  That's got nothing to do with cpufreq.  The reason we have the
cpufreq interface in sa1100fb is that the base clock rate for the LCD
controller on this chip is derived from the CPU core clock.  You change
the core clock, you have to reprogram the pixel clock divisor.

> Dumb but
> I have seen alot of cards share the accel engine and/or CRTC registers
> between two different framebuffers on the same piece of hardware. So it
> belongs in par.

Again, I think this is another misplaced reason; that's irrelevant to
cpufreq.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Geert Uytterhoeven]

On Fri, 5 Jul 2002, Russell King wrote:
> On Thu, Jul 04, 2002 at 09:05:40PM -0700, James Simmons wrote:
> > > 2. I've no idea why you moved "lccr0" and "lccr3" in sa1100fb.h - this
> > >    looks like noise to me.
> > 
> > Ah the idea of a par and using generic struct fb_info. A few reasons. One
> > I noticed people having fields inside their struct xxxfb_info that was
> > already there in the generic struct fb_info. By making a strick rule I
> > hope to avoid that ugly mess. The second reason is eventually I like to
> > combine DRI and the fbdev layer. This was both interfaces could use the
> > same struct xxx_par. That is a 2.7 thing but I like to prepare now for
> > this. For the SA1100 this is not really needed but I still like to enforce
> > this rule and we still can take advantage of the nice generic functions in
> > fbgen.c.
> 
> First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> the "par" crap.  Intensely.  "par" and "info" should be combined IMO,
> which my framebuffer drivers do.

If you have an `asymmetric' dual-head chipset (both heads are not independent,
and/or have different capabilities), you'll have 2 info structures, with one
shared par. So info and par cannot be combined.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> If you have an `asymmetric' dual-head chipset (both heads are not independent,
> and/or have different capabilities), you'll have 2 info structures, with one
> shared par. So info and par cannot be combined.

That may be true for such systems.  I don't believe in imposing such
restrictions on drivers that can _never ever_ fall into that category.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Geert Uytterhoeven]

On Fri, 5 Jul 2002, Russell King wrote:
> On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > and/or have different capabilities), you'll have 2 info structures, with one
> > shared par. So info and par cannot be combined.
> 
> That may be true for such systems.  I don't believe in imposing such
> restrictions on drivers that can _never ever_ fall into that category.

Then just store your par in your info.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 11:39:24AM +0200, Geert Uytterhoeven wrote:
> On Fri, 5 Jul 2002, Russell King wrote:
> > On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > > and/or have different capabilities), you'll have 2 info structures, with one
> > > shared par. So info and par cannot be combined.
> > 
> > That may be true for such systems.  I don't believe in imposing such
> > restrictions on drivers that can _never ever_ fall into that category.
> 
> Then just store your par in your info.

Err, that's what I _am_ doing.  However, James has converted my info to
a par and reordered some elements without any reason.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> > > That may be true for such systems.  I don't believe in imposing such
> > > restrictions on drivers that can _never ever_ fall into that category.
> >
> > Then just store your par in your info.
>
> Err, that's what I _am_ doing.  However, James has converted my info to
> a par and reordered some elements without any reason.

Read my other email. Lets see the reason. Modularity of the subsystem.
Code reduction.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > and/or have different capabilities), you'll have 2 info structures, with one
> > shared par. So info and par cannot be combined.
>
> That may be true for such systems.  I don't believe in imposing such
> restrictions on drivers that can _never ever_ fall into that category.

Imposing a standard set of rules to a subsystem. What insane person would
ever do that?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 10:16:28AM -0700, James Simmons wrote:
> > On Fri, Jul 05, 2002 at 10:53:35AM +0200, Geert Uytterhoeven wrote:
> > > If you have an `asymmetric' dual-head chipset (both heads are not independent,
> > > and/or have different capabilities), you'll have 2 info structures, with one
> > > shared par. So info and par cannot be combined.
> >
> > That may be true for such systems.  I don't believe in imposing such
> > restrictions on drivers that can _never ever_ fall into that category.
> 
> Imposing a standard set of rules to a subsystem. What insane person would
> ever do that?

Imposing a set of useless features on hardware that can not support it
by design.  Yes, that's sensible, oh yes.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> > Imposing a standard set of rules to a subsystem. What insane person would
> > ever do that?
>
> Imposing a set of useless features on hardware that can not support it
> by design.  Yes, that's sensible, oh yes.

All I'm trying to do is seperate hardware independent data from hardware
dependent data.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 11:21:16AM -0700, James Simmons wrote:
> > > Imposing a standard set of rules to a subsystem. What insane person would
> > > ever do that?
> >
> > Imposing a set of useless features on hardware that can not support it
> > by design.  Yes, that's sensible, oh yes.
> 
> All I'm trying to do is seperate hardware independent data from hardware
> dependent data.

Shrug.  I've decided I no longer care.  There is very little common data
in sa1100fb_info.  In fact, from my point of view as the previous driver
maintainer, I'd say that all the data within sa1100fb_info is hardware
dependent, with the exception of the fb_info at the start, which is
placed there to provide a convienent and FAST way to get at the data.

However, since you've decided you know better, I leave this driver
completely in your hands to fuck up.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[James Simmons]

> First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> the "par" crap. Intensely.

   Why? Should each driver have their own structs that are completely
different then? In this case you would be better off doing something like
newport_con.c.

    We pretty much have this today. Each driver has so much excess code
because they want to create their own special structs. Lost of bloat for
no reason! I will NOT put up with that anymore!!!! Sorry!

> "par" and "info" should be combined IMO,
> which my framebuffer drivers do.

No!!!! This is one of the reasons we have the mess we have!! Look at how
much code that could be removed from the standard drivers into fbmem.c and
fbcon.c.

We should have
					 focus on
struct vc_data    struct fb_info         struct xxx_par

[ fbcon.c]        [ fbmem.c]             [ fbdev driver ]

This makes for a nice modular system. It allows for fbdev to exist without
fbcon. Ideally fbmem could even be modular. Insmod the core driver.
Insmod fbmem.o and you have the fbdev interface. You could then rmmod
fbmem.o and do dri.o. Now with the same core driver you have the DRI
interface. Or you could do both drivers at the same time. Eventually I
will combine both interfaces but that will take some time.

> Secondly, I think you're completely confused above.  lccr0 and lccr3 have
> nothing to do with some "generic struct fb_info".  They hold the base
> register values for two of the SA1100 control registers.
>
> Thirdly, you didn't delete them.  You _moved_ them within the structure.
> They therefore served zero functional purpose.

If you could send me a patch I would be happy.

> Fourthly, nothing but the sa1100fb driver has any business accessing the
> elements around these two both before and after the move.

True which is why things like that go into par.

> Ehh?  That's got nothing to do with cpufreq.  The reason we have the
> cpufreq interface in sa1100fb is that the base clock rate for the LCD
> controller on this chip is derived from the CPU core clock.  You change
> the core clock, you have to reprogram the pixel clock divisor.

Other devices besides the SA1100 does this as well. I knew this and this
reason lead me to originally place it into struct fb_info. Later I
realized it was a bad idea.





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 10:14:12AM -0700, James Simmons wrote:
> > First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> > the "par" crap. Intensely.
> 
>    Why? Should each driver have their own structs that are completely
> different then? In this case you would be better off doing something like
> newport_con.c.
> 
>     We pretty much have this today. Each driver has so much excess code
> because they want to create their own special structs. Lost of bloat for
> no reason! I will NOT put up with that anymore!!!! Sorry!

James, you're OTT here.  Look at what the structure contains.  You will
notice that it's very specific to the driver.  Drivers have the implicit
right to define what data they need to maintain their internal state;
the core has no right to define that.

If you're going to be this hard headed about this, YOU can take over
complete maintainence of ALL framebuffer drivers.  I'll direct ALL
problems to you to solve.

It's part of the deal.  Either you allow driver writers to cleanly code
the way they see fit, or you take over maintainence of those drivers.
You break it, you fix it.  What's it to be?

> > "par" and "info" should be combined IMO,
> > which my framebuffer drivers do.
> 
> No!!!! This is one of the reasons we have the mess we have!! Look at how
> much code that could be removed from the standard drivers into fbmem.c and
> fbcon.c.

sa1100fb was already cleaned up in the way YOU wanted to remove most of
the junk back in the 2.4 days.  I consider it to be extremely clean.  Or
used to be.  All that now remains in there has very little commonality
between the drivers.

When there is ONE and only ONE framebuffer device possible, it makes
sense to try to combine structures as much as possible, especially
when:

1. allocation of structures has overhead.
2. you can get some performance advantage from combining such structures.
3. you're running on an embedded platform and are trying not to waste
   ANY resources.

> > Secondly, I think you're completely confused above.  lccr0 and lccr3 have
> > nothing to do with some "generic struct fb_info".  They hold the base
> > register values for two of the SA1100 control registers.
> >
> > Thirdly, you didn't delete them.  You _moved_ them within the structure.
> > They therefore served zero functional purpose.
> 
> If you could send me a patch I would be happy.

Patch for what?  I _really_ don't understand your request here.

> > Fourthly, nothing but the sa1100fb driver has any business accessing the
> > elements around these two both before and after the move.
> 
> True which is why things like that go into par.

Then why are you trying to share the par between others (as you said in
a previous message)?

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[James Simmons]

> >     We pretty much have this today. Each driver has so much excess code
> > because they want to create their own special structs. Lost of bloat for
> > no reason! I will NOT put up with that anymore!!!! Sorry!
>
> James, you're OTT here.

I apologize I'm sorry. I did get upset. Its just this has been discussed
time and time again. It gets annoying after awhile and it stopped me from
completing the fbdev changes in the last development series. I don't want
that again.

> It's part of the deal.  Either you allow driver writers to cleanly code
> the way they see fit, or you take over maintainence of those drivers.
> You break it, you fix it.  What's it to be?

I'm not going to fight with you about it. I can revert the changes back to
the way you had it before if you want.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 11:32:51AM -0700, James Simmons wrote:
> > James, you're OTT here.
> 
> I apologize I'm sorry. I did get upset. Its just this has been discussed
> time and time again. It gets annoying after awhile and it stopped me from
> completing the fbdev changes in the last development series. I don't want
> that again.

Rubbish.  You posted a fbdev interface change to linux-kernel when the
kernel was supposed to be stabilising.  I converted several of my drivers
to the new interface the best I could.  The drivers are coded in such a
way to make the final stages of your changes as trivial as possible.  I
did find a few bugs with the interface several months later, and had to
undo some of the changes.  However, all work on the new interface appeared
to have stopped.

_I_ didn't stop your fbdev changes.  You stopped them yourself when other
driver maintainers didn't comply with your ill-timed request.  That caused
me to have to back out some of the changes.

And that's the situation today.  If you want to carry on this slagging
match... but its not getting either of us anywhere.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: [PATCH] fbdev updates.

[James Simmons]

> On Fri, Jul 05, 2002 at 11:32:51AM -0700, James Simmons wrote:
> > > James, you're OTT here.
> >
> > I apologize I'm sorry. I did get upset. Its just this has been discussed
> > time and time again. It gets annoying after awhile and it stopped me from
> > completing the fbdev changes in the last development series. I don't want
> > that again.

> _I_ didn't stop your fbdev changes.

I know that. In fact you where one of my best supporters of my ideas. You
defended my ideas against the others who where against it. This I am most
grateful for.

> You stopped them yourself when other
> driver maintainers didn't comply with your ill-timed request.

I didn't want to break their drivers. I still don't. I like to avoid it as
much as possible.

> And that's the situation today.  If you want to carry on this slagging
> match... but its not getting either of us anywhere.

   No I don't either. I'm claimed down and I'm thinking straight again.
Unfortunely email doesn't show this. Sorry about the misunderstanding
here.
   All I want to do is seperate out the console code and redundent
stuff. To make fbdev work without fbcon. You can see the bonus here.
   This is the first step. Once that is out of the way I like to see the
internals AND externals change for fbdev. I'm no big fan of var and fix
being seperate. Plus there is abunch of other things. But this is for the
next developement tree. So once 2.6 comes out I like to start on these
changes right away. Since I see you have a strong opinon (which is a good
thing) I want to here your input on how the next generation of fbdev/dri
drivers should be.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Ani Joshi]

Hi James,

On Fri, 5 Jul 2002, James Simmons wrote:

> > It's part of the deal.  Either you allow driver writers to cleanly code
> > the way they see fit, or you take over maintainence of those drivers.
> > You break it, you fix it.  What's it to be?
>
> I'm not going to fight with you about it. I can revert the changes back to
> the way you had it before if you want.

If you are going to back out the changes you did to RK's drivers could you
please also back out the changes you made to my drivers?  Specifically I
noticed several changes done to rivafb which introduce a riva_par, which I
also don't like to use in my drivers.  My drivers share a very common
structure and I'd like to keep it that way.  I'm not sure if you have done
any changes to the other drivers (radeonfb or aty128fb) but if you could
please backout your changes to rivafb that would be nice.  I will try my
best to free up some time next week and fixup the drivers to go along with
this new API.

The reason I haven't done so yet is that it seems from the traffic on
the list, this "new API" its somewhat of a changing theory so far and its
not yet defined well.  I haven't noticed any other driver maintainers
updating their drivers to this new API (if they are, perhaps I'm looking
at the wrong places) so I am hessitant to do this as it seems its still
'iffy' if this work will actually go into the mainline kernel.  Could
someone please clear up the confusion about this?


Thank you,

ani



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> If you are going to back out the changes you did to RK's drivers could you
> please also back out the changes you made to my drivers?  Specifically I
> noticed several changes done to rivafb which introduce a riva_par, which I
> also don't like to use in my drivers.  My drivers share a very common
> structure and I'd like to keep it that way.  I'm not sure if you have done
> any changes to the other drivers (radeonfb or aty128fb) but if you could
> please backout your changes to rivafb that would be nice.  I will try my
> best to free up some time next week and fixup the drivers to go along with
> this new API.

I did change aty128fb.c. Okay I will revert all the changes I have done.
No more lower level drivers for me.

> The reason I haven't done so yet is that it seems from the traffic on
> the list, this "new API" its somewhat of a changing theory so far and its
> not yet defined well.

It has been in the works for over a year. In CVS, has been tested and even
documented. Been discussed on the mailing list.

I haven't noticed any other driver maintainers
> updating their drivers to this new API (if they are, perhaps I'm looking
> at the wrong places) so I am hessitant to do this as it seems its still
> 'iffy' if this work will actually go into the mainline kernel.  Could
> someone please clear up the confusion about this?

It is and has started to got into the mainline kernel. The thing was I was
bending over backwards to not break peoples drivers.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Russell King]

On Fri, Jul 05, 2002 at 12:32:57PM -0700, James Simmons wrote:
> It is and has started to got into the mainline kernel. The thing was I was
> bending over backwards to not break peoples drivers.

If it's something small, then driver people don't mind having their
drivers fixed.

However, if its something large, just break them and let the driver people
fix up the pieces (assuming you've got adequate documentation either in
code or elsewhere for people to see both the reasons for the breakage,
the direction you're heading in, and an example driver to follow.)
Chances are that they'll know their driver better than anyone else.  If
it stays broken through the next stable series, then start considering
dropping the driver.

That's how it works in the other subsystems.

(FYI, you'll probably find that most people who didn't use the fbgen layer
decided not to use it because of the fix <-> par <-> var mess it forced
into the driver design.)

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> > It is and has started to got into the mainline kernel. The thing was I was
> > bending over backwards to not break peoples drivers.
>
> If it's something small, then driver people don't mind having their
> drivers fixed.
>
> However, if its something large, just break them and let the driver people
> fix up the pieces (assuming you've got adequate documentation either in
> code or elsewhere for people to see both the reasons for the breakage,
> the direction you're heading in, and an example driver to follow.)
> Chances are that they'll know their driver better than anyone else.  If
> it stays broken through the next stable series, then start considering
> dropping the driver.
>
> That's how it works in the other subsystems.

Thinking about it I realized I did the wrong approach. Should I back out
all fbdev driver changes I did or leave some? In this case next week I
will start breaking the upper layer. First to go is the old fbgen code.
Then fields in struct display will start going away. Then get_fix and
stuff will go away.

> (FYI, you'll probably find that most people who didn't use the fbgen layer
> decided not to use it because of the fix <-> par <-> var mess it forced
> into the driver design.)

    I don't like it much either but at the same time I don't want to
break userland. I hate the converting back and forth. I want to make
it better.
    The idea was to make the drivers focused on a par but still generate
a var and fix and update struct fb_info for the upper layer to use. Par is
the main focus and it can be anything. Fix,var and struct fb_info are
only things to generate for the upper layer. We still want some kind of
data struct independent of the driver so we have a common code base for
fbcon. That was the whole idea.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Ani Joshi]

On Fri, 5 Jul 2002, James Simmons wrote:

> It is and has started to got into the mainline kernel. The thing was I was
> bending over backwards to not break peoples drivers.


Ok thanks, sorry for the confusion.  I will try my best to get the few
drivers I maintain to go along with the new API as soon as possible.
Thanks for the work you've done.



ani



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Ani Joshi]

On Fri, 5 Jul 2002, James Simmons wrote:

> It is and has started to got into the mainline kernel. The thing was I was
> bending over backwards to not break peoples drivers.

I forgot to ask another question, the patch you post on your website dir
"fbdev.diff.gz", what exactly is that diffed against?  I tried patching
against 2.5.24 but it failed miserably.  Can you tell me the exact version
for which this was diffed against?


Thanks,

ani





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> > It is and has started to got into the mainline kernel. The thing was I was
> > bending over backwards to not break peoples drivers.
>
> I forgot to ask another question, the patch you post on your website dir
> "fbdev.diff.gz", what exactly is that diffed against?  I tried patching
> against 2.5.24 but it failed miserably.  Can you tell me the exact version
> for which this was diffed against?

Ug. It is against Linus latest BK tree.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[Ani Joshi]

On Fri, 5 Jul 2002, James Simmons wrote:

> Ug. It is against Linus latest BK tree.


Ahh, I don't use BK and I don't wish to use programs which make you
subsribe to silly mailing lists to use their software (but thats another
issue).  Could you please make a diff against 2.5.24 (or whatever the
current 2.5 release is) if possible?  Or is the cvs at sourceforget still
current or did you change over to only BK now?


A patch against a kernel.org tree would be quite helpful, thanks!


ani



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

> Ahh, I don't use BK and I don't wish to use programs which make you
> subsribe to silly mailing lists to use their software (but thats another
> issue).

Okay.

> Could you please make a diff against 2.5.24 (or whatever the
> current 2.5 release is) if possible?  Or is the cvs at sourceforget still
> current or did you change over to only BK now?

Of course I can do that. The CVS still exist. My policy is to have a BK
and CVS tree to make everyone happy.

> A patch against a kernel.org tree would be quite helpful, thanks!

Okay. Thanks.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf

Re: Re: [PATCH] fbdev updates.

[James Simmons]

http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

Its against 2.5.24




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf