I suspect some problem, because when I try sending patches to dri-devel, they
are neither getting delivered nor are waiting in moderation queue. Testing,
based on suggestions from #dri-devel IRC chat.
My apologies for spamming.
--
2.4.5
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/b45330b4/attachment.html>
http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/a78dc094/attachment-0001.html>
Already drm_iommu_attach_device checks whether support iommu internally.
It should clear channels always regardless iommu support. We didn't know
because we can detect the problem when iommu is enabled, so we don't
have to use drm_iommu_attach_device_if_possible and then we can remove
drm_iommu_att
Already drm_iommu_attach_device and drm_iommu_detach_device check
whether support iommu internally, so we don't have to call
is_drm_iommu_supported before call them.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--
drivers/gpu/drm/exynos/exynos7_drm_decon
If CONFIG_ARM_DMA_USE_IOMMU is disable, CONFIG_DRM_EXYNOS_IOMMU also is
disable. When CONFIG_DRM_EXYNOS_IOMMU is disable,
is_drm_iommu_supported() returns always false, so we can remove to use
ifdef CONFIG_ARM_DMA_USE_IOMMU in is_drm_iommu_supported().
Signed-off-by: Joonyoung Shim
---
drivers/g
INT_EN_VSYNC bit is not used when we clear vsync interrupt but
INT_STATUS_VSYNC bit should be related.
Also, if we want to enable vsync interrupt, we should write 1 in
INT_CLEAR_VSYNC bit before we set INT_EN_VSYNC bit. It will clear prior
vsync interrupt. You can check it from exynos mixer user m
Should be !g2d_userptr->vec, not !vec. This will fix below compile
error.
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function
âg2d_userptr_get_dma_addrâ:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:465:7: error: âvecâ undeclared
(first use in this function)
if (!vec)
Also, if g2d_userptr
On 06/29/2015 03:35 PM, Hyungwon Hwang wrote:
> Dear Marek,
>
> On Thu, 25 Jun 2015 15:10:12 +0200
> Marek Szyprowski wrote:
>
>> Some drivers (like Exynos mixer) calls
>> drm_iommu_attach_device_if_possible before registering crtc, so
>> additional check for NULL crtc pointer is required.
>
>
Hi Gustavo,
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This set improves exynos in a number of ways. The first five patches are
> general clean up/fixes.
>
> Patches 06 to 12 are improvements on top of the newly added atomic modesetting
> support.
I'm n
+Cc Hyungwon,
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_dp_commit() was getting called twice by exynos encoder core, once
> inside the .enable() call and another time by .commit() itself.
>
> The remove of the second call caused the wake of a bug, the ope
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct drm_crtc already stores the enabled state of the crtc
> thus we don't need to replicate enabled in exynos_drm_crtc.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 ---
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We already have the plane pointer in before calling .update_plane() or
> disable_plane() so pass it directly to those calls avoiding a new
> conversion from zpos to struct exynos_drm_plane.
>
> Signed-off-by: Gustavo Pado
On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> for us so we can get the correct value instead of relying on fixed value
> defined in a macro. But if vrefresh is still zero we should fail the
>
get it now.
I'll do it right this time and it won't be long before I finish it.
--
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-de
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/5388e197/attachment.html>
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/409222c3/attachment-0001.html>
u 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/20150702/518788b5/attachment.html>
4a8e0699.
I didn't realize it had already been applied.
--
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/20150702/237c530d/attachment.html>
On Thu, Jul 02, 2015 at 05:45:32PM +0100, Damien Lespiau wrote:
> On Thu, Jul 02, 2015 at 05:20:45PM +0100, Damien Lespiau wrote:
> > On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote:
> > > From: Kausal Malladi
> > >
> > > The DRM color management framework is targeting various hard
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/3135898c/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/38214ba3/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/b8df9410/attachment.html>
g 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/20150702/f341e46e/attachment-0001.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/f7da85bb/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/e748f879/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/fb9627d1/attachment.html>
Hi Joonyoung,
2015-07-02 Joonyoung Shim :
> On 06/24/2015 06:35 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> > for us so we can get the correct value instead of relying on fixed value
> > defined in a ma
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/0943e936/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/4b755d05/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/f6512a87/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/0cb71c5b/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/4ea69b2c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150702/58d9ec24/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/9989a8da/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/544a8afd/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/70cb7bff/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/33bc3baa/attachment.html>
On Thu, Jul 02, 2015 at 05:20:45PM +0100, Damien Lespiau wrote:
> On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote:
> > From: Kausal Malladi
> >
> > The DRM color management framework is targeting various hardware
> > platforms and drivers. Different platforms can have different col
On Wed, Jul 01, 2015 at 09:18:13PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch does the following:
> 1. Adds new files intel_color_manager(.c/.h)
> 2. Attaches color properties to CRTC while initialization
We usually order the series so that "it always works". In this case
On Wed, Jul 01, 2015 at 09:18:18PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> drm_property_replace_global_blob() is getting used by many wrapper
> functions to replace an existing blob with new values. Because this
> function was static, modules are forced to create wrapper functions
On Wed, Jul 01, 2015 at 09:18:17PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch adds new structures in DRM layer for Palette color correction.
> These structures will be used by user space agents to configure
> appropriate number of samples and Palette LUT for a platform.
>
On Wed, Jul 01, 2015 at 09:18:13PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch does the following:
> 1. Adds new files intel_color_manager(.c/.h)
> 2. Attaches color properties to CRTC while initialization
A small note that we could remove manager from the whole API name,
On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> The DRM color management framework is targeting various hardware
> platforms and drivers. Different platforms can have different color
> correction and enhancement capabilities.
>
> A commom user space app
From: Thierry Reding
Upon driver load, reset the VBLANK machinery to off to reflect the
hardware state. Since the ->reset() callback is called from the initial
drm_mode_config_reset() call, move the latter after the VBLANK machinery
initialization by drm_vblank_init().
Signed-off-by: Thierry Red
esktop.org/archives/dri-devel/attachments/20150702/3245f643/attachment.html>
On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> CHV/BSW platform supports various Gamma correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Adds the core function to prog
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/e89fcd2f/attachment.html>
http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/432de19a/attachment.html>
t/?id=e4339bc9886a26d75b924ad045c3ddd003f802c3
it seems to render fine.
--
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/20150702/
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/a53bd810/attachment.html>
freedesktop.org/archives/dri-devel/attachments/20150702/1d9233a2/attachment.html>
This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm
Transitional drivers might not have all the state frobbing lined up
yet. But since the initial code has been merged a lot more state was
added, so we really need this.
Cc: Daniel Stone
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 8 +---
drivers/gpu/drm/drm_plane_h
On Thu, Jul 02, 2015 at 02:27:30PM +0100, Daniel Stone wrote:
> Hi,
>
> > On 2 Jul 2015, at 2:16 pm, Daniel Vetter wrote:
> >
> > In
> >
> > commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
> > Author: Daniel Stone
> > Date: Fri May 22 13:34:45 2015 +0100
> >
> >drm/crtc_helper: Replace
On Thu, Jul 02, 2015 at 11:10:06AM +0300, Jani Nikula wrote:
> On Wed, 01 Jul 2015, Jarkko Sakkinen
> wrote:
> > The compat ioctl handler ends up calling access_ok() twice: first
> > indirectly inside compat_alloc_user_space() and then after returning
> > from that function. This patch fixes issu
On Thu, Jul 2, 2015 at 3:53 PM, Mark yao wrote:
> Hi Tomasz
> Thanks for your review, I will fix it soon.
>
> On 2015å¹´07æ02æ¥ 14:00, Tomasz Figa wrote:
>>
>> Hi Mark,
>>
>> Please see my comments inline.
>>
>> On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote:
>>>
>>> vop support yuv with
Hello,
On 2015-07-02 14:49, Joonyoung Shim wrote:
> Already drm_iommu_attach_device checks whether support iommu internally.
> It should clear channels always regardless iommu support. We didn't know
> because we can detect the problem when iommu is enabled, so we don't
> have to use drm_iommu_att
Hello,
On 2015-07-02 14:49, Joonyoung Shim wrote:
> Already drm_iommu_attach_device and drm_iommu_detach_device check
> whether support iommu internally, so we don't have to call
> is_drm_iommu_supported before call them.
>
> Signed-off-by: Joonyoung Shim
Tested-by: Marek Szyprowski
> ---
>
Daniel fixed the same issue for crtc states in
commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
Author: Daniel Stone
Date: Fri May 22 13:34:45 2015 +0100
drm/crtc_helper: Replace open-coded CRTC state helpers
Follow suite.
Cc: Daniel Stone
Signed-off-by: Daniel Vetter
---
drivers/gpu/d
In
commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
Author: Daniel Stone
Date: Fri May 22 13:34:45 2015 +0100
drm/crtc_helper: Replace open-coded CRTC state helpers
error handling code was broken, resulting in the first path not being
checked correctly. Fix this by using the same pattern a
Hello,
On 2015-07-02 14:49, Joonyoung Shim wrote:
> If CONFIG_ARM_DMA_USE_IOMMU is disable, CONFIG_DRM_EXYNOS_IOMMU also is
> disable. When CONFIG_DRM_EXYNOS_IOMMU is disable,
> is_drm_iommu_supported() returns always false, so we can remove to use
> ifdef CONFIG_ARM_DMA_USE_IOMMU in is_drm_iommu_
Hi Tomi,
Thank you for the patch.
On Thursday 02 July 2015 15:35:31 Tomi Valkeinen wrote:
> DRM allows planes to be partially off-screen, but DSS hardware does not.
> This patch adds the necessary check to reject plane configs if the plane
> is not fully inside the crtc.
>
> Signed-off-by: Tomi
From: Fabian Frederick
use mm.h definition
Cc: David Airlie
Cc: Tomi Valkeinen
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Fabian Frederick
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
align_pitch() uses ALIGN() to ensure the pitch is aligned to SGX's
requirement of 8 pixels. However, ALIGN() expects the alignment value to
be a power of two, which is not the case for 24 bits per pixels.
Use roundup() instead, which works for all alignments.
This fixes the error seen with 24 bit
If tiler_unpin() call in omap_gem_put_paddr() fails,
omap_gem_put_paddr() will immediately stop processing and return an
error.
This patch remoes that error checking, and also removes
omap_gem_put_paddr()'s return value, because:
* The caller of omap_gem_put_paddr() can do nothing if an error
omap_framebuffer_unpin() check the return value of omap_gem_put_paddr()
and return immediately if omap_gem_put_paddr() fails.
This patch removes the check for the return value, and also removes the
return value of omap_framebuffer_unpin(), because:
* Nothing checks the return value of omap_frame
The DMM driver uses a timeout of 1 ms to wait for DMM transaction to
finish. While DMM should always finish the operation within that time,
the timeout is rather strict. Small misbehavior of the system (e.g. an
irq taking too long) could trigger the timeout.
As the DMM is a critical piece of code
DRM allows planes to be partially off-screen, but DSS hardware does not.
This patch adds the necessary check to reject plane configs if the plane
is not fully inside the crtc.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++
1 file changed,
On a platform with no TILER (e.g. omap3, am43xx), when the user wants to
allocate buffer with flag OMAP_BO_SCANOUT, the buffer needs to be
allocated with dma_alloc_writecombine. For some reason the driver does
not return an error if that alloc fails, instead it continues without
backing memory. Thi
Hi,
This is v2 of this series. Changes to v1:
* updated according to the comments
* added fix for 24 bpp formats
* added PAGE_ALIGN cleanup that I have missed
Tomi
Fabian Frederick (1):
drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN
Tomi Valkeinen (6):
drm/omap: return error if dma_allo
In
commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
Author: Daniel Stone
Date: Fri May 22 13:34:45 2015 +0100
drm/crtc_helper: Replace open-coded CRTC state helpers
error handling code was broken, resulting in the first path not being
checked correctly. Fix this by using the same pattern a
hardware cursor windows only have some fixed size, and not support
width virtual, when move hardware cursor windows outside of left,
the display would be wrong, so this window can't for cursor now.
And Tag hardware cursor window as a overlay is wrong, will make
userspace wrong behaviour.
So just
On 2015å¹´07æ01æ¥ 19:52, Heiko Stübner wrote:
> Hi Mark,
>
> Am Mittwoch, 1. Juli 2015, 17:49:33 schrieb Mark Yao:
>> hardware cursor windows only have some fixed size, and not support
>> width virtual, when move hardware cursor windows outside of left,
>> the display would be wrong, so this wi
Hi Mark,
Please see my comments inline.
On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote:
> vop support yuv with NV12, NV16 and NV24, only 2 plane yuv.
>
> Signed-off-by: Mark Yao
>
> Changes in v2:
> - Uv buffer not support odd offset, align it.
> - Fix error display when move yuv image.
>
> --
From: Shixin Zeng
The length of each EDID block is EDID_LENGTH, and number of blocks is (1
+ edid->extensions)
This causes wrong EDID to be passed on, and is a regression introduced
by d2ed34362a52 (drm: Introduce helper for replacing blob properties)
Signed-off-by: Shixin Zeng
---
drivers/gp
Hi Tomasz
Thanks for your review, I will fix it soon.
On 2015å¹´07æ02æ¥ 14:00, Tomasz Figa wrote:
> Hi Mark,
>
> Please see my comments inline.
>
> On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote:
>> vop support yuv with NV12, NV16 and NV24, only 2 plane yuv.
>>
>> Signed-off-by: Mark Yao
Hi,
> On 2 Jul 2015, at 2:16 pm, Daniel Vetter wrote:
>
> In
>
> commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
> Author: Daniel Stone
> Date: Fri May 22 13:34:45 2015 +0100
>
>drm/crtc_helper: Replace open-coded CRTC state helpers
>
> error handling code was broken, resulting in the
Hi Linus -
I hear Dave is on vacation, so please pull this first batch of Intel
fixes for v4.2 directly. (Dave, do correct me if I'm wrong!)
Almost all of it is regression fixes all around, with cc: stable, and
then there's Ander's fix for one of the warnings you reported. We're
still working on
On 06/28/2015 12:27 PM, Dmitry Osipenko wrote:
> MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK
> owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted
> value, while unshifted should be used. Fix it by changing '_F' to '_V'.
>
> Signed-off-by: Dmitry Os
On 2015å¹´07æ02æ¥ 12:59, Tomasz Figa wrote:
> On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote:
>> vir_stride need number words of the virtual width, and fb->pitches
>> save bytes_per_pixel, so just div 4 switch to stride.
>>
>> Signed-off-by: Mark Yao
>> ---
>> Changes in v2: None
>>
>> driv
On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote:
> vir_stride need number words of the virtual width, and fb->pitches
> save bytes_per_pixel, so just div 4 switch to stride.
>
> Signed-off-by: Mark Yao
> ---
> Changes in v2: None
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c |2 +-
> 1 fil
On 02.07.2015 06:20, Alex Deucher wrote:
>
> Alex Deucher (4):
[...]
> Revert "drm/radeon: dont switch vt on suspend"
Do we have a plan for re-enabling this? It seems to work fine on my
machines, and it's kinda nice not to see any console spam during
suspend/resume.
--
Earthling Michel D
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/20150702/6e9aa318/attachment.html>
On 7/1/2015 6:06 PM, Emil Velikov wrote:
> Hi Michel,
>
> Although I cannot comment on the exact implementation I can give you
> general some tips which you might find useful.
>
Hi Emil,
> On 1 July 2015 at 16:28, Michel Thierry wrote:
>> Gen8+ supports 48-bit virtual addresses, but some objects
Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.
Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.
v2: extract small helper, apply to error paths
---
Sor
Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.
Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.
---
drivers/gpu/drm/radeon/radeon_device.c | 4 +++-
1
This was regressed by commit 39e7f6f8, although I don't know of any
actual issues caused by it.
The storage domain is read without TTM locking now, but the lock
never helped to prevent any actual races.
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_gem.c | 1 +
1 file changed,
We don't need to call the (expensive) radeon_bo_wait, checking the
fences via RCU is much faster. The reservation done by radeon_bo_wait
does not save us from any race conditions.
---
drivers/gpu/drm/radeon/radeon_gem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
On Wed, 01 Jul 2015, Jarkko Sakkinen wrote:
> The compat ioctl handler ends up calling access_ok() twice: first
> indirectly inside compat_alloc_user_space() and then after returning
> from that function. This patch fixes issue.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> drivers/gpu/drm/drm_ioc3
Hi Linus,
Dave is on vacation, so please pull this directly. First round of fixes for 4.2
for radeon and amdgpu. Stuff all over the place:
- hibernation, suspend fixes for radeon and amdgpu
- radeon audio fix
- amdgpu ioctl optimzations and fixes
- amdgpu VCE cs checker improvements
- misc bug fi
nts/20150702/08c7a913/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150702/1791dbcc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150702/579cfb2d/attachment-0001.html>
On Thu, Jul 2, 2015 at 5:41 AM, Grigori Goronzy wrote:
> We don't need to call the (expensive) radeon_bo_wait, checking the
> fences via RCU is much faster. The reservation done by radeon_bo_wait
> does not save us from any race conditions.
Can you add your signed-off by to these patches?
Alex
On Wed, Jun 24, 2015 at 2:59 AM, Maarten Lankhorst
wrote:
> This change updates the old_fb pointer only after acquiring the plane lock,
> if there are no properties the fb cannot have been changed either, so
> this works out correctly.
>
> Found in a discussion with Rob Clark.
>
> Cc: Rob Clark
>
On Wed, Jul 1, 2015 at 11:08 PM, Michel Dänzer wrote:
> On 02.07.2015 06:20, Alex Deucher wrote:
>>
>> Alex Deucher (4):
> [...]
>> Revert "drm/radeon: dont switch vt on suspend"
>
> Do we have a plan for re-enabling this? It seems to work fine on my
> machines, and it's kinda nice not to s
Hi,
On Thu, 2015-07-02 at 09:23 +0200, Daniel Vetter wrote:
> In
>
> commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
> Author: Daniel Stone
> Date: Fri May 22 13:34:45 2015 +0100
>
> drm/crtc_helper: Replace open-coded CRTC state helpers
>
> error handling code was broken, resulting in t
On Wed, Jul 01, 2015 at 12:24:37PM +0300, Jarkko Sakkinen wrote:
> The compat ioctl handler ends up calling access_ok() twice: first
> indirectly inside compat_alloc_user_space() and then after returning
> from that function. This patch fixes issue.
>
> Signed-off-by: Jarkko Sakkinen
Applied to
In
commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
Author: Daniel Stone
Date: Fri May 22 13:34:45 2015 +0100
drm/crtc_helper: Replace open-coded CRTC state helpers
error handling code was broken, resulting in the first path not being
checked correctly. Fix this by using the same pattern a
1 - 100 of 110 matches
Mail list logo
