On Wed, Nov 30, 2022 at 09:07:23AM -0800, Wayne Boyer wrote:
> As per the performance tuning guide, set the HOSTCACHEEN bit to
> implement the recommended caching policy on PVC.
>
> Signed-off-by: Wayne Boyer
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
>
On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
Drive-by comment: we've been a bit inconsistent about terminology in
the past, but my understanding is
On Wed, 2022-11-30 at 09:32 -0800, Matt Roper wrote:
> On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > tile. PXP as a service for supporting workloads with protected
>
> Drive-by comment: we've been a bit incon
> diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
> index a5af859217c1..3ec7d1756903 100644
> --- a/drivers/pwm/pwm-rockchip.c
> +++ b/drivers/pwm/pwm-rockchip.c
> @@ -57,9 +57,9 @@ static inline struct rockchip_pwm_chip
> *to_rockchip_pwm_chip(struct pwm_chip *c)
> retu
The recently added pcm-test selftest has pointed out that systems with
the tda998x driver end up advertising that they support capture when in
reality as far as I can see the tda998x devices are transmit only. The
DAIs registered through hdmi-codec are bidirectional, meaning that for
I2S systems w
Currently the hdmi-codec driver always registers both playback and capture
capabilities but for most systems there's no actual capture capability,
usually HDMI is transmit only. Provide platform data which allows the users
to indicate what is supported so that we don't end up advertising things
to
As far as I can tell none of the tda998x devices support audio capture so
don't advertise support for it, ensuring that we don't confuse userspace.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_dr
From: Christian Gmeiner
The MMU tells us the fault status. While the raw register value is
already printed, it's a bit more user friendly to translate the
fault reasons into human readable format.
Signed-off-by: Christian Gmeiner
Signed-off-by: Lucas Stach
---
I've rewritten parts of the patch
From: Rob Clark
A couple fixes for error paths that userspace could manage to trigger.
Rob Clark (2):
drm/shmem-helper: Remove errant put in error path
drm/shmem-helper: Avoid vm_open error paths
drivers/gpu/drm/drm_gem_shmem_helper.c | 18 --
1 file changed, 12 insertions(
From: Rob Clark
vm_open() is not allowed to fail. Fortunately we are guaranteed that
the pages are already pinned, thanks to the initial mmap which is now
being cloned into a forked process, and only need to increment the
refcnt. So just increment it directly. Previously if a signal was
delive
From: Rob Clark
drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM
object getting prematurely freed leading to a later use-after-free.
Link: https://syzkaller.appspot.com/bug?extid=c8ae65286134dd1b800d
Reported-by: syzbot+c8ae65286134dd1b8...@syzkaller.appspotmail.com
Fixes: 2
Hi Tomi,
On Wed, Nov 23, 2022 at 8:00 AM Tomi Valkeinen
wrote:
> Add clocks related to display which are needed to get the DSI output
> working.
>
> Extracted from Renesas BSP tree.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
Thanks for your
Hi,
I have started to look at igt for testing and want to use CRC tests. To
implement support for this I need to move away from the simple kms
helper.
When looking around for examples I came across Thomas' nice shadow
helper and thought, yes this is perfect for drm/gud. So I'll switch to
that bef
From: Noralf Trønnes
If a framebuffer flush fails the driver will do one retry by requeing the
worker. Currently the worker is used even for synchronous flushing, but a
later patch will inline it, so this needs to change. Thinking about how to
solve this I came to the conclusion that this retry m
From: Noralf Trønnes
Use the shadow plane helper to take care of mapping the framebuffer for
CPU access. The synchronous flushing is now done inline without the use of
a worker. The async path now uses a shadow buffer to hold framebuffer
changes and it doesn't read the framebuffer behind userspac
From: Noralf Trønnes
UBSAN complains about invalid value for bool:
[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1
[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device
[ 101.213426] usbcore: registered new interface driver gud
[ 101.989431]
==
From: Noralf Trønnes
In preparation for moving to the shadow plane helper prepare the
framebuffer for CPU access as early as possible.
v2:
- Use src as variable name for iosys_map (Thomas)
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c
From: Noralf Trønnes
In preparation for inlining synchronous flushing split out the part of
gud_flush_work() that can be shared by the sync and async code paths.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pip
From: Noralf Trønnes
gud has a module parameter that controls whether framebuffer flushing
happens synchronously during the commit or asynchronously in a worker.
GNOME before version 3.38 handled all displays in the same rendering loop.
This lead to gud slowing down the refresh rate for a faster
Hi Lucas
Am Mi., 30. Nov. 2022 um 19:53 Uhr schrieb Lucas Stach :
>
> From: Christian Gmeiner
>
> The MMU tells us the fault status. While the raw register value is
> already printed, it's a bit more user friendly to translate the
> fault reasons into human readable format.
>
> Signed-off-by: Chr
On Fri, Nov 18, 2022 at 03:15:25PM -0800, Kuogee Hsieh wrote:
>
> On 10/25/2022 8:26 PM, Bjorn Andersson wrote:
[..]
> > + mdss0: display-subsystem@ae0 {
[..]
> > +
> just curious, where are mdss0_dp0 and mdss0_dp1?. Are two dp/usb combo phys
> not going used?
They are, but at the t
This patch series adds bunch of new nodes
also it fixes some small nitpicks in yamls and adds compatible.
Changes since v1
1. Changed title for mdss yaml patch
2. Added missing dmas to spi0
3. Wired freq domains to CPUs
4. Added R-b/Ack tags
5. Reworded smmu dts patch
Adam Sklado
Add a node for the PRNG to enable hw-accelerated pseudo-random number
generation.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot
Document compatible for tsens on Qualcomm SM6115 platform
according to downstream dts it ship v2.4 of IP
Signed-off-by: Adam Skladowski
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/d
Add rpm stats node.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index 6f4c36f3da40..d0928f19965f 100644
--
Follow other YAMLs and replace mdss name into display-subystem.
Signed-off-by: Adam Skladowski
---
.../devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 2 +-
.../devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
dif
Add nodes required for TSENS block using the common qcom,tsens-v2 binding.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/
Add cpufreq-hw node and assign qcom,freq-domain properties
to CPUs to enable CPU clock scaling.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot
Add mdss and dpu node to enable display support on SM6115.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 183 +++
1 file changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boo
Add I2C/SPI nodes for SM6115.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 290 +++
1 file changed, 290 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index b30a5485671d..e676b9d117e3 1
Add fallback to generic qcom mmu-500 implementation.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index 38b903592a57..572bf0
Add GPI DMA node which will be wired to i2c/spi/uart.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6
Add display clock controller to allow controlling display related clocks.
Signed-off-by: Adam Skladowski
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boo
Add WCN node to allow using wifi module.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index e676b9d117e3..38b903592a
On 11/30/2022 00:30, Tvrtko Ursulin wrote:
On 29/11/2022 21:12, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
Engine resets or engine reset failures? Hopefully the latter.
Oops. Yes, that was meant to say "engine r
On Sat, Nov 26, 2022 at 08:54:11PM +0200, Dmitry Baryshkov wrote:
> On 25/11/2022 14:36, Bryan O'Donoghue wrote:
> > We will add in a number of compat strings to dsi-controller-main.yaml in
> > the format "qcom,socname-dsi-ctrl" convert the currently unused
> > qcom,dsi-ctrl-6g-qcm2290 to qcom,qcm2
The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
In file included from ../arch/x86/include/asm/olpc.h:7:0,
from ../drivers/mfd/cs5535-mfd.c:17:
../arch/x86/include/asm/ge
The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’:
../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_gt.c
between commit:
04aa64375f48 ("drm/i915: fix TLB invalidation for Gen12 video and compute
engines")
from Linus' tree and commit:
46c507f03a46 ("drm/i915/gt: Always use MCR functions o
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (4):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
drm/msm/dp: parser data-lanes as property of dp_out endpoint
drm/msm/dp: parser link-fr
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/
By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary p
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 16
drivers/gpu/drm/
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add &dp_out
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Signed-off-by:
Hi,
This series adds guards around vma's but setting a pages at the
beginning and at the end that work as padding.
The first user of the vma guard are scanout objects which don't
need anymore to add scratch to all the unused ggtt's and speeding
up up considerably the boot and resume by several hu
The coming commit "drm/i915: Introduce guard pages to i915_vma"
from Chris, was originally changing display_alignment to u32
from u64. The reason is that the display GGTT is and will be
limited o 4GB.
Put it in a separate patch and use "max(...)" instead of
"max_t(64, ...)" when asigning the value
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_n
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that su
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Curr
This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.
Checking the presence if the IRST (Intel Rapid Start Technology)
through the ACPI to decide whether to rebuild or not the GGTT
puts us at the mercy of the boot firmware and we need to
unnecessarily rely on third parties.
Because now we
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at
On 01/12/2022 02:07, Dmitry Baryshkov wrote:
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
support
Jason Gunthorpe wrote:
> On Thu, Oct 20, 2022 at 02:56:39PM -0700, Dan Williams wrote:
> > A 'struct dev_pagemap' (pgmap) represents a collection of ZONE_DEVICE
> > pages. The pgmap is a reference counted object that serves a similar
> > role as a 'struct request_queue'. Live references are obtaine
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_pars
On 11/23/2022 12:45, Michal Wajdeczko wrote:
On 23.11.2022 02:25, John Harrison wrote:
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Re-work the existing GuC CT printers and extend as required to match
the new wrapping
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/../../accel/drm_accel.c: In function 'accel_sysfs_init':
drivers/gpu/drm/../../accel/drm_accel.c:41:30: error: assignment to 'char *
(*)(const struct device *, umode_t *)'
From: ye xingchen
Replace the open-code with sysfs_emit() to simplify the code.
Signed-off-by: ye xingchen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgp
On Wed, Nov 30, 2022 at 04:21:38PM +0100, Uwe Kleine-König wrote:
> diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
> index 7f10f56c3eb6..11684edc0620 100644
> --- a/drivers/pwm/pwm-cros-ec.c
> +++ b/drivers/pwm/pwm-cros-ec.c
> @@ -183,8 +183,8 @@ static int cros_ec_pwm_apply(str
From: ye xingchen
Replace the open-code with sysfs_emit() to simplify the code.
Signed-off-by: ye xingchen
---
drivers/gpu/drm/i915/i915_mitigations.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mi
-20221130]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Hsia-Jun-Li/Add-pix
On 11/30/22 22:55, Randy Dunlap wrote:
The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’:
../drivers/video/fbd
On 11/30/22 22:55, Randy Dunlap wrote:
The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
In file included from ../arch/x86/include/asm/olpc.h:7:0,
from ../drivers/mfd/c
101 - 163 of 163 matches
Mail list logo
