dri-devel October 2019

dri-devel@lists.freedesktop.org

359 participants
1833 discussions

[PATCH] drm/panfrost: Handle resetting on timeout better
by Steven Price 09 Oct '19

09 Oct '19

Panfrost uses multiple schedulers (one for each slot, so 2 in reality), and on a timeout has to stop all the schedulers to safely perform a reset. However more than one scheduler can trigger a timeout at the same time. This race condition results in jobs being freed while they are still in use. When stopping other slots use cancel_delayed_work_sync() to ensure that any timeout started for that slot has completed. Also use mutex_trylock() to obtain reset_lock. This means that only one thread attempts the reset, the other threads will simply complete without doing anything (the first thread will wait for this in the call to cancel_delayed_work_sync()). While we're here and since the function is already dependent on sched_job not being NULL, let's remove the unnecessary checks, along with a commented out call to panfrost_core_dump() which has never existed in mainline. Signed-off-by: Steven Price <steven.price(a)arm.com> --- This is a tidied up version of the patch orginally posted here: http://lkml.kernel.org/r/26ae2a4d-8df1-e8db-3060-41638ed63e2a%40arm.com drivers/gpu/drm/panfrost/panfrost_job.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index a58551668d9a..dcc9a7603685 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -381,13 +381,19 @@ static void panfrost_job_timedout(struct drm_sched_job *sched_job) job_read(pfdev, JS_TAIL_LO(js)), sched_job); - mutex_lock(&pfdev->reset_lock); + if (!mutex_trylock(&pfdev->reset_lock)) + return; - for (i = 0; i < NUM_JOB_SLOTS; i++) - drm_sched_stop(&pfdev->js->queue[i].sched, sched_job); + for (i = 0; i < NUM_JOB_SLOTS; i++) { + struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched; + + drm_sched_stop(sched, sched_job); + if (js != i) + /* Ensure any timeouts on other slots have finished */ + cancel_delayed_work_sync(&sched->work_tdr); + } - if (sched_job) - drm_sched_increase_karma(sched_job); + drm_sched_increase_karma(sched_job); spin_lock_irqsave(&pfdev->js->job_lock, flags); for (i = 0; i < NUM_JOB_SLOTS; i++) { @@ -398,7 +404,6 @@ static void panfrost_job_timedout(struct drm_sched_job *sched_job) } spin_unlock_irqrestore(&pfdev->js->job_lock, flags); - /* panfrost_core_dump(pfdev); */ panfrost_devfreq_record_transition(pfdev, js); panfrost_device_reset(pfdev); -- 2.20.1

3 4

[PATCH 1/2] drm/fb-helper: include drm/drm_fb_cma_helper.h for missing declarations
by Ben Dooks 09 Oct '19

09 Oct '19

Include <drm/drm_fb_cma_helper.h> to fix the following warnings from missing declarations: drivers/gpu/drm/drm_fb_cma_helper.c:38:27: warning: symbol 'drm_fb_cma_get_gem_obj' was not declared. Should it be static? drivers/gpu/drm/drm_fb_cma_helper.c:62:12: warning: symbol 'drm_fb_cma_get_gem_addr' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- drivers/gpu/drm/drm_fb_helper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index a7ba5b4902d6..23e10075619f 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -45,6 +45,7 @@ #include <drm/drm_fourcc.h> #include <drm/drm_print.h> #include <drm/drm_vblank.h> +#include <drm/drm_fb_cma_helper.h> #include "drm_internal.h" -- 2.23.0

1 1

RE: [PATCH] drm/i915: customize DPCD brightness control for specific panel
by Lee, Shawn C 09 Oct '19

09 Oct '19

On Tue, 08 Oct 2019, Jani Nikula <jani.nikula(a)intel.com> wrote: >On Mon, 07 Oct 2019, Adam Jackson <ajax(a)redhat.com> wrote: >> On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote: >> >>> The problem with the EDID quirks is that exposing the quirks sticks out >>> like a sore thumb. Thus far all of it has been contained in drm_edid.c >>> and they affect how the EDID gets parsed, for all drivers. Obviously >>> this could be changed, but is it the right thing to do? >>> >>> What I suggested was, check the OUI only, and if it matches, do >>> more. Perhaps there's something in the 0x300 range of DPCD offsets that >>> you can read? Or perhaps you need to write the source OUI first, and >>> then do that. >> >> My issue isn't really with identifying the panel from EDID rather than >> DPCD, whichever identifier is most specific is probably the best thing >> to use. It's more that this quirk is identified in common code but only >> applied in one driver. If this panel were ever to be attached to some >> other source, they might well want to apply the same kind of fix. My >> (admittedly naïve) reading of the OUI handshake process is that when >> the source device writes an OUI to DP_SOURCE_OUI it is telling the sink >> "I'm about to issue commands that conform to _this_ vendor's own >> conventions". If that convention communicates information that is >> entirely contained within AUXCH transactions (and doesn't, for example, >> require looking at some other strapping pin or external device) then in >> principle it doesn't matter if the source device "matches" that OUI; it >> would be legal for an AMD GPU to write the same sequence and expect the >> same reaction, should that panel be attached to an AMD GPU. >> >> So, it would be nice to know exactly what that protocol is meant to do, >> if it applies only to this specific panel or anything else with the >> same TCON, how one would identify such TCONs in the wild other than >> EDID, if it relies on an external PWM or something, etc. And it might >> make sense for now to make this a (shudder) driver-specific EDID quirk >> rather than match by DPCD, at least until we know if the panel is ever >> seen attached to other source devices and if the OUI convention is >> self-contained. > >Thanks for clarifying. Pretty much agreed, unfortunately also on the >"would be nice to know more" part... > >If this were to be an EDID quirk after all, I wonder if it would be >better to store the parsed quirks to, say, struct drm_display_info, and >have a drm_connector_has_quirk() function similar to drm_dp_has_quirk(). > >This would also allow us to not return quirks from >drm_add_display_info(), which would arguably clean up the interface. > >BR, >Jani. Thanks for advice! I've already update patch V2. Driver will check sink OUI and confirm TCON's capability to decide to enable this method or not. It depends on TCON's feature description and does not export EDID quirk. Best regards, Shawn

1 0

[PATCH] drm/komeda: Set output color depth for output
by Lowry Li (Arm Technology China) 09 Oct '19

09 Oct '19

Set color_depth according to connector->bpc. Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- .../arm/display/komeda/d71/d71_component.c | 1 + .../gpu/drm/arm/display/komeda/komeda_crtc.c | 20 +++++++++++++++++++ .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++ .../drm/arm/display/komeda/komeda_pipeline.h | 1 + .../display/komeda/komeda_pipeline_state.c | 19 ++++++++++++++++++ .../arm/display/komeda/komeda_wb_connector.c | 4 ++++ 6 files changed, 47 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c index c3d29c0b051b..27cdb03573c1 100644 --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c @@ -951,6 +951,7 @@ static void d71_improc_update(struct komeda_component *c, to_d71_input_id(state, index)); malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize)); + malidp_write32(reg, IPS_DEPTH, st->color_depth); } static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 75263d8cd0bd..baa986b70876 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -17,6 +17,26 @@ #include "komeda_dev.h" #include "komeda_kms.h" +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths) +{ + struct drm_connector *conn; + struct drm_connector_state *conn_st; + int i, min_bpc = 31, conn_bpc = 0; + + for_each_new_connector_in_state(crtc_st->state, conn, conn_st, i) { + if (conn_st->crtc != crtc_st->crtc) + continue; + + conn_bpc = conn->display_info.bpc ? conn->display_info.bpc : 8; + + if (conn_bpc < min_bpc) + min_bpc = conn_bpc; + } + + *color_depths = GENMASK(conn_bpc, 0); +} + static void komeda_crtc_update_clock_ratio(struct komeda_crtc_state *kcrtc_st) { u64 pxlclk, aclk; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h index 45c498e15e7a..a42503451b5d 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h @@ -166,6 +166,8 @@ static inline bool has_flip_h(u32 rot) return !!(rotation & DRM_MODE_REFLECT_X); } +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths); unsigned long komeda_crtc_get_aclk(struct komeda_crtc_state *kcrtc_st); int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev *mdev); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h index b322f52ba8f2..7653f134a8eb 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h @@ -323,6 +323,7 @@ struct komeda_improc { struct komeda_improc_state { struct komeda_component_state base; + u8 color_depth; u16 hsize, vsize; }; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index 0ba9c6aa3708..e68e8f85ab27 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -743,6 +743,7 @@ komeda_improc_validate(struct komeda_improc *improc, struct komeda_data_flow_cfg *dflow) { struct drm_crtc *crtc = kcrtc_st->base.crtc; + struct drm_crtc_state *crtc_st = &kcrtc_st->base; struct komeda_component_state *c_st; struct komeda_improc_state *st; @@ -756,6 +757,24 @@ komeda_improc_validate(struct komeda_improc *improc, st->hsize = dflow->in_w; st->vsize = dflow->in_h; + if (drm_atomic_crtc_needs_modeset(crtc_st)) { + u32 output_depths; + u32 avail_depths; + + komeda_crtc_get_color_config(crtc_st, + &output_depths); + + avail_depths = output_depths & improc->supported_color_depths; + if (avail_depths == 0) { + DRM_DEBUG_ATOMIC("No available color depths, conn depths: 0x%x & display: 0x%x\n", + output_depths, + improc->supported_color_depths); + return -EINVAL; + } + + st->color_depth = __fls(avail_depths); + } + komeda_component_add_input(&st->base, &dflow->input, 0); komeda_component_set_output(&dflow->input, &improc->base, 0); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c index 2851cac94d86..740a81250630 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c @@ -142,6 +142,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, struct komeda_dev *mdev = kms->base.dev_private; struct komeda_wb_connector *kwb_conn; struct drm_writeback_connector *wb_conn; + struct drm_display_info *info; u32 *formats, n_formats = 0; int err; @@ -171,6 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs); + info = &kwb_conn->base.base.display_info; + info->bpc = __fls(kcrtc->master->improc->supported_color_depths); + kcrtc->wb_conn = kwb_conn; return 0; -- 2.17.1

3 6

[PATCH] drm/komeda: Adds zorder support
by Lowry Li (Arm Technology China) 09 Oct '19

09 Oct '19

- Creates the zpos property. - Implement komeda_crtc_normalize_zpos to replace drm_atomic_normalize_zpos, reasons as the following: 1. The drm_atomic_normalize_zpos allows to configure same zpos for different planes, but komeda doesn't support such configuration. 2. For further slave pipline case, Komeda need to calculate the max_slave_zorder, we will merge such calculation into komed_crtc_normalize_zpos to save a separated plane_state loop. 3. For feature none-scaling layer_split, which a plane_state will be assigned to two individual layers(left/right), which requires two normalize_zpos for this plane, plane_st->normalize_zpos will be used by left layer, normalize_zpos + 1 for right_layer. This patch series depends on: - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ - https://patchwork.freedesktop.org/series/59747/ - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/60083/ - https://patchwork.freedesktop.org/series/60698/ Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 90 ++++++++++++++++++++++- drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 3 + drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 +- 3 files changed, 97 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 306ea06..0ec7665 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -100,6 +100,90 @@ static void komeda_kms_commit_tail(struct drm_atomic_state *old_state) .atomic_commit_tail = komeda_kms_commit_tail, }; +static int komeda_plane_state_list_add(struct drm_plane_state *plane_st, + struct list_head *zorder_list) +{ + struct komeda_plane_state *new = to_kplane_st(plane_st); + struct komeda_plane_state *node, *last; + + last = list_empty(zorder_list) ? + NULL : list_last_entry(zorder_list, typeof(*last), zlist_node); + + /* Considering the list sequence is zpos increasing, so if list is empty + * or the zpos of new node bigger than the last node in list, no need + * loop and just insert the new one to the tail of the list. + */ + if (!last || (new->base.zpos > last->base.zpos)) { + list_add_tail(&new->zlist_node, zorder_list); + return 0; + } + + /* Build the list by zpos increasing */ + list_for_each_entry(node, zorder_list, zlist_node) { + if (new->base.zpos < node->base.zpos) { + list_add_tail(&new->zlist_node, &node->zlist_node); + break; + } else if (node->base.zpos == new->base.zpos) { + struct drm_plane *a = node->base.plane; + struct drm_plane *b = new->base.plane; + + /* Komeda doesn't support setting a same zpos for + * different planes. + */ + DRM_DEBUG_ATOMIC("PLANE: %s and PLANE: %s are configured same zpos: %d.\n", + a->name, b->name, node->base.zpos); + return -EINVAL; + } + } + + return 0; +} + +static int komeda_crtc_normalize_zpos(struct drm_crtc *crtc, + struct drm_crtc_state *crtc_st) +{ + struct drm_atomic_state *state = crtc_st->state; + struct komeda_plane_state *kplane_st; + struct drm_plane_state *plane_st; + struct drm_framebuffer *fb; + struct drm_plane *plane; + struct list_head zorder_list; + int order = 0, err; + + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n", + crtc->base.id, crtc->name); + + INIT_LIST_HEAD(&zorder_list); + + /* This loop also added all effected planes into the new state */ + drm_for_each_plane_mask(plane, crtc->dev, crtc_st->plane_mask) { + plane_st = drm_atomic_get_plane_state(state, plane); + if (IS_ERR(plane_st)) + return PTR_ERR(plane_st); + + /* Build a list by zpos increasing */ + err = komeda_plane_state_list_add(plane_st, &zorder_list); + if (err) + return err; + } + + list_for_each_entry(kplane_st, &zorder_list, zlist_node) { + plane_st = &kplane_st->base; + fb = plane_st->fb; + plane = plane_st->plane; + + plane_st->normalized_zpos = order++; + + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] zpos:%d, normalized zpos: %d\n", + plane->base.id, plane->name, + plane_st->zpos, plane_st->normalized_zpos); + } + + crtc_st->zpos_changed = true; + + return 0; +} + static int komeda_kms_check(struct drm_device *dev, struct drm_atomic_state *state) { @@ -111,7 +195,7 @@ static int komeda_kms_check(struct drm_device *dev, if (err) return err; - /* komeda need to re-calculate resource assumption in every commit + /* Komeda need to re-calculate resource assumption in every commit * so need to add all affected_planes (even unchanged) to * drm_atomic_state. */ @@ -119,6 +203,10 @@ static int komeda_kms_check(struct drm_device *dev, err = drm_atomic_add_affected_planes(state, crtc); if (err) return err; + + err = komeda_crtc_normalize_zpos(crtc, new_crtc_st); + if (err) + return err; } err = drm_atomic_helper_check_planes(dev, state); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h index 178bee6..d1cef46 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h @@ -7,6 +7,7 @@ #ifndef _KOMEDA_KMS_H_ #define _KOMEDA_KMS_H_ +#include <linux/list.h> #include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_crtc_helper.h> @@ -46,6 +47,8 @@ struct komeda_plane { struct komeda_plane_state { /** @base: &drm_plane_state */ struct drm_plane_state base; + /** @zlist_node: zorder list node */ + struct list_head zlist_node; /* @img_enhancement: on/off image enhancement */ u8 img_enhancement : 1; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index bcf30a7..aad7663 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c @@ -21,7 +21,7 @@ memset(dflow, 0, sizeof(*dflow)); - dflow->blending_zorder = st->zpos; + dflow->blending_zorder = st->normalized_zpos; /* if format doesn't have alpha, fix blend mode to PIXEL_NONE */ dflow->pixel_blend_mode = fb->format->has_alpha ? @@ -343,6 +343,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, if (err) goto cleanup; + err = drm_plane_create_zpos_property(plane, layer->base.id, 0, 8); + if (err) + goto cleanup; + return 0; cleanup: komeda_plane_destroy(plane); -- 1.9.1

3 3

[PATCH v2 0/2] drm/komeda: Add layer line size support
by Lowry Li (Arm Technology China) 09 Oct '19

09 Oct '19

Hi, >From D32 every component have a line size register to indicate internal fifo size, instead of using the global line_sz. This serie aims at adding the layer line size support and check accordingly on both D71 and D32 or newer. Changes since v1: Rebases to drm-misc-next branch. Lowry Li (Arm Technology China) (2): drm/komeda: Add line size support drm/komeda: Adds layer horizontal input size limitation check for D71 .../arm/display/komeda/d71/d71_component.c | 106 ++++++++++++++++-- .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 9 +- .../drm/arm/display/komeda/komeda_pipeline.h | 2 + .../display/komeda/komeda_pipeline_state.c | 17 +++ 4 files changed, 119 insertions(+), 15 deletions(-) -- 2.17.1

3 9

linux-next: manual merge of the drm-misc tree with the drm tree
by Stephen Rothwell 09 Oct '19

09 Oct '19

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_gem_gtt.c between commit: 1e0a96e50882 ("drm/i915: export color_differs") from the drm tree and commit: 71724f708997 ("drm/mm: Use helpers for drm_mm_node booleans") from the drm-misc tree. I fixed it up (I used the former change) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell

1 0

linux-next: manual merge of the drm-misc tree with the drm tree
by Stephen Rothwell 09 Oct '19

09 Oct '19

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_vma.c between commits: 1e0a96e50882 ("drm/i915: export color_differs") 33dd88992313 ("drm/i915: cleanup cache-coloring") b290a78b5c3d ("drm/i915: Use helpers for drm_mm_node booleans") 5e053450c1c3 ("drm/i915: Only track bound elements of the GTT") 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") from the drm tree and commit: 71724f708997 ("drm/mm: Use helpers for drm_mm_node booleans") from the drm-misc tree. I fixed it up (the subset of 71724f708997 affecting this file is in b290a78b5c3d) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell

1 0

linux-next: manual merge of the drm-misc tree with the drm tree
by Stephen Rothwell 08 Oct '19

08 Oct '19

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_gem.c between commits: b290a78b5c3d ("drm/i915: Use helpers for drm_mm_node booleans") 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") from the drm tree and commit: 71724f708997 ("drm/mm: Use helpers for drm_mm_node booleans") from the drm-misc tree. I fixed it up (b290a78b5c3d and 71724f708997 do basically identical things to this file ...) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell

1 0

linux-next: manual merge of the drm-misc tree with the drm tree
by Stephen Rothwell 08 Oct '19

08 Oct '19

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_drv.c between commit: 2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()") from the drm tree and commit: f2521f7731ed ("drm/i915: switch to drm_fb_helper_remove_conflicting_pci_framebuffers") from the drm-misc tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/i915/i915_drv.c index 15abad5c2d62,1c4ff8b5b0a2..000000000000 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@@ -350,44 -422,6 +350,19 @@@ out return ret; } - static int i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv) - { - struct apertures_struct *ap; - struct pci_dev *pdev = dev_priv->drm.pdev; - struct i915_ggtt *ggtt = &dev_priv->ggtt; - bool primary; - int ret; - - ap = alloc_apertures(1); - if (!ap) - return -ENOMEM; - - ap->ranges[0].base = ggtt->gmadr.start; - ap->ranges[0].size = ggtt->mappable_end; - - primary = - pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW; - - ret = drm_fb_helper_remove_conflicting_framebuffers(ap, "inteldrmfb", primary); - - kfree(ap); - - return ret; - } - +static void i915_driver_modeset_remove(struct drm_i915_private *i915) +{ + intel_modeset_driver_remove(i915); + + intel_bios_driver_remove(i915); + + i915_switcheroo_unregister(i915); + + intel_vga_unregister(i915); + + intel_csr_ucode_fini(i915); +} + static void intel_init_dpio(struct drm_i915_private *dev_priv) { /*

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2019