similar to: [PATCH v2] drm: Bump encoder limit from 32 to 64

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1 eDP port and 5 DP ports. On the P71,

On Tue, Aug 20, 2019 at 08:16:55PM -0400, Lyude Paul wrote: > Assuming that GPUs would never have even close to 32 separate video > encoders is quite honestly a pretty reasonable assumption. Unfortunately > we do not live in a reasonable world, as it looks like it is actually > possible to find devices that will create more drm_encoder objects then > this. Case in point: the

On Thu, Mar 05, 2020 at 04:59:29PM +0100, Thomas Zimmermann wrote: > The arc driver uses empty implementations for its encoders. Replace > the code with the generic simple encoder. We should , as a follow-up patch, embed the encoder in arcgpu_drm_private. Then we drop the kzalloc() and avoid that life-time challenge. This patch looks good for what it does. Acked-by: Sam Ravnborg <sam

In multi-x-screen ZaphodHeads configurations, there isn't a one-to-one mapping of kernel provided drmmode crtc index to the index of the corresponding xf86Crtc inside the xf86CrtcConfig crtc array anymore, ie. for kernel provided drmmode->mode_res->crtcs[i], the i'th crtc won't correspond to the xf86Crtc in the i'th slot of the x-screens xf86CrtcConfig anymore, once

From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com> Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. Also removing the best_encoder hook from the drivers that only have one encoder per

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++

The patches contain some tidy-up work, and refactoring that has arisen as a by-product of my initial work on adding TV support to nv50. Joel Holdsworth (4): drm/nouveau: Removed unneeded include in nvc0_fence.c drm/nouveau: Replaced magic numbers with defines from nouveau_reg drm/nouveau: Replaced copy-pasted nv_wait with nv50_wait_dpms_ctrl helper drm/nouveau: Refactored encoder

Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Ville Syrjälä

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

This is the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: - Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. - Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that

On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS

The arc driver uses empty implementations for its encoders. Replace the code with the generic simple encoder. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++------- drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++------ 2 files changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c

On 2/18/20 1:44 PM, Christian K?nig wrote: > Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >> Hi >> >> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>> GPU address handling is device specific and should be handle by its >>> device >>> driver. >>> >>> Signed-off-by: Nirmoy Das <nirmoy.das at amd.com> >>> ---

I have a GeForce G 105M. That's, I guess, an NV50 family video card: https://nouveau.freedesktop.org/wiki/CodeNames/#NV50 My question is... does Nouveau support HDMI with this video card? According to https://nouveau.freedesktop.org/wiki/FeatureMatrix/ TVout is "TODO" and HDMI audio is "DONE". What about HDMI video? Is that grouped under TVout or is TVout supposed to be

Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: > Hi > > Am 18.02.20 um 18:13 schrieb Nirmoy: >> On 2/18/20 1:44 PM, Christian K?nig wrote: >>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>>> Hi >>>> >>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>>> GPU address handling is device specific and should be handle by its

Am 18.02.20 um 19:28 schrieb Thomas Zimmermann: > Hi > > Am 18.02.20 um 19:23 schrieb Christian K?nig: >> Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 18.02.20 um 18:13 schrieb Nirmoy: >>>> On 2/18/20 1:44 PM, Christian K?nig wrote: >>>>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:

I don't understand this patch (what are all these masks? how are they used?), and don't want to invest the time required to do so. However Mario is probably the sole serious user of ZaphodHeads, and if it fixes issues for him, probably fixes issues for others who try and give up with ZaphodHeads. Any objections if I just push this out? On Sat, Jun 27, 2015 at 8:33 PM, Mario Kleiner

mode_fixup function for encoder drivers became optional with patch http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com This patch set nukes all the dummy mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Changes v1->v2: incorporated Daniel comments * added signed-off-by line to all patches * threading enabled due to

mode_fixup function for encoder drivers became optional with patch http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com This patch set nukes all the dummy mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Changes v1->v2: incorporated Daniel comments * added signed-off-by line to all patches * threading enabled due to