Hi Daniel,
On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter wrote:
> On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven
> wrote:
> > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote:
> > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > > wrote:
> > > > On Fri, Jan 8, 2021 at 11:13 AM Phil
Hi
Am 14.01.21 um 17:28 schrieb Kieran Bingham:
Hi Thomas,
On 14/01/2021 15:15, Thomas Zimmermann wrote:
On 23/11/2020 11:56, Thomas Zimmermann wrote:
The new GEM object function drm_gem_cma_mmap() sets the VMA flags
and offset as in the old implementation and immediately maps in the
buffer's
Quoting Daniel Vetter (2021-01-14 09:47:40)
> On Thu, Jan 14, 2021 at 09:45:37AM +, Chris Wilson wrote:
> > Quoting Daniel Vetter (2021-01-14 09:30:32)
> > > On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson
> > > wrote:
> > > > The only other problem I see with the implementation is that there's
The GEM mmap code relies on the GEM object's mmap callback to set the
VMA's vm_ops field. This is easily forgotten and lead to a memory leak
in the CMA helpers. Instead set the vm_ops field in the DRM core code
to the GEM object's value. Drivers with different needs can override
this in their mmap
ping for review
Am 13.01.21 um 12:31 schrieb Thomas Zimmermann:
The file is not in use. It got re-added by a rebased patch. Removing
it.
Signed-off-by: Thomas Zimmermann
Fixes: 4d4dad21cc7b ("drm/hibmc: Remove references to struct drm_device.pdev")
Reported-by: Tian Tao
Cc: Sam Ravnborg
Cc:
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two scre
On Wed, Jan 13, 2021 at 08:08:37PM +0100, Stefan Wahren wrote:
> This converts the v3d bindings to yaml format.
>
> Signed-off-by: Stefan Wahren
Acked-by: Maxime Ripard
Thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing li
From: Palmer Dabbelt
cdn_dp_resume is only used under PM_SLEEP, and now that it's static an
unused function warning is triggered undner !PM_SLEEP. This
conditionally enables the function to avoid the warning.
Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make
cdn_dp_core_suspend/resume stat
This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 24bpp parallel input color format and can map
the input to VESA or JEIDA standards. The two channels cannot be used
simultaneo
This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.
The parameters added here are based on common LVDS PHY
implementation practices. The set of parameters
should cover all potential users.
Cc: Kishon Vijay Abraham
This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays). It consists of two distinct
functions, a pixel transfer function and a c
This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 30bpp parallel input color format and can
map the input to VESA or JEIDA standards. The two channels can be used
simultaneously
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)
.../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 +
On Fri 27 Nov 03:23 CST 2020, Dmitry Baryshkov wrote:
> drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
> thus delaying further lt9611uxc IRQ events processing. It was observed
> occasionally during bootups, when drm_client_modeset_probe() was waiting
> for EDID ready even
Quoting Douglas Anderson (2021-01-14 17:22:59)
> If the HPD signal never asserts in panel_simple_prepare() and we
> return an error, we should unset the enable GPIO and disable the
> regulator to make it consistent for the caller.
>
> At the moment I have some hardware where HPD sometimes doesn't
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
Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
diff --git
a/D
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/bridge/fsl,imx8qxp-ldb.yaml | 176 +
1 file changed, 1
On Thu, Jan 14, 2021 at 09:17:32AM +0100, Giulio Benetti wrote:
> From: Giulio Benetti
>
> During commit 88bc4178568b ("drm: Use new
> DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
> macros have been changed to avoid ambiguity but just because of this
> ambiguity previous DRM
This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
The RGB pixels with padding low per component are transmitted on a 30-bit
input bus(10-bit per component) from a display controller or a 36-bit
output bu
This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
pixel combiner. The RGB pixels with padding low per component are
transmitted on a 30-bit input bus(10-bit per component) from a display
controller o
On 2021-01-13 18:28, John Stultz wrote:
On Wed, Jan 13, 2021 at 11:52 AM Veera Sundaram Sankaran
wrote:
The explicit out-fences in crtc are signaled as part of vblank event,
indicating all framebuffers present on the Atomic Commit request are
scanned out on the screen. Though the fence signal
This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module
that can be found in some F(x)Tec Pro1 and Elephone U1 devices.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/
On Fri 27 Nov 03:23 CST 2020, Dmitry Baryshkov wrote:
> - Call wake_up() when EDID ready event is received to wake
> wait_event_interruptible_timeout()
>
> - Increase waiting timeout, reading EDID can take longer than 100ms, so
> let's be on a safe side.
>
> - Return NULL pointer from get_ed
When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().
Signed-off-by: Hsin-Yi Wang
---
Change
Hello,
Tested on a13 and works.
Here are results:
with DRIVE_NEGEDGE
https://pasteboard.co/JJAGDAy.jpg
https://pasteboard.co/JJAHDAj.jpg
with DRIVE_POSEDGE
https://pasteboard.co/JJAIbBf.jpg
https://pasteboard.co/JJAIGfo.jpg
Il 14/01/2021 09:17, Giulio Benetti ha scritto:
From: Giulio Be
This patch adds a helper to support LDB drm bridge drivers for
i.MX SoCs. Helper functions exported from this driver should
implement common logics for all LDB modules embedded in i.MX SoCs.
Signed-off-by: Liu Ying
---
v1->v2:
* No change.
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
d
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 firmware. (Rob)
.../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106
anx7625 requires 3 power supply regulators.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
1 file changed, 15 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/
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 file changed, 105 insertions(+)
create mode 100644
Documentation/devicetree/bin
On Thu, Jan 14, 2021 at 09:49:49AM +0100, Thomas Zimmermann wrote:
> The function vc4_prime_import_sg_table() is an otherwise empty wrapper
> around CMA's drm_gem_cma_prime_import_sg_table(). Removing it in favor
> of the latter allows to initialize vc4_drm_driver with CMA's initializer
> macro.
>
Signed-off-by: ZhiJie.Zhang
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 2ee6edb3df93..ef4acb1d4a80 10064
Hi,
This is the v2 series to add some DRM bridge drivers support
for i.MX8qm/qxp SoCs.
The bridges may chain one by one to form display pipes to support
LVDS displays. The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.
The DPU KMS driver can be found at:
https://www.spinics.ne
Add myself as the maintainer of DRM bridge drivers for i.MX SoCs.
Signed-off-by: Liu Ying
---
v1->v2:
* No change.
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 389abcf..539dc58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5891,6 +
hi Laurent,
Do you mind me adding a DT property in the old format now? If so, I'd
appreciated an ack in this thread:
https://lore.kernel.org/linux-arm-kernel/20201201134638.ga305...@bogon.m.sigxcpu.org/
If it causes extra work for you and want to resend your series soon, I'll
gladly delay them fo
On 2021-01-13 16:00, Stephen Boyd wrote:
Quoting khs...@codeaurora.org (2021-01-13 15:44:32)
On 2021-01-13 12:22, Stephen Boyd wrote:
> Quoting khs...@codeaurora.org (2021-01-13 09:44:24)
>> On 2021-01-11 11:55, Stephen Boyd wrote:
>> > Quoting Kuogee Hsieh (2021-01-07 12:30:24)
>> >> irq_hpd ev
From: zhangzhijie
this callback was used by drm_kms_helper_hotplug_event()
V2: (Thanks for Daniel's suggestions)
- remove the FIXME below.since with the drm_client
- infrastructure and the generic fbdev emulation we've
- resolved this all very neatly now.
Signed-off-by: zhangzhijie
Signed-off-
This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI). The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color c
(cc'ing dri-devel)
Hi
Am 14.01.21 um 16:15 schrieb Eli Cohen:
Hi Thomas,
After long bisecting I found that this patch,
commit 1086db71a1dbbfb32ffb42cf0d540b69956f951e
Author: Thomas Zimmermann
Date: Tue Nov 3 10:30:06 2020 +0100
drm/vram-helper: Remove invariant parameters from inter
Hi
Am 15.01.21 um 09:50 schrieb tiantao (H):
在 2021/1/15 16:42, Thomas Zimmermann 写道:
ping for review
Am 13.01.21 um 12:31 schrieb Thomas Zimmermann:
The file is not in use. It got re-added by a rebased patch. Removing
it.
Reviewed-by Tian Tao
Thanks a lot. Pushed to -misc-next.
Best r
Hi Thomas,
On 15/01/2021 08:39, Thomas Zimmermann wrote:
> The GEM mmap code relies on the GEM object's mmap callback to set the
> VMA's vm_ops field. This is easily forgotten and lead to a memory leak
s/lead/can lead/
> in the CMA helpers. Instead set the vm_ops field in the DRM core code
> to
Hi
Am 15.01.21 um 10:17 schrieb Kieran Bingham:
Hi Thomas,
On 15/01/2021 08:39, Thomas Zimmermann wrote:
The GEM mmap code relies on the GEM object's mmap callback to set the
VMA's vm_ops field. This is easily forgotten and lead to a memory leak
s/lead/can lead/
in the CMA helpers. Inste
The GEM mmap code relies on the GEM object's mmap callback to set the
VMA's vm_ops field. This is easily forgotten and already led to a memory
leak in the CMA helpers. Instead set the vm_ops field in the DRM core
code to the GEM object's value. Drivers with different needs can override
this in thei
On 15/01/2021 09:28, Thomas Zimmermann wrote:
> Hi
>
> Am 15.01.21 um 10:17 schrieb Kieran Bingham:
>> Hi Thomas,
>>
>> On 15/01/2021 08:39, Thomas Zimmermann wrote:
>>> The GEM mmap code relies on the GEM object's mmap callback to set the
>>> VMA's vm_ops field. This is easily forgotten and lead
On 12/01/2021 10:07, Dan Carpenter wrote:
> On Mon, Jan 11, 2021 at 11:46:38AM +, Colin King wrote:
>> From: Colin Ian King
>>
>> A recent change added a new BOOTUP_DEFAULT power profile mode
>> to the PP_SMC_POWER_PROFILE enum but omitted updating the
>> corresponding profile_name array. Fix
From: Colin Ian King
There is a spelling contraction mistake in a drm_dbg message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i9
Hi Thomas,
On 15/01/2021 09:30, Thomas Zimmermann wrote:
> The GEM mmap code relies on the GEM object's mmap callback to set the
> VMA's vm_ops field. This is easily forgotten and already led to a memory
> leak in the CMA helpers. Instead set the vm_ops field in the DRM core
> code to the GEM obje
On 15/01/2021 10:07, Christophe JAILLET wrote:
> Le 15/01/2021 à 10:37, Colin Ian King a écrit :
>> On 12/01/2021 10:07, Dan Carpenter wrote:
>>> On Mon, Jan 11, 2021 at 11:46:38AM +, Colin King wrote:
From: Colin Ian King
A recent change added a new BOOTUP_DEFAULT power profile
> -Original Message-
> From: Sean Paul
> Sent: Thursday, January 14, 2021 12:04 AM
> To: Daniel Vetter
> Cc: Gupta, Anshuman ; David Airlie
> ; intel-...@lists.freedesktop.org; Sean Paul
> ; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Disable the Q
On Tuesday, December 22nd, 2020 at 2:59 PM, Daniel Vetter
wrote:
> > + * type:
> > + * Immutable property describing the type of the plane.
> > + *
> > + * For user-space which has enabled the
> > &DRM_CLIENT_CAP_UNIVERSAL_PLANES
>
> s/UNIVERSAL_PLANES/ATOMIC/ here?
>
> With just univer
The docs for enum drm_plane_type mention legacy IOCTLs, however the
plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
cursor fields are. Add a small paragraph to reference these.
Instead, document expectations for primary and cursor planes for
non-legacy userspace. Note that thes
Add a new entry for "type" in the section for standard plane properties.
v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
note that a driver may support cursors without cursor planes (Daniel)
v4: fixing rebase gone wrong
v5:
- Fix typo (Daniel)
- Mention CAP_ATOMIC instead o
Am 06.01.21 um 21:21 schrieb Maxim Levitsky:
On Mon, 2021-01-04 at 09:45 -0700, Alex Williamson wrote:
On Mon, 4 Jan 2021 12:34:34 +0100
Christian König wrote:
Hi Maxim,
I can't help with the display related stuff. Probably best approach to
get this fixes would be to open up a bug tracker fo
Hans do you have any more comments or a tested-by?
Otherwise I push it to drm-misc-fixes today.
Thanks,
Christian.
Am 13.01.21 um 14:13 schrieb Christian König:
The only flag we really need is __GFP_NOMEMALLOC, highmem depends on
dma32 and moveable/compound should never be set in the first pla
Hi,
On 1/15/21 1:14 PM, Christian König wrote:
> Hans do you have any more comments or a tested-by?
Sorry, I've been busy chasing after another 5.11 regression,
no comments, also no tested-by, but I do fully expect this to solve
the issue.
> Otherwise I push it to drm-misc-fixes today.
That so
Am 15.01.21 um 13:54 schrieb Hans de Goede:
Hi,
On 1/15/21 1:14 PM, Christian König wrote:
Hans do you have any more comments or a tested-by?
Sorry, I've been busy chasing after another 5.11 regression,
no comments, also no tested-by, but I do fully expect this to solve
the issue.
Yeah, I kn
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handling of the exporter
completely. Importers reall
From: Colin Ian King
Currently the kmalloc allocation for config is not being null
checked and could potentially lead to a null pointer dereference.
Fix this by adding the missing null check.
Addresses-Coverity: ("Dereference null return value")
Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config ty
Am 15.01.21 um 14:02 schrieb Daniel Vetter:
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handli
On Fri, Jan 15, 2021 at 2:09 PM Christian König
wrote:
>
> Am 15.01.21 um 14:02 schrieb Daniel Vetter:
> > have too many people abusing the struct page they can get at but
> > really shouldn't in importers. Aside from that the backing page might
> > simply not exist (for dynamic p2p mappings) look
Am 15.01.21 um 14:22 schrieb Daniel Vetter:
On Fri, Jan 15, 2021 at 2:09 PM Christian König
wrote:
Am 15.01.21 um 14:02 schrieb Daniel Vetter:
have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist
On Fri, Jan 15, 2021 at 12:06 PM Simon Ser wrote:
>
> On Tuesday, December 22nd, 2020 at 2:59 PM, Daniel Vetter
> wrote:
>
> > > + * type:
> > > + * Immutable property describing the type of the plane.
> > > + *
> > > + * For user-space which has enabled the
> > > &DRM_CLIENT_CAP_UNIVER
Hi Laurent,
On 13/01/2021 22:45, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wed, Jan 13, 2021 at 05:02:53PM +, Kieran Bingham wrote:
>> The encoder allocation was converted to a DRM managed resource at the
>> same time as the addition of a new helper drmm_encode
Hi
Am 15.01.21 um 13:56 schrieb Maxime Ripard:
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Let's start conve
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when a reservation
object lock is help or otherwise we can deadlock with page faults.
Make lockdep complain badly about that.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 14 ++
1 file changed, 14 insertions(
On Thu, 14 Jan 2021, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backl
Hi
Am 15.01.21 um 13:56 schrieb Maxime Ripard:
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8a4235d9d9f1..2cb09e9d9306 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -344,12 +344,12 @@ static const struct drm
On Thu, 14 Jan 2021, Lyude Paul wrote:
> In the next commit where we split PWM related backlight functions from
> higher-level backlight functions, we'll want to be able to retrieve the
> backlight level for the current display panel from the
> intel_panel_bl_funcs->setup() function using pwm_func
On Fri, Jan 15, 2021 at 02:35:50PM +0100, Christian König wrote:
> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when a reservation
> object lock is help or otherwise we can deadlock with page faults.
>
> Make lockdep complain badly about that.
>
> Signed-off-by: Christian König
> ---
>
On Fri, Jan 15, 2021 at 11:33:28AM +0800, ZhiJie.Zhang wrote:
> From: zhangzhijie
>
> this callback was used by drm_kms_helper_hotplug_event()
>
> V2: (Thanks for Daniel's suggestions)
> - remove the FIXME below.since with the drm_client
> - infrastructure and the generic fbdev emulation we've
>
On Fri, Jan 15, 2021 at 6:39 PM Colin King wrote:
>
> From: Colin Ian King
>
> Currently the kmalloc allocation for config is not being null
> checked and could potentially lead to a null pointer dereference.
> Fix this by adding the missing null check.
>
> Addresses-Coverity: ("Dereference null
On Fri, Jan 15, 2021 at 09:57:24AM +, Kieran Bingham wrote:
> Hi Thomas,
>
> On 15/01/2021 09:30, Thomas Zimmermann wrote:
> > The GEM mmap code relies on the GEM object's mmap callback to set the
> > VMA's vm_ops field. This is easily forgotten and already led to a memory
> > leak in the CMA
Hi
Am 15.01.21 um 15:11 schrieb Daniel Vetter:
On Fri, Jan 15, 2021 at 09:57:24AM +, Kieran Bingham wrote:
Hi Thomas,
On 15/01/2021 09:30, Thomas Zimmermann wrote:
The GEM mmap code relies on the GEM object's mmap callback to set the
VMA's vm_ops field. This is easily forgotten and alread
Hi,
On 10/01/2021 21:06, Oliver Graute wrote:
> On 10/01/21, Fabio Estevam wrote:
>> Hi Oliver,
>>
>> On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute
>> wrote:
>>
>>> the first two errors are gone. But I still get this:
>>>
>>> [ 42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517
>>>
On Fri, Jan 15, 2021 at 2:28 AM Dave Airlie wrote:
>
> On Fri, 15 Jan 2021 at 07:22, Alex Deucher wrote:
> >
> > Hi Dave, Daniel,
> >
> > More new stuff for 5.12.
> >
> > The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
> >
> > drm/amdgpu: fix DRM_INFO flood if displ
Enable CEC support for STMicroelectronics as loadable module.
Signed-off-by: Yannick Fertre
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index c5f25710fedc..05cc0607a9ad 1006
Remove unused adev variable
Fixes: 8f66090b7bb7 ("drm/amdgpu: Remove references to struct
drm_device.pdev")
Reported-by: Stephen Rothwell
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
Hi Stephen,
On 1/15/21 2:23 AM, Stephen Rothwell wrote:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
'amdgpu_display_user_framebuffer_create':
drivers/gpu/drm/amd/amdgpu/
On Fri, Jan 15, 2021 at 10:02 AM Nirmoy Das wrote:
>
> Remove unused adev variable
>
> Fixes: 8f66090b7bb7 ("drm/amdgpu: Remove references to struct
> drm_device.pdev")
> Reported-by: Stephen Rothwell
> Signed-off-by: Nirmoy Das
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu
On Fri, 15 Jan 2021, Jani Nikula wrote:
> On Thu, 14 Jan 2021, Lyude Paul wrote:
>> In the next commit where we split PWM related backlight functions from
>> higher-level backlight functions, we'll want to be able to retrieve the
>> backlight level for the current display panel from the
>> intel_
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20210115]
[also build test WARNING on v5.11-rc3]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.11-rc3 v5.11-rc2
v5.11-rc1]
[If your patch is applied to the wrong git tree, kindly drop us
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handling of the exporter
completely. Importers reall
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handling of the exporter
completely. Importers reall
Quoting Daniel Vetter (2021-01-15 15:52:26)
> +static void mangle_sg_table(struct sg_table *sg_table)
> +{
> +#ifdef CONFIG_DMABUF_DEBUG
> + int i;
> + struct scatterlist *sg;
> +
> + if (!sg_table)
if (!IS_ENABLED(CONFIG_DMABUF_DEBUG) || IS_ERR_OR_NULL(sg_table))
> +
On Thu, 14 Jan 2021 20:15:45 -0800
Linus Torvalds wrote:
> On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
> >
> > Thanks, I take it, it will be going into mainline soon.
>
> Just got merged - it might be a good idea to verify that your problem is
> solved.
>
Yep, I just tested commi
On Fri, 15 Jan 2021 09:50:25 +0200
Jani Nikula wrote:
> >> fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
> >> ("drm/i915: Shut down displays gracefully on reboot")
> >>
> >> Which makes sense, as it happens on shutdown.
>
> Please try this pull, heading to -rc4, which cointains "drm/i915:
> Di
On Tue, Jan 12, 2021 at 01:37:06PM +0200, Mikko Perttunen wrote:
> Support newer VIC firmware by accepting the new magic number 0x10fe,
> loading the full code segment instead of just the first page at boot
> time, and skipping FCE setup if the firmware header indicates that
> FCE is handled intern
On Tue, Jan 12, 2021 at 09:14:19PM +0300, Dmitry Osipenko wrote:
> Display controller driver isn't listed as a DRM sub-device for Tegra114,
> thus display driver isn't loaded on Tegra114. Enable display controller
> driver for Tegra114 SoC.
>
> Tested-by: Anton Bambura
> Signed-off-by: Dmitry Osi
On Tue, Jan 12, 2021 at 09:14:20PM +0300, Dmitry Osipenko wrote:
> The device-tree compatibles are swapped in the code, correct them.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gr2d.c | 4 ++--
On Tue, Jan 12, 2021 at 09:14:21PM +0300, Dmitry Osipenko wrote:
> Tegra114 has GR2D hardware block, support it by the 2D driver.
>
> Tested-by: Anton Bambura
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/drm.c | 1 +
> drivers/gpu/drm/tegra/gr2d.c | 5 +
> 2 files changed
Am 15.01.21 um 16:52 schrieb Daniel Vetter:
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handli
On Tue, Dec 15, 2020 at 03:00:53PM +0800, Tian Tao wrote:
> Fixes coccicheck warning:
> drivers/gpu/drm/tegra/drm.c:350:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/tegra/drm.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
This cocc
On Tue, Dec 01, 2020 at 08:56:31PM +0800, Qinglang Miao wrote:
> The PM reference count is not expected to be incremented on
> return in these tegra functions.
>
> However, pm_runtime_get_sync will increment the PM reference
> count even failed. Forgetting to putting operation will result
> in a r
We have too many people abusing the struct page they can get at but
really shouldn't in importers. Aside from that the backing page might
simply not exist (for dynamic p2p mappings) looking at it and using it
e.g. for mmap can also wreak the page handling of the exporter
completely. Importers reall
On Thu, 14 Jan 2021 08:44:35 +0200, Laurent Pinchart wrote:
> Convert the Rockchip HDMI TX text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v3:
>
> - Replace endpoint-base with endpoint
>
> Changes since v2:
>
> - Use Mark's @gmail.com e-mail address as the @rock
Quoting Jinoh Kang (2021-01-15 16:23:31)
> If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
> returned only when the object is actually bound.
>
> The xf86-video-intel userspace driver cannot differentiate this
> condition, and marks the GPU as wedged.
The idea was to call g
On Fri, Jan 15, 2021 at 9:51 AM Alex Deucher wrote:
>
> On Fri, Jan 15, 2021 at 2:28 AM Dave Airlie wrote:
> >
> > On Fri, 15 Jan 2021 at 07:22, Alex Deucher wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > More new stuff for 5.12.
> > >
> > > The following changes since commit
> > > 044a48f420b
Quoting Chris Wilson (2021-01-15 16:56:42)
> Quoting Jinoh Kang (2021-01-15 16:23:31)
> > If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
> > returned only when the object is actually bound.
> >
> > The xf86-video-intel userspace driver cannot differentiate this
> > conditio
Hi Liu Ying,
I promised I would have a second, more in-depth, look at this and I finally
managed to do it.
I have to admit it was a challenge. Partially because I'm not very familiar
with DPU but mostly because of the abundance of macros used. It's true, macros
make the code more compact. However
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Penultimate set, promise. :)
Lee Jones (40):
drm/r128/r128_ioc32: Document headers do not make good kernel-doc
candidates
drm/mga/mga_ioc32
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/r128_ioc32.c:2: warning: Cannot understand * file
r128_ioc32.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/r128/r128_ioc32.c | 2 +-
1 file changed,
1 - 100 of 198 matches
Mail list logo
