On Thu, 8 Nov 2018 08:16:53 -0800
Eric Anholt wrote:
> The extra to_v3d_bo() calls came from copying this from the vc4
> driver, which stored the cma gem object in the structs.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 32
Jean,
ast doesn't remove the vesafb's framebuffer before attaching to the
device. I have a patch at [1]. If you have a way of testing it, I'd
appreciate.
Best regards
Thomas
[1] https://bugzilla.suse.com/show_bug.cgi?id=1112963
Am 12.11.18 um 17:41 schrieb Jean Delvare:
> On Mon, 2018-11-12 at
Sir,
We found the performance will be bad on desktop environment with OpenSUSE15
UEFI installation if remove "arch_io_reserve_memtype_wc".
Regards,
Y.C. Chen
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Jean Delvare
Sent: Thursday,
Hello,
syzbot found the following crash on:
HEAD commit:ccda4af0f4b9 Linux 4.20-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12e15b8340
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link:
On 2018-08-02 08:06, Peter Rosin wrote:
> On 2018-08-01 11:35, Russell King - ARM Linux wrote:
>> On Wed, Aug 01, 2018 at 11:01:12AM +0200, Peter Rosin wrote:
>>> I don't think it's a problem with the atmel I2C driver. IIRC, the
>>> tda998x driver issues the command a initiate the EDID read, but
On Mon, 2018-11-12 at 15:45 +0100, Takashi Iwai wrote:
> On Mon, 12 Nov 2018 15:36:07 +0100,
> Jean Delvare wrote:
> > Takashi asked me to compare the contents of
> > /sys/kernel/debug/x86/pat_memtype_list before and after the commit
> > above. Before the commit, we have:
> >
> > uncached-minus @
From: Jorge Ramirez-Ortiz
The video mode for DMT is only populated to support encp.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/gpu/drm/meson/meson_venc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
On 12/11/2018 19:41, Jorge Ramirez-Ortiz wrote:
> From: Jorge Ramirez-Ortiz
>
> The video mode for DMT is only populated to support encp.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/gpu/drm/meson/meson_venc.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
On Thu, 8 Nov 2018 08:16:51 -0800
Eric Anholt wrote:
Maybe you could add a short description here to avoid having an empty
commit message.
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> include/uapi/drm/v3d_drm.h | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Thu, 8 Nov 2018 08:16:52 -0800
Eric Anholt wrote:
> I merged bin and render's paths in a late refactoring.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi
Am 13.11.18 um 13:08 schrieb Jean Delvare:
> Hi Thomas,
>
> On Tue, 13 Nov 2018 10:23:45 +0100, Thomas Zimmermann wrote:
>> ast doesn't remove the vesafb's framebuffer before attaching to the
>> device. I have a patch at [1]. If you have a way of testing it, I'd
>> appreciate.
>>
>> [1]
Le sam. 10 nov. 2018 à 03:48, YueHaibing a écrit :
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/sti/sti_crtc.c: In function 'sti_crtc_vblank_cb':
> drivers/gpu/drm/sti/sti_crtc.c:255:22: warning:
> variable 'priv' set but not used [-Wunused-but-set-variable]
>
> It
On Tue, Nov 13, 2018 at 04:46:08PM +0530, Jagan Teki wrote:
> DSI DPHY gate bit on MIPI DSI clock register is bit 15
> not bit 30.
>
> Signed-off-by: Jagan Teki
> Acked-by: Stephen Boyd
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
On Tue, Nov 13, 2018 at 05:45:35PM +0530, Jagan Teki wrote:
> Allwinner PWM support need for ARM64 Allwinner SoC's
> which used pwms, builds it as module.
>
> Signed-off-by: Jagan Teki
Applied all 4 patches, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
On 13/11/2018 09:35, Neil Armstrong wrote:
> On 12/11/2018 19:41, Jorge Ramirez-Ortiz wrote:
>> From: Jorge Ramirez-Ortiz
>>
>> The video mode for DMT is only populated to support encp.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz
>> ---
>> drivers/gpu/drm/meson/meson_venc.c | 15 ---
>>
On Tue, Nov 13, 2018 at 05:30:54PM +0530, Jagan Teki wrote:
> Add support for Allwinner A64 has Mali-400MP2.
>
> All interrupt lines are mentioned in the manual so used the same.
> Used 408MHz as assigned clock rate used by BSP, so used the same as
> well.
You're not using that frequency
On 05/11/2018 15:02, Maxime Jourdan wrote:
> Hi Neil,
>
> On Mon, Nov 5, 2018 at 1:51 PM Neil Armstrong wrote:
>>
>> Hi Maxime,
>>
>> On 05/11/2018 11:45, Maxime Jourdan wrote:
>>> The meson DRM driver currently uses constant, static canvas indexes.
>>>
>>> This is not optimal and could conflict
On 06/11/2018 10:39, Neil Armstrong wrote:
> This serie adds support for :
> - Overlay Plane blended with the primary plane, we can describe as "behind"
> - Primary Plane up-scaling up to 5x factor to support the OSD plane being
> upscaled from 1920x1080 when the display mode is set as
On Tue, Nov 13, 2018 at 05:30:53PM +0530, Jagan Teki wrote:
> Allwinner A64 has Mali-400MP2, so document the relevant compatible
> as "allwinner,sun50i-a64-mali"
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - New patch, separated from previous version patch.
>
>
On Tue, 13 Nov 2018 16:46:32 +0530
Jagan Teki wrote:
Hi,
> This patch add support for Bananapi S070WV20-CT16 DSI panel to
> BPI-M64 board.
>
> DSI panel connected via board DSI port with,
> - DC1SW as AVDD supply
Are you sure of that? I don't see anything in the schematic to support
this. The
On Tue, 13 Nov 2018 16:46:33 +0530
Jagan Teki wrote:
Hi,
I couldn't find a schematic for this board, but some things in here
look inconsistent:
> Amarula A64-Relic board by default bound with Techstar TS8550B
> MIPI-DSI panel, add support for it.
>
> DSI panel connected via board DSI port
From: Heiko Stuebner
This is a panel handled through the generic lvds-panel binding,
so only needs its additional compatible specified.
Signed-off-by: Heiko Stuebner
---
.../bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++
1 file changed, 7 insertions(+)
create mode 100644
On Tue, Nov 13, 2018 at 04:46:10PM +0530, Jagan Teki wrote:
> Some NKM PLLs, frequency can be set above PLL working range.
>
> Add a constraint for maximum supported rate. This way, drivers can
> specify which is maximum allowed rate for PLL.
>
> Signed-off-by: Jagan Teki
> Acked-by: Stephen
vc4_plane_atomic_async_update() calls vc4_plane_atomic_check()
which in turn calls vc4_plane_setup_clipping_and_scaling(), and since
commit 58a6a36fe8e0 ("drm/vc4: Use
drm_atomic_helper_check_plane_state() to simplify the logic"), this
function accesses plane_state->state which will be NULL when
drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
state->legacy_cursor_update is true, but we now for sure that we want
a sync update when we call drm_atomic_helper_setup_commit() from
vc4_atomic_commit().
Explicitly set state->legacy_cursor_update to false to prevent this
https://bugs.freedesktop.org/show_bug.cgi?id=108729
Bug ID: 108729
Summary: [Kaveri CIK 7400K] [drm:vce_v2_0_start [amdgpu]]
*ERROR* VCE not responding, trying to reset the
ECPU!!!
Product: DRI
Version: DRI git
On Tue, Nov 13, 2018 at 04:27:28PM +0200, Stanislav Lisovskiy wrote:
> Currently whenever we attempt to recalculate
> watermarks, we assign dirty_pipes to zero,
> then compare current wm results to the recalculated
> one and if they changed we set correspondent dirty_pipes
> bit again.
> This can
On Mon, Nov 12, 2018 at 05:20:28PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > Instead of registering through dpu_power_handle just to get a call on
> > runtime_resume, call the crtc function directly.
> >
> > Signed-off-by: Sean Paul
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108591
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
From: Sean Paul
Now that runtime resume is handled in encoder, we don't need to worry
about crtc_lock recursion when calling pm_runtime_(get|put). So drop the
lock drops in _dpu_crtc_vblank_enable_no_lock().
Changes in v2:
- Added to patch series
Signed-off-by: Sean Paul
---
https://bugs.freedesktop.org/show_bug.cgi?id=108591
--- Comment #8 from Chris Wilson ---
Probably should have mentioned the gpu hang, as that makes it a completely
different bug.
<7> [99.123649] hangcheck rcs0
<7> [99.123667] hangcheck \x09current seqno 1ec, last 1fb, hangcheck 1ec [5952
ms]
https://bugs.freedesktop.org/show_bug.cgi?id=108591
--- Comment #9 from Chris Wilson ---
(In reply to Chris Wilson from comment #8)
> Fwiw, my slow pIIIm i915gm doesn't seem to suffer the same fate.
Except I should check pnv for my closest equiv to blb.
--
You are receiving this mail because:
Quoting Stanislav Lisovskiy (2018-11-13 14:31:38)
> Currently whenever we attempt to recalculate
> watermarks, we assign dirty_pipes to zero,
> then compare current wm results to the recalculated
> one and if they changed we set correspondent dirty_pipes
> bit again.
> This can lead to situation,
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #16 from Daniel Exner ---
I own a Dell U3415W also connected via DisplayPort and I have the same issue.
Worked like a charm in the past.
--
You are receiving this mail because:
You are the assignee for the
Currently whenever we attempt to recalculate
watermarks, we assign dirty_pipes to zero,
then compare current wm results to the recalculated
one and if they changed we set correspondent dirty_pipes
bit again.
This can lead to situation, when we same clearing dirty_pipes,
same wm results twice and
Currently whenever we attempt to recalculate
watermarks, we assign dirty_pipes to zero,
then compare current wm results to the recalculated
one and if they changed we set correspondent dirty_pipes
bit again.
This can lead to situation, when we are clearing dirty_pipes,
same wm results twice in a
https://bugs.freedesktop.org/show_bug.cgi?id=108729
Vedran Miletić changed:
What|Removed |Added
Keywords||regression
Summary|[Kaveri
On Mon, Nov 12, 2018 at 05:47:58PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > The crtc runtime resume doesn't actually operate on the crtc, but rather
> > its encoders. The problem with this is that we need to inspect the crtc
> > state to
On Fri, Nov 09, 2018 at 11:37:17AM +0530, Rajendra Nayak wrote:
>
> On 11/2/2018 6:19 PM, Jayant Shekhar wrote:
> > In case of msm drm bind failure, dpu_mdss_destroy is triggered.
> > In this function, resources are freed and pm runtime disable is
> > called, which triggers dpu_mdss_disable. Now
https://bugs.freedesktop.org/show_bug.cgi?id=108729
--- Comment #2 from Alex Deucher ---
Please attach your full dmesg output and xorg log if using X.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Mon, Nov 12, 2018 at 05:43:17PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > Add a bool to dpu_encoder_virt to track whether the encoder is enabled
> > or not. Repurpose the enc_lock mutex to ensure that it is consistent
> > with the hw
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Changes in v2:
- Removed obsolete comment (Jeykumar)
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna, ScreenPtr
> screen)
> } else if (sna->kgem.gen < 040) {
> adaptor->nImages = ARRAY_SIZE(gen3_Images);
> adaptor->pImages = (XvImageRec
On Tue, Nov 13, 2018 at 01:28:40PM +, Peter Rosin wrote:
> Hi!
>
> I'm wondering about some programming details regarding the TDA998x
> driver...
>
> The bindings documentation [1] state that one should fill in the
> desired register content of the AP_ENA register. However, I cannot
> find
Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.
Pretend we have a topology like this:
|- DP-1: mst_primary
|- DP-4: active display
|- DP-5: disconnected
|- DP-6: active hub
|- DP-7: active display
|-
On Tue, Nov 13, 2018 at 08:58:15PM +, Peter Rosin wrote:
> On 2018-11-13 20:09, Russell King - ARM Linux wrote:
> > On Tue, Nov 13, 2018 at 06:12:37PM +, Peter Rosin wrote:
> >> On 2018-11-13 18:24, Russell King - ARM Linux wrote:
> >>> On Tue, Nov 13, 2018 at 01:28:40PM +, Peter Rosin
This is a second revision of the series previously posted here:
https://lists.freedesktop.org/archives/intel-gfx/2018-October/178202.html
As noted before, this functionality adds new ABI so we need a userspace
consumer ready before we merge the kernel work. My understanding is
that some of
Eric Anholt writes:
> The TFU can copy from raster, UIF, and SAND input images to UIF output
> images, with optional mipmap generation. This will certainly be
> useful for media EGL image input, but is also useful immediately for
> mipmap generation without bogging the V3D core down.
>
> For
https://bugzilla.kernel.org/show_bug.cgi?id=201067
--- Comment #10 from Benjamin Xiao (ben.r.x...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #3)
> Created attachment 278455 [details]
> 0001-drm-amd-display-Use-higher-dispclk-value-for-dce120.patch
>
> Do you mind testing
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to
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)
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
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
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
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
DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.
force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.
v4:
*
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
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
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
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: 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
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
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
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
On Tue, 13 Nov 2018 13:24:07 -0800
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > vc4_plane_atomic_async_update() calls vc4_plane_atomic_check()
> > which in turn calls vc4_plane_setup_clipping_and_scaling(), and since
> > commit 58a6a36fe8e0 ("drm/vc4: Use
> >
The pull request you sent on Sun, 11 Nov 2018 04:43:57 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-11-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/20ef6d06ef9a31a33516637a80521b9fc7f1f849
Thank you!
--
Deet-doot-dot, I am a bot.
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
https://bugzilla.kernel.org/show_bug.cgi?id=201067
--- Comment #9 from Benjamin Xiao (ben.r.x...@gmail.com) ---
I get the same visual corruption as well. It only appears when I run the
monitor at 144Hz. 120Hz seems fine.
--
You are receiving this mail because:
You are watching the assignee of
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #68 from dwagner ---
Tested today's current amd-staging-drm-next git head, to see if there has been
any improvement over the last two months.
The bad news: The 3-fps-video-replay test still crashes the driver reproducably
after few
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
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
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
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.
Signed-off-by: Manasi Navare
Cc: Ville
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: "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
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
This patch series addresses review comments from DSC patch set:
https://patchwork.freedesktop.org/series/51986/
and FEc patch set:
https://patchwork.freedesktop.org/series/47848/
Anusha Srivatsa (4):
i915/dp/fec: Add fec_enable to the crtc state.
drm/i915/fec: Set FEC_READY in
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
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
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)
On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
It's just for debug output, we don't need it
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14
On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
The indirection of registering a callback and opaque pointer isn't real
useful when there's only one callsite. So instead of having the
vblank_cb registration, just give encoder a crtc and let it directly
call the vblank handler.
In a
On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
Instead of assigning/clearing the crtc on vblank enable/disable, we can
just assign and clear the crtc on modeset. That allows us to just
toggle
the encoder's vblank interrupts on vblank_enable.
So why is this important? Previously the
https://bugs.freedesktop.org/show_bug.cgi?id=108710
--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Unfortunately in 4.20 rc2 this annoying bug still not fixed
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Wed, Nov 14, 2018 at 2:31 PM Jagan Teki wrote:
>
> On Tue, Nov 13, 2018 at 5:52 PM Andre Przywara wrote:
> >
> > On Tue, 13 Nov 2018 16:46:32 +0530
> > Jagan Teki wrote:
> >
> > Hi,
> >
> > > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > > BPI-M64 board.
> > >
> > > DSI
https://bugs.freedesktop.org/show_bug.cgi?id=108710
--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 142458
--> https://bugs.freedesktop.org/attachment.cgi?id=142458=edit
dmesg 4.20 rc2
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108322
--- Comment #14 from bmil...@gmail.com ---
Problem still present for me on kernels 4.18, 4.19, 4.20 and 4.21-drm-next
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108613
--- Comment #7 from bmil...@gmail.com ---
I gave up trying to use my monitor at it's supported 75hz. Locking mclk to fix
flickering works only temporarily because it resets at certain events
(sleep/wake, resolution changes). Why is this
Quoting Ville Syrjälä (2018-11-13 19:13:40)
> On Tue, Nov 13, 2018 at 06:49:38PM +, Chris Wilson wrote:
> > Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> > > @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna,
> > > ScreenPtr screen)
> > > } else if (sna->kgem.gen
From: Sean Paul
The drm_crtc_vblank_on/off calls in enable/disable guarantee that we
won't call this function when crtc is not enabled.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Sean Paul
Each time it's called we're holding the crtc modeset lock, so it's
redundant.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ---
2 files changed, 14 deletions(-)
diff --git
From: Sean Paul
I think the intention here was to protect the enc->crtc access, but
that's insufficient to avoid enc->crtc changing. Fortunately we're
already holding the modeset lock when this is called (from
atomic_check), so remove the crtc_lock and add a modeset lock check.
While we're at
From: Sean Paul
The indirection of registering a callback and opaque pointer isn't real
useful when there's only one callsite. So instead of having the
vblank_cb registration, just give encoder a crtc and let it directly
call the vblank handler.
In a later patch, we'll make use of this further.
From: Sean Paul
Matches dpu_crtc_enable and we'll need the old state in a future patch
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
From: Sean Paul
There are 4 times that _dpu_crtc_vblank_enable_no_lock() is called:
1- crtc enable
2- crtc disable
3- crtc vblank enable
4- crtc vblank disable
When we enable or disable the crtc, we call drm_crtc_vblank_on and
drm_crtc_vblank_off respectively. That will gate vblank enables and
From: Sean Paul
Instead of assigning/clearing the crtc on vblank enable/disable, we can
just assign and clear the crtc on modeset. That allows us to just toggle
the encoder's vblank interrupts on vblank_enable.
So why is this important? Previously the driver was using the legacy
pointers to
From: Sean Paul
It's just for debug output, we don't need it
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 --
3 files changed, 4 insertions(+),
On Tue, Nov 13, 2018 at 03:52:44PM -0500, Sean Paul wrote:
> From: Sean Paul
I neglected to add --cover-letter to send-email, so pasting my cover here
instead:
Hi all,
So I kept digging into the locking and dependencies around encoder/crtc and this
is the latest series to pop out. I think
Boris Brezillon writes:
> drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
> state->legacy_cursor_update is true, but we now for sure that we want
> a sync update when we call drm_atomic_helper_setup_commit() from
> vc4_atomic_commit().
>
> Explicitly set
1 - 100 of 107 matches
Mail list logo
