[RFC 0/3] drm: Add DRM text mode

Den 02.08.2016 15:05, skrev Daniel Vetter: > On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes > wrote: >> Den 29.07.2016 10:23, skrev Daniel Vetter: >>> Actually adding David. >>> -Daniel >>> >>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote: On Thu, Jul 28, 2016 at

[Intel-gfx] [PATCH] drm: Avoid printing negative values for unsigned variables.

On Wed, Aug 03, 2016 at 09:53:46AM -0700, Rodrigo Vivi wrote: > It was really strange to see negative vblank seqs on debug > messages. It is rare to have that big number, but when it > happens it is confusing and misleading. > > Signed-off-by: Rodrigo Vivi Reviewed-by: Ville Syrjälä > --- >

[PATCH 2/2] drm: Used DRM_LEGACY for all legacy functions

Except for nouveau, only legacy drivers need this really. And nouveau is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special case. I've tried to be careful to leave everything related to modeset still using the DRIVER_MODESET flag. Otherwise it's a direct replacement of

[PATCH 1/2] drm: Mark up legacy/dri1 drivers with DRM_LEGACY

It's super confusing that new drivers need to be marked with DRIVER_MODESET when really it means DRIVER_MODERN. Much better to invert the meaning and rename it to something that's suitably off-putting. Since there's over 100 places using DRIVER_MODESET we need to roll out this change without a

simpledrm problem: Kconfig:error: recursive dependency detected!

Hi, I have changed simpledrm to use drm_simple_kms_helper and now I'm facing this: drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER

[PATCH 1/3] drm/rockchip: inno_hdmi: add audio support

Am Dienstag, 2. August 2016, 10:16:04 schrieb Yakir Yang: > Hi Mark & Heiko, > > Ping.. devicetree side looks good, so we're waiting on Mark to pick up patch 1. Heiko > On 06/15/2016 09:28 PM, Yakir Yang wrote: > > Using the common hdmi-codec driver to support hdmi audio function. > > >

[PATCH 5/8] drm: use drm_file to tag vm-bos

On Wed, Aug 03, 2016 at 08:04:29PM +0200, David Herrmann wrote: > Rather than using "struct file*", use "struct drm_file*" as tag VM tag for > BOs. This will pave the way for "struct drm_file*" without any "struct > file*" back-pointer. > > Signed-off-by: David Herrmann Ok, the danger of

[PATCH 4/4] drm/i915/dp: Dump DP link status when link training stages fails

A full dump of link status can be handy in debugging link training failures. Let's add that to the debug messages when link training fails. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++ drivers/gpu/drm/i915/intel_drv.h | 6

[PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

The causes of clock recovery and channel equalization failures are not explicitly printed in debug messages. Help debugging link training failures by printing why it failed. Doing this in the driver would mean re-implementing some of the drm static functions that decode link status. Let's avoid

[PATCH 2/4] drm/i915/dp: Switch to using the DRM function for reading DP link status

Since a DRM function that reads link DP link status is available, let's use that instead of the i915 clone. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp.c | 15 +++ drivers/gpu/drm/i915/intel_dp_link_training.c | 11 ---

[PATCH 1/4] drm/i915/dp: Add debug messages to print DP link training pattern

Currently we do not print the training pattern used in any of the DP link training stages. Including this piece of information in debug messages will help debugging. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp.c | 13 +++-- 1 file changed, 7 insertions(+), 6

[PATCH 0/4] Improve logging for DP link training

We do not currently output enough information to help debugging DP link training issues. For e.g., training pattern and link status information. This series aims to correct that by adding debug messages that can help developers. Dhinakaran Pandiyan (4): drm/i915/dp: Add debug messages to print

[PATCH 8/8] drm: provide management functions for drm_file

Rather than doing drm_file allocation/destruction right in the fops, lets provide separate helpers. This decouples drm_file management from the still-mandatory drm-fops. It prepares for use of drm_file without the fops, both by possible separate fops implementations and APIs (not that I am aware

[PATCH 7/8] drm: rename drm_file.filp to drm_file.legacy_filp

We don't want anyone but legacy DRM1 code to use drm_file.filp. Especially for in-kernel contexts, this might be set to NULL, so lets make sure no-one accesses it, ever. Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_bufs.c | 7 --- drivers/gpu/drm/drm_fops.c | 2 +-

[PATCH 6/8] drm: use priv->pid to deduce task EUID

Rather than accessing priv->filp->f_cred, use priv->pid->task->creds. We want to get rid of "priv->filp", so lets avoid it if possible. Since we already are in an rcu-read-side, we can use __task_cred() rather than task_cred_xxx(). Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_info.c |

[PATCH 5/8] drm: use drm_file to tag vm-bos

Rather than using "struct file*", use "struct drm_file*" as tag VM tag for BOs. This will pave the way for "struct drm_file*" without any "struct file*" back-pointer. Signed-off-by: David Herrmann --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++- drivers/gpu/drm/ast/ast_ttm.c | 3

[PATCH 4/8] drm: make vma-manager entries untyped

Right now, the vma-manager requires all entries to provide a "struct file*" as identifier. This is confusing, since there is no inherent connection to "struct file" in the vma-manager at all, but it is exclusively used as tag. Replace its usage with a simple "void *tag" and make sure callers can

[PATCH 3/8] drm: reduce GETCLIENT to a minimum

The *only* known user of GETCLIENT is libva, which uses it to check whether its own context is authenticated. It used to iterate all clients, look for one that matches its own pid and then check its state. The entire purpose for us to still have a GETCLIENT implementation is to serve libva. So

[PATCH 2/8] drm: remove redundant drm_file->uid

Each DRM file-context caches the EUID of the process that opened the file. It is used exclusively for debugging purposes in /proc/dri/ and friends. Note, however, that "struct file" already caches the credentials of a process at open-time. So lets just use drm_file->filp->f_cred->euid if

[PATCH 1/8] drm: rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY

The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and gets 'cardX' as name assigned. Lets reduce this magnificent number of names for the same concept by one and rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY (to match the actual struct-member name). Furthermore, this is in no

[PATCH 0/8] DRM File Context Cleanups

Hi Some rather random cleanups on drm_file and whatever I found on the way. The idea here really is to get to a point where we can allocate drm_file from a kernel context to get in-kernel rendering to work. This would allow allocating dumb-buffers, dma-bufs, etc. from within the kernel and get

[PATCH 2/8] drm: remove redundant drm_file->uid

On Wed, Aug 03, 2016 at 08:04:26PM +0200, David Herrmann wrote: > @@ -98,13 +99,14 @@ int drm_clients_info(struct seq_file *m, void *data) > > rcu_read_lock(); /* locks pid_task()->comm */ > task = pid_task(priv->pid, PIDTYPE_PID); > + uid = priv->filp ?

[PATCH 6/8] drm: use priv->pid to deduce task EUID

On Wed, Aug 03, 2016 at 08:04:30PM +0200, David Herrmann wrote: > Rather than accessing priv->filp->f_cred, use priv->pid->task->creds. We > want to get rid of "priv->filp", so lets avoid it if possible. > > Since we already are in an rcu-read-side, we can use __task_cred() rather > than

[PATCH 2/8] drm: remove redundant drm_file->uid

On Wed, Aug 03, 2016 at 08:04:26PM +0200, David Herrmann wrote: > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c > index 323c238..e9d66f5 100644 > --- a/drivers/gpu/drm/drm_fops.c > +++ b/drivers/gpu/drm/drm_fops.c > @@ -199,7 +199,6 @@ static int drm_open_helper(struct file

[PATCH 1/3] drm: Track drm_mm nodes with an interval tree

Hey On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson wrote: > In addition to the last-in/first-out stack for accessing drm_mm nodes, > we occasionally and in the future often want to find a drm_mm_node by an > address. To do so efficiently we need to track the nodes in an interval > tree - lookups

[PATCH 4/8] drm: make vma-manager entries untyped

On Wed, Aug 03, 2016 at 08:04:28PM +0200, David Herrmann wrote: > Right now, the vma-manager requires all entries to provide a "struct > file*" as identifier. This is confusing, since there is no inherent > connection to "struct file" in the vma-manager at all, but it is > exclusively used as tag.

[PATCH 3/3] drm: Skip initialising the drm_mm_node->hole_stack

Hi Chris On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson wrote: > As we always add this to the drm_mm->hole_stack as our first operation, > we do not need to initialise the list node. > > Signed-off-by: Chris Wilson > Cc: David Herrmann > Cc: dri-devel at lists.freedesktop.org > --- >

[PATCH 2/3] drm: Convert drm_vma_manager to embedded interval-tree in drm_mm

Hi Chris On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson wrote: > Having added an interval-tree to struct drm_mm, we can replace the > auxiliary rb-tree inside the drm_vma_manager with it. > > Signed-off-by: Chris Wilson > Cc: David Herrmann > Cc: dri-devel at lists.freedesktop.org > --- Should

[PATCH] drm: Declare that create drm_mm nodes with size 0 is illegal

At a higher level, all objects are created with definite size i.e. 0 is illegal. In forthcoming patches, this assumption is dependent upon in the drm_mm range manager, i.e. trying to create a drm_mm node with size 0 will have undefined behaviour. Add a couple of WARNs upon creating the drm_mm node

[PATCH 0/3] DesignWare HDMI I2S suport

ttachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/02e20f22/attachment.sig>

[PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote: > Now that we can hook into update_crtcs and control the order in which we > update CRTCs at each modeset, we can finish the final step of fixing > Skylake's watermark handling by performing DDB updates at the same time > as plane updates and

[PATCH libdrm] Make sure the second argument to container_of() is initialized

On 03.08.2016 02:49, Nicolai Hähnle wrote: > On 02.08.2016 12:08, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Fixes warnings and miscompilation resulting in crashes with clang. > > How annoying. Seems like this would affect most (current and future) > uses of container_of, and so it

[PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Wed, 2016-08-03 at 18:00 +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote: > > > > Now that we can hook into update_crtcs and control the order in which we > > update CRTCs at each modeset, we can finish the final step of fixing > > Skylake's watermark

[PATCH 0210/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 06:50:01PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro,

[PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling

On 08/01/2016 02:29 AM, Philipp Zabel wrote: > Am Donnerstag, den 28.07.2016, 16:09 -0700 schrieb Steve Longerbeam: >>> Now split the frame in half and suddenly pixel x' = 640 is the start of >>> a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be >>> sampled at x = 160 + (1279 -

[PATCH] drm/rockchip: fix fbdev crash when not use DRM_FBDEV_EMULATION

On 2016年08月03日 16:46, Daniel Vetter wrote: > On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote: >> On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote: >>> [1.162571] Unable to handle kernel NULL pointer dereference at virtual >>> address 0200 >>> [1.165656]

[PATCH 4/4] drm: Add and handle new aspect ratios in DRM layer

HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or viseversa. Signed-off-by: Shashank Sharma ---

[PATCH 3/4] video: Add new aspect ratios for HDMI 2.0

HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds enumeration for the new aspect ratios in the existing aspect ratio list. Signed-off-by: Shashank Sharma --- drivers/video/hdmi.c | 4 include/linux/hdmi.h | 2 ++ 2 files changed, 6 insertions(+) diff

[PATCH 2/4] drm: Add aspect ratio parsing in DRM layer

Current DRM layer functions dont parse aspect ratio information while converting a user mode->kernel mode or viceversa. This causes modeset to pick mode with wrong aspect ratio, eventually cauing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in

[PATCH 1/4] drm: add picture aspect ratio flags

This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. Signed-off-by: Shashank Sharma ---

[PATCH 0/4]: Picture aspect ratio support in DRM layer

This patch series adds 4 patches. - The first two patches add aspect ratio support in DRM layes - Next two patches add new aspect ratios defined in CEA-861-F supported for HDMI 2.0 4k modes. Adding aspect ratio support in DRM layer: - The CEA videmodes contain aspect ratio information, which we

[PATCH] drm/rockchip: fix fbdev crash when not use DRM_FBDEV_EMULATION

[1.162571] Unable to handle kernel NULL pointer dereference at virtual address 0200 [1.165656] Modules linked in: [1.165941] CPU: 5 PID: 143 Comm: kworker/5:2 Not tainted 4.4.15 #237 [1.166506] Hardware name: Rockchip RK3399 Evaluation Board v1 (Android) (DT) [1.167153]

[PATCH 3/3] drm: Skip initialising the drm_mm_node->hole_stack

As we always add this to the drm_mm->hole_stack as our first operation, we do not need to initialise the list node. Signed-off-by: Chris Wilson Cc: David Herrmann Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_mm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)

[PATCH 2/3] drm: Convert drm_vma_manager to embedded interval-tree in drm_mm

Having added an interval-tree to struct drm_mm, we can replace the auxiliary rb-tree inside the drm_vma_manager with it. Signed-off-by: Chris Wilson Cc: David Herrmann Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_vma_manager.c | 43 ---

[PATCH 1/3] drm: Track drm_mm nodes with an interval tree

In addition to the last-in/first-out stack for accessing drm_mm nodes, we occasionally and in the future often want to find a drm_mm_node by an address. To do so efficiently we need to track the nodes in an interval tree - lookups for a particular address will then be O(lg(N)), where N is the

[PATCH 0/4]: Picture aspect ratio support in DRM layer

Hello Joes, > I've also seen this before and I am using them in order to pass HDMI > compliance. Without > these patches the compliance fails. Still, I've made some changes which I can > submit. I've > some comments to you (Shashank): Thanks for addressing these patches. You are welcome to

[PATCH v4 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

Hi Chanwoo Choi, On 2016年08月02日 12:21, Chanwoo Choi wrote: > Hi Lin, > > On the next version, I'd like you to add the 'linux-pm at vger.kernel.org' > because devfreq is a subsystem of power management. Sure, will do it next version. > On 2016년 08월 02일 10:03, hl wrote: >> Hi Chanwoo

[PATCH 0/4]: Picture aspect ratio support in DRM layer

> Patch series seems to have 0 changelogs anywhere, but I'm pretty sure I've > seen this before. > > Please try again and state what changed and why you are > resubmitting this. > -Daniel Hi Daniel, This is a re-spin of the patch series for aspect ratio support. The first four patches dint

[PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Wed, Aug 03, 2016 at 06:00:42PM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote: > > Now that we can hook into update_crtcs and control the order in which we > > update CRTCs at each modeset, we can finish the final step of fixing > > Skylake's watermark

[PATCH 6/6] drm/i915: Sanitize drm crtc vblank counter after DC reset frame count.

DC state reset the frame counter that is a read-only register. So, besides blocking DC state on vblank let's restore the drm crtc vblank counter to a place we know it is reliable. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH 5/6] drm: Introduce drm_crtc_vblank_sanitize_counter.

In modern systems there are situations that you can let the screen enabled and sleep or shut off a most of the display controler. In situations like this the vblank hw counter can be reset. When this happens everything in the system gets crazy by the big count. So, the right approach is to make

[PATCH 4/6] drm/i915: Introduce vblank power domain to avoid DC entry when waiting for vblank.

Vblank counters are not restored by DMC when exiting deep DC states because frame counter register is read-only. So it is better to avoid Deep DC states when waiting for Vblanks. At least we don't mess with the counters when already waiting for vblank. Signed-off-by: Rodrigo Vivi ---

[PATCH 3/6] drm/i915: Split gen 9 irq hooks definitions.

No functional change. This is just a reorg that aims to allow a cleaner introduction of new vblank hooks for gen9+. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_irq.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c

[PATCH 2/6] drm/i915: Move drm_crtc_vblank_get out of disabled pre-emption area.

drm_crtc_vblank_get call the drm_vblank_prepare that will be used soon to control power saving states or anything else that needs a mutex before the vblank happens. local_irq_disable disables kernel preemption so we won't be able to use mutex inside drm_crtc_vblank_get. For this reason we need to

[PATCH 1/6] drm: Add vblank prepare and unprepare hooks.

This will allow drivers to control specific power saving feature and power domains when dealing with vblanks. Vblanks code are protected by spin_locks where we can't have anything that can sleep. While power saving features and power domain code have mutexes to control the states. Mutex can

[PATCH 0/6] Allow DC state to reset the counter on screen enabled.

For now DC is only helping on screen off scenarios since PSR is disabled. But if we want to enable PSR first we need to make DC reliable with screen on. Biggest challenge is to deal with vblank counters since frame counter register is read only and can be reset in DC state. This series is one of

[PATCH 2/2] drm: Remove legacy drm_wait_one_vblank(dev, pipe).

Now that this is not used anywhere else anymore we can go ahead and remove the legacy version. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/drm_irq.c | 35 +++ include/drm/drm_irq.h | 1 - 2 files changed, 11 insertions(+), 25 deletions(-) diff --git

[PATCH 1/2] drm/i915: Use drm_crtc_vblank_wait_one_vblank instead the legacy one.

No functional change. This is the last user of legacy function so we will be able to clean up drm_irq.c a bit. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_drv.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h

[PATCH 2/2] drm: Remove legacy drm_vblank_{on,off}

No functional change. Only removing unused legacy functions. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/drm_irq.c | 62 +-- include/drm/drm_irq.h | 2 -- 2 files changed, 12 insertions(+), 52 deletions(-) diff --git

[PATCH 1/2] drm/nouveau: Use drm_crtc_vblank_{on, off} instead of old legacy ones.

No functional change. Justs finish the migration from drm_vblank_*(dev, pipe) to drm_crtc_vblank_*(crtc) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/nouveau/nouveau_display.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git

[PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

On Wed, Aug 03, 2016 at 02:14:53PM -0700, Matt Roper wrote: ... > > I imagine we'll eventually probably want to create a new display vfunc > to handle platform-specific pipe-level stuff that needs to happen under > vblank evasion (like the scalers and linetime WM we have today) to keep > the code

[PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

On Tue, Aug 02, 2016 at 02:20:33PM -0700, Matt Roper wrote: > On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote: > > Thanks to Ville for suggesting this as a potential solution to pipe > > underruns on Skylake. > > > > On Skylake all of the registers for configuring planes, including the > >

[PATCH 0/4]: Picture aspect ratio support in DRM layer

Hi, On 03-08-2016 12:48, Daniel Vetter wrote: > On Wed, Aug 03, 2016 at 04:26:24PM +0530, Shashank Sharma wrote: >> This patch series adds 4 patches. >> - The first two patches add aspect ratio support in DRM layes >> - Next two patches add new aspect ratios defined in CEA-861-F >> supported

[PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.

On 08/03/2016 08:09 AM, Daniel Vetter wrote: > On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote: >> On 6 July 2016 at 20:05, Mario Kleiner wrote: >>> For DP sinks which don't expose color depth via EDID, use >>> the drm_dp_sink_bpc() helper to derive the bpc of the sink. >>> >>> This

[PATCH 00/10] drm/edid: Clean up display_info stuff

Looks reasonable to me, adding a few more AMD people which probably want to take a look as well. Patch #3 and #4 are Reviewed-by: Christian König since they touch the radeon/amdgpu driver. Patch #1, #2 and #5 - #8 are Acked-by: Christian König . Regards, Christian. Am 03.08.2016 um 08:33

[PATCH] drm/rockchip: fix fbdev crash when not use DRM_FBDEV_EMULATION

On Wed, Aug 03, 2016 at 04:56:20PM +0800, Mark yao wrote: > On 2016年08月03日 16:46, Daniel Vetter wrote: > > On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote: > > > On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote: > > > > [1.162571] Unable to handle kernel NULL

[PATCH 0/4]: Picture aspect ratio support in DRM layer

On Wed, Aug 03, 2016 at 04:26:24PM +0530, Shashank Sharma wrote: > This patch series adds 4 patches. > - The first two patches add aspect ratio support in DRM layes > - Next two patches add new aspect ratios defined in CEA-861-F > supported for HDMI 2.0 4k modes. > > Adding aspect ratio support

RFC: hardware accelerated bitblt using dma engine

On 3 August 2016 at 13:33, Enrico Weigelt, metux IT consult wrote: > On 03.08.2016 01:12, Rob Clark wrote: > > Hi, > >>> Well, if it already does buffer allocation and mapping (which might >>> also involve copying around phyisical buffers), why not also add >>> copy-between-buffers ? >> >> except

[Intel-gfx] [PATCH 4/4] drm: Add and handle new aspect ratios in DRM layer

On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma wrote: > HDMI 2.0/CEA-861-F introduces two new aspect ratios: > - 64:27 > - 256:135 > > This patch: > - Adds new DRM flags for to represent these new aspect ratios. > - Adds new cases to handle these aspect ratios while converting > from

[PATCH 3/4] video: Add new aspect ratios for HDMI 2.0

On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma wrote: > HDMI 2.0/CEA-861-F introduces two new aspect ratios: > - 64:27 > - 256:135 > > This patch adds enumeration for the new aspect ratios > in the existing aspect ratio list. > > Signed-off-by: Shashank Sharma Reviewed-by: Sean Paul > --- >

RFC: hardware accelerated bitblt using dma engine

On Wed, Aug 03, 2016 at 11:24:37AM +0200, Marek Szyprowski wrote: > Hi Enrico, > > > On 2016-08-02 15:21, Enrico Weigelt, metux IT consult wrote: > > I'm currently thinking about adding an hw-accelerated bitblt operation. > > The idea goes like this: > > > > * we add some bitblt ioctl which

[PATCH 2/4] drm: Add aspect ratio parsing in DRM layer

On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma wrote: > Current DRM layer functions dont parse aspect ratio information s/dont/don't/ > while converting a user mode->kernel mode or viceversa. This s/viceversa/vice versa/ > causes modeset to pick mode with wrong aspect ratio, eventually >

[PATCH 1/4] drm: add picture aspect ratio flags

On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma wrote: > This patch adds drm flag bits for aspect ratio information > > Currently drm flag bits don't have field for mode's picture > aspect ratio. This field will help the driver to pick mode with > right aspect ratio, and help in setting right VIC

[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait

https://bugzilla.kernel.org/show_bug.cgi?id=151341 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

[PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.

On 6 July 2016 at 20:05, Mario Kleiner wrote: > For DP sinks which don't expose color depth via EDID, use > the drm_dp_sink_bpc() helper to derive the bpc of the sink. > > This should handle DP native sinks with the "Assume 6 bpc if EDID > doesn't tell us" as mandated by DP spec. It gives more

[PATCH v4 5/5] dma-buf/sync_file: only enable fence signalling on poll()

On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Signalling doesn't need to be enabled at sync_file creation, it is only > required if userspace waiting the fence to signal through poll(). > > Thus we delay fence_add_callback() until poll is called.

[Bug 91281] Tonga VCE 2160p encode fails with BO to small for addr

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/8bc8ea89/attachment-0001.html>

[Bug 97166] lockup during gameplay of Batman series of games

they are annyoing. Instructions can be found in the PC Gaming Wiki. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160

[bug report] drm/amdgpu/gfx7: set USER_SHADER_ARRAY_CONFIG based on disable_cu parameter

Hello Nicolai Hähnle, The patch 324c614a819a: "drm/amdgpu/gfx7: set USER_SHADER_ARRAY_CONFIG based on disable_cu parameter" from Jun 17, 2016, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5057 gfx_v7_0_get_cu_info() error: buffer overflow

RFC: hardware accelerated bitblt using dma engine

Hi Enrico, On 2016-08-02 15:21, Enrico Weigelt, metux IT consult wrote: > I'm currently thinking about adding an hw-accelerated bitblt operation. > The idea goes like this: > > * we add some bitblt ioctl which copies rects between bo's. >(it also handles memory layouts, pixfmt conversion,

[bug report] drm/amdgpu/gfx7: set USER_SHADER_ARRAY_CONFIG based on disable_cu parameter

On 03.08.2016 11:09, Dan Carpenter wrote: > Hello Nicolai Hähnle, > > The patch 324c614a819a: "drm/amdgpu/gfx7: set > USER_SHADER_ARRAY_CONFIG based on disable_cu parameter" from Jun 17, > 2016, leads to the following static checker warning: > > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5057

[PATCH 04/10] drm: make drm_vblank_{get,put}() static

Oh, nevermind... I saw the places that depends on changes on other legacy usage like drm_wait_on_vblank... (not trivial on intel_crt) and other cases... So better to just go with the static for now. Feel free to use: Reviewed-by: Rodrigo Vivi On Wed, Aug 3, 2016 at 12:22 AM, Daniel Vetter

libdrm-armada repository

On 08/02/2016 06:38 PM, Fabio Estevam wrote: > Hi Joshua, > > On Tue, Aug 2, 2016 at 8:09 PM, Joshua Clayton > wrote: >> Greetings Russell, >> I'm publishing an etnaviv yocto layer on github. > Cool! Could you please let us know when this layer becomes available? > > Thanks Sure, Fabio. It is

[Bug 97166] lockup during gameplay of Batman series of games

org/archives/dri-devel/attachments/20160803/8d6d8759/attachment.html>

libdrm-armada repository

On 08/02/2016 04:28 PM, Russell King wrote: > On Tue, Aug 02, 2016 at 04:09:58PM -0700, Joshua Clayton wrote: >> Greetings Russell, >> I'm publishing an etnaviv yocto layer on github. >> One of the components is libdrm-armada, which we get from >>

[PATCH] drm/rockchip: fix fbdev crash when not use DRM_FBDEV_EMULATION

On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote: > On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote: > > [1.162571] Unable to handle kernel NULL pointer dereference at virtual > > address 0200 > > [1.165656] Modules linked in: > > [1.165941] CPU: 5 PID: 143

[PATCH] drm/rockchip: fix fbdev crash when not use DRM_FBDEV_EMULATION

On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote: > [1.162571] Unable to handle kernel NULL pointer dereference at virtual > address 0200 > [1.165656] Modules linked in: > [1.165941] CPU: 5 PID: 143 Comm: kworker/5:2 Not tainted 4.4.15 #237 > [1.166506] Hardware name:

[PATCH v3 2/3] drm: Add API for capturing frame CRCs

On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote: > Adds files and directories to debugfs for controlling and reading frame > CRCs, per CRTC: > > dri/0/crtc-0/crc > dri/0/crtc-0/crc/control > dri/0/crtc-0/crc/data > > Drivers can implement the set_crc_source callback() in

[PATCH v3 3/3] drm/i915: Use new CRC debugfs API

On Fri, Jul 22, 2016 at 04:10:45PM +0200, Tomeu Vizoso wrote: > The core provides now an ABI to userspace for generation of frame CRCs, > so implement the ->set_crc_source() callback and reuse as much code as > possible with the previous ABI implementation. > > v2: > - Leave the legacy

[PATCH v3 2/3] drm: Add API for capturing frame CRCs

On Wed, Aug 03, 2016 at 10:06:38AM +0300, Ville Syrjälä wrote: > On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote: > > Adds files and directories to debugfs for controlling and reading frame > > CRCs, per CRTC: > > > > dri/0/crtc-0/crc > > dri/0/crtc-0/crc/control > >

[PATCH] drm: Avoid printing negative values for unsigned variables.

It was really strange to see negative vblank seqs on debug messages. It is rare to have that big number, but when it happens it is confusing and misleading. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/drm_irq.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v6 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Op 03-08-16 om 00:37 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this however, is

[PATCH v7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[Bug 94249] libdrm_amdgpu: Crash when built with clang

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/90d00785/attachment.html>

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

From: Ville Syrjälä It's perfectly legal for the sink to support 12bpc only for some lower resolution modes, while the higher resolution modes can only be used with 8bpc. So let's take the sink's max TMDS clock into account before we go and decide that a

[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

From: Ville Syrjälä Reduce the eyesore with a local variable. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[PATCH 08/10] drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()

From: Ville Syrjälä drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't even get

[PATCH 07/10] drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID

From: Ville Syrjälä It's not a good idea to leave stale cea_rev in the drm_display_info. The current EDID might not even have a CEA ext block in which case we'd end up leaving the stale value in place. Signed-off-by: Ville Syrjälä ---

[PATCH 06/10] drm/edid: Reduce the number of times we parse the CEA extension block

From: Ville Syrjälä Instead of parsing parts of the CEA extension block in two places to determine supported color formats and whatnot, let's just consolidate it to one function. This also makes it possible to neatly flatten drm_assign_hdmi_deep_color_info().

[PATCH 05/10] drm/edid: Don't pass around drm_display_info needlessly

From: Ville Syrjälä We already pass the connector to drm_add_display_info() and drm_assign_hdmi_deep_color_info(), so passing the connector->display_info also is pointless. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 11 --- 1 file

  1   2   >