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
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
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
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.
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
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 the
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 for
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 the same
On Sunday, February 06, 2011, Matthew Garrett wrote:
> On Sun, Feb 06, 2011 at 09:35:07PM +0100, Rafael J. Wysocki wrote:
> > > + acpi_get_parent(device->dev->handle, _parent);
> > > +
> > > + pdev = acpi_get_pci_dev(acpi_parent);
> > > + if (pdev) {
> > > +
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. Maybe we should be fixing this up
somehow in the acpi-pci glue
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_after() to rearrange the devices in
> the PM core's suspend list,
On Friday, January 14, 2011, Matthew Garrett wrote:
> Dual-GPU machines may provide more than one ACPI backlight interface. Tie
> the backlight device to the GPU in order to allow userspace to identify
> the correct interface.
>
> Signed-off-by: Matthew Garrett
Sorry for the late response, but
On Sun, Feb 06, 2011 at 09:35:07PM +0100, Rafael J. Wysocki wrote:
> > + acpi_get_parent(device->dev->handle, _parent);
> > +
> > + pdev = acpi_get_pci_dev(acpi_parent);
> > + if (pdev) {
> > + parent = >dev;
> > +
On Friday, January 14, 2011, Matthew Garrett wrote:
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett m...@redhat.com
Sorry for the late
On Sun, Feb 06, 2011 at 09:35:07PM +0100, Rafael J. Wysocki wrote:
+ acpi_get_parent(device-dev-handle, acpi_parent);
+
+ pdev = acpi_get_pci_dev(acpi_parent);
+ if (pdev) {
+ parent = pdev-dev;
+ pci_dev_put(pdev);
+
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_after() to rearrange the devices in
the PM core's suspend list, but that
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_after() to
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. Maybe we should be fixing this up
somehow in the acpi-pci glue code?
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. Maybe we
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14 insertions(+), 1
21 matches
Mail list logo
