drm_connector_init_with_ddc() can fail, but the call in
drm_bridge_connector_init() does not check that. Fix this by adding
the missing error handling.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Move declaration of ret to its own line,
- Add Reviewed-by.
---
Add missing call to crtc reset helper to properly vblank reset.
Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
and remove duplicated code.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
vop_plane_destroy and vop_crtc_destroy are plain wrappers around
drm_plane_cleanup and drm_crtc_cleanup. Use them directly as plane and
crtc funcs to closer match VOP2 driver.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 +++-
1 file changed, 3 in
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Fixes: 604be855
struct rockchip_crtc_state members such as output_type, output_bpc and
enable_afbc is always reset to zero in the atomic_duplicate_state crtc
funcs.
Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
-20230619-duplicate-state
Jonas Karlman (4):
drm/rockchip: vop: Fix crtc duplicate state
drm/rockchip: vop: User cleanup helpers directly as destroy ops
drm/rockchip: vop2: Don't crash for invalid duplicate_state
drm/rockchip: vop2: Add missing call to crtc reset helper
drivers/gp
On Mon, 19 Jun 2023 14:29:23 +0200
Boris Brezillon wrote:
> On Mon, 19 Jun 2023 12:44:06 +0200
> Christian König wrote:
>
> > Am 19.06.23 um 12:12 schrieb Boris Brezillon:
> > > [SNIP]
> > > Note that the drm_exec_until_all_locked() helper I introduced is taking
> > > an expression, so in the
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole at
the moment.
Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
[SNIP]
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bbc721870c13..5ec8148a30ee 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm
On 6/15/23 23:19, Cyril Brulebois wrote:
Hi Rob,
Rob Herring (2023-06-15):
On Thu, Jun 15, 2023 at 03:21:07PM +0200, Michal Suchánek wrote:
At the time this was proposed it was said that "of-display", is wrong,
and that "of-display.0" must be used for the first device instead, and
if somethin
Hi Gerd,
>
> On Mon, May 15, 2023 at 10:04:42AM -0700, Mike Kravetz wrote:
> > On 05/12/23 16:29, Mike Kravetz wrote:
> > > On 05/12/23 14:26, James Houghton wrote:
> > > > On Fri, May 12, 2023 at 12:20 AM Junxiao Chang
> wrote:
> > > >
> > > > This alone doesn't fix mapcounting for PTE-mapped H
The module loads firmware so add a MODULE_FIRMWARE macro to provide that
information via modinfo.
Signed-off-by: Juerg Haefliger
Reviewed-by: Robert Foss
---
v2:
- Introduce FW_FILE macro
- Add Rob's r-b
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 +-
1 file changed, 5 insertions
The driver references some firmware files that don't have corresponding
MODULE_FIRMWARE macros and thus won't be listed via modinfo. Fix that.
Signed-off-by: Juerg Haefliger
---
v2:
- Drop addition and removal of zap files (needs more discussion)
- Add new a690_gmu.bin
- Update commit subj
On Fri, 16 Jun 2023 21:25:01 +0530
Akhil P Oommen wrote:
> On Fri, Jun 16, 2023 at 02:28:15PM +0200, Juerg Haefliger wrote:
> >
> > Add missing MODULE_FIRMWARE macros and remove some for firmwares that
> > the driver no longer references.
> >
> > Signed-off-by: Juerg Haefliger
> > ---
> > dri
Smatch error:
gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:316:49: error:
static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
Fixes: 1721bc1b2afa ("drm/amdgpu: Update VF2PF interface")
Signed-off-by: Su Hui
---
driv
On 6/20/23 13:07, Tatsuyuki Ishi wrote:
@@ -1296,9 +1271,8 @@ static int amdgpu_cs_submit(struct
amdgpu_cs_parser *p,
*/
r = 0;
amdgpu_bo_list_for_each_userptr_entry(e, p->bo_list) {
- struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
-
- r |= !amdgpu_ttm_tt_get
ping ?
On 2023/3/14 20:53, Sui Jingfeng wrote:
else is not generally useful after return
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
drivers/gpu/drm/drm_gem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm
+Boris and +Matthew in case you want to take over this patch set.
Here are some review / testing comments, including those I posted before
to ease tracking.
On 5/4/23 20:51, Christian König wrote:
Use the new component here as well and remove the old handling.
v2: drop dupplicate handling
S
Since this is feature is nouveau only currently and doesn't disturb
the current nouveau code paths, I'd like to try and get this work in
tree so other drivers can work from it.
If there are any major objections to this, I'm happy to pull it back
out again, but I'd like to get some acks/rb in the n
Hi,
On 2023/6/8 15:15, Paul Kocialkowski wrote:
Hi,
On Thu 08 Jun 23, 10:42, Sui Jingfeng wrote:
drm/logicvc driver is depend on REGMAP and REGMAP_MMIO, should select this
two kconfig option, otherwise the driver failed to compile on platform
without REGMAP_MMIO selected:
ERROR: modpost: "__d
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dcb0775d36de28992f56455ab3967b30d380]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base: dcb0775d36de28992
Hi,
On 2023/6/20 02:12, Limonciello, Mario wrote:
On 6/12/2023 2:25 PM, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI
display
device(pdev->class != 0x0300) out. T
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dcb0775d36de28992f56455ab3967b30d380]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base: dcb0775d36de28992
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/video/fbdev/hitfb.c
between commit:
bb47f218fd01 ("fbdev/hitfb: Cast I/O offset to address")
from the drm tree and commit:
dadeeffbe525 ("fbdev: hitfb: Use NULL for pointers")
from the fbdev tree.
I fixed it
Hi Donald,
forgot to add your email address to the patch series - sorry about that.
This series (v5) contains the Documentation changes you requested.
- Danilo
On 6/20/23 02:42, Danilo Krummrich wrote:
This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan fea
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and usersp
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the add
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that th
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job wo
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.
Signed-off-by: Danilo Krummric
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
Initialize the GEM's DRM GPU VA manager interface in preparation for the
(u)vmm implementation, provided by subsequent commits, to make use of it.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouve
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c |
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space ma
This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.
Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spac
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, allow userspace applications to request multiple and
arbitrary GPU VA mappings of buffe
Split up the MA_STATE() macro such that components using the maple tree
can easily inherit from struct ma_state and build custom tree walk
macros to hide their internals from users.
Example:
struct sample_iterator {
struct ma_state mas;
struct sample_mgr *mgr;
};
\#define SAMPLE_
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with auto
This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan features, such as sparse bindings and sparse residency.
Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
keep track of GPU virtual address (VA) mappings in a more generic way.
The
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 ++--
drivers/gpu/drm/msm/di
This function does nothing, just clears several data pointers. Drop it
now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
3 file
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
DPU performance module contains code to change performance state
calculations. In addition to normal (sum plane and CRTC requirements),
it can work in 'minimal' or 'fixed' modes. Both modes are impractical,
since they can easily end up with the display underruns. Userspace also
should not depend on
dpu_core_perf.c contains several multi-line conditions which are hard to
comprehent because of the indentation. Rework the identation of these
conditions to make it easier to understand them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 13 +
1
Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
full-featured catalog data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 52 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 +--
drivers/gpu/drm/msm/disp/dpu1/dp
Drop the leftover of bus-client -> interconnect conversion, the enum
dpu_core_perf_data_bus_id.
Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus
scaling")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 13 -
1 file changed
The max_per_pipe_ib is a constant across all CRTCs and is read from the
catalog. Drop corresponding calculations and read the value directly at
icc_set_bw() time.
Suggested-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +
Apply several cleanups to the DPU's core_perf module.
Dmitry Baryshkov (8):
drm/msm/dpu: drop enum dpu_core_perf_data_bus_id
drm/msm/dpu: drop performance tuning modes
drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib
drm/msm/dpu: rework indentation in dpu_core_perf
drm/msm/dpu: dr
On Mon, Jun 19, 2023 at 09:18:25PM +0100, Conor Dooley wrote:
> Hey,
>
> On Mon, Jun 19, 2023 at 06:55:23PM +0200, Dario Binacchi wrote:
> > Boards that use the STM32F{4,7} series have limited amounts of RAM. The
> > added property allows to size, within certain limits, the memory footprint
> > re
On 6/13/23 20:43, Gurchetan Singh wrote:
> We don't want to create a fence for every command submission. It's
> only necessary when userspace provides a waitable token for submission.
> This could be:
>
> 1) bo_handles, to be used with VIRTGPU_WAIT
> 2) out_fence_fd, to be used with dma_fence api
On 18/06/2023 17:54, zhumao...@208suo.com wrote:
Fix typo in comment of msm_gem.c.
Signed-off-by: Zhu Mao
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This patch doesn't apply. Please use git send-email to send patches.
--
With best wishes
Dm
On 14/06/2023 01:19, Kuogee Hsieh wrote:
ince struct drm_dsc_config is stored at atomic_enable() instead
of display setup time during boot up, saving struct drm_dsc_config
at struct msm_display_info is not necessary. Lets drop the dsc member
from struct msm_display_info.
With the 'S' in 'Since'
On 14/06/2023 01:19, Kuogee Hsieh wrote:
Currently struct drm_dsc_config for DSI is populated at display
setup during system boot up. This mechanism works fine with
embedded display but not for pluggable displays as the
struct drm_dsc_config will become stale once external display
is unplugged.
The INTF_SDM845_MASK features mask is zero. Drop it completely.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 4
drivers/
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 52 ++--
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 16 +
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 14
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 55 +
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 41 ++---
Use more standard initialisation for .clk_ctrls definitions. Define a
single .clk_ctrls field and use array init inside.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 22 +
.../msm/disp/
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 9 -
..
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 3 ---
driv
Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks.
This is done in preparation to expanding the rest of hardware block
defines, so that all blocks have similar indentation.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/
Drop useless zero assignments to the dpu_mdp_cfg::features field.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 -
drivers/gpu/
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 15 +++--
Drop useless zero assignments to the dpu_ctl_cfg::features field.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 3 ---
2 files
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 81
Since there is always just a single MDP_TOP instance, drop the enum
dpu_mdp and corresponding index value.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/ca
For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 2 +-
.../
There is always a single MDP TOP block. Drop the mdp_count field and
stop declaring dpu_mdp_cfg instances as arrays.
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 7 +---
..
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n
constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n
for DSI interfaces.
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_
Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration.
Reviewed-by: Abhinav Kumar
Reviewed-by: Marijn Suijten
Tested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/driv
Having a macro with 10 arguments doesn't seem like a good idea. It makes
it inherently harder to compare the actual structure values. Also this
leads to adding macros covering varieties of the block.
As it was previously discussed, inline all foo_BLK macros in order to
ease performing changes to t
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marijn)
- Added a pointer from dsi_timing_setup() docs to
dsi_adjus
On 16/06/2023 15:25, Marijn Suijten wrote:
On 2023-06-16 12:41:52, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 35 ++
Hi Geert,
Thank you for the patch.
On Mon, Jun 19, 2023 at 02:24:21PM +0200, Geert Uytterhoeven wrote:
> drm_connector_init_with_ddc() can fail, but the call in
> drm_bridge_connector_init() does not check that. Fix this by adding
> the missing error handling.
>
> Signed-off-by: Geert Uytterhoe
From: Fabio Estevam
The innolux at043tn24 display is a parallel LCD. Pass the 'connector_type'
information to avoid the following warning:
panel-simple panel: Specify missing connector_type
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertio
Hey,
On Mon, Jun 19, 2023 at 06:55:23PM +0200, Dario Binacchi wrote:
> Boards that use the STM32F{4,7} series have limited amounts of RAM. The
> added property allows to size, within certain limits, the memory footprint
> required by the framebuffer.
Hmm, this sounds quite a lot like "software po
On 6/12/2023 2:25 PM, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
On Mon, 19 Jun 2023 18:55:23 +0200, Dario Binacchi wrote:
> Boards that use the STM32F{4,7} series have limited amounts of RAM. The
> added property allows to size, within certain limits, the memory footprint
> required by the framebuffer.
>
> Signed-off-by: Dario Binacchi
> ---
>
> (no change
The patch, which is backwards compatible, sets the bit depth of the
framebuffer using the optional property 'st,fb-bpp' in the DTS.
Signed-off-by: Dario Binacchi
---
Changes in v4:
- Use DTS property instead of module parameter to set the framebuffer bit depth.
Changes in v3:
- drop [4/6] dt-b
Boards that use the STM32F{4,7} series have limited amounts of RAM. The
added property allows to size, within certain limits, the memory footprint
required by the framebuffer.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
.../devicetree/bindings/display/st,stm32-ltdc.yaml |
The series adds support for the display on the stm32f746-disco board,
along with a generic patch that adds the "bpp" parameter to the stm-drm
module. The intention is to allow users to size, within certain limits,
the memory footprint required by the framebuffer.
Changes in v4:
- Use DTS property
Change the order of region allocations to make the addresses match
downstream. This shouldn't matter very much, but helps eliminate one
more difference when comparing register accesses.
Also, make the log region 16K long. That's what it is, unconditionally
on A6xx and A7xx.
Signed-off-by: Konrad
The GMU force shutdown sequence involves some additional register cleanup
which was not implemented previously. Do so.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/driver
This series brings some niceties in preparation for A7xx introduction.
It should be fully independent of the GMU wrapper series.
Signed-off-by: Konrad Dybcio
---
Changes in v3:
- Pull more definitions from mesa
- Decode CP_PROTECT_CNTL bitfields
- Rebase on next-20230619
- Link to v2:
https
Some specific SKUs leave certain protection range registers empty.
Allow for that behavior.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/m
While it's not very well understood, there is some sort of a fault
handler implemented in the GMU firmware which triggers when a certain
bit is set, resulting in the M3 core not booting up the way we expect
it to.
Write a magic value to a magic register to hopefully prevent that
from happening.
S
We have the necessary information, so explain which bit does what.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index b
Add a definition of the GMU_AHB_FENCE_STATUS_CLR reg and CP_PROTECT_CNTL
bitfields.
This may be substituted with a mesa header sync.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_g
A very basic debugging rule when a device is connected for the first
time is to access a read-only register which contains known data in
order to ensure the communication protocol is properly working. This
driver lacked any read helper which is often a critical piece for
speeding-up bring-ups.
Add
The Sitronix datasheet explains BIT(1) of the RGBCTRL register as the
DOTCLK/PCLK edge used to sample the data lines:
“0” The data is input on the positive edge of DOTCLK
“1” The data is input on the negative edge of DOTCLK
IOW, this bit implies a falling edge and not a high state. Correc
This panel from Emerging Display Technologies Corporation features an
ST7789V2 LCD controller panel inside which is almost identical to what
the Sitronix panel driver supports.
In practice, the module physical size is specific, and experiments show
that the display will malfunction if any of the f
The Sitronix controller expects 9-bit words, provide this as default at
probe time rather than specifying this in each and every access.
Signed-off-by: Miquel Raynal
Reviewed-by: Sam Ravnborg
Acked-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 6 +-
1 file changed,
The ST7789V LCD controller supports regular SPI wiring, as well as no Rx
data line at all. The operating system needs to know whether it can read
registers from the device or not. Let's detail this specific design
possibility by bounding the spi-rx-bus-width property.
Signed-off-by: Miquel Raynal
Hello,
The aim of this series is to add support for the EDT ET028013DMA
panel. This panel features a Sitronix ST7789V2 LCD controller, which is
already supported mainline (or very close to the ST7789V for which
Maxime added support years ago).
The EDT panel is slightly different on the geometry a
The ST7789V LCD controller is also embedded in the ET028013DMA
panel. Add a compatible string to describe this other panel.
Signed-off-by: Miquel Raynal
Acked-by: Krzysztof Kozlowski
Acked-by: Maxime Ripard
---
.../devicetree/bindings/display/panel/sitronix,st7789v.yaml | 1 +
1 file chan
On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
> Sumitra Sharma wrote:
> > kmap() has been deprecated in favor of the kmap_local_page()
> > due to high cost, restricted mapping space, the overhead of a
> > global lock for synchronization, and making the process sleep
> > in the absence
ttm_bo_swapout() shadows the ttm operation context which may cause
major confusion in driver callbacks when swapping out !TTM_PL_SYSTEM
memory. Fix this by reusing the operation context argument to
ttm_bo_swapout().
Cc: "Christian König"
Cc:
Cc:
Signed-off-by: Thomas Hellström
Acked-by: Matthe
On 16/06/2023 09:36, Shuijing Li wrote:
For mt8188, add dsi cmdq reg control to send long packets to panel
initialization.
Signed-off-by: Shuijing Li
Signed-off-by: Jitao Shi
Reviewed-by: Matthias Brugger
---
Changes in v2:
use mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE_SEL, CMDQ_SIZE_
1 - 100 of 176 matches
Mail list logo
