dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH v2 0/4] msm/gpu/a6xx: use the DMA-API for GMU memory allocations
by Jordan Crouse 26 Feb '20

26 Feb '20

When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of cache coherency issues because it is mapped as write-combine without clearing the cache after it was zeroed. Rather than duplicate the hacky workaround we use in the GEM allocator for the same reason it turns out that we don't need to have a bespoke memory allocator for the GMU anyway. It uses a flat, global address space and there are only two relatively minor allocations anyway. In short, this is essentially what the DMA API was created for so replace a bunch of memory management code with two calls to allocate and free DMA memory and we're fine. The only wrinkle is that the memory allocations need to be in a very specific location in the GMU virtual address space so in order to get the iova allocator to do the right thing we need to specify the dma-ranges property in the device tree for the GMU node. Since we've not yet converted the GMU bindings over to YAML two patches quickly turn into four but at the end of it we have at least one bindings file converted to YAML and 99 less lines of code to worry about. v2: Fix the example bindings for dma-ranges - the third item is the size Pass false to of_dma_configure so that it fails probe if the DMA region is not set up. Jordan Crouse (4): dt-bindings: display: msm: Convert GMU bindings to YAML dt-bindings: display: msm: Add required dma-range property arm64: dts: sdm845: Set the virtual address range for GMU allocations drm/msm/a6xx: Use the DMA API for GMU memory objects .../devicetree/bindings/display/msm/gmu.txt | 116 ----------------- .../devicetree/bindings/display/msm/gmu.yaml | 140 +++++++++++++++++++++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 112 ++--------------- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 5 +- 5 files changed, 153 insertions(+), 222 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.yaml -- 2.7.4

5 8

[PATCH 0/2] Support virtio cross-device resources
by David Stevens 26 Feb '20

26 Feb '20

This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments (i.e. renumbering the new virtio gpu command and adding a feature flag). The patchset adds a new flavor of dma-bufs that supports querying the underlying virtio object UUID, as well as adding support for exporting resources from virtgpu. It is expected that this will be used to import virtgpu resources into the virtio-video driver currently under discussion [2]. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute David Stevens (2): virtio: add dma-buf support for exported objects drm/virtio: Support virtgpu exported resources drivers/gpu/drm/virtio/virtgpu_drv.c | 3 + drivers/gpu/drm/virtio/virtgpu_drv.h | 21 +++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 + drivers/gpu/drm/virtio/virtgpu_prime.c | 109 ++++++++++++++++++++++++- drivers/gpu/drm/virtio/virtgpu_vq.c | 58 +++++++++++++ drivers/virtio/Makefile | 2 +- drivers/virtio/virtio.c | 6 ++ drivers/virtio/virtio_dma_buf.c | 97 ++++++++++++++++++++++ include/linux/virtio.h | 1 + include/linux/virtio_dma_buf.h | 62 ++++++++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++ 11 files changed, 378 insertions(+), 4 deletions(-) create mode 100644 drivers/virtio/virtio_dma_buf.c create mode 100644 include/linux/virtio_dma_buf.h -- 2.25.0.265.gbab2e86ba0-goog

2 6

Re: linux-next: Tree for Feb 26 (gpu/drm/amd/amdgpu/)
by Randy Dunlap 26 Feb '20

26 Feb '20

On 2/25/20 8:34 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20200225: > on i386: ld: drivers/gpu/drm/amd/amdgpu/amdgpu_object.o: in function `amdgpu_bo_release_notify': amdgpu_object.c:(.text+0xe07): undefined reference to `amdgpu_amdkfd_remove_fence_on_pt_pd_bos' Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap <rdunlap(a)infradead.org>

1 0

[Bug] virtio-gpu broken with qemu/kvm on arm64 on kernel 5.5+
by Guillaume Gardet 26 Feb '20

26 Feb '20

Hi, With (guest) kernel 5.5+ with qemu/kvm on arm64, I get lots of display corruptions leading to this kind of screen: https://openqa.opensuse.org/tests/1174521#step/yast2_i/24 I git bisected it to commit c66df701e783bc666593e6e665f13670760883ee ********** drm/virtio: switch from ttm to gem shmem helpers virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4: fix drm_gem_object_funcs name. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Reviewed-by: Chia-I Wu <olvaffe(a)gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-15-kraxel@… ********** I also tested kernel 5.6-rc2 which has the same bug. Without kvm, the display is fine. Regards, Guillaume

4 8

[PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)
by Alex Deucher 26 Feb '20

26 Feb '20

Split into init and register functions to avoid a segfault in some configs when the load/unload callbacks are removed. v2: - add back accidently dropped has_aux setting - set dev in late_register v3: - fix dp cec ordering Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++-------- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 7 ++++++- 3 files changed, 24 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index ec1501e3a63a..f355d9a752d2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -1461,6 +1461,20 @@ static enum drm_mode_status amdgpu_connector_dp_mode_valid(struct drm_connector return MODE_OK; } +static int +amdgpu_connector_late_register(struct drm_connector *connector) +{ + struct amdgpu_connector *amdgpu_connector = to_amdgpu_connector(connector); + int r = 0; + + if (amdgpu_connector->ddc_bus->has_aux) { + amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev; + r = drm_dp_aux_register(&amdgpu_connector->ddc_bus->aux); + } + + return r; +} + static const struct drm_connector_helper_funcs amdgpu_connector_dp_helper_funcs = { .get_modes = amdgpu_connector_dp_get_modes, .mode_valid = amdgpu_connector_dp_mode_valid, @@ -1475,6 +1489,7 @@ static const struct drm_connector_funcs amdgpu_connector_dp_funcs = { .early_unregister = amdgpu_connector_unregister, .destroy = amdgpu_connector_destroy, .force = amdgpu_connector_dvi_force, + .late_register = amdgpu_connector_late_register, }; static const struct drm_connector_funcs amdgpu_connector_edp_funcs = { @@ -1485,6 +1500,7 @@ static const struct drm_connector_funcs amdgpu_connector_edp_funcs = { .early_unregister = amdgpu_connector_unregister, .destroy = amdgpu_connector_destroy, .force = amdgpu_connector_dvi_force, + .late_register = amdgpu_connector_late_register, }; void diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c index ea702a64f807..9b74cfdba7b8 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c @@ -186,16 +186,10 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *m void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector) { - int ret; - amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd; - amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev; amdgpu_connector->ddc_bus->aux.transfer = amdgpu_atombios_dp_aux_transfer; - ret = drm_dp_aux_register(&amdgpu_connector->ddc_bus->aux); - if (!ret) - amdgpu_connector->ddc_bus->has_aux = true; - - WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret); + drm_dp_aux_init(&amdgpu_connector->ddc_bus->aux); + amdgpu_connector->ddc_bus->has_aux = true; } /***** general DP utility functions *****/ diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 3959c942c88b..d5b9e72f2649 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -155,6 +155,11 @@ amdgpu_dm_mst_connector_late_register(struct drm_connector *connector) struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector); struct drm_dp_mst_port *port = amdgpu_dm_connector->port; + int r; + + r = drm_dp_aux_register(&amdgpu_dm_connector->dm_dp_aux.aux); + if (r) + return r; #if defined(CONFIG_DEBUG_FS) connector_debugfs_init(amdgpu_dm_connector); @@ -484,7 +489,7 @@ void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm, aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer; aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc; - drm_dp_aux_register(&aconnector->dm_dp_aux.aux); + drm_dp_aux_init(&aconnector->dm_dp_aux.aux); drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux, &aconnector->base); -- 2.24.1

5 18

[PATCH] drm/etnaviv: fix TS cache flushing on GPUs with BLT engine
by Lucas Stach 26 Feb '20

26 Feb '20

As seen in the Vivante kernel driver, most GPUs with the BLT engine have a broken TS cache flush. The workaround is to temporarily set the BLT command to CLEAR_IMAGE, without actually executing the clear. Apparently this state change is enough to trigger the required TS cache flush. As the BLT engine is completely asychronous, we also need a few more stall states to synchronize the flush with the frontend. Root-caused-by: Jonathan Marek <jonathan(a)marek.ca> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 60 ++++++++++++++++++++++-- drivers/gpu/drm/etnaviv/state_blt.xml.h | 2 + 2 files changed, 57 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c index 32d9fac587f9..76d38561c910 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c @@ -12,6 +12,7 @@ #include "common.xml.h" #include "state.xml.h" +#include "state_blt.xml.h" #include "state_hi.xml.h" #include "state_3d.xml.h" #include "cmdstream.xml.h" @@ -233,6 +234,8 @@ void etnaviv_buffer_end(struct etnaviv_gpu *gpu) struct etnaviv_cmdbuf *buffer = &gpu->buffer; unsigned int waitlink_offset = buffer->user_size - 16; u32 link_target, flush = 0; + bool has_blt = !!(gpu->identity.minor_features5 & + chipMinorFeatures5_BLT_ENGINE); lockdep_assert_held(&gpu->lock); @@ -248,16 +251,38 @@ void etnaviv_buffer_end(struct etnaviv_gpu *gpu) if (flush) { unsigned int dwords = 7; + if (has_blt) + dwords += 10; + link_target = etnaviv_buffer_reserve(gpu, buffer, dwords); CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); + if (has_blt) { + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x1); + CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x0); + } CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_CACHE, flush); - if (gpu->exec_state == ETNA_PIPE_3D) - CMD_LOAD_STATE(buffer, VIVS_TS_FLUSH_CACHE, - VIVS_TS_FLUSH_CACHE_FLUSH); + if (gpu->exec_state == ETNA_PIPE_3D) { + if (has_blt) { + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x1); + CMD_LOAD_STATE(buffer, VIVS_BLT_SET_COMMAND, 0x1); + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x0); + } else { + CMD_LOAD_STATE(buffer, VIVS_TS_FLUSH_CACHE, + VIVS_TS_FLUSH_CACHE_FLUSH); + } + } CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); + if (has_blt) { + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x1); + CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x0); + } CMD_END(buffer); etnaviv_buffer_replace_wait(buffer, waitlink_offset, @@ -323,6 +348,8 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 exec_state, bool switch_mmu_context = gpu->mmu_context != mmu_context; unsigned int new_flush_seq = READ_ONCE(gpu->mmu_context->flush_seq); bool need_flush = switch_mmu_context || gpu->flush_seq != new_flush_seq; + bool has_blt = !!(gpu->identity.minor_features5 & + chipMinorFeatures5_BLT_ENGINE); lockdep_assert_held(&gpu->lock); @@ -433,6 +460,15 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 exec_state, * 2 semaphore stall + 1 event + 1 wait + 1 link. */ return_dwords = 7; + + /* + * When the BLT engine is present we need 6 more dwords in the return + * target: 3 enable/flush/disable + 4 enable/semaphore stall/disable, + * but we don't need the normal TS flush state. + */ + if (has_blt) + return_dwords += 6; + return_target = etnaviv_buffer_reserve(gpu, buffer, return_dwords); CMD_LINK(cmdbuf, return_dwords, return_target); @@ -447,11 +483,25 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32 exec_state, CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_CACHE, VIVS_GL_FLUSH_CACHE_DEPTH | VIVS_GL_FLUSH_CACHE_COLOR); - CMD_LOAD_STATE(buffer, VIVS_TS_FLUSH_CACHE, - VIVS_TS_FLUSH_CACHE_FLUSH); + if (has_blt) { + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x1); + CMD_LOAD_STATE(buffer, VIVS_BLT_SET_COMMAND, 0x1); + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x0); + } else { + CMD_LOAD_STATE(buffer, VIVS_TS_FLUSH_CACHE, + VIVS_TS_FLUSH_CACHE_FLUSH); + } } CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE); + + if (has_blt) { + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x1); + CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT); + CMD_LOAD_STATE(buffer, VIVS_BLT_ENABLE, 0x0); + } + CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) | VIVS_GL_EVENT_FROM_PE); CMD_WAIT(buffer); diff --git a/drivers/gpu/drm/etnaviv/state_blt.xml.h b/drivers/gpu/drm/etnaviv/state_blt.xml.h index daae55995def..0e8bcf9dcc93 100644 --- a/drivers/gpu/drm/etnaviv/state_blt.xml.h +++ b/drivers/gpu/drm/etnaviv/state_blt.xml.h @@ -46,6 +46,8 @@ DEALINGS IN THE SOFTWARE. /* This is a cut-down version of the state_blt.xml.h file */ +#define VIVS_BLT_SET_COMMAND 0x000140ac + #define VIVS_BLT_ENABLE 0x000140b8 #define VIVS_BLT_ENABLE_ENABLE 0x00000001 -- 2.20.1

1 0

[PATCH v2 0/6] update hwdw for gc400
by Christian Gmeiner 26 Feb '20

26 Feb '20

This patch series extends the hwdb for an entry for the gc400 found in the ST STM32 SoC. With this patches we report the same limits and features for this GPU as the galcore kernel driver does. Christian Gmeiner (6): drm/etnaviv: update hardware headers from rnndb drm/etnaviv: determine product, customer and eco id drm/etnaviv: show identity information in debugfs drm/etnaviv: update gc7000 chip identity entry drm/etnaviv: update hwdb selection logic drm/etnaviv: add hwdb entry for gc400 found in STM32 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 18 ++++++++++- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 ++-- drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 42 +++++++++++++++++++++++++- drivers/gpu/drm/etnaviv/state_hi.xml.h | 29 +++++++++++------- 4 files changed, 79 insertions(+), 16 deletions(-) -- 2.24.1

3 11

None
by Ville Syrjälä 26 Feb '20

26 Feb '20

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.GH13686(a)intel.com> References: <20200219203544.31013-1-ville.syrjala(a)linux.intel.com> <CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f(a)eucas1p2.samsung.com> <20200219203544.31013-5-ville.syrjala(a)linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82d24(a)samsung.com> <20200225112114.GA13686(a)intel.com> <3ca785f2-9032-aaf9-0965-8657d31116ba(a)samsung.com> <20200225154506.GF13686(a)intel.com> <20200225192720.GG13686(a)intel.com> <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g(a)mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g(a)mail.gmail.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä > <ville.syrjala(a)linux.intel.com> wrote: > > > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. > > That's impressive :D > > > Unfortunately it found a lot of strange stuff: > > I will answer for the weirdness I caused. > > I have long suspected that a whole bunch of the "simple" displays > are not simple but contains a display controller and memory. > That means that the speed over the link to the display and > actual refresh rate on the actual display is asymmetric because > well we are just updating a RAM, the resolution just limits how > much data we are sending, the clock limits the speed on the > bus over to the RAM on the other side. IMO even in command mode mode->clock should probably be the actual dotclock used by the display. If there's another clock for the bus speed/etc. it should be stored somewhere else. -- Ville Syrjälä Intel

2 4

[PATCH v3 0/4] Add support for devices in the Energy Model
by Lukasz Luba 26 Feb '20

26 Feb '20

Hi all, This patch set introduces support for devices in the Energy Model (EM) framework. It will unify the power model for thermal subsystem and make it simpler. The 1st patch refactors EM framework and adds support for devices. The 2nd patch changes dev_pm_opp_of_register_em() in OPP/OF which now should take as an argument struct device pointer. It touches a few trees (OMAP, NXP, Mediatek) updating their CPUfreq drivers to the new interface. Patch 3/4 changes thermal devfreq cooling removing old code for calculating local power table. It simplifies the code and uses EM for requested power calculation. Last patch 4/4 adds EM to Panfrost driver. The patch set is based on linux-next tag next-20200221. Changes: v3: - added back the cpumask 'cpus' in the em_perf_domain due potential cache misses - removed _is_cpu_em() since there is no need for it - changed function name from em_pd_energy() to em_cpu_energy(), which is optimized for usage from the scheduler making some assumptions and not validating arguments to speed-up, there is a comment stressing that it should be used only for CPUs em_perf_domain - changed em_get_pd() to em_pd_get() which is now aligned with em_cpu_get() naming - extended comment in em_cpu_get() describing the need for this function - fixed build warning reported on x86 by kbuild test robot in devfreq_cooling.c - updated documentation in the energy-model.rst - changed print messages from 'energy_model' to 'EM' - changed dev_warn to dev_dbg, should calm down test scripts in case the platform has OPPs less efficient in the OPP table (some of them are there for cooling reasons, we shouldn't warn in this case, debug info is enough) v2 [2]: - changed EM API em_register_perf_domain() adding cpumask_t pointer as last argument (which was discussed with Dietmar and Quentin) - removed dependency on PM_OPP, thanks to the cpumask_t argument - removed enum em_type and em->type dependent code - em_get_pd() can handle CPU device as well as devfreq device - updated EM documentation - in devfreq cooling added code which prevents from race condition with devfreq governors which are trying to use OPPs while thermal is in the middle of disabling them. - in devfreq cooling added code which updates state of the devfreq device to avoid working on stale data when governor has not updated it for a long time - in devfreq cooling added backward compatibility frequency table for drivers which did not provide EM - added Steven's Reviewed-by to trace code in thermal - added another CPUFreq driver which needs to be updated to the new API The v1 can be found here [1]. Regards, Lukasz Luba [1] https://lkml.org/lkml/2020/1/16/619 [2] https://lkml.org/lkml/2020/2/6/377 Lukasz Luba (4): PM / EM: add devices to Energy Model OPP: change parameter to device pointer in dev_pm_opp_of_register_em() thermal: devfreq_cooling: Refactor code and switch to use Energy Model drm/panfrost: Register to the Energy Model with devfreq device Documentation/power/energy-model.rst | 133 +++--- Documentation/scheduler/sched-energy.rst | 2 +- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/imx6q-cpufreq.c | 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scmi-cpufreq.c | 11 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/cpufreq/vexpress-spc-cpufreq.c | 2 +- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 + drivers/opp/of.c | 45 +-- drivers/thermal/cpufreq_cooling.c | 10 +- drivers/thermal/devfreq_cooling.c | 425 +++++++++----------- include/linux/devfreq_cooling.h | 17 - include/linux/energy_model.h | 107 +++-- include/linux/pm_opp.h | 14 +- include/trace/events/thermal.h | 19 +- kernel/power/energy_model.c | 400 ++++++++++++++---- kernel/sched/fair.c | 2 +- kernel/sched/topology.c | 4 +- 21 files changed, 711 insertions(+), 495 deletions(-) -- 2.17.1

4 10

[PATCH] drm/ttm: fix leaking fences via ttm_buffer_object_transfer
by Alex Deucher 26 Feb '20

26 Feb '20

From: Ahzo <Ahzo(a)tutanota.com> Set the drm_device to NULL, so that the newly created buffer object doesn't appear to use the embedded gem object. This is necessary, because otherwise no corresponding dma_resv_fini for the dma_resv_init is called, resulting in a memory leak. The dma_resv_fini in ttm_bo_release_list is only called if the embedded gem object is not used, which is determined by checking if the drm_device is NULL. Bug: https://gitlab.freedesktop.org/drm/amd/issues/958 Fixes: 1e053b10ba60 ("drm/ttm: use gem reservation object") Signed-off-by: Ahzo <Ahzo(a)tutanota.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index c8e359ded1df..44c1e7adfb7c 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -514,6 +514,7 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, fbo->base.base.resv = &fbo->base.base._resv; dma_resv_init(&fbo->base.base._resv); + fbo->base.base.dev = NULL; ret = dma_resv_trylock(&fbo->base.base._resv); WARN_ON(!ret); -- 2.24.1

4 6

← Newer
1
...
27
28
29
30
31
32
33
...
68
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2020