Tracked it down to my init mem type changes, patch is on the list.
Dave.
On Wed, 30 Sep 2020 at 18:28, Christian König wrote:
>
> That sounds like the same problem I've got when drm-next was merged into
> drm-misc-next.
>
> I've fixed it in this commit:
>
> commit
From: Dave Airlie
When I refactored this code with the new init paths, I failed to
set the funcs back up properly, this caused a failure to bringup
gdm properly.
Fixes: 252f8d7b9174 ("drm/vmwgfx/ttm: convert vram mm init to new code paths")
Signed-off-by: Dave Airlie
---
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc:
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc:
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc:
Hey All,
So this patch series contains a series of performance
optimizations to the dma-buf system heap.
Unfortunately, in working these up, I realized the heap-helpers
infrastructure we tried to add to miniimize code duplication is
not as generic as we intended. For some heaps it makes sense
On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter wrote:
> > >
> > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter
> > > wrote:
> > > >
> > > > Ben, did you have a chance to look at
TTM currently supports allocating pages with GFP_TRANSHUGE_LIGHT, but with
the __GFP_COMP flag cleared. Instead of being normal transparent huge
pages, these are multiorder non-compound pages that have the same order as
THPs. This interferes with drivers that import DMA-BUFs / SGTs backed by
pages
Hi Christian,
I've been looking into the DMA-BUFs exported from AMDGPU / TTM. Would
you mind giving some input on this?
I noticed that your changes implementing transparent huge page support
in TTM are allocating them as non-compound. I understand that using
multiorder non-compound pages is
From: Rob Clark
This will allow userspace to control the scheduling policy and priority.
In particular if the userspace half of the display pipeline is SCHED_FIFO
then it will want to use the same scheduling policy and an appropriate
priority to ensure that it is not preempting commit_work.
From: Rob Clark
The android userspace treats the display pipeline as a realtime problem.
And arguably, if your goal is to not miss frame deadlines (ie. vblank),
it is. (See https://lwn.net/Articles/809545/ for the best explaination
that I found.)
But this presents a problem with using
From: Rob Clark
This will allow us to more easily switch scheduling rules based on what
userspace wants.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 13
include/drm/drm_atomic.h| 31 +
2 files changed, 40
From: Rob Clark
This will be used for non-block atomic commits.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 11 +++
include/drm/drm_crtc.h | 8
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index
On Wed, 2020-09-30 at 16:25 -0400, Lyude Paul wrote:
> On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> > Thank you for the reply. And in regards to digging into it further,
> > thanks for requesting that I do some more due diligence here :)
> >
> > Also if you did get around to it,
On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> Thank you for the reply. And in regards to digging into it further,
> thanks for requesting that I do some more due diligence here :)
>
> Also if you did get around to it, thanks for double-checking with
> Bill! Let me know if you'd like
Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit 911d5bd5e7b8531b39301c2c27e5b90d7bd71b88:
drm/amd/pm: Skip smu_post_init in SRIOV (2020-09-18 16:14:56 -0400)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #70 from Lahfa Samy (s...@lahfa.xyz) ---
I've opened a new bug report as the issue is clearly related to networking and
the iwlwifi driver and not to the AMDGPU driver in my case.
Here is the link to the bug report :
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #69 from Lahfa Samy (s...@lahfa.xyz) ---
I've got news of a current workaround for my T495 with a Ryzen 7 3700U and a
Vega RX 10 on kernel 5.8.12arch, I have disabled the Network card (which means
no more WiFi at all) in the BIOS and
On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig wrote:
>
> On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> > Hmm, those are both committed after our last -next pull request, so they
> > would normally only target next merge window. drm-next closes the merge
> > window around
On Wed, Sep 30, 2020 at 03:57:58PM +0300, Jani Nikula wrote:
> On Wed, 30 Sep 2020, Ville Syrjälä wrote:
> > Now we have an actual difference between EHL and JSL so we
> > should split. Granted it's a bit annoying to have to do it
> > just for some vswing tables. Ideally that stuff would be
> >
Hi,
Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
>> Hi Nathan,
>>
>> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
>>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
Now that all the
On Wed, Sep 30, 2020 at 12:14:06PM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 06:05:15PM +0300, Maor Gottlieb wrote:
> > This is right only for the last iteration. E.g. in the first iteration in
> > case that there are more pages (left_pages), then we allocate
> > SG_MAX_SINGLE_ALLOC.
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #68 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
Created attachment 292729
--> https://bugzilla.kernel.org/attachment.cgi?id=292729=edit
Resume fail with RX 580 GPU
I've been having random resume problems form around
On 9/30/2020 1:54 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2020-09-29 10:10:26)
Set link rate by using OPP set rate api so that CX level will be set
accordingly base on the link rate.
s/base/based/
Signed-off-by: Kuogee Hsieh
---
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
Hi Dave, Daniel,
A bit bigger than usual since I missed last week. Mostly updates
for new asics and a few of misc bug fixes.
The following changes since commit 1f08fde70075784d28d1687d0e75871e81cc1173:
Merge tag 'mediatek-drm-fixes-5.9' of
On Wed, Sep 30, 2020 at 03:24:43PM +0200, Mauro Carvalho Chehab wrote:
> As warned by Sphinx:
>
> ./Documentation/gpu/drm-kms-helpers:305: ./include/drm/drm_dsc.h:587:
> WARNING: Unparseable C cross-reference: 'struct'
> Invalid C declaration: Expected identifier in nested name, got
On Tue, Sep 29, 2020 at 12:53:44PM -0700, Peter Collingbourne wrote:
> Also partially revert the follow-up change "drm: pl111: Absorb the
> external register header".
>
> This reverts the parts of commits
> 7e4e589db76a3cf4c1f534eb5a09cc6422766b93 and
> 0fb8125635e8eb5483fb095f98dcf0651206a7b8
On Tue, Sep 29, 2020 at 11:16 PM Peter Collingbourne wrote:
> On Tue, Sep 29, 2020 at 1:33 PM Linus Walleij
> wrote:
> > Can you also share the kernel config used for this build so it is
> > easy to rebuild a similar kernel?
>
> There are instructions here for how to build Android targeting
On Fri, Aug 28, 2020 at 12:47 PM Lee Jones wrote:
> > create mode 100644 drivers/video/backlight/ktd253-backlight.c
>
> Applied, thanks.
Not to unnecessarily nag but I can't see this in linux-next and since we
are at -rc7 it makes me a bit nervous, is it still gonna be in v5.10?
Yours,
Linus
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169:
As warned by Sphinx:
./Documentation/gpu/drm-kms-helpers:305: ./include/drm/drm_dsc.h:587:
WARNING: Unparseable C cross-reference: 'struct'
Invalid C declaration: Expected identifier in nested name, got keyword:
struct [error at 6]
struct
--^
The markup
On Wed, 30 Sep 2020, Ville Syrjälä wrote:
> Now we have an actual difference between EHL and JSL so we
> should split. Granted it's a bit annoying to have to do it
> just for some vswing tables. Ideally that stuff would be
> specified in a sane way by the VBT. But since VBT is generally
> useless
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
>
> Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
> >>> Hi
> >>>
> >>> Am 30.09.20 um 10:05 schrieb Christian König:
>
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35
On Tue, 29 Sep 2020, "Souza, Jose" wrote:
> On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
>> If the thing has nothing to do PCH then it should not use the PCH type
>> for the the check. Instead we should just do the EHL/JSL split.
>
> In the first version Matt Roper suggested to use PCH
On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote:
> > > On Tue, Sep 29, 2020 at 2:32 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Sep 29, 2020 at
On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye wrote:
> >
> > On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > > On Tue, Sep 29, 2020 at 04:38:49PM
On Tue, Sep 29, 2020 at 11:44 AM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
> >
> > On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote:
> > >
> > > On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote:
> > > > On Tue, Sep 29, 2020 at 09:30:08AM
On Tue, Sep 29, 2020 at 2:32 AM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 09:28:56AM +0200, Neil Armstrong wrote:
> > Hi,
> >
> > On 28/09/2020 22:08, Peter Collingbourne wrote:
> > > Also revert the follow-up change "drm: pl111: Absorb the external
> > > register header".
> > >
> > > This
This patch restores DRM connector registration in the TC358764 bridge
driver and restores usage of the old drm_panel_* API, thus allows dynamic
panel registration. This fixes panel operation on Exynos5250-based
Arndale board.
This is equivalent to the revert of the following commits:
1644127f83bc
Quoting Gustavo A. R. Silva (2020-09-25 16:35:12)
> Hi all,
>
> Friendly ping: who can take this?
We had picked up the same patch from Dan Carpenter, thanks.
commit 68ba71e3ae6dd86a23486655e33c5f8c9bd90777
Author: Dan Carpenter
Date: Fri Sep 11 10:52:43 2020 +0300
drm/i915: Fix an error
On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye wrote:
>
> On Wed, Sep 30, 2020 at 11:53:17AM +0200, Daniel Vetter wrote:
> > On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> > > On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > > > On Tue, Sep 29, 2020 at 2:34 PM Peilin
On Wed, Sep 30, 2020 at 12:31 PM Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 12:13 PM Andrzej Hajda wrote:
> >
> >
> > W dniu 24.09.2020 o 10:31, Marek Szyprowski pisze:
> > > This patch restores DRM connector registration in the TC358764 bridge
> > > driver and restores usage of the old
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 1ebf4588bcd8d58d1f3c3d38e360ad068b791634
commit: 519b8b76f0b62a0be0d9fcee39819d2461fc3cb0 [182/207] drm/amdgpu:
Implement new guest side VF2PF message transaction (v2)
config: microblaze-randconfig-r034-20200930 (attached
On Tue, Sep 29, 2020 at 04:38:22PM -0700, Matt Roper wrote:
> On Wed, Sep 30, 2020 at 12:59:58AM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> > > > On Tue, Sep 29, 2020 at
On Wed, Sep 30, 2020 at 12:13 PM Andrzej Hajda wrote:
>
>
> W dniu 24.09.2020 o 10:31, Marek Szyprowski pisze:
> > This patch restores DRM connector registration in the TC358764 bridge
> > driver and restores usage of the old drm_panel_* API, thus allows dynamic
> > panel registration. This fixes
W dniu 24.09.2020 o 10:31, Marek Szyprowski pisze:
> This patch restores DRM connector registration in the TC358764 bridge
> driver and restores usage of the old drm_panel_* API, thus allows dynamic
> panel registration. This fixes panel operation on Exynos5250-based
> Arndale board.
>
> This is
On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > Explicit synchronization is the future. At least, that seems to be what
> > most userspace APIs are agreeing on at this point. However, most of our
> > Linux APIs (both userspace
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> > *device,
> > goto umem_release;
> >
> > cur_base
On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye wrote:
> > > It seems that users don't use `console_font` directly, they use
> > > `console_font_op`. Then, in TTY:
> >
> >
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 30.09.20 um 10:05 schrieb Christian König:
> > > Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
> > > > Hi Christian
> > > >
> > > > Am 29.09.20 um 17:35 schrieb
On Tue, Sep 29, 2020 at 01:51:36PM -0700, Peter Collingbourne wrote:
> On Tue, Sep 29, 2020 at 11:44 AM Daniel Vetter wrote:
> >
> > On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
> > >
> > > On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Sep 29, 2020
On Tue, Sep 29, 2020 at 10:29:22PM +0200, Linus Walleij wrote:
> On Tue, Sep 29, 2020 at 8:44 PM Daniel Vetter wrote:
> > On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
>
> > But aside from all this, why is this blocking the migration from fbdev
> > to drm? With fbdev you don't have
On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with
On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> On Wed, 30 Sep 2020 at 00:52, Daniel Vetter wrote:
> >
> > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter
> > wrote:
> > >
> > > Ben, did you have a chance to look at this?
> >
> > Ping
> > -Daniel
> >
> > > On Mon, Aug 3, 2020 at
https://bugzilla.kernel.org/show_bug.cgi?id=204241
Lahfa Samy (s...@lahfa.xyz) changed:
What|Removed |Added
CC||s...@lahfa.xyz
--- Comment
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper
That sounds like the same problem I've got when drm-next was merged into
drm-misc-next.
I've fixed it in this commit:
commit 0b06286579b81449b1e8f14f88d3a8db091fd443
Author: Christian König
Date: Wed Aug 19 15:27:48 2020 +0200
drm/ttm: fix broken merge between drm-next and
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 29.09.20 um 17:35 schrieb Christian König:
>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct
It is redundant to do irqsave and irqrestore in hardIRQ context.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index
在 2020/9/29 15:24, Thomas Zimmermann 写道:
Am 29.09.20 um 02:45 schrieb Tian Tao:
The macro PADDING is no longer used. Delete it.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks a lot for the timely help with the review code!
---
On Tue, Sep 29, 2020 at 10:12:46AM +0900, Tetsuo Handa wrote:
> On 2020/09/29 2:59, Martin Hostettler wrote:
> > On Sun, Sep 27, 2020 at 08:46:30PM +0900, Tetsuo Handa wrote:
> >> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
> >> comes to the "+ more" part, and I couldn't
On 29. 09. 20 16:55, Rob Herring wrote:
> On Tue, Sep 29, 2020 at 1:55 AM Michal Simek wrote:
>>
>> Hi Rob,
>>
>> On 28. 09. 20 17:59, Rob Herring wrote:
>>> The default sizes in examples for 'reg' are 1 cell each. Fix the
>>> incorrect sizes in zynqmp examples:
>>>
>>>
On Tue, Sep 29, 2020 at 11:09:45AM +0200, Daniel Vetter wrote:
> If you want to follow along a bit I think would be good to subscribe to
> the dri-devel mailing list. At least for all the fbcon/fbdev/gpu stuff.
>
> I don't think there's a dedicated list for vt/console stuff, aside from
> Greg's
On 10.09.20 20:18, Deucher, Alexander wrote:
> [AMD Public Use]
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Daniel Vetter
>> Sent: Monday, September 7, 2020 3:15 AM
>> To: Jan Kiszka ; amd-gfx list > g...@lists.freedesktop.org>; Wentland, Harry ;
>> Kazlauskas, Nicholas
On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye wrote:
> > It seems that users don't use `console_font` directly, they use
> > `console_font_op`. Then, in TTY:
>
> Wow, this is a maze :-/
>
> > (drivers/tty/vt/vt.c)
> > int
On Mon 2020-09-28 12:25:59, Peter Zijlstra wrote:
> On Mon, Sep 28, 2020 at 06:04:23PM +0800, Chengming Zhou wrote:
>
> > Well, you are lucky. So it's a problem in our printk implementation.
>
> Not lucky; I just kicked it in the groin really hard:
>
>
Consistently Use the same style of variable type in hibmc_drm_de.c and
hibmc_drm_de.h.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8
2 files changed, 10 insertions(+), 11
Consistently Use the same style of variable type in hibmc_drm_de.c.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
On Fri, Sep 25, 2020 at 03:25:51PM +0200, Daniel Vetter wrote:
> I think the only way to make this work is that we have one place which
> takes in the userspace uapi struct, and then converts it once into a
> kernel_console_font. With all the error checking.
Hi Daniel,
It seems that users don't
On Wed, Sep 30, 2020 at 07:26:52AM +0200, Jiri Slaby wrote:
> On 29. 09. 20, 14:34, Peilin Ye wrote:
> > the work in general? I couldn't think of how do we clean up subsystems
> > one by one, while keeping a `console_font` in `struct vc_data`.
>
> Hi,
>
> feel free to change struct vc_data's
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> *device,
> goto umem_release;
>
> cur_base += ret * PAGE_SIZE;
> - npages -= ret;
> -
> -
On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> I can
> then figure out whether it's better to risk not spotting issues with
> call_rcu vs slapping a memalloc_noio_save/restore around all these
> critical section which force-degrades any allocation to GFP_ATOMIC at
did you mean
On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson
Set link rate by using OPP set rate api so that CX level will be set
accordingly base on the link rate.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 33 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.h| 2 +-
drivers/gpu/drm/msm/dp/dp_display.c | 8 +++---
Thank you for the reply. And in regards to digging into it further,
thanks for requesting that I do some more due diligence here :)
Also if you did get around to it, thanks for double-checking with
Bill! Let me know if you'd like me to reach out instead, or if
anything else needs to be done in
patch #1 and #2 Use the same style of variable type in hisilicon drm driver
and both are clean up, no actual functional changes.
Tian Tao (2):
drm/hisilicon: Use the same style of variable type in hibmc_drm_de
drm/hisilicon: Use the same style of variable type in hibmc_drm_drv
On Tue 29-09-20 11:00:03, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote:
> > On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> > > I can
> > > then figure out whether it's better to risk not spotting issues with
> > > call_rcu vs slapping a
On Tue, 29 Sep 2020 at 14:35, Kevin Tang wrote:
>
> Hi Rob,
> Component framework include master and component, here is master subnode.
> It seems that everyone else does it, why not me?
>
> Your comments on v6:
> "We generally try to avoid this virtual node as it doesn't represent
> any h/w.
On 2020-09-25 21:24, John Stultz wrote:
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Hi All,
On 25.09.2020 23:23, Alex Deucher wrote:
> On Tue, Sep 22, 2020 at 2:28 AM Marek Szyprowski
> wrote:
>> On 22.09.2020 01:15, Alex Goins wrote:
>>> Tested-by: Alex Goins
>>>
>>> This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
>>> AMDGPU in v5.9.
>> Thanks for
just FYI I'm seeing a regression on vmwgfx with drm-fixes and drm-next
merged into it.
I'm going take some time to dig through and work out where, the
regression is a command failure and a ioremap failure.
Dave.
On Wed, 30 Sep 2020 at 16:26, Dave Airlie wrote:
>
> Uggh this is part of the mess
On Tue, Sep 29, 2020 at 02:53:33PM -0700, Gurchetan Singh wrote:
> From: Alistair Delva
>
> We encountered this issue when booting blob with a 32-bit kernel.
> The implementation doesn't match v6 of the virtio-spec change, so fix
> this.
>
> Fixes: ff886cbdcc44 ("virtio-gpu api: blob
Uggh this is part of the mess with the revert, I'm not sure how best
to dig out of this one yet.
Dave.
On Wed, 30 Sep 2020 at 15:55, Dave Airlie wrote:
>
> From: Dave Airlie
>
> This fixes a bug introduced in be1213a341a289afc51f89181c310e368fba0b66
> drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2
88 matches
Mail list logo
