Am 24.11.20 um 02:12 schrieb Luben Tuikov:
On 2020-11-23 3:06 a.m., Christian König wrote:
Am 23.11.20 um 06:37 schrieb Andrey Grodzovsky:
On 11/22/20 6:57 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
No point to try recovery if device is gone, it's meaningless.
Hi
Am 24.11.20 um 02:58 schrieb Xing Zhengjun:
On 11/23/2020 4:04 PM, Thomas Zimmermann wrote:
Hi
Am 22.11.20 um 15:18 schrieb kernel test robot:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 6a1b34c0a339fdc75d7932ad5702f2177c9d7a1c ("drm/fb-helper:
Move
Am 23.11.20 um 22:08 schrieb Andrey Grodzovsky:
On 11/23/20 3:41 PM, Christian König wrote:
Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky:
On 11/23/20 3:20 PM, Christian König wrote:
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky:
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20
This an incremental refactor towards multiple dma-fence contexts
in virtio-gpu. Since all fences are still allocated using
_gpu_fence_driver.context, nothing should break and every
processed fence will be signaled.
The overall idea is every 3D context can allocate a number of
dma-fence contexts.
virtio_gpu_fence_event_process sets the last_fence_id and
subsequently calls dma_fence_signal_locked(..).
dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT,
which is actually checked before _fence_ops.(*signaled) is
called.
The check for last_fence_id is therefore a bit redundant, and
This an incremental refactor towards multiple dma-fence contexts
in virtio-gpu. Since all fences are still allocated using
_gpu_fence_driver.context, nothing should break and every
processed fence will be signaled.
The overall idea is every 3D context can allocate a number of
dma-fence contexts.
virtio_gpu typically uses the prefix virtio_gpu, but there are
a few places where the virtio prefix is used. Modify this for
consistency.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 24 ++
drivers/gpu/drm/virtio/virtgpu_fence.c | 32
Hi Dave,
Just one bug fix to a build error due to common framework dependency.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 6600f9d52213b5c3455481b5c9e61cf5e305c0e6:
Merge tag 'drm-intel-fixes-2020-11-19' of
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to
On 2020-11-23 3:06 a.m., Christian König wrote:
> Am 23.11.20 um 06:37 schrieb Andrey Grodzovsky:
>>
>> On 11/22/20 6:57 AM, Christian König wrote:
>>> Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
No point to try recovery if device is gone, it's meaningless.
>>>
>>> I think that this
On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.
Ideally, that proof would be provided by the compilation system itself
and not patch authors nor
On Mon, Nov 23, 2020 at 4:38 PM wrote:
>
> Hi Rob
>
> On 2020-11-23 15:18, Rob Clark wrote:
> > On Thu, Nov 19, 2020 at 1:41 PM Abhinav Kumar
> > wrote:
> >>
> >> Update the qos remap only if the client type changes for the plane.
> >> This will avoid unnecessary register programming and also
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Colin King
Sent: Monday, November 23, 2020 6:54 PM
To: Deucher, Alexander ; Koenig, Christian
; David Airlie ; Daniel Vetter
; Quan, Evan ; Wang, Kevin(Yang)
; Gui, Jack ;
Hi Rob
On 2020-11-23 15:18, Rob Clark wrote:
On Thu, Nov 19, 2020 at 1:41 PM Abhinav Kumar
wrote:
Update the qos remap only if the client type changes for the plane.
This will avoid unnecessary register programming and also avoid log
spam from the dpu_vbif_set_qos_remap() function.
Hi, Dave & Daniel:
This includes:
1. Remove unused variable.
2. Modify horizontal front/back porch byte formula.
Regards,
Chun-Kuang.
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository
On Thu, Nov 19, 2020 at 1:41 PM Abhinav Kumar wrote:
>
> Update the qos remap only if the client type changes for the plane.
> This will avoid unnecessary register programming and also avoid log
> spam from the dpu_vbif_set_qos_remap() function.
>
> Signed-off-by: Abhinav Kumar
> ---
>
On Sun, Nov 22, 2020 at 11:03:22PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code
On Fri, Nov 20, 2020 at 05:45:07PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the
On Fri, Nov 20, 2020 at 05:42:38PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the
Hi Linus.
On Thu, Nov 12, 2020 at 03:29:25PM +0100, Linus Walleij wrote:
> This implements support for DPI output using the port node
> in the device tree to connect a DPI LCD display to the
> MCDE. The block also supports TV-out but we leave that
> for another day when we have a hardware using
Hi Linus
On Thu, Nov 12, 2020 at 03:29:24PM +0100, Linus Walleij wrote:
> To be able to support DPI without messing things up we
> first break out the DSI set-up to a separate function.
>
> Cc: Stephan Gerhold
> Cc: phone-de...@vger.kernel.org
> Cc: upstream...@lists.sr.ht
> Signed-off-by:
Hi Linus.
On Tue, Nov 17, 2020 at 06:54:13PM +0100, Linus Walleij wrote:
> I was confused when the graphics came out with blue
> penguins on the DPI panel.
>
> It turns out that the so-called "packed RGB666" mode
> on the DSI formatter is incorrect: this mode is the
> actual RGB888 mode, and the
On Wed, Nov 18, 2020 at 09:29:48AM +0100, Guido Günther wrote:
> Less code and easier probe deferral debugging.
>
> Signed-off-by: Guido Günther
> Reviewed-by: Linus Walleij
Nice.
I hope someone comes around and update all panel drivers to use
dev_err_probe. It is simpler and better than the
Hi Guido,
On Wed, Nov 18, 2020 at 09:29:47AM +0100, Guido Günther wrote:
> This adds new panel type to the mantix driver as found on the Librem 5 and
> fixes a glitch in the init sequence (affecting both panels). The fix is at the
> start of the series to make backporting simpler.
> It also adds
Hi Bernard.
On Wed, Nov 18, 2020 at 11:29:55PM -0800, Bernard Zhao wrote:
> This change also fix checkpatch.pl warning:
> WARNING: Prefer using '"%s...", __func__' to using
> 'via_driver_irq_postinstall', this function's name, in a string
> + DRM_DEBUG("via_driver_irq_postinstall\n");
>
>
On Thu, Nov 19, 2020 at 03:07:07PM +0100, Linus Walleij wrote:
> "val" isn't initialized on the default: errorpath.
> Just return from the function if this happens.
>
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Linus Walleij
Reviewed-by: Sam Ravnborg
In the
On 2020-11-23 03:18, Lee Jones wrote:
These tables are not large or overbearing, so moving them into the
source file seems like the right thing to do. The alternative is to
use __maybe_unused, which is undesirable.
Fixes the following W=1 kernel build warning(s):
In file included from
On 2020-11-23 03:19, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/msm_drv.c:124:15: warning: no previous prototype
for ‘_msm_ioremap’ [-Wmissing-prototypes]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc:
On 2020-11-23 03:19, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:247: warning: Excess function
parameter 'Return' description in '_dpu_rm_check_lm_peer'
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c:283: warning: Function
parameter or
On 2020-11-23 03:19, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:152: warning: Function
parameter or member 'plane' not described in '_dpu_plane_calc_bw'
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:152: warning: Function
parameter
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c:55: warning: Function
parameter or member 'ctx' not described in '_stage_offset'
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c:55: warning: Excess
function parameter
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function
parameter or member 'ctx' not described in 'dpu_hw_sspp_setup_format'
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c:240: warning: Function
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:31: warning: Enum value
'DPU_PERF_MODE_MAX' not described in enum 'dpu_perf_mode'
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:34: warning: Cannot
understand
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:207: warning: Function
parameter or member 'cur_slave' not described in 'dpu_encoder_virt'
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:207: warning: Function
On 11/23/20 3:41 PM, Christian König wrote:
Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky:
On 11/23/20 3:20 PM, Christian König wrote:
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky:
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function
parameter or member 'fmt' not described in 'INTERLEAVED_RGB_FMT'
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:50: warning: Function
parameter
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: warning:
initialized field overwritten [-Woverride-init]
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:124:19: note: (near
initialization for
On 2020-11-23 03:18, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c:28: warning: Function
parameter or member 'hw_blk' not described in 'dpu_hw_blk_init'
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c:120: warning: Excess
function
Hi Neil.
Looks good but a few comments in the following that needs some attention.
Sam
On Mon, Nov 23, 2020 at 03:33:54PM +0100, Neil Armstrong wrote:
> This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to
> work
> with the Khadas Edge-V, Captain, VIM3 and VIM3L
https://bugzilla.kernel.org/show_bug.cgi?id=203905
Germán Ríos González (german.rios.gonza...@gmail.com) changed:
What|Removed |Added
CC|
On Mon, Nov 23, 2020 at 03:33:53PM +0100, Neil Armstrong wrote:
> This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel
> designed to work
> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Sam Ravnborg
Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky:
On 11/23/20 3:20 PM, Christian König wrote:
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky:
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple
On 11/23/20 3:20 PM, Christian König wrote:
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky:
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
It would
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> wrote:
> > Well, I used git. It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple
Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky:
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
It would be cleaner if we could do the whole handling
On 11/25/20 5:42 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
It would be cleaner if we could do the whole handling in TTM. I also need to
double check what you are
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, November 23, 2020 10:05 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re:
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, November 23, 2020 10:02 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re:
On Fri, Nov 20, 2020 at 11:25:45AM +0100, Thomas Zimmermann wrote:
> Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which
> in turn requires pinning the BO. While being pinned, the BO cannot be moved
> into VRAM for scanout. Consequently, a concurrent modeset operation that
>
On Fri, Nov 20, 2020 at 11:25:44AM +0100, Thomas Zimmermann wrote:
> Copy the vmap()'ed instance of struct dma_buf_map before modifying it,
> in case the implementation of vunmap() depends on the exact address.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
On Fri, Nov 20, 2020 at 11:25:43AM +0100, Thomas Zimmermann wrote:
> If the damage handling fails, restore the damage area. The next invocation
> of the damage worker will then perform the update.
>
> v2:
> * print a single warning if dirty callback fails (Daniel, Sebastian)
> *
On Fri, Nov 20, 2020 at 11:25:42AM +0100, Thomas Zimmermann wrote:
> Introduce a separate function for the blit code and its vmap setup. Done
> in preparation of additional changes. No functional changes are made.
>
> v2:
> * print a single warning if damage blitter fails
>
>
On Fri, Nov 20, 2020 at 11:25:41AM +0100, Thomas Zimmermann wrote:
> Flushing the shadow framebuffer and invoking the dirty callback are two
> separate operations, so do them seprately. The flush operation is paired
> with calls to vmap and vunmap. They are not needed for the dirty callback,
>
On Fri, Nov 20, 2020 at 11:25:40AM +0100, Thomas Zimmermann wrote:
> Returning early in the dirty worker if no update is required makes the
> code more readable. No functional changes are made.
>
> Signed-off-by: Thomas Zimmermann
It is a damage worker (both subject and changelog).
On Fri, Nov 20, 2020 at 11:25:39AM +0100, Thomas Zimmermann wrote:
> The dirty worker handles all damage updates, instead of just calling
> the framebuffer's dirty callback. Rename it to damage worker. Also
> rename related variables accordingly. No functional changes are made.
>
> Signed-off-by:
On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan
wrote:
>
> On 2020-11-23 20:51, Will Deacon wrote:
> > On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:
> >> Some hardware variants contain a system cache or the last level
> >> cache(llc). This cache is typically a large block
On Fri, Nov 20, 2020 at 11:25:37AM +0100, Thomas Zimmermann wrote:
> The fbdev helper's generic probe function establishes a mapping for
> framebuffers without shadow buffer. The clean-up function did not unmap
> the buffer object. Add the unmap operation.
>
> As fbdev devices are usally released
On Fri, Nov 20, 2020 at 11:25:36AM +0100, Thomas Zimmermann wrote:
> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
> the update might not make it to the screen.
>
> v2:
> * mark virtual screen as dirty (Ville)
>
> Signed-off-by: Thomas Zimmermann
> Fixes:
Am 23.11.20 um 13:32 schrieb Maxime Ripard:
On Mon, Nov 23, 2020 at 12:56:44PM +0100, Thomas Zimmermann wrote:
This patchset moves CMA's mmap into a GEM object function. This change
allows for removing CMA's mmap and gem_prime_mmap callbacks in favor of
the default implementation.
Tested
On 19/11/2020 18:01, Nikhil Devshatwar wrote:
> When removing the tidss driver, there is a warning reported by
> kernel about an unhandled interrupt for mhdp driver.
>
> [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
> ... [snipped backtrace]
> [ 43.330735]
The filter defintion is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).
Also fix a typo in the comments.
Signed-off-by: Jianxin Xiong
---
tests/utils.py | 6 +++---
1 file changed, 3
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' for dma-buf object allocation.
Signed-off-by: Jianxin Xiong
---
pyverbs/CMakeLists.txt | 2 ++
pyverbs/dmabuf.pxd | 13 +
pyverbs/dmabuf.pyx | 58
Define a full set of tests similar to regular MR tests. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/test_mr.py | 130 ++-
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 23 +++
3 files changed, 28 insertions(+)
diff --git
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14
libibverbs/cmd_mr.c | 38
This is the user space counter-part of the kernel patch set to add
dma-buf support to the RDMA subsystem. This patch series adds user
space API for registering dma-buf based memory regions, updates
pyverbs with the new API, and adds new tests.
This series consists of five patches. The first patch
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 114
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
This is the eleventh version of the patch set. Changelog:
v11:
* Rework the parameter checking code inside ib_umem_dmabuf_get()
* Fix incorrect error handling in the new verbs command handler
* Put a duplicated code sequence for checking iova and setting page size
into a function
* In the
Hi,
On Mon, Nov 9, 2020 at 5:01 PM Douglas Anderson wrote:
>
> When I run:
> scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c
>
> I see that several of the kernel-doc entries aren't showing up because
> they don't specify the full path down the hierarchy. Let's fix that
> and also
On 11/22/20 10:22 AM, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
>> On 11/21/20 9:10 AM, Joe Perches wrote:
>>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
A difficult part of automating commits is composing the subsystem
preamble in the commit
https://bugzilla.kernel.org/show_bug.cgi?id=210321
Bug ID: 210321
Summary: /display/dc/dcn20/dcn20_resource.c:3240
dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu]
Product: Drivers
Version: 2.5
Kernel Version: 5.10.0-rc5
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe
https://bugzilla.kernel.org/show_bug.cgi?id=201957
majorgo...@juno.com changed:
What|Removed |Added
CC||majorgo...@juno.com
--- Comment
On Wed, Nov 18, 2020 at 10:13 AM Maxime Ripard wrote:
>
> Hi Arnd, Olof,
>
> Here's the PR for the MBUS rework we discussed in the last couple of
> weeks, for what will become 5.11.
>
> As Arnd suggested, this is based on a PR sent to drm-misc-fixes to merge
> the initial fix for a probe error in
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > wrote:
[cut]
> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
>
On 23-11-20, 11:46, Robert Foss wrote:
> 4k requires two dsi pipes, so don't report MODE_OK when only a
> single pipe is configured. But rather report MODE_PANEL to
> signal that requirements of the panel are not being met.
Acked-By: Vinod Koul
> Reported-by: Peter Collingbourne
>
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches. Let's be conservative and assume
On Sat, 21 Nov 2020, James Bottomley
wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of
https://bugzilla.kernel.org/show_bug.cgi?id=210317
--- Comment #1 from Sujay1844 (sujay1...@protonmail.com) ---
btw the same issue persists for 5.6, 5.7, 5.8 and 5.9 kernels.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=210317
Bug ID: 210317
Summary: Sleep mode not working in ryzen 4000 laptop
Product: Drivers
Version: 2.5
Kernel Version: 5.10.rc4
Hardware: All
OS: Linux
Tree:
On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:
> Some hardware variants contain a system cache or the last level
> cache(llc). This cache is typically a large block which is shared
> by multiple clients on the SOC. GPU uses the system cache to cache
> both the GPU data
On Tue, Nov 17, 2020 at 08:00:42PM +0530, Sai Prakash Ranjan wrote:
> Now that we have a struct domain_attr_io_pgtbl_cfg with quirks,
> use that for non_strict mode as well thereby removing the need
> for more members of arm_smmu_domain in the future.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
On Tue, Nov 17, 2020 at 08:00:41PM +0530, Sai Prakash Ranjan wrote:
> Add iommu domain attribute for pagetable configuration which
> initially will be used to set quirks like for system cache aka
> last level cache to be used by client drivers like GPU to set
> right attributes for caching the
On Tue, Nov 17, 2020 at 08:00:40PM +0530, Sai Prakash Ranjan wrote:
> Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
> the attributes set in TCR for the page table walker when
> using system cache.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/io-pgtable-arm.c | 10
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:50寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: ‘mtk_dpi_encoder_funcs’
> defined but not used [-Wunused-const-variable=]
>
Thanks for this patch, but I've applied another identical
This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to
work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.
The init values was taken from the vendor source
This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel designed
to work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
1 file changed, 2
This add support & bindings for the Khadas TS050 1080x1920 5" LCD DSI panel
designed
to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.
Neil Armstrong (2):
dt-bindings:
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 上午3:01寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_color'
> drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning:
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:49寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_drm_drv.c:316:24: warning: no previous
> prototype for ‘mtk_drm_gem_prime_import’ [-Wmissing-prototypes]
>
Applied to mediatek-drm-next [1], thanks.
[1]
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 下午9:49寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_rdma'
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning:
Hi, Lee:
Lee Jones 於 2020年11月13日 週五 上午3:01寫道：
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
> member 'ddp_comp' not described in 'mtk_disp_ovl'
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function
Hi, Robin:
Robin Murphy 於 2020年9月4日 週五 上午4:59寫道：
>
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Also the DMA segment size is simply a
On 2020-11-23 14:03, Jerome Brunet wrote:
On Fri 20 Nov 2020 at 10:42, Marc Zyngier wrote:
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action that will
On Fri 20 Nov 2020 at 10:42, Marc Zyngier wrote:
> The HDMI driver request clocks early, but never disable them, leaving
> the clocks on even when the driver is removed.
>
> Fix it by slightly refactoring the clock code, and register a devm
> action that will eventually disable/unprepare the
1 - 100 of 159 matches
Mail list logo
