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?
Ben
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 pro
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 higher
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
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/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
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 interru
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, is a linuxism, and you've
> added that and calls to your new radeonfb stublets in shared-core.
BSD would have it's own equivalent of the inl
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.
Beca
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 d
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 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 does
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 con
>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 se
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/rade
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. I
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 ge
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
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 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 wha
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 OpenG
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
> http://lkml.org/lkml/2005/
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 a
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 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 radeo
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 f
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.
>
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
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: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 reaso
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 lo
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
32 matches
Mail list logo
