On Tue, Jul 27, 2021 at 04:37:22PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > > Inside drm_is_current_master, using the outer drm_device.master_mutex
> > > to protect re
On 27/07/2021 21:27, Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
DRM IRQ callbacks are now being called directly or inlined.
Signed-off-by: Thomas Zimmer
On Wed, Jul 28, 2021 at 10:58:51AM -0700, Rob Clark wrote:
> On Wed, Jul 28, 2021 at 10:23 AM Christian König
> wrote:
> >
> >
> >
> > Am 28.07.21 um 17:15 schrieb Rob Clark:
> > > On Wed, Jul 28, 2021 at 4:37 AM Christian König
> > > wrote:
> > >> Am 28.07.21 um 09:03 schrieb Christian König:
>
Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
on a non existing config option to actually emit some code.
Nuke them and clean up the dma_fence_signal* return value.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 44 +--
As we now knew controlling dma_fence synchronization from userspace is
extremely dangerous and can not only deadlock drivers but trivially also the
whole kernel memory management.
Entirely remove this option. We now have in kernel unit tests to exercise the
dma_fence framework and it's containers.
Entirely unused.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 2 +-
drivers/dma-buf/seqno-fence.c | 71 --
include/linux/seqno-fence.h | 109 --
3 files changed, 1 insertion(+), 181 deletions(-)
delete mode 100644 dr
On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer wrote:
> >
> > On 2021-07-28 3:13 p.m., Christian König wrote:
> > > Am 28.07.21 um 15:08 schrieb Michel Dänzer:
> > >> On 2021-07-28 1:36 p.m., Christian König wrote:
> > >>> Am 27.07.21 um
On Wed, Jul 28, 2021 at 06:27:39PM +0800, Desmond Cheong Zhi Xi wrote:
> We make the following changes to the documentation of drm leases to
> make it easier to reason about their usage. In particular, we clarify
> the lifetime and locking rules of lease fields in drm_master:
>
> 1. Make it clear
On Wed, Jul 28, 2021 at 01:52:42PM -0700, Rob Clark wrote:
> Hi Dave & Daniel,
>
> An early pull for v5.15 (there'll be more coming in a week or two),
> consisting of the drm/scheduler conversion and a couple other small
> series that one was based one. Mostly sending this now because IIUC
> danv
On Thu, Jul 29, 2021 at 09:03:29AM +0200, Christian König wrote:
> Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
> on a non existing config option to actually emit some code.
>
> Nuke them and clean up the dma_fence_signal* return value.
>
> Signed-off-by: Christi
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> As we now knew controlling dma_fence synchronization from userspace is
> extremely dangerous and can not only deadlock drivers but trivially also the
> whole kernel memory management.
>
> Entirely remove this option. We now have in
On Thu, Jul 29, 2021 at 09:03:28AM +0200, Christian König wrote:
> Entirely unused.
>
> Signed-off-by: Christian König
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/Makefile | 2 +-
> drivers/dma-buf/seqno-fence.c | 71 --
> include/linux/seqno-fence.h | 109 --
Am 29.07.21 um 09:22 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:29AM +0200, Christian König wrote:
Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
on a non existing config option to actually emit some code.
Nuke them and clean up the dma_fence_signal*
On Thu, Jul 29, 2021 at 09:20:22AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 28, 2021 at 02:59:25PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
> >
> > > I guess those APIs you were talking about are KVM-only. For other
> > > hypervisors, e.g.
On 2021-07-28 4:30 p.m., Christian König wrote:
> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
>> On Wed, 28 Jul 2021 15:31:41 +0200
>> Christian König wrote:
>>
>>> Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian König wrote:
> Am 28.07.21 um 15:08 schrieb
On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
>> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer wrote:
>>> On 2021-07-28 3:13 p.m., Christian König wrote:
Am 28.07.21 um 15:08 schrieb Michel Dänzer:
> On 2021-07-28 1:36 p.m., Chr
Remove the repeated word 'the' from comments
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
.../gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 2 +-
.../drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c | 2 +-
.../gpu/dr
On 7/28/2021 8:59 PM, Jason Gunthorpe wrote:
> On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
>
>> I guess those APIs you were talking about are KVM-only. For other
>> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
>> sure if you have already noticed that VFIO is K
Remove the repeated word 'the' from comments
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/radeon/atombios.h | 4 ++--
drivers/gpu/drm/radeon/r300_reg.h | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
drivers/gpu/drm/radeon/radeon_
On Thu, Jul 29, 2021 at 07:56:27AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 28, 2021 at 11:37:30PM +0200, David Sterba wrote:
> > On Wed, Jul 28, 2021 at 02:37:20PM -0700, Bart Van Assche wrote:
> > > On 7/28/21 2:14 AM, Dan Carpenter wrote:
> > > > On Wed, Jul 28, 2021 at 10:59:22AM +0200, D
On Wed, 28 Jul 2021 16:30:13 +0200
Christian König wrote:
> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
> > On Wed, 28 Jul 2021 15:31:41 +0200
> > Christian König wrote:
> >
> >> Am 28.07.21 um 15:24 schrieb Michel Dänzer:
> >>> On 2021-07-28 3:13 p.m., Christian König wrote:
> Am 28
On Wed, Jul 28, 2021 at 04:33:18PM -0700, Kees Cook wrote:
>
> Ah-ha, got it:
>
Thanks, Kees! Nice!
regards,
dan carpenter
By separating the OUT_FENCE signalling from pageflip completion allows
a Guest compositor to start a new repaint cycle with a new buffer
instead of waiting for the old buffer to be free.
This work is based on the idea/suggestion from Simon and Pekka.
This capability can be a solution for this is
If a driver supports this capability, it means that it will take
ownership of signalling the OUT_FENCE from drm core. Therefore, the
OUT_FENCE will no longer be signalled at pageflip completion time but
instead at a later time as chosen by the driver.
This capability may only be relevant for VKMS
If this feature is available, the virtio-gpu driver will take
ownership of signalling the OUT_FENCE instead of drm core. As
a result, the OUT_FENCE will no longer be signalled along with
pageflip completion but at a later time.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/dr
This implements the hypercall interface for the resource_out_fence
command.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +
2 files changed, 21 insertions(+)
diff --git a/drivers/g
This feature enables the Guest to wait to know when a resource
is completely consumed by the Host.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
include/uapi/linux/virtio_gpu.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uap
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
As we now knew controlling dma_fence synchronization from userspace is
extremely dangerous and can not only deadlock drivers but trivially also the
whole kernel memory management.
Ent
Am 29.07.21 um 10:23 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 16:30:13 +0200
Christian König wrote:
Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König wrote:
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian Kö
On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
> >> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer wrote:
> >>> On 2021-07-28 3:13 p.m., Christian König wrote:
> Am 28
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
> Am 29.07.21 um 09:23 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> >> As we now knew controlling dma_fence synchronization from userspace is
> >> extremely dangerous and can not only deadlock
On 29/07/2021 01:20, Konrad Dybcio wrote:
VDDA is not present and the specified load value is wrong. Fix it.
Signed-off-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 1 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
2 files chang
On Thu, 29 Jul 2021 10:43:16 +0200
Christian König wrote:
> Am 29.07.21 um 10:23 schrieb Pekka Paalanen:
> > On Wed, 28 Jul 2021 16:30:13 +0200
> > Christian König wrote:
> >
> >> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
> >>> On Wed, 28 Jul 2021 15:31:41 +0200
> >>> Christian König wro
Hi Stefan,
On Wed, Jul 28, 2021 at 05:14:38PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 15.07.21 um 18:35 schrieb Stefan Wahren:
> > Hi guys,
> >
> > starting with Linux 5.14-rc1 the framebuffer console on Raspberry Pi 3/4
> > (no U-Boot, multi_v7_defconfig) isn't available anymore. The display
>
Hi Enric,
Thanks for your review.
On Wed, 2021-07-28 at 12:56 +0200, Enric Balletbo Serra wrote:
> Hi Jason,
>
> Missatge de Jason-JH Lin del dia dt., 27
> de jul. 2021 a les 4:53:
> >
> > Hi Enric,
> >
> > On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote:
> > > Hi Jason,
> > >
On Thu, 29 Jul 2021 11:03:36 +0200
Daniel Vetter wrote:
> On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > > On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
> > >> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer
>
Hi Jason,
url:
https://github.com/0day-ci/linux/commits/Jason-Gunthorpe/Provide-core-infrastructure-for-managing-open-release/20210729-085124
base: https://github.com/awilliam/linux-vfio.git next
config: x86_64-randconfig-m001-20210728 (attached as .config)
compiler: gcc-10 (Ubuntu 10.3.0
From: Leon Romanovsky
Changelog:
v3:
* Rewrote to new API suggestion
* Split for more patches
v2: https://lore.kernel.org/lkml/cover.1626605893.git.leo...@nvidia.com
* Changed implementation of first patch, based on our discussion with
Christoph.
https://lore.kernel.org/lkml/ynwavtt0qmqdx.
From: Maor Gottlieb
RDMA is the only in-kernel user that uses __sg_alloc_table_from_pages to
append pages dynamically. In the next patch. That mode will be extended
and that function will get more parameters. So separate it into a unique
function to make such change more clear.
Signed-off-by: Ma
From: Maor Gottlieb
This allows using the normal sg_table APIs and makes all the code
cleaner. Remove sgt, nents and nmapd from ib_umem.
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/core/umem.c | 32 +--
From: Maor Gottlieb
orig_nents should represent the number of entries with pages,
but __sg_alloc_table_from_pages sets orig_nents as the number of
total entries in the table. This is wrong when the API is used for
dynamic allocation where not all the table entries are mapped with
pages. It wasn't
No need to hand roll the set_placements stuff, now that that we have a
helper for this.
v2: add back the -ENODEV checking since it's possible for stolen to be
probed, and yet still be non-functional
Signed-off-by: Matthew Auld
Cc: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
.../drm/i915/ge
On Thu, Jul 29, 2021 at 01:16:57AM -0700, Vivek Kasireddy wrote:
> This feature enables the Guest to wait to know when a resource
> is completely consumed by the Host.
virtio spec update?
What are the exact semantics?
Why a new command? Can't you simply fence one of the commands sent
anyway (se
Hi,
> + bool has_out_fence;
> + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_OUT_FENCE)) {
> + vgdev->has_out_fence = true;
> + vgdev->ddev->mode_config.deferred_out_fence = true;
Looks like you don't need has_out_fence, you can just use
vgdev->ddev->mode_co
On 27/07/2021 02:13, Bjorn Andersson wrote:
eDP panels might need some power sequencing and backlight management,
so make it possible to associate a drm_panel with a DP instance and
prepare and enable the panel accordingly.
Signed-off-by: Bjorn Andersson
The idea looks good from my point of v
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
[SNIP]
But how does it then help to wait on the CPU instead?
A compositor does not "wait" literally. It would only check which state
set is ready to be used, and uses the most recent set that is ready. Any
state sets that are not ready are ignored an
Am 29.07.21 um 11:03 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
As we now knew controlling dma_fence synchronization from userspace is
extremely dan
On 2021-07-29 12:14 p.m., Christian König wrote:
> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
>> [SNIP]
>>> But how does it then help to wait on the CPU instead?
>> A compositor does not "wait" literally. It would only check which state
>> set is ready to be used, and uses the most recent set tha
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail&id=7
Signed-off-by: Alistair Francis
Acked-by: Rob Herring
---
v4:
- Fixup alphebetical sorting
.../bindings/display/panel/panel-simple.yaml | 2 ++
.../devicetree/bindings/vendor-prefix
On Wed, Jul 28, 2021 at 02:56:31PM -0700, Kees Cook wrote:
> On Wed, Jul 28, 2021 at 11:42:15AM +0200, David Sterba wrote:
> > On Tue, Jul 27, 2021 at 01:58:38PM -0700, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field bounds checking for mems
On Wed, Jul 28, 2021 at 02:54:52PM -0700, Kees Cook wrote:
> On Wed, Jul 28, 2021 at 11:23:23AM +0200, David Sterba wrote:
> > On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote:
> > > @@ -372,7 +372,7 @@ ieee80211_add_rx_radiotap_header(struct
> > > ieee80211_local *local,
> > >
Hi Matt,
On 28/07/2021 16:50, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enabl
On 29/07/2021 11:53, Tvrtko Ursulin wrote:
Hi Matt,
On 28/07/2021 16:50, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >
> > If the app happens to be frozen (e.g. some weird bug in fence handling
> > to make it never ready, or maybe it's just bugged itself and never
> > drawing again), then the app is frozen
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
>
> Contexts can onl
On Wed, Jul 28, 2021 at 03:03:22PM -0700, Lucas De Marchi wrote:
> This the part of https://patchwork.freedesktop.org/series/93056/
> that should go through drm-intel-gt-next branch.
Acked-by: Rodrigo Vivi
>
> Lucas De Marchi (4):
> drm/i915/gt: remove explicit CNL handling from intel_mocs.c
From: Matthew Auld
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the fa
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets do that by adding a
Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
If the app happens to be frozen (e.g. some weird bug in fence handling
to make it never ready, or maybe it's just bugged itself and never
drawing
Hey Doug,
Thank you for submitting this.
On Wed, 28 Jul 2021 at 18:46, Douglas Anderson wrote:
>
> When testing with a panel that's apparently a little more persnickety
> about the correct power sequence (specifically Samsung ATNA33XC20), we
> found that the ti-sn65dsi86 was doing things just sl
Hey Doug,
Thanks for submitting this.
On Wed, 28 Jul 2021 at 18:46, Douglas Anderson wrote:
>
> The manual has always said that we need 100 us delays in a few
> places. Though it hasn't seemed to be a big deal to skip these, let's
> add them in case it makes something happier.
>
> NOTE: this fix
On Thu, Jul 29, 2021 at 12:21 PM Christian König
wrote:
> Am 29.07.21 um 11:03 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 10:38 AM Christian König
> > wrote:
> >> Am 29.07.21 um 09:23 schrieb Daniel Vetter:
> >>> On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> As w
On Thu, Jul 29, 2021 at 1:19 PM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Usage of Transparent Hugepages was disabled in 9987da4b5dcf
> ("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
> appears majority of performance regressions reported with an enabled IOMMU
> c
On Thu, Jul 29, 2021 at 12:38:12PM +0300, Dan Carpenter wrote:
> This should just be:
> atomic_add(type->mbytes, &mbochs_avail_mbytes);
Arg, yes, thanks Dan - I thought I got all of these.
Jason
On Wed, Jul 28, 2021 at 07:56:40AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 27, 2021 at 01:58:16PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memcpy(), memmove(), and memset(), avoid
> > intentionally writin
On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> On Thu, 29 Jul 2021 11:03:36 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > > On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > > > On Wed, Jul 28, 2021 at 08:34:13AM -0700,
fix typo for vhost
Signed-off-by: Cai Huoqing
---
drivers/vhost/scsi.c | 4 ++--
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vringh.c | 18 +-
drivers/vhost/vsock.c | 6 +++---
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/
fix typo for drm
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/drm_aperture.c | 2 +-
drivers/gpu/drm/drm_atomic.c| 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
drivers/gpu/drm/drm_auth.c
On 29/07/2021 13:07, Daniel Vetter wrote:
On Thu, Jul 29, 2021 at 1:19 PM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressio
Am 29.07.21 um 13:59 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 12:21 PM Christian König
wrote:
Am 29.07.21 um 11:03 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Chris
On Thu, Jul 29, 2021 at 2:21 PM Tvrtko Ursulin
wrote:
> On 29/07/2021 13:07, Daniel Vetter wrote:
> > On Thu, Jul 29, 2021 at 1:19 PM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Usage of Transparent Hugepages was disabled in 9987da4b5dcf
> >> ("drm/i915: Disable THP until
On Thu, Jul 29, 2021 at 2:25 PM Christian König
wrote:
>
> Am 29.07.21 um 13:59 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 12:21 PM Christian König
> > wrote:
> >> Am 29.07.21 um 11:03 schrieb Daniel Vetter:
> >>> On Thu, Jul 29, 2021 at 10:38 AM Christian König
> >>> wrote:
> Am 29
Hi,
Quoting Ivan T. Ivanov (2021-07-29 09:46:23)
> Quoting Maxime Ripard (2021-07-28 14:54:19)
> > Hi,
> >
> > On Fri, Jul 23, 2021 at 09:24:14AM +0200, Ivan T. Ivanov wrote:
> > > Without prefix debugfs can't properly create component
> > > debug information tree when driver register more than
>
On Thu, 29 Jul 2021 13:43:20 +0200
Christian König wrote:
> Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
> > On Thu, 29 Jul 2021 12:14:18 +0200
> > Christian König wrote:
> >
> >> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >>> If the app happens to be frozen (e.g. some weird bug in fence
On Thu, 29 Jul 2021 14:18:29 +0200
Daniel Vetter wrote:
> On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> > On Thu, 29 Jul 2021 11:03:36 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > > > On 2021-07-29 9:09 a.m.,
Hey Jagan,
On Sun, 4 Jul 2021 at 11:04, Jagan Teki wrote:
>
> Now the exynos dsi driver is fully aware of bridge
> handling, so get the display mode from bridge, mode_set
> API instead of legacy encoder crtc.
>
> This makes bridge usage more efficient instead of relying
> on encoder stack.
>
> Ad
https://bugzilla.kernel.org/show_bug.cgi?id=210263
Jonas Platte (jplatte+li...@posteo.de) changed:
What|Removed |Added
CC||jplatte+li...@pos
From: Matthew Auld
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the fa
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do that.
To e
Am 29.07.21 um 14:49 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 13:43:20 +0200
Christian König wrote:
Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
If the app happens to be frozen (e.g
On Thu, Jul 29, 2021 at 3:00 PM Pekka Paalanen wrote:
> On Thu, 29 Jul 2021 14:18:29 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> > > On Thu, 29 Jul 2021 11:03:36 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, Jul 29, 2021 at 10:17:
On Thu, Jul 29, 2021 at 3:34 PM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Usage of Transparent Hugepages was disabled in 9987da4b5dcf
> ("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
> appears majority of performance regressions reported with an enabled IOMMU
> c
On Thu, 29 Jul 2021 15:41:09 +0200
Christian König wrote:
> Am 29.07.21 um 14:49 schrieb Pekka Paalanen:
> > On Thu, 29 Jul 2021 13:43:20 +0200
> > Christian König wrote:
> >
> >> Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
> >>> On Thu, 29 Jul 2021 12:14:18 +0200
> >>> Christian König wro
On 7/28/21 8:22 AM, Christoph Hellwig wrote:
> On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
>> Introduce an x86 version of the prot_guest_has() function. This will be
>> used in the more generic x86 code to replace vendor specific calls like
>> sev_active(), etc.
>>
>> Wh
On 29/7/21 3:00 pm, Daniel Vetter wrote:
On Tue, Jul 27, 2021 at 04:37:22PM +0200, Peter Zijlstra wrote:
On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
Inside drm_is_current_master, using the outer drm_devic
Add the missing scache_cntl0 register programing which is required for
a660 gpu.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/d
This patch adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x0603050
Use rev instead of revn to identify the SKU. This is in
preparation to the introduction of 7c3 gpu which won't have a
revn.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --gi
Hello Thomas Hellstrom,
The patch fb80edb0d766: "drm/vmwgfx: Implement an infrastructure for
read-coherent resources" from Mar 28, 2019, leads to the following
static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c:461 vmw_bo_vm_fault()
warn: missing conversion: 'page_
On Thu, Jul 29, 2021 at 10:32:13PM +0800, Desmond Cheong Zhi Xi wrote:
> Sounds good, will do. Thanks for the patch, Peter.
>
> Just going to make a small edit:
> s/LOCK_STAT_NOT_HELD/LOCK_STATE_NOT_HELD/
Bah, I knew I should've compile tested it :-), Thanks!
Huh... Vmware is blocking email to Thomas?
"Recipient is not authorized to accept external mail"
This seems like potentially a serious bug and I don't know how to report
it.
regards,
dan carpenter
On Thu, Jul 29, 2021 at 05:39:45PM +0300, Dan Carpenter wrote:
> Hello Thomas Hellstrom,
>
> The
On 7/29/2021 4:10 AM, Rodrigo Vivi wrote:
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed
On Thu, Jul 29, 2021 at 12:03 AM Daniel Vetter wrote:
>
> On Wed, Jul 28, 2021 at 10:58:51AM -0700, Rob Clark wrote:
> > On Wed, Jul 28, 2021 at 10:23 AM Christian König
> > wrote:
> > >
> > >
> > >
> > > Am 28.07.21 um 17:15 schrieb Rob Clark:
> > > > On Wed, Jul 28, 2021 at 4:37 AM Christian Kö
This series adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x060305
Use rev instead of revn to identify the SKU. This is in
preparation to the introduction of 7c3 gpu which won't have a
revn.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --gi
Add the missing scache_cntl0 register programing which is required for
a660 gpu.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/d
This patch adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x0603050
On Thu, Jul 29, 2021 at 7:33 AM Akhil P Oommen wrote:
>
> Use rev instead of revn to identify the SKU. This is in
> preparation to the introduction of 7c3 gpu which won't have a
> revn.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c |
Hi Alistair,
On Thu, Jul 29, 2021 at 08:33:58PM +1000, Alistair Francis wrote:
> Add support for the 10.3" E Ink panel described at:
> https://www.eink.com/product.html?type=productdetail&id=7
>
> Signed-off-by: Alistair Francis
> Acked-by: Rob Herring
> ---
> v4:
> - Fixup alphebetical sortin
On 28.07.2021 23:11, Vinay Belgaumkar wrote:
> Add macros to check for SLPC support. This feature is currently supported
> for Gen12+ and enabled whenever GuC submission is enabled/selected.
>
> Include templates for SLPC init/fini and enable.
>
> v2: Move SLPC helper functions to intel_guc_sl
1 - 100 of 238 matches
Mail list logo
