Den 22.07.2021 04.07, skrev Dillon Min:
> Hi Noralf
>
> Thanks for your time to review my patch.
>
> On Thu, 22 Jul 2021 at 01:42, Noralf Trønnes wrote:
>>
>>
>>
>> Den 21.07.2021 09.41, skrev dillon.min...@gmail.com:
>>> From: Dillon Min
>>>
>>> This driver combine tiny/ili9341.c mipi_dbi_i
Hi Noralf,
On Thu, 22 Jul 2021 at 15:03, Noralf Trønnes wrote:
>
>
>
> Den 22.07.2021 04.07, skrev Dillon Min:
> > Hi Noralf
> >
> > Thanks for your time to review my patch.
> >
> > On Thu, 22 Jul 2021 at 01:42, Noralf Trønnes wrote:
> >>
> >>
> >>
> >> Den 21.07.2021 09.41, skrev dillon.min...@
On Thu, Jul 22, 2021 at 08:22:40AM +0200, Sam Ravnborg wrote:
> The atomic variants of enable/disable in drm_bridge_funcs are the
> preferred operations - introduce these.
>
> The ps8640 driver used the non-atomic variants of the drm_bridge chain
> functions - convert these to the atomic variants.
On Thu, Jul 22, 2021 at 08:22:41AM +0200, Sam Ravnborg wrote:
> The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
> users left and we have atomic variants that should be used.
> Drop them so they do not gain new users.
>
> Adjust a few comments to avoid references to the dropped
https://bugzilla.kernel.org/show_bug.cgi?id=213053
heubor...@gmx.de changed:
What|Removed |Added
CC||heubor...@gmx.de
--- Comment #4 from h
Hi,
On Thu, Jul 22, 2021 at 08:22:42AM +0200, Sam Ravnborg wrote:
> drm_bridge_new_crtc_state() will be used by bridge drivers to provide
> easy access to the mode from the drm_bridge_funcs operations.
>
> The helper will be useful in the atomic operations of
> struct drm_bridge_funcs.
>
> Signe
On Thu, Jul 22, 2021 at 08:22:44AM +0200, Sam Ravnborg wrote:
> The mode_valid implementation had a call to
> drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
> not allowed to change anything - only to validate the mode.
>
> As the next bridge is often/always a connector the
On Thu, Jul 22, 2021 at 08:22:45AM +0200, Sam Ravnborg wrote:
> There are no users left and we do not want to have this function
> available.
>
> drm_atomic_bridge_check() is used to call the mode_fixup() operation for
> the chained bridges and there is no need for drm_atomic_bridge_check().
> Dro
On Wed, 21 Jul 2021 06:49:32 +
Simon Ser wrote:
> It's not obvious what the fields mean and how they should be used.
> The most important detail is the link to drm_property.flags, which
> describes how property types work.
>
> Signed-off-by: Simon Ser
> Cc: Pekka Paalanen
> Cc: Daniel Vett
On Thu, Jul 22, 2021 at 08:22:46AM +0200, Sam Ravnborg wrote:
> - deprecated callbacks in drm_bridge_funcs
> - move connector creation to display drivers
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airl
On Wed, 21 Jul 2021 13:43:05 +0200
Daniel Vetter wrote:
> On Wed, Jul 21, 2021 at 06:51:30AM +, Simon Ser wrote:
> > When a property has the type DRM_MODE_PROP_BITMASK, the value field
> > stores a bitshift, not a bitmask, which can be surprising.
> >
> > Signed-off-by: Simon Ser
> > Cc: Pe
Hi,
On Thu, Jul 22, 2021 at 08:22:43AM +0200, Sam Ravnborg wrote:
> The atomic variants of enable/disable in drm_bridge_funcs are the
> preferred operations - introduce these.
>
> Use of mode_set is deprecated - merge the functionality with
> atomic_enable()
>
> Signed-off-by: Sam Ravnborg
> Cc
On Wed, 21 Jul 2021 13:55:07 -0400
Sean Paul wrote:
> From: Sean Paul
>
> Hi all,
> I just had the pleasure of rebasing this set on our CrOS downstream
> kernel and wanted to resend it for consideration once again. There
> hasn't been any resistence to the set AFAIK, just perhaps not enough
> m
Hi Maxime,
On Tue, Jul 20, 2021 at 7:15 PM Maxime Ripard wrote:
>
> Display drivers so far need to have a lot of boilerplate to first
> retrieve either the panel or bridge that they are connected to using
> drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
> functions or c
Hi Maxime,
On Tue, Jul 20, 2021 at 7:15 PM Maxime Ripard wrote:
>
> In order to make the probe order expectation more consistent between
> bridges, let's create attach and detach hooks for the panels as well to
> match what is there for bridges.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/
On 22.07.2021 01:51, Daniele Ceraolo Spurio wrote:
>
>
> On 7/19/2021 9:04 PM, Matthew Brost wrote:
>> On Mon, Jul 19, 2021 at 05:51:46PM -0700, Daniele Ceraolo Spurio wrote:
>>>
>>> On 7/16/2021 1:16 PM, Matthew Brost wrote:
Implement GuC context operations which includes GuC specific op
Hi Dillon,
On Thu, Jul 22, 2021 at 4:38 AM Dillon Min wrote:
>
> Hi Jagan
>
> Thanks for your time to review my code.
>
> On Wed, 21 Jul 2021 at 23:48, Jagan Teki wrote:
> >
> > On Wed, Jul 21, 2021 at 1:11 PM wrote:
> > >
> > > From: Dillon Min
> > >
> > > This driver combine tiny/ili9341.c m
On 16/07/2021 21:17, Matthew Brost wrote:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Hm "slightly" ends up 5x longer here and one second feels a lot.
Out of curiosity, given this is about a simple submit of a no-op batches
in a tight
On 16/07/2021 21:17, Matthew Brost wrote:
From: John Harrison
Some testing environments and some heavier tests are slower than
What testing environments are they? It's not a simulation patch which
"escaped" by accident I am wondering. If not then it's just GuC which is
so slow, like that
On 21/07/2021 19:44, Lucas De Marchi wrote:
On Wed, Jul 21, 2021 at 10:25:59AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 00:20, Lucas De Marchi wrote:
This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
recent platforms do not depend on this field, so it doesn't make muc
Am 21.07.21 um 21:03 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 09:34:43AM -0700, Rob Clark wrote:
On Wed, Jul 21, 2021 at 12:59 AM Daniel Vetter wrote:
On Wed, Jul 21, 2021 at 12:32 AM Rob Clark wrote:
On Tue, Jul 20, 2021 at 1:55 PM Daniel Vetter wrote:
On Tue, Jul 20, 2021 at 8:26 P
On Wed, 21 Jul 2021 at 21:28, Jason Ekstrand wrote:
>
> On Thu, Jul 15, 2021 at 5:16 AM Matthew Auld wrote:
> >
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> >
Turned out that doing this in vmw_ttm_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_b
Turned out that doing this in amdgpu_ttm_backend_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm
Turned out that doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy()
is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ++-
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
Turned out that doing this in radeon_ttm_tt_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a06d4
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Instead change the drivers to unbind their page tables during unpopulate and
merge those things back into ttm_tt_destroy() again.
This reverts commit 762
On Thu, Jul 22, 2021 at 10:42:26AM +0200, Christian König wrote:
> Am 21.07.21 um 21:03 schrieb Daniel Vetter:
> > On Wed, Jul 21, 2021 at 09:34:43AM -0700, Rob Clark wrote:
> > > On Wed, Jul 21, 2021 at 12:59 AM Daniel Vetter wrote:
> > > > On Wed, Jul 21, 2021 at 12:32 AM Rob Clark wrote:
> > >
On Thu, Jul 22, 2021 at 10:55:54AM +0200, Christian König wrote:
> It turned out that this is not a good idea at all because it leaves pointers
> to freed up system memory pages in the GART tables of the drivers.
>
> Instead change the drivers to unbind their page tables during unpopulate and
> me
On Wed, Jul 21, 2021 at 10:24:01PM +0200, Daniel Vetter wrote:
> On Wed, Jul 21, 2021 at 10:17 PM Jason Ekstrand wrote:
> >
> > On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter
> > wrote:
> > >
> > > This essentially reverts
> > >
> > > commit 84a1074920523430f9dc30ff907f4801b4820072
> > > Author:
Am 22.07.21 um 11:11 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 10:55:54AM +0200, Christian König wrote:
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Instead change the drivers to unbind their
Add mt8195 SoC DRM binding
1. Due to the 2 display hardware path in mt8195 SoC, we need to add vdosys0
and vdosys1 into mmsys binding document.
2. DSC and MERGE is used in vdosys0, so we need to add DSC binding file
and additional MERGE description into original disp binding document.
jason-
Change mediatek,dislpay.txt to mediatek,display.yaml
Signed-off-by: jason-jh.lin
---
.../display/mediatek/mediatek,disp.txt| 219 -
.../display/mediatek/mediatek,disp.yaml | 432 ++
2 files changed, 432 insertions(+), 219 deletions(-)
delete mode 100644
Do
Add mt8195 SoC display binding.
Signed-off-by: jason-jh.lin
---
.../display/mediatek/mediatek,disp.yaml | 24 +--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
b/Documentation/devicetre
1. clock drivers of MERGE
The MERGE controller may have 2 clock inputs.
The second clock of MERGE is async clock which is controlling
the async buffer between MERGE and other display function blocks.
2. MERGE fifo settings enable
The setting of merge fifo is mainly provided for the dis
There are 2 display hardware path in mt8195, namely vdosys0 and
vdosys1, so add their definition in mtk-mmsys documentation.
Signed-off-by: jason-jh.lin
---
this patch is base on [1][2]
[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format
-
https://patchwork.kernel.org/project/linux-me
1. Add mediatek,dsc.yaml to decribe DSC module in details.
2. Add mt8195 SoC binding to mediatek,dsc.yaml.
Signed-off-by: jason-jh.lin
---
.../display/mediatek/mediatek,dsc.yaml| 73 +++
1 file changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindin
Am 22.07.21 um 11:08 schrieb Daniel Vetter:
[SNIP]
As far as I know wake_up_state() tries to run the thread on the CPU it was
scheduled last, while wait_event_* makes the thread run on the CPU who
issues the wake by default.
And yes I've also noticed this already and it was one of the reason wh
Hi,
This series contains some improvements that Daniel Vetter proposed following a
discussion on a recent series:
https://lore.kernel.org/lkml/20210712043508.11584-1-desmondcheon...@gmail.com/
While preparing these patches, I also noticed some unprotected uses of
drm_master in the vmwgfx driver
Inside drm_is_current_master, using the outer drm_device.master_mutex
to protect reads of drm_file.master makes the function prone to creating
lock hierarchy inversions. Instead, we can use the
drm_file.master_lookup_lock that sits at the bottom of the lock
hierarchy.
Reported-by: Daniel Vetter
S
In particular, we make it clear that &drm_device.mode_config.idr_mutex
protects the lease idr and list structures for drm_master. The lessor
field itself doesn't need to be protected as it doesn't change after
it's set in drm_lease_create.
Additionally, we add descriptions for the lifetime of less
drm_file.master should be protected by either drm_device.master_mutex
or drm_file.master_lookup_lock when being dereferenced. However,
drm_master_get is called on unprotected file_priv->master pointers in
vmw_surface_define_ioctl and vmw_gb_surface_define_internal.
This is fixed by replacing drm_m
On Tue, Jul 20, 2021 at 07:19:40PM +0200, Sam Ravnborg wrote:
> Hi Maxime,
> On Tue, Jul 20, 2021 at 03:45:23PM +0200, Maxime Ripard wrote:
> > The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
> > already free'd on release.
> >
> > Fixes: 2f733d6194bd ("drm/panel: Add support fo
On 21/7/21 9:23 pm, Daniel Vetter wrote:
On Wed, Jul 21, 2021 at 2:44 PM Desmond Cheong Zhi Xi
wrote:
On 21/7/21 6:29 pm, Daniel Vetter wrote:
On Wed, Jul 21, 2021 at 6:12 AM Desmond Cheong Zhi Xi
wrote:
On 21/7/21 2:24 am, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 12:35:03PM +0800, Desm
On Wed, Jul 21, 2021 at 04:16:13PM +0200, Sam Ravnborg wrote:
> On Wed, Jul 21, 2021 at 04:03:41PM +0200, Maxime Ripard wrote:
> > The corpro,gm7123 was in use in a DT but was never properly documented,
> > let's add it.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Reviewed-by: Laurent Pinchart
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 83 --
drivers/soc/mediatek/mtk-mmsys.c | 10
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files ch
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
b/include/dt-bindings/reset/mt8195-resets.h
index 7ec27a64afc7..e
1. Add ethdr definition file for mt8195 display.
2. Add mediatek,ethdr.yaml to decribe ethdr module in details.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,disp.yaml | 8 +
.../display/mediatek/mediatek,ethdr.yaml | 144 ++
2 files changed, 152 inserti
Add driver data of mt8195 vdosys1 to mediatek-drm and modify drm for
multi-mmsys support. The two mmsys (vdosys0 and vdosys1) will bring
up two drm drivers, only one drm driver register as the drm device.
Each drm driver binds its own component. The first bind drm driver
will allocate the drm devic
Add vdosys1 RDMA and MERGE definition.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,disp.yaml | 30 +++
1 file changed, 30 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
b/Documentation/devicetree/bindings/d
Add ETHDR module files:
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combines
different layers, output the required HDR or SDR signal to the
subseque
MT8195 support two display system: vdosys0 and vdosys1.
The two mmsys will bring up two drm drivers, only one drm
driver register as the drm device. Use the new mtk_mmsys struct
member for the two mmsys synchronization.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mmsys.c | 1 +
1 file
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 217 +++
1 file changed, 217 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index aa2a7849b822..b2e377515a52
Among other features the mmsys driver should implement a reset
controller to be able to reset different bits from their space.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 77 +
drivers/soc/mediatek/mtk
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains pseudo_ovl, ethdr, merge5,
and dp_intf1. Pseudo_ovl and ethdr components are both composed
of several sub-elements, so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex
Add mmsys config API.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 38
drivers/soc/mediatek/mtk-mmsys.c | 50 ++
drivers/soc/mediatek/mtk-mmsys.h | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 18 ++
The mmsys system controller exposes a set of memory client resets and
needs to specify the #reset-cells property in order to advertise the
number of cells needed to describe each of the resets.
Signed-off-by: Nancy.Lin
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 3 +++
1
The DT binding includes for reset controllers are located in
include/dt-bindings/reset/. Move the Mediatek reset constants in there.
Signed-off-by: Nancy.Lin
---
include/dt-bindings/{reset-controller => reset}/mt8195-resets.h | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename include/d
Add pseudo ovl module files:
Pseudo ovl is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/Makefi
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, PSEUDO_OVL and MERGE.
Add DRM and these modules support by the patches below:
Change in v2:
- Merge PSEUDO_OVL and ETHDR into one DRM component.
- Add mmsys config API for vdosys1 hardware setting.
- Ad
On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
>
> On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
> > > wrote:
> > > >
> > > > On Fri, 16 Jul 2021 at 18:39, Jason Eks
On Thu, 22 Jul 2021 at 10:49, Matthew Auld
wrote:
>
> On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
> >
> > On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
> > > >
> > > > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
On 21/07/2021 19:32, Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vmscan.c:do_shrink_slab() is a thing, if there's an issue w
On Wed, Jul 21, 2021 at 10:23:56AM -0500, Jason Ekstrand wrote:
> If we have a failure, decrement the reference count so that the next
> call to ttm_global_init() will actually do something instead of assume
> everything is all set up.
>
> Signed-off-by: Jason Ekstrand
> Fixes: 62b53b37e4b1 ("drm
On 2021.07.21 17:53:34 +0200, Christoph Hellwig wrote:
> Hi all,
>
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls. This series refactors various
> bits to clean that up. The main user visible change is that almost all
> of the GVT
On Wed, Jul 21, 2021 at 03:15:09PM -0500, Jason Ekstrand wrote:
> On Wed, Jul 21, 2021 at 1:56 PM Daniel Vetter wrote:
> >
> > On Wed, Jul 21, 2021 at 05:25:41PM +0100, Matthew Auld wrote:
> > > On 21/07/2021 16:23, Jason Ekstrand wrote:
> > > > There's no reason that I can tell why this should be
On Wed, Jul 21, 2021 at 10:23:57AM -0500, Jason Ekstrand wrote:
> We create a bunch of debugfs entries as a side-effect of
> ttm_global_init() and then never clean them up. This isn't usually a
> problem because we free the whole debugfs directory on module unload.
> However, if the global referen
On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
> On 21/07/2021 19:32, Daniel Vetter wrote:
> > This essentially reverts
> >
> > commit 84a1074920523430f9dc30ff907f4801b4820072
> > Author: Chris Wilson
> > Date: Wed Jan 24 11:36:08 2018 +
> >
> > drm/i915: Shrink the G
On 22/07/2021 11:16, Daniel Vetter wrote:
On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 19:32, Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm
On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote:
> In particular, we make it clear that &drm_device.mode_config.idr_mutex
> protects the lease idr and list structures for drm_master. The lessor
> field itself doesn't need to be protected as it doesn't change after
> it's set i
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 reads of drm_file.master makes the function prone to creating
> lock hierarchy inversions. Instead, we can use the
> drm_file.master_lookup_loc
On Thu, Jul 22, 2021 at 05:29:29PM +0800, Desmond Cheong Zhi Xi wrote:
> drm_file.master should be protected by either drm_device.master_mutex
> or drm_file.master_lookup_lock when being dereferenced. However,
> drm_master_get is called on unprotected file_priv->master pointers in
> vmw_surface_def
drm-misc-next-2021-07-22:
drm-misc-next for v5.15-rc1:
UAPI Changes:
- Remove sysfs stats for dma-buf attachments, as it causes a performance
regression.
Previous merge is not in a rc kernel yet, so no userspace regression possible.
Cross-subsystem Changes:
- Sanitize user input in kyro's view
On Thu, Jul 22, 2021 at 11:28:01AM +0200, Christian König wrote:
> Am 22.07.21 um 11:08 schrieb Daniel Vetter:
> > [SNIP]
> > > As far as I know wake_up_state() tries to run the thread on the CPU it was
> > > scheduled last, while wait_event_* makes the thread run on the CPU who
> > > issues the wa
Hi Christoph:
Thanks so much for the patches and the testing.
The abstraction between i915 and KVMGT module is for our customers who can
easily port GVT-g into their own hypervisors. As you can see, all the
hypervisor related functions were put in "hypervisor" module. The GVT-g module
talks wi
Hi,
> https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i915/gvt/xengt.c
> But it's hard for some customers to contribute their own "hypervisor"
> module to the upstream Linux kernel. I am thinking what would be a
> better solution here? The MPT layer in the kernel helps a
On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote:
> On 7/21/21 6:12 PM, Daniel Thompson wrote:
> > On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote:
> > > On 7/21/21 12:49 PM, Daniel Thompson wrote:
> > > > > I'm not sure that's correct, we can simply say that any new uses of
Am 22.07.21 um 12:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 11:28:01AM +0200, Christian König wrote:
Am 22.07.21 um 11:08 schrieb Daniel Vetter:
[SNIP]
As far as I know wake_up_state() tries to run the thread on the CPU it was
scheduled last, while wait_event_* makes the thread run on
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
v2: Add a comment explaining why we need sync_shrinkers().
v3: Drop sync_shrinkers() and use an SRCU instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 45
Den 16.07.2021 16.07, skrev Thomas Zimmermann:
> Provide helpers that wrap dma_buf_{begin,end}_cpu_access() for all
> GEM BOs attached to a framebuffer. Convert drivers and remove ugly
> boilerplate code.
>
Nice, for the series:
Reviewed-by: Noralf Trønnes
> Thomas Zimmermann (7):
> drm/
Try to document the object caching related bits, like cache_coherent and
cache_dirty.
v2(Ville):
- As pointed out by Ville, fix the completely incorrect assumptions
about the "partial" coherency on shared LLC platforms.
v3(Daniel):
- Fix nonsense about "dirtying" the cache with reads.
Sugges
EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
possible for userspace to bypass the GTT caching bits set by the kernel,
as per the given object cache_level. This is troublesome since the heavy
flush we apply when first acquiring the pages is skipped if the kernel
thinks the objec
Den 15.07.2021 20.01, skrev Thomas Zimmermann:
> Abstract the framebuffer details by mapping its BOs with a call
> to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunmap().
>
> The call to drm_gem_fb_vmap() ensures that all BOs are mapped
> correctly. Gud still only supports single-plane formats.
>
Hi Dave and Daniel,
here's the PR for drm-misc-fixes. There's a UAPI change where -ENOTTY is
now being returned for non-DRM ioctls.
Best regards
Thomas
drm-misc-fixes-2021-07-22:
Short summary of fixes pull:
* Return -ENOTTY for non-DRM ioctls
* amdgpu: Fix COW checks
* nouveau: init BO GME
On Thu, Jul 22, 2021 at 12:34:55PM +0100, Matthew Auld wrote:
> Try to document the object caching related bits, like cache_coherent and
> cache_dirty.
>
> v2(Ville):
> - As pointed out by Ville, fix the completely incorrect assumptions
>about the "partial" coherency on shared LLC platforms.
On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
> In order to configure device generic in test_hmm, two
> module parameters should be passed, which correspon to the
> SP start address of each device (2) spm_addr_dev0 &
> spm_addr_dev1. If no parameters are passed, private device
> type
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file changed
Doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c|
Doing this in radeon_ttm_tt_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++---
1 file changed, 2 i
Doing this in amdgpu_ttm_backend_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file chang
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Instead change the drivers to unbind their page tables during unpopulate and
merge those things back into ttm_tt_destroy() again.
This reverts commit 762
On 16/07/2021 21:16, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class wh
On Sun, Jul 18, 2021 at 02:09:12PM +0300, Leon Romanovsky wrote:
> @@ -386,12 +414,14 @@ static struct scatterlist *get_next_sg(struct sg_table
> *table,
> return ERR_PTR(-ENOMEM);
> sg_init_table(new_sg, alloc_size);
> if (cur) {
> + if (total_nents)
> +
On 22/7/21 6:35 pm, Daniel Vetter wrote:
On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote:
In particular, we make it clear that &drm_device.mode_config.idr_mutex
protects the lease idr and list structures for drm_master. The lessor
field itself doesn't need to be protected a
On Thu, Jul 22, 2021 at 10:49:47AM +, Wang, Zhi A wrote:
> But it's hard for some customers to contribute their own "hypervisor"
> module to the upstream Linux kernel.
What prevents them from doing this? We will take any code that meets
our standards, what format is this external code in?
>
On Thu, Jul 22, 2021 at 3:44 AM Matthew Auld
wrote:
>
> On Wed, 21 Jul 2021 at 21:28, Jason Ekstrand wrote:
> >
> > On Thu, Jul 15, 2021 at 5:16 AM Matthew Auld wrote:
> > >
> > > From: Chris Wilson
> > >
> > > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > > to de
On Thu, Jul 22, 2021 at 5:34 AM Tvrtko Ursulin
wrote:
> On 22/07/2021 11:16, Daniel Vetter wrote:
> > On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
> >> On 21/07/2021 19:32, Daniel Vetter wrote:
> >>> This essentially reverts
> >>>
> >>> commit 84a1074920523430f9dc30ff907f4801b48
On Thu, Jul 22, 2021 at 02:07:51PM +0100, Christoph Hellwig wrote:
> On Thu, Jul 22, 2021 at 10:00:40AM -0300, Jason Gunthorpe wrote:
> > this is better:
> >
> >struct sg_append_table state;
> >
> >sg_append_init(&state, sgt, gfp_mask);
> >
> >while (..)
> > ret = sg_append_page
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-07-22:
Couple reverts from Jason getting rid of asynchronous command parsing
and fence error propagation and a GVT fix of shadow ppgtt invalidation
with proper D3 state tracking from Colin.
Thanks,
Rodrigo.
The following changes since commit 27
On Thu, Jul 22, 2021 at 3:49 AM Pekka Paalanen wrote:
>
> On Wed, 21 Jul 2021 13:55:07 -0400
> Sean Paul wrote:
>
> > From: Sean Paul
> >
> > Hi all,
> > I just had the pleasure of rebasing this set on our CrOS downstream
> > kernel and wanted to resend it for consideration once again. There
> >
1 - 100 of 255 matches
Mail list logo
