On Thu, Jun 27, 2019 at 2:01 AM Daniel Vetter wrote:
>
> btw reminds me: I guess it would be good to have a per-type .total
> read-only exposed, so that userspace has an idea of how much there is?
> ttm is trying to be agnostic to the allocator that's used to manage a
> memory type/resource, so
I have agreed with Boris Brezillon that we will share the
maintainer role for the drm/atmel_hlcdc driver.
Nicolas Ferre from Microchip has donated a few boards that
allows me to test things - thanks!
Signed-off-by: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc:
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/video/fbdev/mmp/fb/mmpfb.c | 1 -
1 file changed, 1 deletion(-)
diff
On Thu, Jun 27, 2019 at 7:20 PM Koenig, Christian
wrote:
>
> Am 27.06.19 um 19:10 schrieb Daniel Vetter:
> > On Thu, Jun 27, 2019 at 03:48:06PM +, Koenig, Christian wrote:
> >> Am 27.06.19 um 17:34 schrieb Daniel Vetter:
> >>> On Thu, Jun 27, 2019 at 3:19 PM Christian König
> >>> wrote:
>
On Thu, Jun 27, 2019 at 04:17:09PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 2:01 AM Daniel Vetter wrote:
> > btw reminds me: I guess it would be good to have a per-type .total
> > read-only exposed, so that userspace has an idea of how much there is?
> > ttm is trying to be agnostic to
On 25/06/2019 11:54, Andrzej Hajda wrote:
> On 24.04.2019 15:22, Matt Redfearn wrote:
>> In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
>> which attach to the DSI host via mipi_dsi_attach() at probe time, the
>> ADV7533 bridge device does not. Instead it defers this to the
Hi
Am 27.06.19 um 17:16 schrieb Gerd Hoffmann:
> Hi,
>
>> 1) Introduce a default_placement field in struct drm_gem_vram_helper
>> where this flag can be configured. I'd favor this option.
>
>> 2) Introduce a separate callback function for pinning to vram. The
>> driver would have to set the
On Thu, Jun 27, 2019 at 04:44:38PM +0200, Lucas Stach wrote:
> When something goes wrong in the GPU init after the cmdbuf suballocator
> has been constructed, we fail to destory it properly. This causes havok
> later when the GPU is unbound due to a module unload or similar.
>
> Signed-off-by:
Am 27.06.19 um 19:10 schrieb Daniel Vetter:
> On Thu, Jun 27, 2019 at 03:48:06PM +, Koenig, Christian wrote:
>> Am 27.06.19 um 17:34 schrieb Daniel Vetter:
>>> On Thu, Jun 27, 2019 at 3:19 PM Christian König
>>> wrote:
Am 27.06.19 um 12:43 schrieb Daniel Vetter:
> On Thu, Jun 27,
On Thu, Jun 27, 2019 at 9:53 AM Steven Price wrote:
>
> drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
> rename it to remove the _dumb and add a comment that it can be used by
> shmem clients.
>
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/drm_dumb_buffers.c
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #14 from tempel.jul...@gmail.com ---
Well, it's always atomic modesetting that breaks downstream.
Some fixes for 5.1 definitely seem to have improved the situation, as current
drm-next 440e80ce02cde7b810e4eb555768c2d77e7a27c8 shows
On Thu, Jun 27, 2019 at 7:31 PM Jonathan Corbet wrote:
>
> On Wed, 26 Jun 2019 23:27:35 +0200
> Daniel Vetter wrote:
>
> > On Wed, Jun 26, 2019 at 01:14:13PM -0300, Mauro Carvalho Chehab wrote:
> > > Due to two patches being applied about the same time, the
> > > reference for modedb.rst file
Quoting Brendan Higgins (2019-06-26 16:00:40)
> On Tue, Jun 25, 2019 at 8:41 PM Stephen Boyd wrote:
>
> > scenario like below, but where it is a problem. There could be three
> > CPUs, or even one CPU and three threads if you want to describe the
> > extra thread scenario.
> >
> > Here's my
On Thu, Jun 27, 2019 at 02:42:43PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 1:43 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 26, 2019 at 06:41:32PM -0400, Kenny Ho wrote:
> > > So without the sharing restriction and some kind of ownership
> > > structure, we will have to migrate/change
On Thu, Jun 27, 2019 at 11:57:34AM -0600, Rob Herring wrote:
> On Thu, Jun 27, 2019 at 9:53 AM Steven Price wrote:
> >
> > drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
> > rename it to remove the _dumb and add a comment that it can be used by
> > shmem clients.
> >
> >
On Thu, Jun 27, 2019 at 07:34:10PM +0200, Thomas Zimmermann wrote:
> The ast driver's struct ast_framebuffer is a buffer object with GEM
> interface. There are already GEM framebuffer helpers that implement
> the same functionality. Convert ast to these.
>
> Signed-off-by: Thomas Zimmermann
Often there are many similar modes, which cannot be selected
via modetest due to its simple string matching.
This change adds a mode index in the display output, which can
then be used to specify a specific modeline to be set.
Cc: Ilia Mirkin
Cc: Rob Clark
Cc: Bjorn Andersson
Cc: Sumit Semwal
Add support for the LCD panels that must be driven with the
Sharp-specific signals SPL, CLS, REV, PS.
An example of such panel is the LS020B1DD01D supported by the
panel-simple DRM panel driver.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 64
Simplify a bit the probe function by using the newly introduced
devm_platform_ioremap_resource(), instead of having to call
platform_get_resource() followed by devm_ioremap_resource().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +---
1 file changed, 1
Add support for the LCD panels with a serial 8-bit bus, where the color
components of each 24-bit pixel are sent sequentially.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
Hi,
On Sat, Jun 08, 2019 at 12:55:39PM +0200, Wolfram Sang wrote:
> While preparing a refactoring series, I noticed that some drivers use a
> complicated way of determining the adapter of a client. The easy way is
> to use the intended pointer: client->adapter
>
> These drivers do:
>
On Thu, Jun 27, 2019 at 1:43 AM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 06:41:32PM -0400, Kenny Ho wrote:
> > So without the sharing restriction and some kind of ownership
> > structure, we will have to migrate/change the owner of the buffer when
> > the cgroup that created the buffer
When something goes wrong in the GPU init after the cmdbuf suballocator
has been constructed, we fail to destory it properly. This causes havok
later when the GPU is unbound due to a module unload or similar.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +--
1
On Tue, Jun 04, 2019 at 01:39:29AM +0200, Marek Vasut wrote:
> Use hash table instead of ad-hoc arrays.
>
> Signed-off-by: Marek Vasut
> Cc: Christian Gmeiner
> Cc: Lucas Stach
> ---
> etnaviv/etnaviv_bo.c | 6 +++---
> etnaviv/etnaviv_cmd_stream.c | 31
On Thu, Jun 27, 2019 at 3:19 PM Christian König
wrote:
>
> Am 27.06.19 um 12:43 schrieb Daniel Vetter:
> > On Thu, Jun 27, 2019 at 12:18 PM Christian König
> > wrote:
> >> While freeing up memory it is easier to remove a fence from a reservation
> >> object instead of signaling it and installing
On Thu, Jun 27, 2019 at 04:49:30PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 27.06.2019, 15:32 +0100 schrieb Russell King - ARM Linux
> admin:
> > On Thu, Jun 27, 2019 at 11:04:17AM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Thu, Jun 27, 2019 at 11:20:15AM +0200, Lucas Stach
On Thu, 27 Jun 2019, Stanislav Lisovskiy wrote:
> Added edid checking to dp and hdmi edid setting functions, which
> are called from detect hooks. The result currently is propagated
> to calling layer using drm_connector->change_counter(proposed by Daniel
> Vetter).
> drm_helper_hpd_irq_event
Add COMPILE_TEST support to mmp display subsystem for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/mmp/Kconfig|2 +-
drivers/video/fbdev/mmp/hw/Kconfig |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
Index:
Use ->screen_buffer instead of ->screen_base in mmpfb driver.
[ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
pointer") for details. ]
Also fix all other sparse warnings about using incorrect types in
mmp display subsystem.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
On Thu, Jun 27, 2019 at 12:21:39PM +1000, Dave Airlie wrote:
> On Wed, 26 Jun 2019 at 08:34, Rob Clark wrote:
> >
> > Hi Dave,
> >
>
> Naughty naughty rebase.
>
> dim: f47bee2ba447 ("drm/msm/a3xx: remove TPL1 regs from snapshot"):
> Subject in fixes line doesn't match referenced commit:
> dim:
Hi,
> 1) Introduce a default_placement field in struct drm_gem_vram_helper
> where this flag can be configured. I'd favor this option.
> 2) Introduce a separate callback function for pinning to vram. The
> driver would have to set the correct function pointers.
> 3) Pin the fb console
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #24 from tempel.jul...@gmail.com ---
I've mentioned kwin-lowlatency in this ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=108917#add_comment
It can be used as some kind of workaround for this wine issue, as the stutter
panfrost_ioctl_mmap_bo() contains a reimplementation of
drm_gem_map_offset() but with a bug - it allows mapping imported
objects (without going through the exporter). Fix this by switching to
use the newly renamed drm_gem_map_offset() function instead which has
the bonus of simplifying the code.
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb and add a comment that it can be used by
shmem clients.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 9 ++---
Panfrost has a re-implementation of drm_gem_dumb_map_offset() with an
extra bug regarding the handling of imported buffers. However we don't
really want Panfrost calling _dumb functions because it's not a KMS
driver.
This series renames drm_gem_dumb_map_offset() to drop the '_dumb' and
updates
Am 27.06.19 um 18:55 schrieb Christoph Hellwig:
> On Thu, Jun 27, 2019 at 04:19:14PM +, Koenig, Christian wrote:
>> If not then the real question is how to correctly get the backing page
>> from dma_alloc_attrs().
> The answer to that is that you can't. dma_alloc_* is an opaque
> allocator
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #13 from Michel Dänzer ---
Sounds like the stutter with compton could be at least partly a compton
(configuration?) issue then.
--
You are receiving this mail because:
You are the assignee for the
Hi
Am 27.06.19 um 14:23 schrieb Gerd Hoffmann:
> drm clients like the generic framebuffer emulation keep a permanent
> vmap active, which in turn has a permanent pin. This pin needs to
> be in vram, otherwise we can't display the framebuffer.
>
> Signed-off-by: Gerd Hoffmann
> ---
>
Am Donnerstag, den 27.06.2019, 15:32 +0100 schrieb Russell King - ARM Linux
admin:
> On Thu, Jun 27, 2019 at 11:04:17AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jun 27, 2019 at 11:20:15AM +0200, Lucas Stach wrote:
> > > Am Samstag, den 22.06.2019, 17:16 +0100 schrieb Russell
Am 27.06.19 um 17:34 schrieb Daniel Vetter:
> On Thu, Jun 27, 2019 at 3:19 PM Christian König
> wrote:
>> Am 27.06.19 um 12:43 schrieb Daniel Vetter:
>>> On Thu, Jun 27, 2019 at 12:18 PM Christian König
>>> wrote:
While freeing up memory it is easier to remove a fence from a reservation
On Thu, Jun 27, 2019 at 10:24:53AM +0100, Lee Jones wrote:
> On Fri, 21 Jun 2019, Daniel Thompson wrote:
>
> > On 13/06/2019 20:43, Matthias Kaehlcke wrote:
> > > For backlight curves calculated with the CIE 1931 algorithm set
> > > the brightness scale type property accordingly. This makes the
>
On Thu, Jun 27, 2019 at 02:22:18PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Imo get maybe another ttm+gem stakeholder to review this (Thomas for vram
> > helpers or Ben for nouveau) and then this can land. I think Thomas
> > Hellstrom tuned down his categorical "nak" to "we'll see where this
On Wed, Jun 26, 2019 at 9:32 AM Colin Ian King wrote:
>
> On 26/06/2019 14:25, Daniel Stone wrote:
> > Hi Colin,
> >
> > On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
> >> There are a couple of spelling mistakes in dm_error messages and
> >> a comment. Fix these.
> >
> > Whilst there, you
Am 27.06.19 um 16:06 schrieb Dan Carpenter:
> Hello Christian König,
>
> The patch 648bc3574716: "drm/ttm: add transparent huge page support
> for DMA allocations v2" from Jul 6, 2017, leads to the following
> static checker warning:
>
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:314
Hi Lucas,
On Thu, Jun 27, 2019 at 11:44 AM Lucas Stach wrote:
>
> When something goes wrong in the GPU init after the cmdbuf suballocator
> has been constructed, we fail to destory it properly. This causes havok
s/destory/destroy
> later when the GPU is unbound due to a module unload or
On Thu, Jun 27, 2019 at 02:12:40PM +0200, Lukas Schneider wrote:
> Cleanup the line over 80 character warnings, reported by checkpatch
>
> Signed-off-by: Lukas Schneider
> Signed-off-by: Jannik Moritz
> Cc:
> ---
> drivers/staging/fbtft/fbtft-sysfs.c | 3 ++-
> drivers/staging/fbtft/fbtft.h
On Wed, 26 Jun 2019 23:27:35 +0200
Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 01:14:13PM -0300, Mauro Carvalho Chehab wrote:
> > Due to two patches being applied about the same time, the
> > reference for modedb.rst file got wrong:
> >
> > Documentation/fb/modedb.txt is now
Am 27.06.19 um 19:15 schrieb Christoph Hellwig:
> On Thu, Jun 27, 2019 at 05:12:47PM +, Koenig, Christian wrote:
>> the whole TTM page allocation code is not really working that well.
>>
>> How do we then do things like mapping that memory to userspace?
> dma_mmap_attrs with the same flags as
Hello Christian König,
The patch 648bc3574716: "drm/ttm: add transparent huge page support
for DMA allocations v2" from Jul 6, 2017, leads to the following
static checker warning:
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:314 __ttm_dma_alloc_page()
error: 'vaddr' came from
This dependency is already present in higher level Kconfig file
(drivers/video/fbdev/mmp/Kconfig).
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/mmp/fb/Kconfig |4
drivers/video/fbdev/mmp/hw/Kconfig |4
2 files changed, 8 deletions(-)
Index:
On Thu, Jun 27, 2019 at 12:18:12PM +0200, Christian König wrote:
> They are not used that often and certainly not in a hot path.
> Make them normal functions instead of an inline.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/dma-buf/reservation.c | 45
Am 27.06.19 um 17:54 schrieb Thomas Zimmermann:
> Hi
>
> Am 27.06.19 um 17:16 schrieb Gerd Hoffmann:
>> Hi,
>>
>>> 1) Introduce a default_placement field in struct drm_gem_vram_helper
>>> where this flag can be configured. I'd favor this option.
>>
>>> 2) Introduce a separate callback
The ast driver's struct ast_framebuffer is a buffer object with GEM
interface. There are already GEM framebuffer helpers that implement
the same functionality. Convert ast to these.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 12 ---
drivers/gpu/drm/ast/ast_fb.c
Hi Dave,
Just two cleanups - one is to drop drmP.h header, and other is to add
COMPILE_TEST flag for increasing build test coverage.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 14808a12bdbdc21143eba70ea07830197b3a04ff:
On Sun, Jun 02, 2019 at 01:36:27AM +0200, Marek Vasut wrote:
> The following situation can happen in a multithreaded OpenGL application.
> A BO is submitted from etna_cmd_stream #1 with flags set for read.
> A BO is submitted from etna_cmd_stream #2 with flags set for write.
> This triggers a
drm_gem_shmem_create_with_handle() returns a GEM object and attach a
handle to it. When the user closes the DRM FD, the core releases all
GEM handles along with their backing GEM objs, which can lead to a
double-free issue if panfrost_ioctl_create_bo() failed and went
through the err_free path
On Thu, Jun 27, 2019 at 4:57 AM Steven Price wrote:
>
> Sorry for the slow response, I've been on holiday for a few weeks.
Welcome back.
>
> On 20/06/2019 06:50, Tomeu Vizoso wrote:
> > On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
> >>
> >> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
>
On Thu, Jun 27, 2019 at 03:48:06PM +, Koenig, Christian wrote:
> Am 27.06.19 um 17:34 schrieb Daniel Vetter:
> > On Thu, Jun 27, 2019 at 3:19 PM Christian König
> > wrote:
> >> Am 27.06.19 um 12:43 schrieb Daniel Vetter:
> >>> On Thu, Jun 27, 2019 at 12:18 PM Christian König
> >>> wrote:
>
On Wed, Jun 26, 2019 at 11:35 PM Stephen Rothwell wrote:
>
> Hi Dave,
>
> On Wed, 26 Jun 2019 21:22:12 +1000 Stephen Rothwell
> wrote:
> >
> > Hi Alex,
> >
> > After merging the amdgpu tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > In file included from
On Thu, Jun 27, 2019 at 11:04:17AM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Jun 27, 2019 at 11:20:15AM +0200, Lucas Stach wrote:
> > Am Samstag, den 22.06.2019, 17:16 +0100 schrieb Russell King - ARM Linux
> > admin:
> > > While updating my various systems for the TCP SACK issue, I
On Sat, 22 Jun 2019, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 10:16 PM Jani Nikula
> wrote:
>>
>> On Wed, 19 Jun 2019, Daniel Vetter wrote:
>> > - figure out what to do with the libdrm manpages. Some stuff we really
>> > want to also document there. But geez nroff. Maybe we need to stuff
In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
which attach to the DSI host via mipi_dsi_attach() at probe time, the
ADV7533 bridge device does not. Instead it defers this to the point that
the upstream device connects to its bridge via drm_bridge_attach().
The generic
On 10/06/2019 18:04, Rob Herring wrote:
> The midgard/bifrost GPUs need to allocate GPU memory which is allocated
> on GPU page faults and not pinned in memory. The vendor driver calls
> this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
>
Sorry for the slow response, I've been on holiday for a few weeks.
On 20/06/2019 06:50, Tomeu Vizoso wrote:
> On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
>>
>> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
>> wrote:
>>>
>>> On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
On
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files.
Semantic patch information:
Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
imposes some significant overhead as compared to
DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
Generated by:
On 6/27/19 5:26 AM, Christian Gmeiner wrote:
> Am Di., 4. Juni 2019 um 01:40 Uhr schrieb Marek Vasut :
>>
>> Use hash table instead of ad-hoc arrays.
>>
>
> Please re-spin this patch in mesa on top of latest master. If you see
> a real benefit for setups where
> newest libdrm with older mesa gets
On 10/06/2019 14:20, Rob Herring wrote:
[...]
> I wouldn't have expected AS_TRANSCFG_ADRMODE_LEGACY to work and if it
> did it was by chance. So I don't think it is something we want to
> support.
Actually legacy mode is supported on (most?) Bifrost GPUs. But best to
follow the lead of kbase here
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_common_early_init':
drivers/gpu/drm/amd/amdgpu/nv.c:471:7: warning:
variable 'psp_enabled' set but not used [-Wunused-but-set-variable]
It's not used since inroduction in
commit c6b6a42175f5
https://bugs.freedesktop.org/show_bug.cgi?id=110929
--- Comment #1 from John Bridgman ---
How are you enabling SME - transparent mode (via SBIOS I think) where all pages
are encrypted, or via OS where only pages
with PA bit 47 set are encrypted ?
I would not expect the first option to work
On 6/26/2019 11:01 PM, Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 12:06:13AM -0400, Kenny Ho wrote:
>> On Wed, Jun 26, 2019 at 12:12 PM Daniel Vetter wrote:
>>>
>>> I think with all the ttm refactoring going on I think we need to de-ttm
>>> the interface functions here a bit. With Gerd
kzalloc has already zeroes the memory.
So memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
On Wed, Jun 26, 2019 at 02:27:02PM +0200, Christoph Hellwig wrote:
> This function has never been used since it was first added to the kernel
> more than a year and a half ago, and if we ever grow a consumer of the
> MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages
>
kzalloc has already zeroes the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
Sorry for the late response! just jumping back on this now.
On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> [CAUTION: External Email]
>
> So a couple of things:
>
> On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
>> From: Ville Syrjälä
>>
>> All available downstream ports - physical
https://bugs.freedesktop.org/show_bug.cgi?id=110929
--- Comment #2 from Nick Sarnie ---
Thanks for the response John. I'm pretty sure it is the second case: through
the OS. I am not changing any BIOS options, I am only passing mem_encrypt=on to
the kernel command line.
--
You are receiving
Hi, Jitao:
On Thu, 2019-06-27 at 10:59 +0800, Jitao Shi wrote:
> This patch add mt8183 mipi_tx driver.
> And also support other chips that use the same binding and driver.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
>
Hi Dave, Daniel,
Arm fix as requested by Dave, plus a few navi fixes.
The following changes since commit 14808a12bdbdc21143eba70ea07830197b3a04ff:
Merge tag 'drm-next-5.3-2019-06-25' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2019-06-27 12:33:57
+1000)
are available in the
Hi, Jitao:
On Thu, 2019-06-27 at 10:59 +0800, Jitao Shi wrote:
> Different IC has different mipi_tx setting of dsi.
> This patch separates the mipi_tx hardware relate part for mt8173.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/Makefile | 1
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/video/fbdev/mmp/fb/mmpfb.c | 1 -
1 file changed, 1 deletion(-)
diff
Hi Alex,
On Thu, 27 Jun 2019 10:18:38 -0400 Alex Deucher wrote:
>
> Fixed in this patch:
> https://patchwork.freedesktop.org/patch/314527/?series=62866=1
Thanks. I will manually apply that to the drm tree merge until it is
no longer necessary there.
--
Cheers,
Stephen Rothwell
On Wed, Jun 26, 2019 at 02:27:19PM +0200, Christoph Hellwig wrote:
> The only user of it has just been removed, and there wasn't really any need
> to wrap a basic memory allocator to start with.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/hmm.h | 3 ---
> mm/hmm.c|
On Wed, Jun 26, 2019 at 11:18:23AM -0700, Ralph Campbell wrote:
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index b224ea635a7716..89549eac03d506 100644
> > +++ b/mm/hmm.c
> > @@ -64,7 +64,7 @@ static struct hmm *hmm_get_or_create(struct mm_struct *mm)
> > init_rwsem(>mirrors_sem);
> >
On Wed, Jun 26, 2019 at 02:27:23PM +0200, Christoph Hellwig wrote:
> All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau
> depend on it instead of the mix of a dummy dependency symbol plus the
> actually selected one. Drop various odd dependencies, as the code is
> pretty
kzalloc has already zeroes the memory.
So memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
On Wed, Jun 26, 2019 at 02:27:11PM +0200, Christoph Hellwig wrote:
> This replaces the hacky ->fault callback, which is currently directly
> called from common code through a hmm specific data structure as an
> exercise in layering violations.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by:
On 6/27/19 5:09 PM, Wladimir J. van der Laan wrote:
> On Tue, Jun 04, 2019 at 01:39:29AM +0200, Marek Vasut wrote:
>> Use hash table instead of ad-hoc arrays.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Christian Gmeiner
>> Cc: Lucas Stach
>> ---
>> etnaviv/etnaviv_bo.c | 6 +++---
>>
kzalloc already zerored the memory.
so memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
kzalloc has already zeroes the memory.
So memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
On 2019-06-26 6:27 a.m., Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Also, for the P2PDMA changes in this series:
Tested-by: Logan Gunthorpe
I've ran this series
On Thu, Jun 27, 2019 at 07:57:05PM +0800, Laurent Pinchart wrote:
> Hello Xin Ji,
>
> Thank you for the patch.
>
> On Thu, Jun 27, 2019 at 11:29:47AM +, Xin Ji wrote:
> > Move analogix chip ANX78XX bridge driver into "analogix" directory.
> >
> > Signed-off-by: Xin Ji
> > ---
> >
Move analogix chip ANX78XX bridge driver into "analogix" directory.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/Kconfig | 10 --
drivers/gpu/drm/bridge/Makefile | 3 +--
drivers/gpu/drm/bridge/analogix/Kconfig |
On 6/27/19, 9:58 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Reported-by: kbuild test robot
> Cc: Jingoo Han
Acked-by:
Hi, Jitao:
On Thu, 2019-06-27 at 16:01 +0800, Jitao Shi wrote:
> Config the different CMDQ reg address in driver data.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 29 -
> 1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git
On Thu, Jun 27, 2019 at 11:20:15AM +0200, Lucas Stach wrote:
> Am Samstag, den 22.06.2019, 17:16 +0100 schrieb Russell King - ARM Linux
> admin:
> > While updating my various systems for the TCP SACK issue, I notice
> > that while most platforms are happy, the Cubox-i4 is not. During
> > boot,
Fix build warning if drm_panel.h is built with CONFIG_OF=n or
CONFIG_DRM_PANEL=n and included without the prerequisite err.h:
./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
./include/drm/drm_panel.h:203:9: error: implicit declaration of function
‘ERR_PTR’
On Tue, Jun 25, 2019 at 5:35 PM Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Now that the da8xx fbdev driver supports power control with an actual
> regulator, switch to using a fixed power supply for da850-evm.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
On 27.06.2019 12:26, Tomi Valkeinen wrote:
> On 19/06/2019 08:27, Andrey Smirnov wrote:
>> Everyone:
>>
>> This series contains various improvements (at least in my mind) and
>> fixes that I made to tc358767 while working with the code of the
>> driver. Hopefuly each patch is self explanatory.
>>
Hi
Am 27.06.19 um 10:12 schrieb Gerd Hoffmann:
> The driver doesn't consider framebuffer pitch and offset, leading to a
> wrong display in case offset != 0 or pitch != width * bpp. Fix it.
Thanks
Acked-by: Thomas Zimmermann
> Signed-off-by: Gerd Hoffmann
> ---
>
Hi,
> Imo get maybe another ttm+gem stakeholder to review this (Thomas for vram
> helpers or Ben for nouveau) and then this can land. I think Thomas
> Hellstrom tuned down his categorical "nak" to "we'll see where this goes,
> I might need to jump in and help course-correct".
Yep, seems he
drm-misc-next-fixes-2019-06-27:
- Fixes to the tfp410 bridge.
- Small build fix for vga_switcheroo to prevent building against modular fbcon.
The following changes since commit 80d42db02b3a5beb8cffba08207adf5f4c525ee3:
drm/edid: use for_each_displayid_db where applicable (2019-06-25 14:44:03
1 - 100 of 184 matches
Mail list logo
