From: Russell King <hidden> Date: 2002-07-05 17:58:03
On Fri, Jul 05, 2002 at 10:14:12AM -0700, James Simmons wrote:
quoted
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?
quoted
"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.
quoted
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.
quoted
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
From: James Simmons <hidden> Date: 2002-07-05 18:33:00
quoted
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
From: Ani Joshi <hidden> Date: 2002-07-05 19:16:06
Hi James,
On Fri, 5 Jul 2002, James Simmons wrote:
quoted
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
From: James Simmons <hidden> Date: 2002-07-05 19:33:08
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
From: Ani Joshi <hidden> Date: 2002-07-05 19:39:59
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
From: Ani Joshi <hidden> Date: 2002-07-05 19:41:57
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
From: James Simmons <hidden> Date: 2002-07-05 19:58:25
quoted
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
From: Ani Joshi <hidden> Date: 2002-07-05 20:07:31
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
From: James Simmons <hidden> Date: 2002-07-05 20:09:12
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