On Mon, 14 Jul 2003 [email protected] wrote:
>
> Hi Marcelo,
>
> Is there any particular reason why you decided to merge Ben H.'s radeonfb
> update instead of the one I sent you?
I've decided to CC lkml because I think there are other people interested
in this discussion.
I merged his version because he sent me your update (0.1.8) plus his code
(which are useful fixes he has been working on).
It seems things are broken now due to a missing header, but he also sent
me that.
Do you have any objections to his fixes ?
On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
>
> On Mon, 14 Jul 2003 [email protected] wrote:
>
> >
> > Hi Marcelo,
> >
> > Is there any particular reason why you decided to merge Ben H.'s radeonfb
> > update instead of the one I sent you?
>
> I've decided to CC lkml because I think there are other people interested
> in this discussion.
>
> I merged his version because he sent me your update (0.1.8) plus his code
> (which are useful fixes he has been working on).
Which is what the original 0.1.8 patch included, his fixes were included.
>
> It seems things are broken now due to a missing header, but he also sent
> me that.
There was no missing header, if you see the patch I sent you (about 3
times), the header file is in there.
>
> Do you have any objections to his fixes ?
>
Besides the obvious version changes and difficulty maintaining a driver
where anyone seems to be able to change it in the official tree, the
objections were deteremined and fixed in the patch I sent you.
Refresh my memory as it seems things have changed in kernel patch
submission process:
There is someone called a driver author or maintainer, this person
recieves patches for fixes from various people, he/she then compiles them
into a single patch and submits it to the kernel tree maintiner. However
nowdays it seems the kernel tree maintainer has the descretion to accept
patches from anyone how puts up a fight, is this the case nowdays?
If so then please let me know, so I don't waste anymore of my time on this
driver and let someone else play these silly games and maintain it.
ani
On Mon, 14 Jul 2003 [email protected] wrote:
>
>
> On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
> >
> > On Mon, 14 Jul 2003 [email protected] wrote:
> >
> > >
> > > Hi Marcelo,
> > >
> > > Is there any particular reason why you decided to merge Ben H.'s radeonfb
> > > update instead of the one I sent you?
> >
> > I've decided to CC lkml because I think there are other people interested
> > in this discussion.
> >
> > I merged his version because he sent me your update (0.1.8) plus his code
> > (which are useful fixes he has been working on).
>
> Which is what the original 0.1.8 patch included, his fixes were included.
Ah really? I though that his changes were not merged in your 0.1.8 patch.
So can I just revert his patch and accept your instead that all of his
stuff is in ? Whoaa, great.
>
> >
> > It seems things are broken now due to a missing header, but he also sent
> > me that.
>
> There was no missing header, if you see the patch I sent you (about 3
> times), the header file is in there.
>
> >
> > Do you have any objections to his fixes ?
> >
>
> Besides the obvious version changes and difficulty maintaining a driver
> where anyone seems to be able to change it in the official tree, the
> objections were deteremined and fixed in the patch I sent you.
>
> Refresh my memory as it seems things have changed in kernel patch
> submission process:
>
> There is someone called a driver author or maintainer, this person
> recieves patches for fixes from various people, he/she then compiles them
> into a single patch and submits it to the kernel tree maintiner. However
> nowdays it seems the kernel tree maintainer has the descretion to accept
> patches from anyone how puts up a fight, is this the case nowdays?
Ani, I received complains that you were not accepting patches from Ben. He
needs that code in.
> If so then please let me know, so I don't waste anymore of my time on
> this driver and let someone else play these silly games and maintain it.
I prefer playing no silly games in the 2.4 stable series, as I've been
trying to do so far. If you had accepted Ben's changes in the first place
I wouldnt need to apply his patch.
Ben is very interested in maintaining the driver, AFAIK. Is that
correct, Ben?
Are you interested in giving up maintenance?
For me it doenst matter who maintains the driver, as long as it is well
maintained.
On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
>
> Ah really? I though that his changes were not merged in your 0.1.8 patch.
>
> So can I just revert his patch and accept your instead that all of his
> stuff is in ? Whoaa, great.
Here is an xcept from ChangeLong section of the driver from the patch I
sent you:
+ * 2003-04-12 Mac PowerBook sleep fixes, Benjamin Herrenschmidt,
+ * 0.1.8
I agree this isn't very descriptive of this other fixes and I can change
that, but a lot of his Mac changes have been merged in, but apparently
nobody has taken the time to actually look at that patch. If there are
things that are missing then I asked him to tell me, which he has not so I
assume there are none.
> Ani, I received complains that you were not accepting patches from Ben. He
> needs that code in.
This is not true, see the above. Also, its hard to "accept patches" from
people if you do NOT recieve any patches from them! Ben's style is to get
the maintainers of drivers to go around and search for his personal tree
and do their own diffs from that tree, instead of him sending a patch to
the maintainer.
> > If so then please let me know, so I don't waste anymore of my time on
> > this driver and let someone else play these silly games and maintain it.
>
> I prefer playing no silly games in the 2.4 stable series, as I've been
> trying to do so far. If you had accepted Ben's changes in the first place
> I wouldnt need to apply his patch.
I did accept most all of his changes when this patch was made (originally
I sent it May 12, which you did not merge into 2.4.21, probably because I
sent it during the RC stange, but after that you lost the patch ?). Since
that time, I assume Ben has made some other changes, which I have not
recieved any word about.
Please don't accuse people of not accpeting patches when that is simply
not true, as it can be easily said for you too.
On Mon, 14 Jul 2003 [email protected] wrote:
>
>
> On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
>
> >
> > Ah really? I though that his changes were not merged in your 0.1.8 patch.
> >
> > So can I just revert his patch and accept your instead that all of his
> > stuff is in ? Whoaa, great.
>
> Here is an xcept from ChangeLong section of the driver from the patch I
> sent you:
>
> + * 2003-04-12 Mac PowerBook sleep fixes, Benjamin Herrenschmidt,
> + * 0.1.8
>
> I agree this isn't very descriptive of this other fixes and I can change
> that, but a lot of his Mac changes have been merged in, but apparently
> nobody has taken the time to actually look at that patch. If there are
> things that are missing then I asked him to tell me, which he has not so I
> assume there are none.
Ben, can you submit a patch against Ani's latest driver which adds all
your fixes, please?
> > Ani, I received complains that you were not accepting patches from Ben. He
> > needs that code in.
>
> This is not true, see the above. Also, its hard to "accept patches" from
> people if you do NOT recieve any patches from them! Ben's style is to get
> the maintainers of drivers to go around and search for his personal tree
> and do their own diffs from that tree, instead of him sending a patch to
> the maintainer.
I'vee asked Ben to submit his code against yours 1
>
> > > If so then please let me know, so I don't waste anymore of my time on
> > > this driver and let someone else play these silly games and maintain it.
> >
> > I prefer playing no silly games in the 2.4 stable series, as I've been
> > trying to do so far. If you had accepted Ben's changes in the first place
> > I wouldnt need to apply his patch.
>
> I did accept most all of his changes when this patch was made (originally
> I sent it May 12, which you did not merge into 2.4.21, probably because I
> sent it during the RC stange, but after that you lost the patch ?).
Yes I lost it.
> Since that time, I assume Ben has made some other changes, which I have
> not recieved any word about.
>
> Please don't accuse people of not accpeting patches when that is simply
> not true, as it can be easily said for you too.
I received complains from people I trust. I'm sorry for accusing you of
something you have not made.
Now lets have a 0.1.8 + "ok with you" ben changes patch ?
I will revert Ben patch and apply that instead once we have it.
Seems everyone will be happy that way, right?
On Mon, Jul 14, 2003 at 04:11:02PM -0300, Marcelo Tosatti wrote:
> I received complains from people I trust. I'm sorry for accusing you of
> something you have not made.
There's no linux/radeonfb.h :-)
Just add it from Ani Joshi 0.1.8 patch:
.~. $ cat /src/linux/include/linux/radeonfb.h
#ifndef __LINUX_RADEONFB_H__
#define __LINUX_RADEONFB_H__
#include <asm/ioctl.h>
#include <asm/types.h>
#define ATY_RADEON_LCD_ON 0x00000001
#define ATY_RADEON_CRT_ON 0x00000002
#define FBIO_RADEON_GET_MIRROR _IOR('@', 3, sizeof(__u32*))
#define FBIO_RADEON_SET_MIRROR _IOW('@', 4, sizeof(__u32*))
#endif
.~. $
--
# Damian *dEiMoS* Ko?kowski # http://deimos.one.pl/ #
On Mon, 14 Jul 2003, Damian Kolkowski wrote:
> On Mon, Jul 14, 2003 at 04:11:02PM -0300, Marcelo Tosatti wrote:
> > I received complains from people I trust. I'm sorry for accusing you of
> > something you have not made.
>
> There's no linux/radeonfb.h :-)
>
> Just add it from Ani Joshi 0.1.8 patch:
Damian,
I'll do it for 2.4.22-pre6 (which is going out today, btw) but I prefer
having Ani send me a patch with all of acceptable Ben's patches in.
Thanks
> >
> > Which is what the original 0.1.8 patch included, his fixes were included.
>
> Ah really? I though that his changes were not merged in your 0.1.8 patch.
>
> So can I just revert his patch and accept your instead that all of his
> stuff is in ? Whoaa, great.
No. 0.1.8 lacks a lot of my stuffs
> I prefer playing no silly games in the 2.4 stable series, as I've been
> trying to do so far. If you had accepted Ben's changes in the first place
> I wouldnt need to apply his patch.
>
> Ben is very interested in maintaining the driver, AFAIK. Is that
> correct, Ben?
>
> Are you interested in giving up maintenance?
>
> For me it doenst matter who maintains the driver, as long as it is well
> maintained.
I could take over if Ani wants to give up, though I would prefer a
dedicated maintainer with more time to do the necessary rewrite of
this driver in 2.6 and later, which I don't have time to do right
now, however, I can maintain the existing code base if necessary.
Ben.
> This is not true, see the above. Also, its hard to "accept patches" from
> people if you do NOT recieve any patches from them! Ben's style is to get
> the maintainers of drivers to go around and search for his personal tree
> and do their own diffs from that tree, instead of him sending a patch to
> the maintainer.
Ok, please stop that, I did post patches publically and you were always
CCed, I have really no time to spend on useless arguments here, the code
is there, it works, it fixes bugs, you didn't even look at it since you
claim it's all in your 0.1.8, so please, stop bs'ing us.
I spent a significant amount of time tracking problems that users
reported after they told me they never got any useful reply from you.
Some obvious fixes like the VRAM amount fix for LY chips, which is still
broken in your 0.1.8, have been around -ac etc... for monthes. I DO NOT
care about beeing "maintainer" just to get my name in there, all I care
about right now is getting those fixes in so the driver works and
concentrate on more interesting matters.
I spent several hours redoing most of my patches against 0.1.8, which is
what Marcelo merged, I won't do it again. If you don't agree with the
version change (which was here only to avoid confusion when getting user
reports), then send Marcelo a patch that tells "0.1.9" and be done with
it.
Ben.
Benjamin Herrenschmidt <[email protected]> writes:
> > >
> > > Which is what the original 0.1.8 patch included, his fixes were included.
> >
> > Ah really? I though that his changes were not merged in your 0.1.8 patch.
> >
> > So can I just revert his patch and accept your instead that all of his
> > stuff is in ? Whoaa, great.
>
> No. 0.1.8 lacks a lot of my stuffs
I have a small problem with radeonfb in 2.4.22-pre5 (+manually created
radeonfb.h file). During boot, when the console is switched over to
the frame buffer device, the screen becomes corrupted. Mostly by white
squares in a grid pattern and some squares with other colors. Between
the squares, normal characters can be seen, but each character is
duplicated. Here is a picture: (not very sharp unfortunately)
http://w1.894.telia.com/~u89404340/radeonfb.jpg
Text added after the switch is not corrupted, so eventually the
corruption is scrolled off the screen and after that the framebuffer
appears to be working correctly.
2.4.22-pre3 does not have this problem. I haven't found a patch for
the vanilla 0.1.8 version, so I don't know if that version also has
this problem. I think someone has reported a similar problem in 2.5.x,
but I don't remember the details.
Here are some messages from the kernel log:
Jul 14 23:08:44 best kernel: radeonfb: ref_clk=2700, ref_div=12, xclk=18300 from BIOS
Jul 14 23:08:44 best kernel: radeonfb: panel ID string: Samsung LTN150P1-L02
Jul 14 23:08:44 best kernel: radeonfb: detected LCD panel size from BIOS: 1400x1050
Jul 14 23:08:44 best kernel: Console: switching to colour frame buffer device 175x65
Jul 14 23:08:44 best kernel: radeonfb: ATI Radeon M7 LW DDR SGRAM 64 MB
Jul 14 23:08:44 best kernel: radeonfb: DVI port LCD monitor connected
Jul 14 23:08:44 best kernel: radeonfb: CRT port no monitor connected
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
>
> I have a small problem with radeonfb in 2.4.22-pre5 (+manually created
> radeonfb.h file). During boot, when the console is switched over to
> the frame buffer device, the screen becomes corrupted. Mostly by white
> squares in a grid pattern and some squares with other colors. Between
> the squares, normal characters can be seen, but each character is
> duplicated. Here is a picture: (not very sharp unfortunately)
>
> http://w1.894.telia.com/~u89404340/radeonfb.jpg
>
> Text added after the switch is not corrupted, so eventually the
> corruption is scrolled off the screen and after that the framebuffer
> appears to be working correctly.
It's a known artifact caused by my latest stuffs, mostly because
I setup the display earlier than expected by the fbcon core, at
which point the console buffer contains junk. I'm working on a fix
though I can't reproduce on pmac.
> 2.4.22-pre3 does not have this problem. I haven't found a patch for
> the vanilla 0.1.8 version, so I don't know if that version also has
> this problem. I think someone has reported a similar problem in 2.5.x,
> but I don't remember the details.
>
> Here are some messages from the kernel log:
>
> Jul 14 23:08:44 best kernel: radeonfb: ref_clk=2700, ref_div=12, xclk=18300 from BIOS
> Jul 14 23:08:44 best kernel: radeonfb: panel ID string: Samsung LTN150P1-L02
> Jul 14 23:08:44 best kernel: radeonfb: detected LCD panel size from BIOS: 1400x1050
> Jul 14 23:08:44 best kernel: Console: switching to colour frame buffer device 175x65
> Jul 14 23:08:44 best kernel: radeonfb: ATI Radeon M7 LW DDR SGRAM 64 MB
> Jul 14 23:08:44 best kernel: radeonfb: DVI port LCD monitor connected
> Jul 14 23:08:44 best kernel: radeonfb: CRT port no monitor connected
--
Benjamin Herrenschmidt <[email protected]>
