> + /*
> + * dma_sync_sg_*() flush the physical pages, so point
> + * sg->dma_address to the physical ones for the right behavior.
> + */
> + for_each_sg(msm_obj->sgt->sgl, s, msm_obj->sgt->nents, i)
> + sg_dma_addre
On 11/28/2018 10:56 AM, Stéphane Marchesin wrote:
Hi,
Just a drive-by comment, but did you check that this fails gracefully
on platforms which don't enable the ME? For example Chrome OS :)
That is taken care :) HDCP2.2 is attempted only if platform enables the
ME and its required kernel drive
https://bugs.freedesktop.org/show_bug.cgi?id=108825
--- Comment #5 from Samantha McVey ---
I have bisected it to commit: drm/amd/display: Support amdgpu "max bpc"
connector property
307638884f721b02b6a54ee8b351c5b4434bd4a6 Author: Nicholas Kazlauskas
--
You are receiving this mail because:
You
Op 27-11-18 om 18:34 schreef Daniel Vetter:
> KMS drivers really should all be able to restore their display state
> on resume without fbcon helping out. So make this the default.
>
> Since I'm not entirely foolish, make it only a default, which drivers
> can still override. That way when the inevi
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Get the ref clock of the PHY from the device tree instead of
> hardcoding its name and rate.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - patch added to the series
> ---
> drivers/gpu/drm/msm/dsi/pll/dsi_pll_28n
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Add 'xo_board' as ref clock for the DSI PHYs, it was previously
> hardcoded in the PLL 'driver' for the 28nm PHY.
Note: presumably your series should have one more patch to fix
"arch/arm/boot/dts/qcom-apq8064.dtsi" too?
> Signed-
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Get the ref clock of the PHY from the device tree instead of
> hardcoding its name and rate.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - remove anonymous array in clk_init_data assignment
> - log error code if d
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously
> hardcoded in the PLL 'driver' for the 10nm PHY.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> based on "[v4,1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file"
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
> @@ -409,8 +410,9 @@ static void dsi_pll_28nm_destroy(struct msm_dsi_pll *pll)
> static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
> {
> char *clk_name, *parent_name, *vco_name;
> + const char *ref_clk_name =
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Get the ref clock of the PHY from the device tree instead of
> hardcoding its name and rate.
In the case of the 14nm PHY I think it's OK that you break
compatibility with old device tree files (as this patch does) since
the 14nm su
Hi,
On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
>
> Allow the PHY drivers to get the ref clock from the DT.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - add the ref clock for all PHYs, not only the 10nm one
> - updated commit message
> ---
> Documentation/devicet
Hi,
Just a drive-by comment, but did you check that this fails gracefully
on platforms which don't enable the ME? For example Chrome OS :)
Stéphane
On Tue, Nov 27, 2018 at 2:48 AM Ramalingam C wrote:
>
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DP
On 11/27/2018 11:07 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:54:15PM +, Bloomfield, Jon wrote:
I'm not formally reviewing this series, but while glancing at it, I noticed
-Original Message-
From: Intel-gfx On Behalf Of
Ramalingam C
Sent: Tuesday, November 27, 2018
Hi Vivek,
On Tue, Nov 27, 2018 at 6:37 AM Vivek Gautam
wrote:
>
> dma_map_sg() expects a DMA domain. However, the drm devices
> have been traditionally using unmanaged iommu domain which
> is non-dma type. Using dma mapping APIs with that domain is bad.
>
> Replace dma_map_sg() calls with dma_syn
On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote:
> +linux-acpi
>
> Hi Michael,
>
> On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote:
> > So a new thinkpad:
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro
> > P2000 Mobile] (rev a1)
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108878
Alex Deucher changed:
What|Removed |Added
QA Contact||dri-devel@lists.freedesktop
On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote:
> > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote:
> > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Ly
18. 11. 27. 오후 11:36에 Andrzej Hajda 이(가) 쓴 글:
> On 12.10.2018 12:53, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Changes:
>> v2: resend of v1 rebased on next with EXYNOS DRM IOMMU changes posted by
>> Marek.
>>
>> This patchset refactors IOMMU/DMA code in ExynosDRM driver.
>> It performs several chan
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.20-rc4 next-20181127]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
https://bugs.freedesktop.org/show_bug.cgi?id=108882
Bug ID: 108882
Summary: Many different installation problems with
amdgpu-pro-18.40-676022-rhel-6 driver in CentOS 6.10
Product: DRI
Version: unspecified
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=108883
Bug ID: 108883
Summary: Vulkan support broken in
amdgpu-pro-18.40-676022-rhel-6 driver in CentOS 6.10
Product: DRI
Version: unspecified
Hardware: Other
OS:
Specify geometry for DPU iommu domain which sets
the address space for gem allocations.
Signed-off-by: Jeykumar Sankaran
Suggested-by: Jordan Crouse
Suggested-by: Vivek Gautam
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm
From: Sean Paul
drm_atomic_state_put doesn't require any locking, and this makes things
easier for switching to modeset_lock_all helpers in a future patch
Cc: Daniel Vetter
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Sean Paul
Instead of always re-initializing the variables we need to clean up on
out, move the re-initialization into the branch that goes back to retry
label.
This is a lateral move right now, but will allow us to pull out the
modeset locking into common code. I kept this change separate
From: Sean Paul
This patch adds a couple of helpers to remove the boilerplate involved
in grabbing all of the modeset locks.
I've also converted the obvious cases in drm core to use the helpers.
The only remaining instance of drm_modeset_lock_all_ctx() is in
drm_framebuffer. It's complicated by
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jo
For the series:
Acked-by: Ben Skeggs
On Sat, 17 Nov 2018 at 10:21, Lyude Paul wrote:
>
> So we don't ever have to worry about drivers touching drm_dp_mst_port
> structs without verifying them and crashing again.
>
> Lyude Paul (6):
> drm/dp_mst: Add drm_dp_get_payload_info()
> drm/nouveau: U
On Tue, 2018-11-27 at 15:38 +0200, Ville Syrjälä wrote:
> On Mon, Nov 26, 2018 at 04:37:02PM -0800, José Roberto de Souza
> wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9
On Tue, 2018-11-27 at 22:23 +0100, Daniel Vetter wrote:
> On Fri, Nov 16, 2018 at 07:21:15PM -0500, Lyude Paul wrote:
> > Some hardware (nvidia hardware in particular) needs to be notified of
> > the exact VCPI and payload settings that the topology manager decided on
> > for each mstb port. Since
On Fri, Nov 16, 2018 at 07:21:15PM -0500, Lyude Paul wrote:
> Some hardware (nvidia hardware in particular) needs to be notified of
> the exact VCPI and payload settings that the topology manager decided on
> for each mstb port. Since there isn't currently any way to get this
> information without
Swati Sharma kirjoitti 22.10.2018 klo 8.31:
From: Vidya Srinivas
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
v3: since support for planar formats on ICL was
On 2018-11-27 11:18 a.m., David Francis wrote:
> The fallback code for getting default backlight caps was using
> the wrong variable name. Fix it.
>
> Fixes:
> https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.html
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
I did earlier give R-b for this patch. The patch anyway hasn't changed
as those defines have not changed.
/Juha-Pekka
Swati Sharma kirjoitti 22.10.2018 klo 8.31:
From: Vidya Srinivas
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
v3: no change
Signed-off-by: S
From: Noralf Trønnes
This adds a library for shmem backed GEM objects.
v6:
- Fix uninitialized variable issue in an error path (anholt).
- Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
of the pages (anholt).
v5:
- Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
- drm_gem
Daniel Vetter writes:
> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>> Noralf Trønnes writes:
>> > +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>> > +{
>> > + struct drm_gem_object *obj = vma->vm_private_data;
>> > + struct drm_gem_shmem_object *shmem = to_d
This cuts out a tremendous amount of boilerplate. I've used the PRIME
support now to test V3D rendering on a STB development board with no
KMS driver.
v2: Use the DEFINE_DRM_GEM_SHMEM_FOPS for proper mmap setup.
Signed-off-by: Eric Anholt
Acked-by: Daniel Vetter (v1)
---
drivers/gpu/drm/Kconf
Ah I see. Thank you for the clarification.
Regards,
Kenny
On Tue, Nov 27, 2018 at 3:31 PM Christian König
wrote:
>
> Am 27.11.18 um 19:15 schrieb Kenny Ho:
> > Hey Christian,
> >
> > Sorry for the late reply, I missed this for some reason.
> >
> > On Wed, Nov 21, 2018 at 5:00 AM Christian König
Am 27.11.18 um 19:15 schrieb Kenny Ho:
Hey Christian,
Sorry for the late reply, I missed this for some reason.
On Wed, Nov 21, 2018 at 5:00 AM Christian König
wrote:
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 370e9a5536ef..531726443104 100644
--- a/includ
From: Ville Syrjälä
On i965gm the hardware frame counter does not work when
the TV encoder is active. So let's not try to consult
the hardware frame counter in that case. Instead we'll
fall back to the timestamp based guesstimation method
used on gen2.
Note that the pipe timings generated by the
Acked-by: Alex Deucher
From: amd-gfx on behalf of David
Francis
Sent: Tuesday, November 27, 2018 11:18:14 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Francis, David
Subject: [PATCH] drm/amd/display: Fix compile error with ACPI disa
On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote:
> On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote:
> > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> > > > There has been a TODO waiting for quite
On Tue, Nov 27, 2018 at 08:20:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm we need to adjust max_vblank_count dynamically
> depending on whether the TV encoder is used or not. To
> that end add a per-crtc max_vblank_count that takes
> precedence over its device wide counte
https://bugzilla.kernel.org/show_bug.cgi?id=201795
thomas.lassdiesonner...@gmx.de changed:
What|Removed |Added
Regression|No |Yes
--
You are receivin
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #2 from thomas.lassdiesonner...@gmx.de ---
When I compare the two xrandr outputs the only difference are the missing
interlaced resolutions on Kernel 4.19. Maybe that is a hint where the problem
may be?
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #1 from thomas.lassdiesonner...@gmx.de ---
Created attachment 279679
--> https://bugzilla.kernel.org/attachment.cgi?id=279679&action=edit
xrandr output on kernel 4.19
--
You are receiving this mail because:
You are watching the ass
https://bugs.freedesktop.org/show_bug.cgi?id=93649
--- Comment #81 from Alex Deucher ---
(In reply to Amarildo from comment #80)
> Uh oh. This bug may be back.
>
> I'm back on Linux. First time playing for more than 30 mins (my little
> sister was playing) PC hangs.
>
> Will test it to see whet
https://bugzilla.kernel.org/show_bug.cgi?id=201795
Bug ID: 201795
Summary: [Regression] Wrong 4k resolution detected with
DisplayPort to HDMI adapter on amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 4.19.4
Hardwa
On Sat, 2018-11-17 at 12:24 +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.19.2, v4.18
From: Ville Syrjälä
On i965gm the hardware frame counter does not work when
the TV encoder is active. So let's not try to consult
the hardware frame counter in that case. Instead we'll
fall back to the timestamp based guesstimation method
used on gen2.
Note that the pipe timings generated by the
From: Ville Syrjälä
On i965gm we need to adjust max_vblank_count dynamically
depending on whether the TV encoder is used or not. To
that end add a per-crtc max_vblank_count that takes
precedence over its device wide counterpart. The driver
can now call drm_crtc_set_max_vblank_count() to configure
Hey Christian,
Sorry for the late reply, I missed this for some reason.
On Wed, Nov 21, 2018 at 5:00 AM Christian König
wrote:
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index 370e9a5536ef..531726443104 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > ++
From: Anusha Srivatsa
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.
Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the DSC_MUX_WORD_SIZE constants (Mana
DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the remaining
From: Anusha Srivatsa
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.
v2:
- rebased.
- Add additional check for compression state. (Gaurav)
v3: rebased.
v4:
- Move the code to the proper spot according to spec (Ville)
- Use proper checks (manasi)
v5: Remove unn
Display Stream Splitter registers need to be programmed to enable
the joiner if two DSC engines are used and also to enable
the left and the right DSC engines. This happens as part of
the DSC enabling routine in the source in atomic commit.
v4:
* Remove redundant comment (Ville)
v3:
* Use cpu_tran
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the
DSC DPCD color depth register advertises its color depth capabilities
by setting each of the bits that corresponding to a specific color
depth. This patch defines those specific color depths and adds
a helper to return an array of color depth capabilities.
v2:
* Simplify the logic (Ville)
Signed-
Basic DSC parameters and DSC configuration data needs to be computed
for each of the requested mode during atomic check. This is
required since for certain modes, valid DSC parameters and config
data might not be computed in which case compression cannot be
enabled for that mode.
For that reason we
From: Gaurav K Singh
This patches does the following:
1. This patch defines all the DSC parameters as per the VESA
DSC specification. These are stored in the encoder and used
to compute the PPS parameters to be sent to the Sink.
2. Compute all the DSC parameters which are derived from DSC
state
From: Gaurav K Singh
This patch enables decompression support in sink device
before link training and disables the same during the
DDI disabling.
v3 (From manasi):
* Pass bool state to enable/disable (Ville)
v2:(From Manasi)
* Change the enable/disable function to take crtc_state
instead of inte
DSC PPS secondary data packet infoframes are filled with
DSC picure parameter set metadata according to the DSC standard.
These infoframes are sent to the sink device and used during DSC
decoding.
v3:
* Rename to intel_dp_write_pps_sdp (Ville)
* Use const intel_crtc_state (Ville)
v2:
* Rebase ond
From: Anusha Srivatsa
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.
The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is alrea
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload
A separate power well 2 (PG2) is required for VDSC on eDP transcoder
whereas all other transcoders use the power wells associated with the
transcoders for VDSC.
This patch adds a helper to obtain correct power domain depending on
transcoder being used and enables/disables the power wells during
VDS
From: Anusha Srivatsa
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.
This has to happen before link training.
v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
- change commit message. (Gaurav)
v3: rebased. (r-b Manasi)
v4
If a eDP panel supports both PSR2 and VDSC, our HW cannot
support both at a time. Give priority to PSR2 if a requested
resolution can be supported without compression else enable
VDSC and keep PSR2 disabled.
v4:
Fix the unrealted stuff removed during rebase (Ville)
v3:
* Rebase
v2:
* Add warning f
1. Disable Left/right VDSC branch in DSS Ctrl reg
depending on the number of VDSC engines being used
2. Disable joiner in DSS Ctrl reg
v4:
* Remove encoder, make crtc_state const (Ville)
v3 (From Manasi):
* Add Disable PG2 for VDSC on eDP
v2 (From Manasi):
* Use old_crtc_state to find dsc para
On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.
v3:
* Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville)
* Move it around TRANSCODER power domain defs (Ville)
v2:
* Fix the power well mismatch CI er
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
From: Gaurav K Singh
This computation of RC params happens in the atomic commit phase
during compute_config() to validate if display stream compression
can be enabled for the requested mode.
v7 (From Manasi):
* Use DRM_DEBUG instead of DRM_ERROR (Ville)
* Use Error numberinstead of -1 (Ville)
v6
Infoframes are used to send secondary data packets. This patch
adds support for DSC Picture parameter set secondary data packets
in the existing write_infoframe helpers.
v3:
* Unused variables cleanup (Ville)
v2:
* Rebase on drm-tip (Manasi)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec
v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
C
From: "Srivatsa, Anusha"
DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.
v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Manasi Na
On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote:
> On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> > > There has been a TODO waiting for quite a long time in
> > > drm_dp_mst_topology.c:
> > >
> > > /* We can
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Tuesday, November 20, 2018 10:37 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH v10 01/23] drm/dsc: Modify DRM he
On Tue, Nov 20, 2018 at 10:37:35AM -0800, Manasi Navare wrote:
> From: Anusha Srivatsa
>
> If FEC is supported, the corresponding
> DP_TP_CTL register bits have to be configured.
>
> The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> and wait till FEC_STATUS in DP_TP_CTL[28] is
On Tue, Nov 20, 2018 at 10:37:33AM -0800, Manasi Navare wrote:
> From: Anusha Srivatsa
>
> For DP 1.4 and above, Display Stream compression can be
> enabled only if Forward Error Correctin can be performed.
>
> Add a crtc state for FEC. Currently, the state
> is determined by platform, DP and DS
On Tue, Nov 27, 2018 at 05:33:58PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-11-27 17:28:43)
> > On Tue, Nov 27, 2018 at 5:50 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Daniel Vetter (2018-11-27 07:49:18)
> > > > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
>
On Tue, Nov 27, 2018 at 04:54:15PM +, Bloomfield, Jon wrote:
> I'm not formally reviewing this series, but while glancing at it, I
> noticed
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ramalingam C
> > Sent: Tuesday, November 27, 2018 2:43 AM
> > To: intel-...@l
KMS drivers really should all be able to restore their display state
on resume without fbcon helping out. So make this the default.
Since I'm not entirely foolish, make it only a default, which drivers
can still override. That way when the inevitable regression report
happens I can fix things up w
From: Thierry Reding
The host1x hardware found on Tegra194 is mostly backwards compatible
with the version found on Tegra186, with the notable exceptions of the
increased number of syncpoints and mlocks. In addition, some rarely
used features such as syncpoint wait bases were dropped and some
reg
Quoting Daniel Vetter (2018-11-27 17:28:43)
> On Tue, Nov 27, 2018 at 5:50 PM Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2018-11-27 07:49:18)
> > > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
> > > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > >
On Tue, Nov 27, 2018 at 5:50 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2018-11-27 07:49:18)
> > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
> > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > > fairly easy to provoke a specific notifier to be run o
On Tue, Nov 27, 2018 at 03:57:23PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 20, 2018 at 10:37:21AM -0800, Manasi Navare wrote:
> > DSC params like the enable, compressed bpp, slice count and
> > dsc_split are added to the intel_crtc_state. These parameters
> > are set based on the requested mode a
On 2018-11-27 6:09 p.m., Daniel Vetter wrote:
> KMS drivers really should all be able to restore their display state
> on resume without fbcon helping out. So make this the default.
>
> Since I'm not entirely foolish, make it only a default, which drivers
> can still override. That way when the in
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #26 from Linnea S ---
The patch from bug 108704 doesn't help for me, the system still boots to a
black screen. The card is a MSI Radeon R9 390 Gaming 8G running on (patched)
kernel 4.19.4-300.fc29.x86_64. The system boots if I leave
KMS drivers really should all be able to restore their display state
on resume without fbcon helping out. So make this the default.
Since I'm not entirely foolish, make it only a default, which drivers
can still override. That way when the inevitable regression report
happens I can fix things up w
Den 26.11.2018 21.07, skrev Daniel Vetter:
On Mon, Nov 26, 2018 at 04:38:48PM +0100, Noralf Trønnes wrote:
On drm_driver->last_close the generic fbdev emulation will restore fbdev
regardless of it being used or not. This is a problem for e-ink displays
which don't want to be overwritten with ze
I'm not formally reviewing this series, but while glancing at it, I noticed
> -Original Message-
> From: Intel-gfx On Behalf Of
> Ramalingam C
> Sent: Tuesday, November 27, 2018 2:43 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; W
Quoting Daniel Vetter (2018-11-27 07:49:18)
> On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and then munmap() it.
> >
On 11/27/2018 8:45 PM, Ville Syrjälä wrote:
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
the GT Driver Mailbox interface. Instead of listing a
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colo
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
This patch adds a HDMI colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspace
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
The fallback code for getting default backlight caps was using
the wrong variable name. Fix it.
Fixes:
https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.html
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 inser
On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
wrote:
> I think a more abstract property "% of GPU (processing power)" might
> be a more universal approach. One can then implement that through
> subdividing the resources or timeslicing them, depending on the GPU
> topology.
>
> Leasing 1/8th, 1/
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 6be068c27b290af91689304898e484573e3bb4f1
commit: 6be068c27b290af91689304898e484573e3bb4f1 [72/72] drm/amdgpu: support
Vega20 A1 ASICs
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, November 20, 2018 9:06 PM
>To: Shankar, Uma ; Syrjala, Ville
>; Lankhorst, Maarten ;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org
>Cc: nd
>Subject: Re: [v2 1/2] drm: Add colorspace prope
1 - 100 of 255 matches
Mail list logo
