Re: [PATCH 0/6] drm: msm: A5XX zap shader

On 04/13/2017 02:45 AM, Jordan Crouse wrote: Hey Rob - Here is the stack of stuff to add the zap shader for msm-next. I left the code broken out as the first two changes are merged into the device specific tree and the third one has been seen before so this should hopefully cut down on

[Bug 100681] F1 2015 glitches (letters mainly)

https://bugs.freedesktop.org/show_bug.cgi?id=100681 --- Comment #6 from Michel Dänzer --- Might be fixed with LLVM r300791. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

https://bugzilla.kernel.org/show_bug.cgi?id=195465 --- Comment #3 from Michel Dänzer (mic...@daenzer.net) --- What exactly is the problem? The only suspicious thing in dmesg is the below, which indicates that the GPU's power management might not be working perfectly: [ 20.346154] cant't get

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

https://bugs.freedesktop.org/show_bug.cgi?id=100726 --- Comment #2 from Michel Dänzer --- It's unlikely that this is caused by the bisected commit. You'll need to test longer before declaring a commit as good. -- You are receiving this mail because: You are the assignee for

Re: [PATCH 3/3] drm/panel: add backlight dependency for sitronix-st7789v

On 04/20/2017 03:03 AM, Arnd Bergmann wrote: Without the dependency, we run into a link error: drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe': panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to `of_find_backlight_by_node' Fixes:

Re: [PATCH 2/3] drm/panel: S6E3HA2 needs backlight code

Hi Arnd, Thanks for your patch. On 04/20/2017 02:59 AM, Arnd Bergmann wrote: The new S6E3HA2 driver fails to link when backlight is disabled: ERROR: "backlight_device_register" [drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined! ERROR: "backlight_device_unregister"

[PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1]

Re: [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote: Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #26 from Zachary Michaels --- Also note that forcing VGT_STREAMOUT_SYNC, VGT_STREAMOUT_RESET, or VGT_FLUSH to be emitted on each call to si_draw_vbo (via si_emit_cache_flush) also appears to work around the

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #25 from Zachary Michaels --- These settings reproduce consistently on my W600 test machine: ./thrash -w 1920 -h 1080 -c 3 -t 1000 -m 10 -- You are receiving this mail because: You are the assignee

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #24 from Zachary Michaels --- Hi! There is a stress test here that we have been using to reproduce this issue: https://github.com/Oblong/thrasher Enabling debug tracing works around the issue. Specifically,

Re: [PATCH 2/2] drm/panel: simple: add support for NLT NL192108AC18-02D

On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote: > This adds support for the NLT Technologies NL192108AC18-02D > 15.6" LVDS FullHD TFT LCD panel, which can be supported > by the simple panel driver. > > Timings are taken from the preliminary datasheet, as a final > one is not yet

Re: [PATCH 1/2] dt-bindings: add vendor prefix for NLT Technologies, Ltd.

On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote: > NLT technologies is the former NEC display business, but changed its > name to NLT Technologies when forming a joint venture with > Shenzhen AVIC OPTOELECTRONICS, Ltd. > > Signed-off-by: Lucas Stach > --- >

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

Hi Arnd, On 19/04/17 18:59, Arnd Bergmann wrote: > When the media subsystem is built as a loadable module, a built-in > DRM driver cannot use the cec notifiers: > > drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove': > sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to >

Re: [PATCH v2] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

Thanks Vladis! Reviewed-by: Sinclair Yeh On Thu, Apr 06, 2017 at 02:33:40PM +0200, Vladis Dronov wrote: > The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is > a user-controlled 'uint32_t' value which is used as a loop count limit. > This can lead to a kernel

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

On Wed, Apr 19, 2017 at 10:21 PM, Laurent Pinchart wrote: >> >> This adds a dependency like we have for the other panel drivers. > > I believe the dependency should be made optional. DPI panels that don't need > backlight control should be supported by a kernel

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

Hi Arnd, Thank you for the patch. On Wednesday 19 Apr 2017 19:59:17 Arnd Bergmann wrote: > The panel driver gained support for backlight but fails to link now > when that is disabled: > > drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function > `panel_dpi_probe_of':

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt wrote: > Daniel Vetter writes: >> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote: >>> The FBDEV initialization would throw an error in dmesg, when we just >>> want to silently not initialize

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

On 20 April 2017 at 04:42, Dave Airlie wrote: > On 19 April 2017 at 22:07, Christian König wrote: >> Am 13.04.2017 um 03:41 schrieb Dave Airlie: >>> >>> Okay I've taken Chris's suggestions to heart and reworked things >>> around a sem_file to see how

Re: [PATCH] drm/etnaviv: add thermal dependency

On Wed, Apr 19, 2017 at 9:11 PM, Arnd Bergmann wrote: > When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is > built-in, we get a link error: > > drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': > etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34):

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

https://bugs.freedesktop.org/show_bug.cgi?id=100726 --- Comment #1 from hiwatari.se...@gmail.com --- Created attachment 130926 --> https://bugs.freedesktop.org/attachment.cgi?id=130926=edit Short video showing the issue -- You are receiving this mail because: You are the assignee for the

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

https://bugs.freedesktop.org/show_bug.cgi?id=100726 Bug ID: 100726 Summary: [REGRESSION][BISECTED] Severe flickering with an R9 290 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

On 19 April 2017 at 22:07, Christian König wrote: > Am 13.04.2017 um 03:41 schrieb Dave Airlie: >> >> Okay I've taken Chris's suggestions to heart and reworked things >> around a sem_file to see how they might look. >> >> This means the drm_syncobj are currently only

Re: [PATCH v2 4/5] nouveau_hwmon: Add support for auto_point attributes

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This patch creates a special group attributes for attrs like "*auto_point*". > We check if we have support for them, and if we do, we gather them all in > an attribute_group's structure which is the parameter

[PATCH] gpu: host1x: select IOMMU_IOVA

When IOMMU_IOVA is not built-in but host1x is, we get a link error: drivers/gpu/host1x/dev.o: In function `host1x_remove': dev.c:(.text.host1x_remove+0x50): undefined reference to `put_iova_domain' drivers/gpu/host1x/dev.o: In function `host1x_probe': dev.c:(.text.host1x_probe+0x31c): undefined

[PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse

When dma_addr_t and phys_addr_t are not the same size, we get a warning from the dma_alloc_wc function: drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init': drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of 'dma_alloc_wc' from incompatible pointer type

Re: X.org EVoC Ideas

Quoting Rob Clark (2017-04-18 11:27:14) > On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov > wrote: > > On 18 April 2017 at 16:48, Rob Clark wrote: > >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia > >> wrote: > >>> Hi

Re: [Nouveau] [PATCH v2 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > +static char *input_label = "GPU core"; This needs to be static const char input_label[] = "GPU core"; or at least static const char *const input_label = "GPU core"; -ilia

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

Got it, I'll make a v3 with that line in all patches. Thanks! On 19 April 2017 at 20:11, Ilia Mirkin wrote: > All kernel patches must have a Signed-off-by: $user. See >

[PATCH] drm/etnaviv: add thermal dependency

When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is built-in, we get a link error: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to `thermal_of_cooling_device_register'

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

All kernel patches must have a Signed-off-by: $user. See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This is a preparation for

[PATCH 3/3] drm/panel: add backlight dependency for sitronix-st7789v

Without the dependency, we run into a link error: drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe': panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to `of_find_backlight_by_node' Fixes: 7142afb3a186 ("drm/panel: Add driver for sitronix ST7789V

[PATCH 2/3] drm/panel: S6E3HA2 needs backlight code

The new S6E3HA2 driver fails to link when backlight is disabled: ERROR: "backlight_device_register" [drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined! ERROR: "backlight_device_unregister" [drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined! This adds a Kconfig dependency like

[PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

The panel driver gained support for backlight but fails to link now when that is disabled: drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of': panel-dpi.c:(.text.panel_dpi_probe_of+0xe8): undefined reference to `of_find_backlight_by_node' This adds a dependency like

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

Daniel Vetter writes: > On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote: >> The FBDEV initialization would throw an error in dmesg, when we just >> want to silently not initialize fbdev on a V3D-only VC4 instance. >> >> Signed-off-by: Eric Anholt

[Bug 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

https://bugzilla.kernel.org/show_bug.cgi?id=195465 --- Comment #2 from Hugo Andrade (hugo.s...@gmail.com) --- Created attachment 255929 --> https://bugzilla.kernel.org/attachment.cgi?id=255929=edit lshw -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

https://bugzilla.kernel.org/show_bug.cgi?id=195465 --- Comment #1 from Hugo Andrade (hugo.s...@gmail.com) --- Created attachment 255927 --> https://bugzilla.kernel.org/attachment.cgi?id=255927=edit Lspci -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

On 04/19/2017 05:07 AM, Christian König wrote: Am 13.04.2017 um 03:41 schrieb Dave Airlie: Okay I've taken Chris's suggestions to heart and reworked things around a sem_file to see how they might look. This means the drm_syncobj are currently only useful for semaphores, the flags field could

[Bug 195465] New: AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

https://bugzilla.kernel.org/show_bug.cgi?id=195465 Bug ID: 195465 Summary: AMD Hybrid graphic dont work, R7 M260/M265 (Topaz) Product: Drivers Version: 2.5 Kernel Version: 4.9.0-2-amd64 Hardware: x86-64 OS: Linux

[PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

When the media subsystem is built as a loadable module, a built-in DRM driver cannot use the cec notifiers: drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove': sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to `cec_notifier_set_phys_addr'

[PATCH] [media] exynos_hdmi: improve MEDIA_CEC_NOTIFIER dependency

When the media subsystem is built as a loadable module, a built-in DRM driver cannot use the cec notifiers: drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_get_modes': exynos_hdmi.c:(.text.hdmi_get_modes+0x80): undefined reference to `cec_notifier_set_phys_addr_from_edid'

Re: [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Minor nits, otherwise the vmwgfx part, Reviewed-by: Sinclair Yeh On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote: > Seeing the kunmap_atomic dma_buf_op shares the same name with a macro s^ > in higmem.h, the former can be

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

https://bugs.freedesktop.org/show_bug.cgi?id=92258 --- Comment #49 from russianneuroman...@ya.ru --- By the way, seems like issue is much easier to reproduce with Steam desktop notifications. Try to download something small, and it will show "download completed" notification, or ask someone to

[PATCH] drm/cec: Add CEC over Aux register definitions

From: Clint Taylor Adding DPCD register definitions from the DP 1.3 specification for CEC over AUX support. Signed-off-by: Clint Taylor --- include/drm/drm_dp_helper.h | 59 +++ 1 file changed,

drm-tip/drm-tip boot: 114 boots: 3 failed, 109 passed with 2 offline (v4.11-rc7-1959-g3ae84ad0eb45)

drm-tip/drm-tip boot: 114 boots: 3 failed, 109 passed with 2 offline (v4.11-rc7-1959-g3ae84ad0eb45) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/ Full Build Summary:

Re: [PATCH 04/11] drm: parse ycbcr420 vcb block

Regards Shashank On 4/8/2017 11:13 PM, Emil Velikov wrote: Hi Shashank, On 7 April 2017 at 17:39, Shashank Sharma wrote: + u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map; for (i = 0; i < len; i++) { struct

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

Regards Shashank On 4/10/2017 3:17 PM, Andrzej Hajda wrote: On 07.04.2017 18:39, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as

Re: [PATCH 07/11] drm: set output colorspace in AVI infoframe

Regards Shashank On 4/12/2017 3:19 PM, Jose Abreu wrote: Hi Shashank, On 07-04-2017 17:39, Shashank Sharma wrote: HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI

Re: [PATCH 06/11] drm: create hdmi output property

Hello Jose, Sorry for delay in response, I was on vacation. Please find my comments inline. Regards Shashank On 4/12/2017 3:28 PM, Jose Abreu wrote: Hi Shashank, On 07-04-2017 17:39, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and

Re: [PATCH v4.1 01/9] drm/atomic: Handle aspect ratio and scaling mode in core, v2.

On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote: > This is required to for i915 to convert connector properties to atomic. > > Changes since v1: > - Add docbook info. (danvet) > - Change picture_aspect_ratio to enum hdmi_picture_aspect. > > Signed-off-by: Maarten Lankhorst

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

https://bugs.freedesktop.org/show_bug.cgi?id=92258 --- Comment #48 from russianneuroman...@ya.ru --- Issue is still reproducible with Linux 4.11rc7 and Mesa 17.2-git. -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 100591] [AMD APU A9-9410] Kernel hang when using graphics acceleration

https://bugs.freedesktop.org/show_bug.cgi?id=100591 --- Comment #7 from Alex Deucher --- https://patchwork.kernel.org/patch/9669611/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing

Re: [PATCH] drm: i915: Avoid format string expansion from engine names

On Tue, 11 Apr 2017, Kees Cook wrote: > While highly unlikely, this makes sure that the string built from > engine names won't be processed as a format string. > > Signed-off-by: Kees Cook Pushed to drm-intel-next-queued, thanks for the patch. BR,

Re: [PATCH 1/6] drm: Add writeback connector type

On Wed, Apr 19, 2017 at 01:34:34PM +0200, Boris Brezillon wrote: On Wed, 19 Apr 2017 10:51:23 +0100 Brian Starkey wrote: [snip] Could you expand a bit on how you think planes fit better? Just had the impression that the writeback feature was conceptually closer to a

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

Hi Daniel, On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote: > On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote: > > Most of the items have been taken care of by a clean up series. Remove > > the completed items and add a few new ones. > > > > Signed-off-by: Laura Abbott

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1959-g3ae84ad0eb45)

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1959-g3ae84ad0eb45) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc7-1959-g3ae84ad0eb45 Git Commit:

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > > >> native endian packed colour values. > > > > > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get > > >

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

Am 13.04.2017 um 03:41 schrieb Dave Airlie: Okay I've taken Chris's suggestions to heart and reworked things around a sem_file to see how they might look. This means the drm_syncobj are currently only useful for semaphores, the flags field could be used in future to use it for other things, and

[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770

https://bugs.freedesktop.org/show_bug.cgi?id=100712 --- Comment #5 from Julien Isorce --- (In reply to Michel Dänzer from comment #4) > (In reply to Julien Isorce from comment #0) > > In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved > > >

Re: [PATCH 3/7] sync_file: split out fence_file base class from sync_file.

Am 13.04.2017 um 03:41 schrieb Dave Airlie: From: Dave Airlie This just splits out a common base object to be shared between sync_file and sem_files. I don't think I like that approach. A good argument of using sync_file instead of self coding it was to be able to be

drm-tip/drm-tip boot: 86 boots: 3 failed, 81 passed with 2 offline (v4.11-rc7-1958-g05040c47d415)

drm-tip/drm-tip boot: 86 boots: 3 failed, 81 passed with 2 offline (v4.11-rc7-1958-g05040c47d415) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/ Full Build Summary:

Re: [PATCH 1/6] drm: Add writeback connector type

On Wed, 19 Apr 2017 10:51:23 +0100 Brian Starkey wrote: > On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote: > >Hi Brian, > > > >On Tue, 18 Apr 2017 18:34:43 +0100 > >Brian Starkey wrote: > > > >> >> @@ -214,6 +214,19 @@ struct

[Bug 96296] clpeak causes a GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=96296 --- Comment #7 from ricardo.riba...@gmail.com --- Created attachment 130914 --> https://bugs.freedesktop.org/attachment.cgi?id=130914=edit AMD PALM (DRM 2.49.0 / 4.10.0-qtec-standard, LLVM 4.0.1 + MESA 17.0.3 -- You are receiving this mail

[Bug 96296] clpeak causes a GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=96296 --- Comment #6 from ricardo.riba...@gmail.com --- Using llvm 4.0.1 and the latest git commit from libclc ( 17648cd846390e294feafef21c32c7106eac1e24 ): I am getting a cpu endless loop with clpeak, fixable with ctrl+c. Other samples, such as

drm-tip/drm-tip boot: 16 boots: 2 failed, 14 passed (v4.11-rc7-1957-g06b36a78fe41)

drm-tip/drm-tip boot: 16 boots: 2 failed, 14 passed (v4.11-rc7-1957-g06b36a78fe41) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/ Full Build Summary:

Re: [PATCH 1/6] drm: Add writeback connector type

On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote: Hi Brian, On Tue, 18 Apr 2017 18:34:43 +0100 Brian Starkey wrote: >> @@ -214,6 +214,19 @@ struct drm_connector_state { >>struct drm_encoder *best_encoder; >> >>struct drm_atomic_state

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote: > Most of the items have been taken care of by a clean up series. Remove > the completed items and add a few new ones. > > Signed-off-by: Laura Abbott > --- > drivers/staging/android/TODO | 21

Re: [Linaro-mm-sig] [PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client

On Tue, Apr 18, 2017 at 11:27:12AM -0700, Laura Abbott wrote: > ion_handle was introduced as an abstraction to represent a reference to > a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf > emerged as the preferred standard for use in the kernel. This has made > the

Re: [Linaro-mm-sig] [PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress

On Tue, Apr 18, 2017 at 11:27:07AM -0700, Laura Abbott wrote: > Several of the Ion ioctls were designed in such a way that they > necessitate compat ioctls. We're breaking a bunch of other ABIs and > cleaning stuff up anyway so let's follow the ioctl guidelines and clean > things up while everyone

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1958-g05040c47d415)

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1958-g05040c47d415) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc7-1958-g05040c47d415 Git Commit:

drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc7-1957-g06b36a78fe41)

drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc7-1957-g06b36a78fe41) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc7-1957-g06b36a78fe41

[Bug 100591] [AMD APU A9-9410] Kernel hang when using graphics acceleration

https://bugs.freedesktop.org/show_bug.cgi?id=100591 --- Comment #6 from splitt --- Same hang here, same CPU : booting with kernel parameter amd_iommu=off solved the problem. For more details, please search for stoney patch disable ATS. ++ -- You are receiving this mail

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Wed, 19 Apr 2017 10:01:47 +0900 Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > > Hi, > > > >>> Quite true that this proves nothing. However one should note that > >>> fbcon -> fbdev works, > >> > >> BTW, this supports Gerd's patch, since the KMS

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

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #8 from omegap...@startmail.com --- For anyone else having this issue, looking through the xrandr output allows you to make a workaround, for me: === xrandr --output DisplayPort-0