Can you try to use a fixed limit like I suggested once more?
E.g. just stop swapping if get_nr_swap_pages() < 256MB.
Maybe you missed previous mail. I explain again here.
Set the value as 256MB not work on my platform. My machine has 8GB system
memory, and 8GB swap disk.
On my ma
On Wed, Jan 17, 2018 at 11:55:35PM +0200, Laurent Pinchart wrote:
> The plane cleanup handler currently calls drm_plane_helper_disable(),
> which is a legacy helper function. Replace it with a call to
> drm_atomic_helper_shutdown() at removal time. The plane .destroy()
> handler now consisting only
Can you try to use a fixed limit like I suggested once more?
E.g. just stop swapping if get_nr_swap_pages() < 256MB.
Regards,
Christian.
Am 02.02.2018 um 07:57 schrieb He, Roger:
Use the limit as total ram*1/2 seems work very well.
No OOM although swap disk reaches full at peak
On 2018年02月02日 15:34, Chunming Zhou wrote:
On 2018年02月02日 15:22, Roger He wrote:
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/
On 2 February 2018 at 02:50, Dave Airlie wrote:
> On 2 February 2018 at 12:44, Linus Torvalds
> wrote:
>> On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote:
>>>
>>> Turned out I was running on wayland instead of X.org and my cut-n-paste from
>>> gedit to firefox got truncated, wierd. I'll go ann
Am 02.02.2018 um 08:22 schrieb Roger He:
to indicate whether we are servicing for page fault routine in
ttm_mem_global_reserve.
for ttm_mem_global_reserve if in page fault routine, allow success
always. because page fault routing already grabbed system memory
successfully and allow this exceptio
NAK, that the gfx driver doesn't need DMA32 doesn't mean that we can use
it all up with BO allocations.
It is still quite likely that other drivers in the system might need it.
Christian.
Am 02.02.2018 um 08:22 schrieb Roger He:
because this zone has only 4GB, it is easy to became bottleneck
On 2018年02月02日 15:22, Roger He wrote:
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files cha
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 875e5b8..25e1ce0 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/tt
because this zone has only 4GB, it is easy to became bottleneck for
huge normal zone.
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +++
drivers/gpu/drm/ttm/ttm_memory.c| 10 --
include/drm/ttm/ttm_memory.h| 1 +
3 files changed, 12 inserti
to indicate whether we are servicing for page fault routine in
ttm_mem_global_reserve.
for ttm_mem_global_reserve if in page fault routine, allow success
always. because page fault routing already grabbed system memory
successfully and allow this exception is harmless.
Otherwise, it will trigger O
separate swapped memory account from zone->used_mem because swapped
ttm pages can be flushed into SWAP disk/file under high memory pressure.
add check conditon in ttm_mem_global_reserve to prevent triggering OOM.
because if swap space is full, all swapped ttm pages would stay in
system memory whic
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff
Use the limit as total ram*1/2 seems work very well.
No OOM although swap disk reaches full at peak for piglit test.
But for this approach, David noticed that has an obvious defect.
For example, if the platform has 32G system memory, 8G swap disk.
1/2 * ram = 16G which is bigger
https://bugs.freedesktop.org/show_bug.cgi?id=102261
Jani Saarinen changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |tomi.p.sarv...@intel.com
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[cannot apply to v4.15 next-20180201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On 2 February 2018 at 12:44, Linus Torvalds
wrote:
> On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote:
>>
>> Turned out I was running on wayland instead of X.org and my cut-n-paste from
>> gedit to firefox got truncated, wierd. I'll go annoy some people, and make
>> sure
>> it doesn't happen ag
On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote:
>
> Turned out I was running on wayland instead of X.org and my cut-n-paste from
> gedit to firefox got truncated, wierd. I'll go annoy some people, and make
> sure
> it doesn't happen again.
Heh, so there's some Wayland clipboard buffer limit.
On Thu, Feb 1, 2018 at 4:40 PM, Dave Airlie wrote:
>
> This seems to have been a comparatively quieter merge window, I assume
> due to holidays etc.
Hmm. I pulled, and then noticed that there's no diffstat to compare my
end result with.
Then I was going to at least compare the shortlog, but that
From: Dominik Behr
v2: now with fixed result comparison and spelling fixes
Signed-off-by: Dominik Behr
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>> I got this after a recent suspend/resume:
>>
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs
>> Feb 01
Hi Dave,
I didn't send sooner because I wasn't happy with the
CI results running on drm-intel-next-fixes, but now
everything looks greener there.
Here goes drm-intel-next-fixes-2018-02-01:
Fixes for GPU hangs and other bugs around hangcheck and result;
Fix for regression on suspend case with vga
Hi Linus,
This seems to have been a comparatively quieter merge window, I assume
due to holidays etc. The "biggest" change is AMD header cleanups, which
merge/remove a bunch of them. The AMD gpu scheduler is now being made generic
with the etnaviv driver wanting to reuse the code, hopefully other
From: Dominik Behr
Signed-off-by: Dominik Behr
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 33d91e4474ea..6c1ab6
+cgroups list since this discussion goes back to the general design
On Thu, Feb 01, 2018 at 08:27:33PM +, Chris Wilson wrote:
> Quoting Matt Roper (2018-02-01 19:56:15)
> > intel_cgroup is used to modify i915 cgroup parameters. At the moment only a
> > single parameter is supported (GPU prior
On Wed, Jan 31, 2018 at 11:21:56AM +0100, Daniel Vetter wrote:
> I'm stepping down, also handing all the drm-misc stuff to the new
> team. Plan is that Sean handles 4.17, and Maarten then has fun with
> 4.18 as his first release.
>
> Cc: Maarten Lankhorst
> Cc: David Airlie
> Cc: Gustavo Padovan
https://bugs.freedesktop.org/show_bug.cgi?id=101978
--- Comment #9 from Konstantin A. Lepikhov ---
BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15
gives 25-30+ FPS and the same during the gameplay with performance set to
'auto' and fps spikes up to 50+ with 'high' per
On Thu, Feb 01, 2018 at 08:49:32PM +, Chris Wilson wrote:
> Quoting Matt Roper (2018-02-01 19:53:11)
...
> > +struct cgroup *
> > +cgroup_for_driver_process(struct pid *pid)
> > +{
> > + struct task_struct *task = pid_task(pid, PIDTYPE_PID);
> > +
> > + mutex_lock(&cgroup_mutex);
>
Quoting Andy Lutomirski (2018-02-01 21:04:30)
> I got this after a recent suspend/resume:
>
> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs
> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator:
https://bugs.freedesktop.org/show_bug.cgi?id=104463
Dmitry changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
On Thu, Feb 1, 2018 at 9:53 AM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 17:40:22)
>> *However*, I do see one unfortunate side effect of turning on PSR. It
>> seems that, when I move my cursor a little bit after a few seconds of
>> doing nothing, there seems to be a little bit of
Quoting Matt Roper (2018-02-01 19:53:11)
> Drivers will need to save/restore the appropriate cgroup data for the process
> submitting a driver request. Add an interface for drivers to determine the
> cgroup for the userspace process submitting a driver request.
>
> Cc: Tejun Heo
> Cc: cgro...@vg
Quoting Kristian Høgsberg (2018-02-01 20:22:40)
> On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson
> wrote:
>
> > Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > > *However*, I do see one unfortunate side effect of turning on PSR. It
> > > seems that, when I move my cursor a little bit after a few
Quoting Matt Roper (2018-02-01 19:56:15)
> intel_cgroup is used to modify i915 cgroup parameters. At the moment only a
> single parameter is supported (GPU priority offset). In the future the driver
> may support additional parameters as well (e.g., limits on memory usage).
>
> Signed-off-by: Ma
Quoting Matt Roper (2018-02-01 19:53:15)
> Update i915_context_status to include priority information.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i
On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson
wrote:
> Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > *However*, I do see one unfortunate side effect of turning on PSR. It
> > seems that, when I move my cursor a little bit after a few seconds of
> > doing nothing, there seems to be a little bit
Quoting Matt Roper (2018-02-01 19:53:14)
> There are cases where a system integrator may wish to raise/lower the
> priority of GPU workloads being submitted by specific OS process(es),
> independently of how the software self-classifies its own priority.
> Exposing "priority offset" as an i915-spec
Quoting Matt Roper (2018-02-01 19:53:13)
> +#include
> +
> +#include "i915_drv.h"
> +
> +struct i915_cgroup_data {
> + struct cgroup_driver_data base;
> +};
> +
> +static inline struct i915_cgroup_data *
> +cgrp_to_i915(struct cgroup_driver_data *data)
> +{
Document your requirement that ba
Quoting Matt Roper (2018-02-01 19:53:13)
> Register i915 as a consumer of the cgroup_driver framework and add an ioctl to
> allow userspace to set i915-specific parameters associated with cgroups.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm
Quoting Matt Roper (2018-02-01 19:53:13)
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd95889f4b7..1c6b53ee76cd 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
>
Quoting Matt Roper (2018-02-01 19:53:12)
> +/**
> + * drm_file_get_cgroup - obtain cgroup for drm_file's owning process
> + * @file_priv: DRM file
> + *
> + * Obtains the cgroup from a specific hierarchy that the drm_file's owning
> + * process belongs to. The cgroup may be used to set driver-spec
Quoting Matt Roper (2018-02-01 19:53:10)
> Drivers may wish to access a cgroup's inode to perform permission checks on
> driver-specific operations.
>
> Cc: Tejun Heo
> Cc: cgro...@vger.kernel.org
> Signed-off-by: Matt Roper
> ---
> fs/kernfs/inode.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
intel_cgroup is used to modify i915 cgroup parameters. At the moment only a
single parameter is supported (GPU priority offset). In the future the driver
may support additional parameters as well (e.g., limits on memory usage).
Signed-off-by: Matt Roper
---
tools/Makefile.sources | 1 +
tool
There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-lev
Update i915_context_status to include priority information.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..e9d8e20155b1 100644
Register i915 as a consumer of the cgroup_driver framework and add an ioctl to
allow userspace to set i915-specific parameters associated with cgroups.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_
Signed-off-by: Matt Roper
---
include/drm/drm_file.h| 20
kernel/cgroup/cgroup_driver.c | 12 ++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868451a5..72ac40530ad3 100644
--- a/inc
Drivers may wish to access a cgroup's inode to perform permission checks on
driver-specific operations.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
fs/kernfs/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index a3430
Drivers will need to save/restore the appropriate cgroup data for the process
submitting a driver request. Add an interface for drivers to determine the
cgroup for the userspace process submitting a driver request.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include
There are cases where drivers need to adjust behavior or control
device-specific resources according to the type of clients (processes)
submitting requests. Linux cgroups are a natural fit for this type of
resource control and policy management, so we need a way for drivers to
associate their own
This is a second iteration of the patches originally posted here:
https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
Please see the original cover letter to understand the general goal and
justification for this work.
This series makes the following important chang
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.15
head: 8a2a2ac361e69f4ad68f9a675a8b86dcfe9d82a4
commit: d5fe2b46627629c30a513761bf03093314ac7b18 [388/829] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (D
Move a5xx specific code to load firmware into a buffer object to
the generic Adreno code. This will come in useful for future targets.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 23 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 19 +
The number and type of firmware files required differs for each
target. Instead of using a fixed struct member for each possible
firmware file use a generic list of files that should be loaded
on boot. Use some semi-target specific enums to help each target
find the appropriate firmware(s) that it
This is new refresh of the outstanding changes from
https://patchwork.freedesktop.org/series/36923/. Rob expressed concern about
the microcode code duplication per target so on his suggestions we did something
different.
The developer will specify a list of applicable microcode filenames per targ
Hi,
On 1/31/2018 6:39 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which get
On Thu, Feb 1, 2018 at 12:08 AM, Harry Wentland wrote:
> On 2018-01-31 09:31 AM, Chris Chiu wrote:
>> Hi,
>> We are working with new laptops that have the AMD Ravenl Ridge
>> chipset with this `/proc/cpuinfo`
>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
>>
>> With t
On 26.01.2018 15:54, Aishwarya Pant wrote:
Add documentation for sysfs interface of adp5520/adp5501 analog devices
backlight driver by reading code and looking through git commit logs.
Signed-off-by: Aishwarya Pant
Acked-by: Michael Hennerich
---
.../ABI/testing/sysfs-class-backlight-adp
On 2/1/2018 5:03 PM, Sricharan R wrote:
Hi Robin,
On 1/31/2018 6:36 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
th
2018-02-02 1:56 GMT+09:00 Ulf Magnusson :
> On Thu, Feb 1, 2018 at 4:52 PM, Bartlomiej Zolnierkiewicz
> wrote:
>>
>> Hi,
>>
>> On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote:
>>> Blank help texts are probably either a typo, a Kconfig misunderstanding,
>>> or some kind of half-commi
On 26.01.2018 15:55, Aishwarya Pant wrote:
Add documentation for sysfs interface of adp8860 series backlight
devices by reading through code and git commits.
Signed-off-by: Aishwarya Pant
Acked-by: Michael Hennerich
---
.../ABI/testing/sysfs-class-backlight-adp8860 | 54
Il 01/02/2018 11:14, Maxime Ripard ha scritto:
On Sat, Jan 27, 2018 at 11:07:09PM +0100, Giulio Benetti wrote:
I don't really know what the polarity of D0 would be just by
judging at that capture, but we would have noticed if the colors
were inverted for quite some time now.
D0-D23 are correct
From: Kuninori Morimoto
panel-lvds.c is for LVDS Panel Driver,
not R-Car Display Unit CRTCs
Reported-by: Koji Matsuoka
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/panel/panel-lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.
On Thu, Feb 1, 2018 at 4:52 PM, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote:
>> Blank help texts are probably either a typo, a Kconfig misunderstanding,
>> or some kind of half-committing to adding a help text (in which case a
>> TODO
On Thu, Feb 01, 2018 at 11:06:42AM +, Daniel Thompson wrote:
> On Fri, Jan 26, 2018 at 08:23:00PM +0530, Aishwarya Pant wrote:
> > Add documentation for sysfs interface of Texas Instruments lp855x
> > backlight driver by reading code and looking through git commit logs.
> >
> > Signed-off-by:
Dear Rodrigo Vivi, Ville Syrjälä,
My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We
intend to use static analysis tools on the kernel source to identify,
analyze and report issues. As a very first step, we are looking into
clang compiler warnings and will then move to more
Hi Robin,
On 1/31/2018 6:36 PM, Robin Murphy wrote:
> On 19/01/18 11:43, Vivek Gautam wrote:
>> From: Sricharan R
>>
>> The smmu device probe/remove and add/remove master device callbacks
>> gets called when the smmu is not linked to its master, that is without
>> the context of the master device
https://bugs.freedesktop.org/show_bug.cgi?id=102261
Imre Deak changed:
What|Removed |Added
Assignee|imre.d...@intel.com |dri-devel@lists.freedesktop
This adds the NvPmEnableGating config option to nouveau, which can be
used to enable or disable clockgating for supported chipsets. Enabling
can be done by passing
config=NvPmEnableGating=1
To nouveau. If your chipset supports it, you'll see a message in your
kernel log indicating that cl
That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating. The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before
Same as the previous patch, but for Kepler2 now
Signed-off-by: Lyude Paul
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62 ++
This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more
This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).
This introduces two therm helpers for controlling ba
Next version of my patchseries for adding clockgating support for
kepler1 and 2 on nouveau. The first version of this series can be found
here:
https://patchwork.freedesktop.org/series/36504/
Some small changes (shouldn't change anything functionally):
- Made gf100_therm_new, gk104_clkgate_pack,
On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
> Dear Rodrigo Vivi, Ville Syrjälä,
>
> My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We
> intend to use static analysis tools on the kernel source to identify,
> analyze and report issues. As a very first step, w
Quoting Andy Lutomirski (2018-02-01 17:40:22)
> *However*, I do see one unfortunate side effect of turning on PSR. It
> seems that, when I move my cursor a little bit after a few seconds of
> doing nothing, there seems to be a little bit of lag, as if either a
> few frames are dropped at the begin
On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote:
> Hi-
>
> As requested in your blog post, I tested PSR. I see something like
> 2.69W with PSR off and 2.17W with PSR on. Screen blanking,
> suspend/resume, and the contents of the screen all seem okay. This is
> a Dell XPS 13 9350, i.e.:
>
Hi-
As requested in your blog post, I tested PSR. I see something like
2.69W with PSR off and 2.17W with PSR on. Screen blanking,
suspend/resume, and the contents of the screen all seem okay. This is
a Dell XPS 13 9350, i.e.:
System Information
Manufacturer: Dell Inc.
Product N
Thanks!
Quoting Eric Engestrom (2018-01-31 03:14:50)
> On Thursday, 2018-01-25 16:14:45 -0800, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker
>
> Reviewed-by: Eric Engestrom
>
> > ---
> >
> > I have tested building every mesa driver against this (with and without
> > udev!)
> > so I'm pre
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20180201]
[cannot apply to v4.15]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi,
Sorry for joining the party late. Had a broken finger and was offline
for a bunch of weeks (and a buif backlog afterwards ...).
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the co
On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote:
> Using a Kconfig 'select' statement for a user-visible symbol that other
> drivers depend on often causes circular dependencies. A new one showed
> up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
>
> drivers/i2c/Kconf
https://bugs.freedesktop.org/show_bug.cgi?id=104906
Ilia Mirkin changed:
What|Removed |Added
Component|Drivers/DRI/r200|Drivers/Gallium/radeonsi
--
You are rece
Hi,
On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote:
> Blank help texts are probably either a typo, a Kconfig misunderstanding,
> or some kind of half-committing to adding a help text (in which case a
> TODO comment would be clearer, if the help text really can't be added
> right a
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #29 from Deposite Pirate (dpir...@metalpunks.info) ---
Created attachment 273963
--> https://bugzilla.kernel.org/attachment.cgi?id=273963&action=edit
dmesg output
Here's the dmesg output with the patch applied On top of v4.15 (compi
https://bugs.freedesktop.org/show_bug.cgi?id=104906
Bug ID: 104906
Summary: Mesa crashes randomly during Youtube playback
Product: Mesa
Version: 17.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Se
https://bugs.freedesktop.org/show_bug.cgi?id=104880
Konstantin A. Lepikhov changed:
What|Removed |Added
Summary|No sound via DP on R9 Fury |No sound via DP on R9 Fury
Den 01.02.2018 16.15, skrev Noralf Trønnes:
Den 01.02.2018 14.19, skrev Ville Syrjälä:
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB155
Den 01.02.2018 14.19, skrev Ville Syrjälä:
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This
https://bugs.freedesktop.org/show_bug.cgi?id=104880
--- Comment #7 from Konstantin A. Lepikhov ---
Tried with changes from amd-staging-4.15 up to v4.15-829-g8a2a2ac :
[lakostis@lks ~]$ fgrep -r monitor /proc/asound/HDMI/
...
/proc/asound/HDMI/eld#0.0:monitor_present 0
/proc/asound
On Wed, Jan 31, 2018 at 12:46 PM, John Stultz wrote:
> On Wed, Jan 31, 2018 at 8:01 AM, Emil Velikov
> wrote:
>> On 30 January 2018 at 05:42, John Stultz wrote:
>>> On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov
>>> wrote:
Hi all,
Couple of ideas/notes,
On 10 January
On Wed, Jan 31, 2018 at 11:29 PM, Archit Taneja wrote:
>
>
> On 01/31/2018 09:50 PM, Rob Clark wrote:
>>
>> On Wed, Jan 31, 2018 at 1:40 AM, Archit Taneja
>> wrote:
>>>
>>>
>>>
>>> On 01/29/2018 10:45 PM, Rob Herring wrote:
On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wr
On 2018-02-01 05:30 AM, Maarten Lankhorst wrote:
> Op 31-01-18 om 20:57 schreef Harry Wentland:
>> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
>>> Op 29-01-18 om 16:41 schreef Leo Li:
Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>
On Thu, Feb 01, 2018 at 05:42:35AM +0100, Mauro Rossi wrote:
> Il 08/gen/2018 09:46 PM, "Sean Paul" ha scritto:
>
> On Mon, Jan 08, 2018 at 03:41:49PM -0500, Sean Paul wrote:
> > On Sat, Jan 06, 2018 at 12:59:58AM +0100, Mauro Rossi wrote:
> > > Porting of original commit 76fb87e675 of Jim Bish i
https://bugs.freedesktop.org/show_bug.cgi?id=102423
--- Comment #5 from Alex Deucher ---
amdgpu is the kernel driver and radeonsi is the user mode mesa driver. They
both work together on your system.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104895
--- Comment #3 from Marta Löfstedt ---
(In reply to Mika Kuoppala from comment #2)
> The test in question fails before the commit in question, so that is not the
> offending commit.
please specify on which CI/IGT run before IGT_4206 the test wa
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
> The following happened when migrating an old fbdev driver to DRM:
>
> The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
> or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
>
> This makes the initialization of the fr
https://bugs.freedesktop.org/show_bug.cgi?id=104895
--- Comment #2 from Mika Kuoppala ---
The test in question fails before the commit in question, so that is not the
offending commit.
--
You are receiving this mail because:
You are the assignee for the bug._
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns th
The Versatile PL110 implementations use multiple endpoints:
from the PL111 port, the lines are routed through a PLD,
and from there forked so the same lines go to a VGA DAC and
an external TFT panel connector. This is discrete wireing
so there is no way to turn of one output, i.e. this is
really tw
1 - 100 of 131 matches
Mail list logo
