Hi Deepanshu,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/intel-lab-lkp/linux/commits/Deepanshu-Kartikey/Staging-fbtft-fbtft-bus-fixed-extra-space-and-parenthesis-issue/20230408-130429
patch link:
https:
Hi Lyude,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.3-rc5 next-20230406]
Hi Lyude,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.3-rc5 next-20230406]
Mark DSPP_2 and DSPP_3 as used for LM_2 and LM_3
Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp
Enable DSPP and DSC hardware blocks on sc8180x platform.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 28 +--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
b/drivers/g
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d ("drm/msm/dpu: add support
for SM8450") had all (relevant at that time) bit spelled individually.
Then commit 0e91bcbb0016 ("drm/msm/dpu: Add
This is a spin-off from [1]. Since most of the patches have been merged,
split away the small fixes. Continue the versioning of the patches.
Changes since v4:
- Fix commit message of sc8280xp patch. It is split display/panel rather
than split source (Abhinav)
- Added DSC_4 and DSC_5 to sc8180x p
Theoretically, since sm8150 we should be using a single CTL for the
split panel case, but since we do not support it for now, fallback to
DPU_CTL_SPLIT_DISPLAY.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 5 +++--
1 file changed, 3 insertions(+)
On Tue, 04 Apr 2023 16:05:40 +0300, Dmitry Baryshkov wrote:
> This huge series attempts to restructure the DPU HW catalog into a
> manageable and reviewable data set. In order to ease review and testing
> I merged all the necessary fixes into this series. Also I cherry-picked
> & slightly fixed K
On 08/04/2023 02:43, Abhinav Kumar wrote:
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Enable DSPP and DSC hardware blocks on sc8180x platform.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 26 +--
1 file changed, 24 insertions(+), 2 d
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Enable DSPP and DSC hardware blocks on sc8180x platform.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
On Fri, 31 Mar 2023 03:14:48 +0200, Konrad Dybcio wrote:
> This series brings SM8[12]50 (A6[45]0) speedbin support along with a
> touch-up for 8150, allowing Adreno to cooperate with the display hw.
>
> Tested on Xperia 5 II (SM8250 Edo PDX206) and Xperia 5 (SM8150 Kumano
> Bahamut).
>
> v2 -> v3
Reviewed-by: Lyude Paul
On Wed, 2023-04-05 at 13:04 +0200, Karol Herbst wrote:
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
> Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common
> code")
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/
Now that we're supporting things like Ada and the GSP, there's situations
where we really need to actually know the display state that we're starting
with when loading the driver in order to prevent breaking GSP expectations.
The first step in doing this is making it so that we can read the current
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
index 6094805fbd63..06b19883a06b 100644
---
Quoting Pin-yen Lin (2023-03-31 02:11:36)
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate those for a match too, in
On 4/6/23 15:21, Thomas Zimmermann wrote:
From: Daniel Vetter
Since vgaarb has been promoted to be a core piece of the pci subsystem
we don't have to open code random guesses anymore, we actually know
this in a platform agnostic way, and there's no need for an x86
specific hack. See also commit
On Fri, Apr 7, 2023 at 10:52 AM Nick Desaulniers
wrote:
>
> Jimmy, can you review?
>
> The change LGTM; but I'm not sure if there was something else intended here.
Nevermind, Jimmy's email address bounced.
Reviewed-by: Nick Desaulniers
>
> On Sat, Mar 25, 2023 at 6:45 AM Tom Rix wrote:
> >
> >
On Fri, Mar 31, 2023 at 1:42 PM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:7: error: variable
> 'loc' set but not used [-Werror,-Wunused-but-set-variable]
> u32 loc, sig, cnt, *meta;
> ^
> This variable is no
On Fri, Mar 31, 2023 at 10:24 AM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/qxl/qxl_ioctl.c:149:14: error: variable
> 'num_relocs' set but not used [-Werror,-Wunused-but-set-variable]
> int i, ret, num_relocs;
> ^
> This variable is not used so remove
On Fri, Mar 31, 2023 at 9:40 AM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:1700:6: error: variable
> 'num_of_active_display' set but not used [-Werror,-Wunused-but-set-variable]
> int num_of_active_display = 0;
> ^
> This v
On Wed, Mar 29, 2023 at 4:14 PM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/nouveau/nouveau_svm.c:929:6: error: variable
> 'ret' set but not used [-Werror,-Wunused-but-set-variable]
> int ret;
> ^
> This variable is not used so remove it.
>
> Signed-off-by: To
Jimmy, can you review?
The change LGTM; but I'm not sure if there was something else intended here.
On Sat, Mar 25, 2023 at 6:45 AM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_enc_cfg.c:625:6: error:
> variable 'matching_stream_ptrs' set bu
On Fri, Mar 24, 2023 at 12:54 PM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c:716:21: error: unused function
> 'mksstat_init_record' [-Werror,-Wunused-function]
> static inline char *mksstat_init_record(mksstat_kern_stats_t stat_idx,
> ^
> T
On Tue, Mar 21, 2023 at 11:24 AM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error:
> unused function 'vmw_overlay' [-Werror,-Wunused-function]
> static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)
>
On Mon, 20 Mar 2023 07:43:22 -0700, Rob Clark wrote:
> From: Rob Clark
>
> Inspired by
> https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
> it seemed like a good idea to get rid of memory allocation in job_run()
> fence signaling path, and use lockdep annotation
On Sat, 18 Mar 2023 14:42:46 +0100, Konrad Dybcio wrote:
> v5 -> v6:
> - Squash both fixes that concerned the deprecated QCM2290 compatible to
> avoid warnings
>
> v5:
> https://lore.kernel.org/r/20230307-topic-dsi_qcm-v5-0-9d4235b77...@linaro.org
>
> v4 -> v5:
> - Drop superfluous items: leve
On Sat, Mar 18, 2023 at 6:39 AM Tom Rix wrote:
>
> clang with W=1 reports
> drivers/gpu/drm/kmb/kmb_dsi.c:822:2: error: unused function
> 'set_test_mode_src_osc_freq_target_low_bits' [-Werror,-Wunused-function]
> set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
>
On 01/04/2023 01:12, Mark Yacoub wrote:
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
On 01/04/2023 01:12, Mark Yacoub wrote:
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
On 01/04/2023 01:12, Mark Yacoub wrote:
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new plat
On Thu, Apr 06, 2023 at 10:29:56PM +0200, Krzysztof Kozlowski wrote:
> HWmon core receives an array of pointers to hwmon_channel_info and it
> does not modify it, thus it can be array of const pointers for safety.
> This allows drivers to make them also const.
>
> Signed-off-by: Krzysztof Kozlowsk
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
This depends on hwmon core patch:
https://lore.kernel.org/all/20230406203103.3011503-2-krzysztof.kozlow...@linaro.org/
Therefore I propose this should also go via hw
Statically allocated array of pointed to hwmon_channel_info can be made
const for safety.
Signed-off-by: Krzysztof Kozlowski
---
This depends on hwmon core patch:
https://lore.kernel.org/all/20230406203103.3011503-2-krzysztof.kozlow...@linaro.org/
Therefore I propose this should also go via hw
On Fri, Apr 07, 2023 at 05:45:52AM -0400, Rodrigo Vivi wrote:
On Thu, Apr 06, 2023 at 05:37:58PM -0700, Lucas De Marchi wrote:
On Fri, Mar 31, 2023 at 03:52:16PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> First release of GuC for Meteorlake.
>
> NB: As this is still pre-r
The VI peripheral of Tegra supports capturing from MIPI CSI-2 or parallel
video (called VIP in the docs).
The staging tegra-video driver currently implements MIPI CSI-2 video
capture for Tegra210. Add support for parallel video capture (VIP) on
Tegra20. With the generalizations added to the VI dri
Tegra20 can do horizontal and vertical image flip, but Tegra210 cannot
(either the hardware, or this driver).
In preparation to adding Tegra20 support, add a flag in struct tegra_vi_soc
so the generic vi.c code knows whether the flip controls should be added or
not.
Also provide a generic impleme
Tegra20 supports planar YUV422 capture, which can be implemented by writing
U and V base address registers in addition to the "main" base buffer
address register.
It also supports H and V flip, which among others requires to write the
start address (i.e. the 1st offset to write, at the end of the
In preparation to implement Tegra20 parallel video capture, add a variable
to hold the required syncpt and document all the syncpt variables.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
Changed in v3:
- recycle mw_ack_sp
tegra_channel_host1x_syncpt_init() gets the host1x syncpts needed for the
Tegra210 implementation, and tegra_channel_host1x_syncpts_free() puts
them.
Tegra20 needs to get and put a different syncpt. In preparation for adding
Tegra20 support, move these functions to new ops in the soc-specific
`str
The CSI module does not handle all the MIPI lane calibration procedure,
leaving a small part of it to the VI module. In doing this,
tegra_channel_enable_stream() (vi.c) manipulates the private data of the
upstream subdev casting it to struct 'tegra_csi_channel', which will be
wrong after introducin
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 7 +
The tegra_default_format in vi.c is specific to Tegra210 CSI.
In preparation for adding Tegra20 VIP support, move the default format to a
new field in the soc-specific `struct tegra_vi_soc`. Instead of an entire
format struct, only store a pointer to an item in the existing format
array.
No funct
tegra_channel_fmt_align() takes care of the size constraints, alignment and
rounding requirements of the Tegra210 VI peripheral. Tegra20 has different
constraints.
In preparation for adding Tegra20 support, move this function to a new op
in the soc-specific `struct tegra_vi_ops` .
Also move to te
We are about to add support for the Tegra20 parallel video capture, which
has no TPG. In preparation for that, limit the VIDEO_TEGRA_TPG option to
Tegra210 which is the only implementation currently provided by this
driver.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No chang
There is only a pointer reference to struct tegra_vi in video.h, thus vi.h
is not needed.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/video.h | 1 -
struct tegra_vi_graph_entity is an internal implementation detail of the VI
module. Move its declaration from vi.h to vi.c.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/stagin
This declaration is used only in csi.c, no need to export it elsewhere.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
This patch was added in v3.
---
drivers/staging/media/tegra-video/csi.c | 4
drivers/staging/media/
of_node_put(node) does nothing if node == NULL, so it can be moved to the
cleanup section at the bottom.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video
tegra_vi_channels_alloc() can primarily fail for two reasons:
1. "ports" node not found
2. port_num > vi->soc->vi_max_channels
Case 1 prints nothing, case 2 has a dev_err(). The caller [tegra_vi_init()]
has a generic dev_err() on any failure. This mean that in case 2 we print
two messages, and
Add "skip" in "so we can *skip* the current channel" or it doesn't make
sense.
Also add articles where appropriate to fix English grammar.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
Clarify what this function does.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/sta
The Tegra20 VI peripheral can receive parallel input from the VIP parallel
input module. Add it to the allowed properties and augment the existing
nvidia,tegra20-vi example to show a 'vip' property.
Signed-off-by: Luca Ceresoli
Reviewed-by: Rob Herring
---
No changes in v5
Changed in RESEND,v
Some fields are irrelevant for Tegra20/VIP. Add a note to clarify that.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 6 +++---
1 file changed,
New in v5: dropped the patch that was removing lots of the logic behind
enum_format, after discussion with Hans. The rest is unmodified except for
rebasing and fixing a couple typos in comments.
Full details follow.
Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
receive
VIP is the parallel video capture component within the video input
subsystem of Tegra20 (and other Tegra chips, apparently).
Signed-off-by: Luca Ceresoli
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Dmitry Osipenko
---
No changes in v5
Changed in v4:
- Added review tags
- remove leftover
On 04/04/2023 11:11, Maxime Ripard wrote:
> The Versatile sp810 "timerclken" clock implements a mux with a
> set_parent hook, but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock.
Explanati
Thomas Zimmermann wrote:
> Select color format for EFI/VESA firmware scanout buffer from the
> number of bits per pixel and the position of the individual color
> components. Fixes the selected format for the buffer in several odd
> cases. For example, XRGB1555 has been reported as ARGB1555 becau
Javier Martinez Canillas writes:
> Hello,
>
> This series contains two trivial cleanups for the vkms driver.
>
> Patch #1 just gets rid of a wrapper helper that wasn't really adding that
> much value and patch #2 drops the header
> that was only used to call the drm_simple_encoder_init() functio
On Wed, Apr 05, 2023 at 09:45:20PM -0700, Ashutosh Dixit wrote:
> In preparation for follow-on patches, refactor hwm_power_max_write to take
> hwmon_lock and runtime pm wakeref at start of the function and release them
> at the end, therefore acquiring these just once each.
>
> Signed-off-by: Ashu
On Wed, Apr 05, 2023 at 09:45:21PM -0700, Ashutosh Dixit wrote:
> On dGfx, the PL1 power limit being enabled and set to a low value results
> in a low GPU operating freq. It also negates the freq raise operation which
> is done before GuC firmware load. As a result GuC firmware load can time
> out.
On Wed, Apr 05, 2023 at 09:45:22PM -0700, Ashutosh Dixit wrote:
> Instead of erroring out when GuC reset is in progress, block waiting for
> GuC reset to complete which is a more reasonable uapi behavior.
>
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 13 ++
Thomas Zimmermann writes:
> From: Daniel Vetter
>
> This one nukes all framebuffers, which is a bit much. In reality
> gma500 is igpu and never shipped with anything discrete, so there should
> not be any difference.
>
> v2: Unfortunately the framebuffer sits outside of the pci bars for
> gma500
Dmitry Baryshkov writes:
> Sparse reports plenty of warnings against the a6xx code because of
> a6xx_gmu::mmio and a6xx_gmu::rscc members. For some reason they were
> defined as __iomem pointers rather than pointers to __iomem memory.
> Correct the __iomem attribute.
>
> Fixes: 02ef80c54e7c ("drm
On Thu, Apr 06, 2023 at 05:37:58PM -0700, Lucas De Marchi wrote:
> On Fri, Mar 31, 2023 at 03:52:16PM -0700, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > First release of GuC for Meteorlake.
> >
> > NB: As this is still pre-release and likely to change, use explicit
> > versi
From: Fei Yang
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for ADM/L4 cache calls a
MOCS/PAT table update. Also defines PTE encode functions for
MTL as it has different PAT index definition than previous
platforms.
BSpec: 44509, 45101, 44235
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by Media tile update the whole
cache line even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line. CT
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by a
From: Fei Yang
The series includes patches needed to enable MTL.
Also add new extension for GEM_CREATE uAPI to let
user space set cache policy for buffer objects.
Fei Yang (8):
drm/i915/mtl: Define MOCS and PAT tables for MTL
drm/i915/mtl: enforce mtl PTE encode
drm/i915/mtl: workaround co
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Cc: Andi Shyti
From: Fei Yang
PTE encode functions are platform dependent. This patch ensures the
correct PTE encode function is used by calling pte_encode function
pointer instead of the hardcoded gen8 version of PTE encode.
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drive
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a defau
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, ha
74 matches
Mail list logo