Still in the process of reviewing this, but one minor change that should be
done on all of the patches (which I didn't notice before, whoops):
s:drm/dp-mst:drm/dp_mst:g
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add necessary support for MST DSC.
> (Display Stream COmpression over
Agh, sorry to go back on this - I'm noticing a lot more changes we should have
now that I've been able apply this locally to my tree. See below:
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> With DSC, bpp can be a multiple of 1/16, so
> drm_dp_calc_pbn_mode is insufficient.
>
> Add dr
For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
video timing "64:27" video format correctly.
eg: (vic-76) 1920x1080p@60Hz,24bpp
This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
after crea
Mhhh, one last nitpick
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Instead of having drm_dp_dpcd_read/write and
> drm_dp_mst_dpcd_read/write as entry points into the
> aux code, have drm_dp_dpcd_read/write handle both.
>
> This means that DRM drivers can make MST DPCD read/writes.
>
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> This field on drm_dp_mst_branch was never filled
>
> Initialize it to zero when the list of ports is created.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
>
> v2:
Hi all,
After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
'smu_v11_0_setup_pptable':
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may
be used uninitiali
On Thu, Aug 22, 2019 at 6:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
> 'smu_v11_0_setup_pptable':
> drivers/gpu/drm/amd/amdgpu
On 22/08/2019 21:24, Jason Ekstrand wrote:
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>
wrote:
We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.
Si
DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
which is required to add support for systems with Thunderbolt or other
repeater devices.
Cc: Abdoulaye Berthe
Cc: Harry Wentland
Cc: Leo Li
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Abdoulaye Berthe
---
include/drm/
Quoting Lyude Paul (2019-08-22 21:31:27)
> Now that we've fixed i915 so that it sets a max SG segment length and
> gotten rid of the relevant warnings, let's enable
> CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
> this in the future as well.
>
> Signed-off-by: Lyude Paul
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
> Hi Peter,
>
> Iirc you've been involved at least somewhat in discussing this. -mm folks
> are a bit undecided whether these new non_block semantics are a good idea.
> Michal Hocko still is in support, but Andrew Morton and Jason Gunthorpe
Hi Boris,
On Thu, Aug 22, 2019 at 07:00:11PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:17:05 +0300 Laurent Pinchart wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multipl
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
> two helper functions for MST DSC
>
> The former, given a port, returns the raw DPCD DSC caps off
> that port.
>
> The latter, given a port, enables or disables DSC on that port.
OK-done reviewing, but there's some stuff missing here. The PBN bandwidth
checks in https://patchwork.freedesktop.org/patch/325604/?series=65423&rev=3
need to be moved into drm_dp_mst_atomic_check(), along with moving amdgpu over
to using drm_dp_mst_atomic_check(). Doing so will also give us PBN b
Now that we've fixed i915 so that it sets a max SG segment length and
gotten rid of the relevant warnings, let's enable
CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
this in the future as well.
Changes since v2:
* Also select DMA_API_DEBUG - Chris Wilson
Signed-off-by: Lyu
Hi Boris,
On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
>
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > + /**
> > +* @DRM_BRIDGE_OP_
Hi Boris,
On Thu, Aug 22, 2019 at 08:02:47PM +0200, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 19:35:24 +0300 Laurent Pinchart wrote:
> > On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> >> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >>
> >>> Implement the n
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
primary reviewers already.
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Signed-off-by: Rob Herring
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 67b75fc
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it add
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
d
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_colorimetr
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
sta
The drm panel bridge creates a connector using a connector type explicit
passed by the display controller or bridge driver that instantiates the
panel bridge. Now that drm_panel reports its connector type, use it and
remove the connector_type argument to drm_panel_bridge_add() and
devm_drm_panel_br
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers to fill the new field.
Signed-off-by: Laurent
On Fri, 23 Aug 2019 at 05:29, Rodrigo Vivi wrote:
>
> Hi Dave and Daniel,
>
> Here goes the final pull request targeting 5.4.
For some reason patchwork hasn't picked this up. or if it has I can't
see it. Not sure whether it was the earlier patch code in it or
something else malformed.
Dave.
On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>
> When modifying panfrost_devfreq_target() to support a device without a
> regulator defined I missed the check on the error path. Let's add it.
>
> Reported-by: Dan Carpenter
> Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work withou
Hi Linus,
Hi Linus,
Live from the laundromat after my washing machine broke down, we have
the 5.3-rc6 fixes. Changelog is in the tag below, but nothing too
noteworthy in here.
Dave.
drm-fixes-2019-08-23:
drm fixes for 5.3-rc6
rcar-du:
- LVDS dual-link mode fix
mediatek:
- of node refcount fix
Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes
With further testing of recent changes with lockdep and other locking
checks enabled, we've found several bugs in the shrinker code and one
sleep while atomic in panfrost_gem_open(). This series addresses those
issues.
Delaying the un
Calls to panfrost_device_fini() access the h/w, but we already done a
pm_runtime_put_sync_autosuspend() beforehand. This only works if the
autosuspend delay is long enough. A 0ms delay will hang the system when
removing the device. Fix this by moving the pm_runtime_put_sync_suspend()
after the panf
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which touches the h/w. The
autosuspend delay keeps
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associated with resuming.
Cc: Tomeu Vizoso
Cc: St
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
Cc
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
backing pages have already been released by the shrinker. The result is
the following abort:
Unable to handle kernel paging request at virtual address 898ed000
Mem abort info:
ESR = 0x96000147
Exception class = DA
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
There is also a problem that we could be accessing the h/w when suspended.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airli
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
WA
The following changes since commit 4d352dbd5850bfc752609d46b5c8403ae0bd5163:
drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug
(2019-07-19 16:26:51 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-5.3
for you to fetch changes up to c358ebf5963
Hey Dave,
This is mostly just the stuff I missed last round. Various cleanup
patches + fixes, improvements to display colour management, and some
code to avoid loading when power cables aren't properly attached.
There may be a second round next week with more changes, development
system died une
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/mediatek/mtk_drm_drv.c
between commit:
4c6f3196e6ea ("drm/mediatek: use correct device to import PRIME buffers")
from the drm-fixes tree and commit:
3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/impo
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #26 from gurchetansi...@chromium.org ---
An issue similar occurs when running Civ6 on Virgl. Is there any to disable
TGSI indirect indexing for testing purposes?
--
You are receiving this mail because:
You are the assignee for the
From: Rob Clark
I'm sure there is plenty more to remove.. this is just some of the ones
I noticed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/
Hi Laurent.
Thanks for looking into this, but you will not be happy in a minute...
On Fri, Aug 23, 2019 at 04:40:32AM +0300, Laurent Pinchart wrote:
> Add a type field to the drm_panel structure to report the panel type,
> using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
>
On Fri, 23 Aug 2019 03:34:06 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
> >
> > > +/**
> > > + * enum drm_bridge_ops - Bitmask of operations supported by the brid
From: Thomas Hellstrom
The FAULT_FLAG_ALLOW_RETRY semantics is tricky and appears poorly
documented. Add a comment to the TTM fault() implementation to avoid
future confusion.
Cc: Christian Koenig
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 11 +++
1 file cha
https://bugzilla.kernel.org/show_bug.cgi?id=197327
xtornado (xtorn...@gmail.com) changed:
What|Removed |Added
CC||xtorn...@gmail.com
--- Co
From: Thomas Hellstrom
The FAULT_FLAG_ALLOW_RETRY semantics is tricky and appears poorly
documented. Add a comment to the TTM fault() implementation to avoid
future confusion.
Cc: Christian Koenig
Signed-off-by: Thomas Hellstrom
---
v2: Incorrect email to Christian :)
---
drivers/gpu/drm/ttm/
201 - 250 of 250 matches
Mail list logo
