Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@tr...> - 2002-06-05 16:39:52
|
Since no one has complianed for some time I like to push the next set of changes to Linus. Anyone with objections please give a yell. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-05-03 18:16:29
|
The following link are for more fbdev updates from the PPC guys and a few
fixes.
diff:
http://www.transvirtual.com/~jsimmons/fbdev_fixs.diff
BK URL:
http://fbdev.bkbits.net:8080/fbdev-2.5
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
|
|
From: James S. <jsi...@tr...> - 2002-05-22 16:54:12
|
Hi! I just ported over a few driver to the new api. I also included a few bug fixes as well as a few new drivers. Please try it out and send me any patches. Once the testing is done I will ask Linus to included into his tree. If you look at skeletonfb.c you will see actual info on the new api to help you port it over to the new api. BK: http://fbdev.bkbits.net:8080/fbdev-2.5 Diff: http://www.transvirtual.com/~jsimmons/fbdev.diff P.S Yes with with new api I haven't finished the drawing penguin code so you don't see a penguin yet. I will but I figured the new api is more important. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-05-28 18:10:02
|
Hi! Could you merge the latest stuff in the fbdev BK tree. It has various fixes and ports over ot the new api. Also a few new drivers. http://fbdev.bkbits.net:8080/fbdev-2.5 or a traditional diff at http://www.transvirtual.com/~jsimmons/fbdev.diff P.S To the general list. The company I work for appears to be going under. So if anyone is looking for a kernel developer drop me a email. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-06-04 20:05:34
|
Hi! This patch includes the latest in the fbdev BK repository. I have modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the new api. Please test these changes out before I submit them to linus. Thank you. It is against the latest BK tree and 2.5.20. diff: http://www.transvirtual.com/~jsimmons/fbdev.diff.gz BK: http://fbdev.bkbits.net:8080/fbdev-2.5 . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: Pavel M. <pa...@uc...> - 2002-06-06 22:08:23
|
Hi! > This patch includes the latest in the fbdev BK repository. I have > modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the > new api. Please test these changes out before I submit them to linus. > Thank you. It is against the latest BK tree and 2.5.20. Does the code even boot on any machine having tx3912fb? Pavel -- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa |
|
From: James S. <jsi...@tr...> - 2002-06-17 20:04:52
|
> Hi! > > > This patch includes the latest in the fbdev BK repository. I have > > modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the > > new api. Please test these changes out before I submit them to linus. > > Thank you. It is against the latest BK tree and 2.5.20. > > Does the code even boot on any machine having tx3912fb? Yes :-) Also a few other types of MIPS devices use this framebuffer. |
|
From: Russell K. <rm...@ar...> - 2002-06-05 16:50:28
|
On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote:
> Since no one has complianed for some time I like to push the next set of
> changes to Linus. Anyone with objections please give a yell.
A small suggestion - could you post diffstat -p1 output with your patch
announcements please?
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-06-05 17:21:27
|
> On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote: > > Since no one has complianed for some time I like to push the next set of > > changes to Linus. Anyone with objections please give a yell. > > A small suggestion - could you post diffstat -p1 output with your patch > announcements please? Patch at http://www.transvirtual.com/~jsimmons/fbdev.diff.gz diffstat results: drivers/video/Config.in | 40 drivers/video/Makefile | 28 drivers/video/anakinfb.c | 4 drivers/video/aty128fb.c | 5 drivers/video/cfbcopyarea.c | 4 drivers/video/cfbimgblt.c | 10 drivers/video/clps711xfb.c | 3 drivers/video/cyber2000fb.c | 5 drivers/video/dn_accel.h | 9 drivers/video/dn_cfb4.c | 492 ----- drivers/video/dn_cfb8.c | 540 ------ drivers/video/dnfb.c | 535 +----- drivers/video/fbcmap.c | 2 drivers/video/fbmem.c | 3 drivers/video/maxinefb.c | 290 --- drivers/video/neofb.c | 3639 ++++++++++++++++++++------------------------ drivers/video/neofb.h | 291 --- drivers/video/pm2fb.c | 745 ++++++--- drivers/video/pmag-ba-fb.c | 343 ---- drivers/video/pmagb-b-fb.c | 344 ---- drivers/video/skeletonfb.c | 2 drivers/video/tdfxfb.c | 2434 ++++++++--------------------- drivers/video/tx3912fb.c | 566 ++---- drivers/video/tx3912fb.h | 128 - drivers/video/vfb.c | 4 include/video/neomagic.h | 264 +++ include/video/pm2fb.h | 222 ++ include/video/tx3912.h | 62 28 files changed, 4034 insertions(+), 6980 deletions(-) |
|
From: James S. <jsi...@tr...> - 2002-07-01 17:48:47
|
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!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: Jani M. <ja...@iv...> - 2002-07-02 10:14:44
|
On Mon, 1 Jul 2002 10:48:41 -0700 (PDT) James Simmons <jsi...@tr...> 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. |
|
From: James S. <jsi...@tr...> - 2002-07-05 02:42:05
|
> 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 |
|
From: Russell K. <rm...@ar...> - 2002-07-03 23:04:08
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 04:06:07
|
> 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. |
|
From: Russell K. <rm...@ar...> - 2002-07-05 08:44:53
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Geert U. <ge...@li...> - 2002-07-05 08:54:27
|
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 -- 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
|
|
From: Russell K. <rm...@ar...> - 2002-07-05 09:09:50
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Geert U. <ge...@li...> - 2002-07-05 09:40:18
|
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 -- 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
|
|
From: Russell K. <rm...@ar...> - 2002-07-05 10:20:48
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 17:20:23
|
> > > 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. |
|
From: James S. <jsi...@tr...> - 2002-07-05 17:16:36
|
> 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? |
|
From: Russell K. <rm...@ar...> - 2002-07-05 17:58:52
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 18:21:26
|
> > 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. |
|
From: Russell K. <rm...@ar...> - 2002-07-05 18:27:44
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 17:14:23
|
> 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.
|
Thanks for helping keep SourceForge clean.
X