On 04.02.2018 22:31, Philippe Cornu wrote:
> This patch adds the DCS/GENERIC DSI read feature.
>
> Signed-off-by: Philippe Cornu
> ---
Queued to drm-misc-next.
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fr
On 06.02.2018 09:42, Philippe Cornu wrote:
> Add support for the Synopsys DesignWare MIPI DSI version 1.31
> Two registers need to be updated/added for supporting 1.31:
> * PHY_TMR_CFG 0x9c (updated)
> 1.30 [31:24] phy_hs2lp_time
>[23:16] phy_lp2hs_time
>[14: 0] max_rd_time
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #5 from Dmitry ---
dc1 + hdmi. The problem remained
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
Hi Linus,
Ben missed sending his tree, but he really didn't have much stuff in
it, GP108 acceleration support is enabled by "secure boot" support,
some clockgating work on Kepler, and bunch of fixes. The main bulk is
regenerated firmware files, the change to them really isn't that
large.
Otherwis
swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_device.c
get the max io mapping address of system memory to see if it is over
our card accessing range.
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
drivers/gpu/drm/
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
---
include/drm/drm_cache.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0c
Hi Ville,
I still have some queries regarding the handling of aspect ratio flags
in getblob ioctl.
Please find below my responses inline.
On 2/1/2018 6:24 PM, Ville Syrjälä wrote:
On Thu, Feb 01, 2018 at 04:35:22PM +0530, Nautiyal, Ankit K wrote:
Hi Ville,
Appreciate your time and the sug
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use
Use subdir-ccflags instead of specifying the same flags for every source
file.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
---
Changes in v2:
- added 'Reviewed-by: Guenter Roeck ' tag
drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
1 file changed, 1 insertion(+), 9
El Wed, Feb 07, 2018 at 05:34:44PM -0800 Guenter Roeck ha dit:
> On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote:
> > DML uses the compiler option -mpreferred-stack-boundary=4 to configure
> > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> > instead, which expect
Use subdir-ccflags instead of specifying the same flags for every source
file.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
b/drivers/gpu
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use
Hi Archit,
On 07/02/18 12:33, Kieran Bingham wrote:
> Hi Archit,
>
> Thank you for your review,
>
>>> unsigned int val;
>>> int ret;
>>> @@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c,
>>> const struct i2c_device_id *id)
>>> if (ret)
>>>
Hi Laurent,
On 07/02/18 21:59, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
>> On 29/01/18 10:26, Laurent Pinchart wrote:
>>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
The ADV7511 has four 256-byte maps that can
Hi Lukasz,
I hope you are doing great. I was busy with some other stuff but now will be
working on page-flip damage. At this point I have high level understanding of
what changes to make and before I start just wanted to confirm from you,
whether you have made any progress to avoid duplicate wo
Hello,
On Thu, Feb 01, 2018 at 11:53:11AM -0800, Matt Roper wrote:
> +/**
> + * cgroup_for_driver_process - return the cgroup for a process
> + * @pid: process to lookup cgroup for
> + *
> + * Returns the cgroup from the v2 hierarchy that a process belongs to.
> + * This function is intended to be
Hello,
On Thu, Feb 01, 2018 at 11:53:09AM -0800, Matt Roper wrote:
> * Drivers may be built as modules (and unloaded/reloaded) which is not
>something cgroup controllers support today.
As discussed in the other subthread, this shouldn't be a concern.
> * Drivers may wish to provide their o
Hi Kieran,
On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> On 29/01/18 10:26, Laurent Pinchart wrote:
> > On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> >> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> >> ports. Each map has it own I
Hello,
Forgot to respond to one point.
On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote:
> * The drivers that want to make use of this functionality may be built
>as modules rather than compiled directly into the kernel. This is
>important because the cgroups subsystem removed
On 2018-02-07 04:43 PM, Matthias Kaehlcke wrote:
> The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
> graphics_csc_adjust_type to program_color_matrix(), however the function
> expects a parameter of type enum grph_color_adjust_option. Supposedly
> the intention was to pass GRPH_COLOR_MAT
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #4 from Dmitry ---
Created attachment 137223
--> https://bugs.freedesktop.org/attachment.cgi?id=137223&action=edit
Xorg log
Attach Xorg log. DC then turned, I'll watch the reaction.
--
You are receiving this mail because:
You ar
Hello, Matt, Chris.
On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote:
> > Hmm. Could we not avoid drm_ioctl + well known param names and use a
> > more generic tool to set cgroup attributes? Just feels wrong that a
> > such a generic interface boils down to a driver specific ioctl.
So,
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #3 from Dmitry ---
Created attachment 137222
--> https://bugs.freedesktop.org/attachment.cgi?id=137222&action=edit
dmesg
Attach dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
From: Markus Elfring
Date: Wed, 7 Feb 2018 22:34:45 +0100
* Return directly after a call of the function "kzalloc" failed
at the beginning.
* Delete an initialisation and a check (for the local variable "kms")
which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
--
From: Markus Elfring
Date: Wed, 7 Feb 2018 22:22:28 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 1 -
1 file changed, 1 deleti
From: Markus Elfring
Date: Wed, 7 Feb 2018 22:38:44 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
Return directly after a failed kzalloc()
drivers/gpu/drm/msm/mdp/mdp4/mdp4_k
The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
graphics_csc_adjust_type to program_color_matrix(), however the function
expects a parameter of type enum grph_color_adjust_option. Supposedly
the intention was to pass GRPH_COLOR_MATRIX_SW, which has the same value
as GRAPHICS_CSC_ADJUST_T
On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> On 05.02.2018 07:08, Rob Herring wrote:
> > On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> >> These bindings allow to describe most known standard USB connectors
> >> and it should be possible to extend it if necessa
On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
> On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> > > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> > > return type for drm_
From: Markus Elfring
Date: Wed, 7 Feb 2018 21:50:07 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 1 -
drivers/gpu/drm/msm/md
On 2018-02-07 02:49 PM, Matthias Kaehlcke wrote:
> The double parentheses are not needed. Removing them fixes multiple
> warnings like this when building with clang:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
> error: equality comparison with extraneous parentheses
>
On Wed, Feb 7, 2018 at 2:19 PM, Guenter Roeck wrote:
> On Wed, Feb 7, 2018 at 11:10 AM, Matthias Kaehlcke wrote:
>> The double parentheses are not needed. Removing them fixes the following
>> warning when building with clang:
>>
>> drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
>>
Hi Dave,
Here goes drm-intel-next-fixes-2018-02-07:
Fix for pcode timeouts on BXT and GLK, cmdparser fixes and fixes
for new vbt version on CFL and CNL.
GVT contains vGPU reset enhancement, which refines vGPU reset flow
and the support of virtual aperture read/write when x-no-mmap=on
is set in K
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #2 from Alex Deucher ---
Does it work with DC enabled?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #1 from Alex Deucher ---
Please include your dmesg output and Xorg log if using X.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-
From: Markus Elfring
Date: Wed, 7 Feb 2018 21:17:17 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tegra/fb.c | 4 +---
1 file changed, 1 insertion(+), 3
https://bugzilla.kernel.org/show_bug.cgi?id=197925
--- Comment #12 from kwka...@gmx.com ---
Still not fixed v4.15-11781-g413879a10b0b
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel
The double parentheses are not needed. Removing them fixes multiple
warnings like this when building with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
if ((data->graphics_mi
https://bugs.freedesktop.org/show_bug.cgi?id=105005
Bug ID: 105005
Summary: No image after downtime (RX460)
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: cri
On Wed, Feb 07, 2018 at 11:41:49AM -0600, Rob Herring wrote:
> On Tue, Feb 6, 2018 at 3:48 PM, Sean Paul wrote:
> > On Tue, Feb 06, 2018 at 02:19:34PM -0600, Rob Herring wrote:
> >> On Tue, Feb 6, 2018 at 10:56 AM, Sean Paul wrote:
> >> > This patch adds the ability to override the typical displa
On 07.02.2018 18:45, Thierry Reding wrote:
> From: Thierry Reding
>
> This fixes hangs with legacy applications that use the mmap() syscall on
> the fbdev device to map framebuffer memory. The fbdev implementation for
> mmap() creates a mapping that conflicts with DRM usage and causes a hang
> wh
Hi Dave,
Just one fix this week for 4.16. This is on top of the pull request I
sent last week. One of the fixes from last week got applied to the wrong
asic by accident. The patch this week fixes that.
The following changes since commit 7e24a3ea825e546487c3fc47f8cbf6512f6c9e8c:
drm/amdgpu:
The double parentheses are not needed. Removing them fixes the following
warning when building with clang:
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
if ((data->vdd_gfx_control == SMU7_
On Wed, Feb 7, 2018 at 2:01 PM, Guenter Roeck wrote:
> On Wed, Feb 7, 2018 at 10:58 AM, Matthias Kaehlcke wrote:
>> In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
>> amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
>> amd_powergating_stat) and vice versa. Both
In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
amd_powergating_stat) and vice versa. Both constants have the same
value, so this doesn't cause any problems, but we still want to pass
the correct type.
Fixing the
Hans de Goede writes:
> Hi,
>
> On 06-02-18 00:14, Rodrigo Vivi wrote:
>>
>> Hi Hans,
>>
>> On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01-02-18 13:31, Hans de Goede wrote:
Hi All,
As you may have heard I've recently been working on improving
>
Hi,
On 02/07/2018 02:22 PM, Christian König wrote:
Understood, but why is that?
Well because customers requested it :)
What we try to do here is having a parameter which says when less than
x megabytes of memory are left then fail the allocation.
This is basically to prevent buggy applicati
Reviewed-by: Lyude Paul
On Wed, 2018-02-07 at 18:40 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The recently introduced clock gate support breaks on Tegra chips because
> no thermal support is enabled for those devices. Conditionalize the code
> on the existence of thermal support t
https://bugs.freedesktop.org/show_bug.cgi?id=104932
--- Comment #5 from Robin Kauffman ---
(In reply to Michel Dänzer from comment #4)
> Which versions of Mesa & LLVM are you using?
LLVM & Clang 7.0 Git, LLVM commit e0c16f05e9fbc1dcd291814ceab9dbc5, Clang
commit e0c16f05e9fbc1dcd291814ceab9dbc5.
From: Thierry Reding
This function allows mapping a GEM object into a virtual memory address
space, which makes it useful outside of the GEM code.
While at it, rename the function so it doesn't clash with the function
that implements the DRM_TEGRA_GEM_MMAP IOCTL.
Signed-off-by: Thierry Reding
From: Thierry Reding
Move declarations in the gem.h header file into the same order as the
corresponding definitions in gem.c.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.h b/dri
From: Thierry Reding
This fixes hangs with legacy applications that use the mmap() syscall on
the fbdev device to map framebuffer memory. The fbdev implementation for
mmap() creates a mapping that conflicts with DRM usage and causes a hang
when the memory is accessed through the mapping.
Reporte
On Tue, Feb 6, 2018 at 3:48 PM, Sean Paul wrote:
> On Tue, Feb 06, 2018 at 02:19:34PM -0600, Rob Herring wrote:
>> On Tue, Feb 6, 2018 at 10:56 AM, Sean Paul wrote:
>> > This patch adds the ability to override the typical display timing for a
>> > given panel. This is useful for devices which hav
From: Thierry Reding
The recently introduced clock gate support breaks on Tegra chips because
no thermal support is enabled for those devices. Conditionalize the code
on the existence of thermal support to fix this.
Fixes: b138eca661cc ("drm/nouveau: Add support for basic clockgating on
Kepler1
https://bugs.freedesktop.org/show_bug.cgi?id=103142
Gert Wollny changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=103142
--- Comment #7 from Gert Wollny ---
It seems sb is trying to create an operation that tries to use two distinct
relative indices within the same instruction, this is forbidden and the
scheduler gets stuck.
from the post scheduler dump:
# 0.
This patch adds an override mode for kevin devices. The mode increases
both back porches to allow a pixel clock of 2kHz as opposed to the
'typical' value of 252750kHz. This is needed to avoid interference with
the touch digitizer on these laptops.
Changes in v2:
- Wrap the timing in display-t
In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.
Changes in v2:
- Added
Cc: Doug Anderson
Cc: Eric Anholt
Cc: Heiko Stuebner
Cc: Jeffy Chen
Cc: Rob Herring
Cc: Stéphane Marchesin
Cc: Thierry Reding
Cc: devicet
Hey all,
Here's a set which allows us to add an "override" mode to the simple
panel dt node. The override mode can be used for devices for which the
typical display timing is not sufficient, yet the overriding mode should
not be applied across the entire platform.
An example of this (and the motiv
Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the
This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.
Changes in v2:
- Split out the binding into a new patch (Rob)
- display-timings is a new section (Rob)
- Use the full display-timings subnode instead of picking the
This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:
- pan
On Wed, Feb 07, 2018 at 05:08:30PM +, Eric Engestrom wrote:
> On Wednesday, 2018-02-07 17:24:45 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace the switch statements that try to map between the fb format and
> > the fb_bitfield infromation with a single table.
> >
> > Not
https://bugzilla.kernel.org/show_bug.cgi?id=198713
--- Comment #3 from Jon (j...@moozaad.co.uk) ---
(In reply to Mike Lothian from comment #2)
> As a workaround try amdgpu.dc=0
Well spotted. Workaround has stopped the traces as you'd expect. It's also
stopped the weird blue flicker I was getting
On Wednesday, 2018-02-07 17:24:45 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the switch statements that try to map between the fb format and
> the fb_bitfield infromation with a single table.
>
> Note that this changes the behaviour of drm_fb_helper_check_var() to
> return an
On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> > In case anyone's curious about 30bpp framebuffer support, here's the
> > current status:
> >
> > Kernel:
> >
> > Ben and I have switched the code to using a 256-based
https://bugs.freedesktop.org/show_bug.cgi?id=100784
--- Comment #4 from Jon ---
Present in 18.0.0 too. Still drops to single figures for transitions from space
station menu to solar map. Doesn't seem present from galactic map to solar map.
--
You are receiving this mail because:
You are the ass
https://bugzilla.kernel.org/show_bug.cgi?id=196771
Rokas Kupstys (rokups+kernel-b...@zoho.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> In case anyone's curious about 30bpp framebuffer support, here's the
> current status:
>
> Kernel:
>
> Ben and I have switched the code to using a 256-based LUT for Kepler+,
> and I've also written a patch to cause the addfb ioctl to
https://bugzilla.kernel.org/show_bug.cgi?id=198713
Mike Lothian (m...@fireburn.co.uk) changed:
What|Removed |Added
CC||m...@fireburn.co.uk
https://bugzilla.kernel.org/show_bug.cgi?id=198713
--- Comment #1 from Jon (j...@moozaad.co.uk) ---
Created attachment 274055
--> https://bugzilla.kernel.org/attachment.cgi?id=274055&action=edit
kernel config from /boot
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=198713
Bug ID: 198713
Summary: AMD DC crashes when computing clocks/detecting
freesync
Product: Drivers
Version: 2.5
Kernel Version: 4.15.1-7
Hardware: x86-64
Hi Rob,
On 29/01/18 20:08, Rob Herring wrote:
> On Mon, Jan 22, 2018 at 12:49:56PM +, Kieran Bingham wrote:
>> From: Jean-Michel Hautbois
>>
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts as a standard slave
>
On 07/02/18 14:10, Jyri Sarha wrote:
> Call to omap_drm_irq_install() may fail with an error code. In such a
> case the driver probe should fail.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a
On Wed, Feb 07, 2018 at 09:16:22AM +, Eric Anholt wrote:
> Sean Paul writes:
>
> > Hey all,
> > Here's a set which allows us to add an "override" mode to the simple
> > panel dt node. The override mode can be used for devices for which the
> > typical display timing is not sufficient, yet the
From: Ville Syrjälä
Replace the switch statements that try to map between the fb format and
the fb_bitfield infromation with a single table.
Note that this changes the behaviour of drm_fb_helper_check_var() to
return an error of the requested fb_bitfields don't match the actual
pixel format. Pre
Hi Laurent,
On 29/01/18 10:26, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
Thanks for your review,
> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C
Hi Linus,
Please pull fbdev changes for v4.16. There is nothing really major here
(please see the signed tag description for details).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit 464e1d5f23cca236b930ef068c328a6
https://bugs.freedesktop.org/show_bug.cgi?id=104963
--- Comment #2 from VF ---
No, neither radeon.bapm=O nor radeon.bapm=1 help neither in K4.4.0-112 nor
K4.15.1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel ma
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 1fe699e30113ed6f6e853ff44710d256072ea627
commit: 1fe699e30113ed6f6e853ff44710d256072ea627 [1/1] drm/i915/pmu: Fix sleep
under atomic in RC6 readout
config: i386-randconfig-x019-201805 (attached as .config)
compiler: gcc-
Signed-off-by: Eric Engestrom
---
amdgpu/meson.build| 2 +-
etnaviv/meson.build | 2 +-
freedreno/meson.build | 2 +-
intel/meson.build | 2 +-
meson.build | 3 ++-
nouveau/meson.build | 2 +-
omap/meson.build | 2 +-
radeon/meson.build| 2 +-
tegra/meson.build
Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
adhoc names here and there in the omapdrm code. This moves the names
of hardware entities to omapdss side where they have to be when new
omapdss backend drivers are introduced.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm
Call to omap_drm_irq_install() may fail with an error code. In such a
case the driver probe should fail.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/
The new omapdss API is HW independent and cleans up some of the DSS5
specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
register bits and replace them with HW independent generic u64 based
macros. The new macros make it more straight forward to implement the
IRQ code for the future
Since v2:
- Simplify dispc_mgr_has_framedone()
- dispc_hw_to_api_irq() and dispc_api_to_hw_irq() use new dispc_irq_bits[]
- rename dispc_ops read_irqstatus() to read_and_clear_irqstatus() and remove
clearmask
- precalculate priv->irq_uf_mask in omap_drm_irq_install() and use it in
omap_irq_fif
On 2/6/2018 10:54 PM, Imre Deak wrote:
Hi Rafael,
On Tue, Feb 06, 2018 at 09:11:02PM +, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-06 18:33:11)
From: Tvrtko Ursulin
We are not allowed to call intel_runtime_pm_get from the PMU counter read
callback since the former can sleep, and
On 05.02.2018 19:07, Thierry Reding wrote:
> On Mon, Feb 05, 2018 at 06:39:05PM +0100, Lucas Stach wrote:
>> Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
>>> On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Redi
On 07/02/18 14:10, Jyri Sarha wrote:
> Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
> adhoc names here and there in the omapdrm code. This moves the names
> of hardware entities to omapdss side where they have to be when new
> omapdss backend drivers are introduced.
>
> Signed
Understood, but why is that?
Well because customers requested it :)
What we try to do here is having a parameter which says when less than x
megabytes of memory are left then fail the allocation.
This is basically to prevent buggy applications which try to allocate as
much memory as possible
Hi, Roger.
On 02/07/2018 09:25 AM, He, Roger wrote:
Why should TTM be different in that aspect? It would be good to know
your reasoning WRT this?
Now, in TTM struct ttm_bo_device it already has member no_retry to indicate
your option.
If you prefer no OOM triggered by TTM, set it as t
On Mon, 05 Feb 2018, Thierry Reding wrote:
> From: Thierry Reding
>
> This helper chooses an appropriate configuration, according to the
> bitrate requirements of the video mode and the capabilities of the
> DisplayPort sink.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_help
https://bugzilla.kernel.org/show_bug.cgi?id=198669
--- Comment #13 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk)
---
You can ignore comment 11. I I thought the email reply had not worked. So I
posted a revised version directly. Comment 10 is the correct one.
--
You are receivin
Hi Archit,
Thank you for your review,
On 29/01/18 04:11, Archit Taneja wrote:
> Hi,
>
> On 01/22/2018 06:20 PM, Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C address and acts as a standard slave
>> device on th
From: Colin Ian King
The structure bochs_bo_driver is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warning:
drivers/gpu/drm/bochs/bochs_mm.c:197:22: warning: symbol 'bochs_bo_driver'
was not declared. Should it be static?
Signed-off-by: Colin
On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> > > > Also, how was it tested? This seems quite weird that we haven't caught
> > > > that one sooner, and I'm a bit worried about the possible regressions
> > > > here.
> > >
> > > It sounds really strange to me too,
> > > because e
Sure, will make it turn off as default and make the limit configurable.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, February 07, 2018 4:41 PM
To: He, Roger ; Thomas Hellstrom ;
amd-...@lists.freedesktop.org;
https://bugs.freedesktop.org/show_bug.cgi?id=104989
Vlad Golovkin changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Tue, Feb 06, 2018 at 02:19:34PM -0600, Rob Herring wrote:
> On Tue, Feb 6, 2018 at 10:56 AM, Sean Paul wrote:
> > This patch adds the ability to override the typical display timing for a
> > given panel. This is useful for devices which have timing constraints
> > that do not apply across the e
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server. Buffers must be passed from client to
server/proxy somehow, probably using fd passing
1 - 100 of 113 matches
Mail list logo