Hi,
First of all, thanks organizers for such a great conference. It was
smooth and, although there were some issues as it is usual in any
conference, they were fixed promptly :-)
I would like also to thank all of you for attending and participating
either via submitting talks, watching them or
Am 17.09.21 um 18:15 schrieb Alex Deucher:
Now that the scheduler is being used by more and more
drivers, we need someone to maintain it. Andrey has
stepped up to maintain the scheduler.
Cc: Andrey Grodzovsky
Cc: airl...@gmail.com
Cc: daniel.vet...@ffwll.ch
Signed-off-by: Alex Deucher
On Wed, Sep 15, 2021 at 1:47 AM Jani Nikula wrote:
>
> On Tue, 14 Sep 2021, Vasily Khoruzhick wrote:
> > On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula
> > wrote:
> >>
> >> On Tue, 14 Sep 2021, Lyude Paul wrote:
> >> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> >> >> On Mon, 13 Sep
On 18/09/2021 00:38, Matthew Brost wrote:
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915. Bisections converge convincingly, but arrive at different
and surprising "culprits", none of them the actual culprit.
It is certainly surprising
Am 17.09.21 um 16:43 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:34:52PM +0200, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 68
Am 17.09.21 um 16:55 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:35:08PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
On Fri, 17 Sep 2021, Lucas De Marchi wrote:
> On Mon, May 17, 2021 at 02:57:33PM +0300, Jani Nikula wrote:
>>On Mon, 12 Apr 2021, Matthew Auld wrote:
>>> From: Anshuman Gupta
>>>
>>> Sanitize OPROM header, CPD signature and OPROM PCI version.
>>> OPROM_HEADER, EXPANSION_ROM_HEADER and
On 17/09/2021 18:08, Matt Roper wrote:
From: Venkata Sandeep Dhanalakota
Support for multiple GT's within a single i915 device will be arriving
soon. Since each GT may have its own fusing and require different
workarounds, we need to make the GT workaround functions and multicast
steering
Hi
Am 17.09.21 um 16:47 schrieb Hans de Goede:
Hi,
On 9/16/21 8:15 PM, Thomas Zimmermann wrote:
Add devm_arch_phys_wc_add() and devm_arch_io_reserve_memtype_wc() for
automatic cleanup of writecombine setup.
Several DRM drivers use the non-managed functions for setting their
framebuffer
On 09/01, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 5 +
> 1 file changed, 1 insertion(+), 4
(cc'ing dri-devel)
Hi
Am 13.09.21 um 16:36 schrieb Alex Deucher:
On Thu, Sep 9, 2021 at 11:25 PM Evan Quan wrote:
With the shadow buffer support from generic framebuffer emulation, it's
possible now to have runpm kicked when no update for console.
Change-Id:
On 17/09/2021 14:23, Daniel Vetter wrote:
On Fri, Sep 17, 2021 at 02:34:48PM +0200, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed
Hi
Am 20.09.21 um 10:41 schrieb Thomas Zimmermann:
(cc'ing dri-devel)
Hi
Am 13.09.21 um 16:36 schrieb Alex Deucher:
On Thu, Sep 9, 2021 at 11:25 PM Evan Quan wrote:
With the shadow buffer support from generic framebuffer emulation, it's
possible now to have runpm kicked when no update for
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms, as a normal display port and as an
embedded display port.
Signed-off-by: Markus
Hi everyone,
this series is built around the DisplayPort driver. The dpi/dpintf driver and
the added helper functions are required for the DisplayPort driver to work.
For v2 I rebased the series on top of v5.15-rc1. There still is a functional
dependency on many different patches pulled in
DP_INTF is a similar functional block to mediatek,dpi but is different
in that it serves the DisplayPort controller on mediatek SoCs and uses
different clocks. Therefore this patch creates a new binding file for
this functional block.
Signed-off-by: Markus Schneider-Pargmann
---
Notes:
On Mon, 20 Sep 2021, "Gupta, Anshuman" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Monday, September 20, 2021 1:12 PM
>> To: De Marchi, Lucas
>> Cc: Auld, Matthew ; intel-...@lists.freedesktop.org;
>> dri-devel@lists.freedesktop.org; Gupta, Anshuman
>>
>> Subject: Re:
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
according phy driver mediatek-dp-phy.
It supports both functional units on the mt8195, the embedded
DisplayPort as well as the external DisplayPort units. It offers
hot-plug-detection, audio up to 8 channels, and DisplayPort
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
---
Notes:
Changes v1 -> v2:
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from
On 17/09/2021 13:35, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 32
1 file changed, 11 insertions(+), 21
On 17/09/2021 13:35, Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence instead, according to Tvrtko the lock is
held here anyway.
v3: back to using dma_resv_for_each_fence_unlocked.
It did not work out - what happened?
Regards,
Tvrtko
Signed-off-by:
On 20/09/2021 09:45, Tvrtko Ursulin wrote:
On 17/09/2021 13:35, Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence instead, according to Tvrtko the lock is
held here anyway.
v3: back to using dma_resv_for_each_fence_unlocked.
It did not work out - what
On Mon, 20 Sep 2021, Akira Yokosawa wrote:
> Nested grids in grid-table cells are not specified as proper ReST
> constructs.
> Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
> added a couple of kerneldoc tables of the form:
>
>
On Tuesday, 14 September 2021 2:16:01 AM AEST Alex Sierra wrote:
> In order to configure device public in test_hmm, two module parameters
> should be passed, which correspond to the SP start address of each
> device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
> private device
Hi,
On Sat, Sep 18, 2021 at 11:18:33AM +0200, Michael Stapelberg wrote:
> torvalds at linux-foundation.org (Linus Torvalds) writes:
> > Did I fix it up correctly? Who knows. The code makes more sense to me
> > now and seems valid. But I really *really* want to stress how locking
> > is important.
Nested grids in grid-table cells are not specified as proper ReST
constructs.
Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
added a couple of kerneldoc tables of the form:
+---+---+--+
| 1 | 31:0 |
Am 17.09.21 um 16:35 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:34:50PM +0200, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 86
https://bugzilla.kernel.org/show_bug.cgi?id=214413
--- Comment #2 from Marco Piazza (mpia...@gmail.com) ---
It is a regression, without apparent problems.
In fact the laptop start and is working as usual.
I've found a similar bug described here:
Am 17.09.21 um 16:53 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:35:07PM +0200, Christian König wrote:
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
This will be gone as soon as I can land the last conversion patches. Plus
it's
Am 18.09.21 um 11:41 schrieb Zhiwei Yang:
The bool variable detected_hpd_without_ddc in struct radeon_connector
is uninitialized when first used, that may cause unnecessary ddc ops.
Make it as false when a new connector is alloced.
Signed-off-by: Zhiwei Yang
---
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, September 20, 2021 1:12 PM
> To: De Marchi, Lucas
> Cc: Auld, Matthew ; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; Gupta, Anshuman
>
> Subject: Re: [Intel-gfx] [PATCH 14/19] drm/i915/oprom: Basic
Hi,
On 9/20/21 10:01 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 17.09.21 um 16:47 schrieb Hans de Goede:
>> Hi,
>>
>> On 9/16/21 8:15 PM, Thomas Zimmermann wrote:
>>> Add devm_arch_phys_wc_add() and devm_arch_io_reserve_memtype_wc() for
>>> automatic cleanup of writecombine setup.
>>>
>>> Several
Am 17.09.21 um 19:53 schrieb Zack Rusin:
On some hardware, in particular in virtualized environments, the
system memory can be shared with the "hardware". In those cases
the BO's allocated through the ttm system manager might be
busy during ttm_bo_put which results in them being scheduled
for a
On Mon, 20 Sep 2021, Tvrtko Ursulin wrote:
> On 18/09/2021 00:38, Matthew Brost wrote:
>> From: Hugh Dickins
>>
>> 5.15-rc1 crashes with blank screen when booting up on two ThinkPads
>> using i915. Bisections converge convincingly, but arrive at different
>> and surprising "culprits", none of
On 20/09/2021 08:38, Jani Nikula wrote:
On Mon, 20 Sep 2021, Tvrtko Ursulin wrote:
On 18/09/2021 00:38, Matthew Brost wrote:
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915. Bisections converge convincingly, but arrive at different
and
Am 17.09.21 um 20:09 schrieb Maxime Ripard:
By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge()
introduces a circular dependency between the modules drm (where
devm_drm_of_get_bridge() ends up) and drm_kms_helper (where
devm_drm_panel_bridge_add() is).
Fix this by moving
Hi
Am 17.09.21 um 09:22 schrieb KuoHsiang Chou:
1. Avoid IO-index racing
2. IO-index racing happened on resolustion switching
and mouse moving at the same time
3. System hung while IO-index racing occurred.
I'd say that there's something else going one here. Mode setting and
cursor
Hey Alex,
Thanks for submitting this.
Applied to drm-misc-next.
Hey Yunlongli,
Thanks for submitting this fix.
On Sat, 18 Sept 2021 at 05:51, Yunlongli wrote:
The formatting of this commit message is a bit unusual, let's try to
change it to the normal formatting.
Remove the dot from the commit title:
"drm: bridge: it66121: Added it66121 chip external
On 14/09/2021 20:31, Thomas Hellström wrote:
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and
https://bugzilla.kernel.org/show_bug.cgi?id=214413
--- Comment #3 from Marco Piazza (mpia...@gmail.com) ---
Created attachment 298885
--> https://bugzilla.kernel.org/attachment.cgi?id=298885=edit
Patch to revert ATPX/ATCS global structures
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=214413
--- Comment #4 from Marco Piazza (mpia...@gmail.com) ---
I confirm that using the above patch make the oops disappear.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the
On 14/09/2021 20:31, Thomas Hellström wrote:
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to
On 17/09/2021 13:35, Christian König wrote:
Simplifying the code a bit.
v2: add missing rcu read unlock.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 57 ++--
1 file changed, 14 insertions(+), 43 deletions(-)
diff --git
Am 20.09.21 um 10:43 schrieb Tvrtko Ursulin:
On 17/09/2021 14:23, Daniel Vetter wrote:
On Fri, Sep 17, 2021 at 02:34:48PM +0200, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns
This short sentence references nothing for details about memory manager.
Replace it with the documentation file for DRM memory management.
Cc: Jani Nikula
Signed-off-by: Markus Schneider-Pargmann
---
Documentation/gpu/drm-internals.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Am 20.09.21 um 10:45 schrieb Tvrtko Ursulin:
On 17/09/2021 13:35, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 32
Am 20.09.21 um 10:47 schrieb Tvrtko Ursulin:
On 20/09/2021 09:45, Tvrtko Ursulin wrote:
On 17/09/2021 13:35, Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence instead, according to Tvrtko the
lock is
held here anyway.
v3: back to using
On 20/09/2021 11:09, Christian König wrote:
Am 20.09.21 um 10:43 schrieb Tvrtko Ursulin:
On 17/09/2021 14:23, Daniel Vetter wrote:
On Fri, Sep 17, 2021 at 02:34:48PM +0200, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop
On 20/09/2021 11:13, Christian König wrote:
Am 20.09.21 um 10:45 schrieb Tvrtko Ursulin:
On 17/09/2021 13:35, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
On Mon, Sep 20, 2021 at 02:19:18PM +0200, Cornelia Huck wrote:
> On Thu, Sep 09 2021, Jason Gunthorpe wrote:
>
> > The subchannel should be left in a quiescent state unless the VFIO device
> > FD is opened. When the FD is opened bring the chanel to active and allow
> > the VFIO device to
https://bugzilla.kernel.org/show_bug.cgi?id=214413
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Fri, Sep 17, 2021 at 10:08:45AM -0700, Matt Roper wrote:
> From: Venkata Sandeep Dhanalakota
>
> Support for multiple GT's within a single i915 device will be arriving
> soon. Since each GT may have its own fusing and require different
> workarounds, we need to make the GT workaround
On Mon, Sep 20, 2021 at 05:43:33PM +0200, Maxime Ripard wrote:
> On Mon, Sep 20, 2021 at 04:47:31PM +0200, Maxime Ripard wrote:
> > On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote:
> > > Hi Maxime,
> > >
> > > On Sat, Sep 4, 2021 at 10:10 AM Maxime Ripard wrote:
> > > >
> > > >
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #61 from James Zhu (jam...@amd.com) ---
(In reply to youling257 from comment #60)
> Created attachment 298889 [details]
> dmesg5.15.txt
>
> (In reply to James Zhu from comment #59)
> > (In reply to youling257 from comment #58)
> > >
On Mon, Sep 20, 2021 at 08:26:03AM -0700, Zachary Mayhew wrote:
> Subject: [PATCH] staging: fbtft: add docs for fbtft_write_spi()
Odd, this shouldn't be in the body of the email :(
>
> This patch adds documentation for fbtft_write_spi() to make its
> calling context clear and explain what it
On Mon, Sep 20, 2021 at 8:16 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Using an empty macro expansion as a conditional expression
> produces a W=1 warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c: In function
> 'dce_aux_transfer_with_retries':
>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
On Sun, Sep 19, 2021 at 10:19:35AM -0700, Linus Torvalds wrote:
> On Sun, Sep 19, 2021 at 4:05 AM Sudip Mukherjee
> wrote:
> >
> > And indeed, reverting 27da370e0fb3 ("drm/vc4: hdmi: Remove
> > drm_encoder->crtc usage") on top of d4d016caa4b8 ("alpha: move
> > __udiv_qrnnd library function to
From: Arnd Bergmann
The empty unmap_page_from_agp() macro causes a warning when
building with 'make W=1' on a couple of architectures:
drivers/char/agp/generic.c: In function 'agp_generic_destroy_page':
drivers/char/agp/generic.c:1265:28: error: suggest braces around empty body in
an 'if'
On Mon, Sep 20, 2021 at 10:55:31AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Sat, Sep 18, 2021 at 11:18:33AM +0200, Michael Stapelberg wrote:
> > torvalds at linux-foundation.org (Linus Torvalds) writes:
> > > Did I fix it up correctly? Who knows. The code makes more sense to me
> > > now and
Hi Jani,
On Mon, Sep 20, 2021 at 02:01:57PM +0300, Jani Nikula wrote:
> On Mon, 20 Sep 2021, Markus Schneider-Pargmann wrote:
> > This short sentence references nothing for details about memory manager.
> > Replace it with the documentation file for DRM memory management.
> >
> > Cc: Jani Nikula
Replace most references to struct drm_device.dev_private with the new
helper function to_drm_psb_private(). The only references left are in
assignments and the helper itself.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/backlight.c | 12 -
Embed struct drm_device in struct drm_psb_private. Replace the use
of dev_private by an upcast operation. Switch to managed release of
struct drm_psb_private.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_device.c | 2 +-
drivers/gpu/drm/gma500/intel_bios.c | 6 +++---
The value of dev_priv in psb_driver_unload() is always non-zero. Remove
the respective test.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.c | 93
1 file changed, 46 insertions(+), 47 deletions(-)
diff --git
Use managed disablement of PCI devices via pcim_device_enable().
Disables the PCI device and simplifies error rollback in probe
function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
Set up a clean-up action to automatically release device resources
during driver shutdown. Remove manual release code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git
Switch gma500 to managed cleanup and remove the manual cleanup
code from the driver's PCI callbacks.
Managed cleanup involves embedding the DRM device structure in the
driver's structure. In preparation, patch 1 replaces references all
references to dev_private with a helper function.
Patch 2
Quoting Peter Zijlstra (2021-09-17 16:13:19)
> On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
> >
> > > > For merge logistics, can we pls have a stable branch? I expect that the
> > > > i915 patches will be
Hi Gurchetan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.15-rc2 next-20210920]
[cannot apply to airlied/drm-next
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
v3:
- Slight
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object
https://bugzilla.kernel.org/show_bug.cgi?id=211277
youling...@gmail.com changed:
What|Removed |Added
CC||youling...@gmail.com
--- Comment
On 14/09/2021 20:31, Thomas Hellström wrote:
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using
On Mon, 2021-09-20 at 11:49 +0100, Matthew Auld wrote:
> On 14/09/2021 20:31, Thomas Hellström wrote:
> > Just evict unpinned objects to system. For pinned LMEM objects,
> > make a backup system object and blit the contents to that.
> >
> > Backup is performed in three steps,
> > 1:
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #60 from youling...@gmail.com ---
Created attachment 298889
--> https://bugzilla.kernel.org/attachment.cgi?id=298889=edit
dmesg5.15.txt
(In reply to James Zhu from comment #59)
> (In reply to youling257 from comment #58)
> >
On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote:
> Hi Maxime,
>
> On Sat, Sep 4, 2021 at 10:10 AM Maxime Ripard wrote:
> >
> > On Fri, Sep 03, 2021 at 09:09:50PM +0100, Sudip Mukherjee wrote:
> > > Hi Maxime,
> > >
> > > On Fri, Sep 3, 2021 at 5:03 PM Maxime Ripard wrote:
> > >
> On Sep 20, 2021, at 02:30, Christian König wrote:
>
> Am 17.09.21 um 19:53 schrieb Zack Rusin:
>> On some hardware, in particular in virtualized environments, the
>> system memory can be shared with the "hardware". In those cases
>> the BO's allocated through the ttm system manager might be
On Fri, Sep 17, 2021 at 09:54:21PM -0700, Alan Previn wrote:
> This series adds gem_pxp tests for the new PXP subsystem currently
> being reviewed at https://patchwork.freedesktop.org/series/90504/.
> This series currently includes 4 groups of tests addressing the
> features and restrictions
On Mon, Sep 20, 2021 at 02:17:19PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The empty unmap_page_from_agp() macro causes a warning when
> building with 'make W=1' on a couple of architectures:
>
> drivers/char/agp/generic.c: In function 'agp_generic_destroy_page':
>
On Mon, 20 Sep 2021, Markus Schneider-Pargmann wrote:
> This short sentence references nothing for details about memory manager.
> Replace it with the documentation file for DRM memory management.
>
> Cc: Jani Nikula
> Signed-off-by: Markus Schneider-Pargmann
> ---
>
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> The subchannel should be left in a quiescent state unless the VFIO device
> FD is opened. When the FD is opened bring the chanel to active and allow
> the VFIO device to operate. When the device FD is closed then quiesce the
> channel.
>
> To make
On Mon, Sep 20, 2021 at 09:07:13AM -0700, Zachary Mayhew wrote:
> On Mon, Sep 20, 2021 at 05:38:30PM +0200, Greg KH wrote:
> > On Mon, Sep 20, 2021 at 08:26:03AM -0700, Zachary Mayhew wrote:
> > > Subject: [PATCH] staging: fbtft: add docs for fbtft_write_spi()
> >
> > Odd, this shouldn't be in
On 14/09/2021 20:31, Thomas Hellström wrote:
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict
OK??I will modify the message. Thanks a lot.
------
??: Robert Foss
Reviewed-by: Alyssa Rosenzweig
> index bd9b7be63b0f..fd4309209088 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -400,8 +400,7 @@ void panfrost_device_reset(struct panfrost_device *pfdev)
> #ifdef CONFIG_PM
> int
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> mdev_device should only be used in functions assigned to ops callbacks,
> interior functions should use the struct vfio_ccw_private instead of
> repeatedly trying to get it from the mdev.
>
> Signed-off-by: Jason Gunthorpe
> ---
>
On 20/09/2021 10:05, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
Reviewed-by: Steven Price
I'll push this to drm-misc-next.
Thanks,
Steve
>
> Build
On 18/09/2021 10:13, Jiapeng Chong wrote:
> This symbol is not used outside of panfrost_drv.c, so marks it static.
>
> Fix the following sparse warning:
>
> drivers/gpu/drm/panfrost/panfrost_drv.c:641:12: warning: symbol
> 'mediatek_mt8183_supplies' was not declared. Should it be static?
>
>
On Mon, Sep 20, 2021 at 04:47:31PM +0200, Maxime Ripard wrote:
> On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote:
> > Hi Maxime,
> >
> > On Sat, Sep 4, 2021 at 10:10 AM Maxime Ripard wrote:
> > >
> > > On Fri, Sep 03, 2021 at 09:09:50PM +0100, Sudip Mukherjee wrote:
> > > > Hi
Anyone up for a review on this one? Daniel Vetter has ack'ed but
doesn't have time for a full review.
CC Maarten Lankhorst, Maxime Ripard, Michel Dänzer
Who else should I CC?
1 - 100 of 205 matches
Mail list logo
