On Tue, 25 Aug 2020, Lyude Paul wrote:
> And of course, we'll also need to read the sink count from other drivers
> as well if we're checking whether or not it's supported. So, let's
> extract the code for this into another helper.
>
> v2:
> * Fix drm_dp_dpcd_readb() ret check
> * Add back comment
The Tosa backlight driver was converted to use GPIO descriptors
in 0b0cb52bd80eda76c4b9921f5cf9c1b709d44e83
("video: backlight: tosa: Use GPIO lookup table") but
still includes rather than .
Fix it.
Cc: Arnd Bergmann
Cc: Robert Jarzmik
Signed-off-by: Linus Walleij
---
drivers/video/backlight/
The Tosa backlight LCDE driver was converted to use GPIO descriptors
in 0b0cb52bd80eda76c4b9921f5cf9c1b709d44e83
("video: backlight: tosa: Use GPIO lookup table") but
still includes rather than .
Fix it.
Cc: Arnd Bergmann
Cc: Robert Jarzmik
Signed-off-by: Linus Walleij
---
drivers/video/backl
Hi Dave,
Just one fixup to fix sparse warning reported.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git repository at:
drm-misc-fixes-2020-08-26:
Fixes for v5.9-rc2:
- Take modeset bkl for legacy drivers.
- Allow null crtc in dp_mst.
- Omap locking state fix.
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git repository
On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable o
Hi John,
On 2020/08/22 3:32, John Stultz wrote:
On Fri, Aug 21, 2020 at 2:14 AM Kunihiko Hayashi
wrote:
On 2020/08/01 4:38, John Stultz wrote:
On Fri, Jul 31, 2020 at 2:32 AM Kunihiko Hayashi
wrote:
On 2020/07/29 4:17, John Stultz wrote:
Do you have a upstream driver that you plan to make
Since transl_l[16] is accessed via cdat[y] >> 4, cdat[y] needs to be
evaluated as an "unsigned char" value in order to fit 0...15 range.
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/vga16fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vga16fb.c
On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
> This code was using get_user_pages*(), in a "Case 2" scenario
> (DMA/RDMA), using the categorization from [1]. That means that it's
> time to convert the get_user_pages*() + put_page() calls to
> pin_user_pages*() + unpin_user_pages()
Hi,
On 8/24/2020 12:30 PM, Jim Quinlan wrote:
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
We are version
Hi Stefan,
On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote:
> Am 29.07.20 um 16:42 schrieb Maxime Ripard:
> > Hi,
> >
> > On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote:
> >> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
> >>> In order to avoid pixels getting stu
Hi Ville,
This patch is already reviewed by Ilia Mirkin and I have
unit tested it, if it looks good to you could you please merge it?
Thanks
Rohit
> -Original Message-
> From: Ilia Mirkin [mailto:imir...@alum.mit.edu]
> Sent: Monday, March 23, 2020 11:10 AM
> To: Rohit Visavalia
> Cc:
Hi,
On Tue, Aug 04, 2020 at 11:53:37PM +0200, Rikard Falkeborn wrote:
> A number of static variables are not modified and can be made const to
> allow the compiler to put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
Applied, thanks!
Maxime
signature.asc
Description: PGP signa
On 2020/08/25 21:38, Maxime Ripard wrote:
Hi,
On Tue, Aug 25, 2020 at 07:44:03PM +0800, Yu Kuai wrote:
If sun8i_r40_tcon_tv_set_mux() succeed, at_dma_xlate() doesn't have a
corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes:
Hi Clement,
On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote:
> Hi Maxime and All,
>
> On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote:
> >
> > Hi Maxime,
> >
> > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Jul 04, 2020 at 12:25:34PM +0200
On Tue, Aug 25, 2020 at 10:54 AM John Hubbard wrote:
>
> On 8/25/20 1:32 AM, Jens Wiklander wrote:
> > On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
> ...
> >> OK, one more try, this time actually handling the _USER_MAPPED vs.
> >> _KERNEL_MAPPED pages!
> >>
> >> thanks,
> >> John
LSPCON only supports 8 bpc for RGB/YCbCr444.
Set the correct bpp otherwise it renders blank screen.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Le jeudi 20 août 2020 à 18:54 +0300, Laurent Pinchart a écrit :
> Hi Ezequiel,
>
> On Thu, Aug 20, 2020 at 05:36:40AM -0300, Ezequiel Garcia wrote:
> > Hi John,
> >
> > Thanks a ton for taking the time
> > to go thru this.
> >
> > On Mon, 2020-08-17 at 21:13 -0700, John Stultz wrote:
> > > On Su
syzbot is reporting OOB read at vga_8planes_imageblit() [1], for
"cdat[y] >> 4" can become a negative value due to "const char *cdat".
[1]
https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/vga1
Hi Rob,
Thanks for the feedback.
> Subject: Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec:
> Document vcc-supply property
>
> On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> > Document optional vcc-supply property that may be used as VCC source.
> >
> > Signed-off-by: Bi
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
wrote:
>
> On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > [...]
> > > > > Since both threads seem to have petered out, let me suggest in
> > > > > kernel.h:
> > > > >
> > > > > #define cast_out(ptr, container, member) \
> > > > > container
If sun8i_r40_tcon_tv_set_mux() succeed, at_dma_xlate() doesn't have a
corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
Signed-off-by: Yu Kuai
---
drivers/gpu/drm/sun
From: Gerd Hoffmann
When going through a disable/enable cycle without changing the
framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
skip set_scanout if framebuffer didn't change") causes the screen stay
blank. Add a bool to force an update to fix that.
v2: use drm_atomic_
If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux()
doesn't have a corresponding put_device(). Thus add put_device()
to fix the exception handling for this function implementation.
Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
Signed-off-by: Yu Kuai
---
Changes
Hi,
On Tue, Aug 25, 2020 at 07:44:03PM +0800, Yu Kuai wrote:
> If sun8i_r40_tcon_tv_set_mux() succeed, at_dma_xlate() doesn't have a
> corresponding put_device(). Thus add put_device() to fix the exception
> handling for this function implementation.
>
> Fixes: 0305189afb32 ("drm/sun4i: tcon: Add
laurent,
Please review or give some feedback.
On Thu, Aug 13, 2020 at 9:09 PM Vinay Simha B N wrote:
>
> laurent,
>
> The code sequence was a problem. *num_inputs_fmts =
> ARRAY_SIZE(tc_lvds_in_bus_fmts); should come first and then allocate
> the kcalloc.
>
> input_fmts = kcalloc(*num_input_fmts
On Tue, Aug 25, 2020 at 9:27 AM Dinghao Liu wrote:
>
> When radeon_kick_out_firmware_fb() fails, info should be
> freed just like the subsequent error paths.
>
> Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac")
> Signed-off-by: Dinghao Liu
> ---
> drivers/video/fbdev/at
On Mon, Aug 24, 2020 at 05:04:32PM +0200, Jernej Skrabec wrote:
> Following two patches enable Mali400 GPU on Allwinner R40 SoC. At this
> point I didn't add table for frequency switching because it would
> require far more testing and defaults work stable and reasonably well.
>
> Please take a lo
Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
fixed screen flicker for HP Compaq nx9420 but breaks other laptops like
Asus X50SL.
Turns out we also need to favor lower feedback dividers.
Users confirmed this change fixes the regression and doesn't regress the
original fix.
On Tue, 25 Aug 2020 12:58:19 -0400
"Kazlauskas, Nicholas" wrote:
> On 2020-08-22 5:59 a.m., Michel Dänzer wrote:
> > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
> >> On 2020-08-21 12:57 p.m., Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>> Don't check drm_crtc_state::acti
From: Colin Ian King
There is a spelling mistake in a drm_warn message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-08-26 10:24 a.m., Pekka Paalanen wrote:
> On Tue, 25 Aug 2020 12:58:19 -0400 "Kazlauskas, Nicholas"
> wrote:
>
>> On 2020-08-22 5:59 a.m., Michel Dänzer wrote:
>>> On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
On 2020-08-21 12:57 p
Hi Hoegeun,
Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> Hi everyone,
>
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
thanks for providing this.
>
> Rebased on top of next-20200708
On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> wrote:
> >
> > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > [...]
> > > > > > Since both threads seem to have petered out, let me suggest in
> > > > > > kernel.h:
> > > > > >
On Thu, 20 Aug 2020, Maxime Ripard wrote:
> This PR diffstat is pretty massive since we merged 5.9-rc1 and it's not
> (yet?) in drm-next.
>
> I'm not entirely sure how to tackle this (if it causes an issue?).
>
> Let me know, thanks!
Whatever Dave & Daniel say, but previously the rule of thumb h
Hi Hoeguen,
Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
this patch introduces a mandatory clock, please update
brcm,bcm2835-hdmi.yaml
Hi,
On 11/08/2020 05:36, Laurent Pinchart wrote:
>> +{
>> +u32 max_bw, req_bw, bpp;
>> +
>> +bpp = cdns_mhdp_get_bpp(&mhdp->display_fmt);
>> +req_bw = mode->clock * bpp / 8;
>> +max_bw = lanes * rate;
> mode->clock is in kHz, while rate is expressed in 10kHz unit if I'm not
> mista
Hi Andy,
On Tue, Aug 25, 2020 at 5:54 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma add
Add an alternative to drm_encoder_init() that allocates and initializes
an encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_encoder.c | 104 ++
include/drm/drm_encoder.h | 30 +++
Add an alternative to drm_universal_plane_init() that allocates
and initializes a plane and registers drm_plane_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_plane.c | 127
include/drm/drm_plane.h | 42 ++
Add an alternative to drm_crtc_init_with_planes() that allocates
and initializes a crtc and registers drm_crtc_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_crtc.c | 119 -
include/drm/drm_crtc.h | 33
Add an alternative to drm_simple_encoder_init() that allocates and
initializes a simple encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_simple_kms_helper.c | 12
include/drm/drm_simple_kms_helper.h
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on drm-intel/for-linux-next linus/master v5.9-rc2
next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
From: kernel test robot
drivers/gpu/drm/bridge/tc358775.c:488:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
CC: Vinay Simha BN
Signed-off-by: kernel test robot
--
Applied. Thanks!
Alex
On Wed, Aug 26, 2020 at 9:37 AM Dinghao Liu wrote:
>
> When amdgpu_display_modeset_create_props() fails, state and
> state->context should be freed to prevent memleak. It's the
> same when amdgpu_dm_audio_init() fails.
>
> Signed-off-by: Dinghao Liu
> ---
> drivers/gpu/d
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 4961eb60f145 ("drm/ast: Enable atomic modesetting").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
05f13f5b5996 ("drm/a
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 4961eb60f145 ("drm/ast: Enable atomic modesetting").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
05f13f5b5996 ("drm/a
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Build OK!
v5.7.16: Build OK
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 4961eb60f145 ("drm/ast: Enable atomic modesetting").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
05f13f5b5996 ("drm/a
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 4961eb60f145 ("drm/ast: Enable atomic modesetting").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
05f13f5b5996 ("drm/a
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Failed to apply! Possible d
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolut
Hey Keith,
Most of the cool kids prefer gitlab MR, can you open one going forward?
That aside, here is some long overdue input on the patch itself.
My biggest concern that we expose the extension, even when it's not implemented.
The rest are rather minor - more documentation/comments, style fixes
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/d
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/
Hi Dave, hi Daniel,
please pull the following two fixes for the current release cycle. One
fixes a bad interaction with the DRM scheduler, leading to some dma
fences not getting signalled after hitting the job timeout. The other
one fixes a GPU init regression, as apparently one old core doesn't
l
Am 25.08.20 um 06:56 schrieb Joe Perches:
Use semicolons and braces.
Signed-off-by: Joe Perches
Acked-by: Christian König
---
drivers/dma-buf/st-dma-fence.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma
On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
> On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> > wrote:
> > >
> > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > > [...]
> > > > > > > Since both threads s
Signed-off-by: kernel test robot
---
drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0a565d97650cb..0f1d8589ab6c7 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_p
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your
gem_vm_ops and gem_free_object_unlocked function pointer is deprecated.
This patch replace these functions with drm_gem_object_funcs. And
functions used in drm_gem_object_funcs, vkms_gem_vm_ops and
vkms_gem_free_object, are not used other file but vkms_gem.c. So these
goes static functions. When cr
On 26.08.2020 15:40, Tomi Valkeinen wrote:
> The current EDID allocated with drm_get_edid() is freed when the driver
> gets a new EDID, but it is not freed when the driver is removed, causing
> a leak.
>
> Free the EDID (if any) on driver remove.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: An
On 26.08.2020 16:55, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andrzej Hajda
Regards
Andrzej
___
On 26.08.2020 16:55, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andrzej Hajda
Regards
Andrzej
___
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support add
Novatek NT36672a is a generic DSI IC that drives command and video mode
panels. Add the driver for it.
Right now adding support for some Poco F1 phones that have an LCD panel
from Tianma connected with this IC, with a resolution of 1080x2246 that
operates in DSI video mode.
During testing, Benni
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the
Novatek NT36672A display controller; Add support for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.9-rc1 based drm-misc-
On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> LSPCON only supports 8 bpc for RGB/YCbCr444.
>
> Set the correct bpp otherwise it renders blank screen.
Hmm. Does
git://github.com/vsyrjala/linux.git dp_downstream_ports_5
work?
Actually better make that dp_downstream_ports_5^
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
Hi Enric
On Wed, Aug 26, 2020 at 10:15:21AM +0200, Enric Balletbo i Serra wrote:
> The first patch was initially part of the series [1] but for some reason
> was not picked when the series were merged, so I included in this series
> because it is needed to make the others to work properly.
>
> Th
The current EDID allocated with drm_get_edid() is freed when the driver
gets a new EDID, but it is not freed when the driver is removed, causing
a leak.
Free the EDID (if any) on driver remove.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 2 ++
1 file changed, 2 inserti
From: Gowtham Tammana
drm_gem_fb_prepare_fb() extracts fence and attaches to plane state.
The fence info is needed if implicit fencing is used. Add this as
prepare_fb function pointer to plane helper funcs.
Signed-off-by: Gowtham Tammana
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss
Hi Leon, Shuah,
Thanks for the fix. I had this issue pending to fix,
but have been lazy about it, I appreciate you are taking care of it!
On Sat, 7 Mar 2020 at 11:03, Leon He wrote:
>
> From: Leon He
>
> There are two errors in the dmabuf-heap selftest:
> 1. The 'char name[5]' was not initializ
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[If your
Hi Tom,
On 2019-12-21 15:03, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
https:/
https://bugzilla.kernel.org/show_bug.cgi?id=209019
--- Comment #5 from rtmasura+ker...@hotmail.com ---
Since I started getting this I was using the LTS kernel during the day because
this is my work from home machine. I just had it happen with 5.4.60-1-lts. The
virtual machine running on top of the
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/driv
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice thi
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
v5:
* Drop !!()
* Move drm_dp_has_mst() out of header
* Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_read_downstream_info().
Note that when we do this, we also do make some functional changes
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nou
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..a5934064a75ea 100644
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
1 - 100 of 159 matches
Mail list logo
