Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin

On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you > want. That would be great, although given the potentially inconsistent results we've been seeing so far it would be great if you could additionally push a git

Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin

Hi Maxime, On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote: > I gave it a try with U-Boot with my latest work and couldn't reproduce it, so > it > seems that I fixed it along the way Is your latest work available in a git branch anywhere that we could test directly? Thanks Daniel

Re: [PATCH] i915: disable framebuffer compression on GeminiLake

Hi, On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote: > > Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu: > > Quoting Jian-Hong Pan (2019-04-23 10:28:10) > > > From: Daniel Drake > > > > > > On many (all?) the Gemini Lake systems we work

freedreno header uses not installed xf86atomic.h

Hi, Using libdrm-2.4.97, mesa fails to build on ARM with: [ 456s] In file included from ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33, [ 456s] from ../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34, [ 456s] from

Re: Gemini Lake graphics corruption at top of screen

Hi, On Mon, Oct 8, 2018 at 1:48 PM Daniel Drake wrote: > I recently filed a bug report regarding graphics corruption seen on > Gemini Lake platforms: > https://bugs.freedesktop.org/show_bug.cgi?id=108085 > > This has been reproduced on multiple distros on products from at le

Gemini Lake graphics corruption at top of screen

Hi, I recently filed a bug report regarding graphics corruption seen on Gemini Lake platforms: https://bugs.freedesktop.org/show_bug.cgi?id=108085 This has been reproduced on multiple distros on products from at least 4 vendors. It seems to apply to every GeminiLake product that we have seen.

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

WHi Alex, On Thu, Apr 19, 2018 at 4:13 PM, Alex Deucher wrote: https://bugs.freedesktop.org/show_bug.cgi?id=105684 >>> >>> No progress made on that bug report so far. >>> What can we do to help this advance? >> >> Ping, any news here? How can we help advance on this

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake <dr...@endlessm.com> wrote: > On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: >>> It seems that we are not alone seeing amdgpu-induced stability >>> problems on multiple Raven Ridge platfo

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

Hi Alex, On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote: >> It seems that we are not alone seeing amdgpu-induced stability >> problems on multiple Raven Ridge platforms. >> https://www.phoronix.com/scan.php?page=news_item=AMD-Raven-Ridge-Mobo-Linux >> >> AMD, what

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

Hi, > >>> We are working with new laptops that have the AMD Ravenl Ridge > >>> chipset with this `/proc/cpuinfo` > >>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc > >>> > >>> With the latest kernel 4.15, there're lots of different > >>> panics/oops during boot so no

[PATCH 4.15] drm/amd/display: call set csc_default if enable adjustment is false

: backport to 4.15] Signed-off-by: Daniel Drake <dr...@endlessm.com> --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 2 +- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c | 6 ++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 ++ drivers

AMD DC test results

Hi, Thanks for the hard work on AMD DC development! Here are some new test results - hope they are interesting/useful. CONTEXT We have been tracking DC for a while as we work with multiple products where amdgpu previously was not able to support the HDMI audio output. We are hoping to ship the

Re: Kernel panic on nouveau during boot on NVIDIA NV118 (GM108)

On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu wrote: > We are working with new desktop that have the NVIDIA NV118 > chipset. > > During boot, the display becomes unusable at the point where the > nouveau driver loads. We have reproduced on 4.8, 4.11 and linux > master (4.12-rc3).

Re: i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote: >> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > Please check i

amdgpu display corruption and hang on AMD A10-9620P

Hi, We are working with new laptops that have the AMD Bristol Ridge chipset with this SoC: AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G I think this is the Bristol Ridge chipset. During boot, the display becomes unusable at the point where the amdgpu driver loads. You can see at least two

Re: i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä wrote: > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults > that are set when there is no VBT") fixes things for you. I think this is not going to help. This would only make a difference when there

i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

Hi, Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a regression on Linux 4.9 where the VGA output is shown all-white. This is a regression caused by: commit 0ce140d45a8398b501934ac289aef0eb7f47c596 Author: Ville Syrjälä Date: Tue Oct 11

[PATCH] drm/nouveau/core: recognise GP107 chipset

this is working fine. Signed-off-by: Chris Chiu <c...@endlessm.com> Signed-off-by: Daniel Drake <dr...@endlessm.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/

[PATCH v2] drm/exynos: switch to universal plane API

On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote: > The patch replaces legacy functions > drm_plane_init() / drm_crtc_init() with > drm_universal_plane_init() and drm_crtc_init_with_planes(). > It allows to replace fake primary plane with the real one. > Additionally the patch leaves cleanup

[PATCH] drm/exynos: fix plane-framebuffer linkage

On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter wrote: > On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: >> 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls >> drm_mode_set_config_internal() in order to turn off the CRTC, dropping >> another ref

[PATCH] drm/exynos: fix plane-framebuffer linkage

On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote: > I think fb refcounting in exynos is just plain busted. If you look at > other drivers the only place the refcount framebuffers or backing > storage objects is for pageflips to make sure the memory doesn't go > away while the hw is still

[PATCH] drm/exynos: fix plane-framebuffer linkage

On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim wrote: > It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c. My patch moves that drm_framebuffer_reference() call to the plane function which is called from crtc_mode_set context (and also called in crtc pageflip path),

[PATCH] drm/exynos: fix plane-framebuffer linkage

but rather in the context of updating the plane, which also covers flips. Like omapdrm we also unreference the old framebuffer here. Signed-off-by: Daniel Drake --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 2 files chan

mixer_check_mode drops Exynos5 display modes

Hi Sean, While looking at the following commit I noticed something: commit f041b257a8997c8472a1013e9f252c3e2a1d879e Author: Sean Paul Date: Thu Jan 30 16:19:15 2014 -0500 drm/exynos: Remove exynos_drm_hdmi shim This commit changes how mixer_check_mode() is used. It used to just exclude

exynos-drm HDMI PHY configuration values

Hi Sean, In your commit "drm/exynos: hdmi: support extra resolutions using drm_display_mode timings" you added several more HDMI PHY configs to exynos-drm. Thanks for that. Can you explain where these magic numbers came from? I'm interested in adding 85.5MHz for 1366x768 support. Thanks,

[PATCH] drm/edid: request HDMI underscan by default

ital world, ask the remote display not to overscan by default. Signed-off-by: Daniel Drake --- drivers/gpu/drm/drm_edid.c | 1 + 1 file changed, 1 insertion(+) Replaces the patch titled "video: hdmi: request underscan by default" This version moves the change to the DRM layer, as reque

[PATCH] video: hdmi: request underscan by default

ital world, ask the remote display not to overscan by default. Signed-off-by: Daniel Drake --- drivers/video/hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 9e758a8..6c2d924 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.

[PATCH] drm/exynos: power up HDMI before mixer

eck that the underlying clock gating register has the same value in both cases. Anyway, the mixer clearly has some kind of dependency on the HDMI component, so lets make sure we power that up first. Signed-off-by: Daniel Drake --- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 - 1 file changed

drm_do_probe_ddc_edid ENXIO check too aggressive?

On Wed, Dec 18, 2013 at 2:18 PM, Daniel Drake wrote: > Yes, this looks very similar to the approach I tried earlier. I guess > the patch was written for the same reasons as well. > Sean, any objections to me taking your patch and sending it upstream? > > http://git.chromiu

drm_do_probe_ddc_edid ENXIO check too aggressive?

On Wed, Dec 18, 2013 at 1:58 PM, Daniel Kurtz wrote: > +seanpaul > > I think the problem is that the hdmi irq is really just an undebounced > gpio interrupt, and thus, it is firing way too soon. > The chromium kernel adds an excplicit 1.1 second timer to debounce hpd > between the hdmi hpd-gpio

drm_do_probe_ddc_edid ENXIO check too aggressive?

On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter wrote: > I think we can do it simpler. When you get a hpd interrupt you eventually > call drm_helper_hpd_irq_event which will update all the state and poke > connectors. I'd just create a delay_work which you launch from > hdmi_irq_thread with a 1

drm_do_probe_ddc_edid ENXIO check too aggressive?

On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter wrote: > Have a bit of logic in the exynos ->detect function to re-try a 2nd > round of edid probing after each hdp interrupt if the first one > returns an -ENXIO. Only tricky part is to be careful with edge > detection so that userspace gets all the

drm_do_probe_ddc_edid ENXIO check too aggressive?

On Mon, Dec 16, 2013 at 4:19 PM, Daniel Vetter wrote: > This usually happens if the hpd isn't properly recessed and we start > the i2c transaction while the physical connection hasn't been > established properly yet. If you're _really_ slow and careful you can > probably even break your current

drm_do_probe_ddc_edid ENXIO check too aggressive?

Resend with correct addresses for Eugeni and Chris... On Mon, Dec 16, 2013 at 3:47 PM, Daniel Drake wrote: > Hi, > > I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV. > > When I disconnect and then re-plug the TV, Exynos detects this event > and tries to read the

drm_do_probe_ddc_edid ENXIO check too aggressive?

Hi, I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV. When I disconnect and then re-plug the TV, Exynos detects this event and tries to read the EDID from the DDC over I2C. The DDC does not provide an ACK at this point, so the i2c-s3c2410 driver reports ENXIO, which seems to agree

exynos-drm 1024x768 HDMI output

On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake wrote: > Lets just accept the fact that the first line of the output image is > rendered badly. Specifically, it has 257 black pixels added onto the > end of it. The following rows do not exhibit that problem. > > To accept and ignore

exynos-drm 1024x768 HDMI output

On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake wrote: > What I feel we are missing here is an explanation for why the first > row of pixels is treated differently from the rest. Every value that I > tweak seems to have an effect on the first line (which was rendered > OK) as well as al

exynos-drm 1024x768 HDMI output

On Wed, Dec 4, 2013 at 12:14 PM, Sean Paul wrote: > I assume this is the "1024x768 at 60Hz" mode in drm_edid.c? > > hdisplay = 1024 > hsync_start = 1048 > hsync_end = 1184 > htotal = 1344 > vdisplay = 768 > vsync_start = 771 > vsync_end = 777 > vtotal = 806 That's the one. > I don't have any

exynos-drm 1024x768 HDMI output

Hi, Thanks a lot for this exynos-drm commit: commit 62747fe0ad5169a767987d9009e3398466555cde Author: Sean Paul Date: Tue Jan 15 08:11:08 2013 -0500 drm/exynos: hdmi: support extra resolutions using drm_display_mode timings As you probably know, many people had written off the Exynos4's

DT binding review for Armada display subsystem

On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer wrote: > You don't have to call drm_irq_install(). Both the exynos and i.MX > driver do without it and at least the i.MX driver uses multiple irqs per > drm_device. Good point, thanks. That unblocks that item. >> Secondly, devm. I understand from

Re: DT binding review for Armada display subsystem

On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer s.ha...@pengutronix.de wrote: You don't have to call drm_irq_install(). Both the exynos and i.MX driver do without it and at least the i.MX driver uses multiple irqs per drm_device. Good point, thanks. That unblocks that item. Secondly, devm. I

DT binding review for Armada display subsystem

On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote: > Based on the outcomes of the "Best practice device tree design for display > subsystems" discussion I have drafted a DT binding. Comments much appreciated. > > At a high level, it uses a "super node" as

DT binding review for Armada display subsystem

On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote: > I use my Cubox for daily jobs as a desktop computer. My kernel is a DT > driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel > modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0 > (si5351). Normally,

DT binding review for Armada display subsystem

Hi, Based on the outcomes of the Best practice device tree design for display subsystems discussion I have drafted a DT binding. Comments much appreciated. At a high level, it uses a super node as something for the driver to bind to, needed because there is no clear one device that controls all

Re: DT binding review for Armada display subsystem

On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine moin...@free.fr wrote: I use my Cubox for daily jobs as a desktop computer. My kernel is a DT driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0

DT binding review for Armada display subsystem

On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote: > - I think it is better to keep the names 'lcd' for the memory to dumb panel > sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as > named in the spec. I agree it is worth keeping the spec-defined names, if they

DT binding review for Armada display subsystem

Hi, Based on the outcomes of the "Best practice device tree design for display subsystems" discussion I have drafted a DT binding. Comments much appreciated. At a high level, it uses a "super node" as something for the driver to bind to, needed because there is no clear one device that controls

armada_drm clock selection - try 2

Hi Russell, Here is a new patch which should incorporate all your previous feedback. Now each variant passes clock info to the main driver via a new armada_clk_info structure. A helper function in the core lets each variant find the best clock. As you suggested we first try external (dedicated)

Re: armada_drm clock selection - try 2

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I guess extclk0 and extclk1 should be sufficient for clock names. Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g. extclk0 simultaneously. See below for .is_dedicated in general.

Best practice device tree design for display subsystems/DRM

Hi, I'm looking into implementing devicetree support in armada_drm and would like to better understand the best practice here. Adding DT support for a DRM driver seems to be complicated by the fact that DRM is not hotpluggable - it is not possible for the drm_device to be initialised without an

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote: I will point out that relying on driver probing orders has already been stated by driver model people to be unsafe. This is why I will not adopt such a solution for my driver; it is a bad design. Just to clarify, what

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I am against a super node which contains lcd and dcon/ire nodes. You can enable those devices on a per board basis. We add them to dove.dtsi but disable them by default (status = disabled). The DRM

Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth wrote: > I am against a super node which contains lcd and dcon/ire nodes. You can > enable those devices on a per board basis. We add them to dove.dtsi but > disable them by default (status = "disabled"). > > The DRM driver itself should get a

Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote: > I will point out that relying on driver probing orders has already been > stated by driver model people to be unsafe. This is why I will not > adopt such a solution for my driver; it is a bad design. Just to clarify, what you're objecting

Best practice device tree design for display subsystems/DRM

Hi, I'm looking into implementing devicetree support in armada_drm and would like to better understand the best practice here. Adding DT support for a DRM driver seems to be complicated by the fact that DRM is not "hotpluggable" - it is not possible for the drm_device to be initialised without

armada_drm clock selection - try 2

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth wrote: > I guess "extclk0" and "extclk1" should be sufficient for clock names. > Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g. > extclk0 simultaneously. See below for .is_dedicated in general. Maybe we can find better

armada_drm clock selection - try 2

Hi Russell, Here is a new patch which should incorporate all your previous feedback. Now each variant passes clock info to the main driver via a new armada_clk_info structure. A helper function in the core lets each variant find the best clock. As you suggested we first try external

armada_drm clock selection

On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux wrote: > So, I'd suggest that an initial approach would be something along the > lines of: > - if there is an external clock, can it generate the desired rate? > if yes, use it. > - otherwise, get the clock rate from the internal clocks

armada_drm clock selection

Hi, Thanks for all the clear comments and explanations - I'll address all of that in the next patch. On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux wrote: > Sure... lets add some background info first: the big problem here is the > completely different register layouts for the clock

Re: Armada DRM driver on OLPC XO

On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote: I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 aka PXA2128). After a bit of fighting, I have it running. Could you

Re: armada_drm clock selection

Hi, Thanks for all the clear comments and explanations - I'll address all of that in the next patch. On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Sure... lets add some background info first: the big problem here is the completely different register

Re: armada_drm clock selection

On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: So, I'd suggest that an initial approach would be something along the lines of: - if there is an external clock, can it generate the desired rate? if yes, use it. - otherwise, get the clock rate from the

armada_drm clock selection

Hi Russell, Thanks for pointing me to the most recent version of your driver. Can you comment on the below patch for improved clock handling? It is based on the approach in Jean-Francois Moine's driver, and would serve for the basis of having clock info come from the DT. If you have something

Armada DRM driver on OLPC XO

On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux wrote: > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote: >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 >> aka PXA2128). After a bit of fighting, I have it running. Could you shar

Armada DRM driver on OLPC XO

On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote: > Do you know that there are 2 drm drivers for the Cubox? I posted mine > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html) > before Russell, but I got no return about it yet. I thought there was some

Armada DRM driver on OLPC XO

Hi Russell, Thanks a lot for writing the Armada DRM driver. I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 aka PXA2128). After a bit of fighting, I have it running. Could you share your X driver, or your methodology for testing hardware cursors? I'd like to test your

Armada DRM driver on OLPC XO

Hi Russell, Thanks a lot for writing the Armada DRM driver. I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 aka PXA2128). After a bit of fighting, I have it running. Could you share your X driver, or your methodology for testing hardware cursors? I'd like to test your