On Mon, Feb 03, 2020 at 04:52:56PM +0100, Thomas Zimmermann wrote:
> The implementation of struct drm_mode_config_funcs.mode_valid verifies
> that enough video memory is available for a given display mode. This
> replaces similar functionality in bochs_connector_mode_valid().
>
> v2:
> *
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200203]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.5]
[if your patch
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200203]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.5]
[if your patch
On Mon, Feb 3, 2020 at 4:21 PM John Stultz wrote:
>
> On Wed, Jan 22, 2020 at 11:19 PM Sharat Masetty
> wrote:
> >
> > This patch adds support for enabling Graphics Bus Interface(GBIF)
> > used in multiple A6xx series chipets. Also makes changes to the
> > PDC/RSC sequencing specifically
Andrzej / Neil,
On Mon, Feb 3, 2020 at 3:37 PM Bjorn Andersson
wrote:
>
> On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
>
> > The current bridge driver always forced us to use 24 bits per pixel
> > over the DP link. This is a waste if you are hooked up to a panel
> > that only supports
On Wed, Jan 22, 2020 at 11:19 PM Sharat Masetty wrote:
>
> This patch adds support for enabling Graphics Bus Interface(GBIF)
> used in multiple A6xx series chipets. Also makes changes to the
> PDC/RSC sequencing specifically required for A618. This is needed
> for proper interfacing with RPMH.
>
Hi Linus,
Thomas Hellstrom has some more changes to the TTM layer that needed a
patch to the mm subsystem, this adds a new mm API
vmf_insert_mixed_prot to avoid an ugly hack that has limitations in
the TTM layer.
Should be all correctly acked.
Regards,
Dave.
drm-next-2020-02-04:
drm ttm/mm
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header
Added state readout for DP HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
Before applying it, routines of program SDP always calculated configs when
they
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to pack DP HDR Metadata
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_dp_helper.c | 174
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().
While computing, we'll also fill out the inforames.enable bitmask
appropriately.
v2: Wrap a long line.
Signed-off-by: Gwan-gyeong Mun
---
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
1 file changed, 13
In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.
And it stores computed dp vsc sdp to
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed
It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.
enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
On Sat, 2020-02-01 at 14:43 +0200, Jani Nikula wrote:
> On Fri, 31 Jan 2020, Gwan-gyeong Mun
> wrote:
> > When receiving video it is very useful to be able to log DP VSC
> > SDP.
> > This greatly simplifies debugging.
>
> Seems like a lot of the functions should really be in drm core.
>
> BR,
>
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> The drm_pci_alloc routines have been a thin wrapper around the core dma
> coherent routines. Remove the crutch of a wrapper and the exported
> symbols, marking it for only internal legacy use.
>
> Signed-off-by: Chris Wilson
Reviewed-by:
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> drm_pci_alloc is a thin wrapper over dma_coherent_alloc. Ditch the
> wrapper and just use the dma routines directly.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/r128/ati_pcigart.c | 32 +++---
>
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> Internally for "consistent" maps, we create a temporary struct
> drm_dma_handle in order to user our own dma_alloc_coherent wrapper then
> destroy the temporary wrap. Simplify our logic by removing the temporary
> wrapper!
>
> Signed-off-by:
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
> facilities, and we have no special reason within the drm layer to behave
> differently. In particular, since
>
> commit de09d31dd38a50fdce106c15abd68432eebbd014
>
https://bugzilla.kernel.org/show_bug.cgi?id=206393
--- Comment #5 from Bjoern Franke (b...@nord-west.org) ---
Bisected to
1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 is the first bad commit
commit 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4
Author: Noah Abradjian
Date: Fri Sep 27 16:30:57 2019 -0400
Fixes the following building error:
CC [M] drivers/gpu/drm/drm_edid.o
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function
'cea_mode_alternate_timings':
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to
'__compiletime_assert_3282'
declared with attribute
Hi Jerry,
First of all, thanks for your patch. You can see some comments inline,
just simple things.
On 01/31, Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
>
> v2:
> * don't wrap existing functions; change signature instead
>
> Signed-off-by: Thomas
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
> ---
>
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>
> v4:
> * 80-character line fixes
>
> Signed-off-by: Thomas
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:09 AM
> To: Ville Syrjala
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 8/8] drm/edid: Dump bogus 18 byte descriptors
>
> On
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, January 28, 2020 5:19 PM
> To: Alex Deucher
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 7/8] drm/edid: Constify lots of things
>
> On Mon,
Use the equivalent call to allocate a zeroed array.
Done with a trivial coccinelle script:
$ cat kvmalloc_array.cocci
@@
expression a;
expression b;
expression c;
@@
- kvmalloc_array(a, b, c | __GFP_ZERO)
+ kvcalloc(a, b, c)
Signed-off-by: Joe Perches
---
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, January 25, 2020 1:32 AM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Andres Rodriguez
> Subject: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, January 28, 2020 5:14 PM
> To: Alex Deucher
> Cc: Intel Graphics Development ; Andres
> Rodriguez
> ; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [PATCH 5/8] drm/edid:
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 3:58 AM
> To: Ville Syrjala
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915: Clear out spurious whitespace
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=206387
--- Comment #4 from Alexandre Pereira (alexpere...@disroot.org) ---
Hi,
submitted two attachments, they have the xorg and dmesg log of bootup until
login manager ( in this case sddm ) appears.
bootup 1 is the first reboot, and bootup 2 is a
https://bugzilla.kernel.org/show_bug.cgi?id=206387
--- Comment #3 from Alexandre Pereira (alexpere...@disroot.org) ---
Created attachment 287101
--> https://bugzilla.kernel.org/attachment.cgi?id=287101=edit
xorg and dmesg log - boot 2
--
You are receiving this mail because:
You are watching
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:06 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re:
https://bugzilla.kernel.org/show_bug.cgi?id=206387
--- Comment #2 from Alexandre Pereira (alexpere...@disroot.org) ---
Created attachment 287099
--> https://bugzilla.kernel.org/attachment.cgi?id=287099=edit
xorg and dmesg log - boot 1
--
You are receiving this mail because:
You are watching
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:06 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re:
> -Original Message-
> From: dri-devel On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:04 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [PATCH
Am 03.02.20 um 17:18 schrieb Tianlin Li:
Right now several architectures allow their set_memory_*() family of
functions to fail,
Oh, that is a detail I previously didn't recognized. Which architectures
are that?
Cause the RS400/480, RS690 and RS740 which are affected by this are
integrated
https://bugzilla.kernel.org/show_bug.cgi?id=206387
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=206383
Alois Nespor (i...@aloisnespor.info) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 27 Jan 2020 03:20:21 +0100, Marek Vasut wrote:
> Add vendor prefix for ITE Tech Inc, http://www.ite.com.tw/
>
> Signed-off-by: Marek Vasut
> Cc: Daniel Vetter
> Cc: Rob Herring
> Cc: Sean Cross
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
>
The implementation of struct drm_mode_config_funcs.mode_valid verifies
that enough video memory is available for a given display mode.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git
The implementation of struct drm_mode_config_funcs.mode_valid verifies
that enough video memory is available for a given display mode. This
replaces similar functionality in bochs_connector_mode_valid().
v2:
* remove bochs_connector_mode_valid(), which now serves no purpose
Devices with low amount of dedicated video memory may not be able
to use all possible display modes, as the framebuffers may not fit
into VRAM. The new helper function drm_vram_helper_mode_valid()
implements a simple test to sort out all display modes that can
not be used in any case. Drivers
This adds drm_vram_helper_mode_valid(), which tests a display mode against
the available video memory. It's a helper function to sort out display
modes that cannot be used because of a lack of video memory.
The ast driver already implemented this test for a while. The patchset
converts ast over
The implementation of struct drm_mode_config_funcs.mode_valid verifies
that enough video memory is available for a given display mode.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Feb 03, 2020 at 03:27:24PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
> drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
> variable 'bo' set but not used
From: Ville Syrjälä
Account for the TMDS clock limits declared by the DFP/DP++ dongle
when determining what color depth we're going to use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 67 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 50
From: Ville Syrjälä
Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 5 +
From: Ville Syrjälä
w/a #1139 is only needed for pre-production GLK. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
From: Ville Syrjälä
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
From: Ville Syrjälä
Add helpers to determine whether the DFP supports
YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +
include/drm/drm_dp_helper.h | 8 ++
2 files
From: Ville Syrjälä
The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 54
From: Ville Syrjälä
Decouple the DP dual mode adaptor stuff from the HDMI code so that
we can try to use it for DP branch downstream facing HDMI ports as
well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
.../drm/i915/display/intel_display_types.h
From: Ville Syrjälä
Use drm_dp_downstream_mode() to get a suitable mode for downstream
facing ports which don't have an EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
To save a bit of power let's try to power down the TMDS buffers on
DP++ dongles hooked to downstream facing DP++ ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.c | 25
From: Ville Syrjälä
For platforms that can't do native 4:2:0 outout we may still be
able to do it by getting the DP->HDMI protocol converter to
perform the 4:4:4->4:2:0 downsamling for us. In this case we
have to configure our hardware to output YCbCr 4:4:4, which we've
already hooked up so all
From: Ville Syrjälä
Pull the "do we want to enable audio?" computation into a small helper
to make intel_hdmi_compute_config() less messy. Will make it easier to
add more checks for this later (eg. we should actually be checking
at the hblank is long enough for audio transmission).
From: Ville Syrjälä
In order to get accurate TMDS clocks limits for the DP++ ports we
can try to probe the DP dual mode adapter registers. Unfortunately
I've not yet seen a DP->DP++ branch device that would actually
forward these i2c accesses to the dual mode dongle downstream.
But we don't lose
From: Ville Syrjälä
Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 116
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 122 insertions(+)
diff --git
From: Ville Syrjälä
Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
From: Ville Syrjälä
Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().
TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Add a few helpers to let us better identify which kind of DFP
we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 60 +
include/drm/drm_dp_helper.h | 5 +++
2 files changed, 65 insertions(+)
diff
From: Ville Syrjälä
It helps when the logs have a dump of the DFP capabilities.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
From: Ville Syrjälä
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 42 ++---
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
Attempt to deal with DP downstream facing ports (DFP) more
thoroughly. This involves reading more of the port caps
and dealing with various clock/bpc limitations.
Also we try to hook up the DP dual mode dongles into the
mix (unfortunately I've not yet seen a DP++ DFP that
From: Ville Syrjälä
WaDDIIOTimeout is only for A1 (pre-prod) glk steppings. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
From: Ville Syrjälä
TGL+ supposedly do not need Wa_1405510057 so limit it to
gen11 only.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
Am 03.02.20 um 10:06 schrieb Dan Carpenter:
On Sun, Feb 02, 2020 at 02:19:18PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2020 at 11:28 PM syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD commit:39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
git tree:
From: Ville Syrjälä
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod
since the spec is a bit of a mess but feels more or less correct.
Suggested-by: Chris Wilson
Acked-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
On Mon, Feb 03, 2020 at 02:04:21PM +0200, Gwan-gyeong Mun wrote:
> When a DP downstream uses a DP to HDMI active converter, the active
> converter needs to support YCbCr420 Pass-through to enable DP YCbCr 4:2:0
> outputs.
>
> Signed-off-by: Gwan-gyeong Mun
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=206393
--- Comment #4 from Bjoern Franke (b...@nord-west.org) ---
It's a regression, it did not appear with 5.4.15. The error message "[
1.549880] [drm:dm_helpers_parse_edid_caps [amdgpu]] *ERROR* Couldn't read SADs:
-2" at the beginning also does
https://bugzilla.kernel.org/show_bug.cgi?id=206393
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=206383
--- Comment #4 from Alois Nespor (i...@aloisnespor.info) ---
yes, i will compile and test mesa-master git version. thanks
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=206383
Pierre-Eric Pelloux-Prayer (pierre-eric.pelloux-pra...@amd.com) changed:
What|Removed |Added
CC|
On Mon, Feb 03, 2020 at 12:00:49AM +0300, Dmitry Osipenko wrote:
> 30.01.2020 15:08, Thierry Reding пишет:
> ...
> >> Why not to set the DMA mask to 32bits if IOMMU is unavailable?
> >
> > We already do that. If you look at host1x_iommu_init() in
> > drivers/gpu/host1x/dev.c, you'll see that when
When a DP downstream uses a DP to HDMI active converter, the active
converter needs to support YCbCr420 Pass-through to enable DP YCbCr 4:2:0
outputs.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 26 +
1 file changed, 26 insertions(+)
When DP downstream has HDMI branch, it checks below functionality and
shows supports. It follows DP 1.4a spec; Table 2-161: Address Mapping
within DPCD Receiver Capability Field (DPCD Addresses 0h
through 000FFh).
Added flags for DP downstream:
YCBCR422_PASS_THROUGH_SUPPORT,
Hey,
Just a couple of fixes to Volta/Turing modesetting on some systems.
Thanks,
Ben.
The following changes since commit c3463aed05abf06bd5ebaac12f2c015db298b98f:
drm/nouveau/fb/gp102-: allow module to load even when scrubber
binary is missing (2020-01-29 15:49:56 +1000)
are available in
When a DP downstream uses a DP to HDMI active converter, the active
converter needs to support YCbCr420 Pass-through to enable DP YCbCr 4:2:0
outputs.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 26 +
1 file changed, 26 insertions(+)
On Mon, Feb 03, 2020 at 09:35:54AM +0100, Thomas Zimmermann wrote:
> Hi Gerd
>
> Am 03.02.20 um 07:47 schrieb Gerd Hoffmann:
> > On Sat, Feb 01, 2020 at 01:27:42PM +0100, Thomas Zimmermann wrote:
> >> The implementation of struct drm_mode_config_funcs.mode_valid verifies
> >> that enough video
Hi
Am 03.02.20 um 10:53 schrieb Daniel Vetter:
> On Mon, Feb 03, 2020 at 10:49:30AM +0100, Daniel Vetter wrote:
>> On Sat, Feb 01, 2020 at 01:27:41PM +0100, Thomas Zimmermann wrote:
>>> Devices with low amount of dedicated video memory may not be able
>>> to use all possible display modes, as the
On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote:
> Hi,
>
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
>
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to
On Sat, Feb 01, 2020 at 01:27:44PM +0100, Thomas Zimmermann wrote:
> The implementation of struct drm_mode_config_funcs.mode_valid verifies
> that enough video memory is available for a given display mode.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
> ---
>
1 - 100 of 127 matches
Mail list logo
