Hello
This patchset adds a new set of functions which are open-coded in lot of
place.
Basicly the pattern is always the same, "read, modify a bit, write"
some driver and the powerpc arch already have thoses pattern them as functions.
(like ahci_sunxi.c or dwmac-meson8b)
The first patch rename
On Wed, 24 Oct 2018 07:35:48 +, Corentin Labbe wrote:
> This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and
> setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header.
>
> Signed-off-by: Corentin Labbe
Did you have a look at all the functions defined in bitfield.h?
This patch add a spatch which convert all open coded of
setbits_le32/clrbits_le32/clrsetbits_le32
and their 64 bits counterparts.
Note that 64 and 32_relaxed are generated via
cp scripts/coccinelle/misc/setbits32.cocci
scripts/coccinelle/misc/setbits32_relaxed.cocci
sed -i
This patch convert dwmac-sun8i driver to use all xxxsetbits_le32 functions.
Signed-off-by: Corentin Labbe
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 +--
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
This patch convert meson DRM driver to use all xxxsetbits_le32 functions.
Signed-off-by: Corentin Labbe
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 14 +++---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 33 +++--
This patch adds support for the Armadeus ST0700 Adapt. It comes with a
Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
that it can be connected on the TFT header of Armadeus Dev boards.
Signed-off-by: Sébastien Szymanski
---
.../display/panel/armadeus,st0700-adapt.txt
Since setbits32/clrbits32 work on be32, it's better to remove ambiguity on
the used data type.
Signed-off-by: Corentin Labbe
---
arch/powerpc/include/asm/fsl_lbc.h| 2 +-
arch/powerpc/include/asm/io.h | 4 +-
arch/powerpc/platforms/44x/canyonlands.c | 4 +-
To make use of the new eLCDIF DRM driver OF graph description is
required. Describe the display using OF graph nodes.
Signed-off-by: Sébastien Szymanski
---
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 37 ++---
1 file changed, 16 insertions(+), 21 deletions(-)
diff
This patch convert meson stmmac glue driver to use all xxxsetbits_le32
functions.
Signed-off-by: Corentin Labbe
Reviewed-by: Neil Armstrong
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 ---
1 file changed, 22 insertions(+), 34 deletions(-)
diff --git
This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and
setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header.
Signed-off-by: Corentin Labbe
---
include/linux/setbits.h | 84 +
1 file changed, 84 insertions(+)
create mode 100644
This patch converts ahci_sunxi to use xxxsetbits_le32 functions
Signed-off-by: Corentin Labbe
---
drivers/ata/ahci_sunxi.c | 62 +++-
1 file changed, 17 insertions(+), 45 deletions(-)
diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
index
Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
Reviewed-by: Chunming Zhou
NAK, GFP_ATOMIC should be avoided.
The correct solution is to move the allocation out of the spinlock or
drop the lock and reacquire.
Christian.
-Original Message-
From: Julia Lawall
Sent:
Op 24-10-18 om 19:17 schreef Matt Roper:
> On Tue, Oct 23, 2018 at 01:39:10PM +0200, Maarten Lankhorst wrote:
>>
>> Op 02-10-18 om 13:15 schreef Stanislav Lisovskiy:
>>> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
>>> specification.
>>>
>>> v2: Edited commit message, removed
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
This patch defines the hdcp2.2 protocol messages for authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
v4:
Style and spellings are fixed [Uma]
v5:
Fix for macros.
v6:
comment for Type
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
v7:
No changes
Signed-off-by:
This patch adds HDCP register definitions for HDMI and DP HDCP
adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where as HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field definitions are replaced by macros. [Tomas and Jani]
This series defines the HDCP2.2 authentication messages at drm header
along with intel specific HDCP2.2 registers. And introduces a
structure intel_hdcp to wrap all hdcp related variables into it.
These patches were previously reviewed at
https://patchwork.freedesktop.org/series/38254/
On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This patch enables decompression support in sink device
> before link training and disables the same during the
> DDI disabling.
>
> v2:(From Manasi)
> * Change the enable/disable function to take
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #18 from Robert Strube ---
Created attachment 142204
--> https://bugs.freedesktop.org/attachment.cgi?id=142204=edit
sudo cat /proc/iomem *with* eGPU connected at boot
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142205|fresh dmesg log booting |fresh dmesg log booting
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #19 from Robert Strube ---
Created attachment 142205
--> https://bugs.freedesktop.org/attachment.cgi?id=142205=edit
fresh dmesg log booting system *wite* eGPU connected at boot
--
You are receiving this mail because:
You are the
在 2018/10/25 18:36, Maarten Lankhorst 写道:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to
The DRM framework provides a generic way to report underrun errors.
Let's implement the necessary hooks to support it in the VC4 driver.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- New patch
---
drivers/gpu/drm/vc4/vc4_drv.h | 3 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 71
Display controllers usually provide a lot features like overlay planes,
hardware scalers, hardware rotations, ...
Most of the time those features work just fine when enabled
independently, but activating all of them at the same time tend to
show other limitations like the limited memory bus or
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.
This patch is trying to model the
Hello,
This is the 2nd version of the VC4 load tracker patch.
Daniel, as you suggested, I've implemented a generic infrastructure to
track and report underrun errors (patch 1). Not sure this is what you
had in mind, but it seems to do the job for my use case, and should
allow me to easily track
Hi Dave,
One fix to avoid applying link retraining workaround on eDP monitors
that was missing Fixes: (kindly pointed out by Jani) in addition
to the patches in previous PR.
I also got GVT PR for -next-fixes, but it had an issue with S-o-bs,
so I'll include it then in -fixes pull.
Regards,
Since -rc1 we're hitting a bunch of lockdep splats using the new
cross-release stuff around the 2 kthread completions. In all cases
they are because totally independent uses of kthread are mixed up by
lockdep into the same locking class, creating artificial deadlocks.
Fix this by converting
This reverts the following commits:
commit 527187d28569e39c5d489d6306d3b79605cf85a6
Author: Ingo Molnar
Date: Mon Jan 8 17:27:19 2018 +0100
locking/lockdep: Remove cross-release leftovers
commit dba04eb76df982703fefc021a4d278347b6176a9
Author: David Sterba
Date: Mon Jan 8 16:27:31
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 82bb1a939c0e..744840e5636e 100644
---
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them.
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c
This was originally added in 7e7844226f10 ("lockdep: allow to disable
reclaim lockup detection") but a git log -G "GFP_NOLOCKDEP" indicates
it was never used.
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Mel Gorman
Cc: Daniel Vetter
Cc: "Levin, Alexander (Sasha Levin)"
Cc:
Den 03.10.2018 21.24, skrev Neil Armstrong:
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks.
Den 27.09.2018 13.45, skrev Yannick FERTRE:
Hi Noralf,
many thanks for your patch.
Acked-by: Yannick Fertré
Applied to drm-misc-next, thanks.
Noralf.
On 09/08/2018 03:46 PM, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev
Give this a nice summary,
drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 11:21:05)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=107333
--- Comment #4 from Benjamin Hodgetts ---
To anyone checking, this is still an issue with versions:
Kernel 4.18.16, LLVM 8.0.0, Mesa 18.3.0-devel, XOrg 1.20.2.
Monitor is connected, but powered off:
Screen 0: minimum 320 x 200, current 1024
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142200|lspci (no eGPU) |lspci with eGPU *not*
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #16 from Robert Strube ---
Created attachment 142202
--> https://bugs.freedesktop.org/attachment.cgi?id=142202=edit
fresh dmesg log booting system *without* eGPU
--
You are receiving this mail because:
You are the assignee for
Am 25.10.18 um 12:36 schrieb Maarten Lankhorst:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I
On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner
wrote:
>
> Signed-off-by: Christian Gmeiner
> ---
> xf86drm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 10df682b..4ee1337b 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3516,6 +3516,8 @@ static int
Am 24.10.18 um 16:55 schrieb Jordan Crouse:
> On Wed, Oct 24, 2018 at 07:10:23PM +0530, Sharat Masetty wrote:
>> Hi,
>>
>> Can you please review this and share your thoughts on this approach. We
>> primarily need a clean way to release the finished fence in case the job
>> was not pushed to the
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #9 from John Galt ---
R600_DEBUG=nir works around this issue. If requested, I can provide apidoc of
this rendering issue.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #14 from Robert Strube ---
Created attachment 142200
--> https://bugs.freedesktop.org/attachment.cgi?id=142200=edit
lspci (no eGPU)
lspci -t -nn -v output when the eGPU is *not* connected.
--
You are receiving this mail
On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> DSC PPS secondary data packet infoframes are filled with
> DSC picure parameter set metadata according to the DSC standard.
> These infoframes are sent to the sink device and used during DSC
> decoding.
>
> v2:
> * Rebase ond
On Wed, Oct 24, 2018 at 03:28:33PM -0700, Manasi Navare wrote:
> Infoframes are used to send secondary data packets. This patch
> adds support for DSC Picture parameter set secondary data packets
> in the existing write_infoframe helpers.
>
> v2:
> * Rebase on drm-tip (Manasi)
>
> Cc: Jani
On Wed, Oct 24, 2018 at 03:28:36PM -0700, Manasi Navare wrote:
> Display Stream Splitter registers need to be programmed to enable
> the joiner if two DSC engines are used and also to enable
> the left and the right DSC engines. This happens as part of
> the DSC enabling routine in the source in
https://bugzilla.kernel.org/show_bug.cgi?id=201505
--- Comment #5 from Jan Ziak (http://atom-symbol.net)
(0xe2.0x9a.0...@gmail.com) ---
Created attachment 279151
--> https://bugzilla.kernel.org/attachment.cgi?id=279151=edit
bisect.log
I bisected the issue but encountered some inconsistencies
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #15 from Robert Strube ---
Created attachment 142201
--> https://bugs.freedesktop.org/attachment.cgi?id=142201=edit
sudo cat /proc/iomem when eGPU *not* connected
sudo cat /proc/iomem when eGPU *not* connected
--
You are
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #1 from Nicholas Kazlauskas ---
Thanks for the bisection.
Would you mind posting a full dmesg log for your 4.18.8 kernel?
--
You are receiving this mail because:
You are the assignee for the
On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> whereas all other transcoders use the power wells associated with the
> transcoders for VDSC.
> This patch adds a helper to obtain correct power domain depending
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> Select CONFIG_TOUCHSCREEN_GOODIX so that we can have functional touch
> screen by default on Digi International's AUO/Goodix LCD accessory kit used
> with the ConnectCore 6UL SBC Pro (ccimx6ulsbcpro) board.
>
> Signed-off-by: Alex Gonzalez
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> We used an oscilloscope to observe the actual polarity of the
> DI's pixel clock, and saw the following:
>
> DI_GENERAL bit 17 is SET:
> pixel data is stable on the pixel clock's FALLING
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a
Eric Anholt writes:
> I was going to start working on making the vc4 driver work with
> tinydrm panels, but it turned out tinydrm didn't have the panel I had
> previously bought. So, last night I ported the fbtft staging
> driver over to DRM.
>
> It seems to work (with DT at
>
Sean Paul writes:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> This is just to collect feedback on this idea, and see whether the
>> overall dri-devel community stands on all this. I think the past few
>> cross-vendor uapi extensions all came with igts
Am Do., 25. Okt. 2018 um 15:35 Uhr schrieb Emil Velikov
:
>
> On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner
> wrote:
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > xf86drm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Alex Deucher changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #1
Quoting Chunming Zhou (2018-10-25 16:08:31)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
>
On Thu, Oct 25, 2018 at 12:10 PM Alex Gonzalez wrote:
>
> The ConnectCore 6UL SBC Pro has an AUO/Goodix LCD accessory kit that is
> connected on the LVDS interface through an on-board LVDS transceiver.
>
> This change adds support for the touch interface.
>
> Signed-off-by: Alex Gonzalez
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> This change adds support for the AUO G101EVN010 lcdif panel for the
> mxsfb DRM driver.
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
>
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
Op 25-10-18 om 14:01 schreef Chunming Zhou:
>
> 在 2018/10/25 18:36, Maarten Lankhorst 写道:
>> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>>> 389 but uses
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Bug ID: 108554
Summary: In kernel 4.14.59, monitor resolution is detected
correctly. In kernels after that, they are not
detected correctly.
Product: DRI
On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach
On Fri, Oct 05, 2018 at 05:52:18PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel driver used in MSM reference
> platforms. This panel driver supports both single DSI and dual
> DSI modes.
>
> However, this patch series adds support only for dual DSI mode.
>
> Changes in v10:
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux
On Wed, Oct 24, 2018 at 11:43:11AM -0700, Eric Anholt wrote:
> This adds a new binding for Himax HX8357D display panels. It includes
> a compatible string for one display (more can be added in the future).
>
> The YX350HV15 panel[1] is found in the Adafruit PiTFT 3.5" Touch
> Screen for Raspberry
On Wed, 24 Oct 2018 14:54:56 +0200, =?UTF-8?q?S=C3=A9bastien=20Szymanski?=
wrote:
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be connected on the TFT header of Armadeus Dev boards.
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750]
IMPORTANT -
As a note: I have not had the customer who this second patch is for test
this yet, I'm sending this ahead of time to make sure this is something
that isn't too crazy for upstream to accept. I'm not planning on pushing
this after review until I've verified this actually fixes
Quoting Chris Wilson (2018-10-25 21:20:21)
> Quoting Chris Wilson (2018-10-25 21:15:17)
> > Quoting Christian König (2018-10-04 14:12:43)
> > > No need for that any more. Just replace the list when there isn't enough
> > > room any more for the additional fence.
> >
> > Just a heads up. After
Den 25.10.2018 18.29, skrev Eric Anholt:
Eric Anholt writes:
I was going to start working on making the vc4 driver work with
tinydrm panels, but it turned out tinydrm didn't have the panel I had
previously bought. So, last night I ported the fbtft staging
driver over to DRM.
It seems to
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #17 from Robert Strube ---
Created attachment 142203
--> https://bugs.freedesktop.org/attachment.cgi?id=142203=edit
lspci *with* eGPU attached at boot
--
You are receiving this mail because:
You are the assignee for the
On Mon, Oct 22, 2018 at 01:46:37PM -0700, Douglas Anderson wrote:
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> Remove some duplicated include.
>
> Signed-off-by: YueHaibing
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
> drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4
>
On 2018-10-25 11:45, Doug Anderson wrote:
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #2 from davide26...@gmail.com ---
Created attachment 142207
--> https://bugs.freedesktop.org/attachment.cgi?id=142207=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
On Thu, Oct 25, 2018 at 05:22:18PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> > A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> > whereas all other transcoders use the power wells associated with the
> > transcoders for
On Thu, Oct 25, 2018 at 05:03:06PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> > From: Gaurav K Singh
> >
> > This patch enables decompression support in sink device
> > before link training and disables the same during the
> > DDI disabling.
>
On Wed, Oct 24, 2018 at 06:28:02PM -0400, Lyude Paul wrote:
> On Wed, 2018-10-24 at 15:28 -0700, Manasi Navare wrote:
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
This patchset moves the drivers using the CMA helper fully over to the
generic fbdev emulation.
These are the remaining patches that didn't get a driver maintainer ack
or has been rebased.
For context, this is part 1 of the generic fbdev emulation:
drm: Add generic fbdev emulation
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
1 - 100 of 174 matches
Mail list logo
