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 -> Patchwork_1139
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 separate
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 01/0
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 b
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:
> > > > > O
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 fo
*** 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 changed,
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(+)
dif
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 this
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 kerne
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 AddFB2
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. re-o
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 drm_mm_
[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, Sh
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 ou
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]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/202203161
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 V
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 11:10:1
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 graph
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:
https://github.com/fabioestevam/meta-imx8mmevk-bsp/tree/kirkstone/recipes-kernel/linux/linux-stable/6.1/imx8mm
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 caps
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 03:16:2
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
>> ---
>> drivers/
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 re
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’ [-Wenum-conversion]
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.
> > >
> > > Especia
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 impl
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 drm_minor_alloc(struc
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;
> -
> - list_for_each_en
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 ge
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 fa
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 chang
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 negative
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 excludin
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 f
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 wrote
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 (vop->da
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 wrote
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 a/drivers/gpu/drm/drm_panel_orientation_quirks.
On 2/14/23 10:49, Sebastian Wick wrote:
> 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:
>
Hi,
On 2/14/23 17:46, Darrell Kavanagh wrote:
> Another Lenovo convertable where the panel is installed landscape but is
> reported to the kernel as portrait.
>
> Signed-off-by: Darrell Kavanagh
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Note for other developers the reason t
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 f
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
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing Adreno
These SKUs don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adr
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ensure that we aren't trying to
run the GPU at 1GHz with a VDD_LOW vote, as that would result in
an otherwise inexplainable hang.
Tell th
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 lin
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 a/drivers/gpu/drm/msm/adr
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
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On GMU-equipped GPUs, the GMU requests appropriate bandwidth votes
for us. This is however not the case for the other GPUs. Add the
dev_pm_opp_of_find_icc_paths() call to let the OPP framework handle
bus voting as part of power level setting.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/g
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125
(trinket) and SM6225 (khaje). Trinket does not support speed binning
(only a single SKU exists) and we don't yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allow for per-chip
frequency limiting.
Signed-o
On Mon, Feb 13, 2023 at 6:10 PM Dmitry Baryshkov
wrote:
>
> The rptr_addr is set in the preempt_init_ring(), which is called from
> a5xx_gpu_init(). It uses shadowptr() to set the address, however the
> shadow_iova is not yet initialized at that time. Move the rptr_addr
> setting to the a5xx_preem
On Mon, Feb 13, 2023 at 3:49 PM Arthur Grillo wrote:
>
> Turn global functions that are only used locally into static ones. This
> reduces the number of -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
The first hunk was already fixed, but I applied the second hunk.
Alex
> ---
>
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add function prototypes to headers to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h | 2 ++
> drivers/gpu/drm/amd/displ
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add function prototypes to headers to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 +
> 1 file changed, 1 insertion(+)
>
> d
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add includes that were previously missing to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c | 1 +
> drivers
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Remove arguments present on kernel-doc that are not present on the
> function declaration and add the new ones if present.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c| 15 +
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Make variables declaration inside ifdef guard, as they are only used
> inside the same ifdef guard. This remove some of the
> -Wunused-but-set-variable warning.
>
> Signed-off-by: Arthur Grillo
> ---
> .../gpu/drm/amd/di
On 2/14/2023 5:06 AM, Marijn Suijten wrote:
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
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 couple-weeks-long suffering of figuring out
the ins and outs of the "non-standard" A6xx GPUs whi
On Thu, 2023-02-09 at 16:42 -0800, Teres Alexis, Alan Previn wrote:
> 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.
>
> Be
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> In i915 we have this concept of "wait boosting" where we give a priority boost
> for instance to fences which are actively waited upon from userspace. This has
> it's pros and cons and can certainly be discussed at
On Tue, Feb 14, 2023 at 11:14 AM Rob Clark wrote:
>
> On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> wrote:
> >
> > From: Tvrtko Ursulin
> >
> > In i915 we have this concept of "wait boosting" where we give a priority
> > boost
> > for instance to fences which are actively waited upon from us
On 2/14/23 05:28, 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 11:10:16PM +0200, Ville Syrjala wrote:
Fro
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
>
>
>
> On 2/14/23 10:49, Sebastian Wick wrote:
> > 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 Tue, Feb 14, 2023 at 02:27:19PM -0500, Harry Wentland wrote:
>
>
> On 2/14/23 05:28, 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 Å
On 2/14/23 14:45, Sebastian Wick wrote:
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
On 2/14/23 10:49, Sebastian Wick wrote:
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ä w
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 2/14/23 10:49, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> > > wrote:
> > >>
> > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, H
Hi,
You seem to have sent this twice, perhaps to adjust the To/CC list. I
think I've picked the right one to reply to, but it's usually nice to
use a "v2" notation or otherwise put a comment somewhere in the email.
On Wed, Feb 08, 2023 at 12:44:06PM +0800, Kencp huang wrote:
> From: zain wang
>
Since, hot plugging eDP displays isn't supported, it is sufficient for
us to warn about the lack of a connected display once. So, use ASSERT()
in dce110_edp_wait_for_hpd_ready() instead of DC_LOG_WARNING().
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequence
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 2/14/23 10:49, Sebastian Wick wrote:
> > > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrj
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
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 2/
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
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 wh
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 PXP
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
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 which
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 non-priv
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 un
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:
1
1 - 100 of 130 matches
Mail list logo
