Hi Russell,
å¨ 2015/8/10 23:48, Russell King - ARM Linux åé:
> On Sat, Aug 08, 2015 at 05:10:47PM +0100, Russell King wrote:
>> From: Yakir Yang
>>
>> Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card
>> driver could connect to this codec through the codec dai name
>> "dw-hdmi-i2s
On 08/06/2015 07:00 PM, Daniel Stone wrote:
> Hi Joonyoung,
>
> On 28 July 2015 at 09:53, Joonyoung Shim wrote:
>> static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
>> struct vm_area_struct *vma)
>> {
>> @@ -169,6 +159,11 @@ struct exynos_d
Hi Thierry,
å¨ 2015/8/10 21:17, Thierry Reding åé:
> On Mon, Aug 10, 2015 at 08:59:44PM +0800, Yakir Yang wrote:
>> Hi Thierry,
>>
>> å¨ 2015/8/10 18:00, Thierry Reding åé:
>>> On Sat, Aug 08, 2015 at 11:54:38AM +0800, Yakir Yang wrote:
>>> [...]
edp: edp at ff97 {
>>>
https://bugzilla.kernel.org/show_bug.cgi?id=102401
--- Comment #4 from Maxqia ---
Huh seems to be the EDID detection. Windows/xrandr --verbose seem to get the
EDID right but get-edid doesn't.
--
You are receiving this mail because:
You are watching the assignee of the bug.
/dri-devel/attachments/20150811/8cbb5f36/attachment.html>
The port is removed synchronously, but the connector delayed.
This causes a use after free which can cause a kernel BUG with
slug_debug=FPZU. This is fixed by freeing the port after the
connector.
This fixes a regression introduced with
6b8eeca65b18ae77e175cc2b6571731f0ee413bf
"drm/dp/mst: close d
Without this when a MST connector is removed drm_atomic_helper_set_config
can complain about set->mode && !set->num_connectors.
[ cut here ]
WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673
drm_atomic_helper_set_config+0x22e/0x420()
CPU: 2 PID: 2403 Co
On Tue, Aug 11, 2015 at 09:54:59AM +0200, Maarten Lankhorst wrote:
> Without this when a MST connector is removed drm_atomic_helper_set_config
> can complain about set->mode && !set->num_connectors.
>
> [ cut here ]
> WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_
On Tue, Aug 11, 2015 at 09:54:29AM +0200, Maarten Lankhorst wrote:
> The port is removed synchronously, but the connector delayed.
> This causes a use after free which can cause a kernel BUG with
> slug_debug=FPZU. This is fixed by freeing the port after the
> connector.
>
> This fixes a regressio
Hi Emil,
Do you have chance to look at this version?
Regards,
Jammy
-Original Message-
From: Jammy Zhou [mailto:jammy.z...@amd.com]
Sent: Thursday, August 06, 2015 8:39 PM
To: Emil Velikov
Cc: Zhou, Jammy
Subject: [PATCH] drm: add interface to get drm devices on the system v2
From: Emi
On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
>
> Signed
On 2015ë
08ì 11ì¼ 18:04, Inki Dae wrote:
> On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
>> Use the newly created wrapper drm_fb_helper functions instead of calling
>> core fbdev functions directly. They also simplify the fb_info creation.
>>
>> COMPILE TESTED ONLY.
>>
>> Cc: Inki Dae
>>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/10254d87/attachment.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/a5dc8275/attachment.html>
On Tue, 11 Aug 2015, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 09:54:29AM +0200, Maarten Lankhorst wrote:
>> The port is removed synchronously, but the connector delayed.
>> This causes a use after free which can cause a kernel BUG with
>> slug_debug=FPZU. This is fixed by freeing the port af
Hello Dave,
This serie of patches fix minor bugs around how driver sub-components are
bind and planes z-ordering.
The main part is about atomic support: using more atomic helpers allow us
to simplify the code (~300 lines removed) and to ahve a better match between
drm concepts (planes and crtc) an
Op 10-08-15 om 13:34 schreef Daniel Vetter:
> Instead of our own duplicated one. This fixes a bug in the driver
> unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> try to unregister the nonexistent fbdev drm_framebuffer.
>
> Cc: Archit Taneja
> Cc: Maarten Lankhorst
> Reporte
Op 10-08-15 om 13:34 schreef Daniel Vetter:
> Instead of our own duplicated one. This fixes a bug in the driver
> unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> try to unregister the nonexistent fbdev drm_framebuffer.
>
> Cc: Archit Taneja
> Cc: Maarten Lankhorst
> Reporte
From: Thierry Reding
This function can be used to duplicate an atomic state object. This is
useful for example to implement suspend/resume, where the state before
suspend can be saved and restored upon resume.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 90 +
From: Thierry Reding
Provide subsystem-level suspend and resume helpers that can be used to
implement suspend/resume on atomic mode-setting enabled drivers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 191
include/drm/drm_atomic_
From: Thierry Reding
Use the drm_atomic_helper_suspend() and drm_atomic_helper_resume()
helpers to implement subsystem-level suspend/resume.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 9 +
drivers/gpu/drm/tegra/drm.h | 2 ++
2 files changed, 11 insertions(+)
diff
On Tue, Aug 11, 2015 at 01:37:43PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This function can be used to duplicate an atomic state object. This is
> useful for example to implement suspend/resume, where the state before
> suspend can be saved and restored upon resume.
>
> Signed-o
Hey,
This patch series would be less complicated if you assume the caller locked
with drm_modeset_lock_all
and use the global acquire_ctx in each function. You're locking all state here
after all..
Also you should use drm_atomic_get_*_state instead of calling those
duplicate_state functions di
On Tue, Aug 11, 2015 at 01:37:43PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This function can be used to duplicate an atomic state object. This is
> useful for example to implement suspend/resume, where the state before
> suspend can be saved and restored upon resume.
>
> Signed-o
Op 11-08-15 om 13:37 schreef Thierry Reding:
> From: Thierry Reding
>
> Provide subsystem-level suspend and resume helpers that can be used to
> implement suspend/resume on atomic mode-setting enabled drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 191
>
On Tue, Aug 11, 2015 at 01:37:44PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Provide subsystem-level suspend and resume helpers that can be used to
> implement suspend/resume on atomic mode-setting enabled drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_ato
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3 insert
On Tue, Aug 11, 2015 at 01:25:08PM +0200, Maarten Lankhorst wrote:
> Op 10-08-15 om 13:34 schreef Daniel Vetter:
> > Instead of our own duplicated one. This fixes a bug in the driver
> > unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> > try to unregister the nonexistent fbdev
On 2015ë
08ì 11ì¼ 09:38, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-07 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
08ì 06ì¼ 22:31, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
>>> only a drm_encoder
Op 11-08-15 om 14:00 schreef Inki Dae:
> This patch fixes null pointer access incurred when
> encoder driver didn't set its own mode_fixup callback.
>
> mode_fixup callback shoudn't be called if the callback
> of drm_encoder_helper_funcs is NULL.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/dr
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Changelog v2:
- change it to else if
Signed-off-by: Inki Dae
Reviewed-by: Maarten Lankhorst
---
On 2015ë
07ì 22ì¼ 15:59, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Cc: Joonyoun
Hi Dave,
This pull request fixes memory leak and some issues related to
mixer and gscaler driver issues.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit bdce3e7c729907e303396690b2b23b972c6717be:
Merge branch 'msm-fixes-4.2' of
On Tue, Aug 11, 2015 at 09:13:54PM +0900, Inki Dae wrote:
> On 2015ë
08ì 11ì¼ 09:38, Gustavo Padovan wrote:
> > Hi Inki,
> >
> > 2015-08-07 Inki Dae :
> >
> >> Hi Gustavo,
> >>
> >> On 2015ë
08ì 06ì¼ 22:31, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan
> >>>
> >>> struct exynos_dr
On Tue, Aug 11, 2015 at 09:23:49PM +0900, Inki Dae wrote:
> This patch fixes null pointer access incurred when
> encoder driver didn't set its own mode_fixup callback.
>
> mode_fixup callback shoudn't be called if the callback
> of drm_encoder_helper_funcs is NULL.
>
> Changelog v2:
> - change it
WoW is only able to use OpenGL 3.0
natively atm.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/6d02ae17/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/dced6fa7/attachment.html>
p.org/archives/dri-devel/attachments/20150811/83bf7e04/attachment.html>
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/5d41a8b2/attachment.html>
|--- |NOTOURBUG
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/f31eef24/attachment.html>
Hi,
The idea is to create a GEM bo in one process and pass the prime handle of the
it to another process, which in turn uses the handle only to map and write.
This could be useful for Chrome OS architecture, where the Web content
("unpriviledged process") maps and CPU-draws a buffer, which was pr
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write a
From: Daniel Vetter
FIXME: Update kerneldoc for begin/end to make it clear that those are
for mmap too.
Open: Do we need a special indication that the begin/end is from
userspace mmap and not from kernel mmap?
There's also the question already about kernel internal users - vmap
and kmap interfa
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index e9c2bfd..8447ba4 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer referen
- Remove pattern_check(), which was walking through a useless iterator
- Remove superfluous PROT_WRITE from gem_mmap, in test_correct()
- Add binary file to .gitignore
Signed-off-by: Tiago Vignatti
---
tests/.gitignore | 1 +
tests/prime_mmap.c | 37 -
2 fi
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
p
This program can be used to detect when the writes don't land in scanout due
cache incoherency. Although this seems a problem inherently of non-LCC machines
("Atom"), this particular test catches a cache dirt on scanout on LLC machines
as well. It's inspired in Ville's kms_pwrite_crc.c and can be u
It requires i915 changes to add end_cpu_access().
Signed-off-by: Tiago Vignatti
---
tests/kms_mmap_write_crc.c | 63 --
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
index e24d535
On Tue, Aug 11, 2015 at 05:59:23PM -0300, Tiago Vignatti wrote:
> Userspace is the one in charge of flush CPU by wrapping mmap with
> begin{,end}_cpu_access.
>
> v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix
> return
> before transferring ownership when mmap fails.
> v3
y?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150811/488d61b8/attachment.html>
Hi Olof,
On 07/17/2015 01:51 PM, Maxime Coquelin wrote:
> Dear ARM SoC Maintainers,
>
> On 07/17/2015 01:45 PM, Benjamin Gaignard wrote:
>> STI drm drivers probe and bind using component framework was incorrect.
>> In addition to drivers fix DT update is needed to make all
>> sub-components
>> be
Wall time obtained from do_gettimeofday is susceptible to sudden jumps due to
user setting the time or due to NTP.
Raw monotonic time is constantly increasing time and isn't affected by NTP
adjustments better suited for comparing two timestamps in short intervals.
Signed-off-by: Abhilash Jindal
This addresses two issues that cause problems with viewperf maya-03 in
situation with memory pressure.
The first issue causes attempts to unreserve buffers if batched
reservation fails due to, for example, a signal pending. While previously
the ttm_eu api was resistant against this type of error,
This is a follow-up to the v1 posted in April:
http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro.
These were tested successfully by multiple people and solve two
tickets in Bugzilla:
https://bugzilla.kernel.org
56 matches
Mail list logo
