Re: [PATCH 0/4] Track exported dma-buffers with memcg
On Wed, Jan 11, 2023 at 04:49:36PM -0800, T.J. Mercier wrote: > [...] > > The problem is a bit that with gpu allocations reclaim is essentially "we > > pass the error to userspace and they get to sort the mess out". There are > > some exceptions (some gpu drivers to have shrinkers) would we need to make > > sure these shrinkers are tied into the cgroup stuff before we could enable > > charging for them? > > > I'm also not sure that we can depend on the dmabuf being backed at > export time 100% of the time? (They are for dmabuf heaps.) If not, > that'd make calling the existing memcg folio based functions a bit > difficult. > Where does the actual memory get allocated? I see the first patch is updating the stat in dma_buf_export() and dma_buf_release(). Does the memory get allocated and freed in those code paths?
Re: [PATCH 0/4] Track exported dma-buffers with memcg
Am 12.01.23 um 09:13 schrieb Shakeel Butt: On Wed, Jan 11, 2023 at 04:49:36PM -0800, T.J. Mercier wrote: [...] The problem is a bit that with gpu allocations reclaim is essentially "we pass the error to userspace and they get to sort the mess out". There are some exceptions (some gpu drivers to have shrinkers) would we need to make sure these shrinkers are tied into the cgroup stuff before we could enable charging for them? I'm also not sure that we can depend on the dmabuf being backed at export time 100% of the time? (They are for dmabuf heaps.) If not, that'd make calling the existing memcg folio based functions a bit difficult. Where does the actual memory get allocated? I see the first patch is updating the stat in dma_buf_export() and dma_buf_release(). Does the memory get allocated and freed in those code paths? Nope, dma_buf_export() just makes the memory available to others. The driver which calls dma_buf_export() is the one allocating the memory. Regards, Christian.
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On Thu, Jan 12, 2023 at 1:50 PM Dmitry Baryshkov
wrote:
>
> On 12/01/2023 07:48, Pin-yen Lin wrote:
> > On Thu, Jan 12, 2023 at 1:24 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 12/01/2023 07:19, Pin-yen Lin wrote:
> >>> Hi Dmitry,
> >>>
> >>> Thanks for the review.
> >>>
> >>> On Thu, Jan 12, 2023 at 12:40 PM Dmitry Baryshkov
> >>> wrote:
>
> On 12/01/2023 06:20, Pin-yen Lin wrote:
> > Add helpers to register and unregister Type-C "switches" for bridges
> > capable of switching their output between two downstream devices.
> >
> > The helper registers USB Type-C mode switches when the "mode-switch"
> > and the "data-lanes" properties are available in Device Tree.
> >
> > Signed-off-by: Pin-yen Lin
> > Tested-by: Chen-Yu Tsai
> > Reviewed-by: Chen-Yu Tsai
> > Reviewed-by: AngeloGioacchino Del Regno
> >
> >
> > ---
> >
> > Changes in v10:
> > - Collected Reviewed-by and Tested-by tags
> > - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
> > - Print out the node name when errors on parsing DT
> > - Use dev_dbg instead of dev_warn when no Type-C switch nodes available
> > - Made the return path of drm_dp_register_mode_switch clearer
> >
> > Changes in v8:
> > - Fixed the build issue when CONFIG_TYPEC=m
> > - Fixed some style issues
> >
> > Changes in v7:
> > - Extracted the common codes to a helper function
> > - New in v7
> >
> > drivers/gpu/drm/display/drm_dp_helper.c | 134
> >
> > include/drm/display/drm_dp_helper.h | 17 +++
> > 2 files changed, 151 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index 16565a0a5da6..a2ec40a621cb 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -30,11 +30,13 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> > *panel, struct drm_dp_aux *aux)
> > EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
> >
> > #endif
> > +
> > +#if IS_REACHABLE(CONFIG_TYPEC)
> > +static int drm_dp_register_mode_switch(struct device *dev, struct
> > device_node *node,
> > +struct drm_dp_typec_switch_desc
> > *switch_desc,
> > +void *data, typec_mux_set_fn_t
> > mux_set)
> > +{
> > + struct drm_dp_typec_port_data *port_data;
> > + struct typec_mux_desc mux_desc = {};
> > + char name[32];
> > + u32 dp_lanes[2];
> > + int ret, num_lanes, port_num = -1;
> > +
> > + num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
>
> 2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
> >>>
> >>> This function is implemented for 4-lane DP bridges to switch its
> >>> outputs between 2 downstreams. So, I assume that there will only be at
> >>> most 2 lanes for each downstream. I don't think a 4-lane downstream
> >>> makes sense for mode switches unless we want to support bridges with
> >>> more than 4 lanes.
> >>
> >> Yes. However by using 4 here you'd make the helper generic and cover
> >> both your case and the generic case. We don't need this for the msm case
> >> (since the mux is handled by the PHY). But if not for the PHY, I'd have
> >> used such helper (with max_lanes = 4).
> >>
> > I wonder if simply using 4 here really makes it more generic here.
> > This function assumes the mapping between "data-lanes" and the port
> > number (e.g., 0/1 --> port 0) and hard-coded the way to parse the
> > property.
> >
> > Is it better to use "reg" instead of "data-lanes" to determine the
> > port number? The drivers can still read the DT node to get the
> > "data-lanes" property if they want to do some fancy stuffs around
> > that.
>
> Yes, I admit, this sounds more logical.
>
Thanks for the reply. I'll do that in v11.
>
> > + if (num_lanes <= 0) {
> > + dev_err(dev, "Error on getting data lanes count from %s:
> > %d\n",
> > + node->name, num_lanes);
> > + return num_lanes;
> > + }
> > +
> > + ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
> > num_lanes);
> > + if (ret) {
> > + dev_err(dev, "Failed to read the data-lanes variable from
> > %s: %d\n",
> > + node->name, ret);
> > + return ret;
> > + }
> > +
> > + port_num = dp_lanes[0] / 2;
> > +
> > +
[PATCH] drm/nouveau/mmu: Fix an UAF issue in NVKM
From: Xinghui Li
In nvkm_mem_new_host, the mem is be alloced. And mem->memory is
assigned to pmemory. During this process, the mem will be free if
the error occurs. But the *pmemory still points to the &mem->memory
which has been relased.Laterly, the nvkm_memory_unref will put the
memory which points to the pmemory again.So, we set the *pmemory to
NULL to avoid UAF issue.
Reported-by: loydlv
Signed-off-by: Xinghui Li
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c
index 92e363dbbc5a..ab30eb1fc0a3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c
@@ -185,6 +185,7 @@ nvkm_mem_new_host(struct nvkm_mmu *mmu, int type, u8 page,
u64 size,
} else
if ( (ret = nvif_unvers(ret, &argv, &argc, args->vn))) {
kfree(mem);
+ *pmemory = NULL;
return ret;
}
--
2.31.1
Re: [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
On 1/11/23 8:58 AM, Javier Martinez Canillas wrote:
Hello Daniel,
On 1/11/23 16:41, Daniel Vetter wrote:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
restore
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
symptoms
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
Maybe adding a Fixes: ee7a69aa38d8 tag here too ?
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
Maybe mention in the commit message that you are doing this change, something
like:
"Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting
devices, just call to aperture_detach_devices() to detach the device that
matches
the same PCI BAR / aperture range. Since the former is just a wrapper of the
latter
plus a sysfb_disable() call, and now that's done in this function but only for
the
primary devices"
Patch looks good to me:
Reviewed-by: Javier Martinez Canillas
Thanks Daniel and Javier!
I wasn't able to reproduce the original problem on my hybrid laptop
since it refuses to boot with the console on an external display, but I
was able to reproduce it by switching the configuration around: booting
with i915.modeset=0 and with an experimental version of nvidia-drm that
registers a framebuffer console. I verified that loading nvidia-drm
breaks the efi-firmware framebuffer on Intel on Arch's
linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So
Tested-by: Aaron Plattner
FWIW, the bug ought to be reproducible with i915.modeset=0 + any other
drm driver that registers a framebuffer.
-- Aaron
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On Thu, 12 Jan 2023, Pin-yen Lin wrote:
> Add helpers to register and unregister Type-C "switches" for bridges
> capable of switching their output between two downstream devices.
>
> The helper registers USB Type-C mode switches when the "mode-switch"
> and the "data-lanes" properties are available in Device Tree.
>
> Signed-off-by: Pin-yen Lin
> Tested-by: Chen-Yu Tsai
> Reviewed-by: Chen-Yu Tsai
> Reviewed-by: AngeloGioacchino Del Regno
>
>
> ---
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
> - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
> - Print out the node name when errors on parsing DT
> - Use dev_dbg instead of dev_warn when no Type-C switch nodes available
> - Made the return path of drm_dp_register_mode_switch clearer
>
> Changes in v8:
> - Fixed the build issue when CONFIG_TYPEC=m
> - Fixed some style issues
>
> Changes in v7:
> - Extracted the common codes to a helper function
> - New in v7
>
> drivers/gpu/drm/display/drm_dp_helper.c | 134
> include/drm/display/drm_dp_helper.h | 17 +++
> 2 files changed, 151 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 16565a0a5da6..a2ec40a621cb 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -30,11 +30,13 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> *panel, struct drm_dp_aux *aux)
> EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
>
> #endif
> +
> +#if IS_REACHABLE(CONFIG_TYPEC)
I think IS_REACHABLE() is a workaround for not getting the Kconfig
dependencies right. It allows configurations that silently just don't
work, instead of warning about it at config time. It fixes a build
issue, but trades it for an end user configuration issue that you don't
get any feedback about, and is hard to figure out. It's for people who
deal with build issues, but don't need to deal with user issues.
BR,
Jani.
> +static int drm_dp_register_mode_switch(struct device *dev, struct
> device_node *node,
> +struct drm_dp_typec_switch_desc
> *switch_desc,
> +void *data, typec_mux_set_fn_t mux_set)
> +{
> + struct drm_dp_typec_port_data *port_data;
> + struct typec_mux_desc mux_desc = {};
> + char name[32];
> + u32 dp_lanes[2];
> + int ret, num_lanes, port_num = -1;
> +
> + num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
> + if (num_lanes <= 0) {
> + dev_err(dev, "Error on getting data lanes count from %s: %d\n",
> + node->name, num_lanes);
> + return num_lanes;
> + }
> +
> + ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
> num_lanes);
> + if (ret) {
> + dev_err(dev, "Failed to read the data-lanes variable from %s:
> %d\n",
> + node->name, ret);
> + return ret;
> + }
> +
> + port_num = dp_lanes[0] / 2;
> +
> + port_data = &switch_desc->typec_ports[port_num];
> + port_data->data = data;
> + mux_desc.fwnode = &node->fwnode;
> + mux_desc.drvdata = port_data;
> + snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
> + mux_desc.name = name;
> + mux_desc.set = mux_set;
> +
> + port_data->typec_mux = typec_mux_register(dev, &mux_desc);
> + if (IS_ERR(port_data->typec_mux)) {
> + ret = PTR_ERR(port_data->typec_mux);
> + dev_err(dev, "Mode switch register for port %d failed: %d\n",
> + port_num, ret);
> +
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * drm_dp_register_typec_switches() - register Type-C switches
> + * @dev: Device that registers Type-C switches
> + * @port: Device node for the switch
> + * @switch_desc: A Type-C switch descriptor
> + * @data: Private data for the switches
> + * @mux_set: Callback function for typec_mux_set
> + *
> + * This function registers USB Type-C switches for DP bridges that can switch
> + * the output signal between their output pins.
> + *
> + * Currently only mode switches are implemented, and the function assumes the
> + * given @port device node has endpoints with "mode-switch" property.
> + * Register the endpoint as port 0 if the "data-lanes" property falls in 0/1,
> + * and register it as port 1 if "data-lanes" falls in 2/3.
> + */
> +int drm_dp_register_typec_switches(struct device *dev, struct device_node
> *port,
> +struct drm_dp_typec_switch_desc *switch_desc,
> +void *data, typec_mux_set_fn_t mux_set)
> +{
> + struct device_node *sw;
> + int ret;
> +
> + for_each_child_of_node(port, sw) {
> + if (
Re: [PATCH v2 12/13] drm/bridge: lt9611: stop filtering modes via the table
On 11/01/2023 16:37, Dmitry Baryshkov wrote:
On 11/01/2023 12:57, Neil Armstrong wrote:
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
The lt9611 bridge can support different modes, it makes no sense to list
them in the table. Drop the table and check the number of interfaces
using the fixed value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 41 +++--
1 file changed, 4 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 82af1f954cc6..df9f015aa3a0 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -84,24 +84,6 @@ static const struct regmap_config lt9611_regmap_config = {
.num_ranges = ARRAY_SIZE(lt9611_ranges),
};
-struct lt9611_mode {
- u16 hdisplay;
- u16 vdisplay;
- u8 vrefresh;
- u8 lanes;
- u8 intfs;
-};
-
-static struct lt9611_mode lt9611_modes[] = {
- { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
- { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
- { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
- { 1920, 1080, 24, 3, 1 },
- { 720, 480, 60, 4, 1 },
- { 720, 576, 50, 2, 1 },
- { 640, 480, 60, 2, 1 },
-};
-
static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
{
return container_of(bridge, struct lt9611, bridge);
@@ -603,21 +585,6 @@ static int lt9611_regulator_enable(struct lt9611 *lt9611)
return 0;
}
-static struct lt9611_mode *lt9611_find_mode(const struct drm_display_mode
*mode)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(lt9611_modes); i++) {
- if (lt9611_modes[i].hdisplay == mode->hdisplay &&
- lt9611_modes[i].vdisplay == mode->vdisplay &&
- lt9611_modes[i].vrefresh == drm_mode_vrefresh(mode)) {
- return <9611_modes[i];
- }
- }
-
- return NULL;
-}
-
static enum drm_connector_status lt9611_bridge_detect(struct drm_bridge
*bridge)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
@@ -832,12 +799,12 @@ static enum drm_mode_status
lt9611_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
const struct drm_display_mode *mode)
{
- struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
- if (!lt9611_mode)
- return MODE_BAD;
- else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
+ if (mode->hdisplay >= 3840 && drm_mode_vrefresh(mode) >= 31)
Isn't 31 a typo ?
Maybe I should change that to drm_mode_vrefresh(mode) > 30. The chip supports
3840x2160-30, but doesn't promise to support anything above that.
Yep >= 31 is valid, but > 30 seems more logical.
Concerning the hdisplay check, shouldn't be separate ?
You should switch to:
if (mode->hdisplay > 3840)
return MODE_BAD_WIDTH;
if (mode->hdisplay == 3840 && drm_mode_vrefresh(mode) > 30)
return MODE_CLOCK_HIGH;
Isn't there limits on vdisplay aswell ?
Neil
+ return MODE_CLOCK_HIGH;
+
+ if (mode->hdisplay > 2000 && !lt9611->dsi1_node)
return MODE_PANEL;
else
return MODE_OK;
Re: [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
On 1/12/23 08:55, Thomas Zimmermann wrote: [...] >> Thanks Daniel and Javier! >> >> I wasn't able to reproduce the original problem on my hybrid laptop >> since it refuses to boot with the console on an external display, but I >> was able to reproduce it by switching the configuration around: booting >> with i915.modeset=0 and with an experimental version of nvidia-drm that >> registers a framebuffer console. I verified that loading nvidia-drm > > Thank you for testing. > > One thing I'd like to note is that using DRM's fbdev emulation is the > correct way to support a console. Nvidia-drm's current approach of > utilizing efifb is fragile and requires workarounds from distributions > (at least here at SUSE). Steps towards fbdev emulation are much appreciated. > I was meaning to mention the same. Fedora also is carrying a workaround just for the Nvidia proprietary driver since all other drivers provide a emulated fbdev device. So getting this finally fixed will be indeed highly appreciated. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 01/13] drm/debugfs: Create helper to add debugfs files to device's list
On Wed, 11 Jan 2023, Maíra Canal wrote:
> Create a helper to encapsulate the code that adds a new debugfs file to
> a linked list related to a object. Moreover, the helper also provides
> more flexibily on the type of the object, allowing to use the helper for
> other types of drm_debugfs_entry.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/drm_debugfs.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 4f643a490dc3..255d2068ac16 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -316,6 +316,17 @@ void drm_debugfs_cleanup(struct drm_minor *minor)
> minor->debugfs_root = NULL;
> }
>
> +#define drm_debugfs_add_file_to_list(component) do { \
> + entry->file.name = name;\
> + entry->file.show = show;\
> + entry->file.data = data;\
> + entry->component = (component); \
> + \
> + mutex_lock(&(component)->debugfs_mutex);\
> + list_add(&entry->list, &(component)->debugfs_list); \
> + mutex_unlock(&(component)->debugfs_mutex); \
> + } while (0)
In general, please don't add macros that implicitly depend on certain
local variable names. In this case, "entry".
But I'm also not convinced about the usefulness of adding this kind of
"generics". Sure, it'll save you a few lines here and there, but I think
overall it's just confusing more than it's useful.
BR,
Jani.
> +
> /**
> * drm_debugfs_add_file - Add a given file to the DRM device debugfs file
> list
> * @dev: drm device for the ioctl
> @@ -334,14 +345,7 @@ void drm_debugfs_add_file(struct drm_device *dev, const
> char *name,
> if (!entry)
> return;
>
> - entry->file.name = name;
> - entry->file.show = show;
> - entry->file.data = data;
> - entry->dev = dev;
> -
> - mutex_lock(&dev->debugfs_mutex);
> - list_add(&entry->list, &dev->debugfs_list);
> - mutex_unlock(&dev->debugfs_mutex);
> + drm_debugfs_add_file_to_list(dev);
> }
> EXPORT_SYMBOL(drm_debugfs_add_file);
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
[Why]
Changes cause regression on amdgpu mst.
E.g.
In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
maintained payload table. But previous change tries to go through all the
payloads in mst_state and update amdpug hw maintained table in once everytime
driver only tries to add/remove a specific payload stream only. The newly
design idea conflicts with the implementation in amdgpu nowadays.
[How]
Revert this patch first. After addressing all regression problems caused by
this previous patch, will add it back and adjust it.
Signed-off-by: Wayne Lin
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Cc: sta...@vger.kernel.org # 6.1
Cc: Lyude Paul
Cc: Harry Wentland
Cc: Mario Limonciello
Cc: Ville Syrjälä
Cc: Ben Skeggs
Cc: Stanislav Lisovskiy
Cc: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 53 +-
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 87 ++-
.../amd/display/include/link_service_types.h | 3 -
drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
drivers/gpu/drm/i915/display/intel_dp_mst.c | 67 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 24 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 167 ++--
include/drm/display/drm_dp_mst_helper.h | 177 +++--
9 files changed, 878 insertions(+), 530 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 77277d90b6e2..674f5dc1102b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
const struct drm_display_mode *adjusted_mode =
&crtc_state->adjusted_mode;
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
- struct drm_dp_mst_topology_state *mst_state;
enum dc_color_depth color_depth;
int clock, bpp = 0;
bool is_y420 = false;
@@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
return 0;
- mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
- if (IS_ERR(mst_state))
- return PTR_ERR(mst_state);
-
- if (!mst_state->pbn_div)
- mst_state->pbn_div =
dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
-
if (!state->duplicated) {
int max_bpc = conn_state->max_requested_bpc;
is_y420 = drm_mode_is_420_also(&connector->display_info,
adjusted_mode) &&
@@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp,
false);
}
-
- dm_new_connector_state->vcpi_slots =
- drm_dp_atomic_find_time_slots(state, mst_mgr, mst_port,
- dm_new_connector_state->pbn);
+ dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_time_slots(state,
+
mst_mgr,
+
mst_port,
+
dm_new_connector_state->pbn,
+
dm_mst_get_pbn_divider(aconnector->dc_link));
if (dm_new_connector_state->vcpi_slots < 0) {
DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
(int)dm_new_connector_state->vcpi_slots);
return dm_new_connector_state->vcpi_slots;
@@ -6654,14 +6647,17 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
dm_conn_state->vcpi_slots = slot_num;
ret = drm_dp_mst_atomic_enable_dsc(state,
aconnector->port,
- dm_conn_state->pbn,
false);
+ dm_conn_state->pbn,
0, false);
if (ret < 0)
return ret;
continue;
}
- vcpi = drm_dp_mst_atomic_enable_dsc(state, aconnector->port,
pbn, true);
+ vcpi = drm_dp_mst_atomic_enable_dsc(state,
+ aconnector->port,
+ pbn, pbn_div,
+ true);
if (vcpi < 0)
return vcpi;
Re: [PATCH 02/13] drm/debugfs: Create helper to create debugfs files from list
On Wed, 11 Jan 2023, Maíra Canal wrote:
> Create a helper to encapsulate the code that creates a new debugfs file
> from a linked list related to an object. Moreover, the helper also provides
> more flexibily on the type of the object.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/drm_debugfs.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 255d2068ac16..23f6ed7b5d68 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -218,6 +218,16 @@ void drm_debugfs_create_files(const struct drm_info_list
> *files, int count,
> }
> EXPORT_SYMBOL(drm_debugfs_create_files);
>
> +#define drm_create_file_from_list(component) do {
> \
> + list_for_each_entry_safe(entry, tmp,
> &(component)->debugfs_list,\
> + list) {
> \
> + debugfs_create_file(entry->file.name, 0444,
> \
> + minor->debugfs_root, entry,
> \
> + &drm_debugfs_entry_fops);
> \
> + list_del(&entry->list);
> \
> + }
> \
> + } while (0)
> +
Same here as in the previous patch. I really think you should try to
figure out how to break this into useful functions, and avoid macros
like this.
BR,
Jani.
> int drm_debugfs_init(struct drm_minor *minor, int minor_id,
>struct dentry *root)
> {
> @@ -245,11 +255,7 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> if (dev->driver->debugfs_init)
> dev->driver->debugfs_init(minor);
>
> - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> - debugfs_create_file(entry->file.name, 0444,
> - minor->debugfs_root, entry,
> &drm_debugfs_entry_fops);
> - list_del(&entry->list);
> - }
> + drm_create_file_from_list(dev);
>
> return 0;
> }
> @@ -262,11 +268,7 @@ void drm_debugfs_late_register(struct drm_device *dev)
> if (!minor)
> return;
>
> - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> - debugfs_create_file(entry->file.name, 0444,
> - minor->debugfs_root, entry,
> &drm_debugfs_entry_fops);
> - list_del(&entry->list);
> - }
> + drm_create_file_from_list(dev);
> }
>
> int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 04/13] drm/debugfs: Create a debugfs infrastructure for encoders
On Wed, 11 Jan 2023, Maíra Canal wrote:
> Introduce the ability to add DRM debugfs files to a list managed by the
> encoder and, during drm_encoder_register_all(), all added files will be
> created at once.
>
> Moreover, introduce some typesafety as struct drm_debugfs_encoder_entry
> holds a drm_encoder instead of a drm_device. So, the drivers can get
> a encoder object directly from the struct drm_debugfs_encoder_entry
> in the show() callback.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/drm_debugfs.c | 36 ++
> drivers/gpu/drm/drm_encoder.c | 6 ++
> drivers/gpu/drm/drm_internal.h | 5 +
> include/drm/drm_debugfs.h | 26
> include/drm/drm_encoder.h | 15 ++
> 5 files changed, 88 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index d9ec1ed5a7ec..6a763fe1b031 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -271,6 +272,17 @@ void drm_debugfs_connector_init(struct drm_connector
> *connector)
> drm_create_file_from_list(connector);
> }
>
> +void drm_debugfs_encoder_init(struct drm_encoder *encoder)
> +{
> + struct drm_minor *minor = encoder->dev->primary;
> + struct drm_debugfs_encoder_entry *entry, *tmp;
> +
> + if (!minor)
> + return;
> +
> + drm_create_file_from_list(encoder);
> +}
Because of the macro, this just looks like entry and tmp are unused
local variables.
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 3a09682af685..38b73f2a4e38 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -182,6 +182,21 @@ struct drm_encoder {
>*/
> struct list_head bridge_chain;
>
> + /**
> + * @debugfs_mutex:
> + *
> + * Protects &debugfs_list access.
> + */
> + struct mutex debugfs_mutex;
> +
> + /**
> + * @debugfs_list:
> + *
> + * List of debugfs files to be created by the DRM encoder. The files
> + * must be added during drm_encoder_register_all().
> + */
> + struct list_head debugfs_list;
> +
If you added an additional struct wrapper for the above debugfs stuff
(and actually defined it in a drm debugfs header where it belongs), and
added that to encoder, connector, etc., you could pass a pointer to
*that* to the drm_debugfs_add_file_to_list() and
drm_create_file_from_list() proper functions.
Less boilerplate, nicer functions, debugfs stuff grouped together and
defined in the .[ch] they're used in.
I think that would be much nicer.
BR,
Jani.
> const struct drm_encoder_funcs *funcs;
> const struct drm_encoder_helper_funcs *helper_private;
> };
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
Hi Am 11.01.23 um 16:41 schrieb Daniel Vetter: This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there should not be any difference. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/gma500/psb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index cd9c73f5a64a..9b0daf90dc50 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we * might be able to read the framebuffer range from the device. */ - ret = drm_aperture_remove_framebuffers(true, &driver); + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver); This does not work. The comment just above the changed line explains why. The device uses shared memory similar to other integrated Intel chips. The console is somewhere in a 16 MiB range, which has been stolen by the BIOS from main memory. There's only a 1 MiB memory range on the device to program the device. Unless you want to refactor as described, this call has to cover the whole memory for now. Best regards Thomas if (ret) return ret; -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 03/13] drm/debugfs: Create a debugfs infrastructure for connectors
On Wed, 11 Jan 2023, Maíra Canal wrote:
> Introduce the ability to add DRM debugfs files to a list managed by the
> connector and, during drm_connector_register(), all added files will be
> created at once.
>
> Moreover, introduce some typesafety as struct drm_debugfs_connector_entry
> holds a drm_connector instead of a drm_device. So, the drivers can get
> a connector object directly from the struct drm_debugfs_connector_entry
> in the show() callback.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/drm_connector.c | 5 +
> drivers/gpu/drm/drm_debugfs.c | 35 +
> drivers/gpu/drm/drm_internal.h | 5 +
> include/drm/drm_connector.h | 15 ++
> include/drm/drm_debugfs.h | 26
> 5 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8d92777e57dd..c93655bb0edf 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -273,8 +273,10 @@ static int __drm_connector_init(struct drm_device *dev,
> INIT_LIST_HEAD(&connector->global_connector_list_entry);
> INIT_LIST_HEAD(&connector->probed_modes);
> INIT_LIST_HEAD(&connector->modes);
> + INIT_LIST_HEAD(&connector->debugfs_list);
> mutex_init(&connector->mutex);
> mutex_init(&connector->edid_override_mutex);
> + mutex_init(&connector->debugfs_mutex);
In another mail, I suggested adding a struct wrapper for debugfs_list
and debugfs_mutex. I think those should also be initialized by debugfs
code.
The initializer would not have to be connector/encoder/crtc specific, it
could be:
drm_debugfs_something_init(&connector->debugfs_something);
> connector->edid_blob_ptr = NULL;
> connector->epoch_counter = 0;
> connector->tile_blob_ptr = NULL;
> @@ -581,6 +583,7 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> connector->state);
>
> mutex_destroy(&connector->mutex);
> + mutex_destroy(&connector->debugfs_mutex);
Ditto for cleanup.
>
> memset(connector, 0, sizeof(*connector));
>
> @@ -627,6 +630,8 @@ int drm_connector_register(struct drm_connector
> *connector)
> goto err_debugfs;
> }
>
> + drm_debugfs_connector_init(connector);
Just perhaps this should be called _register()? The name gives a strong
feeling at which stage it is called, and the init here feels like it
should be moved earlier, to connector init, instead of connector
register.
> +
> drm_mode_object_register(connector->dev, &connector->base);
>
> connector->registration_state = DRM_CONNECTOR_REGISTERED;
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 23f6ed7b5d68..d9ec1ed5a7ec 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -260,6 +260,17 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> return 0;
> }
>
> +void drm_debugfs_connector_init(struct drm_connector *connector)
> +{
> + struct drm_minor *minor = connector->dev->primary;
> + struct drm_debugfs_connector_entry *entry, *tmp;
> +
> + if (!minor)
> + return;
> +
> + drm_create_file_from_list(connector);
> +}
> +
> void drm_debugfs_late_register(struct drm_device *dev)
> {
> struct drm_minor *minor = dev->primary;
> @@ -369,6 +380,30 @@ void drm_debugfs_add_files(struct drm_device *dev, const
> struct drm_debugfs_info
> }
> EXPORT_SYMBOL(drm_debugfs_add_files);
>
> +/**
> + * drm_debugfs_connector_add_file - Add a given file to the DRM connector
> debugfs file list
> + * @connector: DRM connector object
> + * @name: debugfs file name
> + * @show: show callback
> + * @data: driver-private data, should not be device-specific
> + *
> + * Add a given file entry to the DRM connector debugfs file list to be
> created on
> + * drm_debugfs_connector_init().
> + */
> +void drm_debugfs_connector_add_file(struct drm_connector *connector, const
> char *name,
> + int (*show)(struct seq_file*, void*), void
> *data)
> +{
> + struct drm_debugfs_connector_entry *entry = drmm_kzalloc(connector->dev,
> + sizeof(*entry),
> + GFP_KERNEL);
> +
> + if (!entry)
> + return;
> +
> + drm_debugfs_add_file_to_list(connector);
> +}
> +EXPORT_SYMBOL(drm_debugfs_connector_add_file);
> +
> static int connector_show(struct seq_file *m, void *data)
> {
> struct drm_connector *connector = m->private;
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index ed2103ee272c..dd9d7b8b45bd 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -185,6 +185,7 @@ int drm_gem_dumb_destroy(struct drm_file *
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
Hi Daniel, On Wed, 11 Jan 2023 22:47:02 +0100 Daniel Vetter wrote: > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > wrote: > > > > Hi Daniel, > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > Daniel Vetter wrote: > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > Hi Jason, > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > Jason Ekstrand wrote: > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > wrote: > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote: > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to have > > > > > > > > > > a 1 to 1 > > > > > > > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. > > > > > > > > > > At first > > > > > > this > > > > > > > > > > seems a bit odd but let us explain the reasoning below. > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > guaranteed to be the same completion even if targeting the > > > > > > > > > > same > > > > > > hardware > > > > > > > > > > engine. This is because in XE we have a firmware scheduler, > > > > > > > > > > the > > > > > > GuC, > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > submissions. If a > > > > > > using > > > > > > > > > > shared drm_gpu_scheduler across multiple drm_sched_entity, > > > > > > > > > > the TDR > > > > > > falls > > > > > > > > > > apart as the TDR expects submission order == completion > > > > > > > > > > order. > > > > > > Using a > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this > > > > > > > > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the same > > > > > > > > > sort of > > > > > > > > > issues to support Arm's new Mali GPU which is relying on a > > > > > > FW-assisted > > > > > > > > > scheduling scheme (you give the FW N streams to execute, and > > > > > > > > > it does > > > > > > > > > the scheduling between those N command streams, the kernel > > > > > > > > > driver > > > > > > > > > does timeslice scheduling to update the command streams > > > > > > > > > passed to the > > > > > > > > > FW). I must admit I gave up on using drm_sched at some point, > > > > > > > > > mostly > > > > > > > > > because the integration with drm_sched was painful, but also > > > > > > > > > because > > > > > > I > > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > > timeslice-oriented scheduling model wasn't really future > > > > > > > > > proof. > > > > > > Giving > > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler > > > > > > > > > probably > > > > > > might > > > > > > > > > help for a few things (didn't think it through yet), but I > > > > > > > > > feel it's > > > > > > > > > coming short on other aspects we have to deal with on Arm > > > > > > > > > GPUs. > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, and I > > > > > > > > think I > > > > > > > > have a better understanding of how you get away with using > > > > > > > > drm_sched > > > > > > > > while still controlling how scheduling is really done. Here > > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you use > > > > > > > > the > > > > > > > > drm_sched job queuing/dep/tracking mechanism. The whole > > > > > > > > run-queue > > > > > > > > > > > > You nailed it here, we use the DRM scheduler for queuing jobs, > > > > > > dependency tracking and releasing jobs to be scheduled when > > > > > > dependencies > > > > > > are met, and lastly a tracking mechanism of inflights jobs that > > > > > > need to > > > > > > be cleaned up if an error occurs. It doesn't actually do any > > > > > > scheduling > > > > > > aside from the most basic level of not overflowing the submission > > > > > > ring > > > > > > buffer. In this sense, a 1 to 1 relationship between entity and > > > > > > scheduler fits quite well. > > > > > > > > > > > > > > > > Yeah, I think there's an annoying difference between what > > > > > AMD/NVIDIA/Intel > > > > > want here and what you need for Arm thanks to the number of FW queues > > > > > available. I don't remember the exact number of GuC queues but it's at > > > > > least 1k. This puts it in an entirely different class from what you > > > > > have
Re: [PATCH 01/13] drm/debugfs: Create helper to add debugfs files to device's list
On Thu, Jan 12, 2023 at 10:50:40AM +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2023, Maíra Canal wrote:
> > Create a helper to encapsulate the code that adds a new debugfs file to
> > a linked list related to a object. Moreover, the helper also provides
> > more flexibily on the type of the object, allowing to use the helper for
> > other types of drm_debugfs_entry.
> >
> > Signed-off-by: Maíra Canal
> > ---
> > drivers/gpu/drm/drm_debugfs.c | 20
> > 1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> > index 4f643a490dc3..255d2068ac16 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -316,6 +316,17 @@ void drm_debugfs_cleanup(struct drm_minor *minor)
> > minor->debugfs_root = NULL;
> > }
> >
> > +#define drm_debugfs_add_file_to_list(component) do {
> > \
> > + entry->file.name = name;\
> > + entry->file.show = show;\
> > + entry->file.data = data;\
> > + entry->component = (component); \
> > + \
> > + mutex_lock(&(component)->debugfs_mutex);\
> > + list_add(&entry->list, &(component)->debugfs_list); \
> > + mutex_unlock(&(component)->debugfs_mutex); \
> > + } while (0)
>
> In general, please don't add macros that implicitly depend on certain
> local variable names. In this case, "entry".
>
> But I'm also not convinced about the usefulness of adding this kind of
> "generics". Sure, it'll save you a few lines here and there, but I think
> overall it's just confusing more than it's useful.
So the non-generics way I guess would be to
- pass the right pointer to the functions as an explicit parameter (struct
drm_device|crtc|connector *, )
- make drm_debugfs_entry and implementation detail
- switch the pointer in there to void *, have glue show functions for each
case which do nothing else than cast from void * to the right type
(both for the parameter and the function pointer)
- have a single function which takes that void *entry list and a pointer
to the debugfs director to add them all for code sharing
I think this should work for ->show, but for ->fops it becomes a rather
big mess I fear. Maybe for ->fops (and also for ->show for now) we leave
the explicit parameter out and just rely on seq_file->private or whatever
it was.
Or just copypaste, it's not that much code really :-)
-Daniel
>
>
> BR,
> Jani.
>
> > +
> > /**
> > * drm_debugfs_add_file - Add a given file to the DRM device debugfs file
> > list
> > * @dev: drm device for the ioctl
> > @@ -334,14 +345,7 @@ void drm_debugfs_add_file(struct drm_device *dev,
> > const char *name,
> > if (!entry)
> > return;
> >
> > - entry->file.name = name;
> > - entry->file.show = show;
> > - entry->file.data = data;
> > - entry->dev = dev;
> > -
> > - mutex_lock(&dev->debugfs_mutex);
> > - list_add(&entry->list, &dev->debugfs_list);
> > - mutex_unlock(&dev->debugfs_mutex);
> > + drm_debugfs_add_file_to_list(dev);
> > }
> > EXPORT_SYMBOL(drm_debugfs_add_file);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/vc4: bo: Fix drmm_mutex_init memory hog
Commit 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") converted,
among other functions, vc4_create_object() to use drmm_mutex_init().
However, that function is used to allocate a BO, and therefore the
mutex needs to be freed much sooner than when the DRM device is removed
from the system.
For each buffer allocation we thus end up allocating a small structure
as part of the DRM-managed mechanism that is never freed, eventually
leading us to no longer having any free memory anymore.
Let's switch back to mutex_init/mutex_destroy to deal with it properly.
Fixes: 374146cad469 ("drm/vc4: Switch to drmm_mutex_init")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index c2b7573bd92b..49320e4d595d 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -179,6 +179,7 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
bo->validated_shader = NULL;
}
+ mutex_destroy(&bo->madv_lock);
drm_gem_dma_free(&bo->base);
}
@@ -406,9 +407,7 @@ struct drm_gem_object *vc4_create_object(struct drm_device
*dev, size_t size)
bo->madv = VC4_MADV_WILLNEED;
refcount_set(&bo->usecnt, 0);
- ret = drmm_mutex_init(dev, &bo->madv_lock);
- if (ret)
- return ERR_PTR(ret);
+ mutex_init(&bo->madv_lock);
mutex_lock(&vc4->bo_lock);
bo->label = VC4_BO_TYPE_KERNEL;
--
2.39.0
Re: [PATCH 03/13] drm/debugfs: Create a debugfs infrastructure for connectors
On Wed, Jan 11, 2023 at 02:37:38PM -0300, Maíra Canal wrote:
> Introduce the ability to add DRM debugfs files to a list managed by the
> connector and, during drm_connector_register(), all added files will be
> created at once.
>
> Moreover, introduce some typesafety as struct drm_debugfs_connector_entry
> holds a drm_connector instead of a drm_device. So, the drivers can get
> a connector object directly from the struct drm_debugfs_connector_entry
> in the show() callback.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/drm_connector.c | 5 +
> drivers/gpu/drm/drm_debugfs.c | 35 +
> drivers/gpu/drm/drm_internal.h | 5 +
> include/drm/drm_connector.h | 15 ++
> include/drm/drm_debugfs.h | 26
> 5 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8d92777e57dd..c93655bb0edf 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -273,8 +273,10 @@ static int __drm_connector_init(struct drm_device *dev,
> INIT_LIST_HEAD(&connector->global_connector_list_entry);
> INIT_LIST_HEAD(&connector->probed_modes);
> INIT_LIST_HEAD(&connector->modes);
> + INIT_LIST_HEAD(&connector->debugfs_list);
> mutex_init(&connector->mutex);
> mutex_init(&connector->edid_override_mutex);
> + mutex_init(&connector->debugfs_mutex);
> connector->edid_blob_ptr = NULL;
> connector->epoch_counter = 0;
> connector->tile_blob_ptr = NULL;
> @@ -581,6 +583,7 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> connector->state);
>
> mutex_destroy(&connector->mutex);
> + mutex_destroy(&connector->debugfs_mutex);
>
> memset(connector, 0, sizeof(*connector));
>
> @@ -627,6 +630,8 @@ int drm_connector_register(struct drm_connector
> *connector)
> goto err_debugfs;
> }
>
> + drm_debugfs_connector_init(connector);
> +
> drm_mode_object_register(connector->dev, &connector->base);
>
> connector->registration_state = DRM_CONNECTOR_REGISTERED;
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 23f6ed7b5d68..d9ec1ed5a7ec 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -260,6 +260,17 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> return 0;
> }
>
> +void drm_debugfs_connector_init(struct drm_connector *connector)
> +{
> + struct drm_minor *minor = connector->dev->primary;
> + struct drm_debugfs_connector_entry *entry, *tmp;
> +
> + if (!minor)
> + return;
> +
> + drm_create_file_from_list(connector);
> +}
> +
> void drm_debugfs_late_register(struct drm_device *dev)
> {
> struct drm_minor *minor = dev->primary;
> @@ -369,6 +380,30 @@ void drm_debugfs_add_files(struct drm_device *dev, const
> struct drm_debugfs_info
> }
> EXPORT_SYMBOL(drm_debugfs_add_files);
>
> +/**
> + * drm_debugfs_connector_add_file - Add a given file to the DRM connector
> debugfs file list
> + * @connector: DRM connector object
> + * @name: debugfs file name
> + * @show: show callback
> + * @data: driver-private data, should not be device-specific
> + *
> + * Add a given file entry to the DRM connector debugfs file list to be
> created on
> + * drm_debugfs_connector_init().
> + */
> +void drm_debugfs_connector_add_file(struct drm_connector *connector, const
> char *name,
> + int (*show)(struct seq_file*, void*), void
> *data)
> +{
> + struct drm_debugfs_connector_entry *entry = drmm_kzalloc(connector->dev,
> + sizeof(*entry),
> + GFP_KERNEL);
> +
> + if (!entry)
> + return;
> +
> + drm_debugfs_add_file_to_list(connector);
> +}
> +EXPORT_SYMBOL(drm_debugfs_connector_add_file);
> +
> static int connector_show(struct seq_file *m, void *data)
> {
> struct drm_connector *connector = m->private;
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index ed2103ee272c..dd9d7b8b45bd 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -185,6 +185,7 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
> drm_device *dev,
> #if defined(CONFIG_DEBUG_FS)
> int drm_debugfs_init(struct drm_minor *minor, int minor_id,
>struct dentry *root);
> +void drm_debugfs_connector_init(struct drm_connector *connector);
> void drm_debugfs_cleanup(struct drm_minor *minor);
> void drm_debugfs_late_register(struct drm_device *dev);
> void drm_debugfs_connector_add(struct drm_connector *connector);
> @@ -199,6 +200,10 @@ static inline int drm_debugfs_init(struct drm_minor
> *minor, int minor_
Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
On Thu, Jan 12, 2023 at 08:17:19AM +0100, Gerd Hoffmann wrote: > Hi, > > > > > I think we need to do a bit of refactoring/documenting here first. > > > [Kasireddy, Vivek] Just for reference, here is Dave's commit that added > > > this > > > property for qxl: > > > commit 4695b03970df378dcb93fe3e7158381f1e980fa2 > > > Author: Dave Airlie > > > Date: Fri Oct 11 11:05:00 2013 +1000 > > > > > > qxl: add a connector property to denote hotplug should rescan modes. > > > > > > So GNOME userspace has an issue with when it rescans for modes on > > > hotplug > > > events, if the monitor has no EDID it assumes that nothing has > > > changed on > > > EDID as with real hw we'd never have new modes without a new EDID, > > > and they > > > kind off rely on the behaviour now, however with virtual GPUs we would > > > like to rescan the modes and get a new preferred mode on hotplug > > > events > > > to handle dynamic guest resizing (where you resize the host window > > > and the > > > guest resizes with it). > > > > Ok this is just terrible. Because _anything_ without an EDID is impacted, > > and we're certainly not going to sprinkle this property all over gpu > > drivers just so Gnome takes the right path. > > Oh, and (newer) virtio-gpu actually has EDIDs ... I forgot to mention. If userspace is worried about the expensive probe cycle that calling the GETCONNECTOR ioctl can cause. There's drmModeGetConnectorCurrent. But that's not guaranteed to give you up to date info after a hotplug event, depending upon driver :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 12/13] drm/bridge: lt9611: stop filtering modes via the table
On 12/01/2023 10:43, neil.armstr...@linaro.org wrote:
On 11/01/2023 16:37, Dmitry Baryshkov wrote:
On 11/01/2023 12:57, Neil Armstrong wrote:
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
The lt9611 bridge can support different modes, it makes no sense to
list
them in the table. Drop the table and check the number of interfaces
using the fixed value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 41
+++--
1 file changed, 4 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 82af1f954cc6..df9f015aa3a0 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -84,24 +84,6 @@ static const struct regmap_config
lt9611_regmap_config = {
.num_ranges = ARRAY_SIZE(lt9611_ranges),
};
-struct lt9611_mode {
- u16 hdisplay;
- u16 vdisplay;
- u8 vrefresh;
- u8 lanes;
- u8 intfs;
-};
-
-static struct lt9611_mode lt9611_modes[] = {
- { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
- { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
- { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
- { 1920, 1080, 24, 3, 1 },
- { 720, 480, 60, 4, 1 },
- { 720, 576, 50, 2, 1 },
- { 640, 480, 60, 2, 1 },
-};
-
static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
{
return container_of(bridge, struct lt9611, bridge);
@@ -603,21 +585,6 @@ static int lt9611_regulator_enable(struct
lt9611 *lt9611)
return 0;
}
-static struct lt9611_mode *lt9611_find_mode(const struct
drm_display_mode *mode)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(lt9611_modes); i++) {
- if (lt9611_modes[i].hdisplay == mode->hdisplay &&
- lt9611_modes[i].vdisplay == mode->vdisplay &&
- lt9611_modes[i].vrefresh == drm_mode_vrefresh(mode)) {
- return <9611_modes[i];
- }
- }
-
- return NULL;
-}
-
static enum drm_connector_status lt9611_bridge_detect(struct
drm_bridge *bridge)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
@@ -832,12 +799,12 @@ static enum drm_mode_status
lt9611_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
const struct drm_display_mode *mode)
{
- struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
- if (!lt9611_mode)
- return MODE_BAD;
- else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
+ if (mode->hdisplay >= 3840 && drm_mode_vrefresh(mode) >= 31)
Isn't 31 a typo ?
Maybe I should change that to drm_mode_vrefresh(mode) > 30. The chip
supports 3840x2160-30, but doesn't promise to support anything above
that.
Yep >= 31 is valid, but > 30 seems more logical.
Concerning the hdisplay check, shouldn't be separate ?
You should switch to:
if (mode->hdisplay > 3840)
return MODE_BAD_WIDTH;
if (mode->hdisplay == 3840 && drm_mode_vrefresh(mode) > 30)
return MODE_CLOCK_HIGH;
Good idea, I'll adapt it for v3.
Isn't there limits on vdisplay aswell ?
I don't see any special limit in the datasheet. HDMI 1.4, 4k@30, that's
all. I think I'll just add vdisply > 2160 check next to hdisplay.
Neil
+ return MODE_CLOCK_HIGH;
+
+ if (mode->hdisplay > 2000 && !lt9611->dsi1_node)
return MODE_PANEL;
else
return MODE_OK;
--
With best wishes
Dmitry
Re: [PATCH 07/13] drm/vc4: Use the encoders' debugfs infrastructure
On Wed, 11 Jan 2023, Maíra Canal wrote:
> Replace the use of drm_debugfs_add_files() with the new
> drm_debugfs_encoder_add_files() function, which centers the debugfs files
> management on the drm_encoder instead of drm_device. Using this function
> on late register callbacks is more adequate as the callback passes a
> drm_encoder as parameter.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vc4/vc4_debugfs.c | 17 +
> drivers/gpu/drm/vc4/vc4_dpi.c | 3 +--
> drivers/gpu/drm/vc4/vc4_drv.h | 8
> drivers/gpu/drm/vc4/vc4_dsi.c | 3 +--
> drivers/gpu/drm/vc4/vc4_hdmi.c| 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 3 +--
> 6 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c
> b/drivers/gpu/drm/vc4/vc4_debugfs.c
> index 80afc69200f0..c71e4d6ec4c4 100644
> --- a/drivers/gpu/drm/vc4/vc4_debugfs.c
> +++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
> @@ -57,9 +57,26 @@ static int vc4_debugfs_dev_regset32(struct seq_file *m,
> void *unused)
> return vc4_debugfs_regset32(drm, regset, &p);
> }
>
> +static int vc4_debugfs_encoder_regset32(struct seq_file *m, void *unused)
> +{
> + struct drm_debugfs_encoder_entry *entry = m->private;
> + struct drm_device *drm = entry->encoder->dev;
Feels like struct drm_debugfs_encoder_entry should be an implementation
detail. Maybe add helpers to get the encoder/connector/etc pointer, and
keep struct drm_debugfs_encoder_entry internal to the debugfs
implementation?
struct drm_device *drm = drm_debugfs_something_encoder(m->private)->dev;
However, even cooler would be if we could have the debugfs code wrap the
calls, and you could have:
static int vc4_debugfs_encoder_regset32(struct drm_encoder *encoder);
struct drm_debugfs_encoder_entry could have a function pointer for the
above, and there'd be a simple wrapper in debugfs code:
static int encoder_debugfs_show(struct seq_file *m, void *unused)
{
struct drm_debugfs_encoder_entry *entry = m->private;
struct drm_encoder *encoder = entry->encoder;
return entry->show(encoder);
}
drm_debugfs_encoder_add_file() would fill in entry->show, and add that
as the show function for core debugfs code.
Ditto for connector/crtc/etc.
This would make all of the drm debugfs functions so much nicer.
BR,
Jani.
> + struct debugfs_regset32 *regset = entry->file.data;
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + return vc4_debugfs_regset32(drm, regset, &p);
> +}
> +
> void vc4_debugfs_add_regset32(struct drm_device *drm,
> const char *name,
> struct debugfs_regset32 *regset)
> {
> drm_debugfs_add_file(drm, name, vc4_debugfs_dev_regset32, regset);
> }
> +
> +void vc4_debugfs_encoder_add_regset32(struct drm_encoder *encoder,
> + const char *name,
> + struct debugfs_regset32 *regset)
> +{
> + drm_debugfs_encoder_add_file(encoder, name,
> vc4_debugfs_encoder_regset32, regset);
> +}
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index f518d6e59ed6..084f7825dfa4 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -265,10 +265,9 @@ static const struct drm_encoder_helper_funcs
> vc4_dpi_encoder_helper_funcs = {
>
> static int vc4_dpi_late_register(struct drm_encoder *encoder)
> {
> - struct drm_device *drm = encoder->dev;
> struct vc4_dpi *dpi = to_vc4_dpi(encoder);
>
> - vc4_debugfs_add_regset32(drm, "dpi_regs", &dpi->regset);
> + vc4_debugfs_encoder_add_regset32(encoder, "dpi_regs", &dpi->regset);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 95069bb16821..8aaa8d00bc45 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -969,12 +969,20 @@ void vc4_debugfs_init(struct drm_minor *minor);
> void vc4_debugfs_add_regset32(struct drm_device *drm,
> const char *filename,
> struct debugfs_regset32 *regset);
> +void vc4_debugfs_encoder_add_regset32(struct drm_encoder *encoder,
> + const char *name,
> + struct debugfs_regset32 *regset);
> #else
>
> static inline void vc4_debugfs_add_regset32(struct drm_device *drm,
> const char *filename,
> struct debugfs_regset32 *regset)
> {}
> +
> +static inline void vc4_debugfs_encoder_add_regset32(struct drm_encoder
> *encoder,
> + const char *name,
> + struct debugfs_regset32
> *regset)
> +{}
> #endif
>
> /* vc4_drv.c */
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index
Re: [PATCH 03/13] drm/debugfs: Create a debugfs infrastructure for connectors
On Thu, 12 Jan 2023, Daniel Vetter wrote:
> On Wed, Jan 11, 2023 at 02:37:38PM -0300, Maíra Canal wrote:
>> Introduce the ability to add DRM debugfs files to a list managed by the
>> connector and, during drm_connector_register(), all added files will be
>> created at once.
>>
>> Moreover, introduce some typesafety as struct drm_debugfs_connector_entry
>> holds a drm_connector instead of a drm_device. So, the drivers can get
>> a connector object directly from the struct drm_debugfs_connector_entry
>> in the show() callback.
>>
>> Signed-off-by: Maíra Canal
>> ---
>> drivers/gpu/drm/drm_connector.c | 5 +
>> drivers/gpu/drm/drm_debugfs.c | 35 +
>> drivers/gpu/drm/drm_internal.h | 5 +
>> include/drm/drm_connector.h | 15 ++
>> include/drm/drm_debugfs.h | 26
>> 5 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index 8d92777e57dd..c93655bb0edf 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -273,8 +273,10 @@ static int __drm_connector_init(struct drm_device *dev,
>> INIT_LIST_HEAD(&connector->global_connector_list_entry);
>> INIT_LIST_HEAD(&connector->probed_modes);
>> INIT_LIST_HEAD(&connector->modes);
>> +INIT_LIST_HEAD(&connector->debugfs_list);
>> mutex_init(&connector->mutex);
>> mutex_init(&connector->edid_override_mutex);
>> +mutex_init(&connector->debugfs_mutex);
>> connector->edid_blob_ptr = NULL;
>> connector->epoch_counter = 0;
>> connector->tile_blob_ptr = NULL;
>> @@ -581,6 +583,7 @@ void drm_connector_cleanup(struct drm_connector
>> *connector)
>> connector->state);
>>
>> mutex_destroy(&connector->mutex);
>> +mutex_destroy(&connector->debugfs_mutex);
>>
>> memset(connector, 0, sizeof(*connector));
>>
>> @@ -627,6 +630,8 @@ int drm_connector_register(struct drm_connector
>> *connector)
>> goto err_debugfs;
>> }
>>
>> +drm_debugfs_connector_init(connector);
>> +
>> drm_mode_object_register(connector->dev, &connector->base);
>>
>> connector->registration_state = DRM_CONNECTOR_REGISTERED;
>> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
>> index 23f6ed7b5d68..d9ec1ed5a7ec 100644
>> --- a/drivers/gpu/drm/drm_debugfs.c
>> +++ b/drivers/gpu/drm/drm_debugfs.c
>> @@ -260,6 +260,17 @@ int drm_debugfs_init(struct drm_minor *minor, int
>> minor_id,
>> return 0;
>> }
>>
>> +void drm_debugfs_connector_init(struct drm_connector *connector)
>> +{
>> +struct drm_minor *minor = connector->dev->primary;
>> +struct drm_debugfs_connector_entry *entry, *tmp;
>> +
>> +if (!minor)
>> +return;
>> +
>> +drm_create_file_from_list(connector);
>> +}
>> +
>> void drm_debugfs_late_register(struct drm_device *dev)
>> {
>> struct drm_minor *minor = dev->primary;
>> @@ -369,6 +380,30 @@ void drm_debugfs_add_files(struct drm_device *dev,
>> const struct drm_debugfs_info
>> }
>> EXPORT_SYMBOL(drm_debugfs_add_files);
>>
>> +/**
>> + * drm_debugfs_connector_add_file - Add a given file to the DRM connector
>> debugfs file list
>> + * @connector: DRM connector object
>> + * @name: debugfs file name
>> + * @show: show callback
>> + * @data: driver-private data, should not be device-specific
>> + *
>> + * Add a given file entry to the DRM connector debugfs file list to be
>> created on
>> + * drm_debugfs_connector_init().
>> + */
>> +void drm_debugfs_connector_add_file(struct drm_connector *connector, const
>> char *name,
>> +int (*show)(struct seq_file*, void*), void
>> *data)
>> +{
>> +struct drm_debugfs_connector_entry *entry = drmm_kzalloc(connector->dev,
>> + sizeof(*entry),
>> + GFP_KERNEL);
>> +
>> +if (!entry)
>> +return;
>> +
>> +drm_debugfs_add_file_to_list(connector);
>> +}
>> +EXPORT_SYMBOL(drm_debugfs_connector_add_file);
>> +
>> static int connector_show(struct seq_file *m, void *data)
>> {
>> struct drm_connector *connector = m->private;
>> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
>> index ed2103ee272c..dd9d7b8b45bd 100644
>> --- a/drivers/gpu/drm/drm_internal.h
>> +++ b/drivers/gpu/drm/drm_internal.h
>> @@ -185,6 +185,7 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
>> drm_device *dev,
>> #if defined(CONFIG_DEBUG_FS)
>> int drm_debugfs_init(struct drm_minor *minor, int minor_id,
>> struct dentry *root);
>> +void drm_debugfs_connector_init(struct drm_connector *connector);
>> void drm_debugfs_cleanup(struct drm_minor *minor);
>> void drm_debugfs_late_register(struct drm_device *dev);
>> void drm_debugfs_connec
Re: [PATCH v2 01/13] drm/bridge: lt9611: fix sleep mode setup
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
On atomic_post_disable the bridge goes to the low power state. However
the code disables too much of the chip, so the HPD event is not being
detected and delivered to the host. Reduce the power saving in order to
get the HPD event.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 7c0a99173b39..2714184cc53f 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -448,12 +448,11 @@ static void lt9611_sleep_setup(struct lt9611 *lt9611)
{ 0x8023, 0x01 },
{ 0x8157, 0x03 }, /* set addr pin as output */
{ 0x8149, 0x0b },
- { 0x8151, 0x30 }, /* disable IRQ */
+
{ 0x8102, 0x48 }, /* MIPI Rx power down */
{ 0x8123, 0x80 },
{ 0x8130, 0x00 },
- { 0x8100, 0x01 }, /* bandgap power down */
- { 0x8101, 0x00 }, /* system clk power down */
+ { 0x8011, 0x0a },
};
regmap_multi_reg_write(lt9611->regmap,
Reviewed-by: Neil Armstrong
Re: [PATCH v2 02/13] drm/bridge: lt9611: fix HPD reenablement
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
The driver will reset the bridge in the atomic_pre_enable(). However
this will also drop the HPD interrupt state. Instead of resetting the
bridge, properly wake it up. This fixes the HPD interrupt delivery after
the disable/enable cycle.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 2714184cc53f..58f39b279217 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -856,12 +856,18 @@ static enum drm_mode_status
lt9611_bridge_mode_valid(struct drm_bridge *bridge,
static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
+ static const struct reg_sequence reg_cfg[] = {
+ { 0x8102, 0x12 },
+ { 0x8123, 0x40 },
+ { 0x8130, 0xea },
+ { 0x8011, 0xfa },
+ };
if (!lt9611->sleep)
return;
- lt9611_reset(lt9611);
- regmap_write(lt9611->regmap, 0x80ee, 0x01);
+ regmap_multi_reg_write(lt9611->regmap,
+ reg_cfg, ARRAY_SIZE(reg_cfg));
lt9611->sleep = false;
}
Reviewed-by: Neil Armstrong
Re: [PATCH 01/13] drm/debugfs: Create helper to add debugfs files to device's list
On Thu, 12 Jan 2023, Daniel Vetter wrote:
> On Thu, Jan 12, 2023 at 10:50:40AM +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2023, Maíra Canal wrote:
>> > Create a helper to encapsulate the code that adds a new debugfs file to
>> > a linked list related to a object. Moreover, the helper also provides
>> > more flexibily on the type of the object, allowing to use the helper for
>> > other types of drm_debugfs_entry.
>> >
>> > Signed-off-by: Maíra Canal
>> > ---
>> > drivers/gpu/drm/drm_debugfs.c | 20
>> > 1 file changed, 12 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
>> > index 4f643a490dc3..255d2068ac16 100644
>> > --- a/drivers/gpu/drm/drm_debugfs.c
>> > +++ b/drivers/gpu/drm/drm_debugfs.c
>> > @@ -316,6 +316,17 @@ void drm_debugfs_cleanup(struct drm_minor *minor)
>> >minor->debugfs_root = NULL;
>> > }
>> >
>> > +#define drm_debugfs_add_file_to_list(component) do {
>> > \
>> > + entry->file.name = name;\
>> > + entry->file.show = show;\
>> > + entry->file.data = data;\
>> > + entry->component = (component); \
>> > + \
>> > + mutex_lock(&(component)->debugfs_mutex);\
>> > + list_add(&entry->list, &(component)->debugfs_list); \
>> > + mutex_unlock(&(component)->debugfs_mutex); \
>> > + } while (0)
>>
>> In general, please don't add macros that implicitly depend on certain
>> local variable names. In this case, "entry".
>>
>> But I'm also not convinced about the usefulness of adding this kind of
>> "generics". Sure, it'll save you a few lines here and there, but I think
>> overall it's just confusing more than it's useful.
>
> So the non-generics way I guess would be to
> - pass the right pointer to the functions as an explicit parameter (struct
> drm_device|crtc|connector *, )
> - make drm_debugfs_entry and implementation detail
> - switch the pointer in there to void *, have glue show functions for each
> case which do nothing else than cast from void * to the right type
> (both for the parameter and the function pointer)
> - have a single function which takes that void *entry list and a pointer
> to the debugfs director to add them all for code sharing
>
> I think this should work for ->show, but for ->fops it becomes a rather
> big mess I fear. Maybe for ->fops (and also for ->show for now) we leave
> the explicit parameter out and just rely on seq_file->private or whatever
> it was.
Similar ideas in https://lore.kernel.org/r/878ri8glee@intel.com
I think for the more general ->fops case, the question really becomes
does drm need *all* the functionality of ->fops, or can we get away with
providing just show/write functions pointers, and wrapping it all inside
drm_debugfs.c? The question *now* is avoiding to paint ourselves in the
corner and requiring a ton of *extra* work to make that happen.
BR,
Jani.
>
> Or just copypaste, it's not that much code really :-)
> -Daniel
>
>>
>>
>> BR,
>> Jani.
>>
>> > +
>> > /**
>> > * drm_debugfs_add_file - Add a given file to the DRM device debugfs file
>> > list
>> > * @dev: drm device for the ioctl
>> > @@ -334,14 +345,7 @@ void drm_debugfs_add_file(struct drm_device *dev,
>> > const char *name,
>> >if (!entry)
>> >return;
>> >
>> > - entry->file.name = name;
>> > - entry->file.show = show;
>> > - entry->file.data = data;
>> > - entry->dev = dev;
>> > -
>> > - mutex_lock(&dev->debugfs_mutex);
>> > - list_add(&entry->list, &dev->debugfs_list);
>> > - mutex_unlock(&dev->debugfs_mutex);
>> > + drm_debugfs_add_file_to_list(dev);
>> > }
>> > EXPORT_SYMBOL(drm_debugfs_add_file);
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2 03/13] drm/bridge: lt9611: fix polarity programming
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Fix programming of hsync and vsync polarities
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 58f39b279217..deb503ca956a 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -207,7 +207,6 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
/* stage 2 */
{ 0x834a, 0x40 },
- { 0x831d, 0x10 },
/* MK limit */
{ 0x832d, 0x38 },
@@ -222,11 +221,19 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
{ 0x8325, 0x00 },
{ 0x832a, 0x01 },
{ 0x834a, 0x10 },
- { 0x831d, 0x10 },
- { 0x8326, 0x37 },
};
+ u8 pol = 0x10;
- regmap_multi_reg_write(lt9611->regmap, reg_cfg, ARRAY_SIZE(reg_cfg));
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ pol |= 0x2;
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ pol |= 0x1;
+ regmap_write(lt9611->regmap, 0x831d, pol);
+
+ if (mode->hdisplay == 3840)
+ regmap_multi_reg_write(lt9611->regmap, reg_cfg2,
ARRAY_SIZE(reg_cfg2));
+ else
+ regmap_multi_reg_write(lt9611->regmap, reg_cfg,
ARRAY_SIZE(reg_cfg));
switch (mode->hdisplay) {
case 640:
@@ -236,7 +243,7 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
regmap_write(lt9611->regmap, 0x8326, 0x37);
break;
case 3840:
- regmap_multi_reg_write(lt9611->regmap, reg_cfg2,
ARRAY_SIZE(reg_cfg2));
+ regmap_write(lt9611->regmap, 0x8326, 0x37);
break;
}
Reviewed-by: Neil Armstrong
Re: [PATCH v2 04/13] drm/bridge: lt9611: fix programming of video modes
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Program the upper part of the hfront_porch into the proper register.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index deb503ca956a..f377052a45a4 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -187,7 +187,8 @@ static void lt9611_mipi_video_setup(struct lt9611 *lt9611,
regmap_write(lt9611->regmap, 0x8319, (u8)(hfront_porch % 256));
- regmap_write(lt9611->regmap, 0x831a, (u8)(hsync_porch / 256));
+ regmap_write(lt9611->regmap, 0x831a, (u8)(hsync_porch / 256) |
+ ((hfront_porch / 256) << 4));
regmap_write(lt9611->regmap, 0x831b, (u8)(hsync_porch % 256));
}
Reviewed-by: Neil Armstrong
Re: [PATCH v2 05/13] drm/bridge: lt9611: fix clock calculation
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Instead of having several fixed values for the pcr register, calculate
it before programming. This allows the bridge to support most of the
display modes.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 32 +++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index f377052a45a4..e2799a0df8f8 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -192,8 +192,9 @@ static void lt9611_mipi_video_setup(struct lt9611 *lt9611,
regmap_write(lt9611->regmap, 0x831b, (u8)(hsync_porch % 256));
}
-static void lt9611_pcr_setup(struct lt9611 *lt9611, const struct drm_display_mode *mode)
+static void lt9611_pcr_setup(struct lt9611 *lt9611, const struct
drm_display_mode *mode, unsigned int postdiv)
{
+ unsigned int pcr_m = mode->clock * 5 * postdiv / 27000;
const struct reg_sequence reg_cfg[] = {
{ 0x830b, 0x01 },
{ 0x830c, 0x10 },
@@ -236,24 +237,14 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
else
regmap_multi_reg_write(lt9611->regmap, reg_cfg,
ARRAY_SIZE(reg_cfg));
- switch (mode->hdisplay) {
- case 640:
- regmap_write(lt9611->regmap, 0x8326, 0x14);
- break;
- case 1920:
- regmap_write(lt9611->regmap, 0x8326, 0x37);
- break;
- case 3840:
- regmap_write(lt9611->regmap, 0x8326, 0x37);
- break;
- }
+ regmap_write(lt9611->regmap, 0x8326, pcr_m);
/* pcr rst */
regmap_write(lt9611->regmap, 0x8011, 0x5a);
regmap_write(lt9611->regmap, 0x8011, 0xfa);
}
-static int lt9611_pll_setup(struct lt9611 *lt9611, const struct drm_display_mode *mode)
+static int lt9611_pll_setup(struct lt9611 *lt9611, const struct
drm_display_mode *mode, unsigned int *postdiv)
{
unsigned int pclk = mode->clock;
const struct reg_sequence reg_cfg[] = {
@@ -271,12 +262,16 @@ static int lt9611_pll_setup(struct lt9611 *lt9611, const
struct drm_display_mode
regmap_multi_reg_write(lt9611->regmap, reg_cfg, ARRAY_SIZE(reg_cfg));
- if (pclk > 15)
+ if (pclk > 15) {
regmap_write(lt9611->regmap, 0x812d, 0x88);
- else if (pclk > 7)
+ *postdiv = 1;
+ } else if (pclk > 7) {
regmap_write(lt9611->regmap, 0x812d, 0x99);
- else
+ *postdiv = 2;
+ } else {
regmap_write(lt9611->regmap, 0x812d, 0xaa);
+ *postdiv = 4;
+ }
/*
* first divide pclk by 2 first
@@ -895,14 +890,15 @@ static void lt9611_bridge_mode_set(struct drm_bridge
*bridge,
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
struct hdmi_avi_infoframe avi_frame;
+ unsigned int postdiv;
int ret;
lt9611_bridge_pre_enable(bridge);
lt9611_mipi_input_digital(lt9611, mode);
- lt9611_pll_setup(lt9611, mode);
+ lt9611_pll_setup(lt9611, mode, &postdiv);
lt9611_mipi_video_setup(lt9611, mode);
- lt9611_pcr_setup(lt9611, mode);
+ lt9611_pcr_setup(lt9611, mode, postdiv);
ret = drm_hdmi_avi_infoframe_from_display_mode(&avi_frame,
<9611->connector,
Reviewed-by: Neil Armstrong
Re: [PATCH v2 06/13] drm/bridge: lt9611: pass a pointer to the of node
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Pass a pointer to the OF node while registering lt9611 MIPI device.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index e2799a0df8f8..3b77238ca4af 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -769,7 +769,7 @@ static const struct drm_connector_funcs
lt9611_bridge_connector_funcs = {
static struct mipi_dsi_device *lt9611_attach_dsi(struct lt9611 *lt9611,
struct device_node *dsi_node)
{
- const struct mipi_dsi_device_info info = { "lt9611", 0, NULL };
+ const struct mipi_dsi_device_info info = { "lt9611", 0,
lt9611->dev->of_node};
struct mipi_dsi_device *dsi;
struct mipi_dsi_host *host;
struct device *dev = lt9611->dev;
Reviewed-by: Neil Armstrong
Re: [PATCH v2 09/13] drm/bridge: lt9611: fix sync polarity for DVI output
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Attaching DVI sink to the lt9611 requires different setup. Fix the
register write to make the DVI displays sync onto the correct sync
pulse.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 773d7a56f86f..7f9be74acf0d 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -352,13 +352,16 @@ static int lt9611_video_check(struct lt9611 *lt9611)
return temp;
}
-static void lt9611_hdmi_tx_digital(struct lt9611 *lt9611)
+static void lt9611_hdmi_tx_digital(struct lt9611 *lt9611, bool is_hdmi)
{
regmap_write(lt9611->regmap, 0x8443, 0x46 - lt9611->vic);
regmap_write(lt9611->regmap, 0x8447, lt9611->vic);
regmap_write(lt9611->regmap, 0x843d, 0x0a); /* UD1 infoframe */
- regmap_write(lt9611->regmap, 0x82d6, 0x8c);
+ if (is_hdmi)
+ regmap_write(lt9611->regmap, 0x82d6, 0x8c);
+ else
+ regmap_write(lt9611->regmap, 0x82d6, 0x0c);
regmap_write(lt9611->regmap, 0x82d7, 0x04);
}
@@ -719,7 +722,7 @@ lt9611_bridge_atomic_enable(struct drm_bridge *bridge,
}
lt9611_mipi_input_analog(lt9611);
- lt9611_hdmi_tx_digital(lt9611);
+ lt9611_hdmi_tx_digital(lt9611, connector->display_info.is_hdmi);
lt9611_hdmi_tx_phy(lt9611);
msleep(500);
Reviewed-by: Neil Armstrong
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > Hi Daniel, > > On Wed, 11 Jan 2023 22:47:02 +0100 > Daniel Vetter wrote: > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > wrote: > > > > > > Hi Daniel, > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > Daniel Vetter wrote: > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > > Hi Jason, > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > Jason Ekstrand wrote: > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote: > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to > > > > > > > > > > > have a 1 to 1 > > > > > > > > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. > > > > > > > > > > > At first > > > > > > > this > > > > > > > > > > > seems a bit odd but let us explain the reasoning below. > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > guaranteed to be the same completion even if targeting > > > > > > > > > > > the same > > > > > > > hardware > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > scheduler, the > > > > > > > GuC, > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > submissions. If a > > > > > > > using > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > falls > > > > > > > > > > > apart as the TDR expects submission order == completion > > > > > > > > > > > order. > > > > > > > Using a > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve > > > > > > > > > > > this > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the same > > > > > > > > > > sort of > > > > > > > > > > issues to support Arm's new Mali GPU which is relying on a > > > > > > > FW-assisted > > > > > > > > > > scheduling scheme (you give the FW N streams to execute, > > > > > > > > > > and it does > > > > > > > > > > the scheduling between those N command streams, the kernel > > > > > > > > > > driver > > > > > > > > > > does timeslice scheduling to update the command streams > > > > > > > > > > passed to the > > > > > > > > > > FW). I must admit I gave up on using drm_sched at some > > > > > > > > > > point, mostly > > > > > > > > > > because the integration with drm_sched was painful, but > > > > > > > > > > also because > > > > > > > I > > > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > > > timeslice-oriented scheduling model wasn't really future > > > > > > > > > > proof. > > > > > > > Giving > > > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler > > > > > > > > > > probably > > > > > > > might > > > > > > > > > > help for a few things (didn't think it through yet), but I > > > > > > > > > > feel it's > > > > > > > > > > coming short on other aspects we have to deal with on Arm > > > > > > > > > > GPUs. > > > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, and > > > > > > > > > I think I > > > > > > > > > have a better understanding of how you get away with using > > > > > > > > > drm_sched > > > > > > > > > while still controlling how scheduling is really done. Here > > > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you use > > > > > > > > > the > > > > > > > > > drm_sched job queuing/dep/tracking mechanism. The whole > > > > > > > > > run-queue > > > > > > > > > > > > > > You nailed it here, we use the DRM scheduler for queuing jobs, > > > > > > > dependency tracking and releasing jobs to be scheduled when > > > > > > > dependencies > > > > > > > are met, and lastly a tracking mechanism of inflights jobs that > > > > > > > need to > > > > > > > be cleaned up if an error occurs. It doesn't actually do any > > > > > > > scheduling > > > > > > > aside from the most basic level of not overflowing the submission > > > > > > > ring > > > > > > > buffer. In this sense, a 1 to 1 relationship between entity and > > > > > > > scheduler fits quite well. > > > > > > > > > > > > > > > > > > > Yeah, I think there's an annoying d
Re: [v3, 3/7] drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement
On 11/01/2023 13:41, Marek Szyprowski wrote:
On 02.11.2022 19:07, Dmitry Baryshkov wrote:
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver migration.
Enabling the HPD from drm_bridge_connector_init() can happen too early,
before the driver is prepared to handle HPD events. As the
drm_bridge_connector_enable_hpd() is empty anyway, drop this call
anyway.
Signed-off-by: Dmitry Baryshkov
---
This patch, merged to recent linux-next as commit 92d755d8f13b
("drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD
enablement"), triggers the following warning on all my Amlogic Meson
based boards:
[ cut here ]
Hot plug detection already enabled
WARNING: CPU: 2 PID: 285 at drivers/gpu/drm/drm_bridge.c:1257
drm_bridge_hpd_enable+0x90/0xa0
Modules linked in: snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo
dwmac_generic panfrost(+) reset_meson_audio_arb(+) drm_shmem_helper
meson_dw_hdmi(+) dw_hdmi rc_odroid drm_display_helper meson_ir(+)
gpu_sched meson_rng rng_core meson_gxbb_wdt crct10dif_ce dwmac_meson8b
stmmac_platform snd_soc_meson_axg_sound_card snd_soc_meson_card_utils
mdio_mux_meson_g12a stmmac meson_drm pwm_meson pcs_xpcs meson_canvas
snd_soc_meson_axg_tdm_interface rtc_meson_vrtc
snd_soc_meson_axg_tdm_formatter nvmem_meson_efuse display_connector
CPU: 2 PID: 285 Comm: systemd-udevd Not tainted 6.1.0-rc6+ #13236
Hardware name: Hardkernel ODROID-C4 (DT)
pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x90/0xa0
lr : drm_bridge_hpd_enable+0x90/0xa0
...
Call trace:
drm_bridge_hpd_enable+0x90/0xa0
_drm_bridge_connector_enable_hpd+0x24/0x34
Weird because _drm_bridge_connector_enable_hpd() has been removed with
4c00ac500d0e ("drm/bridge_connector: drop
drm_bridge_connector_en/disable_hpd()")
drm_kms_helper_poll_enable.part.0+0x50/0xd0
It seems drm_kms_helper_poll_enable is called again by
drm_helper_probe_single_connector_modes() because poll_running isn't set.
Can you try with this change:
===><===
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 7973f2589ced..5d60d4fd868f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -245,7 +245,7 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
struct drm_connector_list_iter conn_iter;
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
- if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
+ if (!dev->mode_config.poll_init || !drm_kms_helper_poll ||
dev->mode_config.poll_enabled)
return;
drm_connector_list_iter_begin(dev, &conn_iter);
@@ -279,6 +279,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
if (poll)
schedule_delayed_work(&dev->mode_config.output_poll_work,
delay);
+
+ dev->mode_config.poll_enabled = true;
}
EXPORT_SYMBOL(drm_kms_helper_poll_enable);
@@ -561,7 +563,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
* disable itself again.
*/
dev->mode_config.delayed_event = true;
- if (dev->mode_config.poll_enabled)
+ if (dev->mode_config.poll_init)
schedule_delayed_work(&dev->mode_config.output_poll_work,
0);
}
@@ -703,7 +705,7 @@ static void output_poll_execute(struct work_struct *work)
bool repoll = false, changed;
u64 old_epoch_counter;
- if (!dev->mode_config.poll_enabled)
+ if (!dev->mode_config.poll_init)
return;
/* Pick up any changes detected by the probe functions. */
@@ -813,11 +815,11 @@ static void drm_kms_helper_poll_disable_fini(struct
drm_device *dev, bool fini)
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
- if (!dev->mode_config.poll_enabled)
+ if (!dev->mode_config.poll_init || !dev->mode_config.poll_enabled)
return;
if (fini)
- dev->mode_config.poll_enabled = false;
+ dev->mode_config.poll_init = false;
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
@@ -830,6 +832,8 @@ static void drm_kms_helper_poll_disable_fini(struct
drm_device *dev, bool fini)
drm_connector_list_iter_end(&conn_iter);
cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
+
+ dev->mode_config.poll_enabled = false;
}
/**
@@ -874,7 +878,7 @@ EXPORT_SYMBOL(drm_kms_helper_poll_disable);
void drm_kms_helper_poll_init(struct drm_device *dev)
{
INIT_D
Re: [v3, 3/7] drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement
On 12/01/2023 11:35, Neil Armstrong wrote:
On 11/01/2023 13:41, Marek Szyprowski wrote:
On 02.11.2022 19:07, Dmitry Baryshkov wrote:
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver migration.
Enabling the HPD from drm_bridge_connector_init() can happen too early,
before the driver is prepared to handle HPD events. As the
drm_bridge_connector_enable_hpd() is empty anyway, drop this call
anyway.
Signed-off-by: Dmitry Baryshkov
---
This patch, merged to recent linux-next as commit 92d755d8f13b
("drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD
enablement"), triggers the following warning on all my Amlogic Meson
based boards:
[ cut here ]
Hot plug detection already enabled
WARNING: CPU: 2 PID: 285 at drivers/gpu/drm/drm_bridge.c:1257
drm_bridge_hpd_enable+0x90/0xa0
Modules linked in: snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo
dwmac_generic panfrost(+) reset_meson_audio_arb(+) drm_shmem_helper
meson_dw_hdmi(+) dw_hdmi rc_odroid drm_display_helper meson_ir(+)
gpu_sched meson_rng rng_core meson_gxbb_wdt crct10dif_ce dwmac_meson8b
stmmac_platform snd_soc_meson_axg_sound_card snd_soc_meson_card_utils
mdio_mux_meson_g12a stmmac meson_drm pwm_meson pcs_xpcs meson_canvas
snd_soc_meson_axg_tdm_interface rtc_meson_vrtc
snd_soc_meson_axg_tdm_formatter nvmem_meson_efuse display_connector
CPU: 2 PID: 285 Comm: systemd-udevd Not tainted 6.1.0-rc6+ #13236
Hardware name: Hardkernel ODROID-C4 (DT)
pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x90/0xa0
lr : drm_bridge_hpd_enable+0x90/0xa0
...
Call trace:
drm_bridge_hpd_enable+0x90/0xa0
_drm_bridge_connector_enable_hpd+0x24/0x34
Weird because _drm_bridge_connector_enable_hpd() has been removed with
4c00ac500d0e ("drm/bridge_connector: drop
drm_bridge_connector_en/disable_hpd()")
drm_kms_helper_poll_enable.part.0+0x50/0xd0
It seems drm_kms_helper_poll_enable is called again by
drm_helper_probe_single_connector_modes() because poll_running isn't set.
Yes, I'm currently reworking poll_running handling. I hope to post a
patch today.
--
With best wishes
Dmitry
Re: [PATCH v2 2/3] drm/panel: boe-tv101wum-nl6: Reduce lcm_reset to send initial code time
Re: [PATCH 01/11] drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
It's just open coded and matches.
Note that Thomas said that his version apparently failed for some
reason, but hey maybe we should try again.
It apparently worked this time. Tested on an AST2100 chip.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Tested-by: Thomas Zimmmermann
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 420fc75c240e..3ac24a780f50 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -90,27 +90,13 @@ static const struct pci_device_id ast_pciidlist[] = {
MODULE_DEVICE_TABLE(pci, ast_pciidlist);
-static int ast_remove_conflicting_framebuffers(struct pci_dev *pdev)
-{
- bool primary = false;
- resource_size_t base, size;
-
- base = pci_resource_start(pdev, 0);
- size = pci_resource_len(pdev, 0);
-#ifdef CONFIG_X86
- primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
-#endif
-
- return drm_aperture_remove_conflicting_framebuffers(base, size, primary,
&ast_driver);
-}
-
static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
struct ast_private *ast;
struct drm_device *dev;
int ret;
- ret = ast_remove_conflicting_framebuffers(pdev);
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
&ast_driver);
if (ret)
return ret;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [RESEND PATCH linux-next v2 00/10] drm: Remove some obsolete drivers(tdfx, mga, i810, savage, r128, sis, via)
On Thu, Jan 05, 2023 at 02:01:50PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.01.23 um 13:40 schrieb Daniel Vetter:
> > On Thu, Dec 08, 2022 at 08:42:07PM +0800, Cai Huoqing wrote:
> > > On 03 12月 22 18:22:51, Cai Huoqing wrote:
> > > > Commit 399516ab0fee ("MAINTAINERS: Add a bunch of legacy (UMS) DRM
> > > > drivers")
> > > > marked these drivers obsolete 7 years ago.
> > > > And the mesa UMD of these drm drivers already in deprecated list
> > > > in the link: https://docs.mesa3d.org/systems.html
> > > >
> > > > 3dfx Glide-->driver/gpu/drm/tdfx
> > > > Matrox-->driver/gpu/drm/mga
> > > > Intel i810-->driver/gpu/drm/i810
> > > > S3 Savage-->drivers/gpu/drm/savage
> > > > ATI Rage 128->drivers/gpu/drm/r128
> > > > Silicon Integrated Systems->drivers/gpu/drm/sis
> > > > VIA Unichrome->drivers/gpu/drm/via
> > > >
> > > > v1->v2:
> > > > 1.Add drm via driver to the patchset.
> > > > 2.Remove related drm_pciids.
> > > > 3.Remove related drm uapi header files.
> > > > 4.split to series avoid large patch email.
> > > Just ping these patch series.
> > > The v1 comments here,
> > > https://lore.kernel.org/lkml/39d8ac1a-d92f-7cdc-14cd-944342f78...@suse.de/
> >
> > Are we really sure that all users of these are gone? Also, I'm not really
> > seeing the benefit of this, we've managed to split out the legacy code
> > quite well, so carrying around isn't hurting anything afaics?
>
> My first reaction was 'no way'. But then I thought about possible users of
> this code and I cannot see anyone relying on it. You'd need an ancient
> userspace Mesa library plus the most recent kernel. And all the rendering is
> OpenGL 1.x. Are there even Linux programs for that?
>
> So as far as I'm concerned
>
> Acked-by: Thomas Zimmermann
>
> DRM's legacy infrastructure could be kept for a few more releases. Just in
> case one of the drivers makes a comeback.
>
> There is code in nouveau that uses legacy functionality for its ancient
> userspace. I think we should scrap that as well. (See
> NOUVEAU_LEGACY_CTX_SUPPORT.)
>From the irc discussion:
Acked-by: Daniel Vetter
Acked-by: Dave Airlie
>
> Best regards
> Thomas
>
> > -Daniel
> >
> > >
> > > Thanks,
> > > Cai
> > > >
> > > > Cai Huoqing (10):
> > > >drm: Remove the obsolete driver-i810
> > > >drm: Remove the obsolete driver-mga
> > > >drm: Remove the obsolete driver-r128
> > > >drm: Remove the obsolete driver-savage
> > > >drm: Remove the obsolete driver-sis
> > > >drm: Remove the obsolete driver-tdfx
> > > >drm: Remove the obsolete driver-via
> > > >drm: Add comments to Kconfig
> > > >drm: Remove some obsolete drm pciids(tdfx, mga, i810, savage, r128,
> > > > sis, via)
> > > >MAINTAINERS: Remove some obsolete drivers info(tdfx, mga, i810,
> > > > savage, r128, sis)
> > > >
> > > > MAINTAINERS | 29 -
> > > > drivers/gpu/drm/Kconfig | 59 +-
> > > > drivers/gpu/drm/Makefile |7 -
> > > > drivers/gpu/drm/i810/Makefile |8 -
> > > > drivers/gpu/drm/i810/i810_dma.c | 1266 -
> > > > drivers/gpu/drm/i810/i810_drv.c | 101 -
> > > > drivers/gpu/drm/i810/i810_drv.h | 246 --
> > > > drivers/gpu/drm/mga/Makefile | 11 -
> > > > drivers/gpu/drm/mga/mga_dma.c | 1168
> > > > drivers/gpu/drm/mga/mga_drv.c | 104 -
> > > > drivers/gpu/drm/mga/mga_drv.h | 685 -
> > > > drivers/gpu/drm/mga/mga_ioc32.c | 197 --
> > > > drivers/gpu/drm/mga/mga_irq.c | 169 --
> > > > drivers/gpu/drm/mga/mga_state.c | 1099
> > > > drivers/gpu/drm/mga/mga_warp.c| 167 --
> > > > drivers/gpu/drm/r128/Makefile | 10 -
> > > > drivers/gpu/drm/r128/ati_pcigart.c| 228 --
> > > > drivers/gpu/drm/r128/ati_pcigart.h| 31 -
> > > > drivers/gpu/drm/r128/r128_cce.c | 944 ---
> > > > drivers/gpu/drm/r128/r128_drv.c | 116 -
> > > > drivers/gpu/drm/r128/r128_drv.h | 544
> > > > drivers/gpu/drm/r128/r128_ioc32.c | 199 --
> > > > drivers/gpu/drm/r128/r128_irq.c | 118 -
> > > > drivers/gpu/drm/r128/r128_state.c | 1641 ---
> > > > drivers/gpu/drm/savage/Makefile |9 -
> > > > drivers/gpu/drm/savage/savage_bci.c | 1082
> > > > drivers/gpu/drm/savage/savage_drv.c | 91 -
> > > > drivers/gpu/drm/savage/savage_drv.h | 580
> > > > drivers/gpu/drm/savage/savage_state.c | 1169
> > > > drivers/gpu/drm/sis/Makefile | 10 -
> > > > drivers/gpu/drm/sis/sis_drv.c | 143 -
> > > > drivers/gpu/drm/sis/sis_drv.h | 80 -
> > > > drivers/gpu/drm/sis/sis_mm.c | 363 ---
> > > > drivers/gpu/drm/tdfx/Makefile |8 -
> > > > drivers/gpu/drm/tdfx/tdfx_drv.c | 90 -
> > > > drivers/gpu/drm/tdfx/tdfx_drv.h | 47 -
> > > > drivers/gpu/drm/via/Makefile |8 -
Re: [PATCH 07/13] drm/vc4: Use the encoders' debugfs infrastructure
On Thu, Jan 12, 2023 at 11:19:37AM +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2023, Maíra Canal wrote:
> > Replace the use of drm_debugfs_add_files() with the new
> > drm_debugfs_encoder_add_files() function, which centers the debugfs files
> > management on the drm_encoder instead of drm_device. Using this function
> > on late register callbacks is more adequate as the callback passes a
> > drm_encoder as parameter.
> >
> > Signed-off-by: Maíra Canal
> > ---
> > drivers/gpu/drm/vc4/vc4_debugfs.c | 17 +
> > drivers/gpu/drm/vc4/vc4_dpi.c | 3 +--
> > drivers/gpu/drm/vc4/vc4_drv.h | 8
> > drivers/gpu/drm/vc4/vc4_dsi.c | 3 +--
> > drivers/gpu/drm/vc4/vc4_hdmi.c| 5 ++---
> > drivers/gpu/drm/vc4/vc4_vec.c | 3 +--
> > 6 files changed, 30 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c
> > b/drivers/gpu/drm/vc4/vc4_debugfs.c
> > index 80afc69200f0..c71e4d6ec4c4 100644
> > --- a/drivers/gpu/drm/vc4/vc4_debugfs.c
> > +++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
> > @@ -57,9 +57,26 @@ static int vc4_debugfs_dev_regset32(struct seq_file *m,
> > void *unused)
> > return vc4_debugfs_regset32(drm, regset, &p);
> > }
> >
> > +static int vc4_debugfs_encoder_regset32(struct seq_file *m, void *unused)
> > +{
> > + struct drm_debugfs_encoder_entry *entry = m->private;
> > + struct drm_device *drm = entry->encoder->dev;
>
> Feels like struct drm_debugfs_encoder_entry should be an implementation
> detail. Maybe add helpers to get the encoder/connector/etc pointer, and
> keep struct drm_debugfs_encoder_entry internal to the debugfs
> implementation?
>
> struct drm_device *drm = drm_debugfs_something_encoder(m->private)->dev;
>
> However, even cooler would be if we could have the debugfs code wrap the
> calls, and you could have:
>
> static int vc4_debugfs_encoder_regset32(struct drm_encoder *encoder);
>
> struct drm_debugfs_encoder_entry could have a function pointer for the
> above, and there'd be a simple wrapper in debugfs code:
>
> static int encoder_debugfs_show(struct seq_file *m, void *unused)
> {
> struct drm_debugfs_encoder_entry *entry = m->private;
> struct drm_encoder *encoder = entry->encoder;
>
> return entry->show(encoder);
> }
>
> drm_debugfs_encoder_add_file() would fill in entry->show, and add that
> as the show function for core debugfs code.
>
> Ditto for connector/crtc/etc.
>
> This would make all of the drm debugfs functions so much nicer.
Yeah this is what I mean with "we should pass the right struct pointer
explicitly". I think at this point the drm debugfs wrappers actually start
to really pay for themselves, because you can make nice clean debugfs
show/write functions for various little things.
-Daniel
>
> BR,
> Jani.
>
>
> > + struct debugfs_regset32 *regset = entry->file.data;
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + return vc4_debugfs_regset32(drm, regset, &p);
> > +}
> > +
> > void vc4_debugfs_add_regset32(struct drm_device *drm,
> > const char *name,
> > struct debugfs_regset32 *regset)
> > {
> > drm_debugfs_add_file(drm, name, vc4_debugfs_dev_regset32, regset);
> > }
> > +
> > +void vc4_debugfs_encoder_add_regset32(struct drm_encoder *encoder,
> > + const char *name,
> > + struct debugfs_regset32 *regset)
> > +{
> > + drm_debugfs_encoder_add_file(encoder, name,
> > vc4_debugfs_encoder_regset32, regset);
> > +}
> > diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> > index f518d6e59ed6..084f7825dfa4 100644
> > --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> > @@ -265,10 +265,9 @@ static const struct drm_encoder_helper_funcs
> > vc4_dpi_encoder_helper_funcs = {
> >
> > static int vc4_dpi_late_register(struct drm_encoder *encoder)
> > {
> > - struct drm_device *drm = encoder->dev;
> > struct vc4_dpi *dpi = to_vc4_dpi(encoder);
> >
> > - vc4_debugfs_add_regset32(drm, "dpi_regs", &dpi->regset);
> > + vc4_debugfs_encoder_add_regset32(encoder, "dpi_regs", &dpi->regset);
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index 95069bb16821..8aaa8d00bc45 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -969,12 +969,20 @@ void vc4_debugfs_init(struct drm_minor *minor);
> > void vc4_debugfs_add_regset32(struct drm_device *drm,
> > const char *filename,
> > struct debugfs_regset32 *regset);
> > +void vc4_debugfs_encoder_add_regset32(struct drm_encoder *encoder,
> > + const char *name,
> > + struct debugfs_regset32 *regset);
> > #else
> >
> > static inline void vc4_debugfs_add_regset32(struct drm_device *drm,
> >
Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission
On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote: On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote: On 22/12/2022 22:21, Matthew Brost wrote: > Hello, > > This is a submission for Xe, a new driver for Intel GPUs that supports both > integrated and discrete platforms starting with Tiger Lake (first platform with > Intel Xe Architecture). The intention of this new driver is to have a fresh base > to work from that is unencumbered by older platforms, whilst also taking the > opportunity to rearchitect our driver to increase sharing across the drm > subsystem, both leveraging and allowing us to contribute more towards other > shared components like TTM and drm/scheduler. The memory model is based on VM > bind which is similar to the i915 implementation. Likewise the execbuf > implementation for Xe is very similar to execbuf3 in the i915 [1]. > > The code is at a stage where it is already functional and has experimental > support for multiple platforms starting from Tiger Lake, with initial support > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO > implementation will be released publicly early next year. We also have a suite > of IGTs for XE that will appear on the IGT list shortly. > > It has been built with the assumption of supporting multiple architectures from > the get-go, right now with tests running both on X86 and ARM hosts. And we > intend to continue working on it and improving on it as part of the kernel > community upstream. > > The new Xe driver leverages a lot from i915 and work on i915 continues as we > ready Xe for production throughout 2023. > > As for display, the intent is to share the display code with the i915 driver so > that there is maximum reuse there. Currently this is being done by compiling the > display code twice, but alternatives to that are under consideration and we want > to have more discussion on what the best final solution will look like over the > next few months. Right now, work is ongoing in refactoring the display codebase > to remove as much as possible any unnecessary dependencies on i915 specific data > structures there.. > > We currently have 2 submission backends, execlists and GuC. The execlist is > meant mostly for testing and is not fully functional while GuC backend is fully > functional. As with the i915 and GuC submission, in Xe the GuC firmware is > required and should be placed in /lib/firmware/xe. What is the plan going forward for the execlists backend? I think it would be preferable to not upstream something semi-functional and so to carry technical debt in the brand new code base, from the very start. If it is for Tigerlake, which is the starting platform for Xe, could it be made GuC only Tigerlake for instance? A little background here. In the original PoC written by Jason and Dave, the execlist backend was the only one present and it was in semi-working state. As soon as myself and a few others started working on Xe we went full in a on the GuC backend. We left the execlist backend basically in the state it was in. We left it in place for 2 reasons. 1. Having 2 backends from the start ensured we layered our code correctly. The layer was a complete disaster in the i915 so we really wanted to avoid that. 2. The thought was it might be needed for early product bring up one day. As I think about this a bit more, we likely just delete execlist backend before merging this upstream and perhaps just carry 1 large patch internally with this implementation that we can use as needed. Final decession TDB though. but that might regress after some time on "let's keep 2 backends so we layer the code correctly". Leaving the additional backend behind CONFIG_BROKEN or XE_EXPERIMENTAL, or something like that, not enabled by distros, but enabled in CI would be a good idea IMO. Carrying a large patch out of tree would make things harder for new platforms. A perfect backend split would make it possible, but like I said, we are likely not to have it if we delete the second backend. Lucas De Marchi Matt Regards, Tvrtko
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.23 um 16:41 schrieb Daniel Vetter: > > This one nukes all framebuffers, which is a bit much. In reality > > gma500 is igpu and never shipped with anything discrete, so there should > > not be any difference. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/gma500/psb_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/gma500/psb_drv.c > > b/drivers/gpu/drm/gma500/psb_drv.c > > index cd9c73f5a64a..9b0daf90dc50 100644 > > --- a/drivers/gpu/drm/gma500/psb_drv.c > > +++ b/drivers/gpu/drm/gma500/psb_drv.c > > @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const > > struct pci_device_id *ent) > > * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we > > * might be able to read the framebuffer range from the device. > > */ > > - ret = drm_aperture_remove_framebuffers(true, &driver); > > + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver); > > This does not work. The comment just above the changed line explains why. > The device uses shared memory similar to other integrated Intel chips. The > console is somewhere in a 16 MiB range, which has been stolen by the BIOS > from main memory. There's only a 1 MiB memory range on the device to program > the device. Unless you want to refactor as described, this call has to cover > the whole memory for now. Uh. So it's maybe not so pretty, but what if I just call both functions? That way we get the vga handling through the pci one, and the "make sure there's no fb left" through the other one. Plus comment of course. Otherwise we'd need to somehow keep the vga stuff in the non-pci paths, and that just feels all kinds of wrong to me. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 3/3] drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence
Re: [PATCH 9/9] arm64: dts: mediatek: mt8186: Add display nodes
Hi,
On Wed, Jan 11, 2023 at 8:37 PM Allen-KH Cheng
wrote:
>
> Add display nodes and GCE info for MT8186 SoC. Also, add GCE
> (Global Command Engine) properties to the display nodes in order to
> enable the usage of the CMDQ (Command Queue), which is required for
> operating the display.
>
> Signed-off-by: Allen-KH Cheng
> ---
> arch/arm64/boot/dts/mediatek/mt8186.dtsi | 128 +++
> 1 file changed, 128 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> index eab30ab01572..8670d37970ef 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> @@ -5,6 +5,7 @@
> */
> /dts-v1/;
> #include
> +#include
> #include
> #include
> #include
> @@ -632,6 +633,15 @@
> clocks = <&clk13m>;
> };
>
> + gce: mailbox@1022c000 {
> + compatible = "mediatek,mt8186-gce";
> + reg = <0 0X1022c000 0 0x4000>;
> + interrupts = ;
> + #mbox-cells = <2>;
> + clocks = <&infracfg_ao CLK_INFRA_AO_GCE>;
> + clock-names = "gce";
> + };
> +
> scp: scp@1050 {
> compatible = "mediatek,mt8186-scp";
> reg = <0 0x1050 0 0x4>,
> @@ -1197,6 +1207,20 @@
> reg = <0 0x1400 0 0x1000>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> + mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>,
> +<&gce 1 CMDQ_THR_PRIO_HIGHEST>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400 0
> 0x1000>;
> + };
> +
> + mutex: mutex@14001000 {
> + compatible = "mediatek,mt8186-disp-mutex";
> + reg = <0 0x14001000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_DISP_MUTEX0>;
> + interrupts = ;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401
> 0x1000 0x1000>;
> + mediatek,gce-events =
> ,
> +
> ;
> + power-domains = <&spm MT8186_POWER_DOMAIN_DIS>;
> };
>
> smi_common: smi@14002000 {
> @@ -1230,6 +1254,49 @@
> power-domains = <&spm MT8186_POWER_DOMAIN_DIS>;
> };
>
> + ovl0: ovl@14005000 {
If there's only one instance, you could drop the trailing zero. Same
for all the other nodes.
> + compatible = "mediatek,mt8186-disp-ovl",
> +"mediatek,mt8192-disp-ovl";
> + reg = <0 0x14005000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_DISP_OVL0>;
> + interrupts = ;
> + iommus = <&iommu_mm IOMMU_PORT_L0_OVL_RDMA0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400
> 0x5000 0x1000>;
> + power-domains = <&spm MT8186_POWER_DOMAIN_DIS>;
> + };
> +
> + ovl0_2l: ovl@14006000 {
I think this should be "ovl_2l0" or "ovl_2l" instead?
> + compatible = "mediatek,mt8186-disp-ovl-2l",
> +"mediatek,mt8192-disp-ovl-2l";
> + reg = <0 0x14006000 0 0x1000>;
> + power-domains = <&spm MT8186_POWER_DOMAIN_DIS>;
> + clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
> + interrupts = ;
> + iommus = <&iommu_mm IOMMU_PORT_L1_OVL_2L_RDMA0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400
> 0x6000 0x1000>;
> + };
Also, this patch is missing the aliases for ovl* and rdma*. Without them
the display driver doesn't properly detect the second pipeline, and only
one CRTC is generated.
ChenYu
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Allow error capture without a request
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
Signed-off-by: John Harrison
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_gpu_error.c | 61 +++
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64e..bd2cf7d235df0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(&ctx->guilty_count);
e->active = atomic_read(&ctx->active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs *engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(&ee->context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(&ee->context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1608,8 +1628,11 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(&engine->gt->i915->drm, "Got hung context on %s
with no active request!\n",
Suggest s/active/started/ since we have both i915_r
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Allow error capture of a pending request
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that this might be better than nothing.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bd2cf7d235df0..2e338a9667a4b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1628,11 +1628,9 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (rq && !i915_request_started(rq)) {
- drm_info(&engine->gt->i915->drm, "Got hung context on %s
with no active request!\n",
-engine->name);
- rq = NULL;
- }
+ if (rq && !i915_request_started(rq))
+ drm_info(&engine->gt->i915->drm, "Confused - active request
not yet started: %lld:%lld, ce = 0x%04X/%s!\n",
+rq->fence.context, rq->fence.seqno,
ce->guc_id.id, engine->name);
Ah you change active to started in this patch! :)
I suggest no "ce" in user visible messages and maybe stick with the
convention grep suggest is already established:
"Hung context with active request %lld:%lld [0x%04X] not started!"
Regards,
Tvrtko
} else {
/*
* Getting here with GuC enabled means it is a forced error
capture
Re: [PATCH v2] drm/i915: Fix CFI violations in gt_sysfs
Hi,
This patch does also solve a kernel crash when reading
/sys/class/drm/card1/gt/gt0/* on a skylake machine:
https://bugzilla.redhat.com/show_bug.cgi?id=2154880
Do you think it can be backported to stable releases ?
Conflicts are trivial on top of v6.0 at least.
Thanks,
--
Jocelyn
On 13/10/2022 22:59, Nathan Chancellor wrote:
When booting with CONFIG_CFI_CLANG, there are numerous violations when
accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
rc6_residency_ms:214934
rps_act_freq_mhz:1300
rps_boost_freq_mhz:1300
rps_cur_freq_mhz:350
rps_max_freq_mhz:1300
rps_min_freq_mhz:350
rps_RP0_freq_mhz:1300
rps_RP1_freq_mhz:350
rps_RPn_freq_mhz:350
throttle_reason_pl1:0
throttle_reason_pl2:0
throttle_reason_pl4:0
throttle_reason_prochot:0
throttle_reason_ratl:0
throttle_reason_status:0
throttle_reason_thermal:0
throttle_reason_vr_tdc:0
throttle_reason_vr_thermalert:0
$ sudo dmesg &| grep "CFI failure at"
[ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
[ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
[ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.
To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.
Link: https://gi
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 10:32:18 +0100 Daniel Vetter wrote: > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > Hi Daniel, > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > Daniel Vetter wrote: > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > wrote: > > > > > > > > Hi Daniel, > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > Daniel Vetter wrote: > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > > > Hi Jason, > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon > > > > > > > > wrote: > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to > > > > > > > > > > > > have a 1 to 1 > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > this > > > > > > > > > > > > seems a bit odd but let us explain the reasoning below. > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > guaranteed to be the same completion even if targeting > > > > > > > > > > > > the same > > > > > > > > hardware > > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > > scheduler, the > > > > > > > > GuC, > > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > > submissions. If a > > > > > > > > using > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > falls > > > > > > > > > > > > apart as the TDR expects submission order == completion > > > > > > > > > > > > order. > > > > > > > > Using a > > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve > > > > > > > > > > > > this > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the > > > > > > > > > > > same sort of > > > > > > > > > > > issues to support Arm's new Mali GPU which is relying on > > > > > > > > > > > a > > > > > > > > FW-assisted > > > > > > > > > > > scheduling scheme (you give the FW N streams to execute, > > > > > > > > > > > and it does > > > > > > > > > > > the scheduling between those N command streams, the > > > > > > > > > > > kernel driver > > > > > > > > > > > does timeslice scheduling to update the command streams > > > > > > > > > > > passed to the > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at some > > > > > > > > > > > point, mostly > > > > > > > > > > > because the integration with drm_sched was painful, but > > > > > > > > > > > also because > > > > > > > > I > > > > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > > > > timeslice-oriented scheduling model wasn't really future > > > > > > > > > > > proof. > > > > > > > > Giving > > > > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler > > > > > > > > > > > probably > > > > > > > > might > > > > > > > > > > > help for a few things (didn't think it through yet), but > > > > > > > > > > > I feel it's > > > > > > > > > > > coming short on other aspects we have to deal with on Arm > > > > > > > > > > > GPUs. > > > > > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, > > > > > > > > > > and I think I > > > > > > > > > > have a better understanding of how you get away with using > > > > > > > > > > drm_sched > > > > > > > > > > while still controlling how scheduling is really done. Here > > > > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you > > > > > > > > > > use the > > > > > > > > > > drm_sched job queuing/dep/tracking mechanism. The whole > > > > > > > > > > run-queue > > > > > > > > > > > > > > > > You nailed it here, we use the DRM scheduler for queuing jobs, > > > > > > > > dependency tracking and releasing jobs to be scheduled when > > > > > > > > dependencies > > > > > > > > are met, and lastly a tracking mechanism of inflights jobs that > > > > > > > > need to > > > > > > > >
Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Add a debug print on GuC triggered reset
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 99d09e3394597..0be7c27a436dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4665,6 +4665,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
+ drm_dbg(&guc_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting = %d, banned = %d\n",
+ ce->guc_id.id, test_bit(CONTEXT_EXITING, &ce->flags),
+ test_bit(CONTEXT_BANNED, &ce->flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..99d09e3394597 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4754,11 +4754,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be safe/reliable to do this here because
the GuC
+* is toast and will not be scheduling behind the KMD's back.
+*/
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
This one I don't feel "at home" enough to r-b. Just a question - can we
be sure at this point that GuC is 100% stuck and there isn't a chance it
somehow comes alive and starts running in parallel (being driven in
parallel by a different "thread" in i915), interfering with the
assumption made in the comment?
Regards,
Tvrtko
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
Hi
Am 12.01.23 um 10:59 schrieb Daniel Vetter:
On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
Hi
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index cd9c73f5a64a..9b0daf90dc50 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
* TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
* might be able to read the framebuffer range from the device.
*/
- ret = drm_aperture_remove_framebuffers(true, &driver);
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
This does not work. The comment just above the changed line explains why.
The device uses shared memory similar to other integrated Intel chips. The
console is somewhere in a 16 MiB range, which has been stolen by the BIOS
from main memory. There's only a 1 MiB memory range on the device to program
the device. Unless you want to refactor as described, this call has to cover
the whole memory for now.
Uh. So it's maybe not so pretty, but what if I just call both functions?
That's ways more ugly IMHO.
That way we get the vga handling through the pci one, and the "make sure
there's no fb left" through the other one. Plus comment of course.
Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
and that just feels all kinds of wrong to me.
With your patch applied, aperture_detach_devices() does all the work of
removing. I'd add the following internal functions:
static void aperture_detach_head(bool is_primary)
{
/*
* lengthy comment here
*/
if (is_primary)
sysfb_disable()
}
static void aperture_detach_tail(bool remove_vga)
{
if (remove_vga) {
aperture_detach_devices(VGA_PHYS_)
vga_remove_vgacon()
}
}
And call both of them at the beginning/end of
aperture_remove_conflicting_devices() and
aperture_remove_conflicting_pci_devices().
You'd still need to primary argument to
aperture_remove_conflicting_devices(), but there will be no code
duplication with the aperture helpers and the purpose of each code
fragment will be clearer.
Best regards
Thomas
-Daniel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 0/4] Track exported dma-buffers with memcg
On Thu 12-01-23 07:56:31, Shakeel Butt wrote: > On Wed, Jan 11, 2023 at 11:56:45PM +0100, Daniel Vetter wrote: > > > [...] > > I think eventually, at least for other "account gpu stuff in cgroups" use > > case we do want to actually charge the memory. > > > > The problem is a bit that with gpu allocations reclaim is essentially "we > > pass the error to userspace and they get to sort the mess out". There are > > some exceptions (some gpu drivers to have shrinkers) would we need to make > > sure these shrinkers are tied into the cgroup stuff before we could enable > > charging for them? > > > > No, there is no requirement to have shrinkers or making such memory > reclaimable before charging it. Though existing shrinkers and the > possible future shrinkers would need to be converted into memcg aware > shrinkers. > > Though there will be a need to update user expectations that if they > use memcgs with hard limits, they may start seeing memcg OOMs after the > charging of dmabuf. Agreed. This wouldn't be the first in kernel memory charged memory that is not directly reclaimable. With a dedicated counter an excessive dmabuf usage would be visible in the oom report because we do print memcg stats. It is definitely preferable to have a shrinker mechanism but if that is to be done in a follow up step then this is acceptable. But leaving out charging from early on sounds like a bad choice to me. -- Michal Hocko SUSE Labs
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 11:11:03 +0100 Boris Brezillon wrote: > On Thu, 12 Jan 2023 10:32:18 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > Hi Daniel, > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > Daniel Vetter wrote: > > > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > > wrote: > > > > > > > > > > Hi Daniel, > > > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > > > > > > > > > > Hi Jason, > > > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon > > > > > > > > > wrote: > > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to > > > > > > > > > > > > > have a 1 to 1 > > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > > this > > > > > > > > > > > > > seems a bit odd but let us explain the reasoning > > > > > > > > > > > > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > > guaranteed to be the same completion even if > > > > > > > > > > > > > targeting the same > > > > > > > > > hardware > > > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > > > scheduler, the > > > > > > > > > GuC, > > > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > > > submissions. If a > > > > > > > > > using > > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > > falls > > > > > > > > > > > > > apart as the TDR expects submission order == > > > > > > > > > > > > > completion order. > > > > > > > > > Using a > > > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity > > > > > > > > > > > > > solve this > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the > > > > > > > > > > > > same sort of > > > > > > > > > > > > issues to support Arm's new Mali GPU which is relying > > > > > > > > > > > > on a > > > > > > > > > FW-assisted > > > > > > > > > > > > scheduling scheme (you give the FW N streams to > > > > > > > > > > > > execute, and it does > > > > > > > > > > > > the scheduling between those N command streams, the > > > > > > > > > > > > kernel driver > > > > > > > > > > > > does timeslice scheduling to update the command streams > > > > > > > > > > > > passed to the > > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at some > > > > > > > > > > > > point, mostly > > > > > > > > > > > > because the integration with drm_sched was painful, but > > > > > > > > > > > > also because > > > > > > > > > I > > > > > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > > > > > timeslice-oriented scheduling model wasn't really > > > > > > > > > > > > future proof. > > > > > > > > > Giving > > > > > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler > > > > > > > > > > > > probably > > > > > > > > > might > > > > > > > > > > > > help for a few things (didn't think it through yet), > > > > > > > > > > > > but I feel it's > > > > > > > > > > > > coming short on other aspects we have to deal with on > > > > > > > > > > > > Arm GPUs. > > > > > > > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, > > > > > > > > > > > and I think I > > > > > > > > > > > have a better understanding of how you get away with > > > > > > > > > > > using drm_sched > > > > > > > > > > > while still controlling how scheduling is really done. > > > > > > > > > > > Here > > > > > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you > > > > > > > > > > > use the > > > > > > > > > > > drm_sched j
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 11:11:03 +0100 Boris Brezillon wrote: > On Thu, 12 Jan 2023 10:32:18 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > Hi Daniel, > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > Daniel Vetter wrote: > > > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > > wrote: > > > > > > > > > > Hi Daniel, > > > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > > > > > > > > > > Hi Jason, > > > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon > > > > > > > > > wrote: > > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to > > > > > > > > > > > > > have a 1 to 1 > > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > > this > > > > > > > > > > > > > seems a bit odd but let us explain the reasoning > > > > > > > > > > > > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > > guaranteed to be the same completion even if > > > > > > > > > > > > > targeting the same > > > > > > > > > hardware > > > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > > > scheduler, the > > > > > > > > > GuC, > > > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > > > submissions. If a > > > > > > > > > using > > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > > falls > > > > > > > > > > > > > apart as the TDR expects submission order == > > > > > > > > > > > > > completion order. > > > > > > > > > Using a > > > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity > > > > > > > > > > > > > solve this > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the > > > > > > > > > > > > same sort of > > > > > > > > > > > > issues to support Arm's new Mali GPU which is relying > > > > > > > > > > > > on a > > > > > > > > > FW-assisted > > > > > > > > > > > > scheduling scheme (you give the FW N streams to > > > > > > > > > > > > execute, and it does > > > > > > > > > > > > the scheduling between those N command streams, the > > > > > > > > > > > > kernel driver > > > > > > > > > > > > does timeslice scheduling to update the command streams > > > > > > > > > > > > passed to the > > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at some > > > > > > > > > > > > point, mostly > > > > > > > > > > > > because the integration with drm_sched was painful, but > > > > > > > > > > > > also because > > > > > > > > > I > > > > > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > > > > > timeslice-oriented scheduling model wasn't really > > > > > > > > > > > > future proof. > > > > > > > > > Giving > > > > > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler > > > > > > > > > > > > probably > > > > > > > > > might > > > > > > > > > > > > help for a few things (didn't think it through yet), > > > > > > > > > > > > but I feel it's > > > > > > > > > > > > coming short on other aspects we have to deal with on > > > > > > > > > > > > Arm GPUs. > > > > > > > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, > > > > > > > > > > > and I think I > > > > > > > > > > > have a better understanding of how you get away with > > > > > > > > > > > using drm_sched > > > > > > > > > > > while still controlling how scheduling is really done. > > > > > > > > > > > Here > > > > > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you > > > > > > > > > > > use the > > > > > > > > > > > drm_sched j
Re: [PATCH v10 0/9] Register Type-C mode-switch in DP bridge endpoints
On Thu, Jan 12, 2023 at 06:34:52AM +0200, Dmitry Baryshkov wrote: > On 12/01/2023 06:20, Pin-yen Lin wrote: > > > > This series introduces bindings for anx7625/it6505 to register Type-C > > mode-switch in their output endpoints, and use data-lanes property to > > describe the pin connections. > > Please cc everybody on all patches. Having received just a single patch made > me spend time on having to look them up on lore. Sorry but this seems a bit outdated requirement nowadays. Why? Because we have `b4` in each famous Linux distro and nice lore.kernel.org. It's really easy for the experienced maintainer to catch up the whole thread. Putting _all_ people on all patches may be an overkill. What people should really get is the cover letter (assuming that it explains well the structure of the series). The rest depends. -- With Best Regards, Andy Shevchenko
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > On Thu, 12 Jan 2023 11:11:03 +0100 > Boris Brezillon wrote: > > > On Thu, 12 Jan 2023 10:32:18 +0100 > > Daniel Vetter wrote: > > > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > > Hi Daniel, > > > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > > Daniel Vetter wrote: > > > > > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > > > wrote: > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > > > > > > > > > > > > > Hi Jason, > > > > > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made > > > > > > > > > > > > > > to have a 1 to 1 > > > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > > > this > > > > > > > > > > > > > > seems a bit odd but let us explain the reasoning > > > > > > > > > > > > > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > > > guaranteed to be the same completion even if > > > > > > > > > > > > > > targeting the same > > > > > > > > > > hardware > > > > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > > > > scheduler, the > > > > > > > > > > GuC, > > > > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > > > > submissions. If a > > > > > > > > > > using > > > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > > > falls > > > > > > > > > > > > > > apart as the TDR expects submission order == > > > > > > > > > > > > > > completion order. > > > > > > > > > > Using a > > > > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity > > > > > > > > > > > > > > solve this > > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the > > > > > > > > > > > > > same sort of > > > > > > > > > > > > > issues to support Arm's new Mali GPU which is relying > > > > > > > > > > > > > on a > > > > > > > > > > FW-assisted > > > > > > > > > > > > > scheduling scheme (you give the FW N streams to > > > > > > > > > > > > > execute, and it does > > > > > > > > > > > > > the scheduling between those N command streams, the > > > > > > > > > > > > > kernel driver > > > > > > > > > > > > > does timeslice scheduling to update the command > > > > > > > > > > > > > streams passed to the > > > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at > > > > > > > > > > > > > some point, mostly > > > > > > > > > > > > > because the integration with drm_sched was painful, > > > > > > > > > > > > > but also because > > > > > > > > > > I > > > > > > > > > > > > > felt trying to bend drm_sched to make it interact > > > > > > > > > > > > > with a > > > > > > > > > > > > > timeslice-oriented scheduling model wasn't really > > > > > > > > > > > > > future proof. > > > > > > > > > > Giving > > > > > > > > > > > > > drm_sched_entity exlusive access to a > > > > > > > > > > > > > drm_gpu_scheduler probably > > > > > > > > > > might > > > > > > > > > > > > > help for a few things (didn't think it through yet), > > > > > > > > > > > > > but I feel it's > > > > > > > > > > > > > coming short on other aspects we have to deal with on > > > > > > > > > > > > > Arm GPUs. > > > > > > > > > > > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how > > > > > > > > > > > > it > > > > > > > > > > > > instantiates the drm_sched_entity and > > > > > > > > > > > > drm_gpu_scheduler, and I think I > > > > > > > > > > > > have a better
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 12.01.23 um 10:59 schrieb Daniel Vetter:
> > On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > > > This one nukes all framebuffers, which is a bit much. In reality
> > > > gma500 is igpu and never shipped with anything discrete, so there should
> > > > not be any difference.
> > > >
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > >drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> > > > b/drivers/gpu/drm/gma500/psb_drv.c
> > > > index cd9c73f5a64a..9b0daf90dc50 100644
> > > > --- a/drivers/gpu/drm/gma500/psb_drv.c
> > > > +++ b/drivers/gpu/drm/gma500/psb_drv.c
> > > > @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev,
> > > > const struct pci_device_id *ent)
> > > > * TODO: Refactor psb_driver_load() to map vdc_reg earlier.
> > > > Then we
> > > > * might be able to read the framebuffer range from the
> > > > device.
> > > > */
> > > > - ret = drm_aperture_remove_framebuffers(true, &driver);
> > > > + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
> > > > &driver);
> > >
> > > This does not work. The comment just above the changed line explains why.
> > > The device uses shared memory similar to other integrated Intel chips. The
> > > console is somewhere in a 16 MiB range, which has been stolen by the BIOS
> > > from main memory. There's only a 1 MiB memory range on the device to
> > > program
> > > the device. Unless you want to refactor as described, this call has to
> > > cover
> > > the whole memory for now.
> >
> > Uh. So it's maybe not so pretty, but what if I just call both functions?
>
> That's ways more ugly IMHO.
>
> > That way we get the vga handling through the pci one, and the "make sure
> > there's no fb left" through the other one. Plus comment of course.
> >
> > Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
> > and that just feels all kinds of wrong to me.
>
> With your patch applied, aperture_detach_devices() does all the work of
> removing. I'd add the following internal functions:
>
> static void aperture_detach_head(bool is_primary)
> {
> /*
>* lengthy comment here
>*/
> if (is_primary)
> sysfb_disable()
> }
>
> static void aperture_detach_tail(bool remove_vga)
> {
> if (remove_vga) {
> aperture_detach_devices(VGA_PHYS_)
> vga_remove_vgacon()
> }
> }
>
> And call both of them at the beginning/end of
> aperture_remove_conflicting_devices() and
> aperture_remove_conflicting_pci_devices().
>
> You'd still need to primary argument to
> aperture_remove_conflicting_devices(), but there will be no code duplication
> with the aperture helpers and the purpose of each code fragment will be
> clearer.
Yeah I don't want the primary argument. Aside from this one case here it's
not needed. Also by pushing this special case into the one driver that
needs it we keep it contained, instead of spreading it all around.
Inflicting a parameter on every (and in total we have a lot of callers of
this stuff) just because of gma500 does not seem like a good idea to me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/vc4: bo: Fix drmm_mutex_init memory hog
On Thu, Jan 12, 2023 at 10:12:43AM +0100, Maxime Ripard wrote:
> Commit 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") converted,
> among other functions, vc4_create_object() to use drmm_mutex_init().
>
> However, that function is used to allocate a BO, and therefore the
> mutex needs to be freed much sooner than when the DRM device is removed
> from the system.
>
> For each buffer allocation we thus end up allocating a small structure
> as part of the DRM-managed mechanism that is never freed, eventually
> leading us to no longer having any free memory anymore.
>
> Let's switch back to mutex_init/mutex_destroy to deal with it properly.
>
> Fixes: 374146cad469 ("drm/vc4: Switch to drmm_mutex_init")
> Signed-off-by: Maxime Ripard
oops :-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index c2b7573bd92b..49320e4d595d 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -179,6 +179,7 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
> bo->validated_shader = NULL;
> }
>
> + mutex_destroy(&bo->madv_lock);
> drm_gem_dma_free(&bo->base);
> }
>
> @@ -406,9 +407,7 @@ struct drm_gem_object *vc4_create_object(struct
> drm_device *dev, size_t size)
> bo->madv = VC4_MADV_WILLNEED;
> refcount_set(&bo->usecnt, 0);
>
> - ret = drmm_mutex_init(dev, &bo->madv_lock);
> - if (ret)
> - return ERR_PTR(ret);
> + mutex_init(&bo->madv_lock);
>
> mutex_lock(&vc4->bo_lock);
> bo->label = VC4_BO_TYPE_KERNEL;
> --
> 2.39.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [v3,3/7] drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement
Hi Neil,
On 12.01.2023 10:35, Neil Armstrong wrote:
> On 11/01/2023 13:41, Marek Szyprowski wrote:
>> On 02.11.2022 19:07, Dmitry Baryshkov wrote:
>>> Use drm_connector's helpers enable_hpd and disable_hpd to enable and
>>> disable HPD automatically by the means of drm_kms_helper_poll_*
>>> functions. As the drm_bridge_connector_enable_hpd() and
>>> drm_bridge_connector_disable_hpd() functions are now unused, replace
>>> them with stubs to ease driver migration.
>>>
>>> Enabling the HPD from drm_bridge_connector_init() can happen too early,
>>> before the driver is prepared to handle HPD events. As the
>>> drm_bridge_connector_enable_hpd() is empty anyway, drop this call
>>> anyway.
>>>
>>> Signed-off-by: Dmitry Baryshkov
>>> ---
>>
>> This patch, merged to recent linux-next as commit 92d755d8f13b
>> ("drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD
>> enablement"), triggers the following warning on all my Amlogic Meson
>> based boards:
>>
>> [ cut here ]
>> Hot plug detection already enabled
>> WARNING: CPU: 2 PID: 285 at drivers/gpu/drm/drm_bridge.c:1257
>> drm_bridge_hpd_enable+0x90/0xa0
>> Modules linked in: snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo
>> dwmac_generic panfrost(+) reset_meson_audio_arb(+) drm_shmem_helper
>> meson_dw_hdmi(+) dw_hdmi rc_odroid drm_display_helper meson_ir(+)
>> gpu_sched meson_rng rng_core meson_gxbb_wdt crct10dif_ce dwmac_meson8b
>> stmmac_platform snd_soc_meson_axg_sound_card snd_soc_meson_card_utils
>> mdio_mux_meson_g12a stmmac meson_drm pwm_meson pcs_xpcs meson_canvas
>> snd_soc_meson_axg_tdm_interface rtc_meson_vrtc
>> snd_soc_meson_axg_tdm_formatter nvmem_meson_efuse display_connector
>> CPU: 2 PID: 285 Comm: systemd-udevd Not tainted 6.1.0-rc6+ #13236
>> Hardware name: Hardkernel ODROID-C4 (DT)
>> pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : drm_bridge_hpd_enable+0x90/0xa0
>> lr : drm_bridge_hpd_enable+0x90/0xa0
>> ...
>> Call trace:
>> drm_bridge_hpd_enable+0x90/0xa0
>> _drm_bridge_connector_enable_hpd+0x24/0x34
>
> Weird because _drm_bridge_connector_enable_hpd() has been removed with
> 4c00ac500d0e ("drm/bridge_connector: drop
> drm_bridge_connector_en/disable_hpd()")
The above log has been captured at commit 92d755d8f13b during bisecting,
so 4c00ac500d0e is not applied yet. Maybe I should have mention that.
The issue on top of linux-next is similar.
>
>> drm_kms_helper_poll_enable.part.0+0x50/0xd0
>
> It seems drm_kms_helper_poll_enable is called again by
> drm_helper_probe_single_connector_modes() because poll_running isn't set.
>
> Can you try with this change:
This fixes the issue on top of linux next-20230112. Thanks! Feel free to
add if you plan to submit it as a formal patch:
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH 1/9] arm64: dts: mediatek: mt8186: Add MTU3 nodes
On Wed, Jan 11, 2023 at 8:37 PM Allen-KH Cheng wrote: > > Add MTU3 nodes for MT8186 SoC. > > Signed-off-by: Allen-KH Cheng Tested-by: Chen-Yu Tsai
Re: [PATCH 7/9] arm64: dts: mediatek: mt8186: Add DPI node
On Wed, Jan 11, 2023 at 8:37 PM Allen-KH Cheng
wrote:
>
> Add DPI node for MT8186 SoC.
>
> Signed-off-by: Allen-KH Cheng
> ---
> arch/arm64/boot/dts/mediatek/mt8186.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> index c52f9be1e750..eab30ab01572 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> @@ -1230,6 +1230,23 @@
> power-domains = <&spm MT8186_POWER_DOMAIN_DIS>;
> };
>
> + dpi0: dpi@1400a000 {
You could drop the trailing 0 in the label, since there is only one
instance.
Tested-by: Chen-Yu Tsai
> + compatible = "mediatek,mt8186-dpi";
> + reg = <0 0x1400a000 0 0x1000>;
> + clocks = <&topckgen CLK_TOP_DPI>,
> +<&mmsys CLK_MM_DISP_DPI>,
> +<&apmixedsys CLK_APMIXED_TVDPLL>;
> + clock-names = "pixel", "engine", "pll";
> + assigned-clocks = <&topckgen CLK_TOP_DPI>;
> + assigned-clock-parents = <&topckgen
> CLK_TOP_TVDPLL_D2>;
> + interrupts = ;
> + status = "disabled";
> +
> + port {
> + dpi_out: endpoint { };
> + };
> + };
> +
> dsi0: dsi@14013000 {
> compatible = "mediatek,mt8186-dsi";
> reg = <0 0x14013000 0 0x1000>;
> --
> 2.18.0
>
Re: [PATCH v3] drm/vkms: reintroduce prepare_fb and cleanup_fb functions
On 01/11, Maíra Canal wrote:
> With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
> end}_fb_access with vmap"), the behavior of the shadow-plane helpers
> changed and the vunmap is now performed at the end of
> the current pageflip, instead of the end of the following pageflip.
Applied to drm-misc-next.
Thank you,
Melissa
>
> By performing the vunmap at the end of the current pageflip, invalid
> memory is accessed by the vkms during the plane composition, as the data
> is being unmapped before being used, as reported by the following
> warning:
>
> [ 275.866047] BUG: unable to handle page fault for address: b382814e8002
> [ 275.866055] #PF: supervisor read access in kernel mode
> [ 275.866058] #PF: error_code(0x) - not-present page
> [ 275.866061] PGD 167 P4D 167 PUD 110a067 PMD 46e3067 PTE 0
> [ 275.866066] Oops: [#1] PREEMPT SMP PTI
> [ 275.866070] CPU: 2 PID: 49 Comm: kworker/u8:2 Not tainted
> 6.1.0-rc6-00018-gb357e7ac1b73-dirty #54
> [ 275.866074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.16.1-2.fc37 04/01/2014
> [ 275.866076] Workqueue: vkms_composer vkms_composer_worker [vkms]
> [ 275.866084] RIP: 0010:XRGB_to_argb_u16+0x5c/0xa0 [vkms]
> [ 275.866092] Code: bf 56 0a 0f af 56 70 48 8b 76 28 01 ca 49 83 f8 02
> 41 b9 01 00 00 00 4d 0f 43 c8 48 01 f2 48 83 c2 02 31 f6 66 c7 04 f0 ff
> ff <0f> b6 0c b2 89 cf c1 e7 08 09 cf 66 89 7c f0 02 0f b6 4c b2 ff 89
> [ 275.866095] RSP: 0018:b382801b7db0 EFLAGS: 00010246
> [ 275.866098] RAX: 896336ace000 RBX: 896310e293c0 RCX:
>
> [ 275.866101] RDX: b382814e8002 RSI: RDI:
> b382801b7de8
> [ 275.866103] RBP: 1400 R08: 0280 R09:
> 0280
> [ 275.866105] R10: 0010 R11: c011d990 R12:
> 896302a1ece0
> [ 275.866107] R13: R14: R15:
> 80008001
> [ 275.866109] FS: () GS:89637dd0()
> knlGS:
> [ 275.866112] CS: 0010 DS: ES: CR0: 80050033
> [ 275.866114] CR2: b382814e8002 CR3: 03bb4000 CR4:
> 06e0
> [ 275.866120] Call Trace:
> [ 275.866123]
> [ 275.866124] compose_active_planes+0x1c4/0x380 [vkms]
> [ 275.866132] vkms_composer_worker+0x9f/0x130 [vkms]
> [ 275.866139] process_one_work+0x1c0/0x370
> [ 275.866160] worker_thread+0x221/0x410
> [ 275.866164] ? worker_clr_flags+0x50/0x50
> [ 275.866167] kthread+0xe1/0x100
> [ 275.866172] ? kthread_blkcg+0x30/0x30
> [ 275.866176] ret_from_fork+0x22/0x30
> [ 275.866181]
> [ 275.866182] Modules linked in: vkms
> [ 275.866186] CR2: b382814e8002
> [ 275.866191] ---[ end trace ]---
>
> Therefore, introduce again prepare_fb and cleanup_fb functions to the
> vkms, which were previously removed on commit b43e2ec03b0d ("drm/vkms:
> Let shadow-plane helpers prepare the plane's FB").
>
> Fixes: 359c6649cd9a ("drm/gem: Implement shadow-plane {begin, end}_fb_access
> with vmap")
> Acked-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
> Signed-off-by: Maíra Canal
> ---
> v1 -> v2:
> https://lore.kernel.org/dri-devel/19951367-2ef0-0f26-ddf0-893259d9a...@igalia.com/T/
>
> - Add kernel oops to the commit description (Melissa Wen).
> - s/introduce/reintroduce/ in the title (Melissa Wen).
> - Add Thomas's Acked-by.
>
> v2 -> v3:
> https://lore.kernel.org/dri-devel/20230106115759.213710-1-mca...@igalia.com/T/
>
> - Add Daniel's Reviewed-by.
> - Resend patch due to corrupted mailbox.
> ---
> drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index c3a845220e10..b3f8a115cc23 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -160,10 +160,44 @@ static int vkms_plane_atomic_check(struct drm_plane
> *plane,
> return 0;
> }
>
> +static int vkms_prepare_fb(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_shadow_plane_state *shadow_plane_state;
> + struct drm_framebuffer *fb = state->fb;
> + int ret;
> +
> + if (!fb)
> + return 0;
> +
> + shadow_plane_state = to_drm_shadow_plane_state(state);
> +
> + ret = drm_gem_plane_helper_prepare_fb(plane, state);
> + if (ret)
> + return ret;
> +
> + return drm_gem_fb_vmap(fb, shadow_plane_state->map,
> shadow_plane_state->data);
> +}
> +
> +static void vkms_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_shadow_plane_state *shadow_plane_state;
> + struct drm_framebuffer *fb = state->fb;
> +
> + if (!fb)
> + return;
> +
> + shadow_plane_state = to_drm_shadow_plane_state(state
[PATCH v2] drm: Optimize drm buddy top-down allocation method
We are observing performance drop in many usecases which include
games, 3D benchmark applications,etc.. To solve this problem, We
are strictly not allowing top down flag enabled allocations to
steal the memory space from cpu visible region.
The idea is, we are sorting each order list entries in
ascending order and compare the last entry of each order
list in the freelist and return the max block.
This patch improves the 3D benchmark scores and solves
fragmentation issues.
All drm buddy selftests are verfied.
drm_buddy: pass:6 fail:0 skip:0 total:6
Signed-off-by: Arunpravin Paneer Selvam
Acked-by: Christian König
Acked-by: Alex Deucher
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/drm_buddy.c | 81 -
1 file changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..3d1f50f481cf 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -38,6 +38,25 @@ static void drm_block_free(struct drm_buddy *mm,
kmem_cache_free(slab_blocks, block);
}
+static void list_insert_sorted(struct drm_buddy *mm,
+ struct drm_buddy_block *block)
+{
+ struct drm_buddy_block *node;
+ struct list_head *head;
+
+ head = &mm->free_list[drm_buddy_block_order(block)];
+ if (list_empty(head)) {
+ list_add(&block->link, head);
+ return;
+ }
+
+ list_for_each_entry(node, head, link)
+ if (drm_buddy_block_offset(block) <
drm_buddy_block_offset(node))
+ break;
+
+ __list_add(&block->link, node->link.prev, &node->link);
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -52,8 +71,7 @@ static void mark_free(struct drm_buddy *mm,
block->header &= ~DRM_BUDDY_HEADER_STATE;
block->header |= DRM_BUDDY_FREE;
- list_add(&block->link,
-&mm->free_list[drm_buddy_block_order(block)]);
+ list_insert_sorted(mm, block);
}
static void mark_split(struct drm_buddy_block *block)
@@ -387,20 +405,26 @@ alloc_range_bias(struct drm_buddy *mm,
}
static struct drm_buddy_block *
-get_maxblock(struct list_head *head)
+get_maxblock(struct drm_buddy *mm, unsigned int order)
{
struct drm_buddy_block *max_block = NULL, *node;
+ unsigned int i;
- max_block = list_first_entry_or_null(head,
-struct drm_buddy_block,
-link);
- if (!max_block)
- return NULL;
+ for (i = order; i <= mm->max_order; ++i) {
+ if (!list_empty(&mm->free_list[i])) {
+ node = list_last_entry(&mm->free_list[i],
+ struct drm_buddy_block,
+ link);
+ if (!max_block) {
+ max_block = node;
+ continue;
+ }
- list_for_each_entry(node, head, link) {
- if (drm_buddy_block_offset(node) >
- drm_buddy_block_offset(max_block))
- max_block = node;
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block)) {
+ max_block = node;
+ }
+ }
}
return max_block;
@@ -412,20 +436,23 @@ alloc_from_freelist(struct drm_buddy *mm,
unsigned long flags)
{
struct drm_buddy_block *block = NULL;
- unsigned int i;
+ unsigned int tmp;
int err;
- for (i = order; i <= mm->max_order; ++i) {
- if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
- block = get_maxblock(&mm->free_list[i]);
- if (block)
- break;
- } else {
- block = list_first_entry_or_null(&mm->free_list[i],
-struct drm_buddy_block,
-link);
- if (block)
- break;
+ if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
+ block = get_maxblock(mm, order);
+ if (block)
+ /* Store the obtained block order */
+ tmp = drm_buddy_block_order(block);
+ } else {
+ for (tmp = order; tmp <= mm->max_order; ++tmp) {
+ if (!list_empty(&mm->free_list[tmp])) {
+ block = list_last_entry(&mm->free_list[tmp],
+ struct drm_buddy_block,
+ link);
+
[PULL] drm-intel-next
Hi Dave & Daniel - Here's the first i915 feature pull towards v6.3. drm-intel-next-2023-01-12: drm/i915 feature pull #1 for v6.3: Features and functionality: - Meteorlake display enabling (Animesh, Luca, Stan, Jouni, Anusha) - DP MST DSC support (Stan) - Gamma/degamma readout support for the state checker (Ville) - Enable SDP split support for DP 2.0 (Vinod) - Add probe blocking support to i915.force_probe parameter (Rodrigo) - Enable Xe HP 4tile support (Jonathan) Refactoring and cleanups: - Color refactoring, especially related to DSB usage (Ville) - DSB refactoring (Ville) - DVO refactoring (Ville) - Backlight register and logging cleanups (Jani) - Avoid display direct calls to uncore (Maarten, Jani) - Add new "soc" sub-directory (Jani) - Refactor DSC platform support checks (Swati) Fixes: - Interlace modes are no longer supported starting at display version 12 (Ankit) - Use polling read for aux control (Arun) - DMC firmware no longer requires specific versions (Gustavo) - Fix PSR flickering and freeze issues (Jouni) - Fix ICL+ DSI GPIO handling (Jani) - Ratelimit errors in display engine irqs (Lucas) - Fix DP MST DSC bpp and timeslot calculations (Stan) - Fix CDCLK squash and crawl sequences (Ville, Anusha) - Fix bigjoiner checks for fused pipes (Ville) - Fix ADP+ degamma LUT size (Ville) - Fix DVO ch7xxx and sil164 suspend/resume (Ville) - Fix memory leak in VBT parsing (Xia Fukun) - Fix VBT packet port selection for dual link DSI (Mikko Kovanen) - Fix SDP infoframe product string for discrete graphics (Clint) - Fix VLV/CHV HDMI/DP audio enable (Ville) - Fix VRR delays and calculations (Ville) - No longer disable transcoder for PHY test pattern change (Khaled) - Fix dual PPS handling (Ville) - Fix timeout and wait for DDI BUF CTL active after enabling (Ankit) Merges: - Backmerge drm-next to sync up with v6.2-rc1 (Jani) BR, Jani. The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2: Linux 6.2-rc1 (2022-12-25 13:41:39 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-01-12 for you to fetch changes up to f71c9b7bc35ff7c1fb68d114903876eec658439b: drm/i915/display: Prune Interlace modes for Display >=12 (2023-01-12 12:46:12 +0530) drm/i915 feature pull #1 for v6.3: Features and functionality: - Meteorlake display enabling (Animesh, Luca, Stan, Jouni, Anusha) - DP MST DSC support (Stan) - Gamma/degamma readout support for the state checker (Ville) - Enable SDP split support for DP 2.0 (Vinod) - Add probe blocking support to i915.force_probe parameter (Rodrigo) - Enable Xe HP 4tile support (Jonathan) Refactoring and cleanups: - Color refactoring, especially related to DSB usage (Ville) - DSB refactoring (Ville) - DVO refactoring (Ville) - Backlight register and logging cleanups (Jani) - Avoid display direct calls to uncore (Maarten, Jani) - Add new "soc" sub-directory (Jani) - Refactor DSC platform support checks (Swati) Fixes: - Interlace modes are no longer supported starting at display version 12 (Ankit) - Use polling read for aux control (Arun) - DMC firmware no longer requires specific versions (Gustavo) - Fix PSR flickering and freeze issues (Jouni) - Fix ICL+ DSI GPIO handling (Jani) - Ratelimit errors in display engine irqs (Lucas) - Fix DP MST DSC bpp and timeslot calculations (Stan) - Fix CDCLK squash and crawl sequences (Ville, Anusha) - Fix bigjoiner checks for fused pipes (Ville) - Fix ADP+ degamma LUT size (Ville) - Fix DVO ch7xxx and sil164 suspend/resume (Ville) - Fix memory leak in VBT parsing (Xia Fukun) - Fix VBT packet port selection for dual link DSI (Mikko Kovanen) - Fix SDP infoframe product string for discrete graphics (Clint) - Fix VLV/CHV HDMI/DP audio enable (Ville) - Fix VRR delays and calculations (Ville) - No longer disable transcoder for PHY test pattern change (Khaled) - Fix dual PPS handling (Ville) - Fix timeout and wait for DDI BUF CTL active after enabling (Ankit) Merges: - Backmerge drm-next to sync up with v6.2-rc1 (Jani) Animesh Manna (1): drm/i915/mtl: update scaler source and destination limits for MTL Ankit Nautiyal (4): drm/i915/ddi: Align timeout for DDI_BUF_CTL active with Bspec drm/i915/ddi: Add missing wait-for-active for HDMI aligning with bspec updates drm/i915/display: Drop check for doublescan mode in modevalid drm/i915/display: Prune Interlace modes for Display >=12 Anusha Srivatsa (3): drm/i915/display: Add missing checks for cdclk crawling drm/i915/display: Add CDCLK Support for MTL drm/i915/display: Add missing CDCLK Squash support for MTL Arun R Murthy (1): drm/i915/dp: change aux_ctl reg read to polling read Gustavo Sousa (2): drm/i915/dmc: Update DG2 DMC version to v2.08 drm/i915/dmc: Do not require specific versions Jani Nikula (22):
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 11:42:57 +0100 Daniel Vetter wrote: > On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > > On Thu, 12 Jan 2023 11:11:03 +0100 > > Boris Brezillon wrote: > > > > > On Thu, 12 Jan 2023 10:32:18 +0100 > > > Daniel Vetter wrote: > > > > > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > > > Hi Daniel, > > > > > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > > > > wrote: > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon > > > > > > > > wrote: > > > > > > > > > Hi Jason, > > > > > > > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon > > > > > > > > > > > wrote: > > > > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has > > > > > > > > > > > > > > > made to have a 1 to 1 > > > > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > > > > this > > > > > > > > > > > > > > > seems a bit odd but let us explain the reasoning > > > > > > > > > > > > > > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > > > > guaranteed to be the same completion even if > > > > > > > > > > > > > > > targeting the same > > > > > > > > > > > hardware > > > > > > > > > > > > > > > engine. This is because in XE we have a firmware > > > > > > > > > > > > > > > scheduler, the > > > > > > > > > > > GuC, > > > > > > > > > > > > > > > which allowed to reorder, timeslice, and preempt > > > > > > > > > > > > > > > submissions. If a > > > > > > > > > > > using > > > > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > > > > falls > > > > > > > > > > > > > > > apart as the TDR expects submission order == > > > > > > > > > > > > > > > completion order. > > > > > > > > > > > Using a > > > > > > > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity > > > > > > > > > > > > > > > solve this > > > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve > > > > > > > > > > > > > > the same sort of > > > > > > > > > > > > > > issues to support Arm's new Mali GPU which is > > > > > > > > > > > > > > relying on a > > > > > > > > > > > FW-assisted > > > > > > > > > > > > > > scheduling scheme (you give the FW N streams to > > > > > > > > > > > > > > execute, and it does > > > > > > > > > > > > > > the scheduling between those N command streams, the > > > > > > > > > > > > > > kernel driver > > > > > > > > > > > > > > does timeslice scheduling to update the command > > > > > > > > > > > > > > streams passed to the > > > > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at > > > > > > > > > > > > > > some point, mostly > > > > > > > > > > > > > > because the integration with drm_sched was painful, > > > > > > > > > > > > > > but also because > > > > > > > > > > > I > > > > > > > > > > > > > > felt trying to bend drm_sched to make it interact > > > > > > > > > > > > > > with a > > > > > > > > > > > > > > timeslice-oriented scheduling model wasn't really > > > > > > > > > > > > > > future proof. > > > > > > > > > > > Giving > > > > > > > > > > > > > > drm_sched_entity exlusive access to a > > > > > > > > > > > > > > drm_gpu_scheduler probably > > > > > > > > > > > might > > > > > > > > > > > > > > help for a few things (didn't think it through > > > > > > > > > > > > > > yet), but I feel it's > > > > > > > > > > > > > > coming short on other aspects we have to deal with > > >
Re: [PATCH] drm/ttm: Fix a regression causing kernel oops'es
On Thu, 2023-01-12 at 08:01 +0100, Christian König wrote:
> !! External Email
>
> Am 11.01.23 um 18:50 schrieb Zack Rusin:
> > From: Zack Rusin
> >
> > The branch is explicitly taken if ttm == NULL which means that to avoid
> > a null pointer reference the ttm object can not be used inside. Switch
> > back to dst_mem to avoid kernel oops'es.
> >
> > This fixes kernel oops'es with any buffer objects which don't have ttm_tt,
> > e.g. with vram based screen objects on vmwgfx.
> >
> > Signed-off-by: Zack Rusin
> > Fixes: e3c92eb4a84f ("drm/ttm: rework on ttm_resource to use size_t type")
> > Cc: Somalapuram Amaranath
> > Cc: Christian König
>
> Reviewed-by: Christian König
>
> Should I push it to drm-misc-fixes?
If you're not too busy that'd be great. Otherwise I can do it tomorrow.
z
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
Hi
Am 12.01.23 um 11:45 schrieb Daniel Vetter:
On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
Hi
Am 12.01.23 um 10:59 schrieb Daniel Vetter:
On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
Hi
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index cd9c73f5a64a..9b0daf90dc50 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
* TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
* might be able to read the framebuffer range from the device.
*/
- ret = drm_aperture_remove_framebuffers(true, &driver);
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
This does not work. The comment just above the changed line explains why.
The device uses shared memory similar to other integrated Intel chips. The
console is somewhere in a 16 MiB range, which has been stolen by the BIOS
from main memory. There's only a 1 MiB memory range on the device to program
the device. Unless you want to refactor as described, this call has to cover
the whole memory for now.
Uh. So it's maybe not so pretty, but what if I just call both functions?
That's ways more ugly IMHO.
That way we get the vga handling through the pci one, and the "make sure
there's no fb left" through the other one. Plus comment of course.
Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
and that just feels all kinds of wrong to me.
With your patch applied, aperture_detach_devices() does all the work of
removing. I'd add the following internal functions:
static void aperture_detach_head(bool is_primary)
{
/*
* lengthy comment here
*/
if (is_primary)
sysfb_disable()
}
static void aperture_detach_tail(bool remove_vga)
{
if (remove_vga) {
aperture_detach_devices(VGA_PHYS_)
vga_remove_vgacon()
}
}
And call both of them at the beginning/end of
aperture_remove_conflicting_devices() and
aperture_remove_conflicting_pci_devices().
You'd still need to primary argument to
aperture_remove_conflicting_devices(), but there will be no code duplication
with the aperture helpers and the purpose of each code fragment will be
clearer.
Yeah I don't want the primary argument. Aside from this one case here it's
not needed. Also by pushing this special case into the one driver that
needs it we keep it contained, instead of spreading it all around.
Inflicting a parameter on every (and in total we have a lot of callers of
this stuff) just because of gma500 does not seem like a good idea to me.
Unfortunately, vgacon and vgaarb require a PCI device. I don't like the
proposal, but maybe it's the best for now. So go ahead if you like. I do
expect that this needs additional work in future, however.
Just some more thoughts.
Grep for drm_aperture_remove_framebuffers(). Within DRM there are really
just 10 drivers calling this function (vs. 12 callers of
drm_aperture_remove_conflicting_pci_framebuffers()). In fbdev, there are
many callers of the PCI helper (~40) and apparently only 3 for the
non-PCI one. The other drivers are panels, USB, MIPI, etc and don't
interact with the system framebuffer. Compared to the overall number of
drivers, we have surprisingly few 'traditional graphics cards' in DRM.
Another thing is that gma500 and the other 9 drivers simply don't bother
to get the framebuffer range. They should be reworked to fetch the
configured framebuffer from the device and release that region only. The
practical impact is close to zero, so it hasn't happened.
Best regards
Thomas
-Daniel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/5] drm/amdgpu: Remove redundant framebuffer format check
Reviewed-by: Simon Ser
Re: [PATCH 3/5] drm/i915: Remove redundant framebuffer format check
The Intel counterpart is also: Reviewed-by: Simon Ser
Re: [PATCH v10 9/9] drm/bridge: it6505: Register Type C mode switches
On Thu, Jan 12, 2023 at 12:22 PM Pin-yen Lin wrote: > > Register USB Type-C mode switches when the "mode-switch" property and > relevant port are available in Device Tree. Configure the "lane_swap" > state based on the entered alternate mode for a specific Type-C > connector, which ends up updating the lane swap registers of the it6505 > chip. > > Signed-off-by: Pin-yen Lin Tested-by: Chen-Yu Tsai
Re: [PATCH 3/5] drm/i915: Remove redundant framebuffer format check
On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote:
> Now that framebuffer_check() verifies that the format is properly
> supported, there is no need to check it again on i915's inside
> helpers.
>
> Therefore, remove the redundant framebuffer format check from the
> intel_framebuffer_init() function, letting framebuffer_check()
> perform the framebuffer validation.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 63137ae5ab21..230b729e42d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1914,15 +1914,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> }
> }
>
> - if (!drm_any_plane_has_format(&dev_priv->drm,
> - mode_cmd->pixel_format,
> - mode_cmd->modifier[0])) {
> - drm_dbg_kms(&dev_priv->drm,
> - "unsupported pixel format %p4cc / modifier
> 0x%llx\n",
> - &mode_cmd->pixel_format, mode_cmd->modifier[0]);
> - goto err;
> - }
> -
This doesn't work for the legacy tiling->modifier path.
> /*
>* gen2/3 display engine uses the fence if present,
>* so the tiling mode must match the fb modifier exactly.
> --
> 2.39.0
--
Ville Syrjälä
Intel
Re: [PATCH 5.10 1/1] drm/amdkfd: Check for null pointer after calling kmemdup
On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> From: Jiasheng Jiang
>
> [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
>
> As the possible failure of the allocation, kmemdup() may return NULL
> pointer.
> Therefore, it should be better to check the 'props2' in order to prevent
> the dereference of NULL pointer.
>
> Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
> Signed-off-by: Jiasheng Jiang
> Reviewed-by: Felix Kuehling
> Signed-off-by: Felix Kuehling
> Signed-off-by: Alex Deucher
> Signed-off-by: Dragos-Marian Panait
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 86b4dadf772e..02e3c650ed1c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -408,6 +408,9 @@ static int kfd_parse_subtype_iolink(struct
> crat_subtype_iolink *iolink,
> return -ENODEV;
> /* same everything but the other direction */
> props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
> + if (!props2)
> + return -ENOMEM;
Not going to queue this up as this is a bogus CVE.
[PULL] drm-misc-next
Hi Dave and Daniel, here's the drm-misc-next PR for this week. Best regards Thomas drm-misc-next-2023-01-12: drm-misc-next for v6.3: UAPI Changes: * fourcc: Document Open Source user waiver Cross-subsystem Changes: * firmware: fix color-format selection for system framebuffers Core Changes: * format-helper: Add conversion from XRGB to various sysfb formats; Make XRGB the only driver-emulated legacy format * fb-helper: Avoid blank consoles from selecting an incorrect color format * probe-helper: Enable/disable HPD on connectors plus driver updates * Use drm_dbg_ helpers in several places * docs: Document defaults for CRTC backgrounds; Document use of drm_minor Driver Changes: * arm/hdlcd: Use new debugfs helpers * gud: Use new debugfs helpers * panel: Support Visionox VTDR6130 AMOLED DSI; Support Himax HX8394; Convert many drivers to common generic DSI write-sequence helper * v3d: Do not opencode drm_gem_object_lookup() * vc4: Various HVS an CRTC fixes * vkms: Fix SEGFAULT from incorrect GEM-buffer mapping * Convert various drivers to i2c probe_new() The following changes since commit 2591939e881cf728b6ac45971eeec2f58051c101: drm/virtio: Spiff out cmd queue/response traces (2023-01-02 17:51:27 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-01-12 for you to fetch changes up to 6e41acd2e5353c5362e0d5c2f5ba495c54ff555e: drm/vkms: reintroduce prepare_fb and cleanup_fb functions (2023-01-12 09:46:19 -0100) drm-misc-next for v6.3: UAPI Changes: * fourcc: Document Open Source user waiver Cross-subsystem Changes: * firmware: fix color-format selection for system framebuffers Core Changes: * format-helper: Add conversion from XRGB to various sysfb formats; Make XRGB the only driver-emulated legacy format * fb-helper: Avoid blank consoles from selecting an incorrect color format * probe-helper: Enable/disable HPD on connectors plus driver updates * Use drm_dbg_ helpers in several places * docs: Document defaults for CRTC backgrounds; Document use of drm_minor Driver Changes: * arm/hdlcd: Use new debugfs helpers * gud: Use new debugfs helpers * panel: Support Visionox VTDR6130 AMOLED DSI; Support Himax HX8394; Convert many drivers to common generic DSI write-sequence helper * v3d: Do not opencode drm_gem_object_lookup() * vc4: Various HVS an CRTC fixes * vkms: Fix SEGFAULT from incorrect GEM-buffer mapping * Convert various drivers to i2c probe_new() Abel Vesa (2): drm/panel-edp: fix name for IVO product id 854b drm/panel-edp: add IVO M133NW4J panel entry Daniel Vetter (2): drm/fourcc: Document open source user waiver drm: document better that drivers shouldn't use drm_minor directly Dave Stevenson (12): drm/vc4: hvs: Configure the HVS COB allocations drm/vc4: hvs: Set AXI panic modes drm/vc4: hvs: SCALER_DISPBKGND_AUTOHS is only valid on HVS4 drm/vc4: hvs: Correct interrupt masking bit assignment for HVS5 drm/vc4: hvs: Support zpos on all planes drm/vc4: hvs: Fix colour order for xRGB1555 on HVS5 drm/vc4: hvs: Add DRM 210101010 RGB formats drm/vc4: plane: Allow using 0 as a pixel order value drm/vc4: plane: Omit pixel_order from the hvs_format for hvs5 only formats drm/vc4: plane: Add 3:3:2 and 4:4:4:4 RGB/RGBX/RGBA formats drm/vc4: Add comments for which HVS_PIXEL_ORDER_xxx defines apply drm/vc4: hdmi: Correct interlaced timings again Dmitry Baryshkov (7): drm/poll-helper: merge drm_kms_helper_poll_disable() and _fini() drm/probe-helper: enable and disable HPD on connectors drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement drm/imx/dcss: stop using drm_bridge_connector_en/disable_hpd() drm/msm/hdmi: stop using drm_bridge_connector_en/disable_hpd() drm/omap: stop using drm_bridge_connector_en/disable_hpd() drm/bridge_connector: drop drm_bridge_connector_en/disable_hpd() Javier Martinez Canillas (17): drm/mipi-dsi: Fix mipi_dsi_dcs_write_seq() macro definition format drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro dt-bindings: display: Add Himax HX8394 panel controller MAINTAINERS: Add entry for Himax HX8394 panel controller driver drm/panel-asus-z00t-tm5p5-n35596: Drop custom DSI write macros drm/panel-sitronix-st7703: Drop custom DSI write macros drm/panel-leadtek-ltk050h3146w: Drop custom DSI write macro drm/panel-elida-kd35t133: Drop custom DSI write macro drm/panel-boe-bf060y8m-aj0: Drop custom DSI write macro drm/panel-novatek-nt35950: Drop custom DSI write macro drm/panel-jdi-fhd-r63452: Drop custom DSI write macros drm/panel-samsung-s6e88a0-ams452ef01: Drop custom DSI write mac
Re: [PATCH] drm/ttm: Fix a regression causing kernel oops'es
Am 12.01.23 um 13:11 schrieb Zack Rusin:
On Thu, 2023-01-12 at 08:01 +0100, Christian König wrote:
!! External Email
Am 11.01.23 um 18:50 schrieb Zack Rusin:
From: Zack Rusin
The branch is explicitly taken if ttm == NULL which means that to avoid
a null pointer reference the ttm object can not be used inside. Switch
back to dst_mem to avoid kernel oops'es.
This fixes kernel oops'es with any buffer objects which don't have ttm_tt,
e.g. with vram based screen objects on vmwgfx.
Signed-off-by: Zack Rusin
Fixes: e3c92eb4a84f ("drm/ttm: rework on ttm_resource to use size_t type")
Cc: Somalapuram Amaranath
Cc: Christian König
Reviewed-by: Christian König
Should I push it to drm-misc-fixes?
If you're not too busy that'd be great. Otherwise I can do it tomorrow.
Done.
z
[PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2023-01-12: Several fixes for amdgpu (all addressing issues with fences), yet another orientation quirk for a Lenovo device, a use-after-free fix for virtio, a regression fix in TTM and a performance regression in drm buddy. The following changes since commit 83e79ae3216c70f2b63c935a4e089d1620e8ef01: Merge tag 'drm-misc-fixes-2023-01-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-01-05 09:43:37 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-01-12 for you to fetch changes up to 5640e81607152d7f2d2558227c0f6cb78b8f39cf: drm: Optimize drm buddy top-down allocation method (2023-01-12 13:50:28 +0100) Several fixes for amdgpu (all addressing issues with fences), yet another orientation quirk for a Lenovo device, a use-after-free fix for virtio, a regression fix in TTM and a performance regression in drm buddy. Arunpravin Paneer Selvam (1): drm: Optimize drm buddy top-down allocation method Christian König (3): drm/amdgpu: fix another missing fence reference in the CS code drm/amdgpu: fix missing dma_fence_put in error path drm/amdgpu: fix pipeline sync v2 Patrick Thompson (1): drm: Add orientation quirk for Lenovo ideapad D330-10IGL Rob Clark (1): drm/virtio: Fix GEM handle creation UAF Thomas Zimmermann (1): drm/nouveau: Remove file nouveau_fbcon.c Zack Rusin (2): drm/vmwgfx: Remove rcu locks from user resources drm/ttm: Fix a regression causing kernel oops'es drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 51 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 +- drivers/gpu/drm/drm_buddy.c| 81 ++-- drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 + drivers/gpu/drm/nouveau/nouveau_fbcon.c| 613 - drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +- drivers/gpu/drm/vmwgfx/ttm_object.c| 41 +- drivers/gpu/drm/vmwgfx/ttm_object.h| 14 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 38 -- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 18 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 176 --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 33 -- 13 files changed, 202 insertions(+), 894 deletions(-) delete mode 100644 drivers/gpu/drm/nouveau/nouveau_fbcon.c signature.asc Description: PGP signature
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) changed: What|Removed |Added CC||regressi...@leemhuis.info --- Comment #9 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressi...@leemhuis.info) --- FWIW, I just wanted to add this to the regression tracking, but 6.0.y is EOL now; and it seems 6.1.y works. Greg might do another fixup release, but maybe investigating this further is not worth it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v10 1/9] device property: Add remote endpoint to devcon matcher
On Thu, Jan 12, 2023 at 12:20:56PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate those for a match too, instead
> of only looking at the remote parent devices. This is required when a
> device supports two mode switches in its endpoints, so we can't simply
> register the mode switch with the parent node.
>
> Signed-off-by: Prashant Malani
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
Acked-by: Heikki Krogerus
> ---
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
>
> Changes in v6:
> - New in v6
>
> drivers/base/property.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 2a5a37fcd998..48877af4e444 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1223,6 +1223,21 @@ static unsigned int fwnode_graph_devcon_matches(struct
> fwnode_handle *fwnode,
> break;
> }
>
> + /*
> + * Some drivers may register devices for endpoints. Check
> + * the remote-endpoints for matches in addition to the remote
> + * port parent.
> + */
> + node = fwnode_graph_get_remote_endpoint(ep);
> + if (fwnode_device_is_available(node)) {
> + ret = match(node, con_id, data);
> + if (ret) {
> + if (matches)
> + matches[count] = ret;
> + count++;
> + }
> + }
> +
> node = fwnode_graph_get_remote_port_parent(ep);
> if (!fwnode_device_is_available(node)) {
> fwnode_handle_put(node);
> --
> 2.39.0.314.g84b9a713c41-goog
--
heikki
Re: [PATCH v10 2/9] platform/chrome: cros_ec_typec: Purge blocking switch devlinks
On Thu, Jan 12, 2023 at 12:20:57PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When using OF graph, the fw_devlink code will create links between the
> individual port driver (cros-ec-typec here) and the parent device for
> a Type-C switch (like mode-switch). Since the mode-switch will in turn
> have the usb-c-connector (i.e the child of the port driver) as a
> supplier, fw_devlink will not be able to resolve the cyclic dependency
> correctly.
>
> As a result, the mode-switch driver probe() never runs, so mode-switches
> are never registered. Because of that, the port driver probe constantly
> fails with -EPROBE_DEFER, because the Type-C connector class requires all
> switch devices to be registered prior to port registration.
>
> To break this deadlock and allow the mode-switch registration to occur,
> purge all the usb-c-connector nodes' absent suppliers. This eliminates
> the connector as a supplier for a switch and allows it to be probed.
>
> Signed-off-by: Prashant Malani
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
FWIW:
Acked-by: Heikki Krogerus
> ---
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
>
> Changes in v7:
> - Fix the long comment lines
>
> Changes in v6:
> - New in v6
>
> drivers/platform/chrome/cros_ec_typec.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index 2a7ff14dc37e..302474a647cc 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -382,6 +382,16 @@ static int cros_typec_init_ports(struct cros_typec_data
> *typec)
> return -EINVAL;
> }
>
> + /*
> + * OF graph may have set up some device links with switches,
> + * since connectors have their own compatible. Purge these
> + * to avoid a deadlock in switch probe (the switch mistakenly
> + * assumes the connector is a supplier).
> + */
> + if (dev_of_node(dev))
> + device_for_each_child_node(dev, fwnode)
> + fw_devlink_purge_absent_suppliers(fwnode);
> +
> /* DT uses "reg" to specify port number. */
> port_prop = dev->of_node ? "reg" : "port-number";
> device_for_each_child_node(dev, fwnode) {
> --
> 2.39.0.314.g84b9a713c41-goog
--
heikki
Re: [PATCH v10 1/9] device property: Add remote endpoint to devcon matcher
Hi Pin-yen,
On Thu, Jan 12, 2023 at 12:20:56PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate those for a match too, instead
> of only looking at the remote parent devices. This is required when a
> device supports two mode switches in its endpoints, so we can't simply
> register the mode switch with the parent node.
>
> Signed-off-by: Prashant Malani
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
>
> ---
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
>
> Changes in v6:
> - New in v6
>
> drivers/base/property.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 2a5a37fcd998..48877af4e444 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1223,6 +1223,21 @@ static unsigned int fwnode_graph_devcon_matches(struct
> fwnode_handle *fwnode,
> break;
> }
>
> + /*
> + * Some drivers may register devices for endpoints. Check
> + * the remote-endpoints for matches in addition to the remote
> + * port parent.
> + */
> + node = fwnode_graph_get_remote_endpoint(ep);
> + if (fwnode_device_is_available(node)) {
> + ret = match(node, con_id, data);
> + if (ret) {
> + if (matches)
> + matches[count] = ret;
> + count++;
> + }
> + }
Aren't you missing fwnode_handle-put(node) here??
> +
> node = fwnode_graph_get_remote_port_parent(ep);
> if (!fwnode_device_is_available(node)) {
> fwnode_handle_put(node);
--
Kind regards,
Sakari Ailus
[PATCH] drm/nouveau: Remove support for legacy contexts/buffers
Remove nouveau's support for legacy contexts and buffers. It was
required by libdrm earlier than 2.4.33, released in March 2012. A
previous attempt in 2013 to remove the functionality [1] had to be
reverted [2] as there were still users left. Libdrm 2.4.33 is now
almost 11 years old and it is time for userspace to move on.
With the nouveau code gone, we can also remove the driver-feature
bit DRIVER_KMS_LEGACY_CONTEXT.
Signed-off-by: Thomas Zimmermann
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c510133d93dd6f15ca040733ba7b2891ed61fd1
# 1
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
# 2
---
drivers/gpu/drm/drm_bufs.c| 12 +++--
drivers/gpu/drm/drm_context.c | 36 +--
drivers/gpu/drm/nouveau/Kconfig | 12 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +++-
include/drm/drm_drv.h | 7 --
5 files changed, 19 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..86700560fea2 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -423,8 +423,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!(capable(CAP_SYS_ADMIN) || map->type == _DRM_AGP || map->type ==
_DRM_SHM))
return -EPERM;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
@@ -469,8 +468,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
int idx;
int i;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
idx = map->offset;
@@ -570,8 +568,7 @@ EXPORT_SYMBOL(drm_legacy_rmmap_locked);
void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -628,8 +625,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
struct drm_map_list *r_list;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
mutex_lock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index c6e6a3e7219a..a0fc779e5e1e 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -59,8 +59,7 @@ struct drm_ctx_list {
*/
void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -97,8 +96,7 @@ static int drm_legacy_ctxbitmap_next(struct drm_device * dev)
*/
void drm_legacy_ctxbitmap_init(struct drm_device * dev)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
idr_init(&dev->ctx_idr);
@@ -114,8 +112,7 @@ void drm_legacy_ctxbitmap_init(struct drm_device * dev)
*/
void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -136,8 +133,7 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev,
struct drm_file *file)
{
struct drm_ctx_list *pos, *tmp;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->ctxlist_mutex);
@@ -182,8 +178,7 @@ int drm_legacy_getsareactx(struct drm_device *dev, void
*data,
struct drm_local_map *map;
struct drm_map_list *_entry;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
r
Re: [PATCH] drm/nouveau: Remove support for legacy contexts/buffers
If this patch gets accepted, I'd like to merge it via drm-misc-next
together with the legacy-driver removal patches.
Am 12.01.23 um 14:38 schrieb Thomas Zimmermann:
Remove nouveau's support for legacy contexts and buffers. It was
required by libdrm earlier than 2.4.33, released in March 2012. A
previous attempt in 2013 to remove the functionality [1] had to be
reverted [2] as there were still users left. Libdrm 2.4.33 is now
almost 11 years old and it is time for userspace to move on.
With the nouveau code gone, we can also remove the driver-feature
bit DRIVER_KMS_LEGACY_CONTEXT.
Signed-off-by: Thomas Zimmermann
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c510133d93dd6f15ca040733ba7b2891ed61fd1
# 1
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
# 2
---
drivers/gpu/drm/drm_bufs.c| 12 +++--
drivers/gpu/drm/drm_context.c | 36 +--
drivers/gpu/drm/nouveau/Kconfig | 12 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +++-
include/drm/drm_drv.h | 7 --
5 files changed, 19 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..86700560fea2 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -423,8 +423,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!(capable(CAP_SYS_ADMIN) || map->type == _DRM_AGP || map->type ==
_DRM_SHM))
return -EPERM;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
@@ -469,8 +468,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
int idx;
int i;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
idx = map->offset;
@@ -570,8 +568,7 @@ EXPORT_SYMBOL(drm_legacy_rmmap_locked);
void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -628,8 +625,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
struct drm_map_list *r_list;
int ret;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
mutex_lock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index c6e6a3e7219a..a0fc779e5e1e 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -59,8 +59,7 @@ struct drm_ctx_list {
*/
void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -97,8 +96,7 @@ static int drm_legacy_ctxbitmap_next(struct drm_device * dev)
*/
void drm_legacy_ctxbitmap_init(struct drm_device * dev)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
idr_init(&dev->ctx_idr);
@@ -114,8 +112,7 @@ void drm_legacy_ctxbitmap_init(struct drm_device * dev)
*/
void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
{
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->struct_mutex);
@@ -136,8 +133,7 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev,
struct drm_file *file)
{
struct drm_ctx_list *pos, *tmp;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
- !drm_core_check_feature(dev, DRIVER_LEGACY))
+ if (!drm_core_check_feature(dev, DRIVER_LEGACY))
return;
mutex_lock(&dev->ctxlist_mutex);
@@ -182,8 +178,7 @@ int drm_legacy_getsareactx(struct drm_device *dev, void
*data,
struct drm_local_map *map;
struct drm_map_list *_entry;
- if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY
Re: [PATCH v2 13/13] drm/bridge: lt9611: properly program the dual host mode
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
If the bridge is connected using both DSI ports, the driver should use
both of them all the time. Correct programming sequence to always use
dual-port mode if both dsi0 and dsi1 are connected.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 28 -
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index df9f015aa3a0..561da6bd2698 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -118,7 +118,7 @@ static int lt9611_mipi_input_digital(struct lt9611 *lt9611,
{ 0x8306, 0x0a },
};
- if (mode->hdisplay == 3840)
+ if (lt9611->dsi1_node)
reg_cfg[1].def = 0x03;
return regmap_multi_reg_write(lt9611->regmap, reg_cfg, ARRAY_SIZE(reg_cfg));
@@ -191,16 +191,6 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
{ 0x832d, 0x38 },
{ 0x8331, 0x08 },
};
- const struct reg_sequence reg_cfg2[] = {
- { 0x830b, 0x03 },
- { 0x830c, 0xd0 },
- { 0x8348, 0x03 },
- { 0x8349, 0xe0 },
- { 0x8324, 0x72 },
- { 0x8325, 0x00 },
- { 0x832a, 0x01 },
- { 0x834a, 0x10 },
- };
u8 pol = 0x10;
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
@@ -209,10 +199,18 @@ static void lt9611_pcr_setup(struct lt9611 *lt9611, const
struct drm_display_mod
pol |= 0x1;
regmap_write(lt9611->regmap, 0x831d, pol);
- if (mode->hdisplay == 3840)
- regmap_multi_reg_write(lt9611->regmap, reg_cfg2,
ARRAY_SIZE(reg_cfg2));
- else
- regmap_multi_reg_write(lt9611->regmap, reg_cfg,
ARRAY_SIZE(reg_cfg));
+ regmap_multi_reg_write(lt9611->regmap, reg_cfg, ARRAY_SIZE(reg_cfg));
+ if (lt9611->dsi1_node) {
+ unsigned int hact = mode->hdisplay;
+
+ hact >>= 2;
+ hact += 0x50;
+ hact = min(hact, 0x3e0U);
+ regmap_write(lt9611->regmap, 0x830b, hact / 256);
+ regmap_write(lt9611->regmap, 0x830c, hact % 256);
+ regmap_write(lt9611->regmap, 0x8348, hact / 256);
+ regmap_write(lt9611->regmap, 0x8349, hact % 256);
+ }
regmap_write(lt9611->regmap, 0x8326, pcr_m);
Reviewed-by: Neil Armstrong
[PATCH] drm/amd/display: Conversion to bool not necessary
A logical evaluation already results in bool. There is no need for using
a ternary operator based evaluation and bool conversion of the outcome.
Issue identified using boolconv.cocci Coccinelle semantic patch.
This was also reported by the Kernel Test Robot. Hence
Fixes: 473683a03495 ("drm/amd/display: Create a file dedicated for CRTC")
Reported-by: kernel test robot
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 22125daf9dcf..1e39d0939700 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -105,8 +105,7 @@ static void vblank_control_worker(struct work_struct *work)
else if (dm->active_vblank_irq_count)
dm->active_vblank_irq_count--;
- dc_allow_idle_optimizations(
- dm->dc, dm->active_vblank_irq_count == 0 ? true : false);
+ dc_allow_idle_optimizations(dm->dc, dm->active_vblank_irq_count == 0);
DRM_DEBUG_KMS("Allow idle optimizations (MALL): %d\n",
dm->active_vblank_irq_count == 0);
--
2.34.1
Re: [PATCH v2 11/13] drm/bridge: lt9611: rework infoframes handling
On 08/01/2023 17:56, Dmitry Baryshkov wrote:
Rework handling infoframes:
- Write full HDMI AVI infoframe instead of just fixing the VIC value
- Also send the HDMI Vendor Specific infoframe, as recommended by the
HDMI spec.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 57 +++--
1 file changed, 44 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 1396ab081f61..82af1f954cc6 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -59,7 +59,6 @@ struct lt9611 {
enum drm_connector_status status;
u8 edid_buf[EDID_SEG_SIZE];
- u32 vic;
};
#define LT9611_PAGE_CONTROL 0xff
@@ -352,12 +351,51 @@ static int lt9611_video_check(struct lt9611 *lt9611)
return temp;
}
-static void lt9611_hdmi_tx_digital(struct lt9611 *lt9611, bool is_hdmi)
+static void lt9611_hdmi_set_infoframes(struct lt9611 *lt9611,
+ struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
- regmap_write(lt9611->regmap, 0x8443, 0x46 - lt9611->vic);
- regmap_write(lt9611->regmap, 0x8447, lt9611->vic);
- regmap_write(lt9611->regmap, 0x843d, 0x0a); /* UD1 infoframe */
+ union hdmi_infoframe infoframe;
+ ssize_t len;
+ u8 iframes = 0x0a; /* UD1 infoframe */
+ u8 buf[32];
+ int ret;
+ int i;
+
+ ret = drm_hdmi_avi_infoframe_from_display_mode(&infoframe.avi,
+ connector,
+ mode);
+ if (ret < 0)
+ goto out;
+
+ len = hdmi_infoframe_pack(&infoframe, buf, sizeof(buf));
+ if (len < 0)
+ goto out;
+
+ for (i = 0; i < len; i++)
+ regmap_write(lt9611->regmap, 0x8440 + i, buf[i]);
+
+ ret =
drm_hdmi_vendor_infoframe_from_display_mode(&infoframe.vendor.hdmi,
+ connector,
+ mode);
+ if (ret < 0)
+ goto out;
+
+ len = hdmi_infoframe_pack(&infoframe, buf, sizeof(buf));
+ if (len < 0)
+ goto out;
+ for (i = 0; i < len; i++)
+ regmap_write(lt9611->regmap, 0x8474 + i, buf[i]);
+
+ iframes |= 0x20;
+
+out:
+ regmap_write(lt9611->regmap, 0x843d, iframes); /* UD1 infoframe */
+}
+
+static void lt9611_hdmi_tx_digital(struct lt9611 *lt9611, bool is_hdmi)
+{
if (is_hdmi)
regmap_write(lt9611->regmap, 0x82d6, 0x8c);
else
@@ -687,9 +725,7 @@ lt9611_bridge_atomic_enable(struct drm_bridge *bridge,
struct drm_connector_state *conn_state;
struct drm_crtc_state *crtc_state;
struct drm_display_mode *mode;
- struct hdmi_avi_infoframe avi_frame;
unsigned int postdiv;
- int ret;
connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
if (WARN_ON(!connector))
@@ -710,18 +746,13 @@ lt9611_bridge_atomic_enable(struct drm_bridge *bridge,
lt9611_mipi_video_setup(lt9611, mode);
lt9611_pcr_setup(lt9611, mode, postdiv);
- ret = drm_hdmi_avi_infoframe_from_display_mode(&avi_frame,
- connector,
- mode);
- if (!ret)
- lt9611->vic = avi_frame.video_code;
-
if (lt9611_power_on(lt9611)) {
dev_err(lt9611->dev, "power on failed\n");
return;
}
lt9611_mipi_input_analog(lt9611);
+ lt9611_hdmi_set_infoframes(lt9611, connector, mode);
lt9611_hdmi_tx_digital(lt9611, connector->display_info.is_hdmi);
lt9611_hdmi_tx_phy(lt9611);
Reviewed-by: Neil Armstrong
Re: [PATCH 3/5] drm/i915: Remove redundant framebuffer format check
Hi,
On 1/12/23 09:43, Ville Syrjälä wrote:
On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote:
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on i915's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
intel_framebuffer_init() function, letting framebuffer_check()
perform the framebuffer validation.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/i915/display/intel_fb.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 63137ae5ab21..230b729e42d6 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1914,15 +1914,6 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
}
}
- if (!drm_any_plane_has_format(&dev_priv->drm,
- mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
- drm_dbg_kms(&dev_priv->drm,
- "unsupported pixel format %p4cc / modifier
0x%llx\n",
- &mode_cmd->pixel_format, mode_cmd->modifier[0]);
- goto err;
- }
-
This doesn't work for the legacy tiling->modifier path.
Do you have any idea on how we could remove drm_any_plane_has_format() from
i915? Or is it strictly necessary to validate the modifier in the legacy
path?
Best Regards,
- Maíra Canal
/*
* gen2/3 display engine uses the fence if present,
* so the tiling mode must match the fb modifier exactly.
--
2.39.0
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes this week fix. There was only a small conflict in the multi-cast registers fix, but that's pretty trivial. Just go with the -gt-next version if needed on your side. drm-intel-fixes-2023-01-12: - Reserve enough fence slot for i915_vma_unbind_vsync (Nirmoy) - Fix potential use after free (Rob Clark) - Reset engines twice in case of reset failure (Chris) - Use multi-cast registers for SVG Unit registers (Gustavo) Thanks, Rodrigo. The following changes since commit b7bfaa761d760e72a969d116517eaa12e404c262: Linux 6.2-rc3 (2023-01-08 11:49:43 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-01-12 for you to fetch changes up to 58fc14e14d288d728bf48377b81bb77fd17bfe3f: drm/i915/gt: Cover rest of SVG unit MCR registers (2023-01-11 09:53:45 -0500) - Reserve enough fence slot for i915_vma_unbind_vsync (Nirmoy) - Fix potential use after free (Rob Clark) - Reset engines twice in case of reset failure (Chris) - Use multi-cast registers for SVG Unit registers (Gustavo) Chris Wilson (1): drm/i915/gt: Reset twice Gustavo Sousa (1): drm/i915/gt: Cover rest of SVG unit MCR registers Nirmoy Das (1): drm/i915: Reserve enough fence slot for i915_vma_unbind_async Rob Clark (1): drm/i915: Fix potential context UAFs drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++-- drivers/gpu/drm/i915/gt/intel_reset.c | 34 - drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++-- drivers/gpu/drm/i915/i915_vma.c | 2 +- 5 files changed, 51 insertions(+), 17 deletions(-)
Re: [PATCH 3/5] drm/i915: Remove redundant framebuffer format check
On Thu, Jan 12, 2023 at 11:07:59AM -0300, Maíra Canal wrote:
> Hi,
>
> On 1/12/23 09:43, Ville Syrjälä wrote:
> > On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote:
> >> Now that framebuffer_check() verifies that the format is properly
> >> supported, there is no need to check it again on i915's inside
> >> helpers.
> >>
> >> Therefore, remove the redundant framebuffer format check from the
> >> intel_framebuffer_init() function, letting framebuffer_check()
> >> perform the framebuffer validation.
> >>
> >> Signed-off-by: Maíra Canal
> >> ---
> >> drivers/gpu/drm/i915/display/intel_fb.c | 9 -
> >> 1 file changed, 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> >> b/drivers/gpu/drm/i915/display/intel_fb.c
> >> index 63137ae5ab21..230b729e42d6 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> >> @@ -1914,15 +1914,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> >> *intel_fb,
> >>}
> >>}
> >>
> >> - if (!drm_any_plane_has_format(&dev_priv->drm,
> >> -mode_cmd->pixel_format,
> >> -mode_cmd->modifier[0])) {
> >> - drm_dbg_kms(&dev_priv->drm,
> >> - "unsupported pixel format %p4cc / modifier
> >> 0x%llx\n",
> >> - &mode_cmd->pixel_format, mode_cmd->modifier[0]);
> >> - goto err;
> >> - }
> >> -
> >
> > This doesn't work for the legacy tiling->modifier path.
>
> Do you have any idea on how we could remove drm_any_plane_has_format() from
> i915? Or is it strictly necessary to validate the modifier in the legacy
> path?
I guess techinically we could skip it by knowing that X-tile is always
supported. However that may not hold in the future so not a soution I
really like. Also the drm_any_plane_has_format() call from
framebuffer_check() is too early, so instead of checking X-tile
vs. linear based on the tiling it's going to always assume linear.
--
Ville Syrjälä
Intel
Re: [PATCH 5.10 1/1] drm/amdkfd: Check for null pointer after calling kmemdup
On Thu, 12 Jan 2023 at 13:47, Greg KH wrote:
> On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> > From: Jiasheng Jiang
> >
> > [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
> >
> > As the possible failure of the allocation, kmemdup() may return NULL
> > pointer.
> > Therefore, it should be better to check the 'props2' in order to prevent
> > the dereference of NULL pointer.
> >
> > Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
> > Signed-off-by: Jiasheng Jiang
> > Reviewed-by: Felix Kuehling
> > Signed-off-by: Felix Kuehling
> > Signed-off-by: Alex Deucher
> > Signed-off-by: Dragos-Marian Panait
> > ---
> > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > index 86b4dadf772e..02e3c650ed1c 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > @@ -408,6 +408,9 @@ static int kfd_parse_subtype_iolink(struct
> > crat_subtype_iolink *iolink,
> > return -ENODEV;
> > /* same everything but the other direction */
> > props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
> > + if (!props2)
> > + return -ENOMEM;
>
> Not going to queue this up as this is a bogus CVE.
Are we at the point where CVE presence actually contraindicates
backporting? At least I'm getting a bit the feeling there's a surge of
automated (security) fixes that just don't hold up to any scrutiny.
Last week I had to toss out an fbdev locking patch due to static
checker that has no clue at all how refcounting works, and so
complained that things need more locking ... (that was -fixes, but
would probably have gone to stable too if I didn't catch it).
Simple bugfixes from random people was nice when it was checkpatch
stuff and I was fairly happy to take these aggressively in drm. But my
gut feeling says things seem to be shifting towards more advanced
tooling, but without more advanced understanding by submitters. Does
that holder in other areas too?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
On Thu, 12 Jan 2023 at 13:15, Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.01.23 um 11:45 schrieb Daniel Vetter:
> > On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 12.01.23 um 10:59 schrieb Daniel Vetter:
> >>> On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
> > not be any difference.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> > b/drivers/gpu/drm/gma500/psb_drv.c
> > index cd9c73f5a64a..9b0daf90dc50 100644
> > --- a/drivers/gpu/drm/gma500/psb_drv.c
> > +++ b/drivers/gpu/drm/gma500/psb_drv.c
> > @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev,
> > const struct pci_device_id *ent)
> >* TODO: Refactor psb_driver_load() to map vdc_reg earlier.
> > Then we
> >* might be able to read the framebuffer range from the
> > device.
> >*/
> > - ret = drm_aperture_remove_framebuffers(true, &driver);
> > + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
>
> This does not work. The comment just above the changed line explains why.
> The device uses shared memory similar to other integrated Intel chips.
> The
> console is somewhere in a 16 MiB range, which has been stolen by the BIOS
> from main memory. There's only a 1 MiB memory range on the device to
> program
> the device. Unless you want to refactor as described, this call has to
> cover
> the whole memory for now.
> >>>
> >>> Uh. So it's maybe not so pretty, but what if I just call both functions?
> >>
> >> That's ways more ugly IMHO.
> >>
> >>> That way we get the vga handling through the pci one, and the "make sure
> >>> there's no fb left" through the other one. Plus comment of course.
> >>>
> >>> Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
> >>> and that just feels all kinds of wrong to me.
> >>
> >> With your patch applied, aperture_detach_devices() does all the work of
> >> removing. I'd add the following internal functions:
> >>
> >> static void aperture_detach_head(bool is_primary)
> >> {
> >> /*
> >> * lengthy comment here
> >> */
> >> if (is_primary)
> >> sysfb_disable()
> >> }
> >>
> >> static void aperture_detach_tail(bool remove_vga)
> >> {
> >> if (remove_vga) {
> >> aperture_detach_devices(VGA_PHYS_)
> >> vga_remove_vgacon()
> >> }
> >> }
> >>
> >> And call both of them at the beginning/end of
> >> aperture_remove_conflicting_devices() and
> >> aperture_remove_conflicting_pci_devices().
> >>
> >> You'd still need to primary argument to
> >> aperture_remove_conflicting_devices(), but there will be no code
> >> duplication
> >> with the aperture helpers and the purpose of each code fragment will be
> >> clearer.
> >
> > Yeah I don't want the primary argument. Aside from this one case here it's
> > not needed. Also by pushing this special case into the one driver that
> > needs it we keep it contained, instead of spreading it all around.
> > Inflicting a parameter on every (and in total we have a lot of callers of
> > this stuff) just because of gma500 does not seem like a good idea to me.
>
> Unfortunately, vgacon and vgaarb require a PCI device. I don't like the
> proposal, but maybe it's the best for now. So go ahead if you like. I do
> expect that this needs additional work in future, however.
>
> Just some more thoughts.
>
> Grep for drm_aperture_remove_framebuffers(). Within DRM there are really
> just 10 drivers calling this function (vs. 12 callers of
> drm_aperture_remove_conflicting_pci_framebuffers()). In fbdev, there are
> many callers of the PCI helper (~40) and apparently only 3 for the
> non-PCI one. The other drivers are panels, USB, MIPI, etc and don't
> interact with the system framebuffer. Compared to the overall number of
> drivers, we have surprisingly few 'traditional graphics cards' in DRM.
This is largely historical. fbdev is from the 90s, when we had the
huge explosion in largely pci graphics cards, because that was the
place where all the growth and hence drivers were. 80% of these
companies/chipe all died within a short few years.
kms otoh had the huge growth in the 2010s, where there was the tail
end of the SoC mobile explosion, so that's where we have tons of
drivers. If you look at staging there's a pile more fbdev drivers for
SoC, but many of these never got beyond the "vendor hacked some stuff
together and shipped it" stage. So that's probably why they lack
polish like fw
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 at 13:08, Boris Brezillon wrote: > On Thu, 12 Jan 2023 11:42:57 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > > > On Thu, 12 Jan 2023 11:11:03 +0100 > > > Boris Brezillon wrote: > > > > > > > On Thu, 12 Jan 2023 10:32:18 +0100 > > > > Daniel Vetter wrote: > > > > > > > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > > > > Hi Daniel, > > > > > > > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon > > > > > > > > > wrote: > > > > > > > > > > Hi Jason, > > > > > > > > > > > > > > > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > > > > > > > > Jason Ekstrand wrote: > > > > > > > > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris > > > > > > > > > > > > Brezillon wrote: > > > > > > > > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > > > > > > > > Boris Brezillon > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has > > > > > > > > > > > > > > > > made to have a 1 to 1 > > > > > > > > > > > > > > > > mapping between a drm_gpu_scheduler and > > > > > > > > > > > > > > > > drm_sched_entity. At first > > > > > > > > > > > > this > > > > > > > > > > > > > > > > seems a bit odd but let us explain the > > > > > > > > > > > > > > > > reasoning below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple > > > > > > > > > > > > > > > > drm_sched_entity is not > > > > > > > > > > > > > > > > guaranteed to be the same completion even if > > > > > > > > > > > > > > > > targeting the same > > > > > > > > > > > > hardware > > > > > > > > > > > > > > > > engine. This is because in XE we have a > > > > > > > > > > > > > > > > firmware scheduler, the > > > > > > > > > > > > GuC, > > > > > > > > > > > > > > > > which allowed to reorder, timeslice, and > > > > > > > > > > > > > > > > preempt submissions. If a > > > > > > > > > > > > using > > > > > > > > > > > > > > > > shared drm_gpu_scheduler across multiple > > > > > > > > > > > > > > > > drm_sched_entity, the TDR > > > > > > > > > > > > falls > > > > > > > > > > > > > > > > apart as the TDR expects submission order == > > > > > > > > > > > > > > > > completion order. > > > > > > > > > > > > Using a > > > > > > > > > > > > > > > > dedicated drm_gpu_scheduler per > > > > > > > > > > > > > > > > drm_sched_entity solve this > > > > > > > > > > > > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve > > > > > > > > > > > > > > > the same sort of > > > > > > > > > > > > > > > issues to support Arm's new Mali GPU which is > > > > > > > > > > > > > > > relying on a > > > > > > > > > > > > FW-assisted > > > > > > > > > > > > > > > scheduling scheme (you give the FW N streams to > > > > > > > > > > > > > > > execute, and it does > > > > > > > > > > > > > > > the scheduling between those N command streams, > > > > > > > > > > > > > > > the kernel driver > > > > > > > > > > > > > > > does timeslice scheduling to update the command > > > > > > > > > > > > > > > streams passed to the > > > > > > > > > > > > > > > FW). I must admit I gave up on using drm_sched at > > > > > > > > > > > > > > > some point, mostly > > > > > > > > > > > > > > > because the integration with drm_sched was > > > > > > > > > > > > > > > painful, but also because > > > > > > > > > > > > I > > > > > > > > > > > > > > > felt trying to bend drm_sched to make it interact > > > > > > > > > > > > > > > with a > > > > > > > > > > > > > > > timeslice-oriented scheduling model wasn't really > > > > > > > > > > > > > > > future proof. > > > > > > > > > > > > Giving > > > > > > > > > > > > > > > drm_sched_entity exlusive access to a > > > > > > > > > > > > > > > drm_gpu_scheduler probably > > > > > > > > > > > > might > > > > > > > > > > > > > > > help for a few things (didn't think it through > > > > > > > > > > > > > > > yet), but I feel it's > > > > > > > > > > > > > > > coming short on other aspects w
[PATCH] drm/probe_helper: sort out poll_running vs poll_enabled
There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.
This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.
This fix the following warning reported after merging the HPD series:
Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257
drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card
snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif
adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : 89ef3740
x29: 89ef3740 x28: 09331f00 x27: 1000
x26: 0020 x25: 81148ed8 x24: 0a8fe000
x23: fffd x22: 05086348 x21: 81133ee0
x20: 0550d800 x19: 05086288 x18: 0006
x17: x16: 896ef008 x15: 972891004260
x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
x8 : 00250b00 x7 : 0003 x6 : 0011
x5 : x4 : bd986a48 x3 : 0001
x2 : x1 : x0 : 0025
Call trace:
drm_bridge_hpd_enable+0x94/0x9c [drm]
drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
drm_client_modeset_probe+0x204/0x1190 [drm]
__drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
dcss_kms_attach+0x1c8/0x254 [imx_dcss]
dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
platform_probe+0x70/0xcc
really_probe+0xc4/0x2e0
__driver_probe_device+0x80/0xf0
driver_probe_device+0xe0/0x164
__device_attach_driver+0xc0/0x13c
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1a0
device_initial_probe+0x1c/0x30
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x200/0x474
worker_thread+0x74/0x43c
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace ]---
Reported-by: Laurentiu Palcu
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_probe_helper.c | 110 +
1 file changed, 63 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 7973f2589ced..ef919d95fea6 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -222,6 +222,45 @@ drm_connector_mode_valid(struct drm_connector *connector,
return ret;
}
+static void drm_kms_helper_disable_hpd(struct drm_device *dev)
+{
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ const struct drm_connector_helper_funcs *funcs =
+ connector->helper_private;
+
+ if (funcs && funcs->disable_hpd)
+ funcs->disable_hpd(connector);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+}
+
+static bool drm_kms_helper_enable_hpd(struct drm_device *dev)
+{
+ bool poll = false;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ const struct drm_connector_helper_funcs *funcs =
+ connector->helper_private;
+
+ if (funcs && funcs->disable_hpd)
+ funcs->disable_hpd(connector);
+
+ if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
+DRM_CONNECTOR_POLL_DISCONNECT))
+ poll = true;
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ return poll;
+}
+
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
/**
* drm_kms_h
[linux-next:master] BUILD REGRESSION 0a093b2893c711d82622a9ab27da4f1172821336
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 0a093b2893c711d82622a9ab27da4f1172821336 Add linux-next specific files for 20230112 Error/Warning: (recently discovered and may have been fixed) aarch64-linux-ld: ID map text too big or misaligned drivers/gpu/drm/ttm/ttm_bo_util.c:364:32: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] drivers/gpu/drm/ttm/ttm_bo_util.c:429:17: error: implicit declaration of function 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration] drivers/gpu/drm/vc4/vc4_dsi.c:1829:14: error: no member named 'of_node' in 'struct drm_bridge' Unverified Error/Warning (likely false positive, please contact us if interested): net/rxrpc/recvmsg.c:384:10: warning: Local variable 'len' shadows outer argument [shadowArgument] net/rxrpc/rxkad.c:341:10: warning: Local variable 'buf' shadows outer variable [shadowVariable] net/rxrpc/rxkad.c:801:6: warning: Redundant initialization for 'ret'. The initialized value is overwritten before it is read. [redundantInitialization] net/rxrpc/sendmsg.c:197:2: warning: Syntax Error: AST broken, 'txb' doesn't have a parent. [internalAstError] Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allyesconfig | `-- aarch64-linux-ld:ID-map-text-too-big-or-misaligned |-- mips-allyesconfig | |-- drivers-gpu-drm-ttm-ttm_bo_util.c:error:implicit-declaration-of-function-vmap | `-- drivers-gpu-drm-ttm-ttm_bo_util.c:error:implicit-declaration-of-function-vunmap `-- sparc-randconfig-p002-20230112 |-- net-rxrpc-recvmsg.c:warning:Local-variable-len-shadows-outer-argument-shadowArgument |-- net-rxrpc-rxkad.c:warning:Local-variable-buf-shadows-outer-variable-shadowVariable |-- net-rxrpc-rxkad.c:warning:Redundant-initialization-for-ret-.-The-initialized-value-is-overwritten-before-it-is-read.-redundantInitialization `-- net-rxrpc-sendmsg.c:warning:Syntax-Error:AST-broken-txb-doesn-t-have-a-parent.-internalAstError clang_recent_errors `-- mips-buildonly-randconfig-r003-20230111 `-- drivers-gpu-drm-vc4-vc4_dsi.c:error:no-member-named-of_node-in-struct-drm_bridge elapsed time: 724m configs tested: 62 configs skipped: 2 gcc tested configs: x86_64allnoconfig powerpc allnoconfig x86_64 defconfig i386 randconfig-a001 x86_64 rhel-8.3 i386 randconfig-a003 i386defconfig i386 randconfig-a005 arc defconfig alpha defconfig x86_64 allyesconfig arm defconfig x86_64 rhel-8.3-func x86_64randconfig-a004 x86_64rhel-8.3-kselftests x86_64randconfig-a002 s390 allmodconfig um i386_defconfig x86_64randconfig-a013 i386 randconfig-a014 um x86_64_defconfig x86_64randconfig-a011 i386 randconfig-a012 i386 randconfig-a016 x86_64 rhel-8.3-syz ia64 allmodconfig s390defconfig m68k allyesconfig arc randconfig-r043-20230110 sh allmodconfig x86_64randconfig-a006 m68k allmodconfig x86_64randconfig-a015 x86_64 rhel-8.3-kunit s390 allyesconfig arm64allyesconfig arc allyesconfig x86_64 rhel-8.3-kvm mips allyesconfig x86_64 rhel-8.3-bpf alphaallyesconfig powerpc allmodconfig s390 randconfig-r044-20230110 arm allyesconfig riscvrandconfig-r042-20230110 i386 allyesconfig clang tested configs: i386 randconfig-a002 x86_64 rhel-8.3-rust i386 randconfig-a004 hexagon randconfig-r041-20230110 i386 randconfig-a013 i386 randconfig-a006 x86_64randconfig-a001 x86_64randconfig-a003 i386 randconfig-a011 x86_64randco
Re: [PATCH v2] drm/i915: Fix CFI violations in gt_sysfs
Hi Jocelyn,
On Thu, Jan 12, 2023 at 11:08:17AM +0100, Jocelyn Falempe wrote:
> This patch does also solve a kernel crash when reading
> /sys/class/drm/card1/gt/gt0/* on a skylake machine:
> https://bugzilla.redhat.com/show_bug.cgi?id=2154880
Interesting, I wonder what aspect of this patch fixes this because I am
not sure that is an intended consequence of this change but that is
still good to hear!
For the record, this is commit a8a4f0467d70 ("drm/i915: Fix CFI
violations in gt_sysfs") in mainline.
> Do you think it can be backported to stable releases ?
> Conflicts are trivial on top of v6.0 at least.
I had a report from another user of this crash affecting them with kCFI
so it is on my TODO to backport it to 6.1 (6.0 just went EOL) but I am
currently out of the office until next Wednesday so I won't be able to
get to it until then (as I would like to test the backport on affected
hardware). If someone wants to beat me to it, I won't complain ;)
Cheers,
Nathan
[Bug 216920] New: Running IDE eventually leads to BUG: kernel NULL pointer dereference
https://bugzilla.kernel.org/show_bug.cgi?id=216920 Bug ID: 216920 Summary: Running IDE eventually leads to BUG: kernel NULL pointer dereference Product: Drivers Version: 2.5 Kernel Version: 6.1.4-arch1-1 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: gabr...@sullice.com Regression: No Hello, I do my best to provide details, but I am very much a novice so please bear with me. I will not ghost this issue and I will be as helpful as I can be, but I will have difficulty patching my kernel, for example. My desktop has been freezing after its free memory nearly reaches zero. I can consistently reproduce this behavior within a few minutes of opening my IDE (any of the JetBrains products). I have noticed that if I leave my system on for many days, it will eventually report very little free memory and freeze. Unfortunately, I have not recovered for logs after these events. However, within minutes of opening my IDE my memory usage begins to increase rapidly. When I have nearly no free memory left, my desktop freezes. By running "journalctl -b -1" after these events, I am able to recover the error and stack trace included below. I searched for similar but reports and https://bugzilla.kernel.org/show_bug.cgi?id=216730 sounds similar, especially regarding the Linux 5 -> 6 upgrade. I believe the situation started (or became noticeably worse) after I upgraded in early December. Please let me know if I can provide any additional details. - Gabe BUG: kernel NULL pointer dereference, address: 0017 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP NOPTI CPU: 17 PID: 765 Comm: Xorg:cs0 Not tainted 6.1.4-arch1-1 #1 b56a0be67d6a5f69f99015da4a908cae98ee5acc Hardware name: ASUS System Product Name/ProArt Z690-CREATOR WIFI, BIOS 1003 01/19/2022 RIP: 0010:ttm_bo_swapout+0x5c/0x310 [ttm] Code: 31 c0 48 8b 87 70 01 00 00 4c 8d 44 24 07 48 c7 44 24 18 00 00 00 00 48 8d 4c 24 10 c6 44 24 07 00 48 c7 44 24 10 00 00 00 00 <8b> > RSP: 0018:a4f60684b838 EFLAGS: 00010246 RAX: 0007 RBX: 8ccd5cf2e058 RCX: a4f60684b848 RDX: 8cd23ebc2d58 RSI: RDI: 8ccd5cf2e058 RBP: 8cca0ede55c8 R08: a4f60684b83f R09: R10: a4f60684ba00 R11: 8cd2751e70e0 R12: 8cd661e415a0 R10: a4f60684ba00 R11: 8cd2751e70e0 R12: 8cd661e415a0 R13: 0cc0 R14: a4f60684ba38 R15: FS: 7f1c9b1ff6c0() GS:8cd96dc4() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0017 CR3: 000101c4e005 CR4: 00f70ee0 PKRU: 5554 Call Trace: ? __kmem_cache_alloc_node+0x1a5/0x2d0 ? amdgpu_gtt_mgr_new+0x40/0x130 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] ttm_device_swapout+0xf8/0x120 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ttm_global_swapout+0x50/0xc0 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ttm_tt_populate+0x82/0x140 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ttm_bo_handle_move_mem+0x15f/0x170 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ttm_bo_bounce_temp_buffer.constprop.0+0x9c/0xc0 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ? ttm_bo_handle_move_mem+0xb5/0x170 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] ttm_bo_validate+0xd5/0x160 [ttm 63a90b9054166370014bbe40c6fa1031268577f4] amdgpu_cs_bo_validate+0x98/0x280 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] amdgpu_cs_list_validate+0xf9/0x140 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] amdgpu_cs_ioctl+0x10a4/0x1f40 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] drm_ioctl_kernel+0xca/0x170 drm_ioctl+0x1eb/0x450 ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu e075343022af70307c8e70736313f8c62afdb58b] __x64_sys_ioctl+0x91/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x6b/0x90 ? do_syscall_64+0x6b/0x90 ? exit_to_user_mode_prepare+0x160/0x1d0 ? syscall_exit_to_user_mode+0x1b/0x40 ? do_syscall_64+0x6b/0x90 ? do_syscall_64+0x6b/0x90 ? do_syscall_64+0x6b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1ca7308c0f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> > RSP: 002b:7f1c9b1fe920 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7f1c9b1fea98 RCX: 7f1ca7308c0f RDX: 7f1c9b1fe9e0 RSI: c0186444 RDI: 0010 RBP: 7f1c9b1fe9e0 R08: 7f1c9b1feaf0 R09: 7f1c9b1fe9c0 R10: 55d
Re: [PATCH] drm: amd: display: Fix memory leakage
On 11/29/22 21:50, Konstantin Meskhidze wrote:
This commit fixes memory leakage in dc_construct_ctx() function.
Signed-off-by: Konstantin Meskhidze
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 997ab031f816..359e28d3567e 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -878,6 +878,7 @@ static bool dc_construct_ctx(struct dc *dc,
dc_ctx->perf_trace = dc_perf_trace_create();
if (!dc_ctx->perf_trace) {
+ kfree(dc_ctx);
ASSERT_CRITICAL(false);
return false;
}
Reviewed-by: Rodrigo Siqueira
And applied to amd-staging-drm-next.
Thanks
Siqueira
Re: [Intel-gfx] [PATCH 2/2] drm/ttm: replace busy placement with flags
Am 11.01.23 um 16:18 schrieb Matthew Auld: [SNIP] Currently "dim rebuild-tip" doesn't work for me because of a conflict in i915_gem_execbuffer.c Seems to be working now. Nope. When I do a fresh install with "drm setup" in a different working directly I run into exactly this problem again. On a different system "drm rebuild-tip" runs perfectly fine, so my educated guess is that some conflict resolution isn't applied on some systems. I've seen this phenomena couple of times with drm-tip now, but can't really make sense what's going wrong here. Daniel any idea? Christian. Any idea how to fix this? Thanks, Christian. [1] https://patchwork.freedesktop.org/project/intel-gfx-trybot/series/?ordering=-last_updated
Re: [PATCH] drm/amd/display: Fix set scaling doesn's work
On 1/11/23 10:19, Harry Wentland wrote: On 1/10/23 10:58, Rodrigo Siqueira Jordao wrote: On 11/22/22 06:20, hongao wrote: [Why] Setting scaling does not correctly update CRTC state. As a result dc stream state's src (composition area) && dest (addressable area) was not calculated as expected. This causes set scaling doesn's work. [How] Correctly update CRTC state when setting scaling property. Signed-off-by: hongao diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3e1ecca72430..a88a6f758748 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -9386,8 +9386,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, goto fail; } - if (dm_old_con_state->abm_level != - dm_new_con_state->abm_level) + if (dm_old_con_state->abm_level != dm_new_con_state->abm_level || + dm_old_con_state->scaling != dm_new_con_state->scaling) new_crtc_state->connectors_changed = true; } Hi, This change lgtm, and I also run it in our CI, and from IGT perspective, we are good. Harry, do you have any comment about this change? LGTM Reviewed-by: Harry Wentland Harry Thanks Siqueira Thanks, patch applied to amd-staging-drm-next.
[PATCH 1/1] drm: panel: Set connector type for Armadeus ST0700 Adapt panel
The Armadeus ST0700 Adapt is a DPI panel, set the connector type
accordingly.
Signed-off-by: Sébastien Szymanski
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 8a3b685c2fcc..22c579d79d01 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -843,6 +843,7 @@ static const struct panel_desc armadeus_st0700_adapt = {
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct drm_display_mode auo_b101aw03_mode = {
--
2.38.2
Re: [PATCH AUTOSEL 6.1 5/7] drm/amdgpu: Fix size validation for non-exclusive domains (v4)
Hi Sasha,
The patch in the link is a Fixes patch of the quoted patch, and should also go
in:
https://lore.kernel.org/all/20230104221935.113400-1-luben.tui...@amd.com/
Regards,
Luben
On 2022-12-31 15:04, Sasha Levin wrote:
> From: Luben Tuikov
>
> [ Upstream commit 7554886daa31eacc8e7fac9e15bbce67d10b8f1f ]
>
> Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the
> requested memory exists, else we get a kernel oops when dereferencing "man".
>
> v2: Make the patch standalone, i.e. not dependent on local patches.
> v3: Preserve old behaviour and just check that the manager pointer is not
> NULL.
> v4: Complain if GTT domain requested and it is uninitialized--most likely a
> bug.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: AMD Graphics
> Signed-off-by: Luben Tuikov
> Reviewed-by: Christian König
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 2e8f6cd7a729..33e266433e9b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -446,27 +446,24 @@ static bool amdgpu_bo_validate_size(struct
> amdgpu_device *adev,
>
> /*
>* If GTT is part of requested domains the check must succeed to
> - * allow fall back to GTT
> + * allow fall back to GTT.
>*/
> if (domain & AMDGPU_GEM_DOMAIN_GTT) {
> man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
>
> - if (size < man->size)
> + if (man && size < man->size)
> return true;
> - else
> - goto fail;
> - }
> -
> - if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
> + else if (!man)
> + WARN_ON_ONCE("GTT domain requested but GTT mem manager
> uninitialized");
> + goto fail;
> + } else if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
> man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
>
> - if (size < man->size)
> + if (man && size < man->size)
> return true;
> - else
> - goto fail;
> + goto fail;
> }
>
> -
> /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU */
> return true;
>
Re: [PATCH 5.10 1/1] drm/amdkfd: Check for null pointer after calling kmemdup
On Thu, Jan 12, 2023 at 04:26:45PM +0100, Daniel Vetter wrote:
> On Thu, 12 Jan 2023 at 13:47, Greg KH wrote:
> > On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> > > From: Jiasheng Jiang
> > >
> > > [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
> > >
> > > As the possible failure of the allocation, kmemdup() may return NULL
> > > pointer.
> > > Therefore, it should be better to check the 'props2' in order to prevent
> > > the dereference of NULL pointer.
> > >
> > > Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
> > > Signed-off-by: Jiasheng Jiang
> > > Reviewed-by: Felix Kuehling
> > > Signed-off-by: Felix Kuehling
> > > Signed-off-by: Alex Deucher
> > > Signed-off-by: Dragos-Marian Panait
> > > ---
> > > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > index 86b4dadf772e..02e3c650ed1c 100644
> > > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > @@ -408,6 +408,9 @@ static int kfd_parse_subtype_iolink(struct
> > > crat_subtype_iolink *iolink,
> > > return -ENODEV;
> > > /* same everything but the other direction */
> > > props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
> > > + if (!props2)
> > > + return -ENOMEM;
> >
> > Not going to queue this up as this is a bogus CVE.
>
> Are we at the point where CVE presence actually contraindicates
> backporting?
Some would say that that point passed a long time ago :)
> At least I'm getting a bit the feeling there's a surge of
> automated (security) fixes that just don't hold up to any scrutiny.
That has been happening a lot more in the past 6-8 months than in years
past with the introduction of more automated tools being present.
> Last week I had to toss out an fbdev locking patch due to static
> checker that has no clue at all how refcounting works, and so
> complained that things need more locking ... (that was -fixes, but
> would probably have gone to stable too if I didn't catch it).
>
> Simple bugfixes from random people was nice when it was checkpatch
> stuff and I was fairly happy to take these aggressively in drm. But my
> gut feeling says things seem to be shifting towards more advanced
> tooling, but without more advanced understanding by submitters. Does
> that holder in other areas too?
Again, yes, I have seen that a lot recently, especially with regards to
patches that purport to fix bugs yet obviously were never tested.
That being said, there are a few developers who are doing great things
with fault-injection testing and providing good patches for that. So we
can't just say that everyone using these tools has no clue.
thanks,
greg k-h
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, 12 Jan 2023 16:38:18 +0100 Daniel Vetter wrote: > > > > > > Also if you do the allocation in ->prepare_job with dma_fence and not > > > run_job, then I think can sort out fairness issues (if they do pop up) in > > > the drm/sched code instead of having to think about this in each driver. > > > > By allocation, you mean assigning a FW slot ID? If we do this allocation > > in ->prepare_job(), couldn't we mess up ordering? Like, > > lower-prio/later-queuing entity being scheduled before its pairs, > > because there's no guarantee on the job completion order (and thus the > > queue idleness order). I mean, completion order depends on the kind of > > job being executed by the queues, the time the FW actually lets the > > queue execute things and probably other factors. You can use metrics > > like the position in the LRU list + the amount of jobs currently > > queued to a group to guess which one will be idle first, but that's > > just a guess. And I'm not sure I see what doing this slot selection in > > ->prepare_job() would bring us compared to doing it in ->run_job(), > > where we can just pick the least recently used slot. > > In ->prepare_job you can let the scheduler code do the stalling (and > ensure fairness), in ->run_job it's your job. Yeah returning a fence in ->prepare_job() to wait for a FW slot to become idle sounds good. This fence would be signaled when one of the slots becomes idle. But I'm wondering why we'd want to select the slot so early. Can't we just do the selection in ->run_job()? After all, if the fence has been signaled, that means we'll find at least one slot that's ready when we hit ->run_job(), and we can select it at that point. > The current RFC doesn't > really bother much with getting this very right, but if the scheduler > code tries to make sure it pushes higher-prio stuff in first before > others, you should get the right outcome. Okay, so I'm confused again. We said we had a 1:1 drm_gpu_scheduler:drm_sched_entity mapping, meaning that entities are isolated from each other. I can see how I could place the dma_fence returned by ->prepare_job() in a driver-specific per-priority list, so the driver can pick the highest-prio/first-inserted entry and signal the associated fence when a slot becomes idle. But I have a hard time seeing how common code could do that if it doesn't see the other entities. Right now, drm_gpu_scheduler only selects the best entity among the registered ones, and there's only one entity per drm_gpu_scheduler in this case. > > The more important functional issue is that you must only allocate the > fw slot after all dependencies have signalled. Sure, but it doesn't have to be a specific FW slot, it can be any FW slot, as long as we don't signal more fences than we have slots available, right? > Otherwise you might get > a nice deadlock, where job A is waiting for the fw slot of B to become > free, and B is waiting for A to finish. Got that part, and that's ensured by the fact we wait for all regular deps before returning the FW-slot-available dma_fence in ->prepare_job(). This exact same fence will be signaled when a slot becomes idle. > > > > Few fw sched slots essentially just make fw scheduling unfairness more > > > prominent than with others, but I don't think it's fundamentally something > > > else really. > > > > > > If every ctx does that and the lru isn't too busted, they should then form > > > a nice orderly queue and cycle through the fw scheduler, while still being > > > able to get some work done. It's essentially the exact same thing that > > > happens with ttm vram eviction, when you have a total working set where > > > each process fits in vram individually, but in total they're too big and > > > you need to cycle things through. > > > > I see. > > > > > > > > > > I'll need to make sure this still works with the concept of group > > > > > (it's > > > > > not a single queue we schedule, it's a group of queues, meaning that > > > > > we > > > > > have N fences to watch to determine if the slot is busy or not, but > > > > > that should be okay). > > > > > > > > Oh, there's one other thing I forgot to mention: the FW scheduler is > > > > not entirely fair, it does take the slot priority (which has to be > > > > unique across all currently assigned slots) into account when > > > > scheduling groups. So, ideally, we'd want to rotate group priorities > > > > when they share the same drm_sched_priority (probably based on the > > > > position in the LRU). > > > > > > Hm that will make things a bit more fun I guess, especially with your > > > constraint to not update this too often. How strict is that priority > > > difference? If it's a lot, we might need to treat this more like execlist > > > and less like a real fw scheduler ... > > > > Strict as in, if two groups with same priority try to request an > > overlapping set of resources (cores or tilers), it can deadlock, so > > pretty strict I would say :-).
[RFC v3 00/12] DRM scheduling cgroup controller
From: Tvrtko Ursulin This series contains a proposal for a DRM scheduling cgroup controller which implements a weight based hierarchical GPU usage budget based controller similar in concept to some of the existing controllers. Motivation mostly comes from my earlier proposal where I identified that GPU scheduling lags significantly behind what is available for CPU and IO. Whereas back then I was proposing to somehow tie this with process nice, feedback mostly was that people wanted cgroups. So here it is - in the world of heterogenous computing pipelines I think it is time to do something about this gap. Code is not finished but should survive some light experimenting with. I am sharing it early since the topic has been controversial in the past. I hope to demonstrate there are gains to be had in real world usage(*), today, and that the concepts the proposal relies are well enough established and stable. *) Specifically under ChromeOS which uses cgroups to control CPU bandwith for VMs based on the window focused status. It can be demonstrated how GPU scheduling control can easily be integrated into that setup. *) Another real world example later in the cover letter. There should be no conflict with this proposal and any efforts to implement memory usage based controller. Skeleton DRM cgroup controller is deliberatly purely a skeleton patch where any further functionality can be added with no real conflicts. [In fact, perhaps scheduling is even easier to deal with than memory accounting.] Structure of the series is as follows: 1-2) Improve client ownership tracking in DRM core. 3) Adds a skeleton DRM cgroup controller with no functionality. 4-9) Laying down some infrastructure to enable the controller. 10) The controller itself. 11-12) i915 support for the controller. The proposals defines a delegation of duties between the tree parties: cgroup controller, DRM core and individual drivers. Two way communication interfaces are then defined to enable the delegation to work. DRM scheduling soft limits ~~ Because of the heterogenous hardware and driver DRM capabilities, soft limits are implemented as a loose co-operative (bi-directional) interface between the controller and DRM core. The controller configures the GPU time allowed per group and periodically scans the belonging tasks to detect the over budget condition, at which point it invokes a callback notifying the DRM core of the condition. DRM core provides an API to query per process GPU utilization and 2nd API to receive notification from the cgroup controller when the group enters or exits the over budget condition. Individual DRM drivers which implement the interface are expected to act on this in the best-effort manner only. There are no guarantees that the soft limits will be respected. DRM scheduling soft limits interface files ~~ drm.weight Standard cgroup weight based control [1, 1] used to configure the relative distributing of GPU time between the sibling groups. drm.period_us (Most probably only a debugging aid during RFC phase.) An integer representing the period with which the controller should look at the GPU usage by the group and potentially send the over/under budget signal. Value of zero (defaul) disables the soft limit checking. This builds upon the per client GPU utilisation work which landed recently for a few drivers. My thinking is that in principle, an intersect of drivers which support both that and some sort of scheduling control, like priorities, could also in theory support this controller. Another really interesting angle for this controller is that it mimics the same control menthod used by the CPU scheduler. That is the proportional/weight based GPU time budgeting. Which makes it easy to configure and does not need a new mental model. However, as the introduction mentions, GPUs are much more heterogenous and therefore the controller uses very "soft" wording as to what it promises. The general statement is that it can define budgets, notify clients when they are over them, and let individual drivers implement best effort handling of those conditions. Delegation of duties in the implementation goes likes this: * DRM cgroup controller implements the control files and the scanning loop. * DRM core is required to track all DRM clients belonging to processes so it can answer when asked how much GPU time is a process using. * DRM core also provides a call back which the controller will call when a certain process is over budget. * Individual drivers need to implement two similar hooks, but which work for a single DRM client. Over budget callback and GPU utilisation query. What I have demonstrated in practice is that when wired to i915, in a really primitive way where the over-budget condition simply lowers the scheduling priority, the concept can be almost equa
[RFC 01/12] drm: Track clients by tgid and not tid
From: Tvrtko Ursulin Thread group id (aka pid from userspace point of view) is a more interesting thing to show as an owner of a DRM fd, so track and show that instead of the thread id. In the next patch we will make the owner updated post file descriptor handover, which will also be tgid based to avoid ping-pong when multiple threads access the fd. Signed-off-by: Tvrtko Ursulin Cc: Zack Rusin Cc: linux-graphics-maintai...@vmware.com Cc: Alex Deucher Cc: "Christian König" Reviewed-by: Zack Rusin --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 4 ++-- drivers/gpu/drm/drm_file.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 00edc7002ee8..ca0181332578 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -969,7 +969,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m, void *unused) * Therefore, we need to protect this ->comm access using RCU. */ rcu_read_lock(); - task = pid_task(file->pid, PIDTYPE_PID); + task = pid_task(file->pid, PIDTYPE_TGID); seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid), task ? task->comm : ""); rcu_read_unlock(); diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index 4f643a490dc3..4855230ba2c6 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -80,7 +80,7 @@ static int drm_clients_info(struct seq_file *m, void *data) seq_printf(m, "%20s %5s %3s master a %5s %10s\n", "command", - "pid", + "tgid", "dev", "uid", "magic"); @@ -94,7 +94,7 @@ static int drm_clients_info(struct seq_file *m, void *data) bool is_current_master = drm_is_current_master(priv); rcu_read_lock(); /* locks pid_task()->comm */ - task = pid_task(priv->pid, PIDTYPE_PID); + task = pid_task(priv->pid, PIDTYPE_TGID); uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID; seq_printf(m, "%20s %5d %3d %c%c %5d %10u\n", task ? task->comm : "", diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index a51ff8cee049..c1018c470047 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -156,7 +156,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor) if (!file) return ERR_PTR(-ENOMEM); - file->pid = get_pid(task_pid(current)); + file->pid = get_pid(task_tgid(current)); file->minor = minor; /* for compatibility root is always authenticated */ diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c index ce609e7d758f..f2985337aa53 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c @@ -260,7 +260,7 @@ static int vmw_debugfs_gem_info_show(struct seq_file *m, void *unused) * Therefore, we need to protect this ->comm access using RCU. */ rcu_read_lock(); - task = pid_task(file->pid, PIDTYPE_PID); + task = pid_task(file->pid, PIDTYPE_TGID); seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid), task ? task->comm : ""); rcu_read_unlock(); -- 2.34.1
