https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #11 from Coleman Kane (ck...@colemankane.org) ---
Ok scratch those last three messages - I must have mislabeled one of the bisect
cycles, or some other screw up. I still narrowed my search space down, but it
looks like the commit it
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #38 from Petteri Aimonen (j...@kernelbug.mail.kapsi.fi) ---
@krakopo I must say I don't have any idea what could be happening on your
machine. It could be explained if the kernel thread was being pre-empted, but
pre-emption is
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #37 from krak...@protonmail.com ---
I do see ldmxcsr in the disassembly:
81038870 :
81038870: e8 9b 07 03 00 callq 81069010
<__fentry__>
81038875: 48 83 ec 10 sub
Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit f41ed88cbd6f025f7a683a11a74f901555fba11c:
drm/amdgpu/display: use GFP_ATOMIC in dcn20_validate_bandwidth_internal
(2020-08-10 18:09:46 -0400)
are available in the Git repository at:
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #36 from Petteri Aimonen (j...@kernelbug.mail.kapsi.fi) ---
@krakopo The 0020 MXCSR value is also exactly like it was for me before the
bug fix. So something is definitely clearing MXCSR after it should be set to
0x1F80 by
From: Vincent Donnefort
A quick add-on to my earlier fixup series as I realized what the
performance problem was.
This is against Mauro's tree here:
https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master/
For each display cycle, the Kirin960 display IP will generate a
Hello Krzystof,
On Wed, 19 Aug 2020 at 23:21, Krzysztof Kozlowski wrote:
>
> Fix W=1 compile warnings (invalid kerneldoc):
>
> drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member
> 'dmabuf' not described in 'dma_buf_set_name'
Thanks for the patch; I will apply it to
This is against Mauro's tree here:
https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master/
Add support for two color formats (ARGB and ABGR) needed for use
with drm_hwcomposer and AOSP.
NOTE: I see Red/Blue swapped colors with this (and yes I did try
the obvious swap of formats
This is against Mauro's tree here:
https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master/
On reboot we see the following crash:
[ 608.746787] Unable to handle kernel read from unreadable memory at virtual
address 00a8
...
[ 608.822101] CPU: 3 PID: 234 Comm:
This is against Mauro's tree here:
https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master/
A previous patch changed this string to be
"hisilicon,kirin960-dpe", but there are other place where the
code still expects "hisilicon,hi3660-dpe", so change it back.
Cc: Mauro Carvalho
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #35 from krak...@protonmail.com ---
@Petteri
I'm running DragonFly BSD 5.8.1 in my KVM virtual machine.
Here is the dmesg output with the debug info patch applied:
Aug 19 23:18:03 archpad kernel: MXCSR: 0020 XMM3:
On Wed, Aug 19, 2020 at 7:01 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
> >
> > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> > wrote:
> > > So, IMO, the best is to keep it on staging for a while, until those
> > > remaining bugs gets solved.
> > >
>
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #10 from Coleman Kane (ck...@colemankane.org) ---
Trying to do that small change didn't seem to work, so I'm just going to try
seeing if it will work if I just remove that whole commit from the newer
staging-testing I've been working
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Wang Hai
Sent: Wednesday, August 19, 2020 7:34 PM
To: Quan, Evan ; Deucher, Alexander
; Koenig, Christian ;
airl...@linux.ie; dan...@ffwll.ch
Cc: amd-...@lists.freedesktop.org;
Thanks for the feedback.
On Sat, 15 Aug 2020 at 01:00, Imre Deak wrote:
>
> On Wed, Jul 29, 2020 at 04:15:28PM +1000, Sam McNally wrote:
> > As of commit d8bd15b37d32 ("drm/dp_mst: Fix the DDC I2C device
> > registration of an MST port"), DP MST DDC I2C devices are consistently
> > parented to
https://bugzilla.kernel.org/show_bug.cgi?id=208373
Lucas (l.sym...@live.com) changed:
What|Removed |Added
CC||l.sym...@live.com
---
On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> wrote:
> > So, IMO, the best is to keep it on staging for a while, until those
> > remaining bugs gets solved.
> >
> > I added this series, together with the regulator driver and
> > a
On Mon, Aug 3, 2020 at 12:48 AM David Hildenbrand wrote:
>
> [...]
>
> > Well, no v5.8-rc8 to line this up for v5.9, so next best is early
> > integration into -mm before other collisions develop.
> >
> > Chatted with Justin offline and it currently appears that the missing
> > numa information
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
wrote:
> @@ -376,7 +355,7 @@ static int kirin_drm_platform_resume(struct
> platform_device *pdev)
> }
>
> static const struct of_device_id kirin_drm_dt_ids[] = {
> - { .compatible = "hisilicon,hi3660-dpe",
> + { .compatible =
From: Felix Kuehling
[ Upstream commit c0001213d195d1bac83e0744c06ff06dd5a8ba53 ]
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
From: Felix Kuehling
[ Upstream commit c0001213d195d1bac83e0744c06ff06dd5a8ba53 ]
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
From: Felix Kuehling
[ Upstream commit c0001213d195d1bac83e0744c06ff06dd5a8ba53 ]
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
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.1, v5.7.15.
v5.8.1: 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.1, v5.7.15.
v5.8.1: 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.1, v5.7.15.
v5.8.1: 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: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139.
v5.8.1: Build OK!
v5.7.15:
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.1, v5.7.15.
v5.8.1: Failed to apply! Possible dependencies:
05f13f5b5996
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #9 from Coleman Kane (ck...@colemankane.org) ---
I'm going to venture a guess that if I were to reverse the following part of
the change that it would likely "undo" the cause of the problem, but it doesn't
really solve the problem.
On Wed, 19 Aug 2020 13:46:17 +0200, Mauro Carvalho Chehab wrote:
> Add a description of the bindings used by Kirin 960/970 Display
> Serial Interface (DSI) controller and by its Display Engine (DPE).
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../display/hisilicon,hi3660-dpe.yaml
On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller wrote:
>
> Hi Ezequiel,
>
> > Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia
> > :
> >
> > Hello,
> >
> > First of all, I'd like to thank everyone for the great work
> > on ingenic-drm. The driver is in very good shape
> > and a pleasure to work
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #8 from Coleman Kane (ck...@colemankane.org) ---
Update - below is the finding from git bisect:
471c1dd9546df81d259664ac3e2ab0e99169f755 is the first bad commit
commit 471c1dd9546df81d259664ac3e2ab0e99169f755
Author: Reza Amini
On Sun, Jul 12, 2020 at 08:10:12PM +0900, Tetsuo Handa wrote:
> [...]
> @@ -1125,6 +1134,11 @@ int vc_allocate(unsigned int currcons) /* return 0 on
> success */
> if (!*vc->vc_uni_pagedir_loc)
> con_set_default_unimap(vc);
>
> + err = -EINVAL;
> + if (vc->vc_cols >
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_of(ptr, typeof(*container), member)
> > > >
> > > > It does what you
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
wrote:
> So, IMO, the best is to keep it on staging for a while, until those
> remaining bugs gets solved.
>
> I added this series, together with the regulator driver and
> a few other patches (including a hack to fix a Kernel 5.8
> regression
(adding Ville and Imre to the cc here, they might be interested to know about
this, comments down below)
On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > We're going to be doing the same probing process in nouveau for
> >
Hi John.
> > So, IMO, the best is to keep it on staging for a while, until those
> > remaining bugs gets solved.
>
> I'm not sure I see all of these as compelling for pushing it in via
> staging. And I suspect in the process of submitting the patches for
> review folks may find the cause of some
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
wrote:
> Yet, I'm submitting it via staging due to the following reasons:
>
> - It depends on the LDO3 power supply, which is provided by
> a regulator driver that it is currently on staging;
> - Due to legal reasons, I need to preserve the
Hi Mauro.
Some feedback in the following.
Good to see DT schma files and not .txt files - but needs a bit more
work.
Sam
On Wed, Aug 19, 2020 at 01:46:17PM +0200, Mauro Carvalho Chehab wrote:
> Add a description of the bindings used by Kirin 960/970 Display
> Serial Interface (DSI)
The current VKMS blend function ignores alpha channel and just overwrites
vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT
tests, cairo_format_argb32 uses premultiplied alpha (according to
documentation), so
The Kinetic KTD253 backlight driver is controlled with a
single GPIO line, but still supports a range of brightness
settings by sending fast pulses on the line.
This is based off the source code release for the Samsung
GT-S7710 mobile phone.
Cc: Sam Ravnborg
Reviewed-by: Daniel Thompson
Let's use a common.yaml include for the backlight like we do with
the LEDs. The LEDs are inherently incompatible so their bindings
cannot be reused for backlight.
Cc: devicet...@vger.kernel.org
Suggested-by: Sam Ravnborg
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Drop the | for the
This adds device tree bindings for the Kinetic KTD253
white LED backlight driver.
Cc: devicet...@vger.kernel.org
Cc: Sam Ravnborg
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Drop the pointless cargo-culted "default-on" property that
we were not using
- Correct the brightness in the
On Wed, Aug 12, 2020 at 5:46 PM Rob Herring wrote:
> On Wed, Aug 12, 2020 at 2:58 AM Linus Walleij
> wrote:
> >
> > Let's use a common.yaml include for the backlight like we do with
> > the LEDs. The LEDs are inherently incompatible so their bindings
> > cannot be reused for backlight.
> >
> >
Hi Xin Ji.
On Mon, Aug 10, 2020 at 10:35:46PM +0200, Sam Ravnborg wrote:
> Hi Xin Ji.
>
> On Thu, Jul 09, 2020 at 04:31:09PM +0800, Xin Ji wrote:
> > Hi all,
> >
> > The following series add support for the Slimport ANX7625 transmitter, a
> > ultra-low power Full-HD 4K MIPI to DP transmitter
On Wed, 19 Aug 2020 at 23:44, Christian König
wrote:
>
> drm-next reverted the changes to ttm_tt_create() to do the
> NULL check inside the function, but drm-misc-next adds new
> users of this approach.
>
> Re-apply the NULL check change inside the function to fix this.
Where is this problem
On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart
wrote:
> On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
> > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> > > This patch series port the out-of-tree driver for Hikey 970 (which
> > > should also support
I'm now able to reproduce this, looking into it. (The crash looks
actually similar to what was also happening with the next commit,
drm/ttm: make TT creation purely optional v3, but that got reverted
already.)
Roland
Am 19.08.20 um 09:47 schrieb 허종만:
>
> Hi,
>
>
> I'm running Linux guest OS
Hi,
On Wed, Aug 19, 2020 at 10:36 AM Rob Clark wrote:
>
> On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
> > >
> > > From: Jordan Crouse
> > >
> > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These
>
Hi Paul.
On Wed, Aug 19, 2020 at 08:14:12PM +0200, Paul Cercueil wrote:
> There is already a 'struct device' pointer in the drm_panel structure,
> that we can access easily from our priv structure, so there's no need
> for a separate 'dev' field there.
>
> This also allows
Hi
Am 19.08.20 um 11:23 schrieb Tian Tao:
> patch #1 is using the drm_err instead of DRM_ERROR in hibmc_ttm.c
> patch #2 is using the drm_err instead of DRM_ERROR in hibmc_drm_vdac.c
> patch #3 is using the drm_err and drm_dbg_atomic instead of DRM_ERROR
> and DRM_DEBUG_ATOMIC in hibmc_drm_de.c
>
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member
'dmabuf' not described in 'dma_buf_set_name'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or
member 'seqno' not described in 'dma_fence_chain_init'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-fence-chain.c | 1 +
1 file changed, 1 insertion(+)
diff
On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
> >
> > From: Jordan Crouse
> >
> > Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> > devices depend on unique features such as split pagetables,
> > different
On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > 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
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: Jitao Shi
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so call
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: chunhui dai
disable tmds on phy on mt2701 to support other resolutions like 1280x1024
Isn't that worth a Fixes tag?
Regards,
Matthias
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
Hi,
On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
>
> From: Jordan Crouse
>
> Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> devices depend on unique features such as split pagetables,
> different stall/halt requirements and other settings. Identify them
> with a
On Wed, 19 Aug 2020, Markus Elfring wrote:
> > When of_property_read_u32_array() returns an error code,
> > a pairing refcount decrement is needed to keep np's refcount balanced.
>
> Can another imperative wording be helpful for the change description?
>
Hi Chun-Kuang
Two small details below.
Sam
On Wed, Aug 19, 2020 at 11:44:20PM +0800, Chun-Kuang Hu wrote:
> From: CK Hu
>
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Chunfeng Yun
---
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
information.
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Matthias Brugger
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Chunfeng Yun
Reviewed-by: Matthias
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v4:
- Rebase onto 5.9-rc1
- Remove mtk_hdmi_conf_mt8173.
Changes in v3:
- Modify [PATCH v2 3/4] prefix.
On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
> Hi Mauro.
>
> On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> > This patch series port the out-of-tree driver for Hikey 970 (which
> > should also support Hikey 960) from the official 96boards tree:
> >
> >
On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote:
> 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
On Tue, Aug 11, 2020 at 04:04:53PM -0400, 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.
>
> Signed-off-by: Lyude Paul
> ---
>
Hi Mauro.
On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> This patch series port the out-of-tree driver for Hikey 970 (which
> should also support Hikey 960) from the official 96boards tree:
>
>https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
>
> Based on
On Tue, Aug 11, 2020 at 04:04:52PM -0400, Lyude Paul wrote:
> 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
On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> 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:
>
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.9-rc1 next-20200819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
On Tue, Aug 11, 2020 at 04:04:46PM -0400, Lyude Paul wrote:
> 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.
>
Reviewed-by: Sean Paul
> Signed-off-by: Lyude Paul
> ---
>
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
[...]
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> >
> > #define cast_out(ptr, container, member) \
> > container_of(ptr, typeof(*container), member)
> >
>
Hi,
On 13/08/2020 11:36, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
>
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
WARNING: inconsistent lock state
5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: GW
inconsistent {HARDIRQ-ON-W} ->
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Reviewed-by: Lyude Paul
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
On Wed, Aug 19, 2020 at 5:08 AM Michel Dänzer wrote:
>
> On 2020-07-22 7:12 p.m., Alex Deucher wrote:
> > On Wed, Jul 22, 2020 at 10:25 AM Michel Dänzer wrote:
> >> On 2020-07-22 3:10 p.m., Kazlauskas, Nicholas wrote:
> >>> On 2020-07-22 8:51 a.m., Daniel Vetter wrote:
> On Wed, Jul 22,
On Fri, Jul 3, 2020 at 3:01 PM Linus Walleij wrote:
>
> Finalize he conversion of GMA500 to use only GPIO descriptors.
> The GPIO look-up-table is associated with the device directly
> in the GMA500 Medfield chip driver since no explicit platform
> type device (such as in x86/platform/intel-mid)
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
On Wed, Aug 5, 2020 at 10:59 PM wrote:
>
> From: Tom Rix
>
> Reviewing this block of code in cdv_intel_dp_init()
>
> ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ...
>
> cdv_intel_edp_panel_vdd_off(gma_encoder);
> if (ret == 0) {
> /* if this fails, presume the device is
On Wed, Aug 19, 2020 at 07:17:19AM -0600, Jens Axboe wrote:
> On 8/19/20 6:11 AM, Greg KH wrote:
> > On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> >> On 8/18/20 1:00 PM, James Bottomley wrote:
> >>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> On 8/17/20 12:48 PM,
On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
Does
Hi KyongHo,
On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> I have seriously considered CPA in our product but we developed our own
> because of the pool in CPA.
Oh good, I'm glad you considered it :-)
> The high-order pages are required by some specific users like Netflix
> app.
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> >> On 8/17/20 12:48 PM, Kees Cook wrote:
> >>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> On 8/17/20 12:29 PM,
On 19. 08. 20, 14:43, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
>> Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
>
> So if I run drm-tip, no fb.
> If I
Quoting Jani Nikula (2020-08-19 13:34:41)
> On Wed, 19 Aug 2020, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2020-08-19 12:53:53)
> >> In preparation for unconditionally passing the struct tasklet_struct
> >> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
> >> and
On 09. 07. 20, 14:33, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
It's not that exact. The order of modeset_enables and planes is
different. And this causes a regression -- no fb in qemu.
So if I run drm-tip, no fb.
If I revert 73f15a9, it works.
If I then switch the two calls
On Wed, 19 Aug 2020, Chris Wilson wrote:
> Quoting Andy Shevchenko (2020-08-19 12:53:53)
>> In preparation for unconditionally passing the struct tasklet_struct
>> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
>> and from_tasklet() to pass the tasklet pointer
Hi Tomi,
Thank you for the patch.
On Wed, Aug 19, 2020 at 01:30:21PM +0300, Tomi Valkeinen wrote:
> After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
> spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
>
> WARNING: inconsistent lock state
>
Quoting Andy Shevchenko (2020-08-19 12:53:53)
> In preparation for unconditionally passing the struct tasklet_struct
> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Andy Shevchenko
Hi Dinghao,
Thank you for the patch.
On Wed, Aug 19, 2020 at 04:22:28PM +0800, Dinghao Liu wrote:
> When verify_crc_source() fails, source needs to be freed.
> However, current code is returning directly and ends up
> leaking memory.
>
> Fixes: c0811a7d5befe ("drm/crc: Cleanup crtc_crc_open
Add the needed bits for the DRM driver to work with the
Hikey 970 board.
Signed-off-by: Mauro Carvalho Chehab
---
.../boot/dts/hisilicon/hi3670-hikey970.dts| 52 +++
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 6 +
.../boot/dts/hisilicon/hikey970-drm.dtsi | 130
Instead of implementing it at the code, use the default
methods from CMA helper
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git
Use SPMI headers to identify the license of each file.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 1 +
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 +
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 4 ++-
Now that everything is in place, add the driver to the
building system.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/Kconfig | 3 ++
drivers/staging/hikey9xx/Makefile | 1 +
drivers/staging/hikey9xx/gpu/Kconfig | 52 ++-
Do some cleanups at the mode validation code. Right now, there
is a known issue with this driver which makes it to set up
some invalid modes, depending on the display.
We don't know yet what the issue is, so, instead, let's add
a table with the modes which are known to work.
Signed-off-by: Mauro
There are lots of ifdefs checking if the SoC version is
960 or 970. Replace them all by runtime definitions.
With that, the same DRM driver should work with both versions.
The behavior will dynamically change depending on the
OF compatible strings.
Signed-off-by: Mauro Carvalho Chehab
---
From: Xiubin Zhang
Modfiy mipi dsi lanes to improve HDMI compatibility.
Signed-off-by: Xiubin Zhang
Signed-off-by: Liuyao An
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 24 ---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 4
At least on current upstream Kernels, forcing an event parse
during init time isn't needed anymore.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
The I2C buses are not declared at the device tree. As this will
be needed by further patches, add them, keeping all in
disabled state. Per-board settings can override it.
Signed-off-by: Mauro Carvalho Chehab
---
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 71 +++
1 file
1 - 100 of 181 matches
Mail list logo
