search for: num_dod_entri

...SS(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 || num_dod_entries == 0) + goto done; + + status = acpi_bus_g...

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

...f (ret)". > + list_for_each_safe(node, next, &device->children) { No, that's not safe because the ACPI namespace may change concurrently, e.g. because a DSDT patch is applied by the user via sysfs. Use acpi_walk_namespace() with a depth of 1 instead. > + for (i = 0; i < num_dod_entries; i++) { > + if (adr == dod_entries[i]) { > + ret = do_acpi_ddc(child->handle); > + > + if (ret != NULL) > + goto done; I guess ideally we'd want to correlate the display objects with drm_connectors or at least constrain the search to Display Type "Internal/...

...d your feedback into my local tree, but will wait for additional feedback from the individual DRM driver maintainers before sending out a series v2. On 8/8/20 5:11 PM, Lukas Wunner wrote: > On Mon, Jul 27, 2020 at 03:53:54PM -0500, Daniel Dadap wrote: >> + for (i = 0; i < num_dod_entries; i++) { >> + if (adr == dod_entries[i]) { >> + ret = do_acpi_ddc(child->handle); >> + >> + if (ret != NULL) >> + goto done; > I guess ideally we'...