From: Fei Yang
GPU hangs have been observed when multiple engines write to the same aux_inv
register at the same time. To avoid this each engine should only invalidate
its own auxiliary table. The function gen12_emit_flush_xcs() currently
invalidate the auxiliary table for all engines because the
On Fri, Feb 25, 2022 at 05:14:28PM -0800, Lucas De Marchi wrote:
On Fri, Feb 25, 2022 at 10:34:43AM +, Matthew Auld wrote:
On DG2 we allow objects that are smaller than the min_page_size, under
the premise that these are never mapped by the GTT, like with the paging
structures. Currently the
Fix pointer offset usage in error_state_read
when there is no i915_gpu_coredump but buf offset
is non-zero.
This is the 2nd rev of this series.
Changes from prior revs:
v2: - Fix build issue: uninitialized var
Reported-by: kernel test robot
Alan Previn (1):
drm/i915/reset: Fix error
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register said lists
of global, engi
Hi Abhinav,
> Based on the discussion in this thread [1] , it seems like having drm_encoder
> as a pointer seems to have merits for both of us and also in agreement with
> the folks on this thread and has a better chance of an ack.
>
> However drm_connector is not.
>
> I had a brief look at your
From: Fei Yang
GPU hangs have been observed when multiple engines write to the same aux_inv
register at the same time. To avoid this each engine should only invalidate
its own auxiliary table. The function gen12_emit_flush_xcs() currently
invalidate the auxiliary table for all engines because the
On Fri, Feb 25, 2022 at 10:34:43AM +, Matthew Auld wrote:
On DG2 we allow objects that are smaller than the min_page_size, under
the premise that these are never mapped by the GTT, like with the paging
structures. Currently the suspend-resume path will try to map such
objects through the migr
On 2/24/2022 4:06 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor was being initialised early on in the context
registration sequence. It could then be determined that the actual
registration needs to be delayed and the descriptor would be wiped
out. This is ineff
On 2/24/2022 4:06 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. Further, the function that was
populating it was also doing a bunch of logic about the context
registration sequence. So, split that code apart into separate state
setup and try
Remove the local enabledisable() implementation and adopt the
str_enable_disable() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
drivers/gpu/drm
Remove the local onoff() implementation and adopt the
str_on_off() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/g4x_dp.c | 6 --
drivers/gpu/drm/i915/display/
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 23 +++
.../drm/i915/display/intel_displ
Remove the local enableddisabled() implementation and adopt the
str_enabled_disabled() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi
Acked-by: Daniel Vetter
Acked-by: Jani Nikula
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
drivers/gpu/d
Hi Suraj
On 2/22/2022 10:17 PM, Kandpal, Suraj wrote:
Hey,
The connector/encoder funcs you do have to pass to
drm_writeback_connector_init() can't use any of the shared driver
infrastructure that assume a certain inheritance.
See also my reply to Laurent [1].
It well might be that we all mi
On 2022-02-14 19:59:08 [+0100], To intel-...@lists.freedesktop.org wrote:
> There are a few sections in the driver which are not compatible with
> PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
>
> Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
> PREEMPT_
Quoting Maxime Ripard (2022-02-25 06:26:06)
> Hi Stephen,
>
> On Thu, Feb 24, 2022 at 02:54:20PM -0800, Stephen Boyd wrote:
> > Quoting Daniel Latypov (2022-02-23 14:50:59)
> > > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard wrote:
> > > Incremental coverage for 3/9 files in --diff_file
> > > Tot
Quoting Kuogee Hsieh (2022-02-25 13:23:12)
> Widebus feature will transmit two pixel data per pixel clock to interface.
> This feature now is required to be enabled to easy migrant to higher
> resolution applications in future. However since some legacy chipsets
> does not support this feature, thi
On Thu, Feb 24, 2022 at 04:47:42PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Current default VGA device selection fails in some cases because part of it
> is done in the vga_arb_device_init() subsys_initcall, and some arches
> enumerate PCI devices in pcibios_init(), which runs *after
On Fri, Feb 25, 2022 at 12:25 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Similar to AMD commit
> 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> infrastructure added in previous patches, we add basic client info
> and GPU engine utilisation for msm.
>
> Example output:
>
>
On 2/25/22 21:51, Michal Suchanek wrote:
> efifb is the only user of efifb_setup_from_dmi which is provided by
> sysfb which is selected by efifb. That makes the stub redundant.
>
> Signed-off-by: Michal Suchanek
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Ca
On 2/25/22 21:51, Michal Suchanek wrote:
> Since switch to simplefb/simpledrm VESA graphic mode selection with vga=
> kernel parameter is no longer available with legacy BIOS.
>
> The x86 realmode boot code enables the VESA graphic modes when option
> FB_BOOT_VESA_SUPPORT is enabled.
>
> This opt
Hello Michal,
On 2/25/22 21:51, Michal Suchanek wrote:
> efifb and vesafb requires sysfb implicitly but this is not stated in
> Kconfig. Add the dependency.
>
> With that all drivers that require sysfb depend on it so it can default
> to disabled.
>
> Signed-off-by: Michal Suchanek
> ---
Thank
Hello Hans,
On 2/25/22 22:49, Hans de Goede wrote:
> Add some debug logging to mipi_exec_i2c, to make debugging various
> issues seen with it easier.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4
> 1 file changed, 4 insertions(+)
>
Reviewed-by
Fix pointer offset usage in error_state_read
when there is no i915_gpu_coredump but buf offset
is non-zero.
Alan Previn (1):
drm/i915/reset: Fix error_state_read ptr + offset use
drivers/gpu/drm/i915/i915_sysfs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.25.1
The VBT DSI MIPI sequences of the panel on the Microsoft Surface 3
contain a couple of I2c writes to what seems to be a non existing
TI LP855x backlight controller, leading to the following errors:
i915 :00:02.0: [drm] mipi_exec_i2c bus 5 client-addr 0x2c reg 0x01 data 01
i2c_designware 808622
The current mipi_exec_i2c code uses 2 methods to find the I2C bus / adapter
to use:
1) Search for an ACPI I2cSerialBus resource matching the client address
from the MIPI sequence
2) Fall back to searching the adapter by the I2C bus number from the MIPI
sequence if 1) fails.
1 is fine, 2 however
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i91
On the Lenovo Yoga Tablet 2 830 / 1050 the VBT contains a bogus
192mm x 120mm size. This is especially a problem on the 8" 830 version
which uses a 10:16 portrait screen where as the bogus size is 16:10.
Add a DMI quirk to override the wrong panel size with the correct one.
Note both the 10" 1050
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.
Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa
Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x
Hi Rob,
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 35e7f44c2a75..987e78b18244 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -327,7 +327,7 @@ struct drm_gem_object {
> > > * non-static version of this you're probably doing it
On Fri, Feb 25, 2022 at 12:36 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 25, 2022 at 12:26:12PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Extend the helper macro so we don't have to throw it away if driver adds
> > support for optional fops, like show_fdinfo().
> >
> > Signed-off-by: Rob C
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled by setting
wide_bus_en flag to
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal wid
To improve code readability, this patch replace BIT(x) with
correspond register bit define string
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.
Signed-off-by: Ku
revise widebus timing engine programming and enable widebus feature base on chip
Kuogee Hsieh (4):
drm/msm/dpu: adjust display_v_end for eDP and DP
drm/msm/dpu: replace BIT(x) with correspond marco define string
drm/msm/dpu: revise timing engine programming to support widebus
feature
Applied. Thanks!
Alex
On Fri, Feb 25, 2022 at 8:04 AM Quan, Evan wrote:
>
> [AMD Official Use Only]
>
> Thanks!
> The patch is reviewed-by: Evan Quan
>
> > -Original Message-
> > From: Meng Tang
> > Sent: Friday, February 25, 2022 5:47 PM
> > To: airl...@linux.ie; dan...@ffwll.ch
> >
Quoting Kuogee Hsieh (2022-02-25 12:45:57)
> Widebus feature will transmit two pixel data per pixel clock to interface.
> This feature now is required to be enabled to easy migrant to higher
> resolution applications in future. However since some legacy chipsets
> does not support this feature, thi
efifb and vesafb requires sysfb implicitly but this is not stated in
Kconfig. Add the dependency.
With that all drivers that require sysfb depend on it so it can default
to disabled.
Signed-off-by: Michal Suchanek
---
v4: new patch
---
drivers/firmware/Kconfig| 5 ++---
drivers/video/fbdev/
efifb is the only user of efifb_setup_from_dmi which is provided by
sysfb which is selected by efifb. That makes the stub redundant.
Signed-off-by: Michal Suchanek
---
v4: new patch
---
include/linux/efi.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/efi.h b/include/linux
Since switch to simplefb/simpledrm VESA graphic mode selection with vga=
kernel parameter is no longer available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
This option is selected by vesafb but not simplefb/simpledrm.
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled by setting
wide_bus_en flag to
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal wid
To improve code readability, this patch replace BIT(x) with
correspond register bit define string
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.
Signed-off-by: Ku
revise widebus timing engine programming and enable widebus feature base on chip
Kuogee Hsieh (4):
drm/msm/dpu: adjust display_v_end for eDP and DP
drm/msm/dpu: replace BIT(x) with correspond marco define string
drm/msm/dpu: revise timing engine programming to support widebus
feature
From: John Harrison
A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in G
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence t
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
On Fri, Feb 25, 2022 at 12:26:12PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Extend the helper macro so we don't have to throw it away if driver adds
> support for optional fops, like show_fdinfo().
>
> Signed-off-by: Rob Clark
> ---
> include/drm/drm_gem.h | 3 ++-
> 1 file changed, 2 ins
From: Rob Clark
Noticed this was unused and never set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 1 -
drivers/gpu/drm/msm/msm_gpu.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index af612ad
From: Rob Clark
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
pos:0
From: Rob Clark
Extend the helper macro so we don't have to throw it away if driver adds
support for optional fops, like show_fdinfo().
Signed-off-by: Rob Clark
---
include/drm/drm_gem.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_gem.h b/include/drm/d
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need to ensure the CPU's instruction cache is coherent
with its data cache? Is it a
Add speedbin fuse and additional OPPs for gpu to support sc7280 SKUs.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 46
1 file changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/a
Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace
identify the sku.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 +
drivers/gpu/drm/msm/adreno/adren
Add support for 7c3 SKU detection using speedbin fuse.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu
Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of
hardcoding one. This helps to avoid code churn in case of a gpu rename.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- use devm_kasprintf() to generate gpu name (Rob)
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 -
Use generic name for resources like irq and kthread instead of hardware
specific name to make it easier to grep.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/msm_gpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm
This series supercedes [1]. Major change in this series is that it is now
optional to include a gpu name in the gpu-list. This helps to avoid the
confusion when we have different SKUs with different gpu names. And also
I am pretty happy that the overall changes are smaller now.
[1] https://patchwo
On 2/25/2022 10:29, Tvrtko Ursulin wrote:
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote
On Fri, Feb 25, 2022 at 06:42:37PM +, Tvrtko Ursulin wrote:
> Matthew, what do you think fix for this build warning on h8300 and s390
> should be? Or perhaps a build environment issue with kernel test robot?
I'd suggest this should do the job:
+++ b/include/linux/cacheflush.h
@@ -4,6 +4,8 @@
On 2/25/2022 10:14, Tvrtko Ursulin wrote:
I'll try to simplify the discussion here:
On 24/02/2022 19:45, John Harrison wrote:
On 2/24/2022 03:41, Tvrtko Ursulin wrote:
On 23/02/2022 20:00, John Harrison wrote:
On 2/23/2022 05:58, Tvrtko Ursulin wrote:
On 23/02/2022 02:45, John Harrison wrot
On 25/02/2022 18:23, Michael Cheng wrote:
These seem to be pretty old arch and are day0 warnings, please refer to
[1] to see the warnings. Also I am not sure why my patch series didn't
append to the old one.
[1] https://patchwork.freedesktop.org/patch/475829/?series=99450&rev=11
include/
Hi Dave, Daniel,
New stuff for 5.18.
The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c:
drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 15:59:06
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/am
On 25/02/2022 18:05, Michal Wajdeczko wrote:
On 25.02.2022 18:18, Tvrtko Ursulin wrote:
On 25/02/2022 16:46, John Harrison wrote:
driver we don't care that much that we failed to load HWconfig and
'notice' is enough.
but I'm fine with all messages being drm_err (as we will not have to
chan
On Fri, 18 Feb 2022 18:28:15 +0800, Rex Nie wrote:
> Add support for InnoLux n140hca-eac display panel. It is a 14" eDP panel
> with 1920x1080 display resolution.
>
> Signed-off-by: Rex Nie
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insert
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wro
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
These seem to be pretty old arch and are day0 warnings, please refer to
[1] to see the warnings. Also I am not sure why my patch series didn't
append to the old one.
[1] https://patchwork.freedesktop.org/patch/475829/?series=99450&rev=11
2022-02-25 10:19 a.m., Tvrtko Ursulin wrote:
On 25/02/
On 25/02/2022 17:40, Michael Cheng wrote:
Ah, thanks for pointing that out, when I do include it though, it causes
a few warning other systems such as h8300 and s390.
Errors look like? I haven't heard that kernel code is not allowed to
include something from linux/ on some arch yet.
Since
Quoting Kuogee Hsieh (2022-02-22 16:27:40)
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index 6ae9b29..c789f4e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -483,6 +485,22 @@ int dp_catalog_ctrl_s
I'll try to simplify the discussion here:
On 24/02/2022 19:45, John Harrison wrote:
On 2/24/2022 03:41, Tvrtko Ursulin wrote:
On 23/02/2022 20:00, John Harrison wrote:
On 2/23/2022 05:58, Tvrtko Ursulin wrote:
On 23/02/2022 02:45, John Harrison wrote:
On 2/22/2022 03:19, Tvrtko Ursulin wro
Quoting Kuogee Hsieh (2022-02-22 16:27:39)
> Widebus feature will transmit two pixel data per pixel clock to interface.
> Timing engine provides driving force for this purpose. This patch base
> on HPG (Hardware Programming Guide) to revise timing engine register
> setting to accommodate both wideb
Quoting Vinod Polimera (2022-02-25 07:57:50)
> use max clock during resume sequence from the opp table.
s/use/Use/
> The clock will be scaled down when framework sends an update.
>
> Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
Presumably this is the wrong fixes tag, see be
On Thu, Feb 24, 2022 at 10:16:24PM +0800, Lee Shawn C wrote:
> Support to read HF_EEODB block that request by HDMI 2.1 specification.
Please spell out what that thing is and why it exists.
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Ankit Nautiyal
> Signed-off-by: Lee Shawn C
> ---
> driv
Quoting Vinod Polimera (2022-02-25 07:57:49)
> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.
>
> drop the assigned clock rate property and set it
> during resume sequence with max value in the opp t
On 25.02.2022 18:18, Tvrtko Ursulin wrote:
>
> On 25/02/2022 16:46, John Harrison wrote:
>
driver we don't care that much that we failed to load HWconfig and
'notice' is enough.
but I'm fine with all messages being drm_err (as we will not have to
change that once again
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote
On Fri, Feb 25, 2022 at 05:41:17PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use lockdep_assert_not_held to simplify and correct the code. Otherwise
> false positive are hit if lock state is uknown like after a previous
> taint.
>
> Signed-off-by: Tvrtko Ursulin
> Reported-by: Vil
On Thu, Feb 24, 2022 at 10:16:23PM +0800, Lee Shawn C wrote:
> Try to find and parse more CEA ext blocks if edid->extensions
> is greater than one.
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Ankit Nautiyal
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/drm_edid.c | 110 ++
On 24/02/2022 19:51, John Harrison wrote:
On 2/24/2022 11:19, John Harrison wrote:
[snip]
I'll change it to _uses_ and repost, then.
[ 7.683149] kernel BUG at drivers/gpu/drm/i915/gt/uc/intel_guc.h:367!
Told you that one went bang.
intel_guc_is_used ?
My suggestion was intel_engine_u
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
From: Tvrtko Ursulin
Avoid false positives if lock state is unknown.
Signed-off-by: Tvrtko Ursulin
---
include/linux/dma-resv.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index afdfdfac729f..f475814c0d7a 100644
---
From: Tvrtko Ursulin
Use lockdep_assert_not_held to simplify and correct the code. Otherwise
false positive are hit if lock state is uknown like after a previous
taint.
Signed-off-by: Tvrtko Ursulin
Reported-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_vma.c | 4 +---
1 file changed, 1 ins
Ah, thanks for pointing that out, when I do include it though, it causes
a few warning other systems such as h8300 and s390.
Since it is already pulled is, would it be OK to leave it out for this
case? Or we could use something like !IS_H8300 and !IS_S390
around the header file?
On 2022-02-2
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@i
On 2/25/2022 09:06, Tvrtko Ursulin wrote:
On 24/02/2022 19:19, John Harrison wrote:
[snip]
./gt/uc/intel_guc_fwif.h: u32 execution_quantum;
./gt/uc/intel_guc_submission.c: desc->execution_quantum =
engine->props.timeslice_duration_ms * 1000;
./gt/intel_engine_types.h: unsigne
On 25/02/2022 16:52, Michael Cheng wrote:
Hi Tvrtko,
It seems without cacheflush.h being included, when I build for arm64 or
x86, it stills pulls in cacheflush.h:
./.drm_cache.o.cmd:838: include/linux/cacheflush.h \
./.drm_cache.o.cmd:839: arch/x86/include/asm/cacheflush.h \
./.drm_cache.o.
On Fri, 25 Feb 2022 at 20:11, Abhinav Kumar wrote:
>
>
>
> On 2/25/2022 1:04 AM, Dmitry Baryshkov wrote:
> > On Fri, 25 Feb 2022 at 07:45, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/24/2022 8:22 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar
> >>> wrote:
>
On 25/02/2022 16:46, John Harrison wrote:
driver we don't care that much that we failed to load HWconfig and
'notice' is enough.
but I'm fine with all messages being drm_err (as we will not have to
change that once again after HWconfig will be mandatory for the driver
as well)
I would be ag
On Mon, 21 Feb 2022 10:59:18 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_color_properties() with
> a default encoding and range values of BT601 and Full Range,
> respectively.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it
On Mon, 21 Feb 2022 10:59:14 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> The drm_plane_create_color_properties() function asks for an initial
> value for the color encoding and range, and will set the associated
> plane state variable with that value if a state is present.
>
> However
On Mon, 21 Feb 2022 10:59:02 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> Some functions to create properties (drm_plane_create_zpos_property or
> drm_plane_create_color_properties for example) will ask for a range of
> acceptable value and an initial one.
>
> This initial value is the
On Mon, 21 Feb 2022 10:59:13 +0100, Maxime Ripard wrote:
> The sun4i KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in sun4i_backend_layer_reset()
On Mon, 21 Feb 2022 10:59:12 +0100, Maxime Ripard wrote:
> The sti KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in sti_plane_reset().
> However,
On Mon, 21 Feb 2022 10:59:08 +0100, Maxime Ripard wrote:
> The mdp KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane purpose.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in mdp5_plane_reset(). Howeve
On Mon, 21 Feb 2022 10:59:10 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_zpos_property() with an
> init value of the plane index and the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in omap_plane_reset()
On Mon, 21 Feb 2022 10:59:11 +0100, Maxime Ripard wrote:
> The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in rcar_du_plane_reset() and
1 - 100 of 202 matches
Mail list logo
