linux-stable/drivers/gpu/drm/drm_sysfs.c

595 lines
15 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* drm_sysfs.c - Modifications to drm_sysfs_class.c to support
* extra sysfs attribute from DRM. Normal drm_sysfs_class
* does not allow adding attributes.
*
* Copyright (c) 2004 Jon Smirl <jonsmirl@gmail.com>
* Copyright (c) 2003-2004 Greg Kroah-Hartman <greg@kroah.com>
* Copyright (c) 2003-2004 IBM Corp.
*/
#include <linux/acpi.h>
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
#include <linux/component.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/export.h>
#include <linux/gfp.h>
#include <linux/i2c.h>
#include <linux/kdev_t.h>
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
#include <linux/property.h>
#include <linux/slab.h>
#include <drm/drm_accel.h>
#include <drm/drm_connector.h>
#include <drm/drm_device.h>
#include <drm/drm_file.h>
#include <drm/drm_modes.h>
#include <drm/drm_print.h>
#include <drm/drm_property.h>
#include <drm/drm_sysfs.h>
#include "drm_internal.h"
#include "drm_crtc_internal.h"
#define to_drm_minor(d) dev_get_drvdata(d)
#define to_drm_connector(d) dev_get_drvdata(d)
/**
* DOC: overview
*
* DRM provides very little additional support to drivers for sysfs
* interactions, beyond just all the standard stuff. Drivers who want to expose
* additional sysfs properties and property groups can attach them at either
* &drm_device.dev or &drm_connector.kdev.
*
* Registration is automatically handled when calling drm_dev_register(), or
* drm_connector_register() in case of hot-plugged connectors. Unregistration is
* also automatically handled by drm_dev_unregister() and
* drm_connector_unregister().
*/
static struct device_type drm_sysfs_device_minor = {
.name = "drm_minor"
};
static struct device_type drm_sysfs_device_connector = {
.name = "drm_connector",
};
struct class *drm_class;
#ifdef CONFIG_ACPI
static bool drm_connector_acpi_bus_match(struct device *dev)
{
return dev->type == &drm_sysfs_device_connector;
}
static struct acpi_device *drm_connector_acpi_find_companion(struct device *dev)
{
struct drm_connector *connector = to_drm_connector(dev);
return to_acpi_device_node(connector->fwnode);
}
static struct acpi_bus_type drm_connector_acpi_bus = {
.name = "drm_connector",
.match = drm_connector_acpi_bus_match,
.find_companion = drm_connector_acpi_find_companion,
};
static void drm_sysfs_acpi_register(void)
{
register_acpi_bus_type(&drm_connector_acpi_bus);
}
static void drm_sysfs_acpi_unregister(void)
{
unregister_acpi_bus_type(&drm_connector_acpi_bus);
}
#else
static void drm_sysfs_acpi_register(void) { }
static void drm_sysfs_acpi_unregister(void) { }
#endif
driver core: make struct class.devnode() take a const * The devnode() in struct class should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jens Axboe <axboe@kernel.dk> Cc: Justin Sanders <justin@coraid.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com> Cc: Liam Mark <lmark@codeaurora.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: John Stultz <jstultz@google.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Sean Young <sean@mess.org> Cc: Frank Haverkamp <haver@linux.ibm.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Xie Yongji <xieyongji@bytedance.com> Cc: Gautam Dawar <gautam.dawar@xilinx.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Eli Cohen <elic@nvidia.com> Cc: Parav Pandit <parav@nvidia.com> Cc: Maxime Coquelin <maxime.coquelin@redhat.com> Cc: alsa-devel@alsa-project.org Cc: dri-devel@lists.freedesktop.org Cc: kvm@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-block@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Link: https://lore.kernel.org/r/20221123122523.1332370-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-23 12:25:20 +00:00
static char *drm_devnode(const struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
}
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
static int typec_connector_bind(struct device *dev,
struct device *typec_connector, void *data)
{
int ret;
ret = sysfs_create_link(&dev->kobj, &typec_connector->kobj, "typec_connector");
if (ret)
return ret;
ret = sysfs_create_link(&typec_connector->kobj, &dev->kobj, "drm_connector");
if (ret)
sysfs_remove_link(&dev->kobj, "typec_connector");
return ret;
}
static void typec_connector_unbind(struct device *dev,
struct device *typec_connector, void *data)
{
sysfs_remove_link(&typec_connector->kobj, "drm_connector");
sysfs_remove_link(&dev->kobj, "typec_connector");
}
static const struct component_ops typec_connector_ops = {
.bind = typec_connector_bind,
.unbind = typec_connector_unbind,
};
drm: drop obsolete drm_core.h The drm_core.h header contains a set of constants meant to be used throughout DRM. However, as it turns out, they're each used just once and don't bring any benefit. They're also grossly mis-named and lack name-spacing. This patch inlines them, or moves them into drm_internal.h as appropriate: - CORE_AUTHOR and CORE_DESC are inlined into corresponding MODULE_*() macros. It's just confusing having to follow 2 pointers when trying to find the definition of these fields. Grep'ping for MODULE_AUTHOR() should reveal the full information, if there's no strong reason not to. - CORE_NAME, CORE_DATE, CORE_MAJOR, CORE_MINOR, and CORE_PATCHLEVEL are inlined into the sysfs 'version' attribute. They're stripped everywhere else (which is just some printk() statements). CORE_NAME just doesn't make *any* sense, as we hard-code it in many places, anyway. The other constants are outdated and just serve binary-compatibility purposes. Hence, inline them in 'version' sysfs attribute (we might even try dropping it..). - DRM_IF_MAJOR and DRM_IF_MINOR are moved into drm_internal.h as they're only used by the global ioctl handlers. Furthermore, versioning interfaces breaks backports and as such is deprecated, anyway. We just keep them for historic reasons. I doubt anyone will ever modify them again. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-6-dh.herrmann@gmail.com
2016-09-01 12:48:36 +00:00
static CLASS_ATTR_STRING(version, S_IRUGO, "drm 1.1.0 20060810");
/**
* drm_sysfs_init - initialize sysfs helpers
*
* This is used to create the DRM class, which is the implicit parent of any
* other top-level DRM sysfs objects.
*
* You must call drm_sysfs_destroy() to release the allocated resources.
*
* Return: 0 on success, negative error code on failure.
*/
int drm_sysfs_init(void)
{
int err;
drm_class = class_create("drm");
if (IS_ERR(drm_class))
return PTR_ERR(drm_class);
err = class_create_file(drm_class, &class_attr_version.attr);
if (err) {
class_destroy(drm_class);
drm_class = NULL;
return err;
}
drm_class->devnode = drm_devnode;
drm_sysfs_acpi_register();
return 0;
}
/**
* drm_sysfs_destroy - destroys DRM class
*
* Destroy the DRM device class.
*/
void drm_sysfs_destroy(void)
{
if (IS_ERR_OR_NULL(drm_class))
return;
drm_sysfs_acpi_unregister();
class_remove_file(drm_class, &class_attr_version.attr);
class_destroy(drm_class);
drm_class = NULL;
}
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
}
/*
* Connector properties
*/
static ssize_t status_store(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
{
struct drm_connector *connector = to_drm_connector(device);
struct drm_device *dev = connector->dev;
enum drm_connector_force old_force;
drm: Hold the mode mutex whilst probing for sysfs status As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm] [ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-15 11:40:00 +00:00
int ret;
ret = mutex_lock_interruptible(&dev->mode_config.mutex);
drm: Hold the mode mutex whilst probing for sysfs status As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm] [ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-15 11:40:00 +00:00
if (ret)
return ret;
old_force = connector->force;
if (sysfs_streq(buf, "detect"))
connector->force = 0;
else if (sysfs_streq(buf, "on"))
connector->force = DRM_FORCE_ON;
else if (sysfs_streq(buf, "on-digital"))
connector->force = DRM_FORCE_ON_DIGITAL;
else if (sysfs_streq(buf, "off"))
connector->force = DRM_FORCE_OFF;
else
ret = -EINVAL;
if (old_force != connector->force || !connector->force) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force updated from %d to %d or reprobing\n",
connector->base.id,
connector->name,
old_force, connector->force);
connector->funcs->fill_modes(connector,
dev->mode_config.max_width,
dev->mode_config.max_height);
}
mutex_unlock(&dev->mode_config.mutex);
return ret ? ret : count;
}
static ssize_t status_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
enum drm_connector_status status;
status = READ_ONCE(connector->status);
drm: Hold the mode mutex whilst probing for sysfs status As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm] [ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-15 11:40:00 +00:00
return sysfs_emit(buf, "%s\n",
drm_get_connector_status_name(status));
}
static ssize_t dpms_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
int dpms;
dpms = READ_ONCE(connector->dpms);
return sysfs_emit(buf, "%s\n", drm_get_dpms_name(dpms));
}
static ssize_t enabled_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
bool enabled;
enabled = READ_ONCE(connector->encoder);
return sysfs_emit(buf, enabled ? "enabled\n" : "disabled\n");
}
static ssize_t edid_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf, loff_t off,
size_t count)
{
struct device *connector_dev = kobj_to_dev(kobj);
struct drm_connector *connector = to_drm_connector(connector_dev);
unsigned char *edid;
size_t size;
ssize_t ret = 0;
mutex_lock(&connector->dev->mode_config.mutex);
if (!connector->edid_blob_ptr)
goto unlock;
edid = connector->edid_blob_ptr->data;
size = connector->edid_blob_ptr->length;
if (!edid)
goto unlock;
if (off >= size)
goto unlock;
if (off + count > size)
count = size - off;
memcpy(buf, edid + off, count);
ret = count;
unlock:
mutex_unlock(&connector->dev->mode_config.mutex);
return ret;
}
static ssize_t modes_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
struct drm_display_mode *mode;
int written = 0;
mutex_lock(&connector->dev->mode_config.mutex);
list_for_each_entry(mode, &connector->modes, head) {
written += scnprintf(buf + written, PAGE_SIZE - written, "%s\n",
mode->name);
}
mutex_unlock(&connector->dev->mode_config.mutex);
return written;
}
drm/sysfs: Expose DRM connector id in each connector sysfs Expose DRM connector id in device sysfs so that we can map the connector id to the connector syspath. Currently, even if we can derive the connector id from modeset, we do not have a way to find the corresponding connector's syspath. This is helpful when determining the root connector of MST tree. When a tree of multiple MST hub is connected to the system, modeset describes the tree in the PATH blob. For example, consider the following scenario. +-------------+ | Source | +-------------+ | (Device) | | BranchX | | | | (MST) | | [conn6]--->| [port1]--->DisplayA +-------------+ | | | | +-------------+ | | | BranchY | | | | (MST) | | [port2]--->| [port1]----->DisplayB +-------------+ | | | [port2]----->DisplayC +-------------+ DPMST connector of DisplayA would have "mst:6-1" PATH. DPMST connector of DisplayB would have "mst:6-2-1" PATH. DPMST connector of DisplayC would have "mst:6-2-2" PATH. Given that connector id of 6 is the root of the MST connector tree, we can utilize this patch to parse through DRM connectors sysfs and find which connector syspath corresponds to the root connector (id == 6). ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays even with a MST hub. Chromium patch for parsing DRM connector id from the kernel is at http://crrev.com/c/4317207. Signed-off-by: Won Chung <wonchung@google.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230329014455.1990104-1-wonchung@google.com
2023-03-29 01:44:55 +00:00
static ssize_t connector_id_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
return sysfs_emit(buf, "%d\n", connector->base.id);
}
static DEVICE_ATTR_RW(status);
static DEVICE_ATTR_RO(enabled);
static DEVICE_ATTR_RO(dpms);
static DEVICE_ATTR_RO(modes);
drm/sysfs: Expose DRM connector id in each connector sysfs Expose DRM connector id in device sysfs so that we can map the connector id to the connector syspath. Currently, even if we can derive the connector id from modeset, we do not have a way to find the corresponding connector's syspath. This is helpful when determining the root connector of MST tree. When a tree of multiple MST hub is connected to the system, modeset describes the tree in the PATH blob. For example, consider the following scenario. +-------------+ | Source | +-------------+ | (Device) | | BranchX | | | | (MST) | | [conn6]--->| [port1]--->DisplayA +-------------+ | | | | +-------------+ | | | BranchY | | | | (MST) | | [port2]--->| [port1]----->DisplayB +-------------+ | | | [port2]----->DisplayC +-------------+ DPMST connector of DisplayA would have "mst:6-1" PATH. DPMST connector of DisplayB would have "mst:6-2-1" PATH. DPMST connector of DisplayC would have "mst:6-2-2" PATH. Given that connector id of 6 is the root of the MST connector tree, we can utilize this patch to parse through DRM connectors sysfs and find which connector syspath corresponds to the root connector (id == 6). ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays even with a MST hub. Chromium patch for parsing DRM connector id from the kernel is at http://crrev.com/c/4317207. Signed-off-by: Won Chung <wonchung@google.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230329014455.1990104-1-wonchung@google.com
2023-03-29 01:44:55 +00:00
static DEVICE_ATTR_RO(connector_id);
static struct attribute *connector_dev_attrs[] = {
&dev_attr_status.attr,
&dev_attr_enabled.attr,
&dev_attr_dpms.attr,
&dev_attr_modes.attr,
drm/sysfs: Expose DRM connector id in each connector sysfs Expose DRM connector id in device sysfs so that we can map the connector id to the connector syspath. Currently, even if we can derive the connector id from modeset, we do not have a way to find the corresponding connector's syspath. This is helpful when determining the root connector of MST tree. When a tree of multiple MST hub is connected to the system, modeset describes the tree in the PATH blob. For example, consider the following scenario. +-------------+ | Source | +-------------+ | (Device) | | BranchX | | | | (MST) | | [conn6]--->| [port1]--->DisplayA +-------------+ | | | | +-------------+ | | | BranchY | | | | (MST) | | [port2]--->| [port1]----->DisplayB +-------------+ | | | [port2]----->DisplayC +-------------+ DPMST connector of DisplayA would have "mst:6-1" PATH. DPMST connector of DisplayB would have "mst:6-2-1" PATH. DPMST connector of DisplayC would have "mst:6-2-2" PATH. Given that connector id of 6 is the root of the MST connector tree, we can utilize this patch to parse through DRM connectors sysfs and find which connector syspath corresponds to the root connector (id == 6). ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays even with a MST hub. Chromium patch for parsing DRM connector id from the kernel is at http://crrev.com/c/4317207. Signed-off-by: Won Chung <wonchung@google.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230329014455.1990104-1-wonchung@google.com
2023-03-29 01:44:55 +00:00
&dev_attr_connector_id.attr,
NULL
};
static struct bin_attribute edid_attr = {
.attr.name = "edid",
.attr.mode = 0444,
.size = 0,
.read = edid_show,
};
static struct bin_attribute *connector_bin_attrs[] = {
&edid_attr,
NULL
};
static const struct attribute_group connector_dev_group = {
.attrs = connector_dev_attrs,
.bin_attrs = connector_bin_attrs,
};
static const struct attribute_group *connector_dev_groups[] = {
&connector_dev_group,
NULL
};
int drm_sysfs_connector_add(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct device *kdev;
int r;
if (connector->kdev)
return 0;
kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
if (!kdev)
return -ENOMEM;
device_initialize(kdev);
kdev->class = drm_class;
kdev->type = &drm_sysfs_device_connector;
kdev->parent = dev->primary->kdev;
kdev->groups = connector_dev_groups;
kdev->release = drm_sysfs_release;
dev_set_drvdata(kdev, connector);
r = dev_set_name(kdev, "card%d-%s", dev->primary->index, connector->name);
if (r)
goto err_free;
DRM_DEBUG("adding \"%s\" to sysfs\n",
connector->name);
r = device_add(kdev);
if (r) {
drm_err(dev, "failed to register connector device: %d\n", r);
goto err_free;
}
connector->kdev = kdev;
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
if (dev_fwnode(kdev)) {
r = component_add(kdev, &typec_connector_ops);
if (r)
drm_err(dev, "failed to add component to create link to typec connector\n");
}
if (connector->ddc)
return sysfs_create_link(&connector->kdev->kobj,
&connector->ddc->dev.kobj, "ddc");
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
return 0;
err_free:
put_device(kdev);
return r;
}
void drm_sysfs_connector_remove(struct drm_connector *connector)
{
if (!connector->kdev)
return;
if (connector->ddc)
sysfs_remove_link(&connector->kdev->kobj, "ddc");
drm/sysfs: Link DRM connectors to corresponding Type-C connectors Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by: Won Chung <wonchung@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com
2023-04-27 16:58:13 +00:00
if (dev_fwnode(connector->kdev))
component_del(connector->kdev, &typec_connector_ops);
DRM_DEBUG("removing \"%s\" from sysfs\n",
connector->name);
device_unregister(connector->kdev);
connector->kdev = NULL;
}
void drm_sysfs_lease_event(struct drm_device *dev)
{
char *event_string = "LEASE=1";
char *envp[] = { event_string, NULL };
DRM_DEBUG("generating lease event\n");
kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
}
/**
* drm_sysfs_hotplug_event - generate a DRM uevent
* @dev: DRM device
*
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
*
* Any new uapi should be using the drm_sysfs_connector_status_event()
* for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
char *event_string = "HOTPLUG=1";
char *envp[] = { event_string, NULL };
DRM_DEBUG("generating hotplug event\n");
kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
/**
* drm_sysfs_connector_hotplug_event - generate a DRM uevent for any connector
* change
* @connector: connector which has changed
*
* Send a uevent for the DRM connector specified by @connector. This will send
* a uevent with the properties HOTPLUG=1 and CONNECTOR.
*/
void drm_sysfs_connector_hotplug_event(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
char hotplug_str[] = "HOTPLUG=1", conn_id[21];
char *envp[] = { hotplug_str, conn_id, NULL };
snprintf(conn_id, sizeof(conn_id),
"CONNECTOR=%u", connector->base.id);
drm_dbg_kms(connector->dev,
"[CONNECTOR:%d:%s] generating connector hotplug event\n",
connector->base.id, connector->name);
kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
}
EXPORT_SYMBOL(drm_sysfs_connector_hotplug_event);
/**
* drm_sysfs_connector_property_event - generate a DRM uevent for connector
* property change
* @connector: connector on which property changed
* @property: connector property which has changed.
*
* Send a uevent for the specified DRM connector and property. Currently we
* set HOTPLUG=1 and connector id along with the attached property id
* related to the change.
*/
void drm_sysfs_connector_property_event(struct drm_connector *connector,
struct drm_property *property)
{
struct drm_device *dev = connector->dev;
char hotplug_str[] = "HOTPLUG=1", conn_id[21], prop_id[21];
char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
property->base.id));
snprintf(conn_id, ARRAY_SIZE(conn_id),
"CONNECTOR=%u", connector->base.id);
snprintf(prop_id, ARRAY_SIZE(prop_id),
"PROPERTY=%u", property->base.id);
drm_dbg_kms(connector->dev,
"[CONNECTOR:%d:%s] generating connector property event for [PROP:%d:%s]\n",
connector->base.id, connector->name,
property->base.id, property->name);
kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
}
EXPORT_SYMBOL(drm_sysfs_connector_property_event);
struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
{
const char *minor_str;
struct device *kdev;
int r;
kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
if (!kdev)
return ERR_PTR(-ENOMEM);
device_initialize(kdev);
if (minor->type == DRM_MINOR_ACCEL) {
minor_str = "accel%d";
accel_set_device_instance_params(kdev, minor->index);
} else {
if (minor->type == DRM_MINOR_RENDER)
minor_str = "renderD%d";
else
minor_str = "card%d";
kdev->devt = MKDEV(DRM_MAJOR, minor->index);
kdev->class = drm_class;
kdev->type = &drm_sysfs_device_minor;
}
kdev->parent = minor->dev->dev;
kdev->release = drm_sysfs_release;
dev_set_drvdata(kdev, minor);
r = dev_set_name(kdev, minor_str, minor->index);
if (r < 0)
goto err_free;
return kdev;
err_free:
put_device(kdev);
return ERR_PTR(r);
}
/**
* drm_class_device_register - register new device with the DRM sysfs class
* @dev: device to register
*
* Registers a new &struct device within the DRM sysfs class. Essentially only
* used by ttm to have a place for its global settings. Drivers should never use
* this.
*/
int drm_class_device_register(struct device *dev)
{
if (!drm_class || IS_ERR(drm_class))
return -ENOENT;
dev->class = drm_class;
return device_register(dev);
}
EXPORT_SYMBOL_GPL(drm_class_device_register);
/**
* drm_class_device_unregister - unregister device with the DRM sysfs class
* @dev: device to unregister
*
* Unregisters a &struct device from the DRM sysfs class. Essentially only used
* by ttm to have a place for its global settings. Drivers should never use
* this.
*/
void drm_class_device_unregister(struct device *dev)
{
return device_unregister(dev);
}
EXPORT_SYMBOL_GPL(drm_class_device_unregister);