On Tue, 31 Oct 2023 at 15:23, Dave Airlie wrote:
>
> On Tue, 31 Oct 2023 at 15:09, Borah, Chaitanya Kumar
> wrote:
> >
> > Hello Mario,
> >
> > This is Chaitanya from the Linux graphics team in Intel.
> >
> > We are seeing a build issue in drm-tip[1]
>
> Sorry that was a mismerge from me, let me
On Mon, Oct 30, 2023 at 07:17:48PM +0200, José Pekkarinen wrote:
> This patch addresses the following warning spotted by
> using coccinelle where the case checked does the same
> than the else case.
>
> drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10:
> WARNING:
On Tue, 31 Oct 2023 at 15:09, Borah, Chaitanya Kumar
wrote:
>
> Hello Mario,
>
> This is Chaitanya from the Linux graphics team in Intel.
>
> We are seeing a build issue in drm-tip[1]
Sorry that was a mismerge from me, let me go fix it for summon someone else.
Dave.
From: Dave Airlie
This original one was backwards, compared to traces from nvidia driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
From: Dave Airlie
The nvidia driver sets these two basic registry entries always,
so copy it.
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 45 ++-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git
From: Dave Airlie
This moves the initial effort to the latest 535 firmware.
The gsp msg structs have changed, and the message passing also.
The wpr also seems to have some struct changes.
This version of the firmware will be what we are stuck on for a while,
until we can refactor the driver
This moves Ben's work to the latest GSP stable firmware 535.113.01.
We will be stuck on this for a while.
There is also a fix for a message signature, and additions of two
registry entries, which seem to help recover from crashes.
Dave.
Hello Mario,
This is Chaitanya from the Linux graphics team in Intel.
We are seeing a build issue in drm-tip[1]
``
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL
In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In Xe the submission order from multiple drm_sched_entity is not
guaranteed to be the same
Add a helper whereby a driver can invoke TDR immediately.
v2:
- Drop timeout args, rename function, use mod delayed work (Luben)
v3:
- s/XE/Xe (Luben)
- present tense in commit message (Luben)
- Adjust comment for drm_sched_tdr_queue_imm (Luben)
v4:
- Adjust commit message (Luben)
Cc: Luben
Also add a lockdep assert to drm_sched_start_timeout.
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state which can merged in the near
future. More
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
v2:
- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
timestamp in free_job() work item (Danilo)
v3:
- Drop forward dec of
Add scheduler wqueue ready, stop, and start helpers to hide the
implementation details of the scheduler from the drivers.
v2:
- s/sched_wqueue/sched_wqueue (Luben)
- Remove the extra white line after the return-statement (Luben)
- update drm_sched_wqueue_ready comment (Luben)
Cc: Luben
On Mon, Oct 30, 2023 at 9:23 PM AngeloGioacchino Del Regno
wrote:
>
> Currently, the GPU is being internally powered off for runtime suspend
> and turned back on for runtime resume through commands sent to it, but
> note that the GPU doesn't need to be clocked during the poweroff state,
> hence
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sent to the
hardware.
This implies that for each job, drivers need to account for the maximum
If we skip RC6 init, residency registers do not get initialized,
leading to incorrect drpc debug output. Also release the wakeref
since we skip intel_rc6_enable() entirely when rc6_supported is false.
Fixes: 78d0b4552c37 ("drm/i915/gt: Use RC6 residency types as arguments to
residency
ase-commit: c503e3eec382ac708ee7adf874add37b77c5d312
change-id: 20231030-sc8280xp-dpu-safe-lut-9769027b8452
Best regards,
--
Bjorn Andersson
Hello,
We are a team of linux enthusiasts who are trying to boot Xen on a
Samsung XE303C12 Chromebook aka "snow"
following the suggestions in the slide show presentation here:
https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm
This device uses an
On 10/30/23 02:28, Dave Airlie wrote:
From: Dave Airlie
This converts a bunch of divides into the proper macros.
Signed-off-by: Dave Airlie
Reviewed-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 24 +---
1 file changed, 13 insertions(+), 11
On 10/30/23 02:28, Dave Airlie wrote:
From: Dave Airlie
This needs the proper division macros.
Signed-off-by: Dave Airlie
Reviewed-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.
Add the missing input-format negotiation hook in the
drm_bridge_funcs to complete
On 10/30/2023 12:23 AM, John Watts wrote:
Panel initialization registers are per-display and not tied to the
controller itself. Different panels will specify their own registers.
Attach the sequences to the panel info struct so future panels
can specify their own sequences.
Hi John,
On 10/27/2023 7:19 PM, Clayton Craft wrote:
This panel is found on laptops e.g., variants of the Thinkpad X13s.
Configuration was collected from the panel's EDID.
Hi Clayton,
Thanks for the patch -- it looks good to me aside from one minor comment
below.
Signed-off-by: Clayton Craft
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
In order to check whether the SSPP block has scaler and CSC subblocks
the funcion dpu_plane_atomic_check_pipe() uses macros which enumerate
all possible scaler and CSC features. Replace those checks with the
scaler and CSC subblock length checks
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +--
On 30-Oct-23 14:55, Jan Kiszka wrote:
> On 06.06.23 10:21, Aradhya Bhatia wrote:
>> With the new encoder/bridge chain model, the display controller driver
>> is required to create a drm_connector entity instead of asking the
>> bridge to do so during drm_bridge_attach. Moreover, the controller
On Mon, 30 Oct 2023 18:00:22 +0800, Moudy Ho wrote:
> Add a compatible string for the PADDING block in MediaTek MT8195 that
> is controlled by MDP3.
>
> Signed-off-by: Moudy Ho
> ---
> .../bindings/display/mediatek/mediatek,padding.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1
On Mon, Oct 30, 2023 at 06:00:09PM +0800, Moudy Ho wrote:
> Added the configuration for MT8195 RDMA. In comparison to MT8183, it
> no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.
>
> Signed-off-by: Moudy Ho
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
>
On Mon, Oct 30, 2023 at 06:00:08PM +0800, Moudy Ho wrote:
> To simplify maintenance and avoid branches, the identical component
> should be merged and placed in the path belonging to the MDP
> (from display/* to media/*).
>
> In addition, currently only MDP utilizes RDMA through CMDQ, and the
>
On Mon, Oct 30, 2023 at 9:01 AM Christian König
wrote:
>
> Am 30.10.23 um 14:38 schrieb Rob Clark:
> > On Mon, Oct 30, 2023 at 1:05 AM Christian König
> > wrote:
> >> Am 27.10.23 um 18:58 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> In cases where the # is known ahead of time, it is
From: Rob Clark
Just something I noticed in passing.
Signed-off-by: Rob Clark
---
include/drm/drm_gpuva_mgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_gpuva_mgr.h b/include/drm/drm_gpuva_mgr.h
index ed8d50200cc3..26a2c0880bac 100644
---
Hi Christian,
On Mon, Oct 30, 2023 at 08:38:45AM +0100, Christian König wrote:
> Hi Boris,
>
> Am 27.10.23 um 12:17 schrieb Boris Brezillon:
> > Hi Christian,
> >
> > On Fri, 27 Oct 2023 11:06:44 +0200
> > Christian König wrote:
> >
> > > Am 27.10.23 um 10:22 schrieb Boris Brezillon:
> > > >
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10:
WARNING: possible condition with no effect (if == else)
Fixes: 974ce181
On 2023-10-30 13:17, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10:
WARNING: possible condition with no
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10:
WARNING: possible condition with no effect (if == else)
Fixes: 974ce181
On 2023-10-30 15:52, Aurabindo Pillai wrote:
On 10/29/2023 8:44 AM, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
On 2023-10-30 12:26, José Pekkarinen wrote:
On 2023-10-30 15:52, Aurabindo Pillai wrote:
On 10/29/2023 8:44 AM, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
From: Yannick Fertre
Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.
Signed-off-by: Yannick Fertre
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 28 +++
1 file
This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.
First patch adds runtime PM functionality to the driver.
Second patch adds a clock provider generated by the PHY itself. As
explained in the commit log of the second patch, a
In RCC driver, 'DSI_K' is a kernel clock while 'DSI' has pclk4 as parent
clock, which means that it is an APB peripheral clock. Swap the clocks
in the DSI peripheral clock reference.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm/boot/dts/st/stm32mp157.dtsi | 2 +-
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0 |
|/
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not
Am 30.10.23 um 14:38 schrieb Rob Clark:
On Mon, Oct 30, 2023 at 1:05 AM Christian König
wrote:
Am 27.10.23 um 18:58 schrieb Rob Clark:
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Ah, yes that was my initial implementation as well,
Hi Sagar,
First of all, thanks for your patch.
On 10/25/23 08:04, Sagar Vashnav wrote:
Add kernel documentation for the dc_stream_forward_crc_window
Signed-off-by: Sagar Vashnav
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 13 +
1 file changed, 13 insertions(+)
diff --git
Add helpers drivers can use to calculate the BW allocation overhead -
due to SSC, FEC, DSC and data alignment on symbol cycles - and the
channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
128b/132b links the FEC overhead is part of the coding efficiency, so
not accounted for in
Add a quirk for Synaptics MST hubs, which require a workaround - at leat
on i915 - for some modes, on which the hub applies HBLANK expansion.
These modes will only work by enabling DSC decompression for them, a
follow-up patch will do this in i915.
v2:
- Fix the quirk name in its DocBook
Factor out a helper to check the atomic state for one MST topology
manager, returning the MST port where the BW limit check has failed.
This will be used in a follow-up patch by the i915 driver to improve the
BW sharing between MST streams.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Add the DPCD flag to enable DSC passthrough in a last branch device,
used in a follow-up i915 patch.
Also add a flag to detect HBLANK expansion support in a branch device,
used by a workaround in a follow-up i915 patch.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Stanislav
The Synaptics MST branch devices support DSC decompression on all their
output ports, provided that they are last branch devices (with their
output ports connected to the sinks). The Thinkpad 40B0 TBT dock for
instance has two such branch devices, a secondary one connected to one
of the output
drm_dp_mst_atomic_check_mgr() should check for BW limitation starting
from sink ports continuing towards the root port, so that drivers can
use the @failing_port returned to resolve a BW overallocation in an
ideal way. For instance from streams A,B,C in a topology A,B going
through @failing_port
Add drm_dp_mst_port_downstream_of_parent() required by the i915
driver in a follow-up patch to resolve a BW overallocation of MST
streams going through a given MST port.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul
Signed-off-by: Imre Deak
---
Am 28.10.23 um 02:48 schrieb Yuran Pereira:
Hello,
On Fri, Oct 27, 2023 at 11:57:45AM -0400, Hamza Mahfooz wrote:
On 10/27/23 11:55, Lakha, Bhawanpreet wrote:
[AMD Official Use Only - General]
There was a consensus to use memset instead of {0}. I remember making
changes related to that
On Mon, Oct 30, 2023 at 08:05:28AM -0600, Jeffrey Hugo wrote:
> On 10/28/2023 2:18 AM, Stanislaw Gruszka wrote:
> > On Fri, Oct 27, 2023 at 08:47:11AM -0600, Jeffrey Hugo wrote:
> > > On 10/25/2023 3:43 AM, Stanislaw Gruszka wrote:
> > > > From: Karol Wachowski
> > > >
> > > > Change meaning of
On 10/30/2023 11:49 AM, Aravind Iddamsetty wrote:
On 26/10/23 15:34, Lazar, Lijo wrote:
Hi Lijo,
Thank you for your comments.
On 10/23/2023 8:59 PM, Alex Deucher wrote:
On Fri, Oct 20, 2023 at 7:42 PM Aravind Iddamsetty
wrote:
Our hardware supports RAS(Reliability, Availability,
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
VPU was rebranded as NPU (Neural Processing Unit) so user facing
strings have to be updated but the code remains as is and the module
is still called intel_vpu.ko.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Stanislaw
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
CMD_SYNC does not need any args as we poll for completion anyway.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Previously using dma_alloc_wc() API we created cache coherent
(mapped as write-back) mappings.
Because we disable MMU600 snooping it was required to do costly
page walk and cache flushes after each page table modification.
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Add checking of error reason bits in IVPU_MMU_CMDQ_CONS
register when waiting for consumer timeout occurred.
Signed-off-by: Karol Wachowski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
Reviewed-by:
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
Waking up process, which wait for particular condition, will go to
sleep again on wake_up() if the condition is not met. Add abort flag
to wake up IPC receivers, which will finish with -ECANCELED error.
This is only needed for reset, run time
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
Stop job_done thread when going to suspend. Use kthread_park() instead
of kthread_stop() to avoid memory allocation and potential failure
on resume.
Use separate function as thread wake up condition. Use spin lock to assure
rx_msg_list is properly
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
We should not leave device half enabled if there is failure somewhere
it power up sequence. Fix device init and resume paths.
Reviewed-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
On 30/10/2023 13:22, AngeloGioacchino Del Regno wrote:
> Some platforms/SoCs can power off the GPU entirely by completely cutting
> off power, greatly enhancing battery time during system suspend: add a
> new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
> during full suspend
On 30/10/2023 13:22, AngeloGioacchino Del Regno wrote:
> Currently, the GPU is being internally powered off for runtime suspend
> and turned back on for runtime resume through commands sent to it, but
> note that the GPU doesn't need to be clocked during the poweroff state,
> hence it is possible
On Mon, Oct 30, 2023 at 10:39:32PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 2023/10/30 21:39, Maxime Ripard wrote:
> > On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
> > > I think my approach provide a solution, while still keep the bridges
> > > drivers
> > > to a modular at
On 10/28/2023 9:59 AM, Stanislaw Gruszka wrote:
From: Krystian Pradzynski
Profiling freq is a debug firmware feature. It switches default clock
to higher resolution for fine-grained and more accurate firmware task
profiling. We already configure it during boot up of VPU4.
Add debugfs knob and
On 24/10/23 23:41, Bragatheswaran Manickavel wrote:
The member variable enable_hpo_pg_support is already initialized
and hence the reinitialization instruction can be removed. Issue
identified using the doubleinit.cocci Coccinelle semantic patch script.
Signed-off-by: Bragatheswaran
On 30/10/2023 09:28, Iago Toral Quiroga wrote:
> BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
> compatible to the bindings.
>
> v2: new, requested by Stefan Wahren.
>
> Signed-off-by: Iago Toral Quiroga
Please use scripts/get_maintainers.pl to get a list of
Hi,
On 2023/10/30 21:39, Maxime Ripard wrote:
On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
I think my approach provide a solution, while still keep the bridges drivers
to a modular at the same time. Despite simple, it indeed solve the problem.
It simple because of explicit
On 10/28/2023 7:34 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
Currently the VPU firmware prepares for D0i3 every time the VPU
is entering D0i2 Idle state. This is not optimal as we might not
enter D0i3 every time we enter D0i2 Idle and this preparation
is quite costly.
This
On 10/28/2023 7:34 AM, Stanislaw Gruszka wrote:
Print warning if VPUIP is not idle during power down.
Use warn log level also when we fail to enter reset state
as this is not really an error but unexpected behavior.
Reviewed-by: Krystian Pradzynski
Signed-off-by: Stanislaw Gruszka
On 10/28/2023 7:34 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Split ivpu_ipc_send_receive() implementation to have a version
that does not call pm_runtime_resume_and_get(). That implementation
can be invoked when device is up and runtime resume is prohibited
(for example at the end of
On 10/28/2023 7:34 AM, Stanislaw Gruszka wrote:
From: Krystian Pradzynski
Bump boot API to 4.20
Bump JSM API to 3.15
Signed-off-by: Krystian Pradzynski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
On 10/28/2023 1:59 AM, Stanislaw Gruszka wrote:
Hi
On Fri, Oct 27, 2023 at 08:37:39AM -0600, Jeffrey Hugo wrote:
On 10/25/2023 3:43 AM, Stanislaw Gruszka wrote:
From: Krystian Pradzynski
Bump boot API to 4.20
Bump JSM API to 3.15
Signed-off-by: Krystian Pradzynski
Reviewed-by: Stanislaw
Hi,
On 2023/10/30 21:48, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 15:26, Sui Jingfeng wrote:
Hi,
On 2023/10/30 18:01, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 11:42, Sui Jingfeng wrote:
Hi,
On 2023/10/30 06:53, Dmitry Baryshkov wrote:
On Sun, 29 Oct 2023 at 21:46, Sui
On 10/28/2023 2:18 AM, Stanislaw Gruszka wrote:
On Fri, Oct 27, 2023 at 08:47:11AM -0600, Jeffrey Hugo wrote:
On 10/25/2023 3:43 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Change meaning of test_mode module parameter from integer value
to bitmask allowing setting different test
On 10/29/2023 5:39 AM, José Pekkarinen wrote:
Spotted by coccicheck, there is a redundant check for
v->SourcePixelFormat[k] != dm_444_16. This patch will
remove it. The corresponding output follows.
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c:5130:86-122: duplicated
On 10/29/2023 8:44 AM, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-10:
WARNING: possible condition with no
On Mon, 30 Oct 2023 at 15:26, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/10/30 18:01, Dmitry Baryshkov wrote:
> > On Mon, 30 Oct 2023 at 11:42, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> On 2023/10/30 06:53, Dmitry Baryshkov wrote:
> >>> On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng
> >>> wrote:
On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
> I think my approach provide a solution, while still keep the bridges drivers
> to a modular at the same time. Despite simple, it indeed solve the problem.
> It simple because of explicit control of the loading order by myself, not by
On Mon, Oct 30, 2023 at 1:05 AM Christian König
wrote:
>
> Am 27.10.23 um 18:58 schrieb Rob Clark:
> > From: Rob Clark
> >
> > In cases where the # is known ahead of time, it is silly to do the table
> > resize dance.
>
> Ah, yes that was my initial implementation as well, but I ditched that
>
On Thu, 19 Oct 2023 17:21:21 -0400
Harry Wentland wrote:
> When the floor LUT index (drm_fixp2int(lut_index) is the last
> index of the array the ceil LUT index will point to an entry
> beyond the array. Make sure we guard against it and use the
> value of the floot LUT index.
>
> Blurb about
Hi,
On 2023/10/30 18:01, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 11:42, Sui Jingfeng wrote:
Hi,
On 2023/10/30 06:53, Dmitry Baryshkov wrote:
On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this
chip to
Some platforms/SoCs can power off the GPU entirely by completely cutting
off power, greatly enhancing battery time during system suspend: add a
new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
during full suspend only on selected platforms.
Signed-off-by: AngeloGioacchino
All of the MediaTek SoCs supported by Panfrost can completely cut power
to the GPU during full system sleep without any user-noticeable delay
in the resume operation, as shown by measurements taken on multiple
MediaTek SoCs.
As an example, for MT8195 - a "before" with only runtime PM operations
All of the MediaTek SoCs supported by Panfrost can switch the clocks
off and on during system sleep to save some power without any user
experience penalty.
Measurements taken on multiple MediaTek SoCs show that adding this
will not prolong the time that is required to resume the system in
any
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it, but
note that the GPU doesn't need to be clocked during the poweroff state,
hence it is possible to save some power on selected platforms.
Add suspend and
At least MediaTek platforms are able to get the GPU clocks and regulators
completely off during system suspend, allowing to save a bit of power.
Panfrost is used on more than just MediaTek SoCs and the benefits of this
can be variable across different SoC models and/or different SoCs from
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 1 new issues were detected and 0 were fixed.
In total, 15 issues are still open and 30 have
On 27/10/2023 18:38, Tvrtko Ursulin wrote:
On 27/10/2023 18:28, Harshit Mogalapalli wrote:
When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.
As returning -ENOTSUPP is pretty clear return when perf interface is not
available.
Fixes: 2fec539112e8
Hi Iago,
On 10/30/23 09:20, Iago Toral wrote:
El mar, 24-10-2023 a las 07:05 -0300, Maira Canal escribió:
Hi Iago,
On 10/24/23 02:57, Iago Toral wrote:
El lun, 23-10-2023 a las 07:58 -0300, Maíra Canal escribió:
Currently, we are only warning the user if the BIN or RENDER jobs
don't
finish
Hi Iago,
The whole series is:
Reviewed-by: Maíra Canal
You can add my r-b in the next version (adding the DTS maintainers in
CC).
Best Regards,
- Maíra
On 10/30/23 05:28, Iago Toral Quiroga wrote:
This series includes patches to update the V3D kernel module
that drives the VideoCore VI GPU
On Mon, 30 Oct 2023 at 12:36, Neil Armstrong wrote:
>
> Add DPU version 10.0 support for the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Dmitry Baryshkov
> ---
> .../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h| 457
> +
>
El mar, 24-10-2023 a las 07:05 -0300, Maira Canal escribió:
> Hi Iago,
>
> On 10/24/23 02:57, Iago Toral wrote:
> > El lun, 23-10-2023 a las 07:58 -0300, Maíra Canal escribió:
> > > Currently, we are only warning the user if the BIN or RENDER jobs
> > > don't
> > > finish before we unregister
On Mon, 30 Oct 2023 at 12:27, Simon Ser wrote:
>
> On Monday, October 30th, 2023 at 11:22, Dmitry Baryshkov
> wrote:
>
> > On Mon, 30 Oct 2023 at 12:13, Simon Ser cont...@emersion.fr wrote:
> >
> > > On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> > > dmitry.barysh...@linaro.org
Hi Iago,
Am 30.10.23 um 11:18 schrieb Iago Toral:
El lun, 30-10-2023 a las 10:57 +0100, Stefan Wahren escribió:
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its
specific
compatible to the bindings.
v2: new, requested by
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
compatible to the bindings.
v2: new, requested by Stefan Wahren.
Thanks for sending this but the line above belongs below --- since it's
not relevant after the
On 06.06.23 10:21, Aradhya Bhatia wrote:
> With the new encoder/bridge chain model, the display controller driver
> is required to create a drm_connector entity instead of asking the
> bridge to do so during drm_bridge_attach. Moreover, the controller
> driver should create a drm_bridge entity to
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
This patch updates a number of register addresses that have
been changed in Raspberry Pi 5 (V3D 7.1) and updates the
code to use the corresponding registers and addresses based
on the actual V3D version.
v2:
- added s-o-b and commit
1 - 100 of 189 matches
Mail list logo
