Hi Paul.
On Wed, Aug 26, 2020 at 11:58:41PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
>
Hi Stefan,
Thank you for your review.
On 8/26/20 7:04 PM, Stefan Wahren wrote:
> 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
This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't
enabled. When running igt test kms_cursor_crc just after vkms module, the
warning raised like below. Initial value of vblank time is zero and
hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module
https://bugzilla.kernel.org/show_bug.cgi?id=209019
--- Comment #7 from rtmasura+ker...@hotmail.com ---
Created attachment 292183
--> https://bugzilla.kernel.org/attachment.cgi?id=292183=edit
Xorg.0.log
Found the second place for the log, let me know if it helps at all
--
You are receiving
On Wed, Aug 26, 2020 at 05:49:54PM -0300, Melissa Wen wrote:
Hi Melissa!
Thanks for review.
> Hi Sidong,
>
> Thanks for this patch.
>
> The code looks good to me; however, I see some issues in the patch
> format and commit message. Please, see inline comments.
>
> On 08/25, Sidong Yang wrote:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: dff7bd1a712d1fa6fb6289e38de0769dc8b5d1b4
commit: 10be8791067fc672e44fcaa7afb886390909a0c0 [628/1509] drm/amdkfd: Support
Sienna_Cichlid KFD v4
config: x86_64-randconfig-s022-20200826 (attached as .config)
compiler
Hi Gowtham,
Thank you for the patch.
On Wed, Aug 26, 2020 at 04:44:09PM +0300, Tomi Valkeinen wrote:
> 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
Hi Dave and Daniel,
here goes the first pull request towards 5.10:
As requested, the gem patches have been separated into
a drm-intel/topic/drm-intel-gem-next that will be sent separately
by the gem team later.
Thanks,
Rodrigo.
drm-intel-next-2020-08-24-1:
UAPI Changes:
- Introduce a
Hi Tomi,
Thank you for the patch.
On Wed, Aug 26, 2020 at 04:40:17PM +0300, 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
Hi, Wang Hai:
Chun-Kuang Hu 於 2020年8月21日 週五 上午7:23寫道：
>
> Hi, Wang Hai:
>
> Wang Hai 於 2020年8月19日 週三 上午11:00寫道：
> >
> > Remove mtk_drm_ddp.h which is included more than once
> >
>
> Reviewed-by: Chun-Kuang Hu
>
Applied to mediatek-drm-fixes [1], thanks.
[1]
Hi, Jitao:
Chun-Kuang Hu 於 2020年8月18日 週二 下午10:45寫道：
>
> Hi, Jitao:
>
> Jitao Shi 於 2020年8月18日 週二 上午10:41寫道：
> >
> > On Tue, 2020-08-18 at 07:42 +0800, Chun-Kuang Hu wrote:
> > > Hi, Jitao:
> > >
> > > Jitao Shi 於 2020年8月17日 週一 下午9:07寫道：
> > > >
> > > > horizontal_backporch_byte should be hbp *
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong
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 Sidong,
Thanks for this patch.
The code looks good to me; however, I see some issues in the patch
format and commit message. Please, see inline comments.
On 08/25, Sidong Yang wrote:
> From: Sidong Yang , Haneen Mohammed
>
You need to fix the Author name.
>
> When
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.9-rc2
next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us
Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.9-2020-08-26
for you to fetch
https://bugzilla.kernel.org/show_bug.cgi?id=209019
--- Comment #6 from rtmasura+ker...@hotmail.com ---
Hmm, new wire did not help. And it always recovers during shutdown of the
kernel, so when it leaves graphical mode. I don't think that rules out
hardware, though, so still testing.
Also didn't
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
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong
On Wed, 26 Aug 2020 23:47:31 +0500
Bilal Wasim wrote:
> On Mon, 24 Aug 2020 19:51:55 +0500
> Bilal Wasim wrote:
[...]
>
> Can this simple patch be merged?
You sent it two days ago. During a major community conference. Please be
patient, somebody will get to it when they have a chance.
Hi Enric.
On Wed, Aug 26, 2020 at 10:15:26AM +0200, Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> ->
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
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;
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
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
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
---
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
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
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
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
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
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")
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
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
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,
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
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
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
---
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
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
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
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
---
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
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:
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 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
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
---
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
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.
>
>
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 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, 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
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
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
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
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
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:
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
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
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
+++
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> ---
>
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
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
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
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
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
Hi,
On 11/08/2020 05:36, Laurent Pinchart wrote:
>> +{
>> +u32 max_bw, req_bw, bpp;
>> +
>> +bpp = cdns_mhdp_get_bpp(>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
> mistaken.
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
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
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:
> > > > > >
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
-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
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
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
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
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, 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
> ---
>
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
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
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
---
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 =
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:
1 - 100 of 157 matches
Mail list logo
