Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
You do get the nice serial console printout at boot right, it's only
not working on resume?
Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
The serial line is probably coming back at the default baud rate and
you were setting it
On 6/18/05, Lorenzo Colitti [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
The serial line is probably coming
Jon Smirl wrote:
The only way I can think to debug this is to put bunches of
printks into drivers/video/aty/radeon_pm.c and then hook a serial
console up to the laptop. [...]
Hmm. I could try that (though not in the next couple of weeks because I
won't have access to another machine), will the
On 6/17/05, Lorenzo Colitti [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
The only way I can think to debug this is to put bunches of
printks into drivers/video/aty/radeon_pm.c and then hook a serial
console up to the laptop. [...]
Hmm. I could try that (though not in the next couple of
On Friday 10 June 2005 22:14, Jon Smirl wrote:
BSD would have it's own equivalent of the inlines for getting the
flags. BSD is already getting the flags with a different scheme than
Linux. There will probably be other places where BSD needs special
code, for example attaching to the interrupt
On 6/11/05, Adam Jackson [EMAIL PROTECTED] wrote:
I did it so that maintenance of the flags would be in a single place.
All of those flags are exactly duplicated in radeonfb. If I recall
right I'm the one who added the flag code to DRM to begin with and I
copied it out of radeonfb. The
Linux only allows one device driver to attach to a device like the
radeon. Right now this driver is radeonfb. When DRM loads it uses the
radeon hardware without attaching to it and informing the kernel. What
DRM is doing is not compatible with hotplug. DRM enables the
framebuffer without reserving
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in use.
I chose this method because Xegl wants radeonfb loaded and
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in use.
I chose this method because Xegl wants radeonfb loaded and this
scheme has minimal code impact.
Seems
On Friday 10 June 2005 11:09, Jon Smirl wrote:
Linux only allows one device driver to attach to a device like the
radeon. Right now this driver is radeonfb. When DRM loads it uses the
radeon hardware without attaching to it and informing the kernel. What
DRM is doing is not compatible with
On Friday, June 10, 2005 8:39 am, Jon Smirl wrote:
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in
use. I
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote:
My solution to this is to make radeon DRM depend on radeonfb. radeonfb
properly attaches to the device and marks everything in use. I chose
this method because Xegl wants radeonfb loaded and this scheme has
minimal code impact.
This
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
A lot of embedded systems are going with OpenGL/ES. EGL is derived
from the OpenGL/ES spec. Going with OpenGL/ES is a cross platform
solution for them, KAA would be kdrive specific.
Right, I'm just saying that alternatives exist for people
On Friday, June 10, 2005 8:52 am, Jon Smirl wrote:
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote:
My solution to this is to make radeon DRM depend on radeonfb.
radeonfb properly attaches to the device and marks everything in
use. I chose this method because Xegl wants radeonfb loaded
Jon Smirl wrote:
Can everyone please try this patch out and see if loading radeonfb
causes any problems on your system. Having radeonfb loaded on x86 is
not a normal case. Radeon Xegl is going to depend on having both
radeon and radeonfb loaded so I need to know if this will cause
problems.
If
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Can everyone please try this patch out and see if loading radeonfb
causes any problems on your system. Having radeonfb loaded on x86 is
not a normal case. Radeon Xegl is going to depend on having both
radeon and
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote:
If I load radeonfb, my laptop hangs on resume from S3. It has been known
to cause problems for other people too, see for example the following:
http://sourceforge.net/mailarchive/message.php?msg_id=10772046
On Friday, June 10, 2005 9:07 am, Jon Smirl wrote:
The Xegl model lets you pick where you get your drivers from. It just
runs on top of a driver stack providing the OpenGL/ES+EGL API. The
embedded systems I am aware of are ignoring mesa, drm, fbdev and and
building their own optimized
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
My point about KAA (or Shiny or whatever it ends up being) is that
people, who for whatever reason don't want DRM/DRI (too big, too
complex, or maybe they're just contrarians), can still just use the fb
drivers by themselves along with whatever
On Friday, June 10, 2005 10:46 am, Jon Smirl wrote:
We don't have enough people to finish one set of drivers and cetainly
not enough to finish two. What we are going to end up with is two
half finished systems. People working on KAA are capable of making
valuable contributions to DRI/DRM if
On Fri, 2005-06-10 at 13:46 -0400, Jon Smirl wrote:
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote:
My point about KAA (or Shiny or whatever it ends up being) is that
people, who for whatever reason don't want DRM/DRI (too big, too
complex, or maybe they're just contrarians), can still
On 6/10/05, Eric Anholt [EMAIL PROTECTED] wrote:
Your constant harping on we don't have enough people to be working on
both sides, that's why they should all work on this (my) project is
what makes me want to not help with Xegl efforts at all.
I'm in open-source software because I get to
Jon Smirl wrote:
My patch will do nothing for the S3 resume problem. There must be some
bug in the radeonfb power management code. The only way I can think to
debug this is to put bunches of printks into
drivers/video/aty/radeon_pm.c and then hook a serial console up to the
laptop. [...]
Hmm.
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
My patch will do nothing for the S3 resume problem. There must be some
bug in the radeonfb power management code. The only way I can think to
debug this is to put bunches of printks into
drivers/video/aty/radeon_pm.c
This seems like an odd solution. Why wouldn't you just enable
multiple drivers to attach to the device?
Nah, that would cause endless issues. Especially since we actually want
some synchronisation/locking between the two, at least ultimately.
Can everyone please try this patch out and see
On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't touch
the hardware per-se (thus won't break your VGA console,
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote:
On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't touch
On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't
touch the hardware per-se (thus won't break your VGA
On Fri, 2005-06-10 at 20:03 -0400, Adam Jackson wrote:
On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote:
Anyway, I really want a slightly different approach than what Jon is
doing, that is a 3 modules scenario:
- A basic stub module that attaches to the PCI card. It doesn't
On Friday 10 June 2005 20:13, Jon Smirl wrote:
Why don't we start with a two module system which is already 90%
written. There is nothing stopping it from being split into a three
module system later. I'm not against the three module system I just
don't want to create more work to do.
Because
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote:
Because technically this patch is bogus if it ever gets merged back to DRM
CVS. It will break BSD, video/radeon_share.h is a linuxism, and you've
added that and calls to your new radeonfb stublets in shared-core.
BSD would have it's own
32 matches
Mail list logo
