dri-devel December 2020

dri-devel@lists.freedesktop.org

278 participants
659 discussions

[PATCH 0/5] Thermal devfreq cooling improvements with Energy Model
by Lukasz Luba 01 Dec '20

01 Dec '20

Hi all, This path set is a continuation of my previous work, which aimed to add Energy Model to all devices. This series is a follow up for the patches which got merged to v5.9-rc1. It aims to change the thermal devfreq cooling and use the Energy Model instead of private calculation and structures. The new registration interface in the patch 3/5 helps to register devfreq cooling and the EM in one call. There is also another improvement, patch 2/5 is changing the way how thermal gets the device status. Now it's taken on demand and stored as a copy. The last patch wouldn't go through thermal tree, but it's here to consistency. The patch set is based on current next (next-20200921). Regards, Lukasz Luba [1] https://lkml.org/lkml/2020/5/11/326 Lukasz Luba (5): thermal: devfreq_cooling: change tracing function and arguments thermal: devfreq_cooling: get a copy of device status thermal: devfreq_cooling: add new registration functions with Energy Model thermal: devfreq_cooling: remove old power model and use EM drm/panfrost: Register devfreq cooling and attempt to add Energy Model drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +- drivers/thermal/devfreq_cooling.c | 414 ++++++++++---------- include/linux/devfreq_cooling.h | 39 +- include/trace/events/thermal.h | 19 +- 4 files changed, 249 insertions(+), 225 deletions(-) -- 2.17.1

3 19

[PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
by Dmitry Osipenko 01 Dec '20

01 Dec '20

Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces power consumption and heating of the Tegra chips. Tegra SoC has multiple hardware units which belong to a core power domain of the SoC and share the core voltage. The voltage must be selected in accordance to a minimum requirement of every core hardware unit. The minimum core voltage requirement depends on: 1. Clock enable state of a hardware unit. 2. Clock frequency. 3. Unit's internal idling/active state. This series is tested on Acer A500 (T20), AC100 (T20), Nexus 7 (T30) and Ouya (T30) devices. I also added voltage scaling to the Ventana (T20) and Cardhu (T30) boards which are tested by NVIDIA's CI farm. Tegra30 is now up to 5C cooler on Nexus 7 and stays cool on Ouya (instead of becoming burning hot) while system is idling. It should be possible to improve this further by implementing a more advanced power management features for the kernel drivers. The DVFS support is opt-in for all boards, meaning that older DTBs will continue to work like they did it before this series. It should be possible to easily add the core voltage scaling support for Tegra114+ SoCs based on this grounding work later on, if anyone will want to implement it. WARNING(!) This series is made on top of the memory interconnect patches which are currently under review [1]. The Tegra EMC driver and devicetree-related patches need to be applied on top of the ICC series. [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=212196 Dmitry Osipenko (30): dt-bindings: host1x: Document OPP and voltage regulator properties dt-bindings: mmc: tegra: Document OPP and voltage regulator properties dt-bindings: pwm: tegra: Document OPP and voltage regulator properties media: dt: bindings: tegra-vde: Document OPP and voltage regulator properties dt-binding: usb: ci-hdrc-usb2: Document OPP and voltage regulator properties dt-bindings: usb: tegra-ehci: Document OPP and voltage regulator properties soc/tegra: Add sync state API soc/tegra: regulators: Support Tegra SoC device sync state API soc/tegra: regulators: Fix lockup when voltage-spread is out of range regulator: Allow skipping disabled regulators in regulator_check_consumers() drm/tegra: dc: Support OPP and SoC core voltage scaling drm/tegra: gr2d: Correct swapped device-tree compatibles drm/tegra: gr2d: Support OPP and SoC core voltage scaling drm/tegra: gr3d: Support OPP and SoC core voltage scaling drm/tegra: hdmi: Support OPP and SoC core voltage scaling gpu: host1x: Support OPP and SoC core voltage scaling mmc: sdhci-tegra: Support OPP and core voltage scaling pwm: tegra: Support OPP and core voltage scaling media: staging: tegra-vde: Support OPP and SoC core voltage scaling usb: chipidea: tegra: Support OPP and SoC core voltage scaling usb: host: ehci-tegra: Support OPP and SoC core voltage scaling memory: tegra20-emc: Support Tegra SoC device state syncing memory: tegra30-emc: Support Tegra SoC device state syncing ARM: tegra: Add OPP tables for Tegra20 peripheral devices ARM: tegra: Add OPP tables for Tegra30 peripheral devices ARM: tegra: ventana: Add voltage supplies to DVFS-capable devices ARM: tegra: paz00: Add voltage supplies to DVFS-capable devices ARM: tegra: acer-a500: Add voltage supplies to DVFS-capable devices ARM: tegra: cardhu-a04: Add voltage supplies to DVFS-capable devices ARM: tegra: nexus7: Add voltage supplies to DVFS-capable devices .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++ .../bindings/media/nvidia,tegra-vde.txt | 12 + .../bindings/mmc/nvidia,tegra20-sdhci.txt | 12 + .../bindings/pwm/nvidia,tegra20-pwm.txt | 13 + .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 4 + .../bindings/usb/nvidia,tegra20-ehci.txt | 2 + .../boot/dts/tegra20-acer-a500-picasso.dts | 30 +- arch/arm/boot/dts/tegra20-paz00.dts | 40 +- .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 386 ++++++++++++++++ arch/arm/boot/dts/tegra20-ventana.dts | 65 ++- arch/arm/boot/dts/tegra20.dtsi | 14 + .../tegra30-asus-nexus7-grouper-common.dtsi | 23 + arch/arm/boot/dts/tegra30-cardhu-a04.dts | 44 ++ .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 415 ++++++++++++++++++ arch/arm/boot/dts/tegra30.dtsi | 13 + drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 138 +++++- drivers/gpu/drm/tegra/dc.h | 5 + drivers/gpu/drm/tegra/gr2d.c | 140 +++++- drivers/gpu/drm/tegra/gr3d.c | 136 ++++++ drivers/gpu/drm/tegra/hdmi.c | 63 ++- drivers/gpu/host1x/Kconfig | 1 + drivers/gpu/host1x/dev.c | 87 ++++ drivers/memory/tegra/tegra20-emc.c | 8 +- drivers/memory/tegra/tegra30-emc.c | 8 +- drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/sdhci-tegra.c | 70 ++- drivers/pwm/Kconfig | 1 + drivers/pwm/pwm-tegra.c | 84 +++- drivers/regulator/core.c | 12 +- .../soc/samsung/exynos-regulator-coupler.c | 2 +- drivers/soc/tegra/common.c | 152 ++++++- drivers/soc/tegra/regulators-tegra20.c | 25 +- drivers/soc/tegra/regulators-tegra30.c | 30 +- drivers/staging/media/tegra-vde/Kconfig | 1 + drivers/staging/media/tegra-vde/vde.c | 127 ++++++ drivers/staging/media/tegra-vde/vde.h | 1 + drivers/usb/chipidea/Kconfig | 1 + drivers/usb/chipidea/ci_hdrc_tegra.c | 79 ++++ drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-tegra.c | 79 ++++ include/linux/regulator/coupler.h | 6 +- include/soc/tegra/common.h | 22 + 43 files changed, 2360 insertions(+), 50 deletions(-) -- 2.27.0

9 97

[RESEND PATCH 0/3] Move Mediatek MIPI DSI PHY driver from DRM folder to PHY folder
by Chun-Kuang Hu 01 Dec '20

01 Dec '20

mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's more suitable to place a phy driver into phy driver folder, so move mtk_mipi_dsi_phy driver into phy driver folder. Chun-Kuang Hu (3): drm/mediatek: Separate mtk_mipi_tx to an independent module phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder MAINTAINERS: add files for Mediatek DRM drivers MAINTAINERS | 1 + drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/Makefile | 3 --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 - drivers/phy/mediatek/Kconfig | 7 +++++++ drivers/phy/mediatek/Makefile | 5 +++++ .../mediatek/phy-mtk-mipi-dsi-mt8173.c} | 2 +- .../mediatek/phy-mtk-mipi-dsi-mt8183.c} | 2 +- .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 5 ++++- .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0 11 files changed, 20 insertions(+), 8 deletions(-) rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%) rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%) rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} (97%) rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} (100%) -- 2.17.1

3 8

[PATCH v3 0/7] drm/vc4: hdmi: Support the 10/12 bit output
by Maxime Ripard 01 Dec '20

01 Dec '20

Hi, Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI controller. Let me know what you think, Maxime Changes from v2: - Rebased on current drm-misc-next - Fixed a bug that was dropping the refresh rate when the bpc count was increased Changes from v1: - Added the coccinelle script to the first patch - Fixed the pixel_rate ramp up Maxime Ripard (7): drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Use the connector state pixel rate for the PHY drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++--- drivers/gpu/drm/vc4/vc4_drv.h | 14 +-- drivers/gpu/drm/vc4/vc4_hdmi.c | 147 +++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 21 +++- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 ++ drivers/gpu/drm/vc4/vc4_hvs.c | 8 +- drivers/gpu/drm/vc4/vc4_txp.c | 8 +- 8 files changed, 190 insertions(+), 47 deletions(-) -- 2.28.0

2 8

[PATCH] drm/v3d: fix reference leak when pm_runtime_get_sync fails
by Qinglang Miao 01 Dec '20

01 Dec '20

The PM reference count is not expected to be incremented on return in functions v3d_get_param_ioctl and v3d_job_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Fixes: 935f3d88434b ("drm/v3d: Make sure the GPU is on when measuring clocks.") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- drivers/gpu/drm/v3d/v3d_debugfs.c | 4 ++-- drivers/gpu/drm/v3d/v3d_gem.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c b/drivers/gpu/drm/v3d/v3d_debugfs.c index e76b24bb8..91ceed774 100644 --- a/drivers/gpu/drm/v3d/v3d_debugfs.c +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c @@ -132,7 +132,7 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused) u32 ident0, ident1, ident2, ident3, cores; int ret, core; - ret = pm_runtime_get_sync(v3d->drm.dev); + ret = pm_runtime_resume_and_get(v3d->drm.dev); if (ret < 0) return ret; @@ -219,7 +219,7 @@ static int v3d_measure_clock(struct seq_file *m, void *unused) int measure_ms = 1000; int ret; - ret = pm_runtime_get_sync(v3d->drm.dev); + ret = pm_runtime_resume_and_get(v3d->drm.dev); if (ret < 0) return ret; diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index 182c58652..765683569 100644 --- a/drivers/gpu/drm/v3d/v3d_gem.c +++ b/drivers/gpu/drm/v3d/v3d_gem.c @@ -439,7 +439,7 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv, job->v3d = v3d; job->free = free; - ret = pm_runtime_get_sync(v3d->drm.dev); + ret = pm_runtime_resume_and_get(v3d->drm.dev); if (ret < 0) return ret; -- 2.23.0

1 0

[PATCH 0/3] drm/rockchip: fix reference leak when pm_runtime_get_sync fails
by Qinglang Miao 01 Dec '20

01 Dec '20

pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. BTW, pm_runtime_resume_and_get is introduced in v5.10-rc5 as dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to dealwith usage counter") Qinglang Miao (3): drm/rockchip: cdn-dp: fix reference leak when pm_runtime_get_sync fails drm/rockchip: vop: fix reference leak when pm_runtime_get_sync fails drm/rockchip: lvds: fix reference leak when pm_runtime_get_sync fails drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++-- drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) -- 2.23.0

1 3

re: video: fbdev: sis: Fix set but not used warnings in init.c
by Colin Ian King 01 Dec '20

01 Dec '20

Hi, Static analysis on linux-next with Coverity had detected a minor issue in the following commit: commit 2a74e8682a39d00e04ca278459ae7d7ecbdfb394 Author: Sam Ravnborg <sam(a)ravnborg.org> Date: Sat Nov 28 23:40:55 2020 +0100 video: fbdev: sis: Fix set but not used warnings in init.c The analysis is as follows: 2659 if(SiS_Pr->UseCustomMode) { 2660 infoflag = SiS_Pr->CInfoFlag; 2661 } else { Useless call (USELESS_CALL) side_effect_free: Calling SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its return value, which is ignored. 2662 SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex); 2663 if(ModeNo > 0x13) { 2664 infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag; 2665 } 2666 } .. SiSGetResInfo() just returns an unsigned short and this returns a values is not being used. The function does not side effect anything, so it does look like a redundant call. Is this intentional? 3044 unsigned short 3045 SiS_GetResInfo(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned short ModeIdIndex) 3046 { 3047 if(ModeNo <= 0x13) 3048 return ((unsigned short)SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ResInfo); 3049 else 3050 return ((unsigned short)SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO); 3051 } Colin

1 0

[PATCH v1 0/1] drm/imx/dcss: Add interconnect support
by Guido Günther 01 Dec '20

01 Dec '20

This allows us to raise DRAM bandiwth to a high enough value for a stable picture on i.mx8mq. We pick a bandwidth that should be sufficient for 4k@60Hz. This was tested on a Librem 5 with the (not yet) mainline mhdp DP controller. Without that initial boot works fine but e.g. fb unblank results in a cyan screen. Modelled like mdp5_kms. Guido Günther (1): drm/imx/dcss: Add interconnect support drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++++++++++++++++++++++++++-- drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++ 2 files changed, 48 insertions(+), 2 deletions(-) -- 2.29.2

2 2

[PATCH] drm: mxsfb: Add interconnect path request
by Martin Kepplinger 01 Dec '20

01 Dec '20

Add interconnect support to mxsfb so that it is able to request enough bandwidth to DDR for display output to work. Signed-off-by: Martin Kepplinger <martin.kepplinger(a)puri.sm> --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 33 +++++++++++++++++++++++++++++++ drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++ drivers/gpu/drm/mxsfb/mxsfb_kms.c | 13 ++++++++++++ 3 files changed, 48 insertions(+) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 6faf17b6408d..b05e8e5f1e38 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -15,6 +15,7 @@ #include <linux/of_device.h> #include <linux/platform_device.h> #include <linux/pm_runtime.h> +#include <linux/interconnect.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> @@ -311,6 +312,34 @@ static const struct of_device_id mxsfb_dt_ids[] = { }; MODULE_DEVICE_TABLE(of, mxsfb_dt_ids); + +static int mxsfb_init_icc(struct platform_device *pdev) +{ + struct drm_device *drm = platform_get_drvdata(pdev); + struct mxsfb_drm_private *mxsfb = drm->dev_private; + int ret; + + /* Optional interconnect request */ + mxsfb->icc_path = devm_of_icc_get(&pdev->dev, "lcdif-dram"); + if (IS_ERR(mxsfb->icc_path)) { + ret = PTR_ERR(mxsfb->icc_path); + if (ret == -EPROBE_DEFER) + return ret; + + mxsfb->icc_path = NULL; + dev_dbg(drm->dev, + "No interconnect may cause display underflows!\n"); + } + + ret = icc_set_bw(mxsfb->icc_path, 0, MBps_to_icc(700)); + if (ret) { + dev_err(drm->dev, "%s: icc_set_bw failed: %d\n", __func__, ret); + return ret; + } + + return 0; +} + static int mxsfb_probe(struct platform_device *pdev) { struct drm_device *drm; @@ -329,6 +358,10 @@ static int mxsfb_probe(struct platform_device *pdev) if (ret) goto err_free; + ret = mxsfb_init_icc(pdev); + if (ret) + goto err_free; + ret = drm_dev_register(drm, 0); if (ret) goto err_unload; diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h index 399d23e91ed1..d74ff4818e62 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h @@ -41,6 +41,8 @@ struct mxsfb_drm_private { struct drm_encoder encoder; struct drm_connector *connector; struct drm_bridge *bridge; + + struct icc_path *icc_path; }; static inline struct mxsfb_drm_private * diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 3e1bb0aefb87..8925ee7deeaa 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -13,6 +13,7 @@ #include <linux/iopoll.h> #include <linux/pm_runtime.h> #include <linux/spinlock.h> +#include <linux/interconnect.h> #include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> @@ -310,6 +311,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); struct drm_device *drm = mxsfb->drm; dma_addr_t paddr; + int ret; + + ret = icc_enable(mxsfb->icc_path); + if (ret) + dev_err_ratelimited(drm->dev, "%s: icc_enable failed: %d\n", + __func__, ret); pm_runtime_get_sync(drm->dev); mxsfb_enable_axi_clk(mxsfb); @@ -334,6 +341,7 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc, struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); struct drm_device *drm = mxsfb->drm; struct drm_pending_vblank_event *event; + int ret; mxsfb_disable_controller(mxsfb); @@ -349,6 +357,11 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc, mxsfb_disable_axi_clk(mxsfb); pm_runtime_put_sync(drm->dev); + + ret = icc_disable(mxsfb->icc_path); + if (ret) + dev_err_ratelimited(drm->dev, "%s: icc_disable failed: %d\n", + __func__, ret); } static int mxsfb_crtc_enable_vblank(struct drm_crtc *crtc) -- 2.20.1

2 1

GPU-side memory protection landscape
by Alexander Monakov 01 Dec '20

01 Dec '20

Hi, On #dri-devel Daniel invited me to chime in on the topic of clearing GPU memory handed to userspace, so here I go. I was asking how information leak from giving userspace dirty memory previously used by another process is not seen as a security issue. I was pointed to a recent thread, which offers a little perspective: https://lists.freedesktop.org/archives/dri-devel/2020-November/287144.html I think the main argument shown there is weak: > And for the legacy node model with authentication of clients against > the X server, leaking that all around was ok. seeing how there's the XCSECURITY extension that is supposed to limit what clients can retrieve, or there could be two X servers running for different users. My other concern is how easy it is to cause system instability or hangs by out-of-bounds writes from the GPU (via compute shaders or copy commands). In my experience of several years doing GPU computing with NVIDIA tech, I don't recall needing to lose time rebooting my PC after running a buggy CUDA "kernel". Heck, I could run the GCC C testsuite on the GPU without worrying about locking myself and others from the server. But now when I develop on a laptop with AMD's latest mobile SoC, every time I make a mistake in my GLSL code it more often than not forces a reboot. I hope you understand what a huge pain it is. What are the existing GPU hardware capabilities for memory protection (both in terms of preventing random accesses to system memory like with an IOMMU, and in terms of isolating different process contexts from each other), and to what extend Linux DRM drivers are taking advantage of them? Would you consider producing a document with answers to the above so users know what to expect? Thank you. Alexander

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2020