https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #19 from Jan Burgmeier ---
Hi,
the video looks good. I don't know why you do not see the error. I am unable to
get a picture after boot because the says "Frequency out of range".
At the start of next week I will retest and give mor
On Tue, Nov 13, 2018 at 11:47 PM Lyude Paul wrote:
>
> Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
> accidentally introduced into DRM two years ago.
>
> Pretend we have a topology like this:
>
> |- DP-1: mst_primary
>|- DP-4: active display
>|- DP-5: disconnect
On Wed, Nov 21, 2018 at 10:35:10PM +0100, Daniel Vetter wrote:
> Ever since
>
> commit cb6458f97b53d7f73043206c18014b3ca63ac345
> Author: Daniel Vetter
> Date: Thu Aug 8 15:41:34 2013 +0200
>
> drm: remove procfs code, take 2
>
> Having the code shared between procfs and debugfs in the se
On Wed, Nov 21, 2018 at 06:46:57PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 21, 2018 at 05:22:49PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 21, 2018 at 5:16 PM Ville Syrjälä
> > wrote:
> > >
> > > On Wed, Nov 21, 2018 at 04:19:36PM +0100, Daniel Vetter wrote:
> > > > On Wed, Nov 21, 2018 at 01
On Wed, Nov 21, 2018 at 08:21:29PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday, 21 November 2018 11:42:33 EET Daniel Vetter wrote:
> > On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote:
> > > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos wrote:
> > >> One of the thin
On Thu, Nov 22, 2018 at 02:33:29AM -0300, Sergio Correia wrote:
> When drm_new_set_master() fails, set is_master to 0, to prevent a
> possible NULL pointer deref.
>
> Here is a problematic flow: we check is_master in drm_is_current_master(),
> then proceed to call drm_lease_owner() passing master.
On Wed, Nov 21, 2018 at 05:56:42PM +0100, Noralf Trønnes wrote:
> On drm_driver->last_close the generic fbdev emulation will restore fbdev
> regardless of it being used or not. This is a problem for e-ink displays
> which don't want to be overwritten with zeroes when DRM userspace closes.
>
> Amen
On Wed, Nov 21, 2018 at 07:02:15PM +0100, Noralf Trønnes wrote:
>drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap':
> >> drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes
> >> is larger than 1024 bytes [-Wframe-larger-than=]
>
> Fix by allocating on the heap
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.
MDSS is one of the interconnect consumers which uses the interconne
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (Sean Paul)
Signed-off-b
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- none
Changes in v3:
- Remove common property definitions (Rob Herring)
On Thu, Nov 22, 2018 at 09:44:17AM +0800, Qiang Yu wrote:
> Render like lima will attach a fence to the framebuffer
> dma_buf, display like sun4i should wait it finish before
> show the framebuffer. Otherwise tearing will be observed.
>
> Signed-off-by: Qiang Yu
Thanks for submitting this fix, a
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.
MDSS is one of
From: Oleksandr Andrushchenko
based frontends. Currently the frontends which implement
similar code for sharing big buffers between frontend and
backend are para-virtualized DRM and sound drivers.
Both define the same way to share grant references of a
data buffer with the corresponding backend w
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/Kconfig | 1 +
sound/xen/Makefile | 1 -
sound/xen/xen_snd_front.c
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/Kconfig | 1 +
drivers/gpu/drm/xen/Makefile | 1 -
drivers/gp
On 21/11/2018 18:15, Neil Armstrong wrote:
> Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
> a warning when ctrc is disabled :
> " driver forgot to call drm_crtc_vblank_off()"
>
> But, the vsync IRQ was not totally disabled due the transient hardware
> state and speci
This reverts commit 0efd2d2f68cd5dbddf4ecd974c33133257d16a8e.
It's still causing problems for V3D.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/schedu
Now that the plane code takes the underscan setup into account, we can
safely attach the underscan props to the HDMI connector.
We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.
Note that these underscan props match pretty well the
overscan_{left,right
Applying an underscan setup is just a matter of scaling all planes
appropriately and adjusting the CRTC X/Y offset to account for the
horizontal and vertical border.
Create an vc4_plane_underscan_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are ready
Hello,
This is an attempt at providing generic support for underscan connector
props. We already have 3 drivers defining the same underscan, underscan
vborder and underscan hborder properties (amd, radeon and nouveau) and
I am about to add a new one, hence my proposal to put the prop parsing
code
We have 3 drivers defining the "underscan", "underscan hborder" and
"underscan vborder" properties (radeon, amd and nouveau) and we are
about to add the same kind of thing in VC4.
Define generic underscan props and add new fields to the drm_connector
state so that the property parsing logic can be
Am 22.11.18 um 07:52 schrieb zhoucm1:
On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline point in drm_syncobj_find_fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff -
This reverts commit 0efd2d2f68cd5dbddf4ecd974c33133257d16a8e.
It's still causing problems for V3D.
v2: keep rearming the timeout.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --
Hi Dave,
Here's the -fixes for 4.20-rc4. Stuck backlight/flickering
fix for DSI screen and GPU hang fix for SNB are the main
user visible ones.
Then two more fixes to prevent GPU hangs in more rare
scenarios.
Regards, Joonas
***
drm-intel-fixes-2018-11-22:
- Fix for fastboot DSI panel boot tim
On Tue 20-11-18 15:12:54, Dan Williams wrote:
> devm_memremap_pages() is a facility that can create struct page entries
> for any arbitrary range and give drivers the ability to subvert core
> aspects of page management.
>
> Specifically the facility is tightly integrated with the kernel's memory
Hi Jerome,
Bit late reply, but here goes :)
We're working quite hard to avoid pinning any pages unless they're in
the GPU page tables. And when they are in the GPU page tables, they must
be pinned for whole of that duration, for the reason that our GPUs can
not take a fault. And to avoid thrashin
https://bugs.freedesktop.org/show_bug.cgi?id=108832
Bug ID: 108832
Summary: Cursor flickering on switching between cursor types
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108832
--- Comment #1 from Dieter Nützel ---
Maybe duplicate of Bug #106175.
Can you please verify if patch from comment #55,
attachment 142558 solve it?
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, Nov 22, 2018 at 03:59:50PM +0200, Joonas Lahtinen wrote:
> Hi Jerome,
>
> Bit late reply, but here goes :)
>
> We're working quite hard to avoid pinning any pages unless they're in
> the GPU page tables. And when they are in the GPU page tables, they must
> be pinned for whole of that dur
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #58 from Nicholas Kazlauskas ---
(In reply to Brandon Wright from comment #55)
> Created attachment 142558 [details] [review]
> Patch that "fixes" the problem.
>
> I've attached a patch that fixes the problem for me. It copies parts
On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Use page directory based shared buffer implementation
> now available as common code for Xen frontend drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/Kco
From: Ville Syrjälä
For real commits we WARN if ->hw_done hasn't been completed by the time
drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for
the fake commit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
1 file changed, 3 insertions(+),
From: Ville Syrjälä
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the fake_commit in step 1
and we don't complete the fake_commit-> flip
Den 22.11.2018 10.06, skrev Daniel Vetter:
On Wed, Nov 21, 2018 at 07:02:15PM +0100, Noralf Trønnes wrote:
drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap':
drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes is
larger than 1024 bytes [-Wframe-larger-than
Op 22-11-18 om 15:34 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> Consider the following scenario:
> 1. nonblocking enable crtc
> 2. wait for the event
> 3. nonblocking disable crtc
>
> On i915 this can lead to a spurious -EBUSY from step 3 on
> account of non-enabled planes getting the fake_c
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #59 from bmil...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #58)
> (In reply to Brandon Wright from comment #55)
> > Created attachment 142558 [details] [review] [review]
> > Patch that "fixes" the problem.
> >
> > I
On Thu, 22 Nov 2018 11:02:30 +0100,
Oleksandr Andrushchenko wrote:
>
> @@ -214,12 +221,19 @@ static void stream_clear(struct
> xen_snd_front_pcm_stream_info *stream)
> stream->out_frames = 0;
> atomic_set(&stream->hw_ptr, 0);
> xen_snd_front_evtchnl_pair_clear(stream->evt_pair);
https://bugzilla.kernel.org/show_bug.cgi?id=201763
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
From the dmesg output, it looks like the AMD GPU is powered off most of the
time. Do the freezes happen when you explicitly use it for something, e.g. for
a game via DRI_PRIME=1?
--
You
On Wed, Nov 21, 2018 at 10:33:18AM +0100, Daniel Vetter wrote:
On Wed, Nov 21, 2018 at 10:31 AM Daniel Vetter wrote:
On Tue, Nov 13, 2018 at 12:52:14AM -0500, Sasha Levin wrote:
> From: "Lee, Shawn C"
>
> [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
>
> BOE panel (ID: 0x0771)
Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
a warning when ctrc is disabled :
" driver forgot to call drm_crtc_vblank_off()"
But, the vsync IRQ was not totally disabled due the transient hardware
state and specific interrupt line, thus adding proper IRQ masking from
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #60 from Brandon Wright ---
> There are larger problems within amdgpu_dm's commit tail that if addressed
> should resolve this issue for compton I'd imagine.
Honestly, I don't care about compton. I don't think you realize the effect
https://bugs.freedesktop.org/show_bug.cgi?id=102637
erhar...@mailbox.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Nov 22, 2018 at 05:38:58PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 22, 2018 at 02:30:13PM +0100, Michal Hocko wrote:
> > Whoever needs a wrapper around arch_add_memory can do so because this
> > symbol has no restriction for the usage.
>
> arch_add_memory is not exported, and it real
On Thu, Nov 22, 2018 at 02:30:13PM +0100, Michal Hocko wrote:
> Whoever needs a wrapper around arch_add_memory can do so because this
> symbol has no restriction for the usage.
arch_add_memory is not exported, and it really should not be.
___
dri-devel m
Hi all,
We're having some good fun with the i915 mmu notifier (it deadlocks), and
I think it'd be very useful to have a bunch more runtime debug checks to
catch screw-ups.
I'm also working on some lockdep improvements in gpu code (better
annotations and stuff like that). Together with this series
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. But
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
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.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job d
Quoting Daniel Vetter (2018-11-22 16:51:04)
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
Most callers could handle the failure correctly. It looks like the
fa
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #18 from freedesk...@nuclearsunshine.com ---
I just hit this as well with 4.19 on Fedora and a R9 390X - Grub shows fine,
then no video output after that (monitor goes into power save), and boot
doesn't seem to continue (no disk activ
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #61 from tempel.jul...@gmail.com ---
Thanks a lot @ Brandon Wright, your patch really does the trick. I also totally
agree on your opinion that it should be mainlined as at least a temporary
solution (and also get backported to older
Hi Boris,
Just because I happened to read the docs in here, one typo below:
On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
>We have 3 drivers defining the "underscan", "underscan hborder" and
>"underscan vborder" properties (radeon, amd and nouveau) and we are
>about to add the
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #51 from Allan ---
Tried to install the RX480 on the other PC : the card is too big that it
touches the RAM slot's tabs. Can't install it.
In time, seems like the errors delay a little bit when setting
randomize_va_space=0. Was test
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
>
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #62 from Brandon Wright ---
(In reply to tempel.julian from comment #61)
> I just noticed that it works fine with xf86-video-amdgpu driver, but with
> modesetting driver, xorg or the driver freezes when starting/logging in. Not
> sur
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> 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.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger, and
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #19 from Jim Haddad ---
This happened to me 7 days ago when Fedora replaced kernel-4.18.18-300.fc29
with kernel-4.19.2-300.fc29. Also on kernel-4.19.3-300.fc29 from yesterday.
On a different hard drive I tried rawhide and kernel-4
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #17 from Shmerl ---
(In reply to Nicholas Kazlauskas from comment #13)
>
> This does help narrow down the problem, thanks.
Is there any chance of fixing this in 4.20?
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #63 from bmil...@gmail.com ---
(In reply to Brandon Wright from comment #62)
> (In reply to tempel.julian from comment #61)
> > I just noticed that it works fine with xf86-video-amdgpu driver, but with
> > modesetting driver, xorg or
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #52 from fin4...@hotmail.com ---
To prevent random kernel lock ups with Ryzen, fix this with bios, set to
Typical Current Idle in the bios Advanced/AMD CBS menu.
Use latest AMD wip kernel and Oibaf ppa Mesa. Disable display composti
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #53 from fin4...@hotmail.com ---
Created attachment 142573
--> https://bugs.freedesktop.org/attachment.cgi?id=142573&action=edit
AMD wip kernel config with 1000Hz timer
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #64 from Nicholas Kazlauskas ---
Created attachment 142574
--> https://bugs.freedesktop.org/attachment.cgi?id=142574&action=edit
0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch
This patch is similar to the async_up
From: Philip Yang
[ Upstream commit c837243ff4017f493c7d6f4ab57278d812a86859 ]
The bug limits the IH ring wptr address to 40bit. When the system memory
is bigger than 1TB, the bus address is more than 40bit, this causes the
interrupt cannot be handled and cleared correctly.
Reviewed-by: Christi
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #65 from bmil...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #64)
> Created attachment 142574 [details] [review]
> 0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch
>
> This patch is similar to the async
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #66 from Brandon Wright ---
(In reply to bmilreu from comment #65)
> Is there an easy way to backport this to 4.19 mainline? Would be very useful
> to integrate the fix into stable kernels.
>
> As it is currently it wont work on 4.1
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/Makefile
between commit:
2bb42410b1bd ("drm: Remove drm_global.{c,h} v2")
from the drm tree and commit:
c6fdea6e1a19 ("drm: Merge drm_info.c into drm_debugfs.c")
from the drm-misc tree.
I fixed it
Hi,
I have recently tried to use dpm=1 with the amdgpu driver for the 4.19.x
kernel, but unfortunately the screen just went black. This is a regression
from the 4.18.x kernel.
I have attached the full dmesg log, but the relevant section look to be:
[8.958679] WARNING: CPU: 0 PID: 320 at driv
https://bugs.freedesktop.org/show_bug.cgi?id=108843
Bug ID: 108843
Summary: Laptop with ATI RX 580 doesn't turn the screen on when
resuming.
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (
https://bugs.freedesktop.org/show_bug.cgi?id=108843
--- Comment #1 from alex14...@yahoo.com ---
Created attachment 142583
--> https://bugs.freedesktop.org/attachment.cgi?id=142583&action=edit
Kernel config file
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi Linus,
Regular drm fixes pull for rc4.
amdgpu: Vega20 fixes, firmware loading fix, panel display fix, override fix
i915: Sandybridge lockup fix, fastboot DSI panel fix, GPU hang on
Broxton, GPU reloc fixes on pineview/bearlake
ast: screen blurring fix, cursor appearance fix
udmabuf: mmap fix
v
Hi Helen,
On Fri, Nov 23, 2018 at 8:31 AM Helen Koike wrote:
>
> Hi Tomasz,
>
> On 11/20/18 4:48 AM, Tomasz Figa wrote:
> > Hi Helen,
> >
> > On Tue, Nov 20, 2018 at 4:08 AM Helen Koike
> > wrote:
> >>
> >> From: Enric Balletbo i Serra
> >>
> >> Add support to async updates of cursors by using
On 2018年11月22日 19:30, Christian König wrote:
Am 22.11.18 um 07:52 schrieb zhoucm1:
On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline point in drm_syncobj_find_fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 10 +-
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=108844
Bug ID: 108844
Summary: not a crical prblem
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: All
Status: NEW
Severity: minor
Priorit
https://bugs.freedesktop.org/show_bug.cgi?id=108845
Bug ID: 108845
Summary: login button not working as expected
Product: DRI
Version: DRI git
Hardware: All
OS: All
Status: NEW
Severity: normal
P
https://bugs.freedesktop.org/show_bug.cgi?id=108845
jyotiba changed:
What|Removed |Added
URL||http://www.newtours.demoaut
Hi Michael,
On Fri, Nov 23, 2018 at 1:58 PM Michael Zoran wrote:
>
> On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote:
> >
> > The point here is not about setting and resetting the plane->fb
> > pointer. It's about what happens inside
> > drm_atomic_set_fb_for_plane().
> >
> > It calls drm_fr
https://bugs.freedesktop.org/show_bug.cgi?id=108845
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Controls which of the 8 lanes are used for 6 bit color.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 22 ---
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
b/drivers/gpu/drm/ms
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
bl_idle_init() doesn't do that, so fix it.
Signed-off-by: Yangtao Li
---
drivers/gpu/drm/pl111/pl111_vexpress.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drive
This prepares framedone interrupt handling for
manual display update support.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
drivers/gpu/drm/omapdrm/omap_crtc.
On Wed, Nov 21, 2018 at 6:55 AM Daniel Vetter wrote:
>
> On Sun, Nov 18, 2018 at 08:57:20PM -0300, Sergio Correia wrote:
> > When drm_new_set_master() fails, we restore the old master, however we may
> > have changed the is_master flag to 1, before failing, and it may be the
> > case it was 0 prev
Hi,
Dne ponedeljek, 19. november 2018 ob 15:33:11 CET je Qiang Yu napisal(a):
> Render like lima will attach a fence to the framebuffer
> dma_buf, display like sun4i should wait it finish before
> show the framebuffer. Otherwise tearing will be observed.
Please resend this patch to all emails lis
Remove gca/gfx_8_0_enum.h which is included more than once
Signed-off-by: Brajeswar Ghosh
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
b/drivers/gpu/drm/amd/amdkfd/kfd_dev
From: Cristian Birsan
PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).
Adding Device Tree bindings for this panel.
Signed-off-by: Cristian Birsan
---
.../devicetree/bindings/display/panel/pda,91-00156-a0.tx
From: "Y.C. Chen"
v1: over-sample data to increase the stability with some specific monitors
v2: refine to avoid infinite loop
v3: remove un-necessary "volatile" declaration
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_mode.c | 34 --
1 file changed, 28
Hi,
Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv4. The patches are based
on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches
for OMAP3 support (it needs a workaround for a hardware bug) and
for automatic display rotation. They shoul
PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).
Signed-off-by: Eugen Hristev
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/
Makes it possible to have MMU for GPU but not display.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index d97f6ecb0531..6657453a3a58 100644
--- a/d
After the changes from 4.20 the DSI encoder tries to find the
attached panel before populating the DSI bus. If the panel is
not found -EPROBE_DEFER is returned, so the DSI bus is never
populated and the panel never added.
Fix this by populating the DSI bus before searching for the
video sink in ds
Hi Maxime,
On 21/11/18 3:41 PM, Maxime Ripard wrote:
> Hi Kishon,
>
> On Tue, Nov 20, 2018 at 11:02:34AM +0530, Kishon Vijay Abraham I wrote:
+static int cdns_dphy_config_from_opts(struct phy *phy,
+struct phy_configure_opts_mipi_dphy *opts,
+
Precision Design Associates, Inc. (PDA) manufactures standard and custom
capacitive touch screens, LCD's embedded controllers and custom embedded
software. They specialize in industrial, rugged and outdoor applications.
Website: http://www.pdaatl.com/
Signed-off-by: Eugen Hristev
---
Documentati
Hi,
we have on-board ASPEED Graphics card on PCIe.
kernel version: 4.16
I select following drive to enable ast graphics support.
Symbol: DRM_AST [=y]
Remove drm/drm_fb_helper.h which is included more than once
Signed-off-by: Brajeswar Ghosh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index b9e9e8b02fb7..1cac
This macro is only used by omapdrm, which should print
debug messages using the DRIVER category instead of the
default CORE category.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++--
1 fil
On 11/21/18 2:56 PM, Souptick Joarder wrote:
> On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
> wrote:
>> On 11/21/18 1:24 AM, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
>>> wrote:
Previouly drivers have their own way of mapping range of
kernel pages/
On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote:
> On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
> >
> > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > > Hi Mike,
> > >
> > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox
> > > wrote:
> > > >
> > >
The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the
same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder
only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way
union works, it won't be NULL if dsi.set_config is set. This means
dsi_set_config
Hello,
syzbot found the following crash on:
HEAD commit:92b419289cee Merge tag 'riscv-for-linus-4.20-rc4' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17ed377b40
kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446
da
Hello,
This patch series adds support for PDA (Precision Design Associates, Inc.)
vendor, and for the PDA 91-00156-A0 simple panel, together with the bindings.
The series is on top of http://anongit.freedesktop.org/git/drm/drm.git drm-next
branch.
Cristian Birsan (1):
dt-bindings: drm/panel: s
1 - 100 of 130 matches
Mail list logo
