> From: Tvrtko Ursulin
>
> On Meteorlake CPU cache will not contain stale data after GPU
> access since write-invalidate protocol is used, which means
> there is no need to flush before potentially transitioning the
> buffer to a non-coherent domain.
>
> Use the opportunity to documet the
On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > I did run into a bit of a chicken vs. egg problem with testing the "in
> > tree" version (compared to earlier versions which kept most of the yml
> > and scripts in a separate tree), is that it actually requires this
> > commit to exist in the
Use the helpers to simplify code.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: David Hildenbrand
Reviewed-by: Felix Kuehling
Signed-off-by: Kefeng Wang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 +
1
Factor out VMA stack and heap checks and name them
vma_is_initial_stack() and vma_is_initial_heap() for
general use.
Cc: Christian Göttsche
Cc: David Hildenbrand
Reviewed-by: David Hildenbrand
Signed-off-by: Kefeng Wang
---
fs/proc/task_mmu.c | 24
Use the helpers to simplify code.
Cc: Paul Moore
Cc: Stephen Smalley
Cc: Eric Paris
Acked-by: Paul Moore
Reviewed-by: David Hildenbrand
Signed-off-by: Kefeng Wang
---
security/selinux/hooks.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
Use the helpers to simplify code, also kill unneeded goto cpy_name.
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Reviewed-by: David Hildenbrand
Signed-off-by: Kefeng Wang
---
kernel/events/core.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
Add vma_is_initial_stack() and vma_is_initial_heap() helper and use
them to simplify code.
v2:
- add comment for heap helper and remove one more goto cpy_name,
per David Hildenbrand
- add RB
v2:
- address comments per David Hildenbrand and Christian Göttsche
- fix selinux build
Kefeng Wang
On 7/25/2023 4:49 PM, Nautiyal, Ankit K wrote:
On 7/25/2023 3:43 PM, Lisovskiy, Stanislav wrote:
On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote:
Hi Stan,
Thanks for the reviews ans suggestions. Please my response inline:
On 7/20/2023 2:59 PM, Lisovskiy, Stanislav
For MST the bpc is hardcoded to 8, and pipe bpp to 24.
So avoid forcing DSC bpc for MST case.
v2: Warn and ignore the debug flag than to bail out. (Jani)
v3: Fix dbg message to mention forced bpc instead of bpp.
v4: Fix checkpatch longline warning.
Signed-off-by: Ankit Nautiyal
---
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as
From: Stanislav Lisovskiy
Currently we seem to be using wrong DPCD register for reading
compressed bpps, reading min/max input bpc instead of compressed bpp.
Fix that, so that we now apply min/max compressed bpp limitations we
get from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD
Currently we check if the pipe_bpp selected is >= the
min DSC bpc/bpp requirement. We do not check if it is <= the max DSC
bpc/bpp requirement.
Add checks for max DSC BPC/BPP constraints while computing the
pipe_bpp when DSC is in use.
v2: Fix the commit message.
Signed-off-by: Ankit Nautiyal
Pull the code to get joiner constraints on maximum compressed bpp into
separate function.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 54 ++---
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git
Use checks for src and sink limits before computing compressed bpp for
eDP.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
Currently for testing an output format with DSC, we just force the
output format, without checking if it can be supported.
This also creates an issue where there is a PCON which might need to
convert from forced output format to the format to sink format.
Signed-off-by: Ankit Nautiyal
---
Refactor code to separate functions for eDP and DP for computing
pipe_bpp/compressed bpp when DSC is involved.
This will help to optimize the link configuration for DP later.
v2: Fix checkpatch warning.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 191
DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
Fix the DSC RECEIVER CAP SIZE accordingly.
Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
and missing SHIFT")
Cc: Anusha Srivatsa
Cc: Manasi Navare
Cc: # v5.0+
Signed-off-by: Ankit Nautiyal
---
The helper intel_dp_dsc_compute_bpp gives the maximum
pipe bpp that is allowed with DSC.
Rename the this to reflect that it returns max pipe bpp supported
with DSC.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
Separate out functions for getting maximum and minimum input BPC based
on platforms, when DSC is used.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 38 +++--
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
Check this condition for cases where bpc is forced by debugfs flag
dsc_force_bpc. If the check fails, then WARN and ignore the debugfs
flag.
For MST case the pipe_bpp is already computed (hardcoded to be 24),
and this check is not
To make way for fractional bpp support, avoid left shifting the
output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c |
As per Bsepc:49259, Bigjoiner BW check puts restriction on the
compressed bpp for a given CDCLK, pixelclock in cases where
Bigjoiner + DSC are used.
Currently compressed bpp is computed first, and it is ensured that
the bpp will work at least with the max CDCLK freq.
Since the CDCLK is computed
DSC compressed bpp and slice counts are already getting printed at the
end of dsc compute config. Remove extra logs.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).
v2: Corrected Display ver to 13.
v3: Follow convention for conditional statement. (Ville)
v4: Fix check for display ver. (Ville)
v5: Added note for 2 PPC. (Stan)
Signed-off-by: Ankit Nautiyal
The final link bpp used to calculate the m_n values depend on the
output_format. Though the output_format is set to RGB for MST case and
the link bpp will be same as the pipe bpp, for the sake of semantics,
lets calculate the m_n values with the link bpp, instead of pipe_bpp.
Signed-off-by: Ankit
Currently there are many places where we use output_bpp for link bpp and
compressed bpp.
Lets use consistent naming:
output_bpp : The intermediate value taking into account the
output_format chroma subsampling.
compressed_bpp : target bpp for the DSC encoder.
link_bpp : final bpp used in the link.
Move the check for limiting compressed bite_per_pixel for 420,422
formats in the helper to compute bits_per_pixel.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff
While using DSC the compressed bpp is computed assuming RGB output
format. Consider the output_format and compute the compressed bpp
during mode valid and compute config steps.
For DP-MST we currently use RGB output format only, so continue
using RGB while computing compressed bpp for MST case.
This series is an attempt to address multiple issues with DSC,
scattered in separate existing series.
Patches 1-4 are DSC fixes from series to Handle BPC for HDMI2.1 PCON
https://patchwork.freedesktop.org/series/107550/
Patches 5-6 are from series DSC fixes for Bigjoiner:
Hi Linus,
Regular scheduled fixes, msm and amdgpu leading the way, with some
i915 and a single misc fbdev, all seems fine.
Dave.
drm-fixes-2023-07-28:
drm fixes for 6.5-rc4
fbdev:
- remove unused function
amdgpu:
- gfxhub partition fix
- Fix error handling in psp_sw_init()
- SMU13 fix
- DCN
Add the check for the return value of bitmap_zalloc() in order to
guarantee the success of the allocation.
Fixes: e9b73c67390a ("drm/i915: Reduce memory pressure during shrinker by
preallocating swizzle pages")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 5
Please resend under the correct email.
Thanks,
Jessica Zhang
On 7/27/2023 6:12 PM, parellan wrote:
From: Paloma Arellano
Enable display compression (DSC v1.2) and CMD mode for 1080x2400 Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC
Enable display compression (DSC v1.2) and CMD mode for 1080x2400 Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC enabled.
Note: This patch has only been validated DSC over command mode as DSC over
video mode has never been validated for
On Thu, Jul 27, 2023 at 04:57:53PM -0700, Matt Roper wrote:
> On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
> > introduced PAT indices to i915 internal APIs, partially
On Thu, Jul 27, 2023 at 03:55:03PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Now that i915 understands the caching modes behind PAT indices, we can
> refine the check in use_cpu_reloc() to not reject the uncached PAT if it
> was set by userspace.
>
> Instead it can decide based on
On Thu, Jul 27, 2023 at 03:55:02PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Now that i915 understands the caching modes behind PAT indices, and having
> also special cased the Meteorlake snooping fully coherent mode, we can
> remove the user PAT check from
On Thu, Jul 27, 2023 at 03:55:01PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Now that i915 understands the caching modes behind PAT indices, we can
> refine the check in vm_fault_gtt() to not reject the uncached PAT if it
> was set by userspace on a snoopable platform.
>
>
On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
> introduced PAT indices to i915 internal APIs, partially replacing the
> usage of driver internal cache_level, but has also added
On 7/28/23 07:59, Dave Chinner wrote:
> On Thu, Jul 27, 2023 at 07:20:46PM +0900, Damien Le Moal wrote:
>> On 7/27/23 17:55, Qi Zheng wrote:
> goto err;
> }
> + zmd->mblk_shrinker->count_objects = dmz_mblock_shrinker_count;
> +
Hi Arthur,
On 7/8/23 22:38, Arthur Grillo wrote:
Support a 1D gamma LUT with interpolation for each color channel on the
VKMS driver. Add a check for the LUT length by creating
vkms_atomic_check().
Enable VKMS to run the test igt@kms_plane@pixel-format.
Tested with:
igt@kms_color@gamma
On Thu, Jul 27, 2023 at 11:57 PM Lyude Paul wrote:
>
> On Sun, 2023-07-09 at 01:42 +0200, Karol Herbst wrote:
> > On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul wrote:
> > >
> > > Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> > > nouveau in order to read the DPCD of a DP
drm_exec_prepare_obj() and drm_exec_prepare_array() both reserve
dma-fence slots and hence a dma_resv_list without ever freeing it.
Make sure to call drm_gem_private_object_fini() for each GEM object
passed to drm_exec_prepare_obj()/drm_exec_prepare_array() throughout the
test to fix this up.
Hi Arthur,
On 7/27/23 16:22, Arthur Grillo wrote:
The drm_exec tests where crashing[0] because of a null dereference. This
is caused by a new access of the `driver` attribute of `struct
drm_driver` on drm_gem_private_object_init(). Alloc the drm_device to
fix that.
[0]
[15:05:24]
On Thu, Jul 27, 2023 at 07:20:46PM +0900, Damien Le Moal wrote:
> On 7/27/23 17:55, Qi Zheng wrote:
> >>> goto err;
> >>> }
> >>> + zmd->mblk_shrinker->count_objects = dmz_mblock_shrinker_count;
> >>> + zmd->mblk_shrinker->scan_objects = dmz_mblock_shrinker_scan;
> >>> +
Chancellor
Reported-by: Naresh Kamboju
Signed-off-by: Nick Desaulniers
---
Changes in v2:
Fix the continue to be outside of the do while
- Link to v1:
https://lore.kernel.org/r/20230727-amdgpu-v1-1-a95690e75...@google.com
---
include/drm/drm_exec.h | 21 +
1 file changed, 5 inse
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Let's just stash it in adreno_platform_config rather than looking it up
> in N different places.
This leaves me with the feeling that we are abusing the
dev->platform_data, but we were doing it anyway even before the patch.
> \
> #define drm_exec_retry_on_contention(exec) \
> do {\
> if (unlikely(drm_exec_is_contended(exec))) \
> - goto *__drm_exec_retry_ptr;
1eb6a374f4dbcfc1cf007eafea91ab
change-id: 20230727-amdgpu-93c0e5302951
Best regards,
--
Nick Desaulniers
On 7/27/23 21:22, Arthur Grillo wrote:
The drm_exec tests where crashing[0] because of a null dereference. This
is caused by a new access of the `driver` attribute of `struct
drm_driver` on drm_gem_private_object_init(). Alloc the drm_device to
fix that.
[0]
[15:05:24] ==
On Thu, Jul 27, 2023 at 03:54:59PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Eliminate a bunch of runtime calls to i915_gem_get_pat_index() by caching
> the interesting PAT indices in struct drm_i915_private. They are static
> per platfrom so no need to consult a function every
On Thu, Jul 27, 2023 at 03:54:58PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> No need to run extra instructions which will never trigger on platforms
> before Meteorlake.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 26
On Thu, Jul 27, 2023 at 03:54:57PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> On Meteorlake CPU cache will not contain stale data after GPU access since
> write-invalidate protocol is used, which means there is no need to flush
> before potentially transitioning the buffer to a
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Sometimes it is useful to know the sub-generation (or "family"). And in
> any case, this helps us get away from infering the generation from the
Nit: inferring
> numerical chip-id.
>
> v2: Fix is_a2xx() typo
>
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> This simplifies the code.
>
> v2: Use a table of structs instead of flat uint32_t[]
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> There are cases where there are differences due to SoC integration.
> Such as cache-coherency support, and (in the next patch) e-fuse to
> speedbin mappings.
>
> Signed-off-by: Rob Clark
> ---
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> It is better to explicitly list it. With the move to opaque chip-id's
> for future devices, we should avoid trying to infer things like
> generation from the numerical value.
>
> Signed-off-by: Rob Clark
> Reviewed-by:
On Fri, 28 Jul 2023 at 00:22, Rob Clark wrote:
>
> From: Rob Clark
>
> Even in the ocmem case, the allocated ocmem buffer size should match the
> requested size.
>
> v2: Move stray hunk to previous patch, make OCMEM size mismatch an error
> condition.
>
> Signed-off-by: Rob Clark
On Fri, 28 Jul 2023 at 00:13, Rob Clark wrote:
>
> On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
> wrote:
> >
> > On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> > >
> > > On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> > > wrote:
> > > >
> > > > On 26/07/2023 23:11, Rob Clark wrote:
>
In order to address the STiH418, add more entries in sti_plane
Signed-off-by: Alain Volmat
---
drivers/gpu/drm/sti/sti_plane.c | 8
drivers/gpu/drm/sti/sti_plane.h | 8 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_plane.c
Add a new compatible in st,stih4xx.txt in order to support sti vtg on
stih418 platforms.
Signed-off-by: Alain Volmat
---
Documentation/devicetree/bindings/display/st,stih4xx.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On STiH418, the mixer is able to driver more layers of
planes. For this purpose, add those new possible entries
and allow it to work in either STiH407 or STiH418 mode.
Signed-off-by: Alain Volmat
---
drivers/gpu/drm/sti/sti_mixer.c | 66 -
On the STiH418, since there are more planes attached to the
mixer, the bit field for each depth of is now coded using 4 bits
instead of 3 bits. Some registers as well differ between STiH407
and STiH418 leading on relying on the st,stih418-compositor compatible
to distinguish proper behavior.
On the STiH418, a new clock (proc_mixer) must be enabled in order
to have the plane mixers properly behaving. Add a new
st,stih418-compositor in order to describe the planes/mixers
available on this platform.
Signed-off-by: Alain Volmat
---
drivers/gpu/drm/sti/sti_compositor.c | 26
The tvout for stih407 and stih418 differ in the connection with the
vtg regarding to the hdmi output. In order to cop with that, introduce
a new compatible st,stih418-tvout in order to have the hdmi_sync_id
being part of the data attached to each compatible.
Signed-off-by: Alain Volmat
---
Since the synchro signal used for hdmi output and coming from the
VTG differs between the stih407 and stih418 platforms, we cannot
rely anymore on hardcoded value and involve drivers use compatible
to figure out the value.
The macro VTG_SYNC_ID_HDMI can thus be removed.
Signed-off-by: Alain
This serie adds support for graphic display features on the stih418 soc.
Major differences compare to the already supported stih407 are
- a new HDMI PHY to support 4K resolutions
- updated mixer to support the higher number of planes available
on the stih418
- updated GDP (graphic
The STiH418 platform embeds two kinds of graphical planes (GDP),
so called GDPPLUS which has additional (yet unimplemented)
features compared to the GDP, and also the GDP.
Register map of GDPPLUS slightly differ from the GDP even if,
for common functionalities registers name and behavior are the
Addition of the HDMI TX PHY driver for use in the STiH418
SoC platform and more especially the 4KOpen (B2264) board.
Signed-off-by: Alain Volmat
---
drivers/gpu/drm/sti/Makefile | 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 4 +
drivers/gpu/drm/sti/sti_hdmi_tx6g0c28phy.c
VTG integrated into the STiH418 differ in the number of outputs
available and allocation of each output. Indeed on STiH418, there
are 6 outputs (4 on the STiH407/STiH410) and HDMI is connected to
the 5th output in case of STiH418 while it is on the 1st output
in case of STiH407/STiH410.
A new
On Sun, 2023-07-09 at 01:42 +0200, Karol Herbst wrote:
> On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul wrote:
> >
> > Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> > nouveau in order to read the DPCD of a DP connector, which makes sure we do
> > the right thing and also
On Thu, Jul 27, 2023 at 12:49 PM Rob Clark wrote:
>
> On Thu, Jul 20, 2023 at 8:27 AM Helen Koike wrote:
> >
> > From: Tomeu Vizoso
> >
> > Developers can easily execute several tests on different devices
> > by just pushing their branch to their fork in a repository hosted
> > on
Hi, Vivek,
On Tue, Jul 25, 2023 at 10:24:21PM +, Kasireddy, Vivek wrote:
> Hi Hugh,
>
> >
> > On Mon, 24 Jul 2023, Kasireddy, Vivek wrote:
> > > Hi Jason,
> > > > On Mon, Jul 24, 2023 at 07:54:38AM +, Kasireddy, Vivek wrote:
> > > >
> > > > > > I'm not at all familiar with the udmabuf
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-off-by: Rob Clark
---
From: Rob Clark
Let's just stash it in adreno_platform_config rather than looking it up
in N different places.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +++
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +++--
From: Rob Clark
Upcoming GPUs use an opaque chip-id for identifying the GPU.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
v2: Fix is_a2xx() typo
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 31
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c
From: Rob Clark
This simplifies the code.
v2: Use a table of structs instead of flat uint32_t[]
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
From: Rob Clark
All of these are derivatives of a630.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +++---
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
v2: Move stray hunk to previous patch, make OCMEM size mismatch an error
condition.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 25 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +--
From: Rob Clark
Downstream seems to be moving to using the chip_id as simply an opaque
identifier, and if we want to avoid headaches with userspace mesa
supporting both kgsl and upstream, we should move away from the
assumption that certain bits in the chip_id have a specific meaning.
v2 adds a
On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
wrote:
>
> On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> >
> > On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On 26/07/2023 23:11, Rob Clark wrote:
> > > > On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
> > > >
On 6/1/2023 8:59 AM, Alan Previn wrote:
In the case of failed suspend flow or cases where the kernel does not go
into full suspend but goes from suspend_prepare back to resume_complete,
we get called for a pm_complete but without runtime_pm guaranteed.
Thus, ensure we take the runtime_pm
We have a number of customers using these stats, but the issue that
keeps coming up is the CPU overhead to gather them, particularly on
systems with hundreds of processes using the GPU. Has anyone given
any thought to having a single interface to get this information for
the entire GPU in one
On Wed, Jul 19, 2023 at 05:42:54AM +, Kasireddy, Vivek wrote:
> > > + } else {
> > > + page =
> > shmem_read_mapping_page(mapping, pgoff + pgidx);
> >
> > It may not matter to your users, but the semantics for hugetlb and shmem
> > pages is different.
On 2023-07-27 22:22:20, Marijn Suijten wrote:
> On 2023-07-27 19:21:04, Dmitry Baryshkov wrote:
> > As the INTF is fixed at the encoder creation time, we can move the
> > check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
> > This function can return an error if INTF doesn't have
On 2023-07-27 23:16:22, Dmitry Baryshkov wrote:
> On 27/07/2023 23:14, Marijn Suijten wrote:
> > On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
> >> Replace the only user of the DPU_INTF_TE feature flag with the direct
> >> DPU version comparison.
> >>
> >> Signed-off-by: Dmitry Baryshkov
> >
>
On 2023-07-27 19:21:04, Dmitry Baryshkov wrote:
> As the INTF is fixed at the encoder creation time, we can move the
> check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
> This function can return an error if INTF doesn't have required feature.
> Performing this check in
On 2023-07-27 19:21:03, Dmitry Baryshkov wrote:
> The dpu_encoder_phys_cmd_te_rd_ptr_irq() function uses neither hw_intf
> nor hw_pp data, so we can drop the corresponding check.
Maybe because it would catch "bogus" interrupts, or these blocks are
accessed somewhere down the line in the vblank
On 27/07/2023 23:14, Marijn Suijten wrote:
On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
Replace the only user of the DPU_INTF_TE feature flag with the direct
DPU version comparison.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
> Replace the only user of the DPU_INTF_TE feature flag with the direct
> DPU version comparison.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ++--
>
This attempts to avoid circular locking dependency between flush delayed work
and intel_gt_reset.
Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync
version for reset path, it is safe as the worker has the trylock code to handle
the lock; Meanwhile keep the sync version
On 2023-07-27 19:21:01, Dmitry Baryshkov wrote:
> The DPU_INTF_TE bit is set for all INTF blocks on DPU >= 5.0, however
> only INTF_1 and INTF_2 actually support tearing control. Rather than
> trying to fix the DPU_INTF_TE, check for the presense of the
I would more exactly expand "fix" to
On 2023-07-27 19:21:00, Dmitry Baryshkov wrote:
> Inline the _setup_intf_ops() function, it makes it easier to handle
> different conditions involving INTF configuration.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 47
On 2023-07-27 19:20:59, Dmitry Baryshkov wrote:
> The DPU_PINGPONG_TE flag became unused, we can drop it now.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4
1 - 100 of 360 matches
Mail list logo
