Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_vma.c
between commit:
52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
from the drm tree and commit:
cd2a4eaf8c79 ("drm/i915: Report resv_obj allocation failure")
from
Applied. thanks!
Alex
On Fri, Jul 26, 2019 at 11:58 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function
> restore_process_worker:
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:949:29: warning:
>
Applied. thanks!
Alex
On Fri, Jul 26, 2019 at 5:42 AM YueHaibing wrote:
>
> Remove duplicated include.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git
Applied. thanks!
Alex
On Tue, Jul 9, 2019 at 11:03 PM YueHaibing wrote:
>
> Remove duplicated include.
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>
Applied. thanks!
Alex
On Thu, Jun 27, 2019 at 10:29 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_common_early_init':
> drivers/gpu/drm/amd/amdgpu/nv.c:471:7: warning:
> variable 'psp_enabled' set but not used
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.
QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.
Signed-off-by: Wen He
---
Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
Applied. thanks!
Alex
On Wed, Aug 21, 2019 at 12:40 PM Harry Wentland wrote:
>
> On 2019-08-20 7:57 p.m., Nathan Chancellor wrote:
> > When building arm32 allyesconfig:
> >
> > ld.lld: error: undefined symbol: __aeabi_uldivmod
> referenced by dc_link.c
>
Hi Dave, Daniel,
A few fixes for 5.3. Nothing major.
The following changes since commit 2f62c5d6ed0abae8e70bd83f4d41b9d63acde45a:
Merge tag 'drm-fixes-5.3-2019-08-14' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-08-15 13:29:18
+1000)
are available in the Git
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 45bfac9e3af7..c5653771e8fa 100644
---
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:45PM +0200, Boris Brezillon wrote:
> This takes the form of various helpers, plus the addition of 2 new
> structs:
> * drm_bus_caps: describe the bus capabilities of a bridge/encoder. For
> bridges we have one for the input port
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:49PM +0200, Boris Brezillon wrote:
> Add a new entry for the Toshiba LTA089AC29000 panel.
>
> Signed-off-by: Boris Brezillon
> ---
> .../display/panel/toshiba,lt089ac29000.txt| 5 ++-
> drivers/gpu/drm/panel/panel-simple.c
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:48PM +0200, Boris Brezillon wrote:
> The SN75LVDS83 bridge support several input formats except the input
> format is directly related to the expected output format. Let's express
> that constraint by setting the
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:44PM +0200, Boris Brezillon wrote:
> Will be useful for bridge drivers that want to do bus format
> negotiation with their neighbours.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_bridge.c | 19
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:43PM +0200, Boris Brezillon wrote:
> So that bridge drivers have a way to check/reject an atomic operation.
> The drm_atomic_bridge_chain_check() (which is just a wrapper around
> the ->atomic_check() hook) is called in place of
>
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:42PM +0200, Boris Brezillon wrote:
> Instead of a drm_atomic_state. The only driver implementing those hooks
> is patched too.
>
> Signed-off-by: Boris Brezillon
> ---
> .../drm/bridge/analogix/analogix_dp_core.c| 12 ++--
>
The documentation for most of the bridge atomic operations incorrectly
reference the non-atomic version when stating the operations are
optional. Fix them, and make sure that all references to bridge
operations are correctly marked with @.
Signed-off-by: Laurent Pinchart
---
Hi all,
On Wed, 14 Aug 2019 12:54:33 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> drivers/gpu/drm/i915/i915_vma.c
> drivers/gpu/drm/i915/i915_gem_batch_pool.c
>
Quoting Daniel Vetter (2019-08-21 22:50:28)
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I haven't
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #41 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sergey Kondakov from comment #40)
>
> I little bit strange to call 2x1080p on AMD's fancy 5-port GPU (+ possible
> DP multiplexing) "my issue".
It's a limitation of
We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.
Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #40 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Alex Deucher from comment #39)
> (In reply to Sergey Kondakov from comment #38)
> Here is your issue: "simple 2x1080p"
>
> multiple display are really hard to deal
https://bugzilla.kernel.org/show_bug.cgi?id=204575
--- Comment #2 from Alessandro Surace (zioa...@gmail.com) ---
Thanks Jani.
It can be related with https://bugs.freedesktop.org/show_bug.cgi?id=107738 .
Checking it.
--
You are receiving this mail because:
You are watching the assignee of the
What branch does this patch series actually apply to? I've been trying to
apply this locally, but it doesn't appear to apply against drm-tip/drm-tip,
amdgpu-next/drm-next, or origin (e.g. kernel.org) /master. Is there any chance
we could have this go against drm-tip instead (and even better, split
On Wed, 2019-08-21 at 16:01 -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.
>
> Cc: Leo Li
> Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=204345
Joaquin Otsoa (edisonalvari...@bol.com.br) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #2 from Tom Seewald ---
Could you try applying the following patch set from AMD's Nicholas Kazlauskas:
https://patchwork.freedesktop.org/series/64505/
There have been similar reports filed on the kernel bugzilla:
On Wed, 2019-08-21 at 20:02 +, Francis, David wrote:
> I know this looks like it could be a DRM helper, but
> - That would require a DRM-generic way of knowing if a
>connector supports DSC, and current precedent is that
>DSC functionality is stored on a driver-specific basis
Don't
Oops.
Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
Cc: Tomeu Vizoso
Cc: Emil Velikov
Cc: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #38 from tempel.jul...@gmail.com ---
Huh, that seems suspicious. I'm not aware of any such a tool which would be
active for me all the time. I had redshift installed, but it wasn't running in
background, so not surprisingly
On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson wrote:
>
> Quoting Christian König (2019-08-21 13:31:37)
> > Hi everyone,
> >
> > In previous discussion it surfaced that different drivers use the shared
> > and explicit fences in the dma_resv object with different meanings.
> >
> > This is
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:41PM +0200, Boris Brezillon wrote:
> One of the last remaining object to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
>
Make dma_fence_enable_sw_signaling() behave like its
dma_fence_add_callback() and dma_fence_default_wait() counterparts and
perform the test to enable signaling under the fence->lock, along with
the action to do so. This ensure that should an implementation be trying
to flush the cb_list (by
Quoting Christian König (2019-08-21 13:31:37)
> Hi everyone,
>
> In previous discussion it surfaced that different drivers use the shared and
> explicit fences in the dma_resv object with different meanings.
>
> This is problematic when we share buffers between those drivers and
> requirements
On Wed, Aug 21, 2019 at 06:13:27PM +0200, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 02:31:37PM +0200, Christian König wrote:
> > Hi everyone,
> >
> > In previous discussion it surfaced that different drivers use the shared
> > and explicit fences in the dma_resv object with different
Reviewed-by: Lyude Paul
Thanks!
On Wed, 2019-08-21 at 16:01 -0400, David Francis wrote:
> With DSC, bpp can be a multiple of 1/16, so
> drm_dp_calc_pbn_mode is insufficient.
>
> Add drm_dp_calc_pbn_mode_dsc, a function which is
> the same as drm_dp_calc_pbn_mode, but the bpp is
> in units of
I know this looks like it could be a DRM helper, but
- That would require a DRM-generic way of knowing if a
connector supports DSC, and current precedent is that
DSC functionality is stored on a driver-specific basis
- This function, by necessity, locks global state. Other
hardware may
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.
In both cases, the port given as input should be a leaf of
the MST
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of bandwidths possible
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the drm_dp_mst_dsc_enable helper.
Cc: Wenjing Liu
Cc: Nikola Cornij
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 16 +++-
1 file changed, 15 insertions(+), 1
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_caps_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Cc: Wenjing Liu
Cc: Nikola Cornij
Signed-off-by: David Francis
---
Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not
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: remember to decrement on port removal
Signed-off-by: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
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.
Cc: Leo Li
Cc: Lyude Paul
Signed-off-by: David Francis
---
We were using drm helpers to convert a timing into its
bandwidth, its bandwidth into pbn, and its pbn into timeslots
These helpers
-Did not take DSC timings into account
-Used the link rate and lane count of the link's aux device,
which are not the same as the link's current cap
-Did not take FEC
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
This patchset enables Display Stream Compression (DSC) on DP
connectors on Navi ASICs, both SST and DSC.
8k60 and 4k144 support requires ODM combine, an AMD internal
feature that may be a bit buggy right now.
Patches 1 through 5 enable DSC for SST. Most of the work was
already done in the Navi
With DSC, bpp can be a multiple of 1/16, so
drm_dp_calc_pbn_mode is insufficient.
Add drm_dp_calc_pbn_mode_dsc, a function which is
the same as drm_dp_calc_pbn_mode, but the bpp is
in units of 1/16.
Cc: Lyude Paul
Cc: Nicholas Kazlauskas
Signed-off-by: David Francis
---
This reverts commit 80e80ec817f161560b4159608fb41bd289abede3.
This commit fixed an issue with underscan commits not updating all
needed timing values, but through various refactors it is no longer
necessary. It causes corruption on odm combine by
overwriting the halved h_active in the stream
This reverts commit 55a6f5bbcf00a49565946c0a9b8c716313dc6c05.
This commit was accidentally promoted twice
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
Reviewed-by: Nicholas Kazlauskas
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 4 --
This reverts commit 5f2fd347eeff7d4ce271920efd47baaa18fe968c.
Re-enable enc2_dp_set_dsc_config. This function caused warnings
due to missing register definitions. With the registers added,
this now works
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
In create_stream_for_sink, check for SST DP connectors
Parse DSC caps to DC format, then, if DSC is supported,
compute the config
DSC hardware will be programmed by dc_commit_state
Tested-by: Mikita Lipski
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
This reverts commit 55ad81f3510ec1a1c19e6a4d8a6319812d07d256.
optc dsc config was causing warnings due to missing register
definitions. With the registers restored, the function can
be re-enabled
The reverted commit also disabled sanity checks and dsc
power gating. The sanity check warnings are
Liu, Wenjing would like to recall the message, "[PATCH v2 11/14]
drm/amd/display: Validate DSC caps on MST endpoints".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=111332
--- Comment #2 from Todd ---
I can't comment on where the fix should be, but
1. This does not happen on a radeon based system
2. With the patch applied to the amdgpu code the application has been running
for over 7 days now with no issues.
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #37 from Nicholas Kazlauskas ---
Are you running a color management tool in the background?
The difference between my setup and yours is that there isn't anything locking
the connectors hundreds of times per second and performing
On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
> On 8/21/19 8:11 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> > wrote:
> > > On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > > > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas
On Wed, Aug 21, 2019 at 02:26:02PM -0500, Rob Herring wrote:
> On Mon, Aug 05, 2019 at 08:22:24PM -0400, Brian Masney wrote:
> > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > optional ocmem
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #39 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sergey Kondakov from comment #38)
>
> Thanks ! It's a shame, I've already begun believing in "The Silver Bullet of
> VSync". And it's completely "software" GPU-agnostic
On Mon, Aug 05, 2019 at 08:22:24PM -0400, Brian Masney wrote:
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #36 from tempel.jul...@gmail.com ---
The log now starts at [ 2788.164016], I hope nothing important is cut out. Else
I'd have to recheck my log size limits.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111459
Bug ID: 111459
Summary: AMDg black screen
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: not set
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #35 from tempel.jul...@gmail.com ---
Created attachment 145119
--> https://bugs.freedesktop.org/attachment.cgi?id=145119=edit
debug dmesg.log
--
You are receiving this mail because:
You are the assignee for the
On Wed, Aug 21, 2019 at 11:04 AM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Aug 20, 2019 at 11:06:01PM +, John Stultz wrote:
> > Sending this out again (apologies!), to address a few issues Sam
> > found.
> >
> > This patchset contains one fix (in the front, so its easier to
> > eventually
On Fri, Aug 9, 2019 at 8:43 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> The Vulkan timeline semaphores allow signaling to happen on the point
> of the timeline without all of the its dependencies to be created.
>
> The current 2 implementations (AMD/Intel) of the Vulkan spec on
On Wed, 2019-08-21 at 12:27 +, Kazlauskas, Nicholas wrote:
> On 8/20/19 4:43 PM, Lyude Paul wrote:
> > Some nitpicks below
> >
> > On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote:
> > > We were using drm helpers to convert a timing into its
> > > bandwidth, its bandwidth into pbn, and
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #34 from tempel.jul...@gmail.com ---
Thank you for being still with me on this.
I've downgraded to stock packages provided by Arch stable repository, which is:
xorg-server 1.20.5
xf86-video-amdgpu 19.0.1
mesa 19.1.4
stock (read:
The drm_get_edid() function skips EDID read when the connector is
disabled through connector->force. drm_do_get_edid(), which is supposed
to be used instead of drm_get_edid() for drivers that need to provide a
custom DDC read method, is missing the connector force checks. This
breaks the connector
This patch is a proof of concept showing how EDID retrieval could be
decoupled from drm_connector, in order to avoid passing the connector
pointer to the drm_bridge .get_edid() operation. The user of such
bridges (in most case the future drm_bridge_connector helper, see
"[PATCH v2 00/50] drm/omap:
The static function that populates the drm_connector tile-related fields
from EDID displayid will be used outside of drm_edid.c. As it logically
belongs to connector code, move it to drm_connector.c and rename it from
drm_get_displayid() to drm_connector_set_displayid().
While at it, fix a few
Move the EDID retrieval functions to the end of the file to avoid
forward declarations. While at it fix a typo in a comment
(s/firmare/firmware/). No functional change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_edid.c | 637 ++---
1 file
Hello,
This small patch series attemps at decoupling EDID retrieval from
drm_connector, following a discussion with Daniel Vetter [1]. While
working on this I noticed a few issues with EDID retrieval, which I have
attempted to fix in patches 1/5 to 4/5. Patch 5/5 then tries to decouple
the EDID
This change started as an attempt to remove the forward declaration of
validate_displayid(), and ended up reorganising the DisplayID parsing
code to fix serial intertwined issues.
The drm_parse_display_id() function, which parses a DisplayID block, is
made aware of whether the DisplayID comes
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #33 from Nicholas Kazlauskas ---
I haven't seen anything like the video in my testing. It also doesn't seem to
happen every time so I'm wondering if something else is going on in the
background that's issuing atomic commits.
Do you
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #32 from tempel.jul...@gmail.com ---
Created attachment 145118
--> https://bugs.freedesktop.org/attachment.cgi?id=145118=edit
issue demonstrated with D9VK frametime graph in game Oblivion
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #31 from tempel.jul...@gmail.com ---
Created attachment 145117
--> https://bugs.freedesktop.org/attachment.cgi?id=145117=edit
new dmesg log with staging-drm-next kernel default parameters
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #38 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Alex Deucher from comment #37)
> (In reply to Sergey Kondakov from comment #34)
> > By the way, is there any disadvantage in forcing TearFree to be always on
> > when
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
(which uses the DT port 1) and DPI outputs other than DPI0 (which are
not used in mainline
On Tue, 20 Aug 2019 10:41:00 +0200
Neil Armstrong wrote:
> Before switching to bridge funcs, make sure drm_display_mode is passed
> as const to the venc functions.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/meson/meson_venc.c | 2 +-
>
On Wed, 14 Aug 2019 09:51:07 +0200
Neil Armstrong wrote:
> On 08/08/2019 17:11, Boris Brezillon wrote:
> > This takes the form of various helpers, plus the addition of 2 new
> > structs:
> > * drm_bus_caps: describe the bus capabilities of a bridge/encoder. For
> > bridges we have one for the
Am 21.08.2019 20:28 schrieb "Thomas Hellström (VMware)"
:
On 8/21/19 8:11 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> wrote:
>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
On Tue, 20 Aug 2019 10:40:58 +0200
Neil Armstrong wrote:
> This patchset is based on Boris's "drm: Add support for bus-format
> negotiation" RFC at [1]
Small clarification. Neil's work in based on a slightly different
version of my RFC [4] (I plan to post a v2 very soon).
> patchset to
Hi Guido,
Thank you for the patch.
On Fri, Aug 09, 2019 at 06:24:22PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++
> 1 file
On 8/20/19 3:12 PM, David Francis wrote:
> The first step in MST DSC is checking MST endpoints
> to see how DSC can be enabled
>
> Case 1: DP-to-DP peer device
> if the branch immediately upstream has
> - PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2)
> - DPCD rev. >= DP 1.4
> - Exactly one
On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
wrote:
>
> On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> >> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon,
Hi John.
On Tue, Aug 20, 2019 at 11:06:01PM +, John Stultz wrote:
> Sending this out again (apologies!), to address a few issues Sam
> found.
>
> This patchset contains one fix (in the front, so its easier to
> eventually backport), and a series of changes from YiPing to
> refactor the kirin
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #30 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #29)
> The patches by Nicholas are now merged in drm-next-5.4 branch (tested with
> recent commit that bases the branch on 5.3-rc3), but the mouse input issue
On Wed, Aug 21, 2019 at 12:24 PM Heiko Stuebner wrote:
>
> Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> > This series converts the various Arm Mali GPU bindings to use the DT
> > schema format.
> >
> > The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
>
Hi,
On Tue, Aug 13, 2019 at 01:07:52PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote:
> > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote:
> > > On Fri, Aug 9, 2019 at 6:24 PM Guido Günther wrote:
> > > >
> > > > This adds all the gpr registers
On Mon, Aug 19, 2019 at 3:27 PM John Stultz wrote:
> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn
> wrote:
> >
> > In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
> > which attach to the DSI host via mipi_dsi_attach() at probe time, the
> > ADV7533 bridge device does not.
Quoting Chris Wilson (2019-08-21 16:24:22)
> Quoting Christian König (2019-08-21 13:31:45)
> > @@ -117,17 +120,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
> > *data,
> >
> > busy_check_writer(rcu_dereference(obj->base.resv->fence_excl));
> >
> > /* Translate
Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> This series converts the various Arm Mali GPU bindings to use the DT
> schema format.
>
> The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
> because there's all different ordering. The Utgard binding
Hi Laurent,
Thank you for getting back to me.
> From: Laurent Pinchart
> Sent: 20 August 2019 17:04
> Subject: Re: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support
>
> Hi Fabrizio,
>
> On Thu, Aug 15, 2019 at 03:36:53PM +, Fabrizio Castro wrote:
> > On 15 August 2019 14:09
On 2019-08-20 7:57 p.m., Nathan Chancellor wrote:
> When building arm32 allyesconfig:
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
referenced by dc_link.c
gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive
drivers/built-in.a
referenced by dc_link.c
On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >
On Wed, Aug 21, 2019 at 11:03:55AM -0500, Rob Herring wrote:
> On Wed, Aug 21, 2019 at 3:23 AM Daniel Vetter wrote:
> >
> > On Tue, Aug 20, 2019 at 07:35:47AM -0500, Rob Herring wrote:
> > > On Tue, Aug 20, 2019 at 4:05 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Aug 19, 2019 at 11:12:02AM
On Wed, Aug 21, 2019 at 05:15:54PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i916_display_info. A hint is printed if the port is type-C.
Typo here, should be i915_display_info
Manasi
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> ---
>
1 - 100 of 201 matches
Mail list logo
