Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

Hi Everyone, On Wed, May 10, 2017 at 9:24 AM, Inki Dae wrote: > > > 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글: >> Hi Marek, >> >> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote: >>> Hi Laurent, >>> >>> On 2017-04-20 12:25, Laurent Pinchart wrote: Hi

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 --- Comment #2 from Francesco Turco --- Created attachment 131291 --> https://bugs.freedesktop.org/attachment.cgi?id=131291=edit gdb backtrace (full version) I used the "thread apply all bt full" gdb command. -- You are

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 --- Comment #1 from Francesco Turco --- Created attachment 131290 --> https://bugs.freedesktop.org/attachment.cgi?id=131290=edit gdb backtrace (basic version) I used the "bt" gdb command. -- You are receiving this mail

[Bug 100984] QupZilla crashes at startup after mesa upgrade

https://bugs.freedesktop.org/show_bug.cgi?id=100984 Bug ID: 100984 Summary: QupZilla crashes at startup after mesa upgrade Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: All Status: NEW

[Bug 100983] qupzilla

https://bugs.freedesktop.org/show_bug.cgi?id=100983 Francesco Turco changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/9/2017 8:58 PM, Ville Syrjälä wrote: On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 10:39 PM, Ville Syrjälä wrote: On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 9:54

[PATCH] drm: mediatek: change the variable type of rdma threshold

For some greater resolution, the rdma threshold variable will overflow. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글: > Hi Marek, > > On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote: >> Hi Laurent, >> >> On 2017-04-20 12:25, Laurent Pinchart wrote: >>> Hi Marek, >>> >>> (CC'ing Sakari Ailus) >>> >>> Thank you for the patches. >>> >>> On Thursday 20

Re: [PATCH RESEND 3/4] drm/exynos: Merge pre/postclose hooks

Hi Daniel, 2017년 05월 08일 17:26에 Daniel Vetter 이(가) 쓴 글: > Again no apparent explanation for the split except hysterical raisins. > Merging them also makes it a bit more obviuos what's going on wrt the > runtime pm refdancing. I had requested git-pull,

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

> > Just please make sure that one (user configurable/opt-in if necessary) > policy from the beginning is to allow leasing out any output to > applications, not just HMDs. My type of scientific/medical applications > would benefit as soon as it has the option to get a drm lease for a given >

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Wed, Mar 22, 2017 at 5:01 PM, Philipp Zabel wrote: > On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote: > > > > Similar to the previous commit, convert drivers open coding OF graph > > parsing to use drm_of_find_panel_or_bridge instead. > > > > This changes some

Re: [PATCH 0/3] GPU-DRM-Radeon: Fine-tuning for three function implementations

On 03/05/17 09:46 PM, Christian König wrote: > Am 02.05.2017 um 22:04 schrieb SF Markus Elfring: >> From: Markus Elfring >> Date: Tue, 2 May 2017 22:00:02 +0200 >> >> Three update suggestions were taken into account >> from static source code analysis. >> >> Markus

[PATCH v2 8/8] drm: arc: Use crtc->mode_valid() callback

Now that we have a callback to check if crtc supports a given mode we can use it in arcpgu so that we restrict the number of probbed modes to the ones we can actually display. This is specially useful because arcpgu crtc is responsible to set a clock value in the commit() stage but unfortunatelly

[PATCH v6 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

Read desired PWM frequency from panel vbt and calculate the value for divider in DPCD address 0x724 and 0x728 to have as many bits as possible for PWM duty cyle for granularity of brightness adjustment while the frequency is still within 25% of the desired frequency. Signed-off-by: Puthikorn

[PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

There are some panel that (1) does not support display backlight enable via AUX (2) support display backlight adjustment via AUX (3) support display backlight enable via eDP BL_ENABLE pin The current driver required that (1) must be support to enable (2). This patch drops that requirement.

[PATCH v6 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

intel_dp_aux_backlight driver should check for the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote: > Thanks for reporting this. Can you confirm the following patch prevents > the issue? Nope, it still gripes. [ 43.910362] BUG: sleeping function called from invalid context at mm/slab.h:432 [ 43.910955] in_atomic(): 1,

[PATCH v6 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

intel_dp_aux_enable_backlight() assumed that the register BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. This patch fixed that by handling all cases of that register. Signed-off-by: Puthikorn Voravootivat

[PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

This changes the connector probe helper function to use the new encoder->mode_valid() and crtc->mode_valid() helper callbacks to validate the modes. The new callbacks are optional so the behaviour remains the same if they are not implemented. If they are, then the code loops through all the

[PATCH v2 2/8] drm: Add drm_crtc_mode_valid()

Add a new helper to call crtc->mode_valid callback. Suggested-by: Ville Syrjälä Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä

[PATCH v3 0/2] vsp1 writeback prototype

This short series extends the VSP1 on the RCar platforms to allow creating a V4L2 video node on display pipelines where the hardware allows writing to memory simultaneously. In this instance, the hardware restricts the output to match the display size (no rescaling) but does allow pixel format

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

> How is backlight enabled in this case? Using eDP BL_ENABLE pin On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com> wrote: > On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > > There are some panel that > > (1) does not support display

[PATCH v3 1/2] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to the DU continuously") The DU output mode does not rely on frames being supplied on the WPF as its pipeline is supplied from DRM. For the upcoming WPF writeback functionality, we will choose to enable writeback mode if there is

[PATCH] gpu: drm: gma500: remove dead code

Local variable use_gct is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID: 145690 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 51

[PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

Add option to allow choosing how to adjust brightness if panel supports both PWM pin and AUX channel. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/i915_params.c| 8 +--- drivers/gpu/drm/i915/i915_params.h| 2 +-

[PATCH v6 7/9] drm/i915: Restore brightness level in aux backlight driver

Some panel will default to zero brightness when turning the panel off and on again. This patch restores last brightness level back when panel is turning back on. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan ---

[PATCH v2 0/8] Introduce new mode validation callbacks

This series is a follow up from the discussion at [1]. We start by introducing crtc->mode_valid(), encoder->mode_valid() and bridge->mode_valid() callbacks which will be used in followup patches. We proceed by introducing new helpers to call this new callbacks at 2/8, 3/8 and 4/8. Next, at 5/8

[PATCH] gpu: drm: gma500: remove dead code

Local variable pipe is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID: 201351 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 21 ++--- 1

[PATCH v6 5/9] drm/i915: Set backlight mode before enable backlight

We should set backlight mode register before set register to enable the backlight. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++-- 1 file changed, 2

[PATCH v2 3/8] drm: Add drm_encoder_mode_valid()

Add a new helper to call encoder->mode_valid callback. Suggested-by: Ville Syrjälä Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä

[PATCH v6 0/9] Enhancement to intel_dp_aux_backlight driver

This patch set contain 9 patches. - First five patches fix bug in the driver and allow choosing which way to adjust brightness if both PWM pin and AUX are supported - Next patch adds enable DBC by default - Next patch makes the driver restore last brightness level after turning display off and

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

Looks good for Cygnus. On 17-05-09 11:15 AM, Eric Anholt wrote: With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" to let the module get built on a cygnus-only kernel. However, I anticipate having a port for Kona soon, so just present the module on all of BCM. v2: Keep

[PATCH v6 6/9] drm/i915: Support dynamic backlight via DPCD register

This patch enables dynamic backlight by default for eDP panel that supports this feature via DPCD register and set minimum / maximum brightness to 0% and 100% of the normal brightness. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c |

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

On 05/09/2017 04:16 PM, Eric Anholt wrote: > Florian Fainelli writes: > >> On 05/09/2017 11:15 AM, Eric Anholt wrote: >>> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" >>> to let the module get built on a cygnus-only kernel. However, I >>> anticipate

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote: > "Ong, Hean Loong" writes: > > > > > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote: > > > > > > "Ong, Hean Loong" writes: > > > > > > > > > > > > > > > On Wed, 2017-05-03 at

[PATCH v2 4/8] drm: Add drm_connector_mode_valid()

Add a new helper to call connector->mode_valid callback. Suggested-by: Ville Syrjälä Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen [170509 04:56]: > On 08/05/17 20:07, Tony Lindgren wrote: > > * Laurent Pinchart [170508 04:36]: > >> The next step is to remove the omapdss platform driver (for the virtual > >> omapdss platform device, also known as

[PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

When the VSP1 is used in an active display pipeline, the output of the WPF can supply the LIF entity directly and simultaneously write to memory. Support this functionality in the VSP1 driver, by extending the WPF source pads, and establishing a V4L2 video device node connected to the new source.

[PATCH v6 8/9] drm: Add definition for eDP backlight frequency

This patch adds the following definition - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap register which only use bit 0:4 - Base frequency (27 MHz) for backlight PWM frequency generator. Signed-off-by: Puthikorn Voravootivat --- include/drm/drm_dp_helper.h | 2 ++ 1

[PATCH v2 1/8] drm: Add crtc/encoder/bridge->mode_valid() callbacks

This adds a new callback to crtc, encoder and bridge helper functions called mode_valid(). This callback shall be implemented if the corresponding component has some sort of restriction in the modes that can be displayed. A NULL callback implicates that the component can display all the modes. We

[PATCH v2 7/8] drm: Use mode_valid() in atomic modeset

This patches makes use of the new mode_valid() callbacks introduced previously to validate the full video pipeline when modesetting. This calls the connector->mode_valid(), encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() so that we can make sure that the mode will be accepted

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

Hi, On Tue, May 09, 2017 at 03:10:40PM +0300, Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Hello, > > > > This patch series is a second, extended version of the code previously > > posted > > as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code". > > As

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

On 05/09/2017 11:15 AM, Eric Anholt wrote: > With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" > to let the module get built on a cygnus-only kernel. However, I > anticipate having a port for Kona soon, so just present the module on > all of BCM. > > v2: Keep allowing

[PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()

Introduce a new helper function which calls mode_valid() callback for all bridges in an encoder chain. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä Cc:

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

Florian Fainelli writes: > On 05/09/2017 11:15 AM, Eric Anholt wrote: >> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" >> to let the module get built on a cygnus-only kernel. However, I >> anticipate having a port for Kona soon, so just present the

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Tue, May 9, 2017 at 9:28 AM, Leonard Crestez wrote: > On Wed, Mar 22, 2017 at 5:01 PM, Philipp Zabel wrote: >> On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote: >> > >> > Similar to the previous commit, convert drivers open coding OF graph

Re: [PATCH 1/6 v2] drm/omap: add new connector types

Hi Tomi, Thank you for the patch. On Tuesday 09 May 2017 10:16:27 Tomi Valkeinen wrote: > We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs > because there has not been a proper connector type for them. > > We now have connector type for DPI so let's take it into use. At the

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

Hi Tomi, On Wednesday 10 May 2017 01:24:52 Laurent Pinchart wrote: > On Tuesday 09 May 2017 12:23:13 Tomi Valkeinen wrote: > > On 08/05/17 14:32, Laurent Pinchart wrote: > > > The DPI code only needs to differentiate between major OMAP revisions, > > > which can be obtained from the DSS

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

Hi Tomi, On Tuesday 09 May 2017 12:23:13 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > The DPI code only needs to differentiate between major OMAP revisions, > > which can be obtained from the DSS compatible string. Replace the OMAP > > SoC model checks to prepare for

Re: [rfc] drm sync objects (search for spock)

On Wed, Apr 26, 2017 at 7:57 AM, Christian König wrote: > Am 26.04.2017 um 11:57 schrieb Dave Airlie: > >> On 26 April 2017 at 18:45, Christian König >> wrote: >> >>> Am 26.04.2017 um 05:28 schrieb Dave Airlie: >>> Okay I've gone around the

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

Hi Tomi, On Tuesday 09 May 2017 15:10:40 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Hello, > > > > This patch series is a second, extended version of the code previously > > posted as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code". > As this is a long

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #20 from MirceaKitsune --- The same freeze happened again today, after a two week period of not seeing the problem any more. This is reaching the point where it's becoming outright ridiculous:

Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

Hi Tomi, On Tuesday 09 May 2017 15:02:36 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Both structures describe features of a particular OMAP DSS version, > > there's no reason to keep them separate. Merge them together, allowing > > initialization of the features based

Re: [PATCH 1/5] drm: introduce sync objects

On Mon, May 8, 2017 at 7:26 PM, Dave Airlie wrote: > On 4 May 2017 at 18:16, Chris Wilson wrote: > > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > >> +#include > > > > I wonder if Daniel has already split everything used here into

Re: [PATCH v2 13/28] drm: omapdrm: dss: Initialize DSS internal features at probe time

Hi Tomi, On Tuesday 09 May 2017 12:48:57 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > The DSS internal features are derived from the platform device > > compatible string which is available at probe time. Don't delay > > initialization until bind time. This prepares for

Re: [PATCH v2 11/28] drm: omapdrm: dss: Select features based on compatible string

Hi Tomi, On Tuesday 09 May 2017 12:41:26 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Use the compatible string instead of the OMAP SoC revision to determine > > device features. The various OMAP3-based SoCs can be told apart from the > > compatible string, use

Re: [PATCH v2 10/28] drm: omapdrm: dsi: Handle pin muxing internally

Hi Tomi, On Tuesday 09 May 2017 12:37:36 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > Don't rely on callback functions provided by the platform, but access > > the syscon internally to mux the DSI pins. > > > > Signed-off-by: Laurent Pinchart

Re: [PATCH v2 22/28] drm: omapdrm: Move shutdown() handler from core to dss

Hi Tomi, On Tuesday 09 May 2017 14:38:39 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > In preparation for removal of the core module, move the shutdown() > > handler from core to dss. > > > > Signed-off-by: Laurent Pinchart > > --- > >

Re: [PATCH v2 07/28] drm: omapdrm: dpi: Remove platform driver

Hi Tomi, On Tuesday 09 May 2017 12:06:58 Tomi Valkeinen wrote: > On 08/05/17 14:32, Laurent Pinchart wrote: > > No device is ever registered that binds with the driver, the DPI port is > > handled manually. Remove the DPI platform driver. > > You could add a bit more details: the DPI platform

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #5 from Przemek --- Created attachment 131285 --> https://bugs.freedesktop.org/attachment.cgi?id=131285=edit system log after second suspend and hard lockup -- You are receiving this mail because: You are the

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #4 from Przemek --- Created attachment 131284 --> https://bugs.freedesktop.org/attachment.cgi?id=131284=edit system log after first suspend -- You are receiving this mail because: You are the assignee for the

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #3 from Przemek --- Created attachment 131283 --> https://bugs.freedesktop.org/attachment.cgi?id=131283=edit kernel config file -- You are receiving this mail because: You are the assignee for the

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #2 from Przemek --- Created attachment 131282 --> https://bugs.freedesktop.org/attachment.cgi?id=131282=edit system log after performing hibernate -- You are receiving this mail because: You are the assignee

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 --- Comment #1 from Przemek --- Created attachment 131281 --> https://bugs.freedesktop.org/attachment.cgi?id=131281=edit system log after clean boot -- You are receiving this mail because: You are the assignee for the

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=100979 Bug ID: 100979 Summary: Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend Product: DRI Version: DRI git Hardware: x86-64 (AMD64)

Re: Soliciting DRM feedback on latest DC rework

On 2017-05-09 04:24 AM, Daniel Vetter wrote: On Mon, May 08, 2017 at 02:54:22PM -0400, Harry Wentland wrote: Hi Daniel, Thanks for taking the time to look at DC. I had a couple more questions/comments in regard to the patch you posted on IRC: http://paste.debian.net/plain/930704 My

RE: amdgpu display corruption and hang on AMD A10-9620P

> -Original Message- > From: Daniel Drake [mailto:dr...@endlessm.com] > Sent: Tuesday, May 09, 2017 12:55 PM > To: dri-devel; amd-...@lists.freedesktop.org; Deucher, Alexander > Cc: Chris Chiu; Linux Upstreaming Team > Subject: amdgpu display corruption and hang on AMD A10-9620P > > Hi, >

Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

On Fri, May 05, 2017 at 08:39:31PM +0800, Icenowy Zheng wrote: > >> > > + /* Set base coordinates */ > >> > > + DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n", > >> > > + state->crtc_x, state->crtc_y); > >> > > + regmap_write(mixer->engine.regs, > >> > > +

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

1;4601;0c On Fri, May 05, 2017 at 08:34:16PM +0800, Icenowy Zheng wrote: > > > 于 2017年5月5日 GMT+08:00 下午8:30:35, Maxime Ripard > 写到: > >On Fri, May 05, 2017 at 04:53:43PM +0800, icen...@aosc.io wrote: > >> > > + de2_clocks: clock@100 { > >> >

Re: [PATCH] drm/vgem: Convert to a struct drm_device subclass

On 05/08/2017 06:22 AM, Chris Wilson wrote: With Laura's introduction of the fake platform device for importing dmabuf, we add a second static that is logically tied to the vgem_device. Convert vgem over to using the struct drm_device subclassing, so that the platform device is stored inside its

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

On 2017-05-09 08:53 AM, Alex Deucher wrote: On Mon, May 8, 2017 at 1:01 PM, Gustavo A. R. Silva wrote: Local variable use_doorbell is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID:

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #14 from John Brooks --- (In reply to at46n from comment #13) > Seems like its a glsl compiler bug and not a radeonsi bug. With "prlimit > --pid PIDofDeadIsland -n65535" I am able to start and play

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

On Tue, 2017-05-09 at 19:29 +0200, Noralf Trønnes wrote: > Den 08.05.2017 13.54, skrev SF Markus Elfring: > > A single character (line break) should be put into a sequence. > > Thus use the corresponding function "seq_putc". Markus, I know this is hard for you, but think more before sending

Re: [PATCH v2] drm/pl111: Register the clock divider and use it.

Linus Walleij writes: > On Mon, May 8, 2017 at 9:33 PM, Eric Anholt wrote: > >> This is required for the panel to work on bcm911360, where CLCDCLK is >> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the >> CLCDCLK, for platforms

[PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS" to let the module get built on a cygnus-only kernel. However, I anticipate having a port for Kona soon, so just present the module on all of BCM. v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't exist

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #9 from Nikola Forró --- Thanks Harry, I've just tested the patch and I can confirm it fixes the problem. -- You are receiving this mail because: You are the assignee for the

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 at...@t-online.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 Harry Wentland changed: What|Removed |Added Attachment #131276|0 |1 is

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #7 from Nikola Forró --- Hi Alex, yes, that's exactly what I meant. Sorry for not being clear. Nikola -- You are receiving this mail because: You are the assignee for the

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

Den 08.05.2017 13.54, skrev SF Markus Elfring: From: Markus Elfring Date: Mon, 8 May 2017 13:42:03 +0200 A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #6 from Alex Deucher --- what about the else case? Shouldn't the logic be: if (dc_is_dvi_signal(stream->signal)) { if (stream->public.timing.pix_clk_khz >

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

Series is Reviewed-by: Harry Wentland Harry On 2017-05-08 12:35 PM, Jeff Smith wrote: Changes: I have broken one patch into three. Note: this only covers the display (not amdgpu) portion and does not include the code to make it work over the card's DVI port. I

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #5 from Harry Wentland --- Nikola, this line from the patch should take care of your concern: + if (dc_is_dvi_signal(stream->signal) && Other signal types shouldn't be affected. -- You are receiving

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #4 from Nikola Forró --- Comment on attachment 131276 --> https://bugs.freedesktop.org/attachment.cgi?id=131276 Patch to fix this (hopefully) Review of attachment 131276:

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: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

"Ong, Hean Loong" writes: > On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote: >> "Ong, Hean Loong" writes: >> >> > >> > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote: >> > > >> > > "Ong, Hean Loong"

[Bug 99029] VCE VAAPI segfault using ffmpeg

https://bugs.freedesktop.org/show_bug.cgi?id=99029 --- Comment #3 from Andy Furniss --- Hmm, I haven't tested yet, but if you hit the division by zero, I guess there is something special about thet file (or ffmpeg/something changed since I last looked). Before reading your

[RFC] drm: add unref_fb ioctl

Similar to rmfb but does not have the side effect of shutting down any pipes that are scanning out the fb. Advantages compared to rmfb: * slightly easier userspace, it doesn't have to track fb-id's until they come of the screen * it might be desirable to keep existing layers on screen

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 5/8/2017 10:39 PM, Ville Syrjälä wrote: > > On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 5/8/2017 9:54 PM, Ville Syrjälä

Re: [PATCH 1/5] drm: introduce sync objects

On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Sync objects are new toplevel drm object, that contain a > pointer to a fence. This fence can be updated via command > submission ioctls via drivers. > > There is also a generic wait obj API

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #3 from Harry Wentland --- Created attachment 131276 --> https://bugs.freedesktop.org/attachment.cgi?id=131276=edit Patch to fix this (hopefully) Hi Nikola, Thomas. Thanks for reporting this. Try this

[Bug 99029] VCE VAAPI segfault using ffmpeg

https://bugs.freedesktop.org/show_bug.cgi?id=99029 Martin Bednar changed: What|Removed |Added Version|13.0|17.1 --- Comment #2

[PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Acked-by: Ville Syrjälä Reviewed-by: Neil Armstrong Signed-off-by: Daniel Vetter ---

[PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence

[PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. v2: - WARN_ON_ONCE to avoid excessive spam (Ville) - Really

[PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3:

[PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything

Re: [RFC v2 0/7] drm: asynchronous atomic plane update

On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Second take of Asynchronous Plane Updates over Atomic. Here I looked > to msm, vc4 and i915 to identify a common pattern to create atomic helpers > for async

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

On Mon, May 8, 2017 at 1:01 PM, Gustavo A. R. Silva wrote: > Local variable use_doorbell is assigned to a constant value and it is never > updated again. Remove this variable and the dead code it guards. > > Addresses-Coverity-ID: 1401828 > Signed-off-by: Gustavo A. R.

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

On 08/05/17 14:32, Laurent Pinchart wrote: > Hello, > > This patch series is a second, extended version of the code previously posted > as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code". As this is a long series, I'd like to pick a bunch of patches from this series already: 1-5,

  1   2   >