From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-08-02 03:34:34
Hi !
I'm having more and more pain with atyfb at this point. I really need
the changes that bring the pci_driver (and new PM callbacks) so I can
properly work on these.
However, bringing just that change from the fbdev tree to the main tree
is incredibly painful due to the major amount of changes that went into
this driver.
So can somebody show up and tell me what is the status of this driver as
it is currently in the fbdev-2.5 bk tree and if that stuff can actually
be sent upstream ASAP or not ?
I don't feel like re-doing just the pci_driver changes, did it once, was
painful enough, but on the other hand, this driver has been drifting
away from mainstream for ages, which is simply not acceptable.
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-08-02 05:24:29
Ok, I built an upstream tree with just the new atyfb in, and it breaks
on the wallstreet powerbook (LT-G) here. I'm not sure what is wrong at
this point, I'd say the clock stuff is incorrectly calculated.
On PPC, you do not have access to BIOS tables. So driver starts with
blowing up since the code for retreiving that from BIOS is unconditional
(it should be X86 only).
I disabled that, but then, the default values (which are the same as the old
driver afaik) don't seem to be enough anymore to produce a correct output.
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
From: Alexander Kern <hidden> Date: 2004-08-03 20:58:28
Am Montag, 2. August 2004 07:21 schrieb Benjamin Herrenschmidt:
Ok, I built an upstream tree with just the new atyfb in, and it breaks
on the wallstreet powerbook (LT-G) here. I'm not sure what is wrong at
this point, I'd say the clock stuff is incorrectly calculated.
On PPC, you do not have access to BIOS tables. So driver starts with
blowing up since the code for retreiving that from BIOS is unconditional
(it should be X86 only).
I disabled that, but then, the default values (which are the same as the
old driver afaik) don't seem to be enough anymore to produce a correct
output.
Ben.
Hi, I do not have any information or hardware about PPC. Should it own
something like OpenFirmware? In this case it is possible to read clock
information from this.
I found, that we change a little behaviour. Please give a try for this
patch...
Regards Alex
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-08-03 21:25:58
Hi, I do not have any information or hardware about PPC. Should it own
something like OpenFirmware? In this case it is possible to read clock
information from this.
On some models, yes, on some no. Older machines have a firmware that
won't tell you anything, the MacOS driver back then was hard coding the
values.
Anyway, the clocks are ok, apparently (maybe not the engine one though,
see later), the problem was that the DLL magic was reverted for the
LT-G, plus some minor issues with the driver blowing up on non-BIOS
machines that I can fix.
The engine tends to lockup quickly though, I'll do experiments.
I found, that we change a little behaviour. Please give a try for this
patch...
Your patch seem to address the DLL issue, I did that too, fixes the display,
I'll toy around and let you know.
Also, when just dropping the existing driver into the current linus tree, the
cursor code is blowing up, I don't know why yet, I suppose some changes to the
common code in the fbdev tree. I'll have a look.
I really want this new driver to be sent upstream ASAP. What I may do is once
I get it working well enough, I'll send it to andrew for the -mm tree and
leave it there for a while to get it properly tested.
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
From: Ville Syrjälä <syrjala@sci.fi> Date: 2004-08-03 22:05:35
On Wed, Aug 04, 2004 at 07:25:40AM +1000, Benjamin Herrenschmidt wrote:
Also, when just dropping the existing driver into the current linus tree, the
cursor code is blowing up, I don't know why yet, I suppose some changes to the
common code in the fbdev tree. I'll have a look.
I had (probably) the same oops when using the driver from bk on 2.6.5-mm6.
Alex's latest patch fixed it for me.
On a somewhat related note...
I'd like to know if my LT LCD register access patch works correctly. It
should allow the generic LCD code to work on LT. It's included in Alex's
latest patch. But since parsing the BIOS is out of the question you'd have
to hardcode the LCD parameters. Could you test it?
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
From: Alexander Kern <hidden> Date: 2004-08-06 06:10:06
Am Dienstag, 3. August 2004 23:25 schrieb Benjamin Herrenschmidt:
quoted
Hi, I do not have any information or hardware about PPC. Should it own
something like OpenFirmware? In this case it is possible to read clock
information from this.
On some models, yes, on some no. Older machines have a firmware that
won't tell you anything, the MacOS driver back then was hard coding the
values.
Anyway, the clocks are ok, apparently (maybe not the engine one though,
see later), the problem was that the DLL magic was reverted for the
LT-G, plus some minor issues with the driver blowing up on non-BIOS
machines that I can fix.
The engine tends to lockup quickly though, I'll do experiments.
quoted
I found, that we change a little behaviour. Please give a try for this
patch...
Your patch seem to address the DLL issue, I did that too, fixes the
display, I'll toy around and let you know.
Also, when just dropping the existing driver into the current linus tree,
the cursor code is blowing up, I don't know why yet, I suppose some changes
to the common code in the fbdev tree. I'll have a look.
I really want this new driver to be sent upstream ASAP. What I may do is
once I get it working well enough, I'll send it to andrew for the -mm tree
and leave it there for a while to get it properly tested.
Ben.
Hi, here a snapshot from my tree over 2.6.7 + js3
Changes:
revert SDRAM_MAGIC_PLL to old behaviour
do a "from BIOS" initialisation only by __i386__
Regards
Alex
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-08-06 08:13:04
On Fri, 2004-08-06 at 16:09, Alexander Kern wrote:
Hi, here a snapshot from my tree over 2.6.7 + js3
Thanks, I'll have a look next week
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com