dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[PATCH 0/2] drm/msm: HDMI PHY rework for MSM8x94 support
by Stephane Viau 19 Jun '15

19 Jun '15

This it to follow up with my RFC sent a few days ago[1]. Since the RFC got discussed and approved through IRC, here are the actual patches. Rgds, Stephane. [1] http://lists.freedesktop.org/archives/dri-devel/2015-June/084788.html Stephane Viau (2): drm/msm/hdmi: remove ->reset() from HDMI PHY drm/msm: Add support for msm8x94 drivers/gpu/drm/msm/hdmi/hdmi.c | 30 ++++++---- drivers/gpu/drm/msm/hdmi/hdmi.h | 1 - drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 8 ++- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 94 +++++++++++++++++++++++++------ drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 52 ----------------- drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 32 ----------- drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 57 ------------------- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 73 +++++++++++++++++++++++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 8 ++- 9 files changed, 179 insertions(+), 176 deletions(-) -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 2

[PATCH] drm/atomic: Don't set crtc_state->enable manually
by Laurent Pinchart 19 Jun '15

19 Jun '15

The enable field needs to be kept in sync with the mode_blob field. Call drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false in order to dereference the mode blob correctly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> --- drivers/gpu/drm/drm_atomic_helper.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) Another option would be to open-code the mode blob unreference in update_output_state(). I'm not sure what's best. diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 536ae4da4665..64c75af1c088 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1554,6 +1554,8 @@ static int update_output_state(struct drm_atomic_state *state, } for_each_crtc_in_state(state, crtc, crtc_state, i) { + unsigned int num_connectors; + /* Don't update ->enable for the CRTC in the set_config request, * since a mismatch would indicate a bug in the upper layers. * The actual modeset code later on will catch any @@ -1561,10 +1563,12 @@ static int update_output_state(struct drm_atomic_state *state, if (crtc == set->crtc) continue; - crtc_state->enable = - drm_atomic_connectors_for_crtc(state, crtc); - if (!crtc_state->enable) + num_connectors = drm_atomic_connectors_for_crtc(state, crtc); + if (!num_connectors) { + ret = drm_atomic_set_mode_prop_for_crtc(crtc_state, + NULL); crtc_state->active = false; + } } return 0; -- Regards, Laurent Pinchart

2 1

[PATCH] drm/atomic: Extract needs_modeset function
by Daniel Vetter 19 Jun '15

19 Jun '15

We use the same check already in the atomic core, so might as well make this official. And it's also reused in e.g. i915. Motivated by Maarten's idea to extract a connector_changed state out of mode_changed. Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 3 +-- drivers/gpu/drm/drm_atomic_helper.c | 16 +++++----------- include/drm/drm_atomic.h | 6 ++++++ 3 files changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index c7e59b074e62..f6f2fb58eb37 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1216,8 +1216,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state) if (!state->allow_modeset) { for_each_crtc_in_state(state, crtc, crtc_state, i) { - if (crtc_state->mode_changed || - crtc_state->active_changed) { + if (drm_atomic_crtc_needs_modeset(crtc_state)) { DRM_DEBUG_ATOMIC("[CRTC:%d] requires full modeset\n", crtc->base.id); return -EINVAL; diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 536ae4da4665..b06a607db6c2 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -331,12 +331,6 @@ mode_fixup(struct drm_atomic_state *state) return 0; } -static bool -needs_modeset(struct drm_crtc_state *state) -{ - return state->mode_changed || state->active_changed; -} - /** * drm_atomic_helper_check_modeset - validate state object for modeset changes * @dev: DRM device @@ -414,7 +408,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, crtc_state->active_changed = true; } - if (!needs_modeset(crtc_state)) + if (!drm_atomic_crtc_needs_modeset(crtc_state)) continue; DRM_DEBUG_ATOMIC("[CRTC:%d] needs all connectors, enable: %c, active: %c\n", @@ -564,7 +558,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state) old_crtc_state = old_state->crtc_states[drm_crtc_index(old_conn_state->crtc)]; if (!old_crtc_state->active || - !needs_modeset(old_conn_state->crtc->state)) + !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state)) continue; encoder = old_conn_state->best_encoder; @@ -601,7 +595,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state) const struct drm_crtc_helper_funcs *funcs; /* Shut down everything that needs a full modeset. */ - if (!needs_modeset(crtc->state)) + if (!drm_atomic_crtc_needs_modeset(crtc->state)) continue; if (!old_crtc_state->active) @@ -792,7 +786,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, const struct drm_crtc_helper_funcs *funcs; /* Need to filter out CRTCs where only planes change. */ - if (!needs_modeset(crtc->state)) + if (!drm_atomic_crtc_needs_modeset(crtc->state)) continue; if (!crtc->state->active) @@ -819,7 +813,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, continue; if (!connector->state->crtc->state->active || - !needs_modeset(connector->state->crtc->state)) + !drm_atomic_crtc_needs_modeset(connector->state->crtc->state)) continue; encoder = connector->state->best_encoder; diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 1bbfedf466b9..8a3a913320eb 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -163,5 +163,11 @@ int __must_check drm_atomic_async_commit(struct drm_atomic_state *state); (plane_state) = (state)->plane_states[__i], 1); \ (__i)++) \ if (plane_state) +static inline bool +drm_atomic_crtc_needs_modeset(struct drm_crtc_state *state) +{ + return state->mode_changed || state->active_changed; +} + #endif /* DRM_ATOMIC_H_ */ -- 2.1.4

3 2

[PATCH] MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section
by Philipp Zabel 19 Jun '15

19 Jun '15

The ipu-v3 core driver is maintained in and merged through the same trees as the imx-drm drivers that are using it. This patch adds the drivers/gpu/ipu-v3/ directory to the i.MX DRM driver section. Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index af802b3..9d2f612 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3402,6 +3402,7 @@ M: Philipp Zabel <p.zabel(a)pengutronix.de> L: dri-devel(a)lists.freedesktop.org S: Maintained F: drivers/gpu/drm/imx/ +F: drivers/gpu/ipu-v3/ F: Documentation/devicetree/bindings/drm/imx/ DRM DRIVERS FOR NVIDIA TEGRA -- 2.1.4

1 0

[PATCH] drm/imx: tve: fix media bus format for VGA output
by Philipp Zabel 19 Jun '15

19 Jun '15

Commit a7c6e76feeb1 ("drm/imx: switch to use media bus formats") accidentally replaced IPU_PIX_FMT_GBR24 with MEDIA_BUS_FMT_YUV8_1X24 instead of the correct MEDIA_BUS_FMT_GBR888_1X24. Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- drivers/gpu/drm/imx/imx-tve.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index 214ecee..e671ad3 100644 --- a/drivers/gpu/drm/imx/imx-tve.c +++ b/drivers/gpu/drm/imx/imx-tve.c @@ -301,7 +301,7 @@ static void imx_tve_encoder_prepare(struct drm_encoder *encoder) switch (tve->mode) { case TVE_MODE_VGA: - imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_YUV8_1X24, + imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_GBR888_1X24, tve->hsync_pin, tve->vsync_pin); break; case TVE_MODE_TVOUT: -- 2.1.4

1 0

[PATCH v10 00/17] drm/exynos: atomic modesetting support
by Gustavo Padovan 19 Jun '15

19 Jun '15

From: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. v2: fixes comments by Joonyoung - remove unused var in patch 09 - use ->disable instead of outdated ->dpms in hdmi code - remove WARN_ON from crtc enable/disable v3: fixes comment by Joonyoung - move the removal of drm_helper_disable_unused_functions() to separated patch v4: add patches that remove unnecessary calls to disable_plane() v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) v6: rebase on latest exynos_drm_next v7: fix comments by Joonyoung - fix two checkpatch errors - remove extra crtc->commit() call - check for null fb on exynos_check_plane() v8: fix comments by Joonyoung - fix merge error - move drm_crtc_vblank_get to the commit that introduces atomic pageflip - remove .prepare() in the apropiated patch - add a new patch to move exynos_drm_crtc_disable() v9: * fix comments by Joonyoung - also remove encoder .prepare() - do not shift exynos_update_plane() parameters - remove unused .mode_set() and .mode_set_base() * add specific exynos .atomic_commit() * add split of exynos_crtc->ops->dpms() into enable() and disable() * add other atomic clean ups v10: * fix comments by Joonyoung - add more comments on exynos_atomic_commit() - make exynos_crtc's .enable and .disable void Gustavo --- Gustavo Padovan (15): drm/exynos: atomic phase 1: use drm_plane_helper_update() drm/exynos: atomic phase 1: use drm_plane_helper_disable() drm/exynos: atomic phase 1: add .mode_set_nofb() callback drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy() drm/exynos: atomic phase 2: keep track of framebuffer pointer drm/exynos: atomic phase 3: atomic updates of planes drm/exynos: atomic phase 3: use atomic .set_config helper drm/exynos: atomic phase 3: convert page flips drm/exynos: remove exported functions from exynos_drm_plane drm/exynos: don't disable unused functions at init drm/exynos: move exynos_drm_crtc_disable() drm/exynos: add exynos specific .atomic_commit() drm/exynos: atomic dpms support drm/exynos: remove unnecessary calls to disable_plane() drm/exynos: split exynos_crtc->dpms in enable() and disable() Joonyoung Shim (2): drm/exynos: fix source data argument for plane drm/exynos: use adjusted_mode of crtc_state instead of mode drivers/gpu/drm/bridge/ps8622.c | 6 +- drivers/gpu/drm/bridge/ptn3460.c | 6 +- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 91 +++---------- drivers/gpu/drm/exynos/exynos_dp_core.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 201 ++++++---------------------- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 35 +---- drivers/gpu/drm/exynos/exynos_drm_fb.c | 41 ++++++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 - drivers/gpu/drm/exynos/exynos_drm_fimd.c | 71 +++------- drivers/gpu/drm/exynos/exynos_drm_plane.c | 137 ++++++++++--------- drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 59 ++++---- drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- drivers/gpu/drm/exynos/exynos_mixer.c | 26 +--- 18 files changed, 269 insertions(+), 458 deletions(-) -- 2.1.0

7 41

[PATCH] drm/exynos: do not wait for vblank at atomic operation
by Inki Dae 19 Jun '15

19 Jun '15

This patch resolves the issue that refresh rate got low at extension mode test with fimd and vidi combination. The problem was because atomic_commit callback waited for the completion of vblank to gaurantee crtc relevant registers are updated from shadow registers to real ones. However, the waiting there is really unnecessary because page flip operation does already it. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 789db6f..2b6320e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -295,8 +295,6 @@ static int exynos_atomic_commit(struct drm_device *dev, drm_atomic_helper_commit_planes(dev, state); - drm_atomic_helper_wait_for_vblanks(dev, state); - drm_atomic_helper_cleanup_planes(dev, state); drm_atomic_state_free(state); -- 1.7.9.5

1 0

[PATCH 1/2] drm/radeon: compute ring fix hibernation (CI GPU family).
by j.glisse＠gmail.com 19 Jun '15

19 Jun '15

From: Jérôme Glisse <jglisse(a)redhat.com> In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which correspond to a suspend inside the radeon kernel driver) and turn off each of the block. It turns out we were not cleanly shutting down the compute ring. This patch fix that. Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Cc: stable(a)vger.kernel.org Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/cik.c | 55 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 55 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index ba50f3c..d2576d4 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -4592,6 +4592,61 @@ static void cik_cp_compute_enable(struct radeon_device *rdev, bool enable) if (enable) WREG32(CP_MEC_CNTL, 0); else { + u32 tmp; + int idx, j; + + /* + * To make hibernation reliable we need to clear compute ring + * configuration before halting the compute ring. + */ + mutex_lock(&rdev->srbm_mutex); + + idx = CAYMAN_RING_TYPE_CP1_INDEX; + cik_srbm_select(rdev, rdev->ring[idx].me, + rdev->ring[idx].pipe, + rdev->ring[idx].queue, 0); + /* Disable wptr polling. */ + tmp = RREG32(CP_PQ_WPTR_POLL_CNTL); + tmp &= ~WPTR_POLL_EN; + WREG32(CP_PQ_WPTR_POLL_CNTL, tmp); + /* Disable HQD. */ + if (RREG32(CP_HQD_ACTIVE) & 1) { + WREG32(CP_HQD_DEQUEUE_REQUEST, 1); + for (j = 0; j < rdev->usec_timeout; j++) { + if (!(RREG32(CP_HQD_ACTIVE) & 1)) + break; + udelay(1); + } + WREG32(CP_HQD_DEQUEUE_REQUEST, 0); + WREG32(CP_HQD_PQ_RPTR, 0); + WREG32(CP_HQD_PQ_WPTR, 0); + } + cik_srbm_select(rdev, 0, 0, 0, 0); + + idx = CAYMAN_RING_TYPE_CP2_INDEX; + cik_srbm_select(rdev, rdev->ring[idx].me, + rdev->ring[idx].pipe, + rdev->ring[idx].queue, 0); + /* Disable wptr polling. */ + tmp = RREG32(CP_PQ_WPTR_POLL_CNTL); + tmp &= ~WPTR_POLL_EN; + WREG32(CP_PQ_WPTR_POLL_CNTL, tmp); + /* Disable HQD. */ + if (RREG32(CP_HQD_ACTIVE) & 1) { + WREG32(CP_HQD_DEQUEUE_REQUEST, 1); + for (j = 0; j < rdev->usec_timeout; j++) { + if (!(RREG32(CP_HQD_ACTIVE) & 1)) + break; + udelay(1); + } + WREG32(CP_HQD_DEQUEUE_REQUEST, 0); + WREG32(CP_HQD_PQ_RPTR, 0); + WREG32(CP_HQD_PQ_WPTR, 0); + } + cik_srbm_select(rdev, 0, 0, 0, 0); + + mutex_unlock(&rdev->srbm_mutex); + WREG32(CP_MEC_CNTL, (MEC_ME1_HALT | MEC_ME2_HALT)); rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX].ready = false; rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX].ready = false; -- 1.7.1

2 2

[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj
by Krzysztof Kozlowski 19 Jun '15

19 Jun '15

The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is not referenced anywhere. One instance of 'exynos_drm_gem_obj' may be mapped to multiple user-space VMAs so 'vma' field does not look useful anyway. Signed-off-by: Krzysztof Kozlowski <k.kozlowski(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h b/drivers/gpu/drm/exynos/exynos_drm_gem.h index 308173cb4f0a..6f42e2248288 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf { * or at framebuffer creation. * @size: size requested from user, in bytes and this size is aligned * in page unit. - * @vma: a pointer to vm_area. * @flags: indicate memory type to allocated buffer and cache attruibute. * * P.S. this object would be transferred to user as kms_bo.handle so @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj { struct drm_gem_object base; struct exynos_drm_gem_buf *buffer; unsigned long size; - struct vm_area_struct *vma; unsigned int flags; }; -- 1.9.1

2 3

[PATCH 0/6] Improve GK20A and introduce GM20B support
by Alexandre Courbot 19 Jun '15

19 Jun '15

Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files officially released by NVIDIA. As you know such firmwares will soon become a necessity for newer GPUs because some falcons will require signed firmware to operate. In addition there is no reverse-engineered version of the GK20A firmwares yet, so since an external file is needed anyway, it may as well be provided officially. NVIDIA plans to release firmwares as one file per binary to keep things simple. The layout will be nvidia/<gpu>/<firmware>.bin, so for GK20A FECS/GPCCS we have: nvidia/gk20a/fecs_inst.bin (aka fuc409c) nvidia/gk20a/fecs_data.bin (aka fuc409d) nvidia/gk20a/gpccs_inst.bin (aka fuc41ac) nvidia/gk20a/gpccs_data.bin (aka fuc41ad) All firmware files listed in this patchset are clean for release, and I am just waiting for a community ack of the layout to send a patch to linux-firmware. The second patch reworks existing GK20A support to make it closer to what our nvgpu driver does. Support so far was heavily based on GK104, which somehow made me feel uneasy - and quite scared after I looked more closely at what nvgpu does. In particular the GK104 MMIO bundles differed significantly from what nvgpu does. This change aligns things and (probably less significant, but still safer) reorders the initialization sequence to match the one of nvgpu. You will note that the MMIO bundles now come as firmware files of their own. I am not sure the community will be pleased with an increase of firmware files, however the rationale for this is as follows: - These initialization sequences are related to the firmwares, so it makes sense to distribute them under the same medium - If NVIDIA needs to update the firmwares for some reason, it can atomically update the MMIO bundles and provide a coherent set, instead of having to introduce versioning into the firmware and driver - For IP reasons, I as an NVIDIA employee cannot extract these register sequences and link them into Nouveau - These are just a bunch of register address/value pairs anyway The new firmware files introduced are: nvidia/gk20a/sw_nonctx.bin (gr_pack_mmio) nvidia/gk20a/sw_ctx.bin (grctx_pack_hub, grctx_pack_gpc, grctx_pack_zcull, grctx_pack_tpc, grctx_pack_ppc) nvidia/gk20a/sw_bundle_init.bin (grctx_pack_icmd) nvidia/gk20a/sw_method_init.bin (grctx_pack_mthd) Third patch is trivial and adds the GM20B FIFO device. Fourth patch adds GM20B GR based on the reworked GK20A support. GM20B will rely on the same firmware files as GK20A (also clean for release). Note that this is not full support yet for released devices, which will require secure boot. This will be my focus once this patchset is merged (Deepak got a working version, but there is still a lot of work to do on it before it is upstreamable). The last two patches recognize GM20B at the device and platform level. Nothing really exciting. I hope the addition of firmware files will not become too controversial. If it does, I have good arguments to support it. ;) Besides the GK20A rework that probably few people care about, the point is the addition of a basic layout for the firmwares that NVIDIA will officially release to finally support secure boot, and I would like to make sure we get this right. Thanks, Alex. Alexandre Courbot (6): gr: support for NVIDIA-provided firmwares gr/gk20a: use same initialization sequence as nvgpu fifo: add GM20B fifo gr: add GM20B support device: recognize GM20B platform: recognize GM20B drm/nouveau/include/nvkm/engine/fifo.h | 1 + drm/nouveau/include/nvkm/engine/gr.h | 1 + drm/nouveau/nouveau_platform.c | 1 + drm/nouveau/nvkm/engine/device/gm100.c | 20 ++ drm/nouveau/nvkm/engine/fifo/Kbuild | 1 + drm/nouveau/nvkm/engine/fifo/gk104.h | 4 + drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +- drm/nouveau/nvkm/engine/fifo/gm20b.c | 34 ++++ drm/nouveau/nvkm/engine/gr/Kbuild | 2 + drm/nouveau/nvkm/engine/gr/ctxgf100.h | 7 + drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 65 +++++-- drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +- drm/nouveau/nvkm/engine/gr/ctxgm204.c | 4 +- drm/nouveau/nvkm/engine/gr/ctxgm20b.c | 110 +++++++++++ drm/nouveau/nvkm/engine/gr/gf100.c | 70 +++++-- drm/nouveau/nvkm/engine/gr/gf100.h | 18 ++ drm/nouveau/nvkm/engine/gr/gk20a.c | 336 +++++++++++++++++++++++++++++++-- drm/nouveau/nvkm/engine/gr/gk20a.h | 35 ++++ drm/nouveau/nvkm/engine/gr/gm20b.c | 84 +++++++++ 19 files changed, 748 insertions(+), 49 deletions(-) create mode 100644 drm/nouveau/nvkm/engine/fifo/gm20b.c create mode 100644 drm/nouveau/nvkm/engine/gr/ctxgm20b.c create mode 100644 drm/nouveau/nvkm/engine/gr/gk20a.h create mode 100644 drm/nouveau/nvkm/engine/gr/gm20b.c -- 2.4.3

3 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015