Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 03/22/2017 02:48 PM, Rob Clark wrote: On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: Quoting Rob Clark (2017-03-22 10:07:54) I guess an interesting question (from someone who doesn't know meson yet) would be whether meson could slurp in the Makefile.sources type

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

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on|79431 | Referenced Bugs:

[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object image

https://bugs.freedesktop.org/show_bug.cgi?id=79431 Jan Vesely changed: What|Removed |Added Resolution|NOTABUG |---

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Sat, Mar 18, 2017 at 12:09 AM, Russell King - ARM Linux wrote: > On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote: >> This is a modesetting driver for the pl111 CLCD display controller >> found on various ARM platforms such as the Versatile Express. The >>

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #5 from omegap...@startmail.com --- Ah, happened again after leaving it off for ~2 hours... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #6 from omegap...@startmail.com --- Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow I'm sure ;) -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v3 2/2] drm/panel: add innolux,p079zca panel driver

can you add bps here too? On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong wrote: > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > panel. > > Signed-off-by: Chris Zhong > Reviewed-by: Sean Paul > Tested-by:

Re: [RFC libdrm 0/2] Replace the build system with meson

On Wed, 22 Mar 2017, Dylan Baker wrote: > Quoting Jani Nikula (2017-03-22 01:24:19) >> Right. That helps avoid many of the issues e.g. Sphinx has with the >> configuration files being pure python. > > Yes, sphinx's configuration files are awful for just that reason. Of

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

Hi, Daniel, On 03/23/2017 08:31 AM, Daniel Vetter wrote: > On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: >> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote: >>> On 03/22/2017 10:50 PM, Daniel Vetter wrote: It's been around forever, no one bothered to address

[PATCH] drm: Make the decision to keep vblank irq enabled earlier

We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for disabling the irq will disable it from with the same interrupt as the last pageflip event. If we move the decision on

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

I realized it was too early to search that in dri-devel last night, I guess it takes some time to sync. Now I can see them all :) On 3/23/2017 12:37 PM, Jose Abreu wrote: Hi Shashank, On 22-03-2017 18:57, Sharma, Shashank wrote: Hi Jose, I can't find the other patches of this series in

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

On 23.03.2017 12:04, Jose Abreu wrote: > Hi Andrzej, > > > Thanks for the feedback! > > On 23-03-2017 08:11, Andrzej Hajda wrote: >> On 22.03.2017 18:35, Jose Abreu wrote: >>> This patch completes CEA table of video modes so that VIC 1-107 >>> are now available. Use the HDMI 2.0+ flag to signal

[PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

From: Michel Dänzer Otherwise this can also prevent modesets e.g. for switching VTs, when multiple monitors with different native resolutions are connected. The depths must match though, so keep the != test for that. Also update the DRM_DEBUG output to be slightly more

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: > Hi, Daniel, > > On 03/23/2017 08:31 AM, Daniel Vetter wrote: > > On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: > >> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote: > >>> On 03/22/2017 10:50 PM,

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote: > On 03/22/2017 10:50 PM, Daniel Vetter wrote: > > It's been around forever, no one bothered to address the FIXME, so I > > presume it's all fine. > > > > Cc: Sinclair Yeh > > Cc: Thomas Hellstrom

Re: [Intel-gfx] [PATCH v4 4/8] drm: Add driver-private objects to atomic state

Op 22-03-17 om 22:05 schreef Pandiyan, Dhinakaran: > On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote: >> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: >>> From: "Pandiyan, Dhinakaran" >>> >>> It is necessary to track states for objects other than

[PATCH 10/24] drm/msm/mdp5: Assign INTF and CTL in encoder's atomic_check()

The INTF and CTL used in a display pipeline are going to be maintained as a part of the CRTC state (i.e, in mdp5_crtc_state). These entities, however, are currently statically assigned to drm_encoders (i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we assign them to the CRTC

[PATCH 02/24] drm/msm/mdp5: describe LM instances in mdp5_cfg

The number of Layer Mixers and the downstream blocks (DSPPs and PPs) connected to each LM can vary with different MDP5 revisions. These parameters are also static. Keep the per instance LM data in mdp5_cfg. This will avoid the need to have macros which identify PP id or DSPP id the LM is

[PATCH 05/24] drm/msm/mdp5: Simplify LM <-> PP mapping

PingPong ID for a Layer Mixer is already contained in mdp5_hw_mixer. This avoids the need to retrieve PP ID using macros Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 6 +++--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 5

[PATCH 07/24] drm/msm/mdp5: Remove the pipeline stuff in mdp5_ctl

The mdp5_ctl has an 'op_mode' struct which contains info on the downstream pipeline. Grouping these params together in a struct doesn't serve much purpose in the code. Maybe there was a plan to expand this further that never happened. Remove the op_mode struct, and place its members directly in

[PATCH 04/24] drm/msm/mdp5: Start using mdp5_hw_mixer

Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of using the LM index. Like before, the Layer Mixers are assigned statically to the CRTCs. The hwmixer(s) will later be dynamically assigned to CRTCs. For now, ignore the hwmixers that can only do WB. Signed-off-by: Archit

[PATCH 15/24] drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state

Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state. This mixer will be used to generate the right half of the scanout. With Source Split, a SSPP can now be connected to 2 Layer Mixers, but has to be at the same blend level (stage #) on both Layer Mixers. A drm_plane that has a lesser

[PATCH 12/24] drm/msm/mdp5: Start using parameters from CRTC state

In the last few commits, we've been adding params to mdp5_crtc_state, and assigning them in the atomic_check() funcs. Now it's time to actually start using them. Remove the duplicated params from the mdp5_crtc struct, and start using them in the mdp5_crtc code. The majority of the references to

[PATCH 11/24] drm/msm/mdp5: Add more stuff to CRTC state

Things like vblank/err irq masks, mode of operation (command mode or not) are derivative of the interface and mixer state. Therefore, they need to be a part of the CRTC state too. Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check() func, so that it can be rolled back to a

[PATCH 08/24] drm/msm/mdp5: subclass CRTC state

Subclass drm_crtc_state so that we can maintain additional state for our CRTCs. Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state. mdp5_pipeline is a grouping of the HW entities that forms the downstream pipeline for a particular CRTC. It currently contains pointers to

[PATCH 13/24] drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl

These are a part of CRTC state, it doesn't feel nice to leave them hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead wherever it is needed. We still have some params in mdp5_ctl like start_mask etc which are derivative of atomic state, and should be rolled back if a commit fails, but

[PATCH 03/24] drm/msm/mdp5: Add structs for hw Layer Mixers

Create a struct to represent MDP5 Layer Mixer instances. This will eventually allow us to detach CRTCs from the Layer Mixers, and generally clean things up a bit. This is very similar to how hwpipes were previously abstracted away from drm planes. Signed-off-by: Archit Taneja

[PATCH 00/24] drm/msm/mdp5: Mixer virtualization and 4K plane support

This patchset enables dynamic assignment of Layer Mixer blocks to CRTCs in order to support wide resolution modes and planes. The approach is similar to what was done for decoupling MDP5 planes from the hwpipes (SSPPs). We go further by letting a CRTC comprise of 2 Layer Mixers, one to scanout

[PATCH 01/24] drm/msm/mdp5: Bring back pipe_lock to mdp5_plane struct

We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring it back to mdp5_plane. We will need this because an mdp5_plane in the future could comprise of 2 hw pipes. It makes more sense to have a single lock to protect the registers for the hw pipes used by a plane, rather than

[PATCH 06/24] drm/msm/mdp5: Clean up interface assignment

mdp5_interface struct contains data corresponding to a INTF instance in MDP5 hardware. This sturct is memcpy'd to the mdp5_encoder struct, and then later to the mdp5_ctl struct. Instead of copying around interface data, create mdp5_interface instances in mdp5_init, like how it's done currently

[PATCH 09/24] drm/msm/mdp5: Prepare for dynamic assignment of mixers

Add the stuff needed to allow dynamically assigning a mixer to a CRTC. Since mixers are a resource that can be shared across multiple CRTCs, we need to maintain a 'hwmixer_to_crtc' map in the global atomic state, acquire the mdp5_kms.state_lock modeset lock and so on. The mixer is assigned in

Re: [PATCH 10/41] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

On 22.03.2017 16:19, Sean Paul wrote: > On Wed, Mar 22, 2017 at 09:36:34AM +0100, Andrzej Hajda wrote: >> On 21.03.2017 20:58, Sean Paul wrote: >>> On Thu, Mar 16, 2017 at 02:40:21PM +0100, Andrzej Hajda wrote: On 10.03.2017 05:32, Sean Paul wrote: > From: zain wang

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #3 from Michel Dänzer --- (In reply to OmegaPhil from comment #2) > confirmed 7.9 is loaded, the problem is still present. Does radeon_scanout_flip still spit out both "Invalid argument" and "Device or resource

[PATCH 22/24] drm/msm/mdp5: Assign 'right' mixer to CRTC state

Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's atomic_check path. Assigning the right mixer has some constraints, i.e, only a few LMs can be paired together. Update mdp5_mixer_assign to handle these constraints. Firstly, we need to identify whether we need a right mixer or not.

[PATCH 19/24] drm/msm/mdp5: Prepare Layer Mixers for source split

In order to enable Source Split in HW, we need to add/modify a few LM register configurations: - Configure the LM width to be half the mode width, so that each LM manages one half of the scanout. - Tell the 'right' LM that it is configured to be the 'right' LM in source split mode. - Since we

[PATCH 17/24] drm/msm/mdp5: Assign a 'right hwpipe' to plane state

If the drm_plane has a source width that's greater than the max width supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe' to it in mdp5_plane_atomic_check(). TODO: There are a few scenarios where the hwpipe assignments aren't recommended by HW. For example, an assignment which

[PATCH 16/24] drm/msm/mdp5: Create mdp5_hwpipe_mode_set

Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter func takes in only the hwpipe and the parameters that need to be programmed into the hwpipe registers. All the code that calculates these parameters is left as is in mdp5_plane_mode_set. In the future, when we let drm_plane be

[PATCH 14/24] drm/msm/mdp5: Add a CAP for Source Split

Some of the newer MDP5 versions support Source Split of SSPPs. It is a feature that allows us to route the output of a hwpipe to 2 Layer Mixers. This is required to achieve the following use cases: - Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single DSI interface doesn't have

[PATCH 21/24] drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs

If a CRTC comprises of 2 LMs, it is mandatory to enable border out and assign it to the base stage. We had to enable border out also when the base plane wasn't fullscreen. Club these checks and put them in a separate function called get_start_stage() that returns the starting stage for assigning

[PATCH 18/24] drm/msm/mdp5: Configure 'right' hwpipe

Now that we have a right hwpipe in mdp5_plane_state, configure it mdp5_plane_mode_set(). The only parameters that vary between the left and right hwpipes are the src_w, src_img_w, src_x and crtc_x as we just even chop the fb into left and right halves. Add a mdp5_plane_right_pipe() which will be

[PATCH 20/24] drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer

Now that our mdp5_planes can consist of 2 hwpipes, update the blend_setup() code to stage the right hwpipe to the left and right LMs Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 12 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 12

[PATCH 23/24] drm/msm/mdp5: Reset CTL blend registers before configuring them

Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that isn't used by our CTL instance anymore. Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM instances. The ones that need to be configured are

[PATCH 24/24] drm/msm/mdp5: Enable 3D mux in mdp5_ctl

3D mux is a small block placed after the DSPPs in MDP5. It can merge 2 LM/DSPP outputs and feed it to a single interface. Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check will need to be made more specific later when we add Dual DSI support with source split enabled. In that use

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote: > We can't expect userspace to have full support for all HDMI 2.0+ > features. Instead of expecting/waiting for userspace to support > the new features add a knob, much like the stereo knob, so that > DRM core will only expose the

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: > On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote: > > On 03/22/2017 10:50 PM, Daniel Vetter wrote: > > > It's been around forever, no one bothered to address the FIXME, so I > > > presume it's all fine. > > > > > >

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

Better subject might be drm: Use vblank irq shadow for entire flip sequence -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Regards Shashank On 3/23/2017 10:11 AM, Andrzej Hajda wrote: On 22.03.2017 18:35, Jose Abreu wrote: This patch completes CEA table of video modes so that VIC 1-107 are now available. Use the HDMI 2.0+ flag to signal these are modes for HDMI 2.0 onwards. edid_cea_modes array is used in

Re: [RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote: > Perform sanity checks so that HDMI 2.0+ modes are not exported to > drivers or userspace unless asked to. Why? They're just normal modes, this doesn't make sense. If you want to filter the aspect ratio stuff, that makes sense, but

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

On 22.03.2017 18:35, Jose Abreu wrote: > This patch completes CEA table of video modes so that VIC 1-107 > are now available. Use the HDMI 2.0+ flag to signal these are > modes for HDMI 2.0 onwards. edid_cea_modes array is used in different contexts, simple extensions of the array with modes not

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 23/03/17 03:19 AM, Zachary Michaels wrote: > We were experiencing an infinite loop due to VRAM bos getting added back > to the VRAM lru on eviction via ttm_bo_mem_force_space, Can you share more details about what happened? I can imagine that moving a BO from CPU visible to CPU invisible VRAM

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On 03/23/2017 11:10 AM, Daniel Vetter wrote: > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: >> Hi, Daniel, >> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote: >>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: On Thu, Mar 23, 2017 at 07:22:31AM +0100,

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote: > Hi Daniel, > > > On 23-03-2017 07:22, Daniel Vetter wrote: > > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote: > >> We can't expect userspace to have full support for all HDMI 2.0+ > >> features. Instead of

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 --- Comment #1 from John Brooks --- Created attachment 130407 --> https://bugs.freedesktop.org/attachment.cgi?id=130407=edit Fix for display not waking -- You are receiving this mail because: You are the

Re: [PATCH v4 3/8] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

On Wed, Mar 15, 2017 at 06:02:09PM +0100, Yannick Fertre wrote: > Signed-off-by: Yannick Fertre > --- > .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 >

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 Bug ID: 100364 Summary: DisplayPort hotplug warning and monitor sometimes stays blank Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux

[PATCH] drm: bochs: Prevent double-free of fb helper

If fbdev registration fails for whatever reason, the error path of bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev initialization error is not fatal to the probe function, a subsequent device removal will try to call bochs_fbdev_fini() again, hitting the Oops below. This was

[PATCH v4 2/2] drm/panel: add innolux,p079zca panel driver

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI panel. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Tested-by: Brian Norris --- Changes in v4: - remove backlight check after probe - add bpc info

[PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and connected to DSI using four lanes. Signed-off-by: Chris Zhong Reviewed-by: Brian Norris --- Changes in v4: None Changes in v3: None Changes in v2: None

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 John Brooks changed: What|Removed |Added See Also|

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

https://bugs.freedesktop.org/show_bug.cgi?id=90320 John Brooks changed: What|Removed |Added See Also|

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Colin Cross (2017-03-23 15:14:16) > On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: > > On 03/22/2017 02:48 PM, Rob Clark wrote: > >> > >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: > >>> > >>> Quoting Rob Clark (2017-03-22

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 17:42, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:43, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank,

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Hi Andrzej, Thanks for the feedback! On 23-03-2017 08:11, Andrzej Hajda wrote: > On 22.03.2017 18:35, Jose Abreu wrote: >> This patch completes CEA table of video modes so that VIC 1-107 >> are now available. Use the HDMI 2.0+ flag to signal these are >> modes for HDMI 2.0 onwards. >

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

Hi Shashank, On 22-03-2017 18:57, Sharma, Shashank wrote: > Hi Jose, > I can't find the other patches of this series in dri patchwork, am I missing > something ? You can find them now in patchwork (I don't know what happened). > > Also, I am planning to publish a series for YUV 420 handling,

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

On Wed, Mar 22, 2017 at 08:26:07AM -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 error messages to debug messages (in the graph core). > Graph connections are often "no

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker wrote: > Quoting Colin Cross (2017-03-23 15:14:16) >> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: >> > On 03/22/2017 02:48 PM, Rob Clark wrote: >> >> >> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

Hi Daniel, On 23-03-2017 07:22, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote: >> We can't expect userspace to have full support for all HDMI 2.0+ >> features. Instead of expecting/waiting for userspace to support >> the new features add a knob, much like the

Re: [PATCH v4 8/8] ARM: configs: Add STM32 panel simple support in STM32 defconfig

Hi, On 03/15/2017 06:02 PM, Yannick Fertre wrote: Signed-off-by: Yannick Fertre --- Same remarks than patch7 arch/arm/configs/stm32_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig

Re: [PATCH v4 7/8] ARM: configs: Add STM32 LTDC support in STM32 defconfig

Hi On 03/15/2017 06:02 PM, Yannick Fertre wrote: Signed-off-by: Yannick Fertre --- Can you change commit header by:" ARM: config: stm32: Add LTDC support" and can you fill a commit message please ? arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On 2017-03-23 01:53, Michel Dänzer wrote: > From: Michel Dänzer > > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. When changing resolution a regular fbdev driver also changes

[git pull] drm fixes for 4.11-rc4.

Hi Linus, This is the fixes pull request for rc4. It contains one core drm/fbdev regression fix. A set of i915 fixes including a few GVT related fixes, along with some reset fixes. One new PCI id for amdgpu, and some minor workaround regression fixes. A set of exynos fixes, dropping support for

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On 03/23/2017 02:26 PM, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for

[Bug 86351] HDMI audio garbled output on Radeon R9 280X

https://bugzilla.kernel.org/show_bug.cgi?id=86351 --- Comment #26 from Christian Birchinger (jo...@netswarm.net) --- Haven't used HDMI for almost a year now. The issue is still present and this time changing prealloc fixes nothing. 2048 used to work, but now all values i've tried from 64 to 4096

[lkp-robot] [drm] f04f7e3e04: general_protection_fault:#[##]

FYI, we noticed the following commit: commit: f04f7e3e041aab12abbf3ed7b854446af5a624a9 ("drm: bochs: Don't remove uninitialized fbdev framebuffer") url: https://github.com/0day-ci/linux/commits/Gabriel-Krisman-Bertazi/drm-bochs-Don-t-remove-uninitialized-fbdev-framebuffer/20170318-164722 base:

[PATCH] drm: omapdrm: Fix oops on rmmod

Looks like in Linux next we can now get an oops when unloading omapdrm: Unable to handle kernel NULL pointer dereference at virtual address ... LR is at omap_drm_irq_uninstall+0xb0/0xe0 [omapdrm] ... [] (omap_drm_irq_uninstall [omapdrm]) from [] (pdev_remove+0x50/0x88 [omapdrm]) []

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: > On 03/22/2017 02:48 PM, Rob Clark wrote: >> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: >>> >>> Quoting Rob Clark (2017-03-22 10:07:54) I guess an interesting question (from

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 18:14, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 17:42, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:43,

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >>> For any other mode, the VIC

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >> For any other mode, the VIC filed in AVI infoframes should be 0. >> HDMI 2.0 sinks, support

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended to (VIC

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, When it happens, the main thread of our gl based app is stuck on a ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same thing happens if true. Other threads are only si_shader:0,1,2,3 and are doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof

Re: [RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

Hi Daniel, Thanks for the feedback! On 23-03-2017 07:25, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote: >> Perform sanity checks so that HDMI 2.0+ modes are not exported to >> drivers or userspace unless asked to. > Why? They're just normal modes, this

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

Hi Ville, On 23-03-2017 19:00, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:16, Ville Syrjälä wrote: >>> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: Add the HDMI 2.0 aspect ratio flags (64:27 and

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:43, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:08, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville,

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Hi Andrzej, On 23-03-2017 11:17, Andrzej Hajda wrote: > On 23.03.2017 12:04, Jose Abreu wrote: >> Hi Andrzej, >> >> >> Thanks for the feedback! >> >> On 23-03-2017 08:11, Andrzej Hajda wrote: >>> On 22.03.2017 18:35, Jose Abreu wrote: This patch completes CEA table of video modes so that

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote: > Hm, I certainly want it... but it would be unreasonable of me to expect > Eric to cold-code a big upfront design for systems he can't even test > this on. > > What I would request would rather be: please do not put in any >

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:45, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

Hi Ville, On 23-03-2017 15:16, Ville Syrjälä wrote: > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new >> flag which will signal userspace that this is a HDMI 2.0+ mode. It >> is expected that these new flags will

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On 2017.03.23 14:43:44 +0100, Frans Klaver wrote: > On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > > From: Colin Ian King > > > > info is being checked to see if it is a null pointer, however, vpgu is > > dereferencing info before this

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 16:43, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:08, Sharma, Shashank wrote: > >>>

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Emil Velikov (2017-03-23 04:39:50) > On 22 March 2017 at 20:10, Dylan Baker wrote: > > The more frustrating part is that atm autotools build is "bug-free" > and with meson will have to go through the same route again :-\ Sure, but if it's easier to get right (which

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 21 March 2017 at 05:00, Jonathan Gray wrote: > On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: >> >> >> On 21/03/17 06:39, Emil Velikov wrote: >> > On 20 March 2017 at 18:30, Matt Turner wrote: >> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #6 from Vedran Miletić --- (In reply to Mig from comment #5) > minimal.cpp compiled with > > gcc -c minimal.cpp -g -o minimal.o > > [miguel@antergos-mig extra]$ gdb > GNU gdb (GDB) 7.12.1 > Copyright (C) 2017

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 17:42, Ville Syrjälä wrote: > > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:43, Sharma, Shashank wrote: > >>> Regards > >>> > >>> Shashank

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote: > On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: > > > > > > On 21/03/17 06:39, Emil Velikov wrote: > > > On 20 March 2017 at 18:30, Matt Turner wrote: > > > > On Mon, Mar 20, 2017 at 6:55 AM,

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: > We want to provide the vblank irq shadow for pageflip events as well as > vblank queries. Such events are completed within the vblank interrupt > handler, and so the current check for disabling the irq will disable it > from with the

[PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

From: Colin Ian King info is being checked to see if it is a null pointer, however, vpgu is dereferencing info before this check, leading to a potential null pointer dereference. If info is null, then the error message being printed by macro gvt_vgpu_err and this

Re: [PATCH] drm/scdc: declare drm_scdc_get_scrambling_status

On Wed, 22 Mar 2017, "Sharma, Shashank" wrote: > Thanks for this patch, Jani. > > Reviewed-by: Shashank Sharma And pushed to drm-misc-next, thanks for the review. BR, Jani. > > > Regards > Shashank > On 3/22/2017 4:33 PM, Jani Nikula

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

Hi Michel, On 23 March 2017 at 08:53, Michel Dänzer wrote: > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. > > The depths must match though, so keep the != test for that. > > Also

  1   2   >