Re: [PATCH 1/5] PCI: Recognize Thunderbolt devices

On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote: > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > > --- a/include/linux/pci.h > > +++ b/include/linux/pci.h > > @@ -358,6 +358,7 @@ struct pci_dev { > > unsigned intis_virtfn:1; > > unsigned intreset_fn:1

[Bug 56666] AMD SUMO GPU lockup when launching any heavy 3D application

https://bugs.freedesktop.org/show_bug.cgi?id=5 sonyj changed: What|Removed |Added Depends on||99958 Referenced Bugs: https://bugs.freedeskto

Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race

On Fri, Feb 24, 2017 at 5:45 PM, liuxinliang wrote: > > > On 2017/2/25 9:39, liuxinliang wrote: >> >> Hi John, >> >> The patch seems good to me, except one minus comment. >> Maybe change fb_lock to fbdev_lock would be better. >> >> Thanks, >> -xinliang >> >> On 2017/2/25 9:25, John Stultz wrote: >

Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race

On Fri, Feb 24, 2017 at 5:39 PM, liuxinliang wrote: > Hi John, > > The patch seems good to me, except one minus comment. > Maybe change fb_lock to fbdev_lock would be better. Sure I'll change that too, but I'll wait before next week before resending to see if anyone else has feedback. thanks -jo

[RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race

In some cases I've been seeing a race where two framebuffers would be initialized, as kirin_fbdev_output_poll_changed() might get called quickly in succession, resulting in the initialization happening twice. This could cause the system to boot up with a blank screen. This patch adds a simple mute

[Bug 99955] [r600g] GPU load always displayed at 100% with GALLIUM_HUD=GPU-load

https://bugs.freedesktop.org/show_bug.cgi?id=99955 Bug ID: 99955 Summary: [r600g] GPU load always displayed at 100% with GALLIUM_HUD=GPU-load Product: Mesa Version: git Hardware: All OS: Linux (All)

[PATCH 3/5] drm/amd/amdgpu: Allow HDMI Stereo 3D (non-DC) over DVI connector

Signed-off-by: Jeff Smith --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index 5a40ef4..3b042e7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_c

[PATCH 5/5] drm/amd/display: Allow HDMI capabilities over DVI connector (DC)

Signed-off-by: Jeff Smith --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 2b92939..168f260 100644 --- a/drivers/gpu/drm/

[PATCH 4/5] drm/amd/display: Add HDMI Stereo 3D (DC) support

Signed-off-by: Jeff Smith --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 32 -- .../display/dc/dce110/dce110_timing_generator.c| 4 --- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c b/dr

[PATCH 1/5] drm/amd/amdgpu: HDMI Stereo 3D (non-DC) support requires enabled audio

Signed-off-by: Jeff Smith --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index 8d1cf2d..b487aa0 100644 --- a/drivers/

[PATCH 2/5] drm/amd/amdgpu: Add HDMI Stereo 3D (non-DC) support

Signed-off-by: Jeff Smith --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 5 ++ drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 27 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 86 -- 4 files chang

[PATCH 0/5] drm/amd: HDMI Stereo 3D support

Hello all, This set now adds support for HDMI Stereo 3D for both DC and non-DC code paths. The non-DC code requires unblocking HDMI audio, which is done in the first patch. I have also split out the portions of the code that allow the stereo 3D to work on a HDMI sink attached to a DVI source. R

Re: [RFC][PATCH] drm: kirin: Add a mutex to avoid fb initialization race

On Thu, Feb 23, 2017 at 5:55 PM, liuxinliang wrote: > Hi John, > > On 2017/2/23 8:56, John Stultz wrote: >> >> In some cases I've been seeing a race where two framebuffers >> would be initialized, as kirin_fbdev_output_poll_changed() >> might get called quickly in succession, resulting in the fb >

Re: [PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo

On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner wrote: > An external Thunderbolt GPU can neither drive the laptop's panel nor be > powered off by the platform, so there's no point in registering it with > vga_switcheroo. > In fact, when the external GPU is runtime suspended, > vga_switcheroo will c

[Bug 99950] Add cl_khr_int64_base_atomics to Clover and make it work on radeonsi

https://bugs.freedesktop.org/show_bug.cgi?id=99950 --- Comment #1 from Jan Vesely --- This should be rather straightforward: add wrappers to libclc (use generic/lib/atomic/atomic_impl.ll as example) add piglit tests -- You are receiving this mail because: You are the assignee for the bug.__

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||99950 Referenced Bugs: https://bugs.f

[Bug 99950] Add cl_khr_int64_base_atomics to Clover and make it work on radeonsi

https://bugs.freedesktop.org/show_bug.cgi?id=99950 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.f

[Bug 99950] Add cl_khr_int64_base_atomics to Clover and make it work on radeonsi

https://bugs.freedesktop.org/show_bug.cgi?id=99950 Bug ID: 99950 Summary: Add cl_khr_int64_base_atomics to Clover and make it work on radeonsi Product: Mesa Version: git Hardware: Other OS: All S

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

Hi Daniel, We have ACKs on the userspace design from both Adams and Eric. Is this enough to merge the kernel patches? I spoke to Eric briefly about this and he gave me a verbal r-b as well. He said the userspace patches cant get merged unless DRM patches are merged. So what should be some of our

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

On Fri, Feb 24, 2017 at 11:06:03AM -0800, Sinclair Yeh wrote: > Hi Oyvind, > > Thanks for looking at this. > > At this moment, I don't really see a benefit one way or anther, so > I am going to stick with the macro version for now, changing the one > remaining module_param_named() you mentioned t

Re: [git pull] drm for v4.11 - main pull request

On 02/24/2017 01:01 AM, Dave Airlie wrote: > Hi Linus, > > This is the main drm pull request for v4.11. Dave, I was sort of expecting the vmwgfx control node removal workaround to be in here. We're sort of blocked on it. Could we have it sent for rc1? Do you want me to resend the patch with the rb

[PATCH 2/5] apple-gmux: Don't switch external DP port on 2011+ MacBook Pros

On MacBook Pros introduced 2011 and onward, external DP ports are combined DP/Thunderbolt ports that are no longer fully switchable between GPUs, they can only be driven by the discrete GPU. More specifically, the Main Link pins (which transport the actual video and audio streams) are soldered to

[PATCH 5/5] drm/amdgpu: Don't register Thunderbolt eGPU with vga_switcheroo

An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. C

[PATCH 4/5] drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo

An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. C

[PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo

An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. C

[PATCH 1/5] PCI: Recognize Thunderbolt devices

Detect on probe whether a PCI device is part of a Thunderbolt controller. Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 on such devices. Detect presence of this VSEC and cache it in a newly added is_thunderbolt bit in struct pci_dev. Add a helper to check whether a given

[PATCH 0/5] Thunderbolt GPU fixes

Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo: Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times total since May 2016. With luck it may be in ack-able shape now. Patch [2/5] amends

[Bug 99136] Blood Effects Total War: Warhammer

https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #35 from siyia --- ipload fails at 51% the file is 2.3gb is there an upload limit? On 02/24/2017 12:32 AM, bugzilla-dae...@freedesktop.org wrote: > > *Comment # 34 > on bug 9

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

Hi Oyvind, Thanks for looking at this. At this moment, I don't really see a benefit one way or anther, so I am going to stick with the macro version for now, changing the one remaining module_param_named() you mentioned to using the macros to keep things consistent. If one day we have a paramter

[Bug 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=99387 --- Comment #19 from Luya Tshimbalanga --- Following up this week with current patched kernel 4.9.11 from Mystro256 COPR repository based on Alex's branch. The South Island part of hybrid GPU.e. Hainan and its derivative (Sun PRO) runs smoothly

[GIT PULL] fbdev changes for v4.11

Hi Linus, Please pull fbdev changes for v4.11. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics The following changes since commit 4dcd19bfabaee8f9f4bcf203afba09b98ccbaf76: video: fbdev: cobalt_lcdfb: Handle return NULL error from devm_ioremap (20

Re: [PATCH v2 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 24, 2017 at 10:14 AM, Benjamin Gaignard wrote: > Lots of calls to of_platform_populate() are not unbalanced by a call > to of_platform_depopulate(). This create issues while drivers are > bind/unbind. > > In way to solve those issues is to add devm_of_platform_populate() > which will c

[PATCH v2 2/2] drm: sti: make driver use devm_of_platform_populate()

This make sure that of_platform_depopulate() is called if an error occur in probe after populating the date from the device tree. Signed-off-by: Benjamin Gaignard --- version 2: - use simplified devm_of_platform_populate function prototype drivers/gpu/drm/sti/sti_drv.c | 3 +-- 1 file changed,

[PATCH v2 1/2] of: add devm_ functions for populate and depopulate

Lots of calls to of_platform_populate() are not unbalanced by a call to of_platform_depopulate(). This create issues while drivers are bind/unbind. In way to solve those issues is to add devm_of_platform_populate() which will call of_platform_depopulate() when the device is unbound from the bus.

[PATCH v2 0/2] Introduce devm_of_platform_populate() helper

version 2: - simplify function prototype to only keep device as parameter - rebased on v4.10 Lots of calls to of_platform_populate() are not unbalanced by a call to of_platform_depopulate(). This create issues while drivers are bind/unbind. In way to solve those issues is to add devm_of_platf

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 24, 2017 at 9:26 AM, Benjamin Gaignard wrote: > 2017-02-24 16:20 GMT+01:00 Rob Herring : >> On Fri, Feb 24, 2017 at 9:13 AM, Benjamin Gaignard >> wrote: >>> 2017-02-24 15:17 GMT+01:00 Rob Herring : On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard wrote: > Lost of call

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 24, 2017 at 9:13 AM, Benjamin Gaignard wrote: > 2017-02-24 15:17 GMT+01:00 Rob Herring : >> On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard >> wrote: >>> Lost of calls to of_platform_populate() are not unbalanced by a call >> >> s/Lost/Lots/ >> >>> to of_platform_depopulate(). This

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

2017-02-24 16:20 GMT+01:00 Rob Herring : > On Fri, Feb 24, 2017 at 9:13 AM, Benjamin Gaignard > wrote: >> 2017-02-24 15:17 GMT+01:00 Rob Herring : >>> On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard >>> wrote: Lost of calls to of_platform_populate() are not unbalanced by a call >>> >>> s/

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

2017-02-24 15:17 GMT+01:00 Rob Herring : > On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard > wrote: >> Lost of calls to of_platform_populate() are not unbalanced by a call > > s/Lost/Lots/ > >> to of_platform_depopulate(). This create issues while drivers are >> bind/unbind. >> >> In way to sol

Re: [PATCH v1 1/2] of: add devm_ functions for populate and depopulate

On Fri, Feb 17, 2017 at 8:31 AM, Benjamin Gaignard wrote: > Lost of calls to of_platform_populate() are not unbalanced by a call s/Lost/Lots/ > to of_platform_depopulate(). This create issues while drivers are > bind/unbind. > > In way to solve those issues is to add devm_of_platform_populate()

Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

On Fri, Feb 24, 2017 at 2:18 AM, Yannick FERTRE wrote: > > > On 02/21/2017 03:07 PM, Rob Herring wrote: >> On Mon, Feb 20, 2017 at 5:01 AM, Yannick FERTRE >> wrote: >>> >>> >>> On 02/16/2017 03:34 AM, Rob Herring wrote: On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote: > S

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi wrote: > Alexandre Belloni wrote: >> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: The device tree is a representation of the hardware itself. The state of the driver support doesn't change the hardware you're running on, just l

Re: [PATCH] drm/doc: Fix up some kms function names

On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote: > A couple of the kms functions didn't have the correct/newest names. > This prevented them to be identified as refs in the html doc. > > Signed-off-by: Archit Taneja Thanks! Reviewed-by: Eric Engestrom Tested-by: Eric Engestrom Th

Re: [PATCH 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

On Wed, Feb 22, 2017 at 2:09 PM, Maxime Ripard wrote: > Hi, > > On Wed, Feb 22, 2017 at 11:23:06PM +0800, Icenowy Zheng wrote: >> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes >> in a new "Display Engine" (mixers instead of old backends and >> frontends). >> >> Add suppo

Re: [PATCH 2/3] drm/vc4: Add HDMI audio support

Hi Eric, On Tue, 7 Feb 2017 13:07:02 -0800 Eric Anholt wrote: > +static int vc4_hdmi_audio_init(struct vc4_hdmi *hdmi) > +{ > + struct snd_soc_dai_link *dai_link = &hdmi->audio.link; > + struct snd_soc_card *card = &hdmi->audio.card; > + struct device *dev = &hdmi->pdev->dev; > +

Re: KMS backlight ABI proposition

On 24/02/17 12:44, Hans de Goede wrote: Hi, On 24-02-17 11:23, Martin Peres wrote: On 24/02/17 11:59, Hans de Goede wrote: Hi, On 24-02-17 10:48, Hans de Goede wrote: Hi, On 24-02-17 10:46, Hans de Goede wrote: Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede

[PATCH v4 11/23] drm/rockchip: dw-mipi-dsi: prepare panel after phy init

Some panels need to be configured with commands sent over the MIPI link, which they will do in the prepare hook. Call this after the PHY has been initialized so that we are able to send commands to the panel. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: -

[PATCH v4 06/23] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

As a side-effect of this, encode the endianness explicitly rather than casting a u16. Signed-off-by: John Keeping --- v4: - Introduce "data" variable to avoid confusion around the masking in GEN_HDATA() v3: - Add Chris' Reviewed-by Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1

[PATCH v4 17/23] drm/rockchip: dw-mipi-dsi: improve PLL configuration

The multiplication ratio for the PLL is required to be even due to the use of a "by 2 pre-scaler". Currently we are likely to end up with an odd multiplier even though there is an equivalent set of parameters with an even multiplier. For example, using the 324MHz bit rate with a reference clock o

[PATCH v4 08/23] drm/rockchip: dw-mipi-dsi: respect message flags

Instead of always sending commands in LP mode, respect the MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also request acks if MIPI_DSI_MSG_REQ_ACK is set. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chri

[PATCH v4 15/23] drm/rockchip: dw-mipi-dsi: configure PHY before enabling

The bias, bandgap and PLL should all be configured before we enable them. Signed-off-by: John Keeping Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Squash together two patches that both affect initialization order of the PHY Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi

[PATCH v4 19/23] drm/rockchip: dw-mipi-dsi: use positive check for N{H, V}SYNC

This matches other drivers. Signed-off-by: John Keeping Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by Unchanged in v3 Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi

[PATCH v4 09/23] drm/rockchip: dw-mipi-dsi: only request HS clock when required

Requesting the HS clock from the PHY before we initialize it causes an invalid signal to be sent out since the input clock is not yet configured. The PHY databook suggests only asserting this signal when performing HS transfers, so let's do that. Signed-off-by: John Keeping Reviewed-by: Chris Zh

[PATCH v4 02/23] drm/rockchip: dw-mipi-dsi: pass mode in where needed

This shows that we only use the mode from the enable function and prepares us to remove the "mode" field and the mode_set hook in the next commit. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewed-by New in v2

[PATCH v4 07/23] drm/rockchip: dw-mipi-dsi: include bad value in error message

As an aid to debugging. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewed-by Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dri

[PATCH v4 23/23] drm/rockchip: dw-mipi-dsi: add reset control

In order to fully reset the state of the MIPI controller we must assert this reset. This is slightly more complicated than it could be in order to maintain compatibility with device trees that do not specify the reset property. Signed-off-by: John Keeping Reviewed-by: Chris Zhong --- v4: - Fix

[PATCH v4 21/23] drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded

This ensures that the output resolution is known before fbcon loads. mipi_dsi_host_register() is moved above dw_mipi_dsi_register() to simplify error cleanup since the order of these operations does not matter. Signed-off-by: John Keeping --- v4: - Use "return 0" to separate normal code flow from

[PATCH v4 14/23] drm/rockchip: dw-mipi-dsi: ensure PHY is reset

Also don't power up the DSI host at this point since this is not necessary in order to configure the PHY and we do so later when selecting video or command mode. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewe

[PATCH v4 22/23] drm/rockchip: dw-mipi-dsi: support non-burst modes

Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewed-by Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers

[PATCH v4 16/23] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

These values are specified as constant time periods but the PHY configuration is in terms of the current lane byte clock so using constant values guarantees that the timings will be outside the specification with some display configurations. Derive the necessary configuration from the byte clock i

[PATCH v4 10/23] drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned

By dereferencing the MIPI command buffer as a u32* we rely on it being correctly aligned on ARM, but this may not be the case. Copy it into a stack variable that will be correctly aligned. Signed-off-by: John Keeping Reviewed-by: Chris Zhong --- v3: - Add Chris' Reviewed-by Unchanged in v2 ---

[PATCH v4 18/23] drm/rockchip: dw-mipi-dsi: use specific poll helper

As the documentation for readx_poll_timeout says, we want to use the specialized macro for readl rather than using the generic version directly. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewed-by Unchanged in

[PATCH v4 12/23] drm/rockchip: dw-mipi-dsi: allow commands in panel_disable

Panel drivers may want to sent commands during the disable function, for example MIPI_DCS_SET_DISPLAY_OFF before the video signal ends. In order to send commands we need to write to registers, so pclk must be enabled. While changing this, remove the unnecessary code after the panel unprepare call

[PATCH v4 00/23] drm/rockchip: MIPI fixes & improvements

This version is mostly small changes in response to review comments from Sean and Chris, the details are in the individual patches. I decided to drop the final patch which adds support for MIPI read commands because I'm not using that feature now and I can't easily test it. It's on the list if an

[PATCH v4 03/23] drm/rockchip: dw-mipi-dsi: remove mode_set hook

This is not needed since we can access the mode via the CRTC from the enable hook. Also remove the "mode" field that is no longer used. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewed-by New in v2 --- drive

[PATCH v4 20/23] drm/rockchip: vop: test for P{H,V}SYNC

When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the internal connection but these flags are meaningless for DSI panels. Switch the test so that we do not set the P{H,V}SYNC bits unless the mode requires it. Signed-off-by: John Keeping Reviewed-by: Mark Yao Reviewed-by: Sean

[PATCH v4 13/23] drm/rockchip: dw-mipi-dsi: fix escape clock rate

This clock rate is derived from the PHY PLL, so it should be calculated dynamically. This calculation is the same as that used by the vendor kernel and ensures that the escape clock runs at <20MHz as required by the MIPI specification. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Review

[PATCH v4 01/23] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the enable function, which is the atomic version of "commit" so let's use the enable hook rather than commit while we're at it. Signed-off-by: John Keeping Reviewed-

[PATCH v4 04/23] drm/rockchip: dw-mipi-dsi: fix command header writes

In a couple of places here we use "val" for the value that is about to be written to a register but then reuse the same variable for the value of a status register before we get around to writing it. Rename the value to be written to so that we write the value we intend to and not what we have jus

[PATCH v4 05/23] drm/rockchip: dw-mipi-dsi: fix generic packet status check

We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits are set so we can't just check "val & mask" because that will be true if either bit is set. Signed-off-by: John Keeping Reviewed-by: Chris Zhong Reviewed-by: Sean Paul --- v4: - Add Sean's Reviewed-by v3: - Add Chris' Reviewe

Re: KMS backlight ABI proposition

On Fri, 24 Feb 2017, Daniel Thompson wrote: > On 24/02/17 08:43, Jani Nikula wrote: > >> - "Some PWM based backlight allow adjusting the PWM modulation > >> frequency." you don't need a motivation for *why* I would want to > >> change the mod freq on the fly, actually in my experience you > >>

Re: KMS backlight ABI proposition

On 24/02/17 08:43, Jani Nikula wrote: >> - "Some PWM based backlight allow adjusting the PWM modulation >> frequency." you don't need a motivation for *why* I would want to >> change the mod freq on the fly, actually in my experience you >> shouldn't since this can lead to flickery backlights. > >

Re: [PATCH v3 1/2] drm_fourcc: Add new P010, P016 video format

On Thu, Feb 23, 2017 at 03:58:19PM -0800, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per > channel video format. Rockchip's vop support this video format(little > endian only) as the input video format. > > P012 is a p

Re: KMS backlight ABI proposition

Hi, On 24-02-17 11:23, Martin Peres wrote: On 24/02/17 11:59, Hans de Goede wrote: Hi, On 24-02-17 10:48, Hans de Goede wrote: Hi, On 24-02-17 10:46, Hans de Goede wrote: Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede wrote: On 24-02-17 09:43, Jani Nikula w

Re: KMS backlight ABI proposition

On 24/02/17 11:59, Hans de Goede wrote: Hi, On 24-02-17 10:48, Hans de Goede wrote: Hi, On 24-02-17 10:46, Hans de Goede wrote: Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede wrote: On 24-02-17 09:43, Jani Nikula wrote: I don't think we have any good ideas h

Re: KMS backlight ABI proposition

Hi, On 24-02-17 10:48, Hans de Goede wrote: Hi, On 24-02-17 10:46, Hans de Goede wrote: Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede wrote: On 24-02-17 09:43, Jani Nikula wrote: I don't think we have any good ideas how to solve the property max changing on

Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

+CC Thierry, as the drm_panel maintainer. Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul: > On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote: > > Hello, > > > > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote: > > > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard

Re: KMS backlight ABI proposition

Hi, On 24-02-17 10:46, Hans de Goede wrote: Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede wrote: On 24-02-17 09:43, Jani Nikula wrote: I don't think we have any good ideas how to solve the property max changing on the fly. But based on the discussion so far, i

Re: KMS backlight ABI proposition

Hi, On 24-02-17 10:34, Jani Nikula wrote: On Fri, 24 Feb 2017, Hans de Goede wrote: On 24-02-17 09:43, Jani Nikula wrote: I don't think we have any good ideas how to solve the property max changing on the fly. But based on the discussion so far, it's starting to look like we'll need to study

Re: KMS backlight ABI proposition

On Fri, 24 Feb 2017, Hans de Goede wrote: > On 24-02-17 09:43, Jani Nikula wrote: >> I don't think we have any good ideas how to solve the property max >> changing on the fly. But based on the discussion so far, it's starting >> to look like we'll need to study that more thoroughly. > > As I menti

Re: [git pull] drm for v4.11 - main pull request

Hi Linus, Yeah this went wrong. My experience with anything Kconfig (whether new drivers or anything else) is that it takes 0day a few days to 1-2 weeks to crunch through all the combos. I guess we could block new drivers pulls like we already do with regular feature pulls in drm (e.g. drm-intel.g

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #9 from thedribbleo...@gmail.com --- (In reply to Ernst Sjöstrand from comment #8) > R600_DEBUG=sisched? One of the first things I tried. It makes no difference. -- You are receiving this mail because: You are the assignee for the b

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #8 from Ernst Sjöstrand --- R600_DEBUG=sisched? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://

Re: KMS backlight ABI proposition

Hi, On 24-02-17 09:43, Jani Nikula wrote: On Thu, 23 Feb 2017, Stéphane Marchesin wrote: On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula wrote: On Wed, 22 Feb 2017, Stéphane Marchesin wrote: On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres wrote: If the KMS property exposes a fixed number of

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #7 from Maciej Cencora --- FWIW, I get same artifacts as well. My setup: - R9 280 TAHITI GCN1.0 (1002:679a) - Mesa 17.1~git1702240730.ccb70d~gd~z (Oibaf PPA) - LLVM 4.0~+rc2-1 -- You are receiving this mail because: You are the

Re: [PATCH 04/12] drm/ast: Remove spurrious include

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley > --- > drivers/gpu/drm/ast/ast_main.c | 2 -- > 1 file changed, 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.

Re: [PATCH 07/12] drm/ast: Fixed vram size incorrect issue on POWER

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" > > The default value of VGA scratch may incorrect. > Should initial h/w before get vram info. > > Signed-off-by: Y.C. Chen Acked-by: Joel Stanley > --- > drivers/gpu/drm/ast/ast_main.c | 6 +++--- > drivers/g

Re: [PATCH 08/12] drm/ast: Factor mmc_test code in POST code

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > There's a some duplication for what's essentially copies of > two loops, so factor it. The upcoming AST2500 POST code adds > more of them. Also cleanup return types for the test functions, > most of them return a boolean, some return

Re: [PATCH 09/12] drm/ast: Rename ast_init_dram_2300 to ast_post_chip_2300

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > The function does more than initializing the DRAM and in turns > calls other functions to do the actual init. This will keeping > things more consistent with the upcoming AST2500 POST code. > > Signed-off-by: Benjamin Herrenschmidt

Re: [PATCH v5 2/12] drm/ast: Handle configuration without P2A bridge

On Fri, Feb 24, 2017 at 1:11 PM, Benjamin Herrenschmidt wrote: > The ast driver configures a window to enable access into BMC > memory space in order to read some configuration registers. > > If this window is disabled, which it can be from the BMC side, > the ast driver can't function. > > Closin

Re: [PATCH 10/12] drm/ast: POST code for the new AST2500

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" > > This is used when the BMC isn't running any code and thus has > to be initialized by the host. > > The code originates from Aspeed (Y.C. Chen) and has been cleaned > up for coding style purposes by BenH. > > Si

Re: [PATCH 05/12] drm/ast: Fix calculation of MCLK

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > Some braces were missing causing an incorrect calculation. > > Y.C. Chen from Aspeed provided me with the right formula > which I tested on AST2400 and 2500. Y. C. Chen, can you point out this calculation in the programming guide?

Re: [PATCH 06/12] drm/ast: Base support for AST2500

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" > > Add detection and mode setting updates for AST2500 generation chip, > code originally from Aspeed and slightly reworked for coding style > mostly by Ben. This doesn't contain the BMC DRAM POST code which > is i

Re: [PATCH 01/12] drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" > > The current POST code for the AST2300/2400 family doesn't work properly > if the chip hasn't been initialized previously by either the BMC own FW > or the VBIOS. This fixes it. > > Signed-off-by: Y.C. Chen > S

Re: [PATCH 12/12] drm/ast: Call open_key before enable_mmio in POST code

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" > > open_key enables access the registers used by enable_mmio > > Signed-off-by: Y.C. Chen > Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley > --- > drivers/gpu/drm/ast/ast_post.c | 2 +- > 1 fil

Re: [PATCH 03/12] drm/ast: const'ify mode setting tables

On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt wrote: > And fix some comment alignment & space/tabs while at it > > Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley > --- > drivers/gpu/drm/ast/ast_drv.h| 4 +- > drivers/gpu/drm/ast/ast_mode.c | 8 +-- > drivers/

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote: > Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]: > > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > > wrote: > > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > > > > Pandiyan, Dhinakaran schreef op d

[PATCH] drm: vc4: Don't wait for vblank when updating the cursor

Commonly used desktop environments such as xfce4 and gnome on debian sid can flood the graphics drivers with cursor updates. Because the current implementation is waiting for a vblank between cursor updates, this will cause the display to hang for a long time since a typical refresh rate is only 6

Re: [PATCH 05/12] drm/ast: Fix calculation of MCLK

On Fri, Feb 24, 2017 at 1:08 PM, Benjamin Herrenschmidt wrote: > On Fri, 2017-02-24 at 12:54 +1030, Joel Stanley wrote: >> On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt >> wrote: >> > Some braces were missing causing an incorrect calculation. >> > >> > Y.C. Chen from Aspeed provided me

Re: [RFC][PATCH] drm: kirin: Add a mutex to avoid fb initialization race

Hi John, On 2017/2/23 8:56, John Stultz wrote: In some cases I've been seeing a race where two framebuffers would be initialized, as kirin_fbdev_output_poll_changed() might get called quickly in succession, resulting in the fb initialization happening twice. This could cause the system I might

  1   2   >