On Thu, May 26, 2022 at 6:29 AM Tvrtko Ursulin
wrote:
>
>
> On 26/05/2022 04:15, Rob Clark wrote:
> > On Wed, May 25, 2022 at 9:11 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 24/05/2022 15:57, Rob Clark wrote:
> >>> On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> >>> wrote:
>
> On
On Thu, May 26, 2022 at 4:38 AM Tvrtko Ursulin
wrote:
>
>
> On 26/05/2022 04:37, Rob Clark wrote:
> > On Wed, May 25, 2022 at 9:22 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 25/05/2022 14:41, Rob Clark wrote:
> >>> On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
> >>> wrote:
>
>
>
Daniel Thompson 於 2022年5月26日 週四 下午6:05寫道：
>
> On Thu, May 26, 2022 at 11:16:35AM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add the property parsing for ocp level selection.
>
> Isn't this just restating the Subject: line?
>
Ah, that's my fault. I didn't state too much in the patch
"Sierra Guiza, Alejandro (Alex)" writes:
> On 5/24/2022 11:11 PM, Alistair Popple wrote:
>> Alex Sierra writes:
>>
>>> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
>>> device-managed anonymous pages that are not LRU pages. Although they
>>> behave like normal pages for
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote:
> I don't mind adding DRM support for BootX displays, but getting the
> necessary test HW with a suitable Linux seems to be laborious. Would
> a G4 Powerbook work?
Probably not unfortunately... it's going to be tricky. I might sitll
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote:
>
> > The palette handling is useful when using a real Open Firmware
> > implementation which tends to boot in 8-bit mode, so without palette
> > things will look ... bad.
> >
> > It's not necessary when using 16/32 bpp framebuffers
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
Remove plane checks/state updates from dpu_crtc_atomic_check(). The
belong to dpu_plane_atomic_check().
The --> They
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 44 ---
Quoting Kuogee Hsieh (2022-05-25 14:02:18)
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Douglas Anderson
> ---
Reviewed-by: Stephen Boyd
Quoting Kuogee Hsieh (2022-05-26 10:26:18)
> During display resolution changes display have to be disabled first
> followed by display enable with new resolution. This patch force
> main link always be retrained during display enable procedure to
> simplify implementation instead of manually
Replace Panfrost's memory shrinker with a generic drm-shmem memory
shrinker.
Tested-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4 -
drivers/gpu/drm/panfrost/panfrost_drv.c |
Don't return -1 in error cases, return proper error code. The returned
error codes propagate to error messages and to userspace and it's always
good to have a meaningful error number for debugging purposes.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 6 +++---
1
Use common dev_is_pci() helper to replace the strcmp("pci") used by driver.
Suggested-by: Robin Murphy
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest
Add unlocked variants of drm_gem_un/pin() functions and make them public.
These new helpers will take care of GEM dma-reservation locking for DRM
drivers.
We are going to add memory shrinking support to the VirtIO-GPU driver
that will need to pin framebuffers explicitly to prevent eviction of the
Replace drm_gem_shmem locks with GEM reservation lock to make drm-shmem
locks consistent with the new locking convention of dma-bufs which tells
that dma-buf importers are responsible for holding reservation lock for
all operations performed over dma-bufs. This prepares drm-shmem code for
addition
Introduce a common DRM SHMEM shrinker framework that allows to reduce
code duplication among DRM drivers by replacing theirs custom shrinker
implementations with the generic shrinker.
In order to start using DRM SHMEM shrinker drivers should:
1. Implement new evict() shmem object callback.
2.
There is no need to refcount vmappings of dma-bufs because dma-buf core
has its own refcounting. Drop the refcounting of dma-bufs. This will ease
replacing of all drm-shmem locks with a single dma-buf reservation lock,
preparing drm-shmem code for addition of the generic drm-shmem shrinker.
Change the order of SHMEM initialization and reservation locking
to make code cleaner and to prepare for transitioning of the common
GEM SHMEM code to use the GEM's reservation lock instead of the
shmem.page_lock.
There is no need to lock reservation during allocation of the SHMEM pages
because
All dma-bufs have dma-reservation lock that allows drivers to perform
exclusive operations over shared dma-bufs. Today's dma-buf API has
incomplete locking specification, which creates dead lock situation
for dma-buf importers and exporters that don't coordinate theirs locks.
This patch
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
GPU
drm_gem_shmem_get_sg_table() never ever returned NULL on error. Correct
the error handling to avoid crash on OOM.
Cc: sta...@vger.kernel.org
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_object.c | 6 --
1 file changed, 4 insertions(+), 2
Unlock reservations on dma_resv_reserve_fences() error to fix recursive
locking of the reservations when this error happens.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The vmapping of dma-buf may succeed, but DRM SHMEM rejects the iomem
mappings, and thus, drm_gem_shmem_vmap_locked() should unvmap the iomem
before erroring out.
Cc: sta...@vger.kernel.org
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and
convert GEM backends")
drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
Correct the doc comment which says that it returns NULL on error.
Acked-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
1 file changed, 4 insertions(+), 2
Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core
wants to clean up and not the current plane's state. Normally the older
atomic state is cleaned up, but the newer state could also be cleaned up
in case of aborted commits.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry
Unlock reservations in the error code path of virtio_gpu_object_create()
to silence debug warning splat produced by ww_mutex_destroy(>lock)
when GEM is released with the held lock.
Cc: sta...@vger.kernel.org
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
Transferred 2D BO always must be a shmem BO. Add check for that to prevent
NULL dereference if userspace passes a VRAM BO.
Cc: sta...@vger.kernel.org
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1
When panfrost_mmu_map_fault_addr() fails, the BO's mapping should be
unreferenced and not the shmem object which backs the mapping.
Cc: sta...@vger.kernel.org
Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. For example, on NVIDIA Tegra we get a hard
lockup when userspace writes to the memory mapping of a dma-buf that was
imported
Calling madvise IOCTL twice on BO causes memory shrinker list corruption
and crashes kernel because BO is already on the list and it's added to
the list again, while BO should be removed from from the list before it's
re-added. Fix it.
Cc: sta...@vger.kernel.org
Fixes: 013b65101315
Use ww_acquire_fini() in the error code paths. Otherwise lockdep
thinks that lock is held when lock's memory is freed after the
drm_gem_lock_reservations() error. The WW needs to be annotated
as "freed", which fixes the noisy "WARNING: held lock freed!" splat
of VirtIO-GPU driver with
Hello,
This patchset introduces memory shrinker for the VirtIO-GPU DRM driver
and adds memory purging and eviction support to VirtIO-GPU driver.
The new dma-buf locking convention is introduced here as well.
During OOM, the shrinker will release BOs that are marked as "not needed"
by userspace
Hello again,
I tried to dig around a bit to unearth some more information. What I'm
seeing is that it works just fine in the beginning, planes are updated a
couple of times and suddenly, after one of the plane updates, the
interrupt handler in the FIMD driver is no longer called. The screen
goes
During display resolution changes display have to be disabled first
followed by display enable with new resolution. This patch force
main link always be retrained during display enable procedure to
simplify implementation instead of manually kicking of irq_hpd
handle.
Changes in v2:
-- set
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify
On Thu, May 26, 2022 at 12:40 PM Simon Ser wrote:
> To discover support for new DMA-BUF IOCTLs, user-space has no
> choice but to try to perform the IOCTL on an existing DMA-BUF.
> However, user-space may want to figure out whether or not the
> IOCTL is available before it has a DMA-BUF at hand,
While trying to fix another issue, it occurred to me that I don't actually
think there is any situation where we want pm_runtime_put() in nouveau to
be synchronous. In fact, this kind of just seems like it would cause
issues where we may unexpectedly block a thread we don't expect to be
blocked.
Since this isn't actually a failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index
It looks like that when we moved nouveau over to using drm_dp_aux_init()
and registering it's aux bus during late connector registration, we totally
forgot to fix the failure codepath in nouveau_connector_create() - as it
still seems to assume that drm_dp_aux_init() can fail (it can't).
So, let's
Hi Dave, Daniel,
This is an additional pull on top of the one I send a few minutes ago.
It adds a minor UAPI change and updates the fdinfo format to match
the generic drm fdinfo format. They are pretty small, but if you'd prefer,
I can wait until next cycle.
The following changes since commit
A remove callback that just returns 0 is equivalent to no callback at all
as can be seen in i2c_device_remove(). So simplify accordingly.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
On 5/13/2022 11:37 PM, Dmitry Baryshkov wrote:
On 04/05/2022 01:32, Abhinav Kumar wrote:
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_pipe instance from struct dpu_plane to struct dpu_plane_state, as
it will become a
Just noticed a small nit on this one :
ordering via these fences, it is the respnosibility of userspace to use
-> responsibility
Acked-by: Lionel Landwerlin
Cheers,
-Lionel
Acked-by: Lionel Landwerlin
On Wed, May 25, 2022 at 3:36 PM Dmitry Baryshkov
wrote:
> On Mon, 23 May 2022 at 15:55, Linus Walleij wrote:
> > Nope, failed:
> >
> > $ dim push-branch drm-misc-next
> > dim: ac890b9eeb9b ("drm/display: Fix build error without CONFIG_OF"):
> > Fixes: SHA1 in not pointing at an ancestor:
> >
Hi Dave, Daniel,
Fixes for 5.19. The size is largely due to updates to new IPs which
were added in this cycle.
The following changes since commit c4955d9cd2fc56c43e78c908dad4e2cac7cc9073:
Merge tag 'drm-intel-next-fixes-2022-05-24' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather
than .remove") fixed a use-after-free error due the vesafb driver freeing
the fb_info in the .remove handler instead of doing it in .fb_destroy.
This can happen if the .fb_destroy callback is executed after the .remove
On Thursday, May 26th, 2022 at 19:40, Simon Ser wrote:
> diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
> b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
> index 5d3bc997dc64..682d313689d8 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
> +++
To discover support for new DMA-BUF IOCTLs, user-space has no
choice but to try to perform the IOCTL on an existing DMA-BUF.
However, user-space may want to figure out whether or not the
IOCTL is available before it has a DMA-BUF at hand, e.g. at
initialization time in a Wayland compositor.
Add a
To discover support for new DMA-BUF IOCTLs, user-space has no
choice but to try to perform the IOCTL on an existing DMA-BUF.
However, user-space may want to figure out whether or not the
IOCTL is available before it has a DMA-BUF at hand, e.g. at
initialization time in a Wayland compositor.
Add a
During display resolution changes display have to be disabled first
followed by display enable with new resolution. This patch force
main link always be retrained during display enable procedure to
simplify implementation instead of manually kicking of irq_hpd
handle.
Signed-off-by: Kuogee Hsieh
On Thu, 26 May 2022 at 18:30, Simon Ser wrote:
>
> Document how to obtain the size of a DMA-BUF. This is what
> Wayland compositors are doing.
>
> Mention the kernel version numbers from which DMA-BUF features are
> available.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Jason
Document how to obtain the size of a DMA-BUF. This is what
Wayland compositors are doing.
Mention the kernel version numbers from which DMA-BUF features are
available.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jason Ekstrand
---
include/uapi/linux/dma-buf.h | 10 +++---
1 file
On 5/24/2022 11:11 PM, Alistair Popple wrote:
Alex Sierra writes:
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not
Hi,
On Thu, May 26, 2022 at 8:42 AM Daniel Vetter wrote:
>
> On Thu, 26 May 2022 at 03:28, Sean Paul wrote:
> >
> > On Wed, May 25, 2022 at 9:26 AM Daniel Vetter wrote:
> > >
> > > On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Fri, May 20, 2022
The uAPI looks good to me as well, if that helps.
Acked-by: Simon Ser
On Thu, 26 May 2022 at 03:28, Sean Paul wrote:
>
> On Wed, May 25, 2022 at 9:26 AM Daniel Vetter wrote:
> >
> > On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Fri, May 20, 2022 at 5:01 PM Doug Anderson
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On
On Thu, May 26, 2022 at 03:28:25PM +0100, Matthew Wilcox wrote:
> On Thu, May 26, 2022 at 11:48:32AM +0300, Dan Carpenter wrote:
> > On Thu, May 26, 2022 at 02:16:34AM +0100, Matthew Wilcox wrote:
> > > Bizarre this started showing up now. The recent patch was:
> > >
> > > - info->alloced
Hi Linus, Yue,
On 23/05/2022 15:54, Linus Walleij wrote:
On Mon, May 23, 2022 at 2:46 PM Linus Walleij wrote:
On Fri, May 6, 2022 at 2:33 PM YueHaibing wrote:
While CONFIG_OF is n but COMPILE_TEST is y, we got this:
WARNING: unmet direct dependencies detected for DRM_DP_AUX_BUS
Depends
Acked-by: Bas Nieuwenhuizen
Didn't test the latest version of everything, but I can confirm the
UAPI worked fine for what we'd want to use it for with radv.
On Thu, May 26, 2022 at 8:47 AM Jason Ekstrand wrote:
>
> On Wed, May 25, 2022 at 5:02 AM Daniel Stone wrote:
>>
>> On Sat, 7 May 2022
Applied. Thanks!
Alex
On Thu, May 26, 2022 at 5:29 AM <1064094...@qq.com> wrote:
>
> From: pengfuyuan
>
> Fix spelling typo in comments.
>
> Reported-by: k2ci
> Signed-off-by: pengfuyuan
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
>
On Thu, May 26, 2022 at 11:48:32AM +0300, Dan Carpenter wrote:
> On Thu, May 26, 2022 at 02:16:34AM +0100, Matthew Wilcox wrote:
> > Bizarre this started showing up now. The recent patch was:
> >
> > - info->alloced += compound_nr(page);
> > - inode->i_blocks += BLOCKS_PER_PAGE <<
On 26/05/2022 12:42, Viresh Kumar wrote:
> The OPP core now provides a unified API for setting all configuration
> types, i.e. dev_pm_opp_set_config().
>
> Lets start using it.
>
> Signed-off-by: Viresh Kumar
Acked-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9
On 26/05/2022 04:15, Rob Clark wrote:
On Wed, May 25, 2022 at 9:11 AM Tvrtko Ursulin
wrote:
On 24/05/2022 15:57, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
btw, one fun (but unrelated) issue I'm hitting with
On Friday, May 6th, 2022 at 20:02, Jason Ekstrand wrote:
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index 46f1e3e98b02..70e213a0d7d9 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -96,6 +96,24 @@ struct dma_buf_sync {
> *
On Mon, 23 May 2022 at 15:25, Marek Vasut wrote:
>
> On 5/23/22 15:20, Jonathan Liu wrote:
> > Hi Marek,
> >
> > On Mon, 23 May 2022 at 23:15, Marek Vasut wrote:
> >>
> >> On 5/23/22 15:01, Jonathan Liu wrote:
> >>> The code from [1] sets SYS_CTRL_1 to different values depending on the
> >>>
On Thu, 26 May 2022 at 00:34, Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Wed, May 25, 2022 at 03:56:26PM -0500, Rob Herring wrote:
> > While 'ddc-i2c-bus' is a common property, it should be in a connector
> > node rather than the HDMI bridge node as the I2C bus goes
On Thu, 26 May 2022 at 01:50, Alvin Šipraga wrote:
>
> On Wed, May 25, 2022 at 06:53:16PM -0300, Fabio Estevam wrote:
> > ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[]
> > are only used inside adv7511_cec.c.
> >
> > Move their definitions to this file to avoid the following
On 19/05/2022 19:21, Abhinav Kumar wrote:
Hi Rob
Here is the pull request for the fixes for 5.19.
Just a few more changes on top of msm-fixes-staging.
Mainly it has the foll fixes:
- Limiting WB modes to max sspp linewidth
- Fixing the supported rotations to add 180 back for IGT
- Fix to
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/tegra/gr3d.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/gr3d.c
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +-
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
Hello,
We have too many configuration specific APIs currently, six of them already,
like dev_pm_opp_set_regulators(). This makes it complex/messy for both the OPP
core and its users to manage. There is also code redundancy in these API, in the
way they add/manage the OPP table specific stuff.
On 5/26/22 08:27, pengfuyuan wrote:
> Fix spelling typo in comment.
>
> Signed-off-by: pengfuyuan
applied to the fbdev git tree.
Thanks!
Helge
> ---
> include/video/radeon.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/video/radeon.h
On 26/05/2022 04:37, Rob Clark wrote:
On Wed, May 25, 2022 at 9:22 AM Tvrtko Ursulin
wrote:
On 25/05/2022 14:41, Rob Clark wrote:
On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
wrote:
On 24/05/2022 15:50, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On
On 26/05/2022 10:13, ChiYuan Huang wrote:
> Krzysztof Kozlowski 於 2022年5月26日 週四 下午4:06寫道：
>>
>> On 26/05/2022 05:16, cy_huang wrote:
>>> From: ChiYuan Huang
>>>
>>> Add the new property for ocp level selection.
>>>
>>> Signed-off-by: ChiYuan Huang
>>> ---
>>>
On 25/05/2022 19:14, Lucas De Marchi wrote:
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no
On 25/05/2022 19:05, Matt Roper wrote:
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles
On Thu, May 26, 2022 at 11:16:35AM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add the property parsing for ocp level selection.
Isn't this just restating the Subject: line?
It would be better to provide information useful to the reviewer here.
Something like:
"Currently this driver
Hi Daniel, Dave,
Here's this week drm-misc-fixes PR.
Maxime
drm-misc-fixes-2022-05-26:
A use-after-free fix for panfrost, and a DT invalid configuration fix for
ti-sn65dsi83
The following changes since commit 6e03b13cc7d9427c2c77feed1549191015615202:
drm/dp/mst: fix a possible memory leak in
On Thu, May 26, 2022 at 02:16:34AM +0100, Matthew Wilcox wrote:
> Bizarre this started showing up now. The recent patch was:
>
> - info->alloced += compound_nr(page);
> - inode->i_blocks += BLOCKS_PER_PAGE << compound_order(page);
> + info->alloced += folio_nr_pages(folio);
> +
On 25/05/2022 15:57, Alyssa Rosenzweig wrote:
> From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more
> or less compatible with Bifrost, although they differ to userspace. Add
> a compatible for Valhall to the existing Bifrost bindings documentation.
>
> As the first SoC with a
On 25/05/2022 15:57, Alyssa Rosenzweig wrote:
> Add the features, issues, and GPU ID for Mali-G57, a first-generation
> Valhall GPU. Other first- and second-generation Valhall GPUs should be
> similar.
>
> v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was
> fixed in r0p1.
On 26/05/2022 09:10, Matthew Auld wrote:
On 26/05/2022 08:58, Tvrtko Ursulin wrote:
On 25/05/2022 19:43, Matthew Auld wrote:
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in
On Wed, May 25, 2022 at 11:35 PM kernel test robot wrote:
> .__mulsi3.o.cmd: No such file or directory
> Makefile:686: arch/h8300/Makefile: No such file or directory
> Makefile:765: arch/h8300/Makefile: No such file or directory
> arch/Kconfig:10: can't open file "arch/h8300/Kconfig"
Please stop
On Wed, May 25, 2022 at 02:50:56PM -0700, Andrew Morton wrote:
> On Thu, 26 May 2022 05:35:20 +0800 kernel test robot wrote:
>
> > tree/branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add
Krzysztof Kozlowski 於 2022年5月26日 週四 下午4:06寫道：
>
> On 26/05/2022 05:16, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add the new property for ocp level selection.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > .../bindings/leds/backlight/richtek,rt4831-backlight.yaml | 8
> >
On 26/05/2022 08:58, Tvrtko Ursulin wrote:
On 25/05/2022 19:43, Matthew Auld wrote:
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
I
On 26/05/2022 05:16, cy_huang wrote:
> From: ChiYuan Huang
>
> Add the new property for ocp level selection.
>
> Signed-off-by: ChiYuan Huang
> ---
> .../bindings/leds/backlight/richtek,rt4831-backlight.yaml | 8
>
> include/dt-bindings/leds/rt4831-backlight.h
On 25/05/2022 19:43, Matthew Auld wrote:
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
I have concerns here that it isn't useful and
New updates to HDMI combo PHY voltage swing tables. Actually with this
update (bspec updated on 08/17/2021), the values are reverted back to be
same as icelake for HDMI combo PHY.
Bspec: 49291
Signed-off-by: Balasubramani Vivekanandan
---
.../drm/i915/display/intel_ddi_buf_trans.c| 22
On Wed, May 25, 2022 at 5:02 AM Daniel Stone wrote:
> On Sat, 7 May 2022 at 14:18, Jason Ekstrand wrote:
> > This patch series actually contains two new ioctls. There is the export
> one
> > mentioned above as well as an RFC for an import ioctl which provides the
> other
> > half. The
Removed trailing whitespace from end of line in amdgpu_device.c
Signed-off-by: Mitchell Augustin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
> On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > Reviewed-by: Christian König for the series.
> >
> > I assume you have the userspace part ready as well? If yes let's push
> this
> > to drm-misc-next asap.
>
> Hopefully
On Wed, May 25, 2022 at 06:53:16PM -0300, Fabio Estevam wrote:
> ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[]
> are only used inside adv7511_cec.c.
>
> Move their definitions to this file to avoid the following build
> warnings when CONFIG_DRM_I2C_ADV7511_CEC is not selected:
On Wed, May 25, 2022 at 10:43 AM Daniel Vetter wrote:
> On Wed, May 25, 2022 at 10:35:47AM -0500, Jason Ekstrand wrote:
> > On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
> >
> > > On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > > > Reviewed-by: Christian König for
Fix spelling typo in comment.
Signed-off-by: pengfuyuan
---
include/video/radeon.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/video/radeon.h b/include/video/radeon.h
index 005eae19ec09..72f94ccfa725 100644
--- a/include/video/radeon.h
+++
98 matches
Mail list logo
