IUM_DDEBUG.
Kernel: 4.7.0-gentoo
Mesa: git-6fb6201
LLVM: r277571
--
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/20160803/0f97d397/attachment.html>
The conversion of the rcar-du driver from the I2C slave encoder to the
DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
the bridge from being handled automatically by the DRM core. Fix it.
Fixes: 1d926114d8f4 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi
encode
ent hardware capabilities.
--
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/20160803/1df48515/attachment-0001.html>
Hi Archit,
On Tuesday 19 Jul 2016 12:06:41 Archit Taneja wrote:
> Hi Dave,
>
> This is an update to the previous drm bridge pull request. The ADV7511
> driver's conversion from slave encoder to bridge meant that its users
> (the rcar-du kms driver) should use the bridge interface too. This pull
>
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 04:15:04
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ä
> ---
>
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
!DRIVER_MODESET
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 fla
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
d
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.
> >
> >
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 untyped
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 ++
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 th
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 ---
drivers/gpu/drm/i
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 dele
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 D
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 of
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 +-
include/drm/drmP.
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 |
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 ++
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 u
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 let
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
available
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 way
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 fbd
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 ? pr
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 task_cred
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 *
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 f
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.
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
> ---
> drivers/gp
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
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
hment 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>
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 w
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 woul
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 handl
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,
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 - 6
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] Modu
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
---
drivers/gpu
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 -
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
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
---
in
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
[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] Wor
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(-)
diff
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 ---
incl
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 numbe
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 review
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 Cho
> 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 get
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 han
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 --git
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 s
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
---
drivers/gpu
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 b/d
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
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 sleep
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
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 a/dr
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 b/drivers/gpu/
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 a/drivers/gpu/drm/drm_irq
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 a/drivers/gpu/drm/nouveau/nouveau_
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
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
> > r
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 fo
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 sh
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
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 pointer
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
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
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 user->kern
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
> ---
>
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 copi
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
> caui
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
https://bugzilla.kernel.org/show_bug.cgi?id=151341
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
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 acc
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. It
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/20160803/8bc8ea89/attachment-0001.html>
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
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 '
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, etc
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 gfx
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 wr
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 a
org/archives/dri-devel/attachments/20160803/8d6d8759/attachment.html>
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
>> git://ftp.arm.linux.org.uk/~rmk/libdrm-armada.git
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 Co
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: R
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 drm_crtc_fun
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 impleme
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
> > dri/0/crtc-0/cr
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 a/dr
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 th
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 full
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>
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 particular mode can
be used with 12bpc.
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
b/drivers/gpu/drm/i915/intel_display.
1 - 100 of 127 matches
Mail list logo
