On Tuesday, 14 February 2023 01:11:42 CET Patchwork wrote:
> == Series Details ==
>
> Series: Resolve barrier tasks list related issues
> URL : https://patchwork.freedesktop.org/series/113975/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12734 -> Patchwork_113975v1
On Tuesday, 14 February 2023 04:38:12 CET Patchwork wrote:
> == Series Details ==
>
> Series: Resolve barrier tasks list related issues
> URL : https://patchwork.freedesktop.org/series/113975/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12734_full ->
On Tue, Feb 14, 2023 at 1:45 AM Laurent Pinchart
wrote:
> To prepare for a rework of the LVDS disable code, which will need to be
> called from rcar_lvds_pclk_disable(), move the LVDS enable code,
> currently stored in the __rcar_lvds_atomic_enable() function, to a
> separate code section
On Thu, Feb 09, 2023 at 09:18:35AM +0100, Christian König wrote:
> Hello everyone,
>
> the drm_debugfs has a couple of well known design problems.
>
> Especially it wasn't possible to add files between initializing and
> registering
> of DRM devices since the underlying debugfs directory wasn't
On Mon, 13 Feb 2023 18:26:55 -0100
Melissa Wen wrote:
> On 02/10, Pekka Paalanen wrote:
> > On Thu, 9 Feb 2023 13:27:02 -0100
> > Melissa Wen wrote:
> >
> > > On 01/31, Pekka Paalanen wrote:
> > > > On Mon, 9 Jan 2023 14:38:09 -0100
> > > > Melissa Wen wrote:
> > > >
> > > > > On
On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:
> On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a new immutable plane property by which a plane can advertise
> > a handful of recommended plane sizes. This would be mostly exposed
>
On Tue, 07 Feb 2023, Arun R Murthy wrote:
> Enable SDP error detection configuration, this will set CRC16 in
> 128b/132b link layer.
> For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
> added to enable/disable SDP CRC applicable for DP2.0 only, but the
> default value of this
Am 14.02.23 um 09:59 schrieb Stanislaw Gruszka:
On Thu, Feb 09, 2023 at 09:18:35AM +0100, Christian König wrote:
Hello everyone,
the drm_debugfs has a couple of well known design problems.
Especially it wasn't possible to add files between initializing and registering
of DRM devices since the
On Mon, 13 Feb 2023 18:45:40 -0100
Melissa Wen wrote:
> On 02/13, Ville Syrjälä wrote:
> > On Mon, Feb 13, 2023 at 11:01:31AM +0200, Pekka Paalanen wrote:
> > > On Fri, 10 Feb 2023 14:47:50 -0500
> > > Harry Wentland wrote:
> > >
> > > > On 2/10/23 04:28, Pekka Paalanen wrote:
> > > > >
On Tue, 14 Feb 2023, Jani Nikula wrote:
> On Tue, 07 Feb 2023, Arun R Murthy wrote:
>> Enable SDP error detection configuration, this will set CRC16 in
>> 128b/132b link layer.
>> For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
>> added to enable/disable SDP CRC applicable
*** BLURB HERE ***
Arun R Murthy (2):
drm: Add SDP Error Detection Configuration Register
i915/display/dp: SDP CRC16 for 128b132b link layer
.../gpu/drm/i915/display/intel_dp_link_training.c| 12
include/drm/display/drm_dp.h | 3 +++
2 files
DP2.0 E11 defines a new register to facilitate SDP error detection by a
128B/132B capable DPRX device.
v2: Update the macro name to reflect the DP spec(Harry)
Signed-off-by: Arun R Murthy
Reviewed-by: Harry Wentland
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping
On Thu, 9 Feb 2023 13:51:05 +0200
Pekka Paalanen wrote:
> Maybe we could refine this so that userspace uses the stride and height
> implied by the caps for allocation, and then use the exact cursor image
> size for AddFB2? And have drivers pick any size between those two they
> can use. The
Hi Isabella,
On Friday, 10 February 2023 17:55:34 CET Isabella Basso wrote:
> Hi, Janusz,
>
> > Am 2023-02-10 um 11:56 AM schrieb Janusz Krzysztofik
> > :
> >
> > Hi Isabella,
> >
> > On Monday, 19 September 2022 22:55:44 CET Isabella Basso wrote:
> >> Hi, Janusz,
> >>
> >>> Am 09/09/2022 um
On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:
> > On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a new immutable plane property by which a plane can advertise
On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote:
> On Thu, 9 Feb 2023 13:51:05 +0200
> Pekka Paalanen wrote:
>
> > Maybe we could refine this so that userspace uses the stride and height
> > implied by the caps for allocation, and then use the exact cursor image
> > size for
On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
> On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:
> > > On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
On Tue, 14 Feb 2023 at 07:43, Christian König
wrote:
>
> From: Somalapuram Amaranath
>
> Change the ttm_range_man_alloc() allocation from pages to size in bytes.
> Fix the dependent drm_mm_nodes start and size from pages to bytes.
>
> v2 (chk): Change the drm_mm_node usage in amdgpu as well.
Am 14.02.23 um 11:31 schrieb Matthew Auld:
On Tue, 14 Feb 2023 at 07:43, Christian König
wrote:
From: Somalapuram Amaranath
Change the ttm_range_man_alloc() allocation from pages to size in bytes.
Fix the dependent drm_mm_nodes start and size from pages to bytes.
v2 (chk): Change the
[AMD Official Use Only - General]
+ Uday, for awareness.
Regards
Shashank
-Original Message-
From: Pekka Paalanen
Sent: 14 February 2023 10:28
To: Melissa Wen
Cc: Ville Syrjälä ;
dri-devel@lists.freedesktop.org; airl...@gmail.com;
laurent.pinchart+rene...@ideasonboard.com; Sharma,
On 07/02/2023 10.23, Marek Vasut wrote:
> On 2/7/23 10:09, Rasmus Villemoes wrote:
>
> [...]
>
>> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
>> that's a separate issue; when I boot with a monitor attached, its edid
>> is correctly read out. But I still don't get any
Hi Laurent,
Gentle ping for review. Is this patchset is on the right direction?
Please let me know.
As per [1], Indirection being removed and created a new DRM driver(rzg2l-du),
and
share common code with the DU driver.
[1]
On Mon, Feb 13, 2023 at 10:41:32AM +, Lin, Wayne wrote:
> [Public]
>
> Add Mario for awareness.
>
> > -Original Message-
> > From: Jani Nikula
> > Sent: Friday, February 10, 2023 6:48 PM
> > To: Lyude Paul ; imre.d...@intel.com; Wentland,
> > Harry ; Deucher, Alexander
> > ; Daniel
On Tue, Feb 14, 2023 at 12:28:44PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
> > On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:
> > > > On Wed, Feb 08, 2023 at
On 14/02/2023 11.55, Rasmus Villemoes wrote:
> On 07/02/2023 10.23, Marek Vasut wrote:
>
> Do any of you happen to have this working on the imx8mp-evk, and if so,
> can you share the .dts updates you've done and how exactly you test the
> graphics?
>
Oh, and could those of you who have some
Hi,
On 06.02.2023 16:41, Jeffrey Hugo wrote:
> The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence
> accelerator PCIe card. It contains a number of components both in the
> SoC and on the card which facilitate running workloads:
>
> QSM: management processor
> NSPs: workload
Hi Rasmus,
On Tue, Feb 14, 2023 at 7:55 AM Rasmus Villemoes
wrote:
> Well, the data sheet for the dsi86 says up to 750MHz DSI HS clock, and
> if the value specified in samsung,burst-clock-frequency is twice the DSI
> HS clk, I suppose I should be good up to 1.5GHz? I have tried many
> different
On Tue, Feb 14, 2023 at 8:09 AM Fabio Estevam wrote:
> Some extra ADV7535 patches were needed. Please check patches 0020-0023
> and see if they help.
Sorry, forgot to put the repo URL:
On Tue, 14 Feb 2023 12:27:45 +0200
Ville Syrjälä wrote:
> On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote:
> > On Thu, 9 Feb 2023 13:51:05 +0200
> > Pekka Paalanen wrote:
> >
> > > Maybe we could refine this so that userspace uses the stride and height
> > > implied by the
On Tue, Feb 14, 2023 at 12:01:49PM +0100, Jonas Ådahl wrote:
> On Tue, Feb 14, 2023 at 12:28:44PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
> > > On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> > > > On Thu, Feb 09, 2023 at
On 8.02.2023 19:21, Jordan Crouse wrote:
> On Thu, Jan 26, 2023 at 04:16:13PM +0100, Konrad Dybcio wrote:
>> Adreno 619 expects some tunables to be set differently. Make up for it.
>>
>> Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
>> Signed-off-by: Konrad Dybcio
>> ---
>>
On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 12:27:45 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote:
> > > On Thu, 9 Feb 2023 13:51:05 +0200
> > > Pekka Paalanen wrote:
> > >
> > > > Maybe we could
On 2/13/23 21:49, Arthur Grillo wrote:
> Make implicit enum conversion to avoid -Wenum-conversion warning, such
> as:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:4109:88:
> warning: implicit conversion from ‘enum ’ to ‘enum
> odm_combine_mode’
On Tue, Feb 14, 2023 at 10:28:24AM +0100, Christian König wrote:
> Am 14.02.23 um 09:59 schrieb Stanislaw Gruszka:
> > On Thu, Feb 09, 2023 at 09:18:35AM +0100, Christian König wrote:
> > > Hello everyone,
> > >
> > > the drm_debugfs has a couple of well known design problems.
> > >
> > >
On 2/13/23 14:50, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Dmitry Osipenko wrote:
>> On 2/13/23 12:56, Jani Nikula wrote:
>>> On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
Hi,
On 1/18/22 20:00, Yaroslav Bolyukin wrote:
Add a brief commit message, describing a user-visible
On 2/3/23 18:37, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote:
This adds the infrastructure for a manager implementation to keep track
of GPU virtual address (VA) mappings.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start
On Thu, Feb 09, 2023 at 09:18:36AM +0100, Christian König wrote:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index c6eb8972451a..88ce22c04672 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -156,6 +156,10 @@ static int
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> -void drm_debugfs_late_register(struct drm_device *dev)
> -{
> - struct drm_minor *minor = dev->primary;
> - struct drm_debugfs_entry *entry, *tmp;
> -
> - if (!minor)
> - return;
> -
> -
The commit e25e92e08e32 ("drm/msm: devcoredump iommu fault support")
enabled SMMU stalling to collect GPU state, but only for a6xx. It tied
enabling the stall with tha per-instance pagetables creation.
Since that commit SoCs with a5xx also gained support for
adreno-smmu-priv. Move stalling into
Split the a6xx_fault_handler() into the generic adreno_fault_handler()
and platform-specific parts. The adreno_fault_handler() can further be
used by a5xx and hopefully by a4xx (at some point).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 64
During the debug of the a5xx preempt issue, having the devcoredump
support was a great help. These patches port necessary code bits from
being a6xx-specific to generic code path and then enables devcoredump
for a5xx.
Dmitry Baryshkov (3):
drm/msm/adreno: stall translation on fault for all GPU
Use adreno_fault_handler() to implement a5xx_fault_handler(). This
enables devcoredump support on a5xx platforms, allowing one to capture
the crashed GPU state at the time of context fault.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 -
1 file
On Tue, Feb 14, 2023 at 01:19:51PM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > -void drm_debugfs_late_register(struct drm_device *dev)
> > -{
> > - struct drm_minor *minor = dev->primary;
> > - struct drm_debugfs_entry *entry, *tmp;
>
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having its creation fail, can have a range of
On 2023-02-13 19:09:32, Abhinav Kumar wrote:
>
>
> On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote:
> > On 13/02/2023 21:37, Jessica Zhang wrote:
> >>
> >>
> >> On 12/31/2022 1:50 PM, Marijn Suijten wrote:
> >>> All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0,
> >>> but
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:08 CET schrieb Liu Ying:
> A valid bridge is already found in lcdif_attach_bridge() and set
> to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
> the unnecessary NULL pointer check in KMS stage.
>
> Signed-off-by:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> Instead of determining LCDIF output bus format and bus flags in
> ->atomic_enable(), do that in ->atomic_check(). This is a
> preparation for the upcoming patch to check consistent bus format
> and bus
On Tue, Feb 14, 2023 at 03:12:55PM +0100, Alexander Stein wrote:
> Hi Liu,
>
> thanks for the update.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do that in ->atomic_check(). This is a
Hi,
On Mon, Feb 13, 2023 at 6:02 PM Abhinav Kumar wrote:
>
> Hi Doug
>
> Sorry for the delayed response.
>
> On 2/2/2023 2:46 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 2, 2023 at 2:37 PM Abhinav Kumar
> > wrote:
> >>
> >> Hi Doug
> >>
> >> On 1/31/2023 2:18 PM, Douglas Anderson
On Mon, Feb 13, 2023 at 04:11:46PM +0900, FUKAUMI Naoki wrote:
> hi,
>
> on my rk3399 boards(ROCK Pi 4B+ and ROCK 4C+), fb0 is configured as
> 1920x1080, and nothing is displayed... "no signal" on display.
I can confirm this.
First of all there is a stupid bug in my patch:
> + if
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 10:19, Ville Syrjälä wrote:
> > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
> > >>
> > >>
> > >> On 2/3/23 07:59, Sebastian Wick
On 14/02/2023 02:37, Laurent Pinchart wrote:
To prepare for a rework of the LVDS disable code, which will need to be
called from rcar_lvds_pclk_disable(), move the LVDS enable code,
currently stored in the __rcar_lvds_atomic_enable() function, to a
separate code section separate from bridge
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:11 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Look at LCDIF output port's remote port parents to
> find all enabled first bridges. Add an encoder for each found
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:12 CET schrieb Liu Ying:
> With all previous preparations done to make it possible for the
> single LCDIF embedded in i.MX93 SoC to drive multiple displays
> simultaneously, add i.MX93 LCDIF compatible string as the last
> step of
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying:
> There is one LCDIF embedded in i.MX93 SoC to connect with
> MIPI DSI controller through LCDIF cross line pattern(controlled
> by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
> directly or
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:10 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Check bus format and flags across first bridges in
> ->atomic_check() to ensure they are consistent. This is a
On 14/02/2023 02:37, Laurent Pinchart wrote:
When disabling the companion bridge in rcar_lvds_atomic_disable(),
there's no need to go through the bridge's operations to call
.atomic_disable(). Call rcar_lvds_atomic_disable() on the companion
directly.
Signed-off-by: Laurent Pinchart
---
On 14/02/2023 02:37, Laurent Pinchart wrote:
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to
the DU, regardless of whether the LVDS output is used or not. When using
the DPAD (RGB) output, the DU driver thus enables and disables the LVDS
PLL manually, while when using the
On Wed, 2023-02-15 at 08:26 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for the review.
>
> Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying:
> > There is one LCDIF embedded in i.MX93 SoC to connect with
> > MIPI DSI controller through
On Tue, Feb 14, 2023 at 08:25:08PM -0800, Ira Weiny wrote:
> Date: Tue, 14 Feb 2023 20:25:08 -0800
> From: Ira Weiny
> Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with
> kmap_local_page()
>
> Zhao Liu wrote:
> > From: Zhao Liu
> >
> > The use of kmap_atomic() is being deprecated
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created
Applied. Thanks!
Alex
On Fri, Feb 10, 2023 at 2:37 PM Harry Wentland wrote:
>
> On 2/10/23 05:00, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> >
Zhao Liu wrote:
> From: Zhao Liu
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
Zhao,
Was there ever a v2 of this series? I'm not finding it on Lore.
Thanks,
Ira
>
> In the following patches, we can convert the calls of kmap_atomic() /
>
Applied. Thanks!
On Fri, Feb 10, 2023 at 10:22 AM Harry Wentland wrote:
>
> On 2/10/23 05:11, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> > Signed-off-by:
On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä
wrote:
[...]
> > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well:
> > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)];
> > But it would only result in an 8 byte wide buffer.
> > Nobody uses it like this yet.
>
> Not sure that would make any sense
+ Akhil
On Tue, Feb 14, 2023 at 10:03 AM Konrad Dybcio wrote:
>
>
> v1 -> v2:
> - Fix A630 values in [2/14]
> - Fix [6/14] for GMU-equipped GPUs
>
> Link to v1:
> https://lore.kernel.org/linux-arm-msm/20230126151618.225127-1-konrad.dyb...@linaro.org/
>
> This series concludes my
On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations. There are too many caching pitfalls due to the
way stolen memory accesses are routed. So it is safest to just not use
On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
>
Hi Guenter,
> On 2/13/23 21:33, Ashutosh Dixit wrote:
> > On ATSM the PL1 power limit is disabled at power up. The previous uapi
> > assumed that the PL1 limit is always enabled and therefore did not have a
> > notion of a disabled PL1
On Tue, 2023-02-14 at 15:12 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for your review.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do
On Tue, Feb 14, 2023 at 10:26:24PM +0100, Martin Blumenstingl wrote:
> On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä
> wrote:
> [...]
> > > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well:
> > > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)];
> > > But it would only result in an 8 byte wide
On 15/02/2023 01:25, Abhinav Kumar wrote:
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Also drop the forware definition of struct led_classdev that is now
provided by linux/leds.h.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
1 file changed, 1
On Tue, Feb 14, 2023 at 4:38 PM Konrad Dybcio wrote:
>
>
>
> On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> > On 14/02/2023 23:56, Rob Clark wrote:
> >> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
> >> wrote:
> >>>
> >>> One of the protected ranges was too small (compared to the data we
> >>>
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations. There are too many caching pitfalls due to the
way stolen memory accesses are routed. So it is safest to just not use
it.
Signed-off-by: John Harrison
---
On Tue, Feb 14, 2023 at 10:18:49PM +0100, Sebastian Wick wrote:
> On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
> > > wrote:
> > > >
> > > >
> > > >
> > > > On
On 14/02/2023 23:56, Rob Clark wrote:
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
One of the protected ranges was too small (compared to the data we
have downstream). Fix it.
Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
Signed-off-by: Konrad Dybcio
---
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
>
> One of the protected ranges was too small (compared to the data we
> have downstream). Fix it.
>
> Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
> Signed-off-by: Konrad Dybcio
> ---
>
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to
On Sat, 11 Feb 2023 13:26:48 +0100, Konrad Dybcio wrote:
> Add the DSI host found on SM6375.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Sat, 11 Feb 2023 13:26:47 +0100, Konrad Dybcio wrote:
> Add the DSI host found on SM6350.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> On 14/02/2023 23:56, Rob Clark wrote:
>> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
>> wrote:
>>>
>>> One of the protected ranges was too small (compared to the data we
>>> have downstream). Fix it.
>>>
>>> Fixes: 408434036958 ("drm/msm/a6xx:
Another Lenovo convertable where the panel is installed landscape but is
reported to the kernel as portrait.
Signed-off-by: Darrell Kavanagh
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Port setting min_access_length, ubwc_mode and upper_bit from downstream.
Values were validated using downstream device trees for SM8[123]50 and
left default (as per downstream) elsewhere.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29 +++
1
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the required kernel-side support for it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 37
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0. For GMU-equipped GPUs this is
done in a6xx_bus_clear_pending_transactions(), but for the GMU-less
ones we have to do it *somewhere*. Unhalting both side by side sounds
like a good plan and
These two will be reused by at least A619_holi in the non-gmu
paths. De-staticize them to make it possible.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
1 - 100 of 130 matches
Mail list logo
