Re: radeonfb patch for 2.4.22...

Re: radeonfb patch for 2.4.22...

[Marcelo Tosatti]

On Mon, 14 Jul 2003 ajoshi@kernel.crashing.org 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 ?

Re: radeonfb patch for 2.4.22...

[ajoshi]

On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
> 
> On Mon, 14 Jul 2003 ajoshi@kernel.crashing.org 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

Re: radeonfb patch for 2.4.22...

[Marcelo Tosatti]

On Mon, 14 Jul 2003 ajoshi@kernel.crashing.org wrote:

>
>
> On Mon, 14 Jul 2003, Marcelo Tosatti wrote:
> >
> > On Mon, 14 Jul 2003 ajoshi@kernel.crashing.org 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.

Re: radeonfb patch for 2.4.22...

[ajoshi]

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.

Re: radeonfb patch for 2.4.22...

[Marcelo Tosatti]

On Mon, 14 Jul 2003 ajoshi@kernel.crashing.org 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?

Re: radeonfb patch for 2.4.22...

[Damian Kolkowski]

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/ #

Re: radeonfb patch for 2.4.22...

[Marcelo Tosatti]

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

Re: radeonfb patch for 2.4.22...

[Benjamin Herrenschmidt]

> >
> > 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.

Re: radeonfb patch for 2.4.22...

[Benjamin Herrenschmidt]

> 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.

Re: radeonfb patch for 2.4.22...

[Peter Osterlund]

Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: radeonfb patch for 2.4.22...

[Benjamin Herrenschmidt]

> 
> 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 <benh@kernel.crashing.org>

Re: radeonfb patch for 2.4.22...

[James Simmons]

> So, basically, it's normal, as I thought. 
> 
> Perhaps a quick clear screen as it's initialized would be good...

I think so. For 2.5.X it woudl be just a matter of calling 
xxxfb_fillrect to clear the screen.

Re: radeonfb patch for 2.4.22...

[Eric Blade]

James Simmons wrote:

>>This has been happening to me on my Radeon and on my Voodoo 3 for as 
>>long as there has been framebuffers and they have in fact compiled and 
>>worked.  I thought this was normal?
>>    
>>
>
>Its caused from switching from text mode to graphics mode. Take for 
>example I have grabbed th epci regions for my voodoo card and then wrote 
>to them. This was done before I switched to graphics mode. It messed up my 
>vga text screen. So when we go from text to graphics we have stale data. 
>
>
>
>
>  
>
So, basically, it's normal, as I thought. 

Perhaps a quick clear screen as it's initialized would be good...


-- 
----BEGIN GEEK CODE BLOCK----
Version: 3.1
GB/CS/MC/MU/O @d+ s:- a- C++++ UL++++  !P  L+++ !E W+++ !N !o K? w--- @O++ !M !V PS+ PE- Y PGP- @t 5? X R tv-- b- DI++ D++ G e* h* r  y+ 
----END GEEK CODE BLOCK----

Re: radeonfb patch for 2.4.22...

[James Simmons]

> This has been happening to me on my Radeon and on my Voodoo 3 for as 
> long as there has been framebuffers and they have in fact compiled and 
> worked.  I thought this was normal?

Its caused from switching from text mode to graphics mode. Take for 
example I have grabbed th epci regions for my voodoo card and then wrote 
to them. This was done before I switched to graphics mode. It messed up my 
vga text screen. So when we go from text to graphics we have stale data. 

Re: radeonfb patch for 2.4.22...

[Eric Blade]

> 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. 



This has been happening to me on my Radeon and on my Voodoo 3 for as long as there has been framebuffers and they have in fact compiled and worked.  I thought this was normal?



-- 
----BEGIN GEEK CODE BLOCK----
Version: 3.1
GB/CS/MC/MU/O @d+ s:- a- C++++ UL++++  !P  L+++ !E W+++ !N !o K? w--- @O++ !M !V PS+ PE- Y PGP- @t 5? X R tv-- b- DI++ D++ G e* h* r  y+ 
----END GEEK CODE BLOCK----