https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #1 from bakarichar...@gmail.com ---
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 15d0
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 15d1
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h
https://bugzilla.kernel.org/show_bug.cgi?id=200517
Bug ID: 200517
Summary: Vega 8/Radeon 535 hybrid graphics - amdgpu crash on
modesetting
Product: Drivers
Version: 2.5
Kernel Version: 4.18.0rc5
Hardware: All
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d0987b4ee380e9d814052071c939b38a74a34ab1
commit: 4771bffd00cf57702e4bea3a1b08fe9a9ea78abd [5/6] drm/amdgpu/pp/smu7:
cache smu firmware toc
reproduce:
# apt-get install sparse
git checkout
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc4 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d0987b4ee380e9d814052071c939b38a74a34ab1
commit: 999555e0e0e9580c61715c55b32e123fe0f4c925 [593/600] drm/amd/display:
Initialize data structure for DalMpVisualConfirm.
reproduce:
# apt-get install sparse
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 44178b4c3599..d556f24c6c48 100644
---
The i2c bus can be both accessed by DRM itself, along with any of it's
devnodes (/sys/class/i2c). So, we need to make sure that all codepaths
using the i2c bus keep the GPU resumed.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: sta...@vger.kernel.org
---
While the GPU is guaranteed to be on when a hotplug has been received,
the same assertion does not hold true if a connector probe has been
started by userspace without having had received a sysfs event. So
ensure that any connector probing keeps the GPU alive for the duration
of the probe.
DP AUX busses can both be accessed by DRM, and through any of the
userspace dev nodes in /dev/drm_dp_auxN. We need to make sure the GPU
stays on in all of these codepaths.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c |
In order to fix all of the spots that need to have runtime PM get/puts()
added, we need to ensure that it's possible for us to call
pm_runtime_get/put() in any context, regardless of how deep, since
almost all of the spots that are currently missing refs can potentially
get called in the runtime
When DP MST hubs get confused, they can occasionally stop responding for
a good bit of time up until the point where the DRM driver manages to
do the right DPCD accesses to get it to start responding again. In a
worst case scenario however, this process can take upwards of 10+
seconds.
Currently
This fixes quite a number of runtime PM bugs I found that have been
causing some pretty nasty issues such as:
- Deadlocking on boot
- Connector probing potentially not working while the GPU is in runtime
suspend
- i2c char dev not working while the GPU is in runtime suspend
- aux char dev
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij wrote:
>
> The need to support some straight-forward VGA panels that are
> not adhering to any standard like DPI arise in the ARM RTSM VE
> Real-Time Systems Model Virtual Executive. This emulator (which
> is not QEMU) does not model any bridge or
GPU accelerators usually don't have display block or the display
driver part can be disable when building driver(for servers it save
some resources) so it is important let userspace check this
capability too.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
No need to run i915_load_modeset_init() when num_pipes == 0 also
kms depends on things initialized in i915_load_modeset_init() so not
initializing it too. fbdev and audio have guards against
num_pipes == 0 but lets move it to the if block to make it explicit
to readers.
Also as planes, CRTCs,
i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset API.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git
i915_load_modeset_init() and intel_modeset_cleanup() was initializing
and cleaning up things that is not modeset only.
This will make easy initialize drive without display part.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 56 ++--
num_pipes is set to 0 if disable_display is set inside
intel_device_info_runtime_init() but when that happen PCH will
already be set in intel_detect_pch().
i915_driver_load()
i915_driver_init_early()
...
intel_detect_pch()
...
...
This 'if's will always be false because of previous changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/intel_audio.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 3 ---
drivers/gpu/drm/i915/intel_i2c.c | 3
Cc'ing some others
On Mon., 16 Jul. 2018, 23:33 Damir Shaikhutdinov, <
damir.shaikhutdi...@opensynergy.com> wrote:
> Hi Dave!
>
> I'm debugging virtio gpu unloading path in kernel 4.14, and found some bug
> that presents even in 4.18.
>
> In file drivers/gpu/drm/virtio/virtgpu_display.c:
>
>
Hi Carsten,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robclark/msm-next]
[also build test WARNING on v4.18-rc5 next-20180716]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On Tue, Jul 03, 2018 at 11:02:21AM +0100, Damian Kos wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge.
>
> Signed-off-by: Damian Kos
> ---
> .../bindings/display/bridge/cdns,mhdp.txt | 39
>
> 1 files changed, 39 insertions(+), 0
Currently, if the DT does not define num-interpolated-steps then
num_steps is undefined and the interpolation code will deploy randomly.
Fix this.
Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
brightness-levels")
Reported-by: Marcel Ziswiler
Signed-off-by: Daniel Thompson
On Mon, 16 Jul 2018 19:50:48 +0200,
Takashi Iwai wrote:
>
> On Mon, 16 Jul 2018 19:22:17 +0200,
> Rodrigo Vivi wrote:
> >
> > > --- /dev/null
> > > +++ b/include/drm/drm_audio_component.h
> > > @@ -0,0 +1,115 @@
> > > +/*
> > > + * Copyright © 2014 Intel Corporation
> > > + *
> > > + *
On Mon, 16 Jul 2018 15:48:15 +0200,
Takashi Iwai wrote:
>
> +static int hdac_component_master_bind(struct device *dev)
> +{
> + struct drm_audio_component *acomp = hdac_get_acomp(dev);
> + int ret;
> +
> + ret = component_bind_all(dev, acomp);
> + if (ret < 0)
> +
> > Hm, why not add seq_file support to dev_coredump? Neither git blame
> > nor google sched any light on why seq_file wasn't picked over the
> > custom read interface ...
> >
> > Adding Johannes and Greg about this.
>
> Main reason was that this is used for devcoredump which has its own similar
https://bugs.freedesktop.org/show_bug.cgi?id=107012
--- Comment #7 from Timothy Pearson ---
(In reply to Michel Dänzer from comment #6)
> Please send patches like this directly to the mesa-dev mailing list for
> review.
Patch has been sent. I don't monitor mesa-dev, so please address any
On Sat, Jul 14, 2018 at 03:23:32PM +0300, Haneen Mohammed wrote:
> Implement the set_crc_source() callback.
> Compute CRC using crc32 on the visible part of the framebuffer.
> Use ordered workqueue to compute and add CRC at the end of a vblank.
>
> Use appropriate synchronization methods since
Hi Laurent,
Some questions here too :)
On 24/05/18 13:51, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
>> Calculate the top and bottom fields for the interlaced frames and
>> utilise the extended display list
On Sat, Jul 14, 2018 at 03:22:36PM +0300, Haneen Mohammed wrote:
> Subclass CRTC state struct to enable storing driver's private
> state. This patch only adds the base drm_crtc_state struct and
> the atomic functions that handle it.
>
> Signed-off-by: Haneen Mohammed
> Reviewed-by: Daniel Vetter
On Sat, Jul 14, 2018 at 03:21:13PM +0300, Haneen Mohammed wrote:
> Call atomic_helper_check_plane_state to clip plane coordinates.
>
> Signed-off-by: Haneen Mohammed
Reviewed-by: Sean Paul
> ---
> Changes in v2:
> - check for plane_state->visible since we can't handle a disabled
> primary
On Sat, Jul 14, 2018 at 03:20:21PM +0300, Haneen Mohammed wrote:
> This patch map/unmap GEM backing memory to kernel address space
> in prepare/cleanup_fb respectively and cache the virtual address
> for later use.
>
> Signed-off-by: Haneen Mohammed
> ---
> Changes in v2:
> - use vkms_gem_vunmap
On Sat, Jul 14, 2018 at 03:18:55PM +0300, Haneen Mohammed wrote:
> This patch add the necessary functions to map/unmap GEM
> backing memory to the kernel's virtual address space.
>
> Signed-off-by: Haneen Mohammed
> ---
> Changes in v2:
> - add vkms_gem_vunmap
> - use vmap_count to guard against
On Mon, 16 Jul 2018 19:22:17 +0200,
Rodrigo Vivi wrote:
>
> > --- /dev/null
> > +++ b/include/drm/drm_audio_component.h
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Copyright © 2014 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of
On Mon, Jul 16, 2018 at 03:48:13PM +0200, Takashi Iwai wrote:
> For allowing other drivers to use the DRM audio component, rename the
> i915_audio_component_* with drm_audio_component_*, and split the
> generic part into drm_audio_component.h. The i915 specific stuff
> remains in struct
Hi Laurent,
On 24/05/18 12:50, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
>> Use the newly exposed VSP1 interface to enable interlaced frame support
>> through the VSP1 lif pipelines.
>
> s/lif/LIF/
Fixed.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
Will push in just a moment, updating patchwork
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index
Hi Laurent,
On 24/05/18 12:44, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
>> Extended display list headers allow pre and post command lists to be
>> executed by the VSP pipeline. This provides the base
On Mon, Jul 16, 2018 at 12:16:45PM -0400, Lyude Paul wrote:
> Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #49 from Alex Deucher ---
Created attachment 140650
--> https://bugs.freedesktop.org/attachment.cgi?id=140650=edit
possible fix
Does this patch help? Just a hack for testing to see if the scratch registers
are stale or corrupt.
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #48 from Alex Deucher ---
(In reply to Thomas Martitz from comment #47)
> So pci_raw_set_power_state() does a pci_read_config_word() and that returns
> a valid word. Yet, the device appears to be not in powerd up state later on.
>
On Mon, Jul 16, 2018 at 11:25 AM, Takashi Iwai wrote:
> On Mon, 16 Jul 2018 17:10:43 +0200,
> Harry Wentland wrote:
>>
>>
>>
>> On 2018-07-15 10:36 AM, Alex Deucher wrote:
>> > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai wrote:
>> >> On Sat, 14 Jul 2018 14:03:26 +0200,
>> >> jimqu wrote:
>>
On Thu, Jul 12, 2018 at 05:08:37PM -0400, Sean Paul wrote:
> From: Jeykumar Sankaran
>
> Adds bindings for Snapdragon 845 display processing unit
>
> Changes in v2:
> - Use SoC specific compatibles for mdss and dpu
> - Use assigned-clocks to set initial clock frequency
>
> Signed-off-by:
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9b9ba5d5ec0c..2e0312e4645a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++
This is something we've needed for a very long time now, as it makes
debugging issues with faulty MST hubs along with debugging issues
regarding us interfacing with hubs correctly vastly easier to debug.
Currently this can actually be done if you trace the i2c devices for DP
using ftrace but
On Mon, 16 Jul 2018 17:10:43 +0200,
Harry Wentland wrote:
>
>
>
> On 2018-07-15 10:36 AM, Alex Deucher wrote:
> > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai wrote:
> >> On Sat, 14 Jul 2018 14:03:26 +0200,
> >> jimqu wrote:
> >>>
> >>>
> >>>
> >>> 在 2018/7/13 23:07, Takashi Iwai 写道:
>
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #14 from Barry G ---
Did some more testing and found that I can cause this issue to happen
repeatably by using Imagemagick convert to attempt to convert and resize a jpg
image.
Doing the same convert and settings the environment
On Mon, Jul 16, 2018 at 02:13:30PM +0530, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
>bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed
On 2018-07-15 10:36 AM, Alex Deucher wrote:
> On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai wrote:
>> On Sat, 14 Jul 2018 14:03:26 +0200,
>> jimqu wrote:
>>>
>>>
>>>
>>> 在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200,
Takashi Iwai wrote:
> And the forced
在 2018/7/16 22:16, Lukas Wunner 写道:
On Mon, Jul 16, 2018 at 03:52:45PM +0800, Hui Wang wrote:
On 2018???07???16??? 14:06, Jim Qu wrote:
On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no
On Thu, Jul 12, 2018 at 11:21:53AM +0300, Stefan Mavrodiev wrote:
> This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The
> panel is used with different LCDs (currently from 480x272 to 1280x800).
> Small EEPROM chip is used for identification, which holds some
> factory data and
On Mon, Jul 16, 2018 at 02:06:35PM +0800, Jim Qu wrote:
> +
> + list_for_each_entry(client, _priv.clients, list) {
> + if (!client_is_audio(client) || client_id(client) !=
> + VGA_SWITCHEROO_UNKNOWN_ID)
Don't you have to check for
client_id(client) !=
On Mon, Jul 16, 2018 at 04:47:11PM +0200, Takashi Iwai wrote:
> On Mon, 16 Jul 2018 16:43:42 +0200,
> Lukas Wunner wrote:
> >
> > On Mon, Jul 16, 2018 at 02:06:35PM +0800, Jim Qu wrote:
> > > +
> > > + list_for_each_entry(client, _priv.clients, list) {
> > > + if (!client_is_audio(client)
On Mon, 16 Jul 2018 16:43:42 +0200,
Lukas Wunner wrote:
>
> On Mon, Jul 16, 2018 at 02:06:35PM +0800, Jim Qu wrote:
> > +
> > + list_for_each_entry(client, _priv.clients, list) {
> > + if (!client_is_audio(client) || client_id(client) !=
> > +
On Monday 09 July 2018 11:01 PM, Sean Paul wrote:
From: Abhinav Kumar
Make the pclk_rate u64 to accommodate higher pixel clock
rates.
Changes in v4:
- fixed commit message
Signed-off-by: Abhinav Kumar
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 9 ++---
1
在 2018/7/16 22:02, Lukas Wunner 写道:
On Sat, Jul 14, 2018 at 02:15:24PM +0800, jimqu wrote:
??? 2018/7/13 17:27, Lukas Wunner ??:
On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio
On Monday 09 July 2018 11:01 PM, Sean Paul wrote:
From: Rajesh Yadav
SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.
Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu
On Sat, Jul 14, 2018 at 02:32:12PM +0200, Nicholas Mc Guire wrote:
> drm_legacy_ctxbitmap_next() returns idr_alloc() which can return
> -ENOMEM, -EINVAL or -ENOSPC none of which are -1 . but the call sites
> of drm_legacy_ctxbitmap_next() seem to be assuming that the error case
> would be -1
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #47 from Thomas Martitz ---
So pci_raw_set_power_state() does a pci_read_config_word() and that returns a
valid word. Yet, the device appears to be not in powerd up state later on.
How's that possible, and why does it work on
On Monday 09 July 2018 11:01 PM, Sean Paul wrote:
From: Rajesh Yadav
postdiv_lock spinlock was used before initialization
for 10nm pll. It causes following spin_bug:
"BUG: spinlock bad magic on CPU#0".
Initialize spinlock before its usage.
Reviewed-by: Archit Taneja
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #12 from Peter ---
I'm running 4.18-rc4 on Slackware and I seem to have the same problem. My
system boots fine, but if I run startx with HDMI connected the system freezes
with a black screen and I get the bug in my kernel log.
I
Hi,
thanks for the review.
On 7/12/2018 4:38 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patches.
When resubmitting patch series, could you please add a version number to the
[PATCH] prefix ? Otherwise it gets difficult to figure out which version is
the latest. This can be
On Monday 09 July 2018 11:01 PM, Sean Paul wrote:
From: Chandan Uddaraju
For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.
Reviewed-by: Archit Taneja
Changes
On Mon, Jul 16, 2018 at 03:52:45PM +0800, Hui Wang wrote:
> On 2018???07???16??? 14:06, Jim Qu wrote:
> >On modern laptop, there are more and more platforms
> >have two GPUs, and each of them maybe have audio codec
> >for HDMP/DP output. For some dGPU which is no output,
> >audio codec usually is
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #35 from Andrey Grodzovsky ---
(In reply to dwagner from comment #30)
> (In reply to Andrey Grodzovsky from comment #29)
> > > (If that is a Mesa issue, no more than user processes / X11 should have
> > > crashed - but not the
On Tue, Jul 10, 2018 at 11:45 AM, Sean Paul wrote:
> The patch was rejected for being too big. Please refer to
> https://gitlab.freedesktop.org/seanpaul/dpu-staging/commit/b4215cf040d1978287bd1403832ffc610659652b
>
heh, and also seems to be too big for gmail to reply to..
That said, +30k is a
On Sat, Jul 14, 2018 at 02:15:24PM +0800, jimqu wrote:
> ??? 2018/7/13 17:27, Lukas Wunner ??:
> >On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
> >>On modern laptop, there are more and more platforms
> >>have two GPUs, and each of them maybe have audio codec
> >>for HDMP/DP output.
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #26 from Andrey Grodzovsky ---
(In reply to dwagner from comment #25)
> Created attachment 140634 [details]
> dmesg before and after S3 sleep with commit "updating plane ..." reverted
Reverting the patch makes the TTM eviction
For allowing other drivers to use the DRM audio component, rename the
i915_audio_component_* with drm_audio_component_*, and split the
generic part into drm_audio_component.h. The i915 specific stuff
remains in struct i915_audio_component, which contains
drm_audio_component as the base.
This is
This is the final step for more generic support of DRM audio
component. The generic audio component code is now moved to its own
file, and the symbols are renamed from snd_hac_i915_* to
snd_hdac_acomp_*, respectively. The generic code is enabled via the
new kconfig, CONFIG_SND_HDA_COMPONENT,
The HD-audio i915 binding code contains a single pointer, hdac_acomp,
for allowing the access to audio component from the master bind/unbind
callbacks. This was needed because the callbacks pass only the device
pointer and we can't guarantee the object type assigned to the drvdata
(which is free
Hi,
this is a preliminiary patch set to convert the existing i915 /
HD-audio component binding to be applicable to other drivers like
radeon / amdgpu. This patchset itself doesn't change the
functionality but only renames and split to a new drm_audio_component
stuff from i915_audio_component.
On x86 some firmwares use a low non native resolution for the display when
they have shown some text messages. While keeping the bgrt filled with info
for the native resolution. If the bgrt image intended for the native
resolution still fits, it will be displayed very close to the right edge of
From: Colin Ian King
The value of tmp being used in the switch statement has the range of
just 0..3 hence the case 4 statement can never be reached and is
deadcode and can be removed.
Detected by CoverityScan, CID#744384 ("Logically dead code")
Signed-off-by: Colin Ian King
---
On Mon, 16 Jul 2018 08:06:35 +0200,
Jim Qu wrote:
>
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it will
On Mon, 16 Jul 2018 08:06:34 +0200,
Jim Qu wrote:
>
> Except PCI_CLASS_DISPLAY_VGA, some PCI class is sometimes
> PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER.
>
> Signed-off-by: Jim Qu
Applied this one now, as it's basically an individual fix.
thanks,
Takashi
Quoting Gustavo A. R. Silva (2018-07-16 13:39:33)
> err is assigned to -EIO, but this value is never actually
> used and *err* is updated later on.
>
> Remove such reduntant code.
The mistake is that err is lost, possible masking the test failure.
Looks like the unwind needs to be refactored?
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, July 12, 2018 10:02 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala,
On Mon, Jul 9, 2018 at 1:31 PM, Sean Paul wrote:
> From: Jeykumar Sankaran
>
> Qualcomm Snapdragon chipsets uses compressed format
> to optimize BW across multiple IP's. This change adds
> needed modifier support in drm for a simple 4x4 tile
> based compressed variants of base formats.
>
>
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.
Currently we simply back off and mark an
On Tue, Jul 10, 2018 at 1:18 PM, Carsten Behling
wrote:
> I found the solution:
>
> ROI has to be recalculated for negative x/y indicating using the lower/right
> corner of the cursor buffer. Further, MDP5_LM_CURSOR_XY_SRC_Y and
> MDP5_LM_CURSOR_XY_SRC_X mus be calculated for the hotspot:
oh,
Hi Dan,
Thanks for your patch. I checked and tested it, everything is fine.
On 07/14, Dan Carpenter wrote:
> The > should be >= so that we don't read one page beyond the end of the
> obj->pages[] array.
>
> Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> Signed-off-by: Dan Carpenter
>
On Fri, Jul 13, 2018 at 04:10:59PM +0100, Alexandru Gheorghe wrote:
> Older version of this patch series reported writeback as disconnected
> to avoid confusing userspace not aware of writeback connectors.
> However, the version that got merged uses a special cap
>
On Fri, Jul 13, 2018 at 04:10:58PM +0100, Alexandru Gheorghe wrote:
> During iteration process one of the proposed mechanism for not
> breaking existing userspace was to report writeback connectors as
> disconnected, however the final version used
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that
On Mon, Jul 16, 2018 at 10:56:13AM +0100, Alexandru Gheorghe wrote:
> Set possible_clones field to report that the writeback connector and
> the one driving the display could be enabled at the same time.
>
> Signed-off-by: Alexandru Gheorghe
Acked-by: Liviu Dudau
>
> Changes since v2:
> -
On Mon, Jul 16, 2018 at 11:07:07AM +0100, Alexandru Gheorghe wrote:
> Currently, if userspace calls drm_wait_vblank before the crtc is
> activated the crtc vblank_enable hook is called, which in case of
> malidp driver triggers some warninngs. This happens because on
> device init we don't inform
https://bugs.freedesktop.org/show_bug.cgi?id=107229
--- Comment #6 from Alexander Tsoy ---
(In reply to Alexander Tsoy from comment #5)
> To clarify a bit: first bad commit in bisect is actually the first good
> commit that fixed hangs in Metro.
But only when transparent huge pages are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=107229
--- Comment #5 from Alexander Tsoy ---
To clarify a bit: first bad commit in bisect is actually the first good commit
that fixed hangs in Metro.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107229
--- Comment #4 from Alexander Tsoy ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Alexander Tsoy from comment #0)
> >
> > linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=y = OK
> > linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=n
Currently, if userspace calls drm_wait_vblank before the crtc is
activated the crtc vblank_enable hook is called, which in case of
malidp driver triggers some warninngs. This happens because on
device init we don't inform the drm core about the vblank state
by calling drm_crtc_vblank_on/off/reset
Set possible_clones field to report that the writeback connector and
the one driving the display could be enabled at the same time.
Signed-off-by: Alexandru Gheorghe
Changes since v2:
- Use proper style for multi-line comments.
---
drivers/gpu/drm/arm/malidp_drv.c | 11 +++
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=107229
--- Comment #3 from Michel Dänzer ---
(In reply to Alexander Tsoy from comment #0)
>
> linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=y = OK
> linux-4.17.x with CONFIG_TRANSPARENT_HUGEPAGE=n + mesa-8.0.x / mesa-8.1.x =
> hang
Did you swap
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by
Update the Versatile Express defconfig to match the
Kconfig changes in the kernel.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Resending.
ChangeLog v3->v4:
- Resending.
ChangeLog v1->v3:
- Rebased
---
arch/arm/configs/vexpress_defconfig | 12
This updates the Versatile defconfig to use the new P111 DRM
driver that is merged in the DRM subsystem.
We deactivate the old CLCD driver and activate the Pl111 DRM
driver and the SiI9022 HDMI bridge.
We activate DMA memory allocation using CMA so that the special
graphics memory for the
The need to support some straight-forward VGA panels that are
not adhering to any standard like DPI arise in the ARM RTSM VE
Real-Time Systems Model Virtual Executive. This emulator (which
is not QEMU) does not model any bridge or panel other than
displaying whatever the user defines that they
https://bugzilla.kernel.org/show_bug.cgi?id=200499
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Patches adding Raven Ridge support are currently being reviewed:
https://patchwork.freedesktop.org/series/46440/
--
You are receiving this mail because:
You are watching the assignee of
On 16/07/2018 10:36, Jerome Brunet wrote:
> On Mon, 2018-07-16 at 09:40 +0200, Neil Armstrong wrote:
>> Remove the modes timings tables for DMT modes and calculate the HW
>> paremeters from the modes timings.
>>
>> Switch the DMT modes pixel clock calculation out of the static frequency
>> list to
Hi
> There are other gpu/drm drivers where drm_dev_unref is used.
> Do we need to replace drm_dev_unref with drm_dev_put in
> other places as well ?
Yes. This is some overall clean-up work that I do as a side project. I
already have patches for all drivers, but I found that sending them
1 - 100 of 113 matches
Mail list logo
