On 2019年04月25日 03:22, Eric Anholt wrote:
"Zhou, David(ChunMing)" writes:
Will linux be only mesa-linux? I thought linux is an open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
reject?
https://bugs.freedesktop.org/show_bug.cgi?id=110510
--- Comment #3 from Tom B ---
Further testing after reading this:
https://bugs.freedesktop.org/show_bug.cgi?id=102646
If I run:
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
Before setting the refresh rate to
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #53 from Robert Strube ---
Created attachment 144091
--> https://bugs.freedesktop.org/attachment.cgi?id=144091=edit
lspci kernel 5.0.x with nividia eGPU
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #52 from Robert Strube ---
Created attachment 144090
--> https://bugs.freedesktop.org/attachment.cgi?id=144090=edit
dmesg log with kernel 5.0.x with nvidia eGPU
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #51 from Robert Strube ---
Hello Everyone,
I realize it's been a long time since I updated this bug report, apologies in
advance. I decided to give up on eGPUs + Linux (over Thunderbolt 3) for a
while, and didn't get a chance to
https://bugs.freedesktop.org/show_bug.cgi?id=110510
--- Comment #2 from Tom B ---
After freezing the system, here's the output from journalctl --boot=-1 | grep
amdgpu
Apr 25 00:10:18 desktop kernel: [drm] amdgpu kernel modesetting enabled.
Apr 25 00:10:18 desktop kernel: fb0: switching to
https://bugs.freedesktop.org/show_bug.cgi?id=110510
--- Comment #1 from Tom B ---
This may be relevant: The crash does not happen if I run the HDMI monitor at
30hz. This means the monitors can be run at different refresh rates.
The DisplayPort monitor does not support 59.94hz or 50hz. My
On Wed, 2019-04-24 at 17:36 -0500, Bjorn Helgaas wrote:
> On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote:
> > On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote:
> > > Not being a scheduled work expert, I was unsure if this experiment was
> > > equivalent to what I proposed.
> > >
Hi Dave, Daniel,
Pretty quiet. Just two fixes:
- ttm regression fix
- sched documentation fix
The following changes since commit 00fd14ff3017f64a9a03a08291e4be0d87bedc17:
Merge branch 'drm-fixes-5.1' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2019-04-18 06:56:35 +1000)
https://bugs.freedesktop.org/show_bug.cgi?id=110510
Bug ID: 110510
Summary: Radeon VII HDMI issues: Flicking/system crashing
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity:
On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote:
> On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote:
> > Not being a scheduled work expert, I was unsure if this experiment was
> > equivalent to what I proposed.
> >
> > I'm always suspicious of singleton solutions like this (using
I was trying to figure out if it was permissible to merge the Mesa
side of V3D's CSD support yet while it's in drm-misc-next but not
drm-next, and developers on #dri-devel IRC had differing opinions of
what the requirement was.
v2: Restrict to just drm-next or drm-misc-next on airlied's request.
Sean Paul writes:
> From: Sean Paul
>
> Sphinx really wants colons after arguments :/
>
> Fixes the following warnings:
> drm_gem.c:1384: warning: Function parameter or member 'fence_array' not
> described in 'drm_gem_fence_array_add'
> drm_gem.c:1384: warning: Function parameter or member
Hi Dave and Daniel,
This has been a very quiet week. The only 2 patches here
was queued last week.
drm-intel-fixes-2019-04-24:
A fix for display lanes calculation for BXT and a protection
to avoid enabling FEC without DSC.
Thanks,
Rodrigo.
The following changes since commit
On Wed, Apr 24, 2019 at 2:15 PM Sam Ravnborg wrote:
> > > I missed where ade_driver_data came from.
> > > This looks an extra patch to intoduce driver_data,
> > > that maybe should be merged with an earlier version?
> >
> > I'm not sure I'm following you here. Can you clarify a bit more?
>
> So I
Hi John.
>
> > I missed where ade_driver_data came from.
> > This looks an extra patch to intoduce driver_data,
> > that maybe should be merged with an earlier version?
>
> I'm not sure I'm following you here. Can you clarify a bit more?
So I looked at this a bit more - and got the bigger
Hi Da.*,
First pull from -next-fixes for 5.2. Mostly lease fixes from Daniel with a NULL
deref from Noralf.
Please pull!
drm-misc-next-fixes-2019-04-24:
- fb_helper: Fix NULL deref in legacy drivers (Noralf)
- leases: Ensure lessees can't connect to objects outside their perview (Daniel)
-
On Wed, Apr 24, 2019 at 1:54 PM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Apr 23, 2019 at 04:20:31PM -0700, John Stultz wrote:
> > This patchset contains one fix (in the front, so its easier to
> > eventually backport), and a series of changes from YiPing to
> > refactor the kirin drm driver
On Wed, 2019-04-24 at 23:52 +0300, Ville Syrjälä wrote:
> On Wed, Apr 24, 2019 at 08:40:30PM +, Li, Sun peng (Leo) wrote:
> >
> >
> > On 2019-04-24 1:26 p.m., Lyude Paul wrote:
> > > Closer, but are we sure we want to use the MST prop path for this? Why
> > > not add
> > > a sysfs attribute
Hi John.
On Tue, Apr 23, 2019 at 04:20:31PM -0700, John Stultz wrote:
> This patchset contains one fix (in the front, so its easier to
> eventually backport), and a series of changes from YiPing to
> refactor the kirin drm driver so that it can be used on both
> kirin620 based devices (like the
On Wed, Apr 24, 2019 at 08:40:30PM +, Li, Sun peng (Leo) wrote:
>
>
>
> On 2019-04-24 1:26 p.m., Lyude Paul wrote:
> > Closer, but are we sure we want to use the MST prop path for this? Why not
> > add
> > a sysfs attribute with the corresponding DRM connector name instead since
> > the
>
From: Sean Paul
Sphinx really wants colons after arguments :/
Fixes the following warnings:
drm_gem.c:1384: warning: Function parameter or member 'fence_array' not
described in 'drm_gem_fence_array_add'
drm_gem.c:1384: warning: Function parameter or member 'fence' not described in
On 2019-04-24 1:26 p.m., Lyude Paul wrote:
> Closer, but are we sure we want to use the MST prop path for this? Why not add
> a sysfs attribute with the corresponding DRM connector name instead since the
> connector itself will have a path property. That way we can associate aux
> devices for
Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > From: Daniel Drake
> >
> > On many (all?) the Gemini Lake systems we work with, there is frequent
> > momentary graphical corruption at the top of the screen, and it seems
> > that
On Thu, 25 Apr 2019 at 05:35, Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 11:56:16AM -0700, Eric Anholt wrote:
> > I was trying to figure out if it was permissible to merge the Mesa
> > side of V3D's CSD support yet while it's in drm-misc-next but not
> > drm-next, and developers on
Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> From: Daniel Drake
>
> On many (all?) the Gemini Lake systems we work with, there is frequent
> momentary graphical corruption at the top of the screen, and it seems
> that disabling framebuffer compression can avoid this.
>
> The ticket was
On Thu, Apr 18, 2019 at 10:41:38AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces and storing the information is a small lockdep
> specific data structure.
>
Acked-by: Peter Zijlstra (Intel)
On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote:
> There is only one caller of check_prev_add() which hands in a zeroed struct
> stack trace and a function pointer to save_stack(). Inside check_prev_add()
> the stack_trace struct is checked for being empty, which is always
> true.
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) ---
Does booting with any of the following options on the kernel command line in
grub help?
amd_iommu=off
idle=nomwait
iommu=pt
pci=noats
Can you also try different IOMMU and SVM settings
On Wed, Apr 24, 2019 at 10:13 AM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Apr 23, 2019 at 04:20:31PM -0700, John Stultz wrote:
> > This patchset contains one fix (in the front, so its easier to
> > eventually backport), and a series of changes from YiPing to
> > refactor the kirin drm driver
On Wed, Apr 24, 2019 at 11:56:17AM -0700, Eric Anholt wrote:
> The point of this review process is that userspace using the new uAPI
> can actually live with the uAPI being provided, and it's hard to know
> that without having actually looked into a kernel patch yourself.
>
> Signed-off-by: Eric
On Wed, Apr 24, 2019 at 11:56:16AM -0700, Eric Anholt wrote:
> I was trying to figure out if it was permissible to merge the Mesa
> side of V3D's CSD support yet while it's in drm-misc-next but not
> drm-next, and developers on #dri-devel IRC had differing opinions of
> what the requirement was.
On Wed, Apr 24, 2019 at 10:09 AM Sam Ravnborg wrote:
> On Tue, Apr 23, 2019 at 04:20:55PM -0700, John Stultz wrote:
> > static int kirin_drm_crtc_init(struct drm_device *dev, struct drm_crtc
> > *crtc,
> > - struct drm_plane *plane)
> > + struct
On Wed, Apr 24, 2019 at 9:50 AM Sam Ravnborg wrote:
> On Tue, Apr 23, 2019 at 04:20:42PM -0700, John Stultz wrote:
>
> This struct:
> > /* ade-format info: */
> > -struct ade_format {
> > - u32 pixel_format;
> > - enum ade_fb_format ade_format;
> > -};
> > -
> > -static const struct
"Zhou, David(ChunMing)" writes:
> Will linux be only mesa-linux? I thought linux is an open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
> reject?
> 2. one hw feature that opengl/amdvlk
On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote:
> Not being a scheduled work expert, I was unsure if this experiment was
> equivalent to what I proposed.
>
> I'm always suspicious of singleton solutions like this (using
> schedule_work() in runtime_resume()) because usually they seem to
On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote:
> On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
> > resume")]
> >
> > On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote:
> > > On Thu,
The point of this review process is that userspace using the new uAPI
can actually live with the uAPI being provided, and it's hard to know
that without having actually looked into a kernel patch yourself.
Signed-off-by: Eric Anholt
Suggested-by: Daniel Vetter
---
I was trying to figure out if it was permissible to merge the Mesa
side of V3D's CSD support yet while it's in drm-misc-next but not
drm-next, and developers on #dri-devel IRC had differing opinions of
what the requirement was. Propose a clarification here to see if Dave
Airlie agrees.
On Wed 2019-04-24 10:57:50, Rob Herring wrote:
> On Wed, Apr 24, 2019 at 9:20 AM Pavel Machek wrote:
> >
> > Hi!
> >
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > > @@ -0,0 +1,129 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR
Hi Linus.
A few repeated comments from last review, and then a bunch
of trivial nits below.
One major thing to consider is to use a regmap for all the register
access.
Another bigger item is the excessive use of logging. Is this relevant
now the driver works or just leftovers which should really
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #8 from Craig ---
I have updated to Ubuntu 19.04 and still getting the same result. Please let
me know what steps to take next to get this issue resolved.
--
You are receiving this mail because:
You are the assignee for the
On Wed, Apr 24, 2019 at 01:31:09PM -0400, Lyude Paul wrote:
> Any update on this? This has been waiting for a while now
Oh, sorry, I guess we were both waiting for the other. Let me respond to
the email with context.
> On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> > [+cc Hans,
Dave Airlie writes:
> I've been looking a bit at 5.0 for a few things recently, and I've
> noticed it shipped with a bunch of regressions, that I'm trying to
> smash.
>
> udl driver regression due to gem unlocked cleanup
> udl driver unload regression due to other unplug changes
> i915 + atomic
https://bugs.freedesktop.org/show_bug.cgi?id=110509
james.dut...@gmail.com changed:
What|Removed |Added
Attachment #144086|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #3 from james.dut...@gmail.com ---
Created attachment 144086
--> https://bugs.freedesktop.org/attachment.cgi?id=144086=edit
dmesg
dmesg during reset.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #2 from james.dut...@gmail.com ---
Created attachment 144085
--> https://bugs.freedesktop.org/attachment.cgi?id=144085=edit
/usr/src/umr/build/src/app/umr -wa
Output of the wave.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #1 from james.dut...@gmail.com ---
Created attachment 144084
--> https://bugs.freedesktop.org/attachment.cgi?id=144084=edit
./umr -O bits -r *.*.mmGRBM_STATUS
Output while GPU failed to reset.
--
You are receiving this mail
Any update on this? This has been waiting for a while now
On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
> resume")]
--
Cheers,
Lyude Paul
___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=110509
Bug ID: 110509
Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout
Product: Mesa
Version: git
Hardware: Other
OS: All
Status:
Closer, but are we sure we want to use the MST prop path for this? Why not add
a sysfs attribute with the corresponding DRM connector name instead since the
connector itself will have a path property. That way we can associate aux
devices for eDP and DP devices with their corresponding connectors
On Tue, Mar 19, 2019 at 02:26:01PM +0100, Marek Szyprowski wrote:
> ACLK400_DISP1 bus feeds some internal buses of the display subsystem, some
> of which are also related to TV/Mixer hardware modules. When that bus
> is set to 120MHz, Exynos Mixer is not able to properly handle two XRGB
> display
lgtm
Reviewed-by: Lyude Paul
On Mon, 2019-04-22 at 19:56 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST, make the IDR
> non-cyclic. That way, hotplug cycling MST devices won't needlessly
> increment the minor version index.
>
>
Den 23.04.2019 13.04, skrev Martin Peres:
> On 20/04/2019 20:24, Noralf Trønnes wrote:
>>
>>
>> Den 20.04.2019 12.45, skrev Noralf Trønnes:
>>> This moves the modesetting code from drm_fb_helper to drm_client so it
>>> can be shared by all internal clients.
>>>
>>> Changes this time:
>>> - Use
Hi John.
On Tue, Apr 23, 2019 at 04:20:31PM -0700, John Stultz wrote:
> This patchset contains one fix (in the front, so its easier to
> eventually backport), and a series of changes from YiPing to
> refactor the kirin drm driver so that it can be used on both
> kirin620 based devices (like the
On 2019-04-24 2:19 p.m., Paul Kocialkowski wrote:
> On Wed, 2019-04-24 at 10:31 +0200, Michel Dänzer wrote:
>> On 2019-04-19 10:38 a.m., Paul Kocialkowski wrote:
>>> On Thu, 2019-04-18 at 20:30 -0400, Nicolas Dufresne wrote:
Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
>>
From: Adrian Salido
When calling drmModeAtomicAddProperty allocation of memory
happens as needed in increments of 16 elements. This can be very
slow if there are multiple properties to be updated in an Atomic
Commit call.
Increase this to as many as can fit in a memory PAGE to avoid
having to
Hi John.
On Tue, Apr 23, 2019 at 04:20:55PM -0700, John Stultz wrote:
> From: Xu YiPing
>
> As part of refactoring the kirin driver to better support
> different hardware revisions, this patch changes funcitons
> to pass the kirin_driver_data as a prameter.
>
> This will allow those funcitons
From: Hemant Hariyani
Allows mmap on dmabuf fd with MAP_SHARED and PROT_WRITE.
This fixes boot failures with Android (likely w/ closed source
user-space drivers) that were caused due to mmap() returning
error.
Cc: Emil Velikov
Cc: Sean Paul
Cc: Alistair Strachan
Cc: Marissa Wall
From: Prabhanjan Kandula
Avoid additional drm device open and close.
Cc: Emil Velikov
Cc: Sean Paul
Cc: Alistair Strachan
Cc: Marissa Wall
Reviewed-by: Alex Deucher
Signed-off-by: John Stultz
---
xf86drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c
Add a check to error out on Android version K(4.4) or
lower.
This is due to dependency added in a previous commit on mmap64,
which was introduced with Android L.
Cc: Emil Velikov
Cc: Sean Paul
Cc: Alistair Strachan
Cc: Marissa Wall
Suggested-by: Emil Velikov
Signed-off-by: John Stultz
---
Recently I've been trying to sync the AOSP libdrm tree with
the upstream freedesktop branch.
Thanks to input from Sean, Alistair and Marissa, we've managed
to drop a bunch of stale patches AOSP was carrying, and get
the AOSP libdrm updated to 2.4.97
I've gone through the remaining patch delta
From: Sean Paul
__mmap2 isn't supported on all platforms, mmap64 is the right way
to do this in android.
Also folds in a fix from Stéphane Marchesin
Cc: Emil Velikov
Cc: Sean Paul
Cc: Alistair Strachan
Cc: Marissa Wall
Acked-by: Alex Deucher
Reviewed-by: Emil Velikov
Signed-off-by: Sean
Clang complains when initializing unions using "= {0}"
so instead use memset.
Cc: Emil Velikov
Cc: Sean Paul
Cc: Alistair Strachan
Cc: Marissa Wall
Reviewed-by: Alex Deucher
Reviewed-by: Emil Velikov
Reviewed-by: Christian König
Signed-off-by: John Stultz
---
amdgpu/amdgpu_cs.c | 9
Hi again.
On Wed, Apr 24, 2019 at 06:52:26PM +0200, Sam Ravnborg wrote:
> Hi John.
>
> On Tue, Apr 23, 2019 at 04:20:43PM -0700, John Stultz wrote:
> > From: Xu YiPing
> >
> > As part of refactoring the kirin driver to better support
> > different hardware revisions, this patch renames the
> >
Hi John.
> >
> > Nice simplification. We are now down to two very small Kconfig files.
> > Consider to merge them into one Kconfig file in the top-level dir.
> >
>
> Part of this cleanup is so that we can add another device option in a
> later commit (though not in this series), so unless folks
On 2019-04-24 5:44 p.m., Nicolas Dufresne wrote:
> Le mercredi 24 avril 2019 à 17:06 +0200, Daniel Vetter a écrit :
>> On Wed, Apr 24, 2019 at 4:41 PM Paul Kocialkowski
>> wrote:
>>> On Wed, 2019-04-24 at 16:39 +0200, Michel Dänzer wrote:
On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote:
Hi John.
On Tue, Apr 23, 2019 at 04:20:43PM -0700, John Stultz wrote:
> From: Xu YiPing
>
> As part of refactoring the kirin driver to better support
> different hardware revisions, this patch renames the
> struct kirin_dc_ops to struct kirin_drm_data and cleans
> up the related variable names.
On Wed, Apr 24, 2019 at 9:46 AM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Apr 23, 2019 at 04:20:41PM -0700, John Stultz wrote:
> > The workqueue used to reset the display when we hit an LDI
> > underflow error is ADE specific, so since this patch series
> > works to make the kirin_crtc
Hi John.
On Tue, Apr 23, 2019 at 04:20:42PM -0700, John Stultz wrote:
> From: Xu YiPing
>
> As part of refactoring the kirin driver to better support
> different hardware revisions, this patch moves some shared
> structures and helpers to the common kirin_drm_drv.h
>
> These structures will
On Wed, Apr 24, 2019 at 9:39 AM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Apr 23, 2019 at 04:20:33PM -0700, John Stultz wrote:
> > The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
> > driver, so cut out the middleman and condense the config
> > logic down.
> >
> > Cc: Xinliang Liu
>
Hi John.
On Tue, Apr 23, 2019 at 04:20:41PM -0700, John Stultz wrote:
> The workqueue used to reset the display when we hit an LDI
> underflow error is ADE specific, so since this patch series
> works to make the kirin_crtc structure more generic, move the
> workqueue to the ade_hw_ctx structure
Hi John.
On Tue, Apr 23, 2019 at 04:20:33PM -0700, John Stultz wrote:
> The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
> driver, so cut out the middleman and condense the config
> logic down.
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: David
Hi John.
On Tue, Apr 23, 2019 at 04:20:32PM -0700, John Stultz wrote:
> From: Da Lv
>
> The original HiKey (620) board has had a long running issue
> where when using a 1080p montior, the display would occasionally
> blink and come come back with a horizontal offset (usually also
> shifting the
https://bugs.freedesktop.org/show_bug.cgi?id=109526
--- Comment #5 from Johannes Hirte ---
Created attachment 144083
--> https://bugs.freedesktop.org/attachment.cgi?id=144083=edit
dmesg log from suspend->resume->suspend->resume
When this bug occurs, from sddm it is possible to put the system
On Wed, Apr 24, 2019 at 9:20 AM Pavel Machek wrote:
>
> Hi!
>
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > @@ -0,0 +1,129 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
This patchset adds some check of the returned error code in probe.
Fabien Dessenne (2):
drm/stm: ltdc: manage the get_irq probe defer case
drm/stm: ltdc: return appropriate error code during probe
drivers/gpu/drm/stm/ltdc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
Op 24-04-2019 om 17:06 schreef Maarten Lankhorst:
> Op 24-04-2019 om 15:12 schreef kbuild test robot:
>> tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes
>> head: d08106796a78a4273e39e1bbdf538dc4334b2635
>> commit: d08106796a78a4273e39e1bbdf538dc4334b2635 [1/1] drm/vc4:
在 2019/4/24 22:36, Daniel Vetter 写道:
> On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter wrote:
>> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
>> wrote:
>>> Will linux be only mesa-linux? I thought linux is an open linux.
>>> Which will impact our opengl/amdvlk(MIT open source), not sure
On Wed, Apr 24, 2019 at 4:41 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Wed, 2019-04-24 at 16:39 +0200, Michel Dänzer wrote:
> > On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote:
> > > Le mercredi 24 avril 2019 à 10:31 +0200, Michel Dänzer a écrit :
> > > > On 2019-04-19 10:38 a.m., Paul
Op 24-04-2019 om 15:12 schreef kbuild test robot:
> tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes
> head: d08106796a78a4273e39e1bbdf538dc4334b2635
> commit: d08106796a78a4273e39e1bbdf538dc4334b2635 [1/1] drm/vc4: Fix memory
> leak during gpu reset.
> reproduce:
>
Manage the -EPROBE_DEFER error case for the ltdc IRQ.
Signed-off-by: Fabien Dessenne
---
drivers/gpu/drm/stm/ltdc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 566b0d8..521ba83 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++
Hi,
On Wed, 2019-04-24 at 16:39 +0200, Michel Dänzer wrote:
> On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote:
> > Le mercredi 24 avril 2019 à 10:31 +0200, Michel Dänzer a écrit :
> > > On 2019-04-19 10:38 a.m., Paul Kocialkowski wrote:
> > > > On Thu, 2019-04-18 at 20:30 -0400, Nicolas Dufresne
During probe, return the "clk_get" error value instead of -ENODEV.
Signed-off-by: Fabien Dessenne
---
drivers/gpu/drm/stm/ltdc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 521ba83..97912e2 100644
---
On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote:
> Le mercredi 24 avril 2019 à 10:31 +0200, Michel Dänzer a écrit :
>> On 2019-04-19 10:38 a.m., Paul Kocialkowski wrote:
>>> On Thu, 2019-04-18 at 20:30 -0400, Nicolas Dufresne wrote:
Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit
On Wed, 24 Apr 2019 at 15:20, Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 03:13:53PM +0200, Tomeu Vizoso wrote:
> > So userspace can get feedback on any error conditions, instead of going
> > ahead and things breaking later.
> >
> > Signed-off-by: Tomeu Vizoso
>
> Bonus: some igts to
On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
> wrote:
> > Will linux be only mesa-linux? I thought linux is an open linux.
> > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> > 1. how to deal with one uapi
On 4/17/19 11:51 PM, Mario Kleiner wrote:
> Pre-DCE12 needs special treatment for BTR / low framerate
> compensation for more stable behaviour:
>
> According to comments in the code and some testing on DCE-8
> and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> programming with a lag of
On Mon, Apr 22, 2019 at 08:49:27PM +0200, Oscar Gomez Fuente wrote:
> These changes solve warning symbol was not declared in the functions:
> ion_carveout_heap_create and ion_chunk_heap_create
>
> Signed-off-by: Oscar Gomez Fuente
> ---
> drivers/staging/android/ion/ion_carveout_heap.c | 2 +-
>
On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
wrote:
> Will linux be only mesa-linux? I thought linux is an open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
> reject?
> 2. one
Will linux be only mesa-linux? I thought linux is an open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
reject?
2. one hw feature that opengl/amdvlk developers work on that but no mesa
On Wed 2019-04-24 05:25:05, Brian Masney wrote:
> Add fwnode support to the lm3630a driver and optionally allow
> configuring the label, default brightness level, and maximum brightness
> level. The two outputs can be controlled by bank A and B independently
> or bank A can control both outputs.
>
On Wed, Apr 24, 2019 at 4:06 PM Noralf Trønnes wrote:
>
>
>
> Den 23.04.2019 21.01, skrev Daniel Vetter:
> > On Tue, Apr 23, 2019 at 04:53:53PM +0200, Noralf Trønnes wrote:
> >> Non-atomic drivers like ast doesn't have connector->state set resulting
> >> in a NULL pointer deref:
> >>
> >> [
The Synopsys MIPI DSI IP contains a video test pattern generator which
is helpful in debugging video timing with connected displays.
Add a debugfs directory containing files which allow the VPG to be
enabled and disabled, and it's orientation to be changed.
Signed-off-by: Matt Redfearn
---
The DRM documentation states that post_disable is an optional callback.
As such an implementing device may not populate it. To avoid panicing
the kernel by calling a NULL function pointer, we should NULL check it
before blindy calling it.
Signed-off-by: Matt Redfearn
---
The Synopsys manual states that software should wait for all active
lanes to reach stop state (User manual section 3.1.5). Currently the
driver only waits for / checks that the clock lane is in stop state. Fix
this by waiting for the mask of PHY STATUS bits corresponding to the
active lanes to be
Hi!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
> +$schema:
On Wed, 2019-04-24 at 14:10 +, Koenig, Christian wrote:
> Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> > Add a pointer to the struct vm_operations_struct in the bo_device,
> > and
> > assign that pointer to the default value currently used.
> >
> > The driver can then optionally modify
Am 24.04.19 um 14:05 schrieb Thomas Zimmermann:
> Hi Christian,
>
> Am 24.04.19 um 13:48 schrieb Thomas Zimmermann:
>> +
>> +/*
>> + * Helpers for struct ttm_bo_driver
>> + */
>> +
>> +static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
>> +{
>> +return (bo->destroy ==
Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> Add a pointer to the struct vm_operations_struct in the bo_device, and
> assign that pointer to the default value currently used.
>
> The driver can then optionally modify that pointer and the new value
> can be used for each new vma created.
>
>
1 - 100 of 225 matches
Mail list logo
