On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
>
> 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 pu
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
>
On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > Hello Maxime,
> >
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > >
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On
It would be better to replace the traditional ternary conditional operator with
max()
Signed-off-by: Li Dong
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02 PM Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Jun 19, 2023 at 1
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > >
The led_access lock must be held when calling led_sysfs_enable() and
led_sysfs_disable(). This fixes warnings such as this:
[2.432495] [ cut here ]
[2.437316] WARNING: CPU: 0 PID: 22 at drivers/leds/led-core.c:349
led_sysfs_disable+0x54/0x58
[2.446105] Modules
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > On Sun, Ju
Use zero as the return value instead of the unused variable ret
Signed-off-by: Li Dong
---
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6d7
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > inte
On Tue, 20 Jun 2023 at 17:06, Oded Gabbay wrote:
>
> On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
> >
> > 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.
Hi Konrad,
kernel test robot noticed the following build errors:
[auto build test ERROR on 47045630bc409ce6606d97b790895210dd1d517d]
url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/drm-msm-a6xx-Add-some-missing-header-definitions/20230620-004639
base
Am 20.06.23 um 08:47 schrieb Boris Brezillon:
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
On Tue, Jun 20, 2023 at 10:13 AM Dave Airlie wrote:
>
> On Tue, 20 Jun 2023 at 17:06, Oded Gabbay wrote:
> >
> > On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
> > >
> > > Since this is feature is nouveau only currently and doesn't disturb
> > > the current nouveau code paths, I'd like to tr
On Tue, Jun 20, 2023 at 12:59:19PM +0800, Su Hui wrote:
> 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"
>
I doubt that moving the
On Tue, Jun 20, 2023 at 10:37:59AM +0300, Dan Carpenter wrote:
> "Mark the associated types properly packed individually, rather than
> use the disgusting "pragma pack()" that should never be used."
>
> https://lore.kernel.org/linux-sparse/CAHk-=wi7jgz+bvbt-ufxokpeqdhzf3z2hbjkgdjh8q4dvpp...@mail.g
On 2023/6/20 15:37, Dan Carpenter wrote:
On Tue, Jun 20, 2023 at 12:59:19PM +0800, Su Hui wrote:
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 mus
Set drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle()
for all DRM drivers. Even drivers that do not support PRIME import
or export of dma-bufs can now import their own buffer objects. This
is required by some userspace, such as wlroots-based compositors, to
share buffers among processes
Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd().
Both are only used internally within the PRIME code.
v2:
* reword docs as functions are now unexported (Simon)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Simon Ser
Acked-by: Alex Deucher
---
drivers/gpu/drm/drm
Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by
default if no PRIME import/export helpers have been set. Both functions
are the default for almost all drivers.
DRM drivers implement struct drm_driver.gem_prime_import_sg_table
to import dma-buf objects from other drivers. Havi
Clear all assignments of struct drm_driver's fd/handle callbacks to
drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These
functions are called by default. Add a TODO item to convert vmwgfx
to the defaults as well.
v2:
* remove TODO item (Zack)
* also update amdgpu's
On Tue, Jun 20, 2023 at 08:24:34AM +0200, Helge Deller wrote:
> 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 wro
Hi Laurent,
> Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
>
> On Wed, Jun 14, 2023 at 11:30:48AM +, Biju Das wrote:
> > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device
> > > API On Wed, Jun 14, 2023 at 08:21:38AM +, Biju Das wrote:
> >> >
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
+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
Am 20.06.23 um 06:14 schrieb Tatsuyuki Ishi:
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
On 6/20/23 17:12, Christian König wrote:
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
+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 n
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
> > I think Boris's suggestion of having this through a common
> > DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
>
> No, again. The only driver which should accept duplicates is radeon, for
> all other drivers especially new ones dup
Am 20.06.23 um 10:28 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
I think Boris's suggestion of having this through a common
DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
No, again. The only driver which should accept duplicates is radeon, for
all other
use "__packed" is clearer amd better than “pragma pack()”.
Signed-off-by: Su Hui
---
As Dan Carpenter mentioned:
'"Mark the associated types properly packed individually, rather than
use the disgusting "pragma pack()" that should never be used."
https://lore.kernel.org/linux-sparse/CAHk-=wi7jgz+b
On 6/20/23 17:16, Tatsuyuki Ishi wrote:
On 6/20/23 17:12, Christian König wrote:
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
@@ -928,18 +874,56 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
*p,
e->user_invalidated = userpage_invalidated;
}
- r = ttm_eu_reserv
On Tue, 20 Jun 2023 10:44:26 +0200
Christian König wrote:
> Am 20.06.23 um 10:28 schrieb Boris Brezillon:
> > On Tue, 20 Jun 2023 10:12:13 +0200
> > Christian König wrote:
> >
> >>> I think Boris's suggestion of having this through a common
> >>> DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
Hi
Am 04.05.23 um 13:51 schrieb Christian König:
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/qxl/qxl_drv.h | 7 ++--
drivers/gpu/drm/qxl/qxl_relea
Am 20.06.23 um 11:09 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:44:26 +0200
Christian König wrote:
Am 20.06.23 um 10:28 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
I think Boris's suggestion of having this through a common
DRM_EXEC_FLAG_ALLOW_D
Am 20.06.23 um 11:13 schrieb Thomas Zimmermann:
Hi
Am 04.05.23 um 13:51 schrieb Christian König:
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/qxl/qxl_dr
On Tue, 20 Jun 2023 11:14:51 +0200
Christian König wrote:
> Am 20.06.23 um 11:09 schrieb Boris Brezillon:
> > On Tue, 20 Jun 2023 10:44:26 +0200
> > Christian König wrote:
> >
> >> Am 20.06.23 um 10:28 schrieb Boris Brezillon:
> >>> On Tue, 20 Jun 2023 10:12:13 +0200
> >>> Christian König w
Hi Danilo,
On Tue, 20 Jun 2023 02:42:03 +0200
Danilo Krummrich wrote:
> 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 featur
Hi,
On 19/06/2023 22:26, Fabio Estevam wrote:
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
Maybe a fixes tag ?
Nei
1. Fix build warning message in mtk_disp_ovl_adaptor.c
>> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c:415:10: warning: cast to
>> smaller integer type 'enum mtk_ovl_adaptor_comp_type' from 'const void *'
>> [-Wvoid-pointer-to-enum-cast]
type = (enum mtk_ovl_adaptor_comp_typ
Dereference struct drm_device.dev_private in the helper function
do_virtio_gpu_device(). The dev_private field is deprecated and
drivers are advised not ot use it. Encapsulating it in a helper
function will help with a later removal. No functional changes.
Signed-off-by: Thomas Zimmermann
---
dr
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> 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
> ---
Reviewed-by: Konrad Dy
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> 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 d
yshkov
> ---
This looks good, but doesn't apply on next-20230620
Konrad
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 2 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 --
> 3 files changed, 5 in
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> 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
> ---
Acked-by: Ko
There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same core. This series is
trying to add PCI device driver support to drm/etnaviv.
v6:
* Fix build issue on system without CONFIG_PCI enabled
v7:
* Add a separate
Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation to extend
this driver for supporting the PCI devices.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-
Loongson CPUs maintain cache coherency by hardware, which means that the
data in the CPU cache is identical to the data in main system memory. As
for the peripheral device, most of Loongson chips chose to define the
peripherals as DMA coherent by default, device drivers do not need to
maintain the
Add a dedicate function to do the DMA configuration to the virtual master.
Also replace the &pdev->dev with dev.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 65 +++
1 file changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm
Originally, component frameworks were used to bind multiple GPU cores to a
virtual master. But there are chips that have only one GPU core integrated.
The component framework can be avoided under some circumstances, Another
reason is that usperspace programs such as X server and Mesa will try to
fi
There are numerous members in the struct etnaviv_drm_private, which are
shared by all GPU core. This patch introduces two dedicated functions for
the construction and destruction of the instances of this structure.
The goal is to keep its members from leaking to the outside. The code
needed for err
After introducing the etnaviv_of_first_available_node() helper, the
creation of the virtual master platform device can also be simplified.
So, switch to etnaviv_create_virtual_master() function.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed
This patch adds PCI driver support on top of what we already have, take
the GC1000 in LS7A1000/LS2K1000 as the first instance which enjoy the PCI
device driver. There is only one GPU core for the GC1000 in the LS7A1000
and LS2K1000. Therefore, component frameworks can be avoided.
Cc: Lucas Stach
Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.
Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.
Cc: Lucas Stach
Cc: C
No functional change.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 8907cdb8a1f8..c9f502a89de6 100644
--- a/drivers/gpu
Because it is also platform-dependent, there are systems where we don't
have DT-based clock drivers supported. For example, discrete PCI GPUs.
Therefire, don't quit if there is no clock subsystem support.
For the GPU in LS7A1000 and LS2K1000, the working frequency of the GPU is
rely on the GFX
On Tue, Jun 20, 2023 at 08:50:44AM +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 Uytterhoeven
> Reviewed-by: Laurent Pinchart
: Dmitry Baryshkov
---
This looks good, but doesn't apply on next-20230620
Hmm. It applied w/o any issues here.
Konrad
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_c
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
> full-featured catalog data.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Acked-by: Konrad Dybcio
Check below.
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 52
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> 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 --
>
On 20.06.2023 02:08, Dmitry Baryshkov wrote:
> Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
> are not used by the code.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 2 --
> drivers/gpu/dr
From: Rob Herring
Etnaviv doesn't use anything from of_platform.h, but depends on
of.h, of_device.h, and platform_device.h which are all implicitly
included, but that is going to be removed soon.
Signed-off-by: Rob Herring
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
drivers/gpu/drm
On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
> Where is the formal(unstream) PCI git branch where we could see the latest
> patch ?
Here's the "misc" branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=misc
And here's the "next" branch that will be merged
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.xml.h | 3 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 2 ++
2 files changed, 5 insertion
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 v4:
- Fix an issue where half of patch 1 got squashed into the cover letter..
- Link to v3:
https://lore.kernel.org/r/2023
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
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
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
I've noticed that this patch is not included in linux-next currently.
Can I get some confirmation that this is going to be included in v6.5?
Currently, I've been having to rebuild Fedora kernels to avoid this
panic, and I'd like to know there is a light at the end of that tunnel.
Thanks,
Jeff
On
On 20/06/2023 13:55, Konrad Dybcio wrote:
> On 20.06.2023 02:08, Dmitry Baryshkov wrote:
>> Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
>> full-featured catalog data.
>>
>> Signed-off-by: Dmitry Baryshkov
>> ---
> Acked-by: Konrad Dybcio
>
> Check below.
>
>> drivers
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
Fixes: 41bcceb4de9c ("drm/panel: simple: Add support for Innolux AT043TN24"
From: Rob Herring
Etnaviv doesn't use anything from of_platform.h, but depends on
of.h, of_device.h, and platform_device.h which are all implicitly
included, but that is going to be removed soon.
Signed-off-by: Rob Herring
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
drivers/gpu/drm
/msm/dsi: Enable runtime PM
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
---
base-commit: 9dbf40840551df336c95ce2a3adbdd25ed53c0ef
change-id: 20230620-topic-dsiphy_rpm-ea4817badaab
Best regards,
--
Konrad Dybcio
Some devices power the DSI PHY/PLL through a power rail that we model
as a GENPD. Enable runtime PM to make it suspendable.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/driv
This helper has been introduced to avoid programmer errors when using
pm_runtime_get, use it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/ds
On 20.06.2023 13:18, Dmitry Baryshkov wrote:
> On 20/06/2023 13:55, Konrad Dybcio wrote:
>> On 20.06.2023 02:08, Dmitry Baryshkov wrote:
>>> Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
>>> full-featured catalog data.
>>>
>>> Signed-off-by: Dmitry Baryshkov
>>> ---
>> Ac
On 20/06/2023 14:29, Konrad Dybcio wrote:
This helper has been introduced to avoid programmer errors when using
pm_runtime_get, use it.
Please expand to mention the error kind. Also as you are at it, could
you please add an error check here?
Signed-off-by: Konrad Dybcio
---
drivers/gpu/
Hi,
On 2023/6/20 19:06, Bjorn Helgaas wrote:
On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
Where is the formal(unstream) PCI git branch where we could see the latest
patch ?
Here's the "misc" branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=misc
And
On 2023-06-19 23:57:22, Dmitry Baryshkov wrote:
> 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 B
:
https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v1-0-446a7fd0c...@linaro.org
---
Konrad Dybcio (2):
drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
drm/msm/dsi: Enable runtime PM
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 8 +++-
1 file changed, 7 insertions
This helper has been introduced to avoid programmer errors (missing
_put calls leading to dangling refcnt) when using pm_runtime_get, use it.
While at it, start checking the return value.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++-
1 file changed, 3 insertio
Some devices power the DSI PHY/PLL through a power rail that we model
as a GENPD. Enable runtime PM to make it suspendable.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/driv
On Tue, Jun 20, 2023 at 06:06:00AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
> > Where is the formal(unstream) PCI git branch where we could see the latest
> > patch ?
>
> Here's the "misc" branch:
> https://git.kernel.org/pub/scm/linux/kernel/git
On 2023-06-20 00:06:47, 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
> ---
>
> Changes since v1:
> - Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marij
Remove rockchip's dependency on GEM DMA helpers. Rework the GEM DMA
interface to fit the needs of rcar-du.
This intends to be a cleanup with no functional changes. With the
patches merged, a later patchset can attempt to generate some of the
boiler-plate code for struct drm_gem_object_funcs automa
Remove the dependency on the GEM DMA helper library. Rockchip comes
with its own implementation of the GEM interface. It only uses the VM
callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are
not DMA specific.
Duplicate drm_gem_dma_vm_ops in rockchip and remove all dependencies on
th
Call __drm_gem_dma_create() to create an object for imported buffers,
instead of reimplementing the function within the driver. Reduces
code duplication and will later allow to un-export a number of symbols
from the GEM DMA helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_dm
There are no external users of drm_gem_dma_vm_ops. Unexport the symbol.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_dma_helper.c | 11 +--
include/drm/drm_gem_dma_helper.h | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem
Adding a new driver for the MIPI CSI CD-PHY module v 0.5 embedded in
some Mediatek soc, such as the MT8365
This driver was adapted from
https://patchwork.kernel.org/project/linux-mediatek/cover/20200708104023.3225-1-louis@mediatek.com/
v1 can be found here:
https://lore.kernel.org/all/20230
From: Florian Sylvestre
This adds the bindings, for the MIPI CD-PHY module v0.5 embedded in
some Mediatek soc, such as the mt8365
Signed-off-by: Florian Sylvestre
Signed-off-by: Julien Stephan
---
.../bindings/phy/mediatek,mt8365-csi-rx.yaml | 79 +++
MAINTAINERS
From: Phi-bang Nguyen
This is a new driver that supports the MIPI CSI CD-PHY version 0.5
The number of PHYs depend on the SoC.
Each PHY can support D-PHY only or CD-PHY configuration.
The driver supports only D-PHY mode, so CD-PHY
compatible PHY are configured in D-PHY mode.
Signed-off-by: Loui
On 19/06/2023 13:31, Li Dong wrote:
> Use zero as the return value instead of the unused variable ret
>
> Signed-off-by: Li Dong
> ---
> drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s
Sumitra Sharma wrote:
> 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 p
On 16/06/2023 15:52, Thomas Zimmermann wrote:
Ast's code for detecting the device type and features is convoluted.
It mixes up several state fields, chip types and sub-models. Rework
the driver into somehting more understandable.
Patches 1 fixes a long-standing bug. The affected code has never
w
Hi Thomas,
On 2023-06-20 14:03, Thomas Zimmermann wrote:
> Remove the dependency on the GEM DMA helper library. Rockchip comes
> with its own implementation of the GEM interface. It only uses the VM
> callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are
> not DMA specific.
>
> Dupl
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole at
the moment.
No worries, thank you for taking a look anyway!
Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
[SNIP]
diff --git a/include/drm/drm_gem.h b
On 6/14/2023 10:15 AM, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
smatch warning:
drivers/accel/qaic/qaic_data.c:620 qaic_free_object() error:
dereferencing freed memory 'obj->import_attach'
obj->import_attach is detached and freed using dma_buf_detach().
B
Hi Boris,
On 6/20/23 11:25, Boris Brezillon wrote:
Hi Danilo,
On Tue, 20 Jun 2023 02:42:03 +0200
Danilo Krummrich wrote:
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
On 20/06/2023 15:05, Marijn Suijten wrote:
On 2023-06-20 00:06:47, 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
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compr
1 - 100 of 186 matches
Mail list logo
