Re: [PATCH 02/10] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection

On Mon, Nov 5, 2018 at 4:09 PM Maxime Ripard wrote: > > On Sat, Nov 03, 2018 at 03:38:52PM +0530, Jagan Teki wrote: > > Instruction loop selection would require before writing > > loop number registers, so enable idle, LP11 bits on > > loop selection register. > > > > Reference code available in B

Re: [PATCH v2 3/4] drm/omap: dsi: Ensure the device is active during probe

* Laurent Pinchart [181105 15:10]: > The probe function performs hardware access to read the number of > supported data lanes from a configuration register and thus requires the > device to be active. Ensure this by surrounding the access with > dsi_runtime_get() and dsi_runtime_put() calls. > >

[PATCH 2/2] drm/meson: Use optional canvas provider

This is the first step into converting the meson/drm driver to use the canvas module. If a canvas provider node is detected in DT, use it. Otherwise, fall back to what is currently being done. Signed-off-by: Maxime Jourdan --- drivers/gpu/drm/meson/Kconfig | 1 + drivers/gpu/drm/meson/me

[PATCH 1/2] dt-bindings: display: amlogic, meson-vpu: Add optional canvas provider node

Allows using the new canvas provider module if present. Signed-off-by: Maxime Jourdan --- Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicet

[PATCH 1/2] Docs/EDID: Fixed erroneous bits of XOFFSET, XPULSE, YOFFSET and YPULSE

The problem was found when EDID data sets for displays other than the provided samples were generated. The patch has no effect on the provided samples that still match the data used in drivers/gpu/drm/drm_edid_load.c. The provided samples use small values for XOFFSET, XPULSE, YOFFSET and YPULSE, w

[PATCH 2/2] Docs/EDID: Calculate CRC while building the code

The previous version made it necessary to first generate an EDID data set without correct CRC and then to fix the CRC in a second step. This patch adds the CRC calculation to the makefile in such a way that a correct EDID data set is generated in a single build step. Successfully tested with all ex

Re: [PATCH 0/2] drm/meson: Allow using optional canvas provider

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 with other drivers also using > > canvases. > > Indee

Re: [PATCH v2 1/4] drm/omap: Populate DSS children in omapdss driver

* Laurent Pinchart [181105 15:10]: > The DSS DT node contains children that describe the DSS components > (DISPC and internal encoders). Each of those components is handled by a > platform driver, and thus needs to be backed by a platform device. > > The corresponding platform devices are created

[PATCH v2] drm/bridge/sii902x: Fix EDID readback

While adding SiI9022A support to the iwg23s board, it came up that when the HDMI transmitter is in pass through mode the device is not compliant with the I2C specification anymore, as it requires a far bigger tbuf, due to a delay the HDMI transmitter is adding when relaying the STOP condition on th

RE: [PATCH] drm/bridge/sii902x: Fix EDID readback

Hello Peter, Thank you for your feedback! > Subject: Re: [PATCH] drm/bridge/sii902x: Fix EDID readback > snip > > If the things you write about the bits are true (haven't looked closely), I > wouldn't > add any regmap coordination. But if I was the maintainer, I'd like a comment > about > this

Re: [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm

* Laurent Pinchart [181105 19:23]: > This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM > issues at module load and unload time" series. It demonstrates what I > think is the proper long term fix for the issue addressed by patch 4/4. > Due to its nature, I don't think this pa

[PATCH 0/2] drm/meson: Allow using optional canvas provider

The meson DRM driver currently uses constant, static canvas indexes. This is not optimal and could conflict with other drivers also using canvases. This patch series allows the driver to optionnally use a canvas provider module that is able to dispatch canvases, on demand and free of conflict. I

Re: [PATCH v3 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if NULL

在 2018-10-08一的 11:21 +0200，Maxime Ripard写道： > On Fri, Oct 05, 2018 at 11:59:51PM +0200, Giulio Benetti wrote: > > If tcon->panel pointer is NULL, trying to dereference from it > > (i.e. tcon->panel->connector) will cause a null pointer > > dereference. > > > > Add tcon->panel null pointer check be

[PATCH 0/2] Docs/EDID: Fixed and improved EDID documentation

A problem was found when EDID data sets for displays other than the provided samples were generated. The patch series has no effect on the provided samples that still match the data used in drivers/gpu/drm/drm_edid_load.c. The provided samples use small values for XOFFSET, XPULSE, YOFFSET and YPULS

Re: [PATCH] backlight/arcxcnn support newer chips in arcxcnn family and fix vendor prefix

Apologies, this patch submission was not done properly and not submitted properly. I have prepared a new patch set which breaks this work into three distinct patches. Brian On 11/3/18 12:58 PM, Daniel Thompson wrote: On Thu, Nov 01, 2018 at 06:49:01PM -0400, Brian Dodge wrote: Support for

Re: [PATCH v2 2/4] drm/omap: hdmi4: Ensure the device is active during bind

* Laurent Pinchart [181105 15:10]: > The bind function performs hardware access (in hdmi4_cec_init()) and > thus requires the device to be active. Ensure this by surrounding the > bind function by hdmi_runtime_get() and hdmi_runtime_put() calls. > > Fixes: 27d624527d99 ("drm/omap: dss: Acquire ne

RE: [PATCH v6 0/6] drm: add support for Cadence MHDP DPI/DP bridge.

Hi Laurent, Understood. Thanks. Damian -Original Message- From: Laurent Pinchart Sent: Monday, November 5, 2018 11:30 To: Damian Kos Cc: David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Andrzej Hajda ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Heik

RE: [PATCH v6 0/6] drm: add support for Cadence MHDP DPI/DP bridge.

Hi Guys, I'm wondering if this time patch is so good that there're no change requests, or is it so bad that it was rejected without a comment : ) Please let me know if this patch is being in review or was rejected and, if so, what needs to be changed. Regards, Damian -Original Message-

RE: [PATCH v6 0/6] drm: add support for Cadence MHDP DPI/DP bridge.

Hi Andrzej, Thanks! Damian -Original Message- From: Andrzej Hajda Sent: Monday, November 5, 2018 12:10 To: Damian Kos ; Laurent Pinchart Cc: David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Heiko Stübner ;

[PATCH] drm/amd/display: Fix misleading buffer information

RETIMER_REDRIVER_INFO shows the buffer as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Fixes: 2f14bc89("drm/amd/display: add retimer log for HWQ tuning use.") Cc: Charlene Liu Cc: Dmytro Laktyushkin Cc: Leo Li Signed-off-by: Sh

Re: [PATCH v2] drm/bridge/sii902x: Fix EDID readback

Hi! A handful of nitpicks inline... On 2018-11-05 14:56, Fabrizio Castro wrote: > While adding SiI9022A support to the iwg23s board, it came > up that when the HDMI transmitter is in pass through mode the > device is not compliant with the I2C specification anymore, > as it requires a far bigger

RE: [PATCH] drm/bridge/sii902x: Fix EDID readback

Hello Peter, Thank you for your feedback! The changes you have suggested seem to be working just fine, I have tested them this morning. Thanks, Fab > Subject: Re: [PATCH] drm/bridge/sii902x: Fix EDID readback > > On 2018-11-02 13:13, Fabrizio Castro wrote: > > While adding SiI9022A support to t

Re: [PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time

* Laurent Pinchart [181105 15:14]: > Hi Tony, > > On Thursday, 1 November 2018 18:17:43 EET Laurent Pinchart wrote: > > On Thursday, 1 November 2018 17:58:56 EET Tony Lindgren wrote: > > > * Laurent Pinchart [181101 12:13]: > > >> On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote: >

[Bug 108675] [CI][BAT] The binary pm_rpm excited before executing module-reload

https://bugs.freedesktop.org/show_bug.cgi?id=108675 Bug ID: 108675 Summary: [CI][BAT] The binary pm_rpm excited before executing module-reload Product: DRI Version: XOrg git Hardware: Other OS: All

[Bug 108675] [CI][BAT] The binary pm_rpm excited before executing module-reload

https://bugs.freedesktop.org/show_bug.cgi?id=108675 Martin Peres changed: What|Removed |Added Priority|medium |highest Whiteboard|

[PATCH] drm: Propagate failure from drm_modeset_register_all() on module load

If we fail to register all the initial CRTCs and connectors, report that failure back to the caller. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_drv.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c ind

Re: [Intel-gfx] [RFC v5 1/8] drm: Add Enhanced Gamma LUT precision structure

On Sun, Sep 16, 2018 at 01:45:24PM +0530, Uma Shankar wrote: > Existing LUT precision structure is having only 16 bit > precision. This is not enough for upcoming enhanced hardwares > and advance usecases like HDR processing. Hence added a new > structure with 32 bit precision values. Also added th

Re: [PATCH] drm/vgem: create a render node for vgem

On Mon, Nov 05, 2018 at 03:35:54PM +, Emil Velikov wrote: > On Mon, 5 Nov 2018 at 15:30, Chris Wilson wrote: > > > > Quoting kbuild test robot (2018-10-26 16:55:25) > > > Hi Emil, > > > > > > Thank you for the patch! Yet something to improve: > > > > > > [auto build test ERROR on sof-driver-fu

Re: [PATCH] drm/syncobj: Fix oops on drm_syncobj_find_fence(file_priv, 0, ...).

Acked-by: Christian König Should I push it to drm-misc-next? Christian. Am 06.11.18 um 03:18 schrieb Zhou, David(ChunMing): > Reviewed-by: Chunming Zhou > >> -Original Message- >> From: Eric Anholt >> Sent: Tuesday, November 06, 2018 7:01 AM >> To: dri-devel@lists.freedesktop.org >> C

[Bug 107947] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:563 during boot

https://bugs.freedesktop.org/show_bug.cgi?id=107947 --- Comment #8 from Alex Smith --- I think this is related to display power management - it occurs when the monitor is woken from standby. The blank screen I get at startup occurs between the login screen (gdm) and the desktop. After logging in,

Re: [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm

On 05/11/18 23:46, Laurent Pinchart wrote: > Hi Tony, > > On Monday, 5 November 2018 22:14:46 EET Tony Lindgren wrote: >> * Laurent Pinchart [181105 19:23]: >>> This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM >>> issues at module load and unload time" series. It demonstra

[Bug 108591] [CI][DRMTIP] igt@gem_tiled_fence_blits@normal - fail - Failed assertion: linear[i] == start_val

https://bugs.freedesktop.org/show_bug.cgi?id=108591 Chris Wilson changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[Bug 108139] My HDMI stopped working at Linux 4.18.8

https://bugs.freedesktop.org/show_bug.cgi?id=108139 --- Comment #6 from Duncan Roe --- Created attachment 142387 --> https://bugs.freedesktop.org/attachment.cgi?id=142387&action=edit Current work-around patch -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected

https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #29 from Duncan Roe --- (In reply to Roman Li from comment #25) > Created attachment 142374 [details] > the latest FBC fixes > > Duncan, you can also try 'the latest FBC fixes' to check whether they fix > your issue. I applied the

[PATCH] drm/meson: Add HDMI 1.4 4k modes

Add the timings for the HDMI 1.4 4K modes support : - 3840x2160@30 - 3840x2160@25 - 3840x2160@24 Since the 297000Hz pixel clock is already managed and the modes are compatible with the HDMI 1.4 current HDMI PHY+Controller support, only the missing timings values needs to be added. Signed-off-by:

[PATCH 1/3] drm/meson: Support Overlay plane for video rendering

The Amlogic Meson GX SoCs support an Overlay plane behind the primary plane for video rendering. This Overlay plane support various YUV layouts : - YUYV - NV12 / NV21 - YUV444 / 422 / 420 / 411 / 410 The scaler supports a wide range of scaling ratios, but for simplicity, plane atomic check limits

[PATCH 3/3] drm/meson: Add primary plane scaling

This patch adds support for the Primary Plane scaling. On the Amlogic GX SoCs, the primary plane is used as On-Screen-Display layer on top of video, and it's needed to keep the OSD layer to a lower size as the physical display size to : - lower the memory bandwidth - lower the OSD rendering - lowe

[PATCH 2/3] drm/meson: move OSD scaler management into plane atomic update

In preparation to support the Primary Plane scaling, move the basic OSD Interlace-Only scaler setup code into the primary plane atomic update callback and handle the vsync scaler update like the overlay plane scaling registers update. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson

[PATCH 0/3] drm/meson: Add support for Overlay and OSD Plane scaling

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 3840x2160. These patches depends on the "drm/meson: Allow us

[Bug 108139] My HDMI stopped working at Linux 4.18.8

https://bugs.freedesktop.org/show_bug.cgi?id=108139 --- Comment #7 from Duncan Roe --- I am currently running Linux 4.19.1 with Attachment 142387 and not seeing the problem. Might it be possible to instead use an approach like Attachment 142350 to Bug 108139 to conditionally obey this code inste

[Bug 108139] My HDMI stopped working at Linux 4.18.8

https://bugs.freedesktop.org/show_bug.cgi?id=108139 --- Comment #8 from Duncan Roe --- I am currently running Linux 4.19.1 with Attachment 142387 and not seeing the problem. Might it be possible to instead use an approach like Attachment 142350 to Bug 108577 to conditionally obey this code inste

Re: [PATCH libdrm 5/5] [libdrm] add syncobj timeline tests

On Mon, Nov 05, 2018 at 10:07:24AM +, Zhou, David(ChunMing) wrote: > > > > -Original Message- > > From: Daniel Vetter On Behalf Of Daniel Vetter > > Sent: Monday, November 05, 2018 5:39 PM > > To: Zhou, David(ChunMing) > > Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedeskt

Re: [PATCH] drm/syncobj: Fix oops on drm_syncobj_find_fence(file_priv, 0, ...).

On Tue, Nov 06, 2018 at 09:10:55AM +, Koenig, Christian wrote: > Acked-by: Christian König > > Should I push it to drm-misc-next? Yeah. This should have broken an igt somewhere ... would be good to double check whether that's true and why it wasn't caught. From a quick look i915 doesn't use

[Bug 107012] [PATCH] Radeon SI driver not architecture safe, crashes on ppc64[el]

https://bugs.freedesktop.org/show_bug.cgi?id=107012 Emil Velikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two

https://bugzilla.kernel.org/show_bug.cgi?id=200645 --- Comment #11 from postmas...@amd.com --- Delivery has failed to these recipients or groups: mikita.lip...@amd.com The e-mail address you entered couldn't be found. Please check the recipient's e-mail address and t

[PATCH] drm/meson: Add support for VIC alternate timings

This change is an attempt to handle the alternate clock for the CEA mode. 60Hz vs. 59.94Hz, 30Hz vs 29.97Hz or 24Hz vs 23.97Hz on the Amlogic Meson SoC DRM Driver pixel clock generation. The actual clock generation will be moved to the Common Clock framework once all the video clock are handled by

[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two

https://bugzilla.kernel.org/show_bug.cgi?id=200645 --- Comment #13 from postmas...@amd.com --- Delivery has failed to these recipients or groups: mikita.lip...@amd.com The e-mail address you entered couldn't be found. Please check the recipient's e-mail address and t

Re: [PATCH 0/3] drm/meson: Add support for Overlay and OSD Plane scaling

On Tue, Nov 06, 2018 at 10:39:59AM +0100, 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

Re: [PATCH] drm/panel: simple: switch AUO g185han01 typical clock to 135MHz

Am Montag, den 05.11.2018, 18:08 +0100 schrieb Lucas Stach: > While 144MHz is listed in the datasheet as the typical pixel clock > this leads to a vrefresh rate of 64Fps, which is not what most people > expect. Change this to 135MHz to provide a more common 60Fps refresh > rate. Please ignore this

Re: [PATCH] drm/panel: simple: switch AUO g185han01 typical clock to 135MHz

On Mon, 2018-11-05 at 18:08 +0100, Lucas Stach wrote: > While 144MHz is listed in the datasheet as the typical pixel clock > this leads to a vrefresh rate of 64Fps, which is not what most people > expect. Change this to 135MHz to provide a more common 60Fps refresh > rate. > > Signed-off-by: Lucas

[Bug 108680] [CI][BAT] igt@kms_chamelium may need to wait a little bit for the network to come back up before connecting to chamelium

https://bugs.freedesktop.org/show_bug.cgi?id=108680 Martin Peres changed: What|Removed |Added Priority|medium |highest Whiteboard|

[Bug 108680] [CI][BAT] igt@kms_chamelium may need to wait a little bit for the network to come back up before connecting to chamelium

https://bugs.freedesktop.org/show_bug.cgi?id=108680 Bug ID: 108680 Summary: [CI][BAT] igt@kms_chamelium may need to wait a little bit for the network to come back up before connecting to chamelium Product: DRI Ver

Re: [PATCH 2/2] drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu

On Mon, 2018-11-05 at 18:12 +0100, Lucas Stach wrote: > This is the only place in the driver that should have to deal with > the raw hardware fences. To avoid any further confusion, consolidate > the fence handling in this file and remove any traces of this from > the header files. > > Signed-off-

Re: [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm

On 06/11/18 11:22, Tomi Valkeinen wrote: > On 05/11/18 23:46, Laurent Pinchart wrote: >> Hi Tony, >> >> On Monday, 5 November 2018 22:14:46 EET Tony Lindgren wrote: >>> * Laurent Pinchart [181105 19:23]: This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM issues at m

Re: [PATCH v2 3/3] drm/vc4: Add a load tracker to prevent HVS underflow errors

On Tue, 30 Oct 2018 16:12:55 -0700 Eric Anholt wrote: > > + /* Even if the bandwidth/plane required for a single frame is > > +* > > +* vc4_state->src_w[i] * vc4_state->src_h[i] * cpp * vrefresh > > +* > > +* when downscaling, we have to r

[Bug 201625] New: Amd RX560D VERY slow after upgrade.

https://bugzilla.kernel.org/show_bug.cgi?id=201625 Bug ID: 201625 Summary: Amd RX560D VERY slow after upgrade. Product: Drivers Version: 2.5 Kernel Version: 4.19.1 Hardware: x86-64 OS: Linux Tree: Mainline

Re: [PATCH 0/3] drm/meson: Add support for Overlay and OSD Plane scaling

Hi Daniel, On 06/11/2018 12:13, Daniel Vetter wrote: > On Tue, Nov 06, 2018 at 10:39:59AM +0100, 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 pl

Re: [PATCH v4 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()

On Mon, Nov 05, 2018 at 05:20:09PM -0500, Lyude Paul wrote: > Currently in intel_hpd_irq_storm_detect() when we detect that the last > recorded hotplug wasn't within the period defined by > HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count > to 0 without incrementing it. This r

Re: [PATCH v4 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems

On Mon, Nov 05, 2018 at 05:20:11PM -0500, Lyude Paul wrote: > Unfortunately, it seems that the HPD IRQ storm problem from the early > days of Intel GPUs was never entirely solved, only mostly. Within the > last couple of days, I got a bug report from one of our customers who > had been having issue

Re: [PATCH v4 4/5] drm/i915: Clarify flow for disabling IRQs on storms

On Mon, Nov 05, 2018 at 05:20:10PM -0500, Lyude Paul wrote: > This is rather confusing to look at as-is: > dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() > handles disabling the actual HPD IRQ, while > intel_hpd_irq_storm_disable() handles moving the HPD pin state over from >

Re: [PATCH 0/3] drm/meson: Add support for Overlay and OSD Plane scaling

On Tue, Nov 6, 2018 at 2:37 PM Neil Armstrong wrote: > > Hi Daniel, > > On 06/11/2018 12:13, Daniel Vetter wrote: > > On Tue, Nov 06, 2018 at 10:39:59AM +0100, Neil Armstrong wrote: > >> This serie adds support for : > >> - Overlay Plane blended with the primary plane, we can describe as "behind"

Re: [PATCH] drm/framebuffer: Expose only modifiers that support at least a format

On Mon, Nov 05, 2018 at 06:44:34PM -0800, Dhinakaran Pandiyan wrote: > Allows drivers to pass a larger modifier array, thereby avoiding > declarations of static modifier arrays that are only slight different > for each plane. > > Cc: dri-devel@lists.freedesktop.org > Cc: Ville Syrjälä > Suggested

Re: [PATCH 01/11] drm/msm/dpu: Remove dpu_dbg

On Mon, Nov 05, 2018 at 04:30:53PM -0700, Jordan Crouse wrote: > The functions in dpu_dbg.c aren't used. The two main dump functions > fail after a lookup from dpu_dbg_base.reg_base_list which turns out > to never be populated and once those are removed the rest of the > file doesn't make any sense

Re: [PATCH 02/11] drm/msm/dpu: Use DEFINE_SHOW_ATTRIBUTE

On Mon, Nov 05, 2018 at 04:30:54PM -0700, Jordan Crouse wrote: > Use the standard DEFINE_SHOW_ATTRIBUTE macro for seq_file based > debugfs files instead of custom macros and hand-coded functions. > > v2: Added a cleanup for dpu_encoder.c too > > Signed-off-by: Jordan Crouse Reviewed-by: Sean Pa

Re: [Freedreno] [PATCH 03/11] drm/msm/dpu: Remove dpu_crtc_get_mixer_height

On Mon, Nov 05, 2018 at 04:30:55PM -0700, Jordan Crouse wrote: > dpu_crtc_get_mixer_height() is only used once and the value it > returns can be easily derived from the calling function. > > Signed-off-by: Jordan Crouse Reviewed-by: Sean Paul > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |

Re: [PATCH 04/11] drm/msm/dpu: Remove dpu_crtc_is_enabled()

On Mon, Nov 05, 2018 at 04:30:56PM -0700, Jordan Crouse wrote: > The static inline function dpu_crtc_enabled() is only called once > and the function that calls it in turn is only called once and > the return value can be easily checked in the calling functions > so collapse everything down. > > S

Re: [PATCH 05/11] drm/msm/dpu: Remove unused functions

On Mon, Nov 05, 2018 at 04:30:57PM -0700, Jordan Crouse wrote: > Remove some unused container_of() helper functions. > > v2: Retained still used helper functions in the name of readability > > Signed-off-by: Jordan Crouse Reviewed-by: Sean Paul > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_in

Re: [PATCH v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC

On Fri, Nov 02, 2018 at 02:31:29PM -0700, Manasi Navare wrote: > 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 DR

Re: [PATCH 0/2] Docs/EDID: Fixed and improved EDID documentation

On Mon, 5 Nov 2018 09:48:33 +0100 Christoph Niedermaier wrote: > A problem was found when EDID data sets for displays other > than the provided samples were generated. The patch series has > no effect on the provided samples that still match the data > used in drivers/gpu/drm/drm_edid_load.c. > T

Re: [PATCH v8 13/19] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling

On Fri, Nov 02, 2018 at 02:31:32PM -0700, Manasi Navare wrote: > 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 enab

Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check

On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote: > On Fri, Nov 02, 2018 at 02:31:26PM -0700, 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

Re: [Freedreno] [PATCH 06/11] drm/msm/dpu: Cleanup callers of dpu_hw_blk_init

On Mon, Nov 05, 2018 at 04:30:58PM -0700, Jordan Crouse wrote: > Outside of superfluous parameter checks the dpu_hw_blk_init() > doesn't have any failure paths. Switch it over to be a void > function and we can remove error handling paths in all the functions > that call it. While we're in those fu

Re: [Freedreno] [PATCH 08/11] drm/msm/dpu: Remove dpu_irq and unused functions

On Mon, Nov 05, 2018 at 04:31:00PM -0700, Jordan Crouse wrote: > dpu_irq.c does some unneeded checks and passes control > to dpu_core_irq.c The simple functions can be defined > in the same file where we use them and the files and > their associated hangers on can be deleted. > > Additionally the

Re: [PATCH 07/11] drm/msm: Make irq_postinstall optional

On Mon, Nov 05, 2018 at 04:30:59PM -0700, Jordan Crouse wrote: > Allow the KMS operation 'irq_postinstall' to be optional > so that the target display drivers don't need to define > a dummy function if they don't need one. > > Signed-off-by: Jordan Crouse Reviewed-by: Sean Paul > --- > driver

Re: [v6 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION

On Mon, Nov 05, 2018 at 04:48:57PM -0800, Manasi Navare wrote: > On Mon, Nov 05, 2018 at 03:31:48PM -0800, Anusha Srivatsa wrote: > > 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.

Re: [v6 1/4] i915/dp/fec: Add fec_enable to the crtc state.

On Mon, Nov 05, 2018 at 03:31:47PM -0800, Anusha Srivatsa wrote: > 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

[PATCH v2 4/9] phy: dphy: Add configuration helpers

The MIPI D-PHY spec defines default values and boundaries for most of the parameters it defines. Introduce helpers to help drivers get meaningful values based on their current parameters, and validate the boundaries of these parameters if needed. Signed-off-by: Maxime Ripard --- drivers/phy/Kcon

[PATCH v2 5/9] sun6i: dsi: Convert to generic phy handling

Now that we have everything in place in the PHY framework to deal in a generic way with MIPI D-PHY phys, let's convert our PHY driver and its associated DSI driver to that new API. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/Kconfig | 11 +- drivers/gpu/drm/sun4i/Makefile

[PATCH v2 8/9] phy: Add Cadence D-PHY support

Cadence has designed a D-PHY that can be used by the, currently in tree, DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers. Only the DSI driver has an ad-hoc driver for that phy at the moment, while the v4l2 drivers are completely missing any phy support. In order to make that phy

[PATCH v2 0/9] phy: Add configuration interface for MIPI D-PHY devices

Hi, Here is a set of patches to allow the phy framework consumers to test and apply runtime configurations. This is needed to support more phy classes that require tuning based on parameters depending on the current use case of the device, in addition to the power state management already provide

[PATCH v2 1/9] phy: Add MIPI D-PHY mode

MIPI D-PHY is a MIPI standard meant mostly for display and cameras in embedded systems. Add a mode for it. Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- include/linux/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h

[PATCH v2 7/9] drm/bridge: cdns: Separate DSI and D-PHY configuration

The current configuration of the DSI bridge and its associated D-PHY is intertwined. In order to ease the future conversion to the phy framework for the D-PHY part, let's split the configuration in two. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/cdns-dsi.c | 96 +

[PATCH v2 9/9] drm/bridge: cdns: Convert to phy framework

Now that we have everything we need in the phy framework to allow to tune the phy parameters, let's convert the Cadence DSI bridge to that API instead of creating a ad-hoc driver for its phy. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/cdns-dsi.c | 485 +++

[PATCH v2 3/9] phy: Add MIPI D-PHY configuration options

Now that we have some infrastructure for it, allow the MIPI D-PHY phy's to be configured through the generic functions through a custom structure added to the generic union. The parameters added here are the ones defined in the MIPI D-PHY spec, plus the number of lanes in use. The current set of p

[PATCH v2 6/9] phy: Move Allwinner A31 D-PHY driver to drivers/phy/

Now that our MIPI D-PHY driver has been converted to the phy framework, let's move it into the drivers/phy directory. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/Kconfig | 10 +- drivers/gpu/drm/sun4i/Makefile | 1 +- drivers/gpu/drm/sun4i/sun6i_mipi_dphy

[PATCH v2 2/9] phy: Add configuration interface

The phy framework is only allowing to configure the power state of the PHY using the init and power_on hooks, and their power_off and exit counterparts. While it works for most, simple, PHYs supported so far, some more advanced PHYs need some configuration depending on runtime parameters. These PH

Re: [PATCH 09/11] drm/msm/dpu: Cleanup the debugfs functions

On Mon, Nov 05, 2018 at 04:31:01PM -0700, Jordan Crouse wrote: > Do some debugfs cleanups from across the DPU driver. The DRM > destroy functions will do a recursive delete on the entire > debugfs node so there is no need to store dentry pointers for > the debugfs files that are persistent for the

Re: [PATCH 10/11] drm/msm/dpu: Further cleanups for static inline functions

On Mon, Nov 05, 2018 at 04:31:02PM -0700, Jordan Crouse wrote: > Remove more static inline functions that are lightly used and/or > very simple and easy to build into the calling functions. > > v2: Removed another unused function from dpu_hw_lm.c and add back > dpu_crtc_get_client_type() since the

Re: [Freedreno] [PATCH 11/11] drm/msm/dpu: Clean up dpu_media_info.h static inline functions

On Mon, Nov 05, 2018 at 04:31:03PM -0700, Jordan Crouse wrote: > Do some cleanup in the static inline functions defined in > dpu_media_info.h by cleaning up gotos and unneeded local > variables. > > Signed-off-by: Jordan Crouse > --- > .../gpu/drm/msm/disp/dpu1/msm_media_info.h| 164 ++--

[Bug 201625] Amd RX560D VERY slow after upgrade.

https://bugzilla.kernel.org/show_bug.cgi?id=201625 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.c

[PATCH] drm: rcar-du: Fix external clock error checks

The rcar-du driver supports probe deferral for external clocks, but implements it badly by checking the wrong pointer due to a bad copy and paste. Fix it. While at it, reject invalid clocks outright for DU channels that have a display PLL, as the external clock is mandatory in that case. This avoi

[PATCH][drm-next] drm/panel: s6d16d0: fix spelling mistake "enble" -> "enable"

From: Colin Ian King Trivial fix to spelling mistake in DRM_DEV_ERROR error message Signed-off-by: Colin Ian King --- drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c b/drivers/gpu/d

Re: [PATCH 02/10] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection

On Mon, Nov 05, 2018 at 04:56:35PM +0530, Jagan Teki wrote: > On Mon, Nov 5, 2018 at 4:09 PM Maxime Ripard > wrote: > > > > On Sat, Nov 03, 2018 at 03:38:52PM +0530, Jagan Teki wrote: > > > Instruction loop selection would require before writing > > > loop number registers, so enable idle, LP11 b

Re: [PATCH v3 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if NULL

On Mon, Nov 05, 2018 at 09:23:08PM +0800, Icenowy Zheng wrote: > 在 2018-10-08一的 11:21 +0200，Maxime Ripard写道： > > On Fri, Oct 05, 2018 at 11:59:51PM +0200, Giulio Benetti wrote: > > > If tcon->panel pointer is NULL, trying to dereference from it > > > (i.e. tcon->panel->connector) will cause a null

[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)

https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.17.19, 4.18.0-rc7,|4.17.19, 4.18.

Re: [PATCH 11/11] drm/msm/dpu: Clean up dpu_media_info.h static inline functions

Hi Jordan. > case COLOR_FMT_P010_UBWC: > - alignment = 256; > - stride = MSM_MEDIA_ALIGN(width * 2, alignment); > + stride = MSM_MEDIA_ALIGN(width * 2, 256); > break; > case COLOR_FMT_P010: > - alignment = 128; > -

[PATCH v2] drm: Rename crtc_idr as object_idr to KMS cleanups

This patch solves this TODO task: drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should be renamed to drm_mode_config.object_idr. Signed-off-by: Shayenne da Luz Moura --- Changes in v2: - Make commit message more clear and change header file drivers/gpu/drm/drm_leas

[PATCH] drm/nouveau: tegra: Initialize mode configuration

From: Thierry Reding Irrespective of whether or not the device has any usable outputs, the modesetting helpers will try to register all the resources such as CRTCs and planes. Unfortunately, the helpers rely on drm_mode_config_init() to properly set up internal data structures. Since the Tegra GP

[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU

https://bugs.freedesktop.org/show_bug.cgi?id=108652 --- Comment #2 from mikhail.v.gavri...@gmail.com --- I would welcome any increase of FPS since I play on a 4K monitor. 1) Project CARS 2 GFX Clocks and Power: 700 MHz (MCLK) 984 MHz (SCLK) 1269 MHz (PSTATE_SCLK)

[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU

https://bugs.freedesktop.org/show_bug.cgi?id=108652 --- Comment #3 from mikhail.v.gavri...@gmail.com --- Created attachment 142389 --> https://bugs.freedesktop.org/attachment.cgi?id=142389&action=edit Project CARS 2 - screenshot with FPS counter -- You are receiving this mail because: You are

  1   2   >