[PULL] drm-intel-next

Hi Dave and Daniel, Here goes first pull request targeting 5.1 made out of 2 tags: drm-intel-next-2019-01-10: - Unwind failure on pinning the gen7 PPGTT (Chris) - Fastset updates to make sure DRRS and PSR are properly enabled (Hans) - Header include clean-up (Brajeswar, Jani) - Improvements and

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

Am 14.01.19 um 18:32 schrieb Ard Biesheuvel: [SNIP] - The existence of a linear region mapping with mismatched attributes is likely not the culprit here. (We do something similar with non-cache coherent DMA in other places). This is still rather problematic. The issue is that we often don't cr

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

https://bugs.freedesktop.org/show_bug.cgi?id=109135 --- Comment #18 from Alex Deucher --- (In reply to rmuncrief from comment #17) > Yes, As I said in the beginning if you don't set amdgpu.dpm=1 the system > boots but resume doesn't work. I presume it's because power management isn't > working. A

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

Am 14.01.19 um 20:13 schrieb Will Deacon: > On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote: >> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel: >> - The reason remapping the CPU side as cacheable does work >> (which I >> did test) is because the GPU's uncac

[Bug 109234] amdgpu random hangs with 5.0-rc2/4.21+

https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #17 from Sibren Vasse --- @bmilreu: Could you try this patch? It works for me. https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html -- You are receiving this mail because: You are the assignee for the bug.

Re: [PATCH] qcom-scm: Include header

Hi Chris, On Mon, Jan 14, 2019 at 5:54 PM Chris Healy wrote: > > Perhaps I am confused but it appears that this patch has already > landed upstream and got included in 5.0-rc2: The patch that Amit is referring is the following entry in MAINTAINERS file: +F: include/linux/qcom* so that the prop

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

https://bugs.freedesktop.org/show_bug.cgi?id=109135 --- Comment #19 from rmuncr...@humanavance.com --- Oh, I see. I wasn't aware of the change. I wondered in the beginning if things were different because I knew the explicit dc and dpm settings were a temporary work around, but unfortunately I did

[Bug 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue

https://bugzilla.kernel.org/show_bug.cgi?id=202261 --- Comment #4 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to Michel Dänzer from comment #3) > Looks like https://bugs.freedesktop.org/109234 => > https://lists.freedesktop.org/archives/dri-devel/2019-January/202909.html > and

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #95 from Brandon Wright --- (In reply to Michel Dänzer from comment #94) > (In reply to tempel.julian from comment #88) > > (TearFree however doesn't work well in general without amdgpu.dc=1). > > Can you elaborate on that? Maybe fi

[Bug 109359] Flickering and artifacts on dual 4K displays from RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=109359 Bug ID: 109359 Summary: Flickering and artifacts on dual 4K displays from RX 570 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

[Bug 109234] amdgpu random hangs with 5.0-rc2/4.21+

https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #18 from bmil...@gmail.com --- (In reply to Sibren Vasse from comment #17) > @bmilreu: Could you try this patch? It works for me. > https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html Sure, will report if it fi

[Bug 109359] Flickering and artifacts on dual 4K displays from RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=109359 Alex Deucher changed: What|Removed |Added CC||harry.wentl...@amd.com,

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

On 1/14/19 10:13 AM, Noralf Trønnes wrote: I see that you have this call chain: st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). That doesn't look safe. The st7586 driver allocates a tx_buf with size: size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay; wh

Re: [PATCH 1/3 v2] drm: rcar-du: add missing of_node_put

Hi Julia, On 14/01/2019 16:44, Julia Lawall wrote: > Add an of_node_put when the result of of_graph_get_remote_port_parent is > not available. > > Add a second of_node_put if no encoder is selected (encoder remains NULL). > > The semantic match that finds the first problem is as follows > (http:

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

On 1/11/19 2:12 PM, Noralf Trønnes wrote: This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili

[PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()

Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. Howev

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

On 1/14/19 3:50 PM, David Lechner wrote: On 1/14/19 10:13 AM, Noralf Trønnes wrote: I see that you have this call chain: st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). That doesn't look safe. The st7586 driver allocates a tx_buf with size: size_t bufsize = (mode->v

[Bug 95517] Constant GPU VM faults

https://bugs.freedesktop.org/show_bug.cgi?id=95517 Dima changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 14.01.2019 23.33, skrev David Lechner: > On 1/14/19 3:50 PM, David Lechner wrote: >> On 1/14/19 10:13 AM, Noralf Trønnes wrote: >>> >>> I see that you have this call chain: >>> st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). >>> >>> That doesn't look safe. The st7586 d

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 14.01.2019 23.06, skrev David Lechner: > On 1/11/19 2:12 PM, Noralf Trønnes wrote: >> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty >> handler. All flushing will now happen in the pipe functions. >> >> Also enable the damage plane property for all except repaper which

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 14.01.2019 23.33, skrev David Lechner: > On 1/14/19 3:50 PM, David Lechner wrote: >> On 1/14/19 10:13 AM, Noralf Trønnes wrote: >>> >>> I see that you have this call chain: >>> st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). >>> >>> That doesn't look safe. The st7586 d

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

On 1/14/19 4:43 PM, Noralf Trønnes wrote: Den 14.01.2019 23.33, skrev David Lechner: On 1/14/19 3:50 PM, David Lechner wrote: On 1/14/19 10:13 AM, Noralf Trønnes wrote: I see that you have this call chain: st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). That doesn't

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 15.01.2019 00.03, skrev David Lechner: > On 1/14/19 4:43 PM, Noralf Trønnes wrote: >> >> >> Den 14.01.2019 23.33, skrev David Lechner: >>> On 1/14/19 3:50 PM, David Lechner wrote: On 1/14/19 10:13 AM, Noralf Trønnes wrote: > > I see that you have this call chain: > st7586_pip

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

On 1/14/19 4:53 PM, Noralf Trønnes wrote: Den 14.01.2019 23.33, skrev David Lechner: On 1/14/19 3:50 PM, David Lechner wrote: On 1/14/19 10:13 AM, Noralf Trønnes wrote: I see that you have this call chain: st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty(). That doesn't

linux-next: build failure after merge of the mali-dp tree

Hi Liviu, After merging the mali-dp tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function 'komeda_pipeline_obj_add': drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:30: error: passing argument 1 of

Re: Armada DRM: bridge with componentized devices

[CC Lukas and linux-pm] On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote: > > On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux > wrote: [cut] > > > > This thread is discussing how to deal with Armada DRM, its use of the > > component helper, TDA998x's hybrid use of the component

[Bug 104362] GPU fault detected on wine-nine Path of Exile

https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #14 from Marek Olšák --- There is some branching and SGPR spilling, so I guess that's the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel m

[Bug 104362] GPU fault detected on wine-nine Path of Exile

https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #15 from nmr --- Marek forgive my ignorance but why would SGPR spilling or branching cause the hang? Is the shader just timing out somehow and the timeout resulting in a kernel module abort? -- You are receiving this mail because:

[Bug 104362] GPU fault detected on wine-nine Path of Exile

https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #16 from Marek Olšák --- The wave dump suggests that image_sample_lz might be responsible for the hang, but its SGPR inputs seem to contain valid descriptors. -- You are receiving this mail because: You are the assignee for the bug

[Bug 104362] GPU fault detected on wine-nine Path of Exile

https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #17 from Marek Olšák --- (In reply to nmr from comment #15) > Marek forgive my ignorance but why would SGPR spilling or branching cause > the hang? Is the shader just timing out somehow and the timeout resulting in > a kernel module

[Bug 109360] [AMD][TAHITI XT] dota2 vulkan texture glitches

https://bugs.freedesktop.org/show_bug.cgi?id=109360 Bug ID: 109360 Summary: [AMD][TAHITI XT] dota2 vulkan texture glitches Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper

On 1/11/19 10:05 AM, Andrew F. Davis wrote: The "unmapped" heap is very similar to the carveout heap except the backing memory is presumed to be unmappable by the host, in my specific case due to firewalls. This memory can still be allocated from and used by devices that do have access to the bac

Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap

On 1/11/19 10:05 AM, Andrew F. Davis wrote: Hello all, This is a set of (hopefully) non-controversial cleanups for the ION framework and current set of heaps. These were found as I start to familiarize myself with the framework to help in whatever way I can in getting all this up to the standard

[Bug 109361] [KBL-G][GL-es] several shader test cases failed to compile

https://bugs.freedesktop.org/show_bug.cgi?id=109361 Bug ID: 109361 Summary: [KBL-G][GL-es] several shader test cases failed to compile Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All)

[Bug 109361] [KBL-G][GL-es] several shader test cases failed to compile

https://bugs.freedesktop.org/show_bug.cgi?id=109361 Hai changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.o

[PATCH v3 5/5] drm/todo: Tick off some tinydrm entries

- Better manual-upload support for atomic The new damage helper has the necessary pieces to make this work. - tinydrm_gem_cma_prime_import_sg_table This is now moved to the CMA helper and can be set using the DRM_GEM_CMA_VMAP_DRIVER_OPS macro. - tinydrm_fb_create This is now covered by dr

[PATCH v3 3/5] drm/tinydrm: Use struct drm_rect

This prepares for the switch to drm_atomic_helper_dirtyfb() in the next patch. The damage helper returns a drm_rect so switch to that everywhere including using a pointer in the dirty functions. This is a non-functional change except for the debug print which looks a bit different. Signed-off-by:

[PATCH v3 4/5] drm/tinydrm: Use damage helper for dirtyfb

This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use

[PATCH v3 2/5] drm/damage-helper: Add drm_atomic_helper_damage_merged()

Useful for drivers that only care about the combined damage. v2: Remove unnecessary clearing of damage clips Cc: Deepak Rawat Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Reviewed-by: Sam Ravnborg --- drivers/gpu/drm/drm_damage_helper.c | 41 + include/dr

[PATCH v3 0/5] drm/tinydrm: Use damage helper for dirtyfb

David discovered a bug which gave memory corruption because the tx_buf was written past its end for st7586 which has a smaller tx_buf. The problem was that mipi_dbi_enable_flush() now calls directly into mipi_dbi_fb_dirty() instead of going via the tindyrm_device dirtyfb callback. Changes: - Inclu

[PATCH v3 1/5] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()

This adds a .fb_create helper that sets the .dirty callback to drm_atomic_helper_dirtyfb(). v2: Improve docs (Daniel) Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Reviewed-by: Sam Ravnborg --- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 50 +--- include/drm/drm_gem

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 15.01.2019 00.26, skrev David Lechner: > On 1/14/19 4:53 PM, Noralf Trønnes wrote: >> >> >> Den 14.01.2019 23.33, skrev David Lechner: >>> On 1/14/19 3:50 PM, David Lechner wrote: On 1/14/19 10:13 AM, Noralf Trønnes wrote: > > I see that you have this call chain: > st7586_pip

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

Den 15.01.2019 05.38, skrev Noralf Trønnes: > > > Den 15.01.2019 00.26, skrev David Lechner: >> On 1/14/19 4:53 PM, Noralf Trønnes wrote: >>> >>> >>> Den 14.01.2019 23.33, skrev David Lechner: On 1/14/19 3:50 PM, David Lechner wrote: > On 1/14/19 10:13 AM, Noralf Trønnes wrote: >>

Re: [PATCH v1 1/1] drm: fix alpha build after drm_util.h change

Hi all. Please do not apply. O-DAY found a similar bug when building ia64, but this time there is something else from irqflags.h that causes the error. So... > It was considered just to pull in interrupt.h but that would > pull in a lot of unused stuff. This seems to be the rigth solution anywa

[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

https://bugzilla.kernel.org/show_bug.cgi?id=202263 --- Comment #3 from Emre Işık (e.isi...@gmail.com) --- Created attachment 280481 --> https://bugzilla.kernel.org/attachment.cgi?id=280481&action=edit Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

https://bugzilla.kernel.org/show_bug.cgi?id=202263 --- Comment #2 from Emre Işık (e.isi...@gmail.com) --- Created attachment 280479 --> https://bugzilla.kernel.org/attachment.cgi?id=280479&action=edit dmesg.log -- You are receiving this mail because: You are watching the assignee of the bug. _

[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

https://bugzilla.kernel.org/show_bug.cgi?id=202263 --- Comment #4 from Emre Işık (e.isi...@gmail.com) --- (In reply to Alex Deucher from comment #1) > Please attach your full dmesg output form boot (so it doesn't get lost when > the pastebin goes away) and xorg log (if using X). Okey I uploaded t

[Bug 109345] drm-next-2018-12-14 -Linux PPC

https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #2 from Allan Cairns --- Micahel Hope these help Allan On 14/01/19 9:19 pm, bugzilla-dae...@freedesktop.org wrote: > > *Comment # 1 > on bug 109345

Re: [PATCH] drm/dp: annotate implicit fall throughs

On 1/14/19 2:27 PM, Mathieu Malaterre wrote: There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: include/linux/compiler.h:77:22: warning: this statement may fall throug

[PATCH v2 0/3] drm: Add panel support for PDA 91-00156-A0

From: Eugen Hristev Hello, This patch series adds support for PDA (Precision Design Associates, Inc.) vendor, and for the PDA 91-00156-A0 simple panel, together with the bindings. The series is on top of http://anongit.freedesktop.org/git/drm/drm.git drm-next branch. Changes in v2: - According

[PATCH v2 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.

From: Eugen Hristev Precision Design Associates, Inc. (PDA) manufactures standard and custom capacitive touch screens, LCD's embedded controllers and custom embedded software. They specialize in industrial, rugged and outdoor applications. Website: http://www.pdaatl.com/ Signed-off-by: Eugen Hri

Re: [PATCH] qcom-scm: Include header

Perhaps I am confused but it appears that this patch has already landed upstream and got included in 5.0-rc2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/qcom_scm.h?h=v5.0-rc2&id=2076607a20bd4dfba699185616cbbbce06d3fa59 On Mon, Jan 14, 2019 at 11:51 AM

[PATCH v9 00/22] Re-use nvram module

The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a /dev/nvram misc device. This module is used only by 32-bit PowerPC platforms. The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a /dev/nvram misc device. This module is now used only by x86 and m68k thanks to c

[PATCH] drm: radeon: annotate implicit fall through

There is a plan to build the kernel with -Wimplicit-fallthrough and this place in the code produced a warning (W=1). This commit remove the following warning: drivers/gpu/drm/radeon/evergreen_cs.c:1301:11: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathi

Re: drm/vc4: NULL ptr dereference during HDMI audio registration with next-20190111

On 1/13/2019 4:38 AM, Stefan Wahren wrote: Stefan Wahren hat am 12. Januar 2019 um 12:24 geschrieben: Hi, kernelci.org [1] noticed a NULL pointer dereference during HDMI audio registration with linux-next-20190111 on Raspberry Pi using bcm2835_defconfig. I was able to reproduce it, but co

Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

On Fri, 11 Jan 2019, Andrew F. Davis wrote: > Buffers may not be mapped from the CPU so skip cache maintenance here. > Accesses from the CPU to a cached heap should be bracketed with > {begin,end}_cpu_access calls so maintenance should not be needed anyway. > > Signed-off-by: Andrew F. Davis > -

[PATCH v2 2/3] dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0

From: Cristian Birsan PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Adding Device Tree bindings for this panel. Signed-off-by: Cristian Birsan [eugen.hris...@microchip.com]: specified backlight and supply

[PATCH v9 19/22] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC && CONFIG_NVRAM

This patch addresses inconsistencies in Mac framebuffer drivers and their use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM. The defined(CONFIG_NVRAM) condition is replaced with the weaker IS_REACHABLE(CONFIG_NVRAM) condition, like atari_scsi. Macintosh framebuffer drivers u

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote: > > On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote: > > ARM systems do not permit the use of anything other than cached > > mappings for system memory, since that memory may be mapped in the > > linear region as well, and the architecture does not

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Mon, 14 Jan 2019 at 12:38, Koenig, Christian wrote: > > Am 14.01.19 um 11:53 schrieb Ard Biesheuvel: > > On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote: > >> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote: > >>> ARM systems do not permit the use of anything other than cached > >>> mappings f

[PATCH] drm/amdgpu: Replace kzalloc with kcalloc

Replace kzalloc() function with its 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a, b, gfp) Also, improve the coding style and the use of sizeof during allocation by changing sizeof(struct dc_surface_update) and sizeof(struct

[PATCH v9 06/22] powerpc: Replace nvram_* extern declarations with standard header

Remove the nvram_read_byte() and nvram_write_byte() declarations in powerpc/include/asm/nvram.h and use the cross-platform static functions in linux/nvram.h instead. Tested-by: Stan Johnson Signed-off-by: Finn Thain --- Changed since v8: - Added nvram_read_byte() and nvram_write_byte() function

Re: [PATCH] video: offb: annotate implicit fall throughs

On 1/14/19 2:40 PM, Mathieu Malaterre wrote: There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: drivers/video/fbdev/offb.c:211:5: warning: this statement may fall thro

Re: [PATCH 3/3] drm/panel: simple: Add Evervision VGG804821 pannel support

Hi Sam, On 19-01-04 17:40, Sam Ravnborg wrote: > Hi Marco. > > In $subject pannel => panel Thanks for covering that, Thierry can you fix this inline? Regards, Marco > > Other than that, bonus points for specifying > all of .flags, .bus_format and .bus_flags > > Sam > _

Re: [PATCH] qcom-scm: Include header

There we go, I was definitely confused... Tnx On Mon, Jan 14, 2019 at 12:02 PM Fabio Estevam wrote: > > Hi Chris, > > On Mon, Jan 14, 2019 at 5:54 PM Chris Healy wrote: > > > > Perhaps I am confused but it appears that this patch has already > > landed upstream and got included in 5.0-rc2: > >

RE: [PATCH] staging: android: ion: add buffer flag update ioctl

>-Original Message- >From: Laura Abbott [mailto:labb...@redhat.com] >Sent: Friday, January 04, 2019 9:53 AM >To: Zengtao (B) ; sumit.sem...@linaro.org >Cc: Greg Kroah-Hartman ; Arve Hjønnevåg >; Todd Kjos ; Martijn Coenen >; Joel Fernandes ; >de...@driverdev.osuosl.org; dri-devel@lists.free

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

On Mon, 14 Jan 2019 at 19:10, Christoph Hellwig wrote: > > On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote: > > On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote: > > > > > > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote: > > > >> From the trace it looks like w

[PATCH v2 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel

From: Eugen Hristev PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Signed-off-by: Eugen Hristev --- drivers/gpu/drm/panel/panel-simple.c | 27 +++ 1 file changed, 27 insertions(+)

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote: > On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote: > > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote: > > > On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote: > > > > Commit 2db76d7c3c6d ("l

RE: [PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from drm_modeset_helper.h

Hi Sam, > -Original Message- > From: Sam Ravnborg [mailto:sam.ravnb...@gmail.com] On Behalf Of Sam Ravnborg > Sent: Saturday, January 12, 2019 10:33 PM > To: Alex Deucher ; Alexey Brodkin > ; Andrzej > Hajda ; Benjamin Gaignard > ; Chen Feng > ; Christian Konig ; Daniel > Vetter > ; Dav

[PATCH] drm/dp: annotate implicit fall throughs

There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] include/asm-generic

Re: [PATCH] qcom-scm: Include header

On Sun, Dec 30, 2018 at 1:21 AM Andy Gross wrote: > > On Sat, Dec 29, 2018 at 10:19:32AM -0200, Fabio Estevam wrote: > > Hi Bjorn, > > > > On Fri, Dec 28, 2018 at 10:27 PM Bjorn Andersson > > wrote: > > > > > Sorry about that, I forgot that the header file is not covered by the > > > MAINTAINERS

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

On Mon, 14 Jan 2019 at 19:13, Christoph Hellwig wrote: > > Hmm, I wonder if we are not actually using swiotlb in the end, > can you check if your dmesg contains this line or not? > > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) This line does not appear in my dmesg. > > If not I gues

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[+ BenH and MPE] On Mon, Jan 14, 2019 at 07:21:08PM +, Koenig, Christian wrote: > Am 14.01.19 um 20:13 schrieb Will Deacon: > > On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote: > >> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel: > >> - The reason remapping the CPU

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote: > Am 14.01.19 um 18:32 schrieb Ard Biesheuvel: > - The reason remapping the CPU side as cacheable does work (which > I > did test) is because the GPU's uncacheable accesses (which I > assume > a

[PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface

This switches the fbtft driver to use GPIO descriptors rather than numerical gpios: Utilize the GPIO library's intrinsic handling of OF GPIOs and polarity. If the line is flagged active low, gpiolib will deal with this. Remove gpios from platform device structure. Neither assign statically number

[PATCH] video: offb: annotate implicit fall throughs

There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: drivers/video/fbdev/offb.c:211:5: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbd

[PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface

This switches the fbtft driver to use GPIO descriptors rather than numerical gpios: Utilize the GPIO library's intrinsic handling of OF GPIOs and polarity. If the line is flagged active low, gpiolib will deal with this. Remove gpios from platform device structure. Neither assign statically number

<    1   2