search for: acpi_device

...Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp> diff -r 618fc299e2f1 -r 4769a6db78f5 drivers/acpi/pci_root.c --- a/drivers/acpi/pci_root.c Thu Dec 18 11:51:36 2008 +0000 +++ b/drivers/acpi/pci_root.c Thu Dec 25 10:37:52 2008 +0900 @@ -151,6 +151,36 @@ return AE_OK; } +ssize_t +acpi_device_seg_show(struct acpi_device *acpi_dev, char *buf) +{ + struct list_head *entry; + + list_for_each(entry, &acpi_pci_roots) { + struct acpi_pci_root *root; + root = list_entry(entry, struct acpi_pci_root, node); + if (root->device == acpi_dev) + return sprintf(buf, "%04x\n", ro...

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that

No, there are not. Here is the recursive directory listing: http://sprunge.us/FIRE Op do 27 okt. 2016 11:30 schreef Mika Westerberg < mika.westerberg at linux.intel.com>: > On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > > power_state contains D3hot. > > And there are no

...amp;in, &out); + edid = out.pointer; + + if (ACPI_SUCCESS(status)) + ret = edid->buffer.pointer; + + kfree(edid); + + if (ret) + break; + } + + return ret; +} + +static struct edid *first_edid_from_acpi_ddc(struct pci_dev *pdev) +{ + acpi_handle handle; + acpi_status status; + struct acpi_device *device = NULL; + struct edid *ret = NULL; + int num_dod_entries; + u64 *dod_entries = NULL; + struct list_head *node, *next; + + handle = ACPI_HANDLE(&pdev->dev); + if (handle == NULL) + return NULL; + + dod_entries = get_dod_entries(handle, &num_dod_entries); + if (dod_entries == NULL...

...180 /* Get the parent device */ 181 result = acpi_bus_get_device(phandle, &pdevice); 182 if (result) { 183 pr_warn(PREFIX "Cannot get acpi bus device\n"); 184 return -EINVAL; 185 } 186 187 /* 188 * Now add the notified device. This creates the acpi_device 189 * and invokes .add function 190 */ 191 result = acpi_bus_scan(handle); 192 if (result) { 193 pr_warn(PREFIX "Cannot add acpi bus\n"); 194 return -EINVAL; 195 } 196 197 end: 198 *mem_device = acpi_driver_data(device);...

...180 /* Get the parent device */ 181 result = acpi_bus_get_device(phandle, &pdevice); 182 if (result) { 183 pr_warn(PREFIX "Cannot get acpi bus device\n"); 184 return -EINVAL; 185 } 186 187 /* 188 * Now add the notified device. This creates the acpi_device 189 * and invokes .add function 190 */ 191 result = acpi_bus_scan(handle); 192 if (result) { 193 pr_warn(PREFIX "Cannot add acpi bus\n"); 194 return -EINVAL; 195 } 196 197 end: 198 *mem_device = acpi_driver_data(device);...

...re supporting Windows 8 or later do not use _DSM to put the device into > + * D3cold, they instead rely on disabling power resources on the parent. */ > +static bool nouveau_pr3_present(struct pci_dev *pdev) > +{ > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > + struct acpi_device *ad; Nit: please call this adev instead of ad. > + > + if (!parent_pdev) > + return false; > + > + ad = ACPI_COMPANION(&parent_pdev->dev); > + if (!ad) > + return false; > + > + return ad->power.flags.power_resources; Is this sufficient to tell if the paren...

...TNESS 0x87 -#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x88 -#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x89 #define MAX_NAME_LEN 20 diff --git a/include/acpi/video.h b/include/acpi/video.h index 4536bd3..bfe484d 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -30,6 +30,17 @@ struct acpi_device; #define ACPI_VIDEO_DISPLAY_LEGACY_PANEL 0x0110 #define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200 +#define ACPI_VIDEO_NOTIFY_SWITCH 0x80 +#define ACPI_VIDEO_NOTIFY_PROBE 0x81 +#define ACPI_VIDEO_NOTIFY_CYCLE 0x82 +#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83 +#define ACPI_VIDEO_NOTIFY_PREV...

...PARM_DESC(lid_notify_init_state, "Notify init lid state to kernel drivers after boot/resume"); /* -------------------------------------------------------------------------- FS Interface (/proc) @@ -224,6 +227,15 @@ static void acpi_lid_notify_state(struct acpi_device *device, if (state) pm_wakeup_event(&device->dev, 0); + if (!lid_notify_init_state) { + /* + * There are cases "state" is not a _LID return value, so + * correct it before notification. + */ + if (!bios_notify && + lid_init_state != ACPI_BUTTON_LID_INIT_...

...d, }; -/* - * Firmware supporting Windows 8 or later do not use _DSM to put the device into - * D3cold, they instead rely on disabling power resources on the parent. - */ -static bool nouveau_pr3_present(struct pci_dev *pdev) -{ - struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); - struct acpi_device *parent_adev; - - if (!parent_pdev) - return false; - - if (!parent_pdev->bridge_d3) { - /* - * Parent PCI bridge is currently not power managed. - * Since userspace can change these afterwards to be on - * the safe side we stick with _DSM and prevent usage of - * _PR3 from the bridge....

Some notebook systems provide the EDID for the internal panel via the _DDC method in ACPI, instead of or in addition to providing the EDID via DDC on LVDS/eDP. Add a DRM helper to search for an ACP _DDC method under the ACPI namespace for each VGA/3D controller, and return the first EDID successfully retrieved via _DDC. Update the i915, nouveau, and radeon DRM-KMS drivers to fall back to

...g Windows 8 or later do not use _DSM to put the device into > + * D3cold, they instead rely on disabling power resources on the parent. */ > +static bool nouveau_pr3_present(struct pci_dev *pdev) > +{ > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > + struct acpi_device *ad; > + > + if (!parent_pdev) > + return false; > + > + ad = ACPI_COMPANION(&parent_pdev->dev); > + if (!ad) > + return false; > + > + return ad->power.flags.power_resources; > +} > + > static void n...

...a->range_guid, 16) == 0) > + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le *)spa->range_guid)) > return i; > return -1; > } > @@ -1400,7 +1400,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc, > struct acpi_device *adev, *adev_dimm; > struct device *dev = acpi_desc->dev; > unsigned long dsm_mask; > - const u8 *uuid; > + const uuid_le *uuid = to_nfit_uuid(NFIT_DEV_DIMM); > int i; > int family = -1; > > @@ -1596,7 +1596,7 @@ static int acpi...

...o put the device into > > > + * D3cold, they instead rely on disabling power resources on the parent. */ > > > +static bool nouveau_pr3_present(struct pci_dev *pdev) > > > +{ > > > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > > > + struct acpi_device *ad; > > > > Nit: please call this adev instead of ad. > > Will do. > > > > + > > > + if (!parent_pdev) > > > + return false; > > > + > > > + ad = ACPI_COMPANION(&parent_pdev->dev); > > > + if (!ad) > > >...

...he device into >> > + * D3cold, they instead rely on disabling power resources on the parent. */ >> > +static bool nouveau_pr3_present(struct pci_dev *pdev) >> > +{ >> > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); >> > + struct acpi_device *ad; >> > + >> > + if (!parent_pdev) >> > + return false; >> > + >> > + ad = ACPI_COMPANION(&parent_pdev->dev); >> > + if (!ad) >> > + return false; >> > + >> > +...

Further cleanup of the vmbus driver: 1) Cleanup the interrupt handler by inlining some code. 2) Ensure message handling is performed on the same CPU that takes the vmbus interrupt. 3) Check for events before messages (from the host). 4) Disable auto eoi for the vmbus interrupt since Linux will eoi the interrupt anyway. 5) Some general cleanup. Regards, K. Y

Further cleanup of the vmbus driver: 1) Cleanup the interrupt handler by inlining some code. 2) Ensure message handling is performed on the same CPU that takes the vmbus interrupt. 3) Check for events before messages (from the host). 4) Disable auto eoi for the vmbus interrupt since Linux will eoi the interrupt anyway. 5) Some general cleanup. Regards, K. Y

...for (i = 0; i < NFIT_UUID_MAX; i++) - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0) + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le *)spa->range_guid)) return i; return -1; } @@ -1400,7 +1400,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc, struct acpi_device *adev, *adev_dimm; struct device *dev = acpi_desc->dev; unsigned long dsm_mask; - const u8 *uuid; + const uuid_le *uuid = to_nfit_uuid(NFIT_DEV_DIMM); int i; int family = -1; @@ -1596,7 +1596,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc) static void acpi_n...

...to that bug)? It should show if the ACPI core even tries to add those power resources. diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index fcd4ce6f78d5..af9c3e15dd74 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device *adev, bool add) if (!adev->power.flags.power_resources) return; + acpi_handle_info(adev->handle, "Adding power resources for %s\n", + dev_name(&adev->dev)); + for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++) acpi_power_expose_hide(adev,...

...e ACPI core even tries to add those > power resources. > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > index fcd4ce6f78d5..af9c3e15dd74 100644 > --- a/drivers/acpi/power.c > +++ b/drivers/acpi/power.c > @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device > *adev, bool add) > if (!adev->power.flags.power_resources) > return; > > + acpi_handle_info(adev->handle, "Adding power resources for %s\n", > + dev_name(&adev->dev)); > + > for (state = AC...