This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq faster (compared to panfrost)
to compensate for the lower overall performance of utgard devices.
[0]
https://
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
.../display/bridge/lontium,lt8912.yaml| 92 +++
MAINTAINERS | 5 +
2 files changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/displa
From: "carlis.zhang_cp"
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: carlis.zhang_cp
---
v2:add release te gpio after irq request fail
---
drivers/staging/fbtft/fb_st7789v.c | 134 -
drivers/staging/fbtft/fbtft.h | 1
From: "carlis.zhang_cp"
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: carlis.zhang_cp
---
drivers/staging/fbtft/fb_st7789v.c | 133 -
drivers/staging/fbtft/fbtft.h | 1 +
2 files changed, 133 insertions(+), 1 deletion
fixed the below warning:
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
before some freeing functions is not needed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/
Lontium Lt8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912.c | 749
4
On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote:
> Hi,
>
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
>
> The reason for calling it 'Generic' is so anyone can make a USB
> display/adapter against this driver, all th
On Sat, Jan 23, 2021 at 12:16:02AM +0800, Rob Herring wrote:
> On Tue, Jan 12, 2021 at 2:57 AM Xin Ji wrote:
> >
> > Hi Rob Herring, thanks for the comments.
> >
> > On Mon, Jan 11, 2021 at 04:14:35PM -0600, Rob Herring wrote:
> > > On Thu, Dec 31, 2020 at 10:21:12AM +0800, Xin Ji wrote:
> > > > A
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
.../display/bridge/lontium,lt8912.yaml| 92 +++
MAINTAINERS | 5 +
2 files changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/displa
On Wed, Jan 13, 2021 at 7:51 PM Jani Nikula
wrote:
>
> On Wed, 13 Jan 2021, Koba Ko wrote:
> > After read the link rate from MST hub, align with
> > maximum source rate.
> >
> > Signed-off-by: Koba Ko
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8
> > drivers/gpu/drm/i915/dis
On 12/24/20 7:18 AM, Marek Vasut wrote:
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pixelclk-active",
same as the one used by display timings, and configure bus flags based on
this DT property.
Bump ?
Hello,
this patch set adds the support of the Lontium lt8912 MIPI to HDMI
bridge in the kernel.
It's only support the video part, not the audio part yet
since I don't have the datasheet of this component.
I get the current i2c configuration from Digi and
Boundary drivers.
Developed using the DB_D
The devm_memremap() function never returns NULL, it returns error
pointers so the test needs to be fixed. Also we need to call
pci_release_regions() to avoid a memory leak.
Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/vmwgfx/vmw
Smatch found an uninitialized variable bug in this code:
drivers/gpu/drm/i915/gvt/cmd_parser.c:3191 intel_gvt_update_reg_whitelist()
error: uninitialized symbol 'ret'.
The first thing that Smatch complains about is that "ret" isn't set if
we don't enter the "for_each_engine(engine, &dev_p
On Mon, Jan 25, 2021 at 04:44:12PM +0800, Carlis wrote:
> From: "carlis.zhang_cp"
I need a "real" name here, and in the signed-off-by: area as I do not
think you sign documents with a "." and "_", right?
thanks,
greg k-h
___
dri-devel mailing list
dri
Quoting Dan Carpenter (2021-01-25 08:48:30)
> Smatch found an uninitialized variable bug in this code:
>
> drivers/gpu/drm/i915/gvt/cmd_parser.c:3191
> intel_gvt_update_reg_whitelist()
> error: uninitialized symbol 'ret'.
>
> The first thing that Smatch complains about is that "ret" isn'
It is already merged to drm-intel-next
https://cgit.freedesktop.org/drm/drm-intel/commit/?h=drm-intel-next&id=40a6cead28f841ac350bd38dd7260ecacd5eab03
> -Original Message-
> From: Jani Nikula
> Sent: Friday, January 22, 2021 8:51 PM
> To: Colin King ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. O
On Mon, Jan 25, 2021 at 11:52:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > > Some drivers are storing the plane->state pointer in atomic_update and
> > > atomic
This still needs to be corrected.
On Thu, Nov 19, 2020 at 01:30:41PM +1100, Jonathan Gray wrote:
> Change the license of color_table.c to match color_table.h granting
> permission to modify and distribute.
>
> Signed-off-by: Jonathan Gray
> ---
> .../amd/display/modules/color/color_table.c |
On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote:
> On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote:
>
> > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner <
> > mario.kleiner...@gmail.com> wrote:
> >
> > > But it still needs to be fixed if we want working HDR. I thought
> > >
On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> The check was introduced to make sure that only the
> DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
>
> However, if .format_mod_supported is not hooked up to
> drm_simple_kms_format_mod_supported then the core will
> simply
> This is not an uapi defintion anyway so fixing should be fine.
Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah
should be completely fine to fix it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskt
> > Just calling ttm_bo_unpin() here makes lockdep unhappy.
>
> How does that one splat? But yeah if that's a problem should be
> explained in the comment. I'd then also only do a pin_count--; to make
> sure you can still catch other pin leaks if you have them. Setting it
> to 0 kinda defeats the
On Wed, Jan 13, 2021 at 01:51:00PM +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Koba Ko wrote:
> > After read the link rate from MST hub, align with
> > maximum source rate.
> >
> > Signed-off-by: Koba Ko
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8
> > drivers/gpu/drm/i
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02 ("d
From: Arnd Bergmann
The x86-specific wbinvd_on_all_cpus() function is exported
through asm/smp.h, causing a build failure in the i915 driver
when SMP is disabled:
drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of function
'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function-de
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I9
Quoting Arnd Bergmann (2021-01-25 12:26:44)
> From: Arnd Bergmann
>
> CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
> to honor its dependencies:
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT
Quoting Arnd Bergmann (2021-01-25 12:25:34)
> From: Arnd Bergmann
>
> The x86-specific wbinvd_on_all_cpus() function is exported
> through asm/smp.h, causing a build failure in the i915 driver
> when SMP is disabled:
>
> drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of
> f
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunused-variable]
Add another such #ifdef.
Fixes: 98
[AMD Public Use]
Hi Arnd Bergmann,
Thanks for your patch. This link error during compile has been fixed by below
commit and been submitted to drm-next branch already.
5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS
Regards,
Guchun
-Original Message-
From: amd-gfx
On Mon, Jan 25, 2021 at 1:33 PM Chris Wilson wrote:
>
> Quoting Arnd Bergmann (2021-01-25 12:26:44)
> > From: Arnd Bergmann
> >
> > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
> > to honor its dependencies:
> >
> > WARNING: unmet direct dependencies detected for DRM_I915_W
On Mon, Jan 25, 2021 at 1:51 PM Chen, Guchun wrote:
>
> [AMD Public Use]
>
> Hi Arnd Bergmann,
>
> Thanks for your patch. This link error during compile has been fixed by below
> commit and been submitted to drm-next branch already.
>
> 5da047444e82 drm/amd/display: fix 64-bit division issue on 3
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during s
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_module.c | 50
drivers/gpu/drm/ttm/ttm_module.h | 2 --
2 files changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index f656660
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gp
Hi Liu Ying,
Just some minor comments below.
On Thu, Jan 21, 2021 at 03:14:22PM +0800, Liu Ying wrote:
> This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support.
>
> DPU is comprised of two main components that include a blit engine for
> 2D graphics accelerations(with composi
On Mon, 25 Jan 2021 19:12:21 +0800, Xin Ji wrote:
> Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> flag and DP tx lane0 and lane1 swing register array define.
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 57
> --
Applied. Thanks!
Alex
On Sun, Jan 24, 2021 at 11:36 PM Huang Rui wrote:
>
> On Fri, Jan 22, 2021 at 11:00:22PM +0800, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the ! operator is incorrectly being used to flip bits on
> > mask values. Fix this by using the bit-wise ~ operator
On 1/19/21 8:56 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separa
On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
wrote:
> On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > The check was introduced to make sure that only the
> > DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
> >
> > However, if .format_mod_supported is not hooked up to
>
Hi Phillip,
On Fri, Jan 22, 2021 at 8:26 PM Phillip Susi wrote:
> Geert Uytterhoeven writes:
> Judging from some of the comments in the code, it looks like you were
> one of the original authors of fbcon? I haven't been able to find any
Indeed, a long time ago... Before DRM existed.
> of t
On 2021-01-25 7:48 a.m., Arnd Bergmann wrote:
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunuse
On Mon, Jan 25, 2021 at 07:12:21PM +0800, Xin Ji wrote:
> Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> flag and DP tx lane0 and lane1 swing register array define.
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 57
>
On Mon, Jan 25, 2021 at 7:07 AM Jonathan Gray wrote:
>
> This still needs to be corrected.
Applied. Thanks!
Alex
>
> On Thu, Nov 19, 2020 at 01:30:41PM +1100, Jonathan Gray wrote:
> > Change the license of color_table.c to match color_table.h granting
> > permission to modify and distribute.
>
On Mon, Jan 25, 2021 at 7:24 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> clang warns about the -mhard-float command line arguments
> on architectures that do not support this:
>
> clang: error: argument unused during compilation: '-mhard-float'
> [-Werror,-Wunused-command-line-argument]
Add DPCD register definitions for eDP 1.4 Multi-SST Operation.
Cc: Nischal Varide
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
ind
On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
> > This is not an uapi defintion anyway so fixing should be fine.
>
> Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah
> should be completely fine to fix it.
>
Good! The beginning of the end of a sad story ;). So i guess i ca
‐‐‐ Original Message ‐‐‐
On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner
wrote:
> On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
>
> > > This is not an uapi defintion anyway so fixing should be fine.
> >
> > Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yea
On Mon, Jan 25, 2021 at 1:09 PM Ville Syrjälä
wrote:
> On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote:
> > On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote:
> >
> > > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner <
> > > mario.kleiner...@gmail.com> wrote:
> > >
> > > > Bu
On Monday, January 25th, 2021 at 5:08 PM, Mario Kleiner
wrote:
> In some way it would even be nice to have all that info exposed in
> parsed form as a connector property or such, so all clients can use
> the same parsed data instead of reinventing the wheel.
So far the policy has more or less b
On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
> wrote:
>
> > On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > > The check was introduced to make sure that only the
> > > DRM_FORMAT_MOD_LINEAR modifier is accepted b
Am Mittwoch, dem 16.12.2020 um 12:42 +0100 schrieb Christian Gmeiner:
> Make it possible for the user space to access these ID values.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 +
Am Mittwoch, dem 23.12.2020 um 20:51 +0100 schrieb Marc Kleine-Budde:
> This patch fixes the following sparse warnings, by adding the missing
> endianess
> conversion functions.
>
> > etnaviv/etnaviv_dump.c:78:26: warning: restricted __le32 degrades to integer
> > etnaviv/etnaviv_dump.c:88:26: wa
Am Montag, dem 25.01.2021 um 11:27 +0800 schrieb Tian Tao:
> fixed the below warning:
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
> before some freeing functions is not needed.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by:
This function will be needed by the next patch where the driver
calculates the BW based on driver specific parameters, so export it.
At the same time sanitize the function params, passing the more natural
link rate instead of the encoding of the same rate.
Cc: Lyude Paul
Cc: Ville Syrjala
Cc:
On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner
wrote:
>
> This fixes corrupted display output in HDMI deep color
> 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
>
> It will hopefully also provide fixes for other DCE's up to
> DCE-11, assuming those will need similar fixes, but i coul
On Mon, Jan 25, 2021 at 5:34 PM Ville Syrjälä
wrote:
> On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> > On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > > > Th
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing b
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing b
> On Jan 25, 2021, at 03:45, Dan Carpenter wrote:
>
> The devm_memremap() function never returns NULL, it returns error
> pointers so the test needs to be fixed. Also we need to call
> pci_release_regions() to avoid a memory leak.
>
> Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handli
On 2021-01-25 12:57 p.m., Alex Deucher wrote:
On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner
wrote:
This fixes corrupted display output in HDMI deep color
10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
It will hopefully also provide fixes for other DCE's up to
DCE-11, assuming th
On Mon, 2021-01-25 at 19:36 +0200, Imre Deak wrote:
> This function will be needed by the next patch where the driver
> calculates the BW based on driver specific parameters, so export it.
>
> At the same time sanitize the function params, passing the more natural
> link rate instead of the encodi
Thanks Alex and Nicholas! Brings quite a bit of extra shiny to those older
asics :)
Nicholas, any thoughts on my cover-letter wrt. why a similar patch (that I
wrote and tested to no good or bad effect) not seem to be needed on DCN,
and probably not DCE-11.2+ either? Is what is left in DC for those
On Wed, 13 Jan 2021 14:07:00 +0800, Nicolas Boichat wrote:
> Define a compatible string for the Mali Bifrost GPU found in
> Mediatek's MT8183 SoCs.
>
> Signed-off-by: Nicolas Boichat
> ---
>
> Changes in v10:
> - Fix the binding to make sure sram-supply property can be provided.
>
> Changes in
On Wed, 13 Jan 2021 11:59:21 +0100, Mauro Carvalho Chehab wrote:
> Changeset 97198614f6c3 ("ASoC: audio-graph-card: switch to yaml base
> Documentation")
> renamed: Documentation/devicetree/bindings/sound/audio-graph-card.txt
> to: Documentation/devicetree/bindings/sound/audio-graph-card.yaml.
>
On Wed, 13 Jan 2021 11:59:22 +0100, Mauro Carvalho Chehab wrote:
> Changeset 9273cf7d3942 ("dt-bindings: display: mediatek: convert the dpi
> bindings to yaml")
> renamed: Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> to: Documentation/devicetree/bindings/display/mediatek/m
On Wed, 13 Jan 2021 11:59:23 +0100, Mauro Carvalho Chehab wrote:
> Changeset 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT
> schema")
> renamed:
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> to:
> Documentation/devicetree/bindings/memory-control
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 +
The filter definition is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).
Signed-off-by: Jianxin Xiong
---
tests/utils.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
To commit bfe0cc6eb249 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/r
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by: Ji
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py |
This is the seventh version of the patch series. Change log:
v7:
* Rebase to the latest rdma-core master (commit a4885eda9addc4)
* Rerun kernel-headers/update against linux-rdma for-next so that the
kernel commit id in the commit message is correct
v6: https://www.spinics.net/lists/linux-rdma/m
On Mon, Jan 25, 2021 at 5:05 PM Simon Ser wrote:
> ‐‐‐ Original Message ‐‐‐
>
> On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
> >
> > > > This is not an uapi defintion anyway so fixing
On Wed, 13 Jan 2021 20:08:37 +0100, Stefan Wahren wrote:
> This converts the v3d bindings to yaml format.
>
> Signed-off-by: Stefan Wahren
> ---
>
> Changes in V4:
> - define order for required reg-names
> - adapt example
>
> Changes in V3:
> - drop redundant maxItems in case we already have it
On Thu, 14 Jan 2021 17:22:02 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp pixel combiner.
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
> * Use enum instead of oneOf + const for the reg property of pixel combiner
> channels. (Rob)
>
> .../dis
On Thu, 14 Jan 2021 17:22:04 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp display pixel link.
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
> * Require all four pixel link output ports. (Laurent)
> * Mention pixel link is accessed via SCU firmwar
On Thu, Jan 14, 2021 at 05:22:06PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
>
> .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 105
> +
> 1 fi
On Thu, Jan 14, 2021 at 05:22:09PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
> * Side note i.MX8qxp LDB official name 'pixel mapper'. (Laurent)
>
> .../bindings/display/
Hi Oliver,
On Mon, Jan 25, 2021 at 6:29 PM Oliver Graute wrote:
> Ok I fixed the pin conflict with regulator-gpio and added a 5V
> regulator node in my dts file. Now the display is working fine!
That's good news :-)
> I'll post the dts files soon and check if there is something to
> improve fo
On Thu, 14 Jan 2021 18:50:24 +0100, AngeloGioacchino Del Regno wrote:
> Document the boe,bf060y8m-aj0 panel.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/panel/boe,bf060y8m-aj0.yaml | 67 +++
> 1 file changed, 67 insertions(+)
> create mode 100644
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #43 from Randune (randyk...@gmail.com) ---
(In reply to Panagiotis Polychronis from comment #41)
> (In reply to j.cordoba from comment #40)
> > (In reply to Randune from comment #39)
> > > There doesn't appear to be any progress on thi
On Fri, 2020-12-11 at 17:01 +0200, Jani Nikula wrote:
> On Wed, 09 Dec 2020, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a s
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
Cc: Jani Nikula
Cc: Dave Airlie
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 file changed,
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
thi
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bit
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of),
Hi!
Follow-up on the v5 [1], things have gotten significantly
better in the last 9 months, thanks to the efforts on Bifrost
support by the Collabora team (and probably others I'm not
aware of).
I've been testing this series on a MT8183/kukui device, with a
chromeos-5.10 kernel [2], and got basic
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.
Signed-off-by: Nicolas Boichat
---
Changes in v11:
- binding: power-domain-names not power-domainS-names
Changes in v10:
- Fix the binding to make sure sram-supply property can be provided.
Changes in v9: No
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
does not support multiple regulators, so we'll need custom
handlers.
2. Generally, platforms with
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
Reviewed-by: Steven Price
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conflicts, re
On 1/20/21 12:29 AM, Dmitry Osipenko wrote:
11.01.2021 15:59, Mikko Perttunen пишет:
Hi all,
here's the fifth revision of the Host1x/TegraDRM UAPI proposal,
containing primarily small bug fixes. It has also been
rebased on top of recent linux-next.
vaapi-tegra-driver has been updated to suppor
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #44 from MajorGonzo (majorgo...@juno.com) ---
Here's another thing I tried which also may have made a difference. Gonna
sound weird, but worth a try. I had a 675VA UPS that my system was plugged
into. One time, it started shrieking
On 2021.01.25 09:44:53 +, Chris Wilson wrote:
> Quoting Dan Carpenter (2021-01-25 08:48:30)
> > Smatch found an uninitialized variable bug in this code:
> >
> > drivers/gpu/drm/i915/gvt/cmd_parser.c:3191
> > intel_gvt_update_reg_whitelist()
> > error: uninitialized symbol 'ret'.
> >
On Mon, Jan 25, 2021 at 07:13:43PM +, Zack Rusin wrote:
>
>
> > On Jan 25, 2021, at 03:45, Dan Carpenter wrote:
> >
> > The devm_memremap() function never returns NULL, it returns error
> > pointers so the test needs to be fixed. Also we need to call
> > pci_release_regions() to avoid a me
1 - 100 of 101 matches
Mail list logo
