On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie wrote:
> On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
> > is this a problem? before trying to submit a solution I wanted to make sure
> > with the experts
> >
> > it seems open_count isn't locked and can cause problems
> >
> > and if it is
On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
>
> > I'm not familiar with video devices, but I agree, this situation does
> > feel broken. Is it the case that there's a PCI device as well as an
> > ACPI namespace Device for t
On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
> I'm not familiar with video devices, but I agree, this situation does
> feel broken. Is it the case that there's a PCI device as well as an
> ACPI namespace Device for the same piece of hardware? If so, I assume
> the reason for th
https://bugs.freedesktop.org/show_bug.cgi?id=32350
--- Comment #34 from Edgar Villanueva 2011-02-07
19:44:26 PST ---
2.6.34.8 exhibits the same problems.
I found the kernel source for fedora 11 that worked but then I realized that I
didn't use DRM there as I had problems.
I build the 2.6.30 an
https://bugs.freedesktop.org/show_bug.cgi?id=32350
--- Comment #34 from Edgar Villanueva 2011-02-07
19:44:26 PST ---
2.6.34.8 exhibits the same problems.
I found the kernel source for fedora 11 that worked but then I realized that I
didn't use DRM there as I had problems.
I build the 2.6.30 an
On 02/06/2011 08:09 PM, Dave Airlie wrote:
> This abstracts the pci/platform interface out a step further,
> we can go further but this is far enough for now to allow USB
> to be plugged in.
>
> The drivers now just call the init code directly for their
> device type.
>
> Signed-off-by: Dave Airlie
On 02/06/2011 08:09 PM, Dave Airlie wrote:
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave Airlie
You don't
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Helber Maciel Guerra changed:
What|Removed |Added
CC||helbe...@gmail.com
--- Comment
On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie wrote:
> On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
> > is this a problem? before trying to submit a solution I wanted to make sure
> > with the experts
> >
> > it seems open_count isn't locked and can cause problems
> >
> > and if it is
On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
> is this a problem? before trying to submit a solution I wanted to make sure
> with the experts
>
> it seems open_count isn't locked and can cause problems
>
> and if it is a problem, and needs to be solved, should locking be done or is
> it
On Sunday, February 06, 2011 04:34:43 pm Rafael J. Wysocki wrote:
>
> Still, IMO, there is a design issue in the entire ACPI subsystem, because the
> idea of "ACPI device" really is not well defined, so to speak. Sometimes
> they are just "device interfaces" that can be used to ask the firmware f
On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
>
> > I'm not familiar with video devices, but I agree, this situation does
> > feel broken. Is it the case that there's a PCI device as well as an
> > ACPI namespace Device for t
https://bugs.freedesktop.org/show_bug.cgi?id=34008
Summary: r600g: piglit failure (regression)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Compon
https://bugs.freedesktop.org/show_bug.cgi?id=34008
Summary: r600g: piglit failure (regression)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Compon
On Sunday, February 06, 2011 04:34:43 pm Rafael J. Wysocki wrote:
>
> Still, IMO, there is a design issue in the entire ACPI subsystem, because the
> idea of "ACPI device" really is not well defined, so to speak. Sometimes
> they are just "device interfaces" that can be used to ask the firmware f
On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
> I'm not familiar with video devices, but I agree, this situation does
> feel broken. Is it the case that there's a PCI device as well as an
> ACPI namespace Device for the same piece of hardware? If so, I assume
> the reason for th
PPC Mac cards do not provide connector tables in
their vbios. Their connector/encoder configurations
must be hardcoded in the driver.
verified by nyef on #radeon
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c | 47
This adds an initial framework to plug USB graphics devices
into the drm/kms subsystem.
I've started writing a displaylink driver using this interface.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_stub.c |1 +
drivers/gpu/drm/drm_usb.c | 117 +++
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_drv.c | 43 ---
PPC Mac cards do not provide connector tables in
their vbios. Their connector/encoder configurations
must be hardcoded in the driver.
verified by nyef on #radeon
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c | 47 +++
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #24 from Török Edwin 2011-02-07 09:13:24 PST
---
(In reply to comment #23)
> Appears the patch is merged in... I can disable shadows in the game and it
> looks really great...
Confirmed, latest Mesa from git works just fine.
Many
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #24 from T?r?k Edwin 2011-02-07 09:13:24
PST ---
(In reply to comment #23)
> Appears the patch is merged in... I can disable shadows in the game and it
> looks really great...
Confirmed, latest Mesa from git works just fine.
Many
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #23 from Kevin DeKorte 2011-02-07 08:48:40 PST
---
Appears the patch is merged in... I can disable shadows in the game and it
looks really great... should I open a new bug on the shadows, or should we
continue the issue here?
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #23 from Kevin DeKorte 2011-02-07 08:48:40
PST ---
Appears the patch is merged in... I can disable shadows in the game and it
looks really great... should I open a new bug on the shadows, or should we
continue the issue here?
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=33348
Dawit Alemayehu changed:
What|Removed |Added
Summary|Display corruption when |[r300g] Display corruption
https://bugs.freedesktop.org/show_bug.cgi?id=33348
Dawit Alemayehu changed:
What|Removed |Added
Summary|Display corruption when |[r300g] Display corruption
https://bugs.freedesktop.org/show_bug.cgi?id=33889
--- Comment #6 from Michel Dänzer 2011-02-07 07:52:45 PST
---
(In reply to comment #4)
> oh then just git master and roll it up into an RPM to confirm, will do this.
That's still not what I asked... while it'll be good to know if the bug is
fix
https://bugs.freedesktop.org/show_bug.cgi?id=33889
--- Comment #6 from Michel D?nzer 2011-02-07 07:52:45
PST ---
(In reply to comment #4)
> oh then just git master and roll it up into an RPM to confirm, will do this.
That's still not what I asked... while it'll be good to know if the bug is
fix
Exit from drm_mode_create_tv_properties and
drm_mode_connector_update_edid_property with -ENOMEM if some of the
internal allocations fails.
This patch fixes only the mentioned routines but doesn't add handling of
the returned values to the caller side. If this patch will be accepted,
I'll also try
is this a problem? before trying to submit a solution I wanted to make
sure with the experts
it seems open_count isn't locked and can cause problems
and if it is a problem, and needs to be solved, should locking be done
or is it better implemented with the (as I understand standard) kref?
ht
drivers/gpu/drm/radeon/mkregtable.c:parser_auth() almost always remembers
to fclose(file) before returning, but it misses two spots.
This is not really important since the process will exit shortly after and
thus close the file for us, but being explicit prevents static analysis
tools from comp
> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
> commit 139315796778a6d5f67c644e2ff470ddc69efb7b
> Author: Adam Jackson
> Date: Tue Aug 3 14:38:19 2010 -0400
<...>
> Maybe this should be ch
On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 12:01:25AM +0100, Rafael J. Wysocki wrote:
>
> > Yes, it seems so, but I'm not sure what the short term consequences of that
> > change will be. Perhaps there will be none. :-)
>
> Ok, I'll have a play with that. Mayb
https://bugzilla.kernel.org/show_bug.cgi?id=21542
--- Comment #11 from curious at bwv190.internetdsl.tpnet.pl 2011-02-07 00:21:45 ---
> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
> commi
On Sunday, February 06, 2011, Matthew Garrett wrote:
> On Sun, Feb 06, 2011 at 11:41:19PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, February 06, 2011, Matthew Garrett wrote:
> > > Ugh. Ok, how can we fix this?
> >
> > Not nicely, I'm afraid.
> >
> > One possible way is to use device_pm_move_
35 matches
Mail list logo
