On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst wrote:
>
> In the past this only led to compilation issues. Also the small amount of
> extra .text shouldn't really matter compared to the entire nouveau driver
> anyway.
>
> select DRM_TTM_HELPER
> - select BACKLIGHT_CLASS_DEVICE if DRM
From: Dillon Min
This driver combines tiny/ili9341.c mipi_dbi_interface driver
with mipi_dpi_interface driver, can support ili9341 with serial
mode and parallel rgb interface mode by different dts bindings.
Signed-off-by: Dillon Min
Reported-by: kernel test robot
Reviewed-by: Linus Walleij
Re
From: Dillon Min
Since the compatible string defined from ilitek,ili9341.yaml is
"st,sf-tc240t-9370-t", "ilitek,ili9341"
so, append "ilitek,ili9341" to avoid the below dtbs_check warning.
arch/arm/boot/dts/stm32f429-disco.dt.yaml: display@1: compatible:
['st,sf-tc240t-9370-t'] is too short
Fix
From: Dillon Min
Add documentation for "ilitek,ili9341" panel.
Signed-off-by: Dillon Min
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Link:
https://lore.kernel.org/lkml/1626853288-31223-2-git-send-email-dillon.min...@gmail.com/
---
v4: no change.
.../bindings/display/panel/ilitek,il
From: Dillon Min
Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts
but, the panel driver didn't get accepted from mainline. it's time to submit
patch fot it.
This driver can support two different interface by different dts bindings:
- spi+dpi, use spi to configure re
[Public]
Look copy right statement is missed in both amdgpu_vkms.c and amdgpu_vkms.h.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, July 23, 2021 10:32 PM
To: Taylor, Ryan
Cc: kernel test robot ; Daniel Vetter ;
Siqueira, Rodrigo ; amd-gfx li
Generally a big fan. 👍
--Jason
On July 23, 2021 19:11:34 Lucas De Marchi wrote:
Patches 1 and 2 are already being reviewed elsewhere. Discussion on 2nd
patch made me revive something I started after comment from Ville
at
https://patchwork.freedesktop.org/patch/428168/?series=88988&rev=1#comm
Quoting Akhil P Oommen (2021-07-23 04:20:54)
> Add the necessary dt nodes for gpu support in sc7280.
>
> Signed-off-by: Akhil P Oommen
> ---
> This patch has dependency on the GPUCC bindings patch here:
> https://patchwork.kernel.org/project/linux-arm-msm/patch/1619519590-3019-4-git-send-email-t..
On 7/22/2021 4:54 PM, Matthew Brost wrote:
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low level (3)
i915 level == 0 -> GuC normal level (2)
i91
On 7/22/2021 4:53 PM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to t
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210723]
[If your patch is applied to the wrong git tree
drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c:67:6: warning: symbol
'intel_eval_slpc_support' was not declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
intel_guc_debugfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with
{==,>=} 11. With the removal of CNL, there is no platform with graphics
version equals 10.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 1 -
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 10 ++
Remove registers that are not used anymore due to CNL removal and rename
those that are.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 192 ++-
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
2 files changed, 48 insertions(+), 146 deletions(
Cleanup remaining cases that we find CNL in the codebase.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 -
drivers/gpu/drm/i915/display/intel_dpll_mg
Remove support for CNL as it's highly untested, probably broken, and
there is no real platform that requires this code. This is part of CNL
removal from i915.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 41 +---
Remove references for CNL from pch detection.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_pch.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index cc44164e242b..d1d4b97b86f5 100644
--
Consider the new WOPCM size as starting in ICL rather than CNL since the
latter is being removed from the driver.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_wopcm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.
With the removal of CNL, let's consider GLK as the first platform using
those constants since GLK has DISPLAY_VER == 10.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
2 files changed, 7 insertion
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly in intel_display_power.c.
Signed-off-by: Lucas De Marchi
---
.../drm/i915/display/intel_display_power.c| 289 --
.../drm/i915/display/intel_display_power.h| 2 -
drivers/gpu/drm
Only one reference to CNL that is not needed, but code is the same for
DISPLAY_VER >= 11, so leave the code around and just remove the special
case for CNL.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
dif
With all the users removed, finish removing the CNL platform definitions.
We will leave the PCI IDs around as those are exposed to userspace.
Even if mesa doesn't support CNL anymore, let's avoid build breakages
due to changing the headers.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly in skl_universal_plane.c.
Remove code and rename functions/macros accordingly to use ICL prefix.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 14 +++---
CNL is the only platform with GRAPHICS_VER == 10. With its removal we
don't need to handle that version anymore.
Also we can now reduce the max number of slices: the call to
intel_sseu_set_info() with the highest number of slices comes from SKL
and BDW with 3 slices. Recent platforms actually incr
The numbers of scalers and sprites depend on the display version, so use
it instead of GRAPHICS_VER. We were mixing both, which let me confused
while removing CNL and GRAPHICS_VER == 10.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_device_info.c | 8
1 file changed, 4 i
Only one reference to CNL that is not needed, but code is the same for
GEN9_BC, so leave the code around and just remove the special
case for CNL.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
The only real platform with DISPLAY_VER == 10 is GLK, that doesn't have
combo phys. We don't need to handle CNL explicitly in
intel_combo_phy.c.
Remove code and rename functions/macros accordingly to use ICL prefix.
Signed-off-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_combo_phy.c
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need
any checks and supporting code for CNL. For DISPLAY_VER >= 11,
ilk_load_csc_matrix() is not used, so make it handle GLK only.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_color.c | 5 ++---
1 file cha
With the removal of CNL, let's consider ICL as the first platform using
those constants.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 24 +++
drivers/gpu/drm/i915/intel_dram.c | 32 +++
2 files changed, 28 insertions(+), 2
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
.../drm/i915/display/intel_ddi_buf_trans.c| 616 +-
.../drm/i915/display/intel_ddi_buf_tran
With the removal of CNL, let's consider ICL as the first platform using
that index.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_engine.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i9
Only one reference to CNL that is not needed, but code is the same for
DISPLAY_VER >= 11, so leave the code around and just remove the special
case for CNL.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly in intel_ddi.c.
A lot of special code for CNL can be removed. There were some
__cnl.*() functions that were created to share the implementation
between ICL and CNL. Those are now embedded in the only calle
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly in intel_dp.c.
Remove code and rename functions/macros accordingly to use ICL prefix.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dp.c | 35 -
1 file ch
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
handle CNL explicitly in intel_ddi.c.
Remove code and rename functions/macros accordingly to use ICL prefix.
There's one leftover reference to cnl that comes from the struct
intel_ddi_buf_trans. This will be renamed later when
Remove special handling of PORT_F in i915_irq.c and only do it for
DISPLAY_VER == 11.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_irq.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_i
Explicit support for CNL is being removed from the driver as it's not
expected to work. Remove the workaround for PORT_F from
display/intel_bios.c so we can also remove the generic DISPLAY_VER == 10
calls to intel_ddi_init(): the only platform with that display version
is already handled separately
No need for special CNL handling as there is no real platform with that
configuration.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i91
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need
any checks and supporting code for CNL. Remove code and rename
functions/macros accordingly.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 72 +-
drivers/gpu/drm/i915/i915
Remove DMC firmware for CNL.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 9895fd957df9..3c3c6cb5c0df 100644
--- a/
Commit 5a9d38b20a5a ("drm/i915/display: hide workaround for broken vbt
in intel_bios.c") moved the workaround for broken or missing VBT to
intel_bios.c. However is_port_valid() only protects the handling of
different skus of the same display version. Since in
intel_setup_outputs() we share the code
Patches 1 and 2 are already being reviewed elsewhere. Discussion on 2nd
patch made me revive something I started after comment from Ville
at
https://patchwork.freedesktop.org/patch/428168/?series=88988&rev=1#comment_768918
This removes CNL completely from the driver, while trying to rename
functi
We were using GRAPHICS_VER() to handle SKL_DFSM register, which means we
were not handling GLK correctly since that has GRAPHICS_VER == 9, but
DISPLAY_VER == 10. Switch the entire branch to check DISPLAY_VER
which makes it more in line with Bspec.
Even though the Bspec has an exception for RKL in
On Fri, Jul 23, 2021 at 05:53:36PM +0800, Huacai Chen wrote:
> Hi, Bjorn,
>
> On Fri, Jul 23, 2021 at 5:29 AM Bjorn Helgaas wrote:
> >
> > From: Bjorn Helgaas
> >
> > This is a little bit of rework and extension of Huacai's nice work at [1].
> >
> > It moves the VGA arbiter to the PCI subsystem,
In the past this only led to compilation issues. Also the small amount of
extra .text shouldn't really matter compared to the entire nouveau driver
anyway.
Cc: Arnd Bergmann
Cc: Lyude Paul
Cc: Ben Skeggs
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.
On 7/17/2021 2:54 PM, Sierra Guiza, Alejandro (Alex) wrote:
On 7/16/2021 5:14 PM, Felix Kuehling wrote:
Am 2021-07-16 um 11:07 a.m. schrieb Theodore Y. Ts'o:
On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
I can think of two ways to test the changes for
MEMORY_DEVICE_GENERIC
On Fri, Jul 23, 2021 at 10:27:08AM +0200, Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote:
> > On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote:
> > > From: Bjorn Helgaas
> > >
> > > This is a little bit of rework and extension of Huacai's nic
On 7/21/2021 11:21 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
This feature hands over the control of HW RC6 to the GuC.
GuC decides when to put HW into RC6 based on it's internal
busyness algorithms.
GUCRC needs GuC submission to be enabled, and only
supported
On 7/21/2021 11:13 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Update the get/set min/max freq hooks to work for
SLPC case as well. Consolidate helpers for requested/min/max
frequency get/set to intel_rps where the proper action can
be taken depending on whether
On 7/21/2021 11:09 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Cache rp0, rp1 and rpn platform limits into SLPC structure
for range checking while setting min/max frequencies.
Also add "soft" limits which keep track of frequency changes
made from userland. Thes
On Mon, Jul 19, 2021 at 1:57 PM Sam Ravnborg wrote:
>
> Hi Rob,
> On Mon, Jul 19, 2021 at 01:50:01PM -0600, Rob Herring wrote:
> > The graph schema doesn't allow custom properties on endpoint nodes for
> > '#/properties/port' and '#/$defs/port-base' should be used instead. This
> > doesn't matter
On Tue, 20 Jul 2021 11:20:25 -0600, Rob Herring wrote:
> There's no reason to have "status" properties in examples. "okay" is the
> default, and "disabled" turns off some schema checks ('required'
> specifically).
>
> Enabling qca,ar71xx causes a warning, so let's fix the node names:
>
> Document
On Mon, 19 Jul 2021 13:50:01 -0600, Rob Herring wrote:
> The graph schema doesn't allow custom properties on endpoint nodes for
> '#/properties/port' and '#/$defs/port-base' should be used instead. This
> doesn't matter until 'unevaluatedProperties' support is implemented.
>
> Cc: David Airlie
>
On 2021-07-21 19:42, Bjorn Andersson wrote:
Not all platforms has P0 at an offset of 0x1000 from the base address,
so add support for specifying each sub-region in DT. The code falls
back
to the predefined offsets in the case that only a single reg is
specified, in order to support existing DT.
On 2021-07-21 19:42, Bjorn Andersson wrote:
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the
DP block. So dss_io_data into representing each of the sub-regions, to
make it possible in the next patch to specify each of the sub-regions
individually.
Signed-off-by: Bjorn Ander
On 2021-07-21 19:42, Bjorn Andersson wrote:
In order to deal with multiple memory ranges in the following commit
change the ioremap wrapper to not poke directly into the dss_io_data
struct.
Signed-off-by: Bjorn Andersson
I think we can squash this one and the next patch into one.
Because the A
On 2021-07-21 19:42, Bjorn Andersson wrote:
The non-devres version of ioremap is used, which requires manual
cleanup. But the code paths leading here is mixed with other devres
users, so rely on this for ioremap as well to simplify the code.
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav
On 2021-07-21 19:42, Bjorn Andersson wrote:
reg was defined as one region covering the entire DP block, but the
memory map is actually split in 4 regions and obviously the size of
these regions differs between platforms.
Switch the reg to require that all four regions are specified instead.
It i
On 2021-07-23 3:14 p.m., Cornij, Nikola wrote:
> [AMD Official Use Only]
>
> +Harry
>
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, July 23, 2021 11:23 AM
> To: Arnd Bergmann
> Cc: Daniel Vetter ; Ben Skeggs ; David
> Airlie ; Lyude Paul ; Arnd Bergmann
> ; Ville Syrjä
On 7/21/2021 11:05 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
This prints out relevant SLPC info from the SLPC shared structure.
We will send a h2g message which forces SLPC to update the
shared data structure with latest information before reading it.
v2: Ad
On 7/21/2021 11:00 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Add helpers to read the min/max frequency being used
by SLPC. This is done by send a H2G command which forces
SLPC to update the shared data struct which can then be
read.
add note that functions w
On 7/21/2021 10:42 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Add param set h2g helpers to set the min and max frequencies
for use by SLPC.
v2: Address review comments (Michal W)
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Vinay Belgaumkar
---
driv
Quoting maitr...@codeaurora.org (2021-07-22 20:53:37)
> On 2021-07-22 15:09, Stephen Boyd wrote:
> Thank you for the comments .
> > Quoting maitr...@codeaurora.org (2021-07-22 14:33:43)
> >> Thank you Stephen.
> >>
> >> On 2021-07-22 13:31, Stephen Boyd wrote:
> >> > Quoting maitreye (2021-07-21 16
On 7/21/2021 10:26 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Allocate data structures for SLPC and functions for
initializing on host side.
v2: Address review comments (Michal W)
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
---
dri
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_luts to just a
slab_luts.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
No longer used.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 -
drivers/gpu/drm/i915/i915_globals.c | 53 ---
drivers/gpu/drm/i915/i915_globals.h | 25 -
drive
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_dependencies|priorities to just a
slab_dependencies|priorities.
Cc: Jason E
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_vmas to just a
slab_vmas.
We have to keep i915_drv.h include in i915_global
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_objects to just a
slab_objects.
Cc: Jason Ekstrand
Signed-off-by: Daniel V
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_blocks to just a
slab_blocks.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vet
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_requests|execute_cbs to just a
slab_requests|execute_cbs.
Cc: Jason Ekstran
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_cache to just a slab_cache.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vette
When modesetting (aka the full pci driver, which has nothing to do
with disable_display option, which just gives you the full pci driver
without the display driver) is disabled, we load nothing and do
nothing.
So move that check first, for a bit of orderliness. With Jason's
module init/exit table
On 7/21/2021 10:38 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Add methods for interacting with GuC for enabling SLPC. Enable
SLPC after GuC submission has been established. GuC load will
fail if SLPC cannot be successfully initialized. Add various
helper method
On 7/21/2021 10:25 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Add constants and params that are needed to configure SLPC.
v2: Add a new abi header for SLPC. Replace bitfields with
genmasks. Address other comments from Michal W.
Signed-off-by: Vinay Belgaumkar
[AMD Official Use Only]
+Harry
-Original Message-
From: Daniel Vetter
Sent: Friday, July 23, 2021 11:23 AM
To: Arnd Bergmann
Cc: Daniel Vetter ; Ben Skeggs ; David
Airlie ; Lyude Paul ; Arnd Bergmann
; Ville Syrjälä ; Cornij, Nikola
; dri-devel ; Nouveau
Dev ; Linux Kernel Mailing L
TTM during the transition to the new page allocator lost the ability
to constrain the allocations via the lower_mem_limit. The code has
been unused since the change:
256dd44bd897 ("drm/ttm: nuke old page allocator")
and there's no reason to keep it.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/
On Fri, Jul 23, 2021 at 8:40 PM Arnd Bergmann wrote:
>
> On Fri, Jul 23, 2021 at 6:34 PM Karol Herbst wrote:
> > On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
> > > On 7/23/21 8:15 AM, Karol Herbst wrote:
> > > > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap
> > > > wrote:
> > > >
> > > >
Hi
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated device
On Fri, Jul 23, 2021 at 6:34 PM Karol Herbst wrote:
> On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
> > On 7/23/21 8:15 AM, Karol Herbst wrote:
> > > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap
> > > wrote:
> > >
> > > what's actually the use case of compiling with
> > > CONFIG_DRM_NOUVE
Hi
Am 23.07.21 um 11:16 schrieb Arnd Bergmann:
From: Arnd Bergmann
A recent patch left an unused variable in place that needs to be
removed:
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c: In function 'hibmc_unload':
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c:252:35: error: unused varia
Are there IGTs for this anywhere?
On Fri, Jul 23, 2021 at 12:47 PM Jason Ekstrand wrote:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
>
> On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> >
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient metho
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
On Fri, Jul 23, 2021 at 6:35 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
> upo
[AMD Official Use Only]
I just want to make a comment that with this approach (the ns) calculating the
percentage will take at least two reads of the fdinfo per pid over some time.
Some engines may be able to provide a single shot percentage usage over an
internal integration period. That is, f
On Fri, Jul 23, 2021 at 10:57:56AM +0200, Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> > From: Chenyang Li
> >
> > This patch adds an initial DRM driver for the Loongson LS7A1000
> > bridge chip(LS7A). The LS7A bridge chip contains two display
> > controlle
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
Without TTM, we have no such hook so we exit early but this is fine
because we use TTM on all LMEM platforms and, on integrated platforms,
there is no real migration. If we do have the hook, it's better to just
let TTM handle the migration because it knows where things are actually
placed.
This f
__i915_ttm_get_pages does two things. First, it calls ttm_bo_validate()
to check the given placement and migrate the BO if needed. Then, it
updates the GEM object to match, in case the object was migrated. If
no migration occured, however, we might still have pages on the GEM
object in which cas
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, there should be no functional change.
v2 (Matthew Auld):
- Add the call to i915_gem_flush_free_objects() from
i915_
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Reviewed-by: Matth
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and retu
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object sh
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
v7:
- Drop "drm/i915/gem/ttm: Place new BOs in the requested region"
-
There is a scenario that dp cable is unplugged from DUT during system
suspended will cause audio option state does not match real connection
state. Fix this problem by Signaling audio plugged change with realtime
connection status at dp_pm_resume() so that audio option will be in
correct state aft
The code was trying to keep a strict limit on the amount of mob
memory that was used in the guest by making it match the host
settings. There's technically no reason to do that (guests can
certainly use more than the host can have resident in renderers
at the same time).
In particular this is prob
The code was using the old DRM logging functions, which made it
hard to figure out what was coming from vmwgfx. The newer logging
helpers include the driver name in the logs and make it explicit
which driver they're coming from. This allows us to standardize
our logging a bit and clean it up in the
The macro has been accounting for DRM_COMMAND_BASE for a long time
now so there's no reason to still be duplicating it. Plus we were
leaving the name undefined which meant that all the DRM ioctl
warnings/errors were always listing "null" ioctl at the culprit.
This fixes the undefined ioctl name an
To let the userspace recognize that it's running on top of a vmwgfx
that supports mks-stat ioctls we need to bump the version number.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Neha Bhende
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 +++---
1 file changed, 3 insertions(
1 - 100 of 198 matches
Mail list logo
