Hi Linus,
Just dequeuing these a bit early as the AMD ones are bit larger than
I'd prefer, but Alex missed last week so it's a double set of fixes.
The larger ones are just register header fixes for the new chips that
were just introduced in rc1 along with some new PCI IDs for new hw.
Otherwise it
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 0b06286579b81449b1e8f14f88d3a8d
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
---
drivers/gpu/drm/vmwgfx
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 reache
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 Baghdasa
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 us
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: Hri
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 to
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: Ezequie
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 commo
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.
Sign
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 workqueue
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 insertions(+)
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 aecd
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, thank
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 me
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 tags/amd-drm-next-5.10-2020-09
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.k
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 t
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
> > sp
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 drive
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&action=edit
Resume fail with RX 580 GPU
I've been having random resume problems form arou
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 b/drive
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
https://git.kernel.org/pub/scm/linux/kernel/git/chun
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 k
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 tha
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 FVP
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 W
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:
WARNI
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 f
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 sch
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 09:28
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 +020
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 Ye
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 drm
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 as
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 11:30:22P
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 e
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 a
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:
> >
> > Wow
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 C
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 at
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 dm
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 1:22
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 ttm_kmap_obj_to_dma_buf(
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 drm-misc-next
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 dma_buf_m
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 b17ac6c..b2fb5c3
在 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!
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_dr
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 f
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:
>>>
>>> Documentation/devicetree
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 in
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
>
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 deletions(-)
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 con_font_op(s
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:
>
> git://git.kernel.org/pub/scm/linux/kernel
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
b/driver
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 u
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 cont
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 memalloc_noreclaim
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
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;
> -
> -
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 +++---
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
drivers/gpu/dr
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 thi
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
Cc:
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 memalloc_noio_save/re
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. Can'
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 te
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
87 matches
Mail list logo
