dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

[PATCH] radeon: added support for 2560x1080 resolution
by Marcin Raszka 09 Feb '21

09 Feb '21

I was wondering why I can't set the resolution to 2560x1080, while in windows 7 I can without a problem. I looked at the radeon driver code and found it doesn't support this resolution. So I made some changes. I added the hdmi_mhz parameter. In cmdline I set radeon.hdmi_mhz=190 Only tested on the Radeon HD 5830 --- drivers/gpu/drm/radeon/radeon_benchmark.c | 5 +++-- drivers/gpu/drm/radeon/radeon_connectors.c | 25 +++++++++++++--------- drivers/gpu/drm/radeon/radeon_drv.c | 5 +++++ drivers/gpu/drm/radeon/radeon_encoders.c | 6 ++++-- 4 files changed, 27 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c b/drivers/gpu/drm/radeon/radeon_benchmark.c index ac9a5ec481c3..c283b6b15925 100644 --- a/drivers/gpu/drm/radeon/radeon_benchmark.c +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c @@ -30,7 +30,7 @@ #define RADEON_BENCHMARK_COPY_DMA 0 #define RADEON_BENCHMARK_ITERATIONS 1024 -#define RADEON_BENCHMARK_COMMON_MODES_N 17 +#define RADEON_BENCHMARK_COMMON_MODES_N 18 static int radeon_benchmark_do_move(struct radeon_device *rdev, unsigned size, uint64_t saddr, uint64_t daddr, @@ -184,7 +184,8 @@ void radeon_benchmark(struct radeon_device *rdev, int test_number) 1680 * 1050 * 4, 1600 * 1200 * 4, 1920 * 1080 * 4, - 1920 * 1200 * 4 + 1920 * 1200 * 4, + 2560 * 1080 * 4 }; switch (test_number) { diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 607ad5620bd9..182f1e364cbd 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -37,6 +37,8 @@ #include <linux/pm_runtime.h> #include <linux/vga_switcheroo.h> +extern int hdmimhz; + static int radeon_dp_handle_hpd(struct drm_connector *connector) { struct radeon_connector *radeon_connector = to_radeon_connector(connector); @@ -503,7 +505,7 @@ static void radeon_add_common_modes(struct drm_encoder *encoder, struct drm_conn struct mode_size { int w; int h; - } common_modes[17] = { + } common_modes[] = { { 640, 480}, { 720, 480}, { 800, 600}, @@ -520,10 +522,11 @@ static void radeon_add_common_modes(struct drm_encoder *encoder, struct drm_conn {1680, 1050}, {1600, 1200}, {1920, 1080}, - {1920, 1200} + {1920, 1200}, + {2560, 1080} }; - for (i = 0; i < 17; i++) { + for (i = 0; i < ARRAY_SIZE(common_modes); i++) { if (radeon_encoder->devices & (ATOM_DEVICE_TV_SUPPORT)) { if (common_modes[i].w > 1024 || common_modes[i].h > 768) @@ -1491,25 +1494,27 @@ static enum drm_mode_status radeon_dvi_mode_valid(struct drm_connector *connecto (mode->clock > 135000)) return MODE_CLOCK_HIGH; - if (radeon_connector->use_digital && (mode->clock > 165000)) { + if (radeon_connector->use_digital && (mode->clock > (hdmimhz * 1000))) { if ((radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I) || (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D) || - (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_HDMI_TYPE_B)) + (radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_HDMI_TYPE_B)){ return MODE_OK; - else if (ASIC_IS_DCE6(rdev) && drm_detect_hdmi_monitor(radeon_connector_edid(connector))) { + }else if (ASIC_IS_DCE6(rdev) && drm_detect_hdmi_monitor(radeon_connector_edid(connector))) { /* HDMI 1.3+ supports max clock of 340 Mhz */ - if (mode->clock > 340000) + if (mode->clock > 340000){ return MODE_CLOCK_HIGH; - else + }else{ return MODE_OK; + } } else { return MODE_CLOCK_HIGH; } } /* check against the max pixel clock */ - if ((mode->clock / 10) > rdev->clock.max_pixel_clock) + if ((mode->clock / 10) > rdev->clock.max_pixel_clock){ return MODE_CLOCK_HIGH; + } return MODE_OK; } @@ -1809,7 +1814,7 @@ static enum drm_mode_status radeon_dp_mode_valid(struct drm_connector *connector if (mode->clock > 340000) return MODE_CLOCK_HIGH; } else { - if (mode->clock > 165000) + if (mode->clock > (hdmimhz * 1000)) return MODE_CLOCK_HIGH; } } diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index e45d7344ac2b..fce8f9ab8018 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -281,6 +281,11 @@ int radeon_cik_support = 1; MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = disabled)"); module_param_named(cik_support, radeon_cik_support, int, 0444); +int hdmimhz = 165; +MODULE_PARM_DESC(hdmi_mhz, "set HDMI max frequency, default is 165"); +module_param_named(hdmi_mhz, hdmimhz, int, 0444); + + static struct pci_device_id pciidlist[] = { radeon_PCI_IDS }; diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index 46549d5179ee..6b805bcd5726 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -35,6 +35,8 @@ #include "radeon_legacy_encoders.h" #include "atom.h" +extern int hdmimhz; + static uint32_t radeon_encoder_clones(struct drm_encoder *encoder) { struct drm_device *dev = encoder->dev; @@ -389,7 +391,7 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder *encoder, else return false; } else { - if (pixel_clock > 165000) + if (pixel_clock > (hdmimhz * 1000)) return true; else return false; @@ -414,7 +416,7 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder *encoder, else return false; } else { - if (pixel_clock > 165000) + if (pixel_clock > (hdmimhz * 1000)) return true; else return false; -- 2.30.0

2 1

[PATCH 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
by Adrien Grassein 09 Feb '21

09 Feb '21

Hello, this patch set adds the support of the Lontium lt8912 MIPI to HDMI bridge in the kernel. It's only support the video part, not the audio part yet since I don't have the datasheet of this component. I get the current i2c configuration from Digi and Boundary drivers. Developed using the DB_DSIHD board from BoundaryDevices. Thanks, Adrien Grassein Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912 drm/bridge: Introduce LT8912 DSI to HDMI bridge .../display/bridge/lontium,lt8912.yaml | 92 +++ MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig | 14 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt8912.c | 749 ++++++++++++++++++ 5 files changed, 862 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912.c -- 2.25.1

2 4

[PATCH] drm/qxl: properly handle device init failures
by Gerd Hoffmann 09 Feb '21

09 Feb '21

Specifically do not try release resources which where not allocated in the first place. Cc: Tong Zhang <ztong0001(a)gmail.com> Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ drivers/gpu/drm/qxl/qxl_kms.c | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index c326412136c5..ec50d2cfd4e1 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -1183,6 +1183,9 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev) { int ret; + if (!qdev->monitors_config_bo) + return 0; + qdev->monitors_config = NULL; qdev->ram_header->monitors_config = 0; diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c index 66d74aaaee06..4dc5ad13f12c 100644 --- a/drivers/gpu/drm/qxl/qxl_kms.c +++ b/drivers/gpu/drm/qxl/qxl_kms.c @@ -288,6 +288,10 @@ void qxl_device_fini(struct qxl_device *qdev) { int cur_idx; + /* check if qxl_device_init() was successful (gc_work is initialized last) */ + if (!qdev->gc_work.func) + return; + for (cur_idx = 0; cur_idx < 3; cur_idx++) { if (!qdev->current_release_bo[cur_idx]) continue; -- 2.29.2

2 4

[PATCH 1/2] drm/vmwgfx: Correctly set the name of the preferred mode
by Zack Rusin 09 Feb '21

09 Feb '21

Our sysfs "modes" entries were broken because our preffered mode never had its name set correctly. This resulted in the first entry simply being called "preferred" followed by a list of other resolutions. Lets fix it by actually setting the name of mode (which is its resolution). This allows one to quickly validate the modes set by the open-vm-tools. Signed-off-by: Zack Rusin <zackr(a)vmware.com> Reviewed-by: Martin Krastev <krastevm(a)vmware.com> Reviewed-by: Roland Scheidegger <sroland(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 84143b707cd3..daec9d07c696 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -2176,6 +2176,7 @@ int vmw_du_connector_fill_modes(struct drm_connector *connector, mode->hdisplay = du->pref_width; mode->vdisplay = du->pref_height; vmw_guess_mode_timing(mode); + drm_mode_set_name(mode); if (vmw_kms_validate_mode_vram(dev_priv, mode->hdisplay * assumed_bpp, -- 2.27.0

1 1

[PATCH v6 0/8] drm/mediatek: add support for mediatek SOC MT8192
by Hsin-Yi Wang 09 Feb '21

09 Feb '21

This series are based on kernel/git/chunkuang.hu/linux.git mediatek-drm-next and following patch: ("soc: mediatek: add mtk mutex support for MT8183") https://patchwork.kernel.org/project/linux-mediatek/patch/20210129092209.25… This series also depends on component support in mmsys[1]: - [v4,06/10] soc: mediatek: mmsys: add component OVL_2L2 - [v4,07/10] soc: mediatek: mmsys: add component POSTMASK - [v4,08/10] soc: mediatek: mmsys: add component RDMA4 [1] https://patchwork.kernel.org/project/linux-mediatek/patch/1609815993-22744-… Change since v5: - move postmask driver into mtk_drm_ddp_comp - fix review comments Change since v4: - fix review comments Change since v3: - change several function to rebase to mediatek-drm-next - drop pm runtime patches due to it's not related to mt8192 support - fix review comments in v3 Changes since v2: - fix review comment in v2 - add pm runtime for gamma and color - move ddp path select patch to mmsys series - remove some useless patch Yongqiang Niu (8): drm/mediatek: add component OVL_2L2 drm/mediatek: add component POSTMASK drm/mediatek: add component RDMA4 drm/mediatek: separate ccorr module drm/mediatek: Fix ccorr size config drm/mediatek: add matrix_bits private data for ccorr soc: mediatek: add mtk mutex support for MT8192 drm/mediatek: add support for mediatek SOC MT8192 drivers/gpu/drm/mediatek/Makefile | 3 +- drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 229 ++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 ++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 187 ++++++---------- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 50 ++++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/soc/mediatek/mtk-mutex.c | 35 +++ 10 files changed, 421 insertions(+), 120 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c -- 2.30.0.365.g02bc693789-goog

4 15

[PATCH] RFC: dma-fence: Document recoverable page fault implications
by Daniel Vetter 09 Feb '21

09 Feb '21

Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd… Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Felix Kuehling <felix.kuehling(a)amd.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 ++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. + +Note that workloads that run on independent hardware like copy engines or other +GPUs do not have any impact. This allows us to keep using DMA fences internally +in the kernel even for resolving hardware page faults, e.g. by using copy +engines to clear or copy memory needed to resolve the page fault. + +In some ways this page fault problem is a special case of the `Infinite DMA +Fences` discussions: Infinite fences from compute workloads are allowed to +depend on DMA fences, but not the other way around. And not even the page fault +problem is new, because some other CPU thread in userspace might +hit a page fault which holds up a userspace fence - supporting page faults on +GPUs doesn't anything fundamentally new. -- 2.30.0

7 18

[PATCH] backlight: ktd253: Bring up in a known state
by Linus Walleij 09 Feb '21

09 Feb '21

The KTD253 backlight might already be on when the driver is probed: then we don't really know what the current ratio is and all light intensity settings will be off relative to what it was at boot. To fix this, bring up the backlight OFF then move it to the default backlight from there so we know the state. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/video/backlight/ktd253-backlight.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/video/backlight/ktd253-backlight.c b/drivers/video/backlight/ktd253-backlight.c index e3fee3f1f582..d7b287cffd5c 100644 --- a/drivers/video/backlight/ktd253-backlight.c +++ b/drivers/video/backlight/ktd253-backlight.c @@ -137,15 +137,7 @@ static int ktd253_backlight_probe(struct platform_device *pdev) brightness = max_brightness; } - if (brightness) - /* This will be the default ratio when the KTD253 is enabled */ - ktd253->ratio = KTD253_MAX_RATIO; - else - ktd253->ratio = 0; - - ktd253->gpiod = devm_gpiod_get(dev, "enable", - brightness ? GPIOD_OUT_HIGH : - GPIOD_OUT_LOW); + ktd253->gpiod = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW); if (IS_ERR(ktd253->gpiod)) { ret = PTR_ERR(ktd253->gpiod); if (ret != -EPROBE_DEFER) @@ -153,6 +145,8 @@ static int ktd253_backlight_probe(struct platform_device *pdev) return ret; } gpiod_set_consumer_name(ktd253->gpiod, dev_name(dev)); + /* Bring backlight to a known off state */ + msleep(KTD253_T_OFF_MS); bl = devm_backlight_device_register(dev, dev_name(dev), dev, ktd253, &ktd253_backlight_ops, NULL); -- 2.29.2

3 3

[PATCH] drm/ttm: fix removal of bo_count sysfs file
by Christian König 09 Feb '21

09 Feb '21

Only a zombie leftover from rebasing. Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixes: 3763d635deaa ("drm/ttm: add debugfs directory v2") --- drivers/gpu/drm/ttm/ttm_device.c | 2 -- include/drm/ttm/ttm_device.h | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c index ac0903c9e60a..8bb61dd26437 100644 --- a/drivers/gpu/drm/ttm/ttm_device.c +++ b/drivers/gpu/drm/ttm/ttm_device.c @@ -49,8 +49,6 @@ static void ttm_global_release(void) if (--ttm_glob_use_count > 0) goto out; - kobject_del(&glob->kobj); - kobject_put(&glob->kobj); ttm_mem_global_release(&ttm_mem_glob); __free_page(glob->dummy_read_page); memset(glob, 0, sizeof(*glob)); diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h index 7bc8bb797161..035bbc044a3b 100644 --- a/include/drm/ttm/ttm_device.h +++ b/include/drm/ttm/ttm_device.h @@ -55,7 +55,6 @@ extern struct ttm_global { * Constant after init. */ - struct kobject kobj; struct page *dummy_read_page; spinlock_t lru_lock; -- 2.25.1

3 4

[PATCH] drm/gma500: Drop DRM_GMA600 config option
by Thomas Zimmermann 09 Feb '21

09 Feb '21

With support for the MID-only Medfield chips removed, simply build the complete driver if DRM_GMA500 has been selected. Anyone who wants to enable one of the chips would probably also want the rest. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 837f23bb4b60 ("drm/gma500: Drop DRM_GMA3600 config option") Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/gma500/Kconfig | 11 ++--------- drivers/gpu/drm/gma500/Makefile | 15 +++++++-------- drivers/gpu/drm/gma500/psb_drv.c | 5 ++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index ec395658a43f..0cff20265f97 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -9,12 +9,5 @@ config DRM_GMA500 select INPUT if ACPI help Say yes for an experimental 2D KMS framebuffer driver for the - Intel GMA500 ('Poulsbo') and other Intel IMG based graphics - devices. - -config DRM_GMA600 - bool "Intel GMA600 support (Experimental)" - depends on DRM_GMA500 - help - Say yes to include support for GMA600 (Intel Moorestown/Oaktrail) - platforms with LVDS ports. MIPI is not currently supported. + Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and + Intel GMA3600/3650 (Cedar Trail). diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile index 884ab1f9063e..ca5013246d7b 100644 --- a/drivers/gpu/drm/gma500/Makefile +++ b/drivers/gpu/drm/gma500/Makefile @@ -23,6 +23,12 @@ gma500_gfx-y += \ intel_i2c.o \ mid_bios.o \ mmu.o \ + oaktrail_device.o \ + oaktrail_crtc.o \ + oaktrail_hdmi.o \ + oaktrail_hdmi_i2c.o \ + oaktrail_lvds.o \ + oaktrail_lvds_i2c.o \ power.o \ psb_device.o \ psb_drv.o \ @@ -33,13 +39,6 @@ gma500_gfx-y += \ psb_lid.o \ psb_irq.o -gma500_gfx-$(CONFIG_ACPI) += opregion.o \ - -gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \ - oaktrail_crtc.o \ - oaktrail_lvds.o \ - oaktrail_lvds_i2c.o \ - oaktrail_hdmi.o \ - oaktrail_hdmi_i2c.o +gma500_gfx-$(CONFIG_ACPI) += opregion.o obj-$(CONFIG_DRM_GMA500) += gma500_gfx.o diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 0bcab065242c..538974c37adb 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -54,7 +54,7 @@ static const struct pci_device_id pciidlist[] = { /* Poulsbo */ { 0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops }, { 0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops }, -#if defined(CONFIG_DRM_GMA600) + /* Oak Trail */ { 0x8086, 0x4100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, { 0x8086, 0x4101, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, { 0x8086, 0x4102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, @@ -64,8 +64,7 @@ static const struct pci_device_id pciidlist[] = { { 0x8086, 0x4106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, { 0x8086, 0x4107, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, { 0x8086, 0x4108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &oaktrail_chip_ops }, -#endif - /* Cedartrail */ + /* Cedar Trail */ { 0x8086, 0x0be0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops }, { 0x8086, 0x0be1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops }, { 0x8086, 0x0be2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops }, -- 2.30.0

2 1

[PATCH v3 0/2] drm/vboxvideo: Use struct drm_shadow_plane_state for cursor plane
by Thomas Zimmermann 09 Feb '21

09 Feb '21

Functions in the atomic commit tail are not allowed to acquire the dmabuf's reservation lock. So we cannot legally call the GEM object's vmap functionality in atomic_update. But, much better, we can use drm_shadow_plane_state to do all the mapping for us. Patch 1 exports the helpers for shadow-buffered planes from the DRM KMS helper library and adds documentation on how to use them. Patch 2 replaces the vmap code in vbox' cursor update code with a the helpers for shadow-buffered planes. v3: * documentation fixes (Daniel) v2: * rebuilt with shadow-buffered planes Thomas Zimmermann (2): drm/gem: Export helpers for shadow-buffered planes drm/vboxvideo: Implement cursor plane with struct drm_shadow_plane_state drivers/gpu/drm/drm_gem_atomic_helper.c | 148 +++++++++++++++++++++++- drivers/gpu/drm/vboxvideo/vbox_mode.c | 28 ++--- include/drm/drm_gem_atomic_helper.h | 32 +++++ 3 files changed, 181 insertions(+), 27 deletions(-) -- 2.30.0

1 2

← Newer
1
...
45
46
47
48
49
50
51
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021