On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >> dither block should be present on many other chipsets too but looks like
> >> on sm8550 was enabling it. Not sure how it was validated there. But we
> >> are enabling dither, even other chipsets have this block.
> >
> > Correct, they all seem to h
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
Reviewed
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 3b85b9b39960c08f29fa91b8d984d055dde6017e Add linux-next specific
files for 20230424
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com
https
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:24PM +0100, Biju Das wrote:
> Add my self as maintainer for RZ DU drivers.
> While at it, update the entries for rcar-du and shmobile.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v8:
> * New patch
> ---
>
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:22PM +0100, Biju Das wrote:
> Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
> SoC and therefore use RZ/G2L fallback to avoid any driver changes.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
Review
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:21PM +0100, Biju Das wrote:
> The RZ/G2L LCD controller is composed of Frame Compression Processor
> (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
>
> The DU module supports the following hardware features
> − Displ
The allocated memory for qdev->dumb_heads should be released
in qxl_destroy_monitors_object before qxl suspend.
otherwise,qxl_create_monitors_object will be called to
reallocate memory for qdev->dumb_heads after qxl resume,
it will cause memory leak.
Signed-off-by: Zongmin Zhou
---
drivers/gpu/dr
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Change lm blocks pairs so that lm blocks with the same features are
paired together:
LM_0 and LM_1 with PP and DSPP
LM_2 and LM_5 with PP
LM_3 and LM_4
This matches the sdm845 configuration and allows using pp or dspp when 2
lm blocks are needed in th
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable pre
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them an
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
Revi
On 4/24/2023 3:25 PM, Marijn Suijten wrote:
On 2023-04-24 13:44:55, Abhinav Kumar wrote:
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x
On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
wrote:
On 2023-04-21 16:25:15, Abhinav Kumar wrote:
On 4/21/2023 1:53 PM, Marijn Suijten wrote:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their
On 4/24/2023 3:30 PM, Marijn Suijten wrote:
On 2023-04-24 13:53:13, Abhinav Kumar wrote:
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to
On Mon, Apr 24, 2023 at 10:01:13AM -0700, Lucas De Marchi wrote:
> On Mon, Apr 24, 2023 at 03:44:18PM +1000, Dave Airlie wrote:
> > On Fri, 21 Apr 2023 at 05:09, Lucas De Marchi
> > wrote:
> > >
> > > On Wed, Apr 19, 2023 at 02:36:52PM +1000, Dave Airlie wrote:
> > > >From: Dave Airlie
> > > >
On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
wrote:
>
> On 2023-04-21 16:25:15, Abhinav Kumar wrote:
> >
> >
> > On 4/21/2023 1:53 PM, Marijn Suijten wrote:
> > > The Resource Manager already iterates over all available blocks from the
> > > catalog, only to pass their ID to a dpu_hw_xxx_init() fu
On 2023-04-24 13:53:13, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > SM8550 only comes with a DITHER subblock inside the PINGPONG block,
> > hence the name and a block length of zero. However, the PP_BLK macro
> > name was typo'd to DIPHER rather than DITHER.
> >
>
On Tue, Mar 28, 2023 at 6:23 PM Won Chung wrote:
>
> Create a symlink pointing to USB Type-C connector for DRM connectors
> when they are created. The link will be created only if the firmware is
> able to describe the connection beween the two connectors.
>
> Currently, even if a display uses a U
On 2023-04-24 13:44:55, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > These offsets do not fall under the MDP TOP block and do not fit the
> > comment right above. Move them to dpu_hw_interrupts.c next to the
> > repsective MDP_INTF_x_OFF interrupt block offsets.
> >
On 2023-04-24 13:41:07, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
> > offset downstream. Even though neither downstream nor upstream utilizes
> > these registers in any way, remove the erroneous
Track every intel_gt_pm_get() until its corresponding release in
intel_gt_pm_put() by returning a cookie to the caller for acquire that
must be passed by on released. When there is an imbalance, we can see who
either tried to free a stale wakeref, or who forgot to free theirs.
Signed-off-by: Andrz
Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.
Signed-off-by: Andrzej Hajda
---
drivers/gp
Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 8 +++
lib/ref_tracker.c | 56 +++
Wakeref has dedicated type. Assumption it will be int
compatible forever is incorrect.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_
In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following changes have been made:
- reports are printed per stack_handle - log is more compact,
- added display name
Library can handle allocation failures. To avoid allocation warnings
__GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
replaced with GFP_NOWAIT in case of stack allocation on tracker free
call.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
To have reliable detection of leaks, caller must be able to check under
the same lock both: tracked counter and the leaks. dir.lock is natural
candidate for such lock and unlocked print helper can be called with this
lock taken.
As a bonus we can reuse this helper in ref_tracker_dir_exit.
Signed-o
This is revived patchset improving ref_tracker library and converting
i915 internal tracker to ref_tracker.
The old thread ended without consensus about small kernel allocations,
which are performed under spinlock.
I have tried to solve the problem by splitting the calls, but it results
in complica
On 2023-04-21 16:25:15, Abhinav Kumar wrote:
>
>
> On 4/21/2023 1:53 PM, Marijn Suijten wrote:
> > The Resource Manager already iterates over all available blocks from the
> > catalog, only to pass their ID to a dpu_hw_xxx_init() function which
> > uses an _xxx_offset() helper to search for and f
On 4/18/23 10:05, Maíra Canal wrote:
Currently, the pixel conversion functions repeat the same loop to
iterate the rows. Instead of repeating the same code for each pixel
format, create a function to wrap the loop and isolate the pixel
conversion functionality.
Suggested-by: Arthur Grillo
Signe
On Wed, Apr 19, 2023 at 9:33 AM Florian Fainelli wrote:
>
> On 4/18/23 23:35, Heiner Kallweit wrote:
> > On 19.04.2023 02:10, Justin Chen wrote:
> >> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> >> introduced with 72165. This controller features two distinct Ethernet
>
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signe
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed
On Fri, Apr 21, 2023 at 3:13 PM Nathan Chancellor wrote:
>
> On Fri, Apr 14, 2023 at 06:07:46PM +0200, Guillaume Ranquet wrote:
> > The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
> > by the kernel test robot.
> >
> > Fix the issue by removing the variable altogether and t
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent con
On 4/17/23 17:41, Christophe JAILLET wrote:
It is likely p1_min_meta_chunk_bytes was expected here, instead of
min_meta_chunk_bytes.
Test the correct variable.
Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
Signed-off-by: Christophe JAILLET
Applied, thanks!
---
.../gp
On 4/17/23 17:35, Christophe JAILLET wrote:
It is likely Height was expected here, instead of Width.
Test the correct variable.
Fixes: 17529ea2acfa ("drm/amd/display: Optimizations for DML math")
Signed-off-by: Christophe JAILLET
Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/dml/dc
On 4/18/23 20:01, Arthur Grillo wrote:
This patchset seeks to add unit tests for the rest of the functions on
the drm_rect.c.
The test coverage report generated by the gcov[1] tool states that this
set reaches 100% of coverage on the drm_rect.c file. This would be
very good for future developmen
On 2023-04-16 23:43:20, Yang, Fei wrote:
> > fei.y...@intel.com kirjoitti 17.4.2023 klo 9.24:
> >> From: Fei Yang
> >>
> >> The series includes patches needed to enable MTL.
> >> Also add new extension for GEM_CREATE uAPI to let user space set cache
> >> policy for buffer objects.
> >
> > if I'm
> On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
>>> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> PTE encode functions are platform dependent. This patch implemen
On Wed, Apr 19, 2023 at 2:22 PM Dmitry Osipenko
wrote:
>
> Hello Gurchetan,
>
> On 4/18/23 02:17, Gurchetan Singh wrote:
> > On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko <
> > dmitry.osipe...@collabora.com> wrote:
> >
> >> We have multiple Vulkan context types that are awaiting for the addition
Hi Biju,
On Mon, Apr 24, 2023 at 05:10:23PM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to suppo
Hi Maxime,
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely ca
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache lin
From: Fei Yang
Extract PTE patch from https://patchwork.freedesktop.org/series/116868/
to fix MTL boot issue caused by MOCS/PAT update.
v2: address comment from Matt.
Fei Yang (2):
drm/i915/mtl: Add PTE encode function
drm/i915/mtl: workaround coherency issue for Media
drivers/gpu/drm/i91
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS
On 4/24/23 11:14, Justin Chen wrote:
On Fri, Apr 21, 2023 at 12:29 AM Krzysztof Kozlowski
wrote:
On 19/04/2023 02:10, Justin Chen wrote:
From: Florian Fainelli
Add a binding document for the Broadcom ASP 2.0 Ethernet
controller.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
On Fri, Apr 21, 2023 at 12:29 AM Krzysztof Kozlowski
wrote:
>
> On 19/04/2023 02:10, Justin Chen wrote:
> > From: Florian Fainelli
> >
> > Add a binding document for the Broadcom ASP 2.0 Ethernet
> > controller.
> >
> > Signed-off-by: Florian Fainelli
> > Signed-off-by: Justin Chen
> > ---
> >
On 4/24/23 10:02 AM, Hamza Mahfooz wrote:
On 4/20/23 09:59, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:
In function ‘dc_dmub_srv_optimized_init_done’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:26:
error: variable ‘dmub’ se
On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
> > On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> >>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> PTE encode functions are platform dependent. This patch implements
On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
>
> Being able to "list" supported extensions sounds like a reasonable
> principle, albeit a departure from the design direction to date.
> Which means there are probably no quick solutions. Also, AFAIU, only
> PXP context create is the problematic one
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:20PM +0100, Biju Das wrote:
> Create vendor specific renesas directory and move renesas drivers
> to that directory.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> MAINTAINERS
On Mon, Apr 24, 2023 at 03:44:18PM +1000, Dave Airlie wrote:
On Fri, 21 Apr 2023 at 05:09, Lucas De Marchi wrote:
On Wed, Apr 19, 2023 at 02:36:52PM +1000, Dave Airlie wrote:
>From: Dave Airlie
>
>This adds a tag that will go into the module info, only one firmware from
>the group given needs
On 4/20/23 09:59, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:
In function ‘dc_dmub_srv_optimized_init_done’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:26:
error: variable ‘dmub’ set but not used [-Werror=unused-but-set-varia
On 4/21/2023 4:22 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:16, Kuogee Hsieh wrote:
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmit
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache lin
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS
From: Fei Yang
Extract PTE patch from https://patchwork.freedesktop.org/series/116868/
to fix MTL boot issue caused by MOCS/PAT update.
Fei Yang (2):
drm/i915/mtl: Add PTE encode function
drm/i915/mtl: workaround coherency issue for Media
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
Soft resets are fatal just as hard resets, but no reset is "always fatal".
There are cases when apps keep working depending on which features are
being used. It's still unsafe.
Marek
On Mon, Apr 24, 2023, 03:03 Christian König
wrote:
> Am 24.04.23 um 03:43 schrieb André Almeida:
> > When a DRM
Quoting Biju Das (2023-04-24 17:10:20)
> Create vendor specific renesas directory and move renesas drivers
> to that directory.
>
> Signed-off-by: Biju Das
Acked-by: Kieran Bingham
On 4/20/23 09:21, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:
In function ‘dmub_abm_set_event_ex’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:22: error: variable
‘feature_support’ set but not used [-Werror=unused-but-set-va
Hi Thomas,
First bad commit (maybe != root cause):
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 70102d77ff22dd88a0111b1c3bac5099ac5d0425
commit: 7470849745e6cd746ae773a6e59b309867310181 [11/19] video: Move HP PARISC
STI core code to shared location
config: parisc-rand
On 4/24/2023 6:09 PM, Andi Shyti wrote:
Hi,
The two patches reverted in this series are, together, preventing
MTL from booting.
Revert them until the fix is deployed.
Andi
Andi Shyti (2):
Revert "drm/i915/mtl: fix mocs selftest"
Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt_reg
Hi,
The two patches reverted in this series are, together, preventing
MTL from booting.
Revert them until the fix is deployed.
Andi
Andi Shyti (2):
Revert "drm/i915/mtl: fix mocs selftest"
Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL"
drivers/gpu/drm/i915/gt/intel_gt_regs.h |
Add my self as maintainer for RZ DU drivers.
While at it, update the entries for rcar-du and shmobile.
Signed-off-by: Biju Das
---
v8:
* New patch
---
MAINTAINERS | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1218a2ec6d97..42d
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
---
v7->v8:
* Fixed the typo vsp2->du
* Added Rb tag from Rob as the change is trivial.
v7:
* New patch.
---
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU mo
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timi
Create vendor specific renesas directory and move renesas drivers
to that directory.
Signed-off-by: Biju Das
---
MAINTAINERS | 3 +--
drivers/gpu/drm/Kconfig | 4 +---
drivers/gpu/drm/Makefile
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +-
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from DSI is connected to ADV7535.
Created a vendor specific directory
On 4/20/23 14:07, Tom Rix wrote:
clang with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:1003:15:
error: variable 'dispclk_delay_subtotal' set but not used
[-Werror,-Wunused-but-set-variable]
unsigned int dispclk_delay_subtotal;
On 4/24/23 15:26, André Almeida wrote:
>>
>> Additional to that I currently didn't considered soft-recovered submissions
>> as fatal and continue accepting submissions from that context, but already
>> wanted to talk with Marek about that behavior.
>>
>
> Interesting. I will try to test and vali
On Sun, Apr 23, 2023 at 10:24 PM Kees Cook wrote:
>
> On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> wrote:
> >Kees,
> > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> >in the process I got gcc-13 which is not WERROR-clean because we only
> >limited the 'array-bounds
On Wed, Mar 22, 2023 at 10:40 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 2/4/23 12:43, Kees Cook wrote:
> > More arrays (and arguments) for dcpd were set to 16, when it looks like
> > DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen
> > with GCC 13:
> >
> > ../drivers/gpu/drm/
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data coherency
> of
On Mon, Apr 24, 2023 at 3:07 AM Christian König
wrote:
>
> Am 24.04.23 um 07:59 schrieb Sukrut Bellary:
> > smatch warning - inconsistent handling of buffer object reserve
> > and unreserve.
> >
> > Signed-off-by: Sukrut Bellary
>
> For now that patch is Reviewed-by: Christian König
> .
Applied.
Hi Jani,
> >> just another "Friday patch". While reviewing some patches from
> >> Tejas I found a bit confusing the use of dev_priv__ inside the
> >> for_each_engine(), perhaps it should be moved inside the gt/?
> >>
> >> As I was at it I made the /dev_priv/i915/ change which is still
> >> harmle
Hi Konrad,
On 18.04.23 15:10, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects..
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
--- /dev/null
+++ b/drivers/gpu/drm/loongson/lsdc_debugfs.c
+void lsdc_debugfs_init(struct drm_minor *minor)
+{
+#ifdef CONFIG_DEBUG_FS
+ drm_debugfs_create_files(lsdc_debugfs_list,
+ARRAY_SIZE(lsdc_debugfs_list),
+
Hi Mark (and Dmitry)
On Fri, 21 Apr 2023 at 18:07, Dmitry Baryshkov
wrote:
>
> On 21/04/2023 19:27, Mark Yacoub wrote:
> > From: Mark Yacoub
>
> Nit: is there a reason for this header? My first impression is that it
> matches your outgoing name & email address and as such is not necessary.
>
> N
On 24.04.23 14:35, Janusz Krzysztofik wrote:
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects usin
smatch warning - inconsistent handling of buffer object reserve
and unreserve.
Signed-off-by: Sukrut Bellary
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8
two separate pipeline:crtc->encoder->bridge->connector->panel
Jagan Teki 于2023年4月23日周日 19:10写道:
> + Bridge Maintainers
>
> On Wed, Apr 19, 2023 at 8:35 AM 余治国 wrote:
> >
> > The log looks like this:
> > [ 31.723823] Internal error: Oops: 9604 [#1] SMP\013 \010
> > [ 31.729030] Modules linke
Hi Christian, thank you for your comments.
Em 24/04/2023 04:03, Christian König escreveu:
Am 24.04.23 um 03:43 schrieb André Almeida:
When a DRM job timeout, the GPU is probably hang and amdgpu have some
ways to deal with that, ranging from soft recoveries to full device
reset. Anyway, when use
On Mon, Apr 24, 2023 at 4:50 AM Adam Ford wrote:
>
> On Mon, Apr 24, 2023 at 4:47 AM Marek Szyprowski
> wrote:
> >
> > On 24.04.2023 11:44, Chen-Yu Tsai wrote:
> > > On Mon, Apr 24, 2023 at 5:31 PM Adam Ford wrote:
> > >> On Mon, Apr 24, 2023 at 1:12 AM Chen-Yu Tsai wrote:
> > >>> On Sun, Apr 2
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects using hardware CRC checksums calculated by
display
During device bringup it might be that we can't access the debugfs files.
Return -ENODEV until the registration is completed on access.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_debugfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/driv
Instead of the per minor directories only create a single debugfs
directory for the whole device directly when the device is initialized.
For DRM devices each minor gets a symlink to the per device directory
for now until we can be sure that this isn't useful any more in any way.
Accel devices cr
Use managed memory allocation for this. That allows us to not keep
track of all the files any more.
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 2 -
drivers/gpu/drm/drm_debugfs.c | 75 +-
drivers/gpu/drm/drm_drv.c | 2 -
drivers/gpu
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
Completely drop that approach and just create the files directly but
return -ENODEV while opening the file whe
We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those in the mid layer callback.
v2: drop it for the accel node as well
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 3 ---
drivers/gpu/drm/drm_debugfs.c | 2 +-
2 fil
Am 17.04.23 um 12:26 schrieb Stanislaw Gruszka:
On Mon, Apr 17, 2023 at 09:18:31AM +0200, Christian König wrote:
Am 16.04.23 um 18:03 schrieb Tomer Tayar:
On 12/04/2023 17:52, Christian König wrote:
/**
- * accel_debugfs_init() - Initialize debugfs for accel minor
+ * accel_debugfs_ini
Hi Lukas,
Lukas Bulwahn writes:
> Dear Michael, dear Harry, dear Alex,
>
> The commit 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
> renames config DRM_AMD_DC_DCN to config DRM_AMD_DC_FP. The concurrent
> commit 78f0929884d4 ("powerpc/64: Always build with 128-bit long
> double") ove
On 8/12/22 17:57, Maíra Canal wrote:
This driver includes the deprecated OF GPIO header
yet fail to use symbols from it, so drop the include.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Maíra Canal
Applie
On 8/12/22 17:57, Maíra Canal wrote:
This driver includes the deprecated OF GPIO header
yet fail to use symbols from it, so drop this include.
Cc: Alain Volmat
Signed-off-by: Maíra Canal
Applied to drm/drm-misc (drm-misc-next).
Best Regards,
- Maíra Canal
---
drivers/gpu/drm/sti/sti_dv
On Sun, 23 Apr 2023, Andi Shyti wrote:
> Hi,
>
> On Fri, Apr 21, 2023 at 03:46:52PM +0200, Andi Shyti wrote:
>> Hi,
>>
>> just another "Friday patch". While reviewing some patches from
>> Tejas I found a bit confusing the use of dev_priv__ inside the
>> for_each_engine(), perhaps it should be mov
1 - 100 of 126 matches
Mail list logo