https://bugs.freedesktop.org/show_bug.cgi?id=104895
Marta Löfstedt changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mika.kah...@intel.com
Need call si_swapinfo to fill those valules .
void si_swapinfo(struct sysinfo *val)
But that function is not exported as well.
Thanks
Roger(Hongbo.He)
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Chunming Zhou
Sent: Friday, February 02, 2018 3:38 PM
To: He, Roger
On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote:
> 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
Hi Robin/Vivek,
On 2/1/2018 2:23 PM, Vivek Gautam wrote:
> 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/disabl
Hi Greg,
On Thu, 1 Feb 2018, Greg KH wrote:
> 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 identi
01.02.2018, 21:03, "Greg KH" :
> 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
Hi Ozan,
why did you send e-mail to kernel development e-mail list?
>> intend to us
https://bugs.freedesktop.org/show_bug.cgi?id=104902
João Henrique changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, 01 Feb 2018, Lukas Bulwahn wrote:
> Hi Greg,
>
> On Thu, 1 Feb 2018, Greg KH wrote:
>
>> 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
On Mon, Jan 8, 2018 at 9:46 PM, Sean Paul wrote:
> 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 in android-ia master to
>> > fdo
>> >
>> > Original commit message:
Probably it is necessary to summarize, and I have done below experiments:
A: use a fixed limit to stopping swapping out as below:
int ttm_bo_swapout(struct ttm_bo_global *glob, struct ttm_operation_ctx
*ctx) {
if get_nr_swap_pages() < 256MB return no memory;
}
Adding the amd-gfx list, please always send amdgpu patches there.
On 2018-02-02 02:55 AM, db...@chromium.org wrote:
> 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_ty
Hi Baruch,
Thank you for the patch.
On Monday, 22 January 2018 18:01:42 EET Baruch Siach wrote:
A commit message is usually required. This patch is so simple that I'm fine
with it as-is though.
> Cc: Laurent Pinchart
> Signed-off-by: Baruch Siach
Reviewed-by: Laurent Pinchart
Thierry, cou
Hi Morimoto-san,
Thank you for your patch.
On Thursday, 1 February 2018 09:45:36 EET Kuninori Morimoto wrote:
> 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
A similar patch
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
Linux laptop battery life, specifically the OOTB experience
without tweaking any options such as e.g. powertop --auto-tune
would do, see:
https://fedoraproject.org/wiki/Changes/Imp
On Fri, Feb 02, 2018 at 10:56:36AM +0100, Lukas Bulwahn wrote:
> On Fri, 2 Feb 2018, Jani Nikula wrote:
>
> > Being brutally honest, please write shorter reports and shorter emails
> > to the lists.
> >
> > The static analysis reports are welcome, but only when 1) we didn't
> > already fix it in
Current implementation of mode_valid() and mode_fixup() callbacks
handle packed pixel modes improperly.
Fix it by using proper maximum clock values from the documentation.
Signed-off-by: Maciej Purski
---
Changes in v2:
- simplify is_packing_required() function
- fix uninitialized variable dete
+Knut, Fengguang
On Fri, 02 Feb 2018, Greg KH wrote:
> - If clang now builds the kernel "cleanly", yes, I want to take
> warning fixes in the stable tree. And even better yet, if you
> keep working to ensure the tree is "clean", that would be
> wonderful.
So we ca
On 02/02/18 05:40, Sricharan R wrote:
Hi Robin/Vivek,
On 2/1/2018 2:23 PM, Vivek Gautam wrote:
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 runti
On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap wrote:
> On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote:
>> 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 dep
Building the amd display driver with link-time optimizations revealed a bug
that caused dal_cmd_tbl_helper_dce80_get_table() and
dal_cmd_tbl_helper_dce110_get_table() get called with an incompatible
return type between the two callers in command_table_helper.c and
command_table_helper2.c:
drivers/
On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
>
> +Knut, Fengguang
>
> On Fri, 02 Feb 2018, Greg KH wrote:
> > - If clang now builds the kernel "cleanly", yes, I want to take
> > warning fixes in the stable tree. And even better yet, if you
> > keep working to ens
https://bugs.freedesktop.org/show_bug.cgi?id=100069
--- Comment #4 from Gregor Münch ---
Created attachment 137129
--> https://bugs.freedesktop.org/attachment.cgi?id=137129&action=edit
Ingame
Looks like this is one of the last games which have pretty garbled graphics
with mesa.
What is needed
On Thu, Feb 1, 2018 at 2:19 PM, Ville Syrjälä
wrote:
> [Me]
>> + /*
>> + * If we run into a situation where, for example, the primary plane
>> + * supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
>> + * 16) we need to scale down the depth of the sizes we reques
On Fri, Feb 02, 2018 at 02:56:30PM +0100, Linus Walleij wrote:
> On Thu, Feb 1, 2018 at 2:19 PM, Ville Syrjälä
> wrote:
> > [Me]
> >> + /*
> >> + * If we run into a situation where, for example, the primary plane
> >> + * supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, d
On Tue, Jan 23, 2018 at 09:02:35PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2018 at 06:42:00PM +, Russell King - ARM Linux wrote:
> > On Tue, Jan 23, 2018 at 07:08:55PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > As armada isn't an atomic driver trying to pass a non
This will make it possible for userspace to know whether reading
will block, without blocking on the fd. This makes it possible to
drain all queued CRC's in blocking mode, without having to reopen
the fd.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
On Fri, 02 Feb 2018, Greg KH wrote:
> On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
>>
>> +Knut, Fengguang
>>
>> On Fri, 02 Feb 2018, Greg KH wrote:
>> >- If clang now builds the kernel "cleanly", yes, I want to take
>> > warning fixes in the stable tree. And even bette
On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
> This will make it possible for userspace to know whether reading
> will block, without blocking on the fd. This makes it possible to
> drain all queued CRC's in blocking mode, without having to reopen
> the fd.
>
> Signed-off-by:
Building with LTO enabled reveals some functions whose prototypes
in the header are different from the definition:
drivers/video/fbdev/sis/sis_main.h:765:0: error: type of 'SiS_SetCH70xxANDOR'
does not match original declaration [-Werror=lto-type-mismatch]
extern void SiS_SetCH70xxANDOR(struct
On Tue, Jan 23, 2018 at 07:08:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
>
> Note that this replaces crtc_state->adjusted_mode usage with
> crtc_state->mode. The latter is the correct choice since that's the
> mod
On Fri, Feb 02, 2018 at 04:10:39PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2018 at 09:02:35PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2018 at 06:42:00PM +, Russell King - ARM Linux wrote:
> > > On Tue, Jan 23, 2018 at 07:08:55PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrj
In case of interlace mode video processor registers and mixer config
register must be check to ensure internal state is in sync with shadow
registers.
This patch fixes page-faults in interlaced mode.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 ++
drivers/
Hi Inki, Tobias,
This is reviewed/updated/tested Tobias's patch addressing page-faults
in Video Processor in interlaced mode. Plus preliminary patch fixing Mixer
interlaced mode.
Regards
Andrzej
Andrzej Hajda (1):
drm/exynos/mixer: fix synchronization check in interlaced mode
Tobias Jakobi (
From: Tobias Jakobi
If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().
Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos of source and destination
Signed-off-by: Tobias Jakobi
[ a.hajda: Halved also destinat
https://bugs.freedesktop.org/show_bug.cgi?id=104902
Michel Dänzer changed:
What|Removed |Added
CC||rtf...@gmail.com
--- Comment #2 from Mi
gcc points out a buffer that is clearly too small to be used
in a meaningful way, as the 'sizeof(*args) + argc > sizeof(stack)'
will always fail:
In function 'memcpy',
inlined from 'nvif_vmm_map' at drivers/gpu/drm/nouveau/nvif/vmm.c:55:2:
include/linux/string.h:353:9: error: '__builtin_memcpy
On 2018-02-02 07:31 AM, Arnd Bergmann wrote:
> Building the amd display driver with link-time optimizations revealed a bug
Curious how I'd go about building with link-time optimizations.
> that caused dal_cmd_tbl_helper_dce80_get_table() and
> dal_cmd_tbl_helper_dce110_get_table() get called with
On 2018-02-01 08:55 PM, db...@chromium.org wrote:
> 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
On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2018, Greg KH wrote:
> > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> >>
> >> +Knut, Fengguang
> >>
> >> On Fri, 02 Feb 2018, Greg KH wrote:
> >> > - If clang now builds the kernel "cleanly", yes, I
On Fri, Feb 2, 2018 at 4:39 PM, Harry Wentland wrote:
> On 2018-02-02 07:31 AM, Arnd Bergmann wrote:
>> Building the amd display driver with link-time optimizations revealed a bug
>
> Curious how I'd go about building with link-time optimizations.
I got the idea from last week's LWN article on th
On 2018-02-02 11:02 AM, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 4:39 PM, Harry Wentland wrote:
>> On 2018-02-02 07:31 AM, Arnd Bergmann wrote:
>>> Building the amd display driver with link-time optimizations revealed a bug
>>
>> Curious how I'd go about building with link-time optimizations.
On Mon, Jan 29, 2018 at 03:47:34PM +0100, Hans de Goede wrote:
> Add a new intel_bios_cleanup function to free memdup-ed bios data
> structures and call it from i915_driver_unload().
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> drivers/gpu/drm/i915/i915_d
_dev_ is being dereferenced before it is null checked, hence there
is a potential null pointer dereference.
Fix this by moving the pointer dereference after _dev_ has been
null checked.
Fixes: d4e7f38d70ef ("drm/msm/dsi: check msm_dsi and dsi pointers before use")
Signed-off-by: Gustavo A. R. Sil
_minor_ is being dereferenced before it is null checked, hence there
is a potential null pointer dereference. Fix this by moving the pointer
dereference after _minor_ has been null checked.
Fixes: 024ad8df763f ("drm/msm: add a5xx specific debugfs")
Signed-off-by: Gustavo A. R. Silva
---
I wonder
On Fri, 2018-02-02 at 12:44 +0200, Jani Nikula wrote:
> +Knut, Fengguang
>
> On Fri, 02 Feb 2018, Greg KH wrote:
> > - If clang now builds the kernel "cleanly", yes, I want to take
> > warning fixes in the stable tree. And even better yet, if you
> > keep working to ensure the tr
Hi Robin,
On 2/2/2018 5:01 PM, Robin Murphy wrote:
> On 02/02/18 05:40, Sricharan R wrote:
>> Hi Robin/Vivek,
>>
>> On 2/1/2018 2:23 PM, Vivek Gautam wrote:
>>> Hi,
>>>
>>>
>>> On 1/31/2018 6:39 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
> From: Sricharan R
>
>
> What is the goal of these types of emails?
>
even more so on this mailing list. It almost feels like guerilla
advertising for Clang.
> thanks,
>
> greg k-h
>
> ___
> Kernelnewbies mailing list
> kernelnewb...@kernelnewbies.org
> https://lists.
Non-x86 systems, such as OpenPOWER and ARM machines, do not execute the ASPEED-
provided option ROM on system start. As a result, the VGA palette registers
remain uninitialized, leading to odd colors and generally hard to read output
on the VGA port.
Add a new module option, ast_resetpalette, to
Non-x86, such as OpenPOWER and ARM machines, do not execute the ASPEED-provided
option ROM on system start. As a result, the VGA palette registers remain
uninitialized, leading to odd colors and generally hard to read output on the
VGA port.
Add a new module option, ast_resetpalette, to enable l
Non-x86 systems, such as OpenPOWER and ARM machines, do not execute the ASPEED-
provided option ROM on system start. As a result, the VGA palette registers
remain uninitialized, leading to odd colors and generally hard to read output
on the VGA port.
Add a new module option, ast_resetpalette, to
On Fri, 2 Feb 2018, Jani Nikula wrote:
> Being brutally honest, please write shorter reports and shorter emails
> to the lists.
>
> The static analysis reports are welcome, but only when 1) we didn't
> already fix it in linux-next, or 2) it reveals an actual bug, not just a
> warning, warranting
On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
>
>
Hi,
I did not look into details, but on amd-staging-drm-next
(495e9e174feaec6e5aeb6f8224f0d3bda4c96114), linking the amdgpu module fails if
DEBUG_FS is not enabled (probably some weird things happen in the code with
the CONFIG_DEBUG_FS macro).
Saw passing something about an amd-gfx mailing list.
On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote:
> _minor_ is being dereferenced before it is null checked, hence there
> is a potential null pointer dereference. Fix this by moving the pointer
> dereference after _minor_ has been null checked.
>
> Fixes: 024ad8df763f ("drm/msm
On 2018-02-02 05:29 PM, sylvain.bertr...@gmail.com wrote:
> Hi,
>
> I did not look into details, but on amd-staging-drm-next
> (495e9e174feaec6e5aeb6f8224f0d3bda4c96114), linking the amdgpu module fails if
> DEBUG_FS is not enabled (probably some weird things happen in the code with
> the CONFIG_D
On Fri, 02 Feb 2018, Ville Syrjälä wrote:
> On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
>> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
>> index = 3, one of which has been kindly provided to me by Jan Brummer,
>> where not working with the i915 driver, giv
On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse wrote:
> On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote:
>> _minor_ is being dereferenced before it is null checked, hence there
>> is a potential null pointer dereference. Fix this by moving the pointer
>> dereference after _mino
The subsystem chould check that, not the driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..42e3ee81a96e 100644
--- a/d
To aid debugging set the page mapping during allocation instead of
during VM faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 -
drivers/gpu/drm/ttm/ttm_tt.c| 18 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
The subsystem chould check that, not the driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..648c449aaa79 10
This allows access to pages allocated through the driver with optional
IOMMU mapping.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 -
1 file changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdg
Stop calling the driver callback directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 10 +-
include/drm/ttm/ttm_bo_driver.h | 9 +
4 files changed, 24 i
On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> 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 s
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> 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 la
https://bugs.freedesktop.org/show_bug.cgi?id=104919
Bug ID: 104919
Summary: R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert
"drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM
PD/PTs" v2
Product: DRI
Ver
https://bugs.freedesktop.org/show_bug.cgi?id=104919
--- Comment #1 from Andy Furniss ---
Created attachment 137138
--> https://bugs.freedesktop.org/attachment.cgi?id=137138&action=edit
error logging from corruption/locks
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=104919
--- Comment #2 from Christian König ---
At least I now knew that the PASID handling is working fine.
Does it work if you disable the new clear method? E.g. just add a "return 0;"
to the beginning of amdgpu_vm_clear_bo().
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=104920
Bug ID: 104920
Summary: Broken hardware video encoding with vaapi/ffmpeg
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: nor
https://bugs.freedesktop.org/show_bug.cgi?id=104920
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/AMDgpu
Aww, you are right. Let me redo it and do the spelling fix separately
because I cannot unsee it now.
On Fri, Feb 2, 2018 at 7:48 AM, Harry Wentland wrote:
> On 2018-02-01 08:55 PM, db...@chromium.org wrote:
>> From: Dominik Behr
>>
>> v2: now with fixed result comparison and spelling fixes
>>
>>
From: Dominik Behr
Replace SUCESSFULL with SUCCESSFUL.
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 | 4 ++--
d
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..a83f7b
https://bugs.freedesktop.org/show_bug.cgi?id=104919
--- Comment #3 from Andy Furniss ---
(In reply to Christian König from comment #2)
> At least I now knew that the PASID handling is working fine.
>
> Does it work if you disable the new clear method? E.g. just add a "return
> 0;" to the beginni
Quoting Andy Lutomirski (2018-02-02 19:23:33)
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> >> Anyway, this is all on a 4.14 kernel. I should update to 4.16 and see
> >> what happens.
> >
> > I updated to 4.15, and the situa
On 2018-02-02 04:37 PM, db...@chromium.org wrote:
> From: Dominik Behr
>
> Replace SUCESSFULL with SUCCESSFUL.
>
> Signed-off-by: Dominik Behr
Series is
Reviewed-by: Harry Wentland
Will pull it into amd-stg over the weekend or on Monday.
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm
Hi Archit, Andrzej, Laurent & Brian,
What is your opinion regarding this patch? Do you have any advice for
handling hw versions?
Do not hesitate to comment.
Many thanks,
Philippe :-)
On 01/22/2018 04:08 PM, Philippe Cornu wrote:
> From: Philippe CORNU
>
> Add support for the Synopsys Design
Hi Laurent & Daniel :-)
On 01/29/2018 11:40 AM, Laurent Pinchart wrote:
> Hi Philippe,
>
> On Monday, 29 January 2018 12:17:37 EET Philippe CORNU wrote:
>> On 01/29/2018 10:46 AM, Laurent Pinchart wrote:
>>> On Thursday, 25 January 2018 17:55:04 EET Philippe Cornu wrote:
>>>
The "adjusted_mo
https://bugs.freedesktop.org/show_bug.cgi?id=104920
--- Comment #1 from Andy Furniss ---
You need -profile:v 578.
x11grab on my old CPU at least is not the best way to go.
ffmpeg is slow doing the BGR0 -> nv12 conversion, and by default it will be 601
rather than 709.
There are ways around that,
Linus Walleij writes:
> With a bit of refactoring we can contain the variant data for
> the strange PL110 versions that is feature-incomplete PL110 for
> the ARM Integrator/CP and somewhere inbetween PL110 and PL111
> for the ARM Versatile AB and Versatile PB.
>
> We also accomodate for the custo
Hi Mathieu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15 next-20180202]
[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
I haven't tried the patch but just like to point out this breaks umr :-) I'll
have to craft something on Monday to support this and iova in parallel until
the iova kernels are realistically EOL'ed.
On the other hand I support this idea since it eliminates the need for an fmem
hack. So much ap
https://bugs.freedesktop.org/show_bug.cgi?id=104888
--- Comment #5 from Robin Kauffman ---
(In reply to Harry Wentland from comment #3)
> Curiously enough this is the first time I've heard of setterm. I'm not sure
> if it's really supported but I tried amdgpu, non-amdgpu (i.e. vbios), and an
> In
https://bugs.freedesktop.org/show_bug.cgi?id=104888
Robin Kauffman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTABUG
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64, store all the bits
without truncating. There is no need to type cast this value down to
32-bits.
Cc: Keith Packard
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pan
From: "Pandiyan, Dhinakaran"
drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requeste
From: "Pandiyan, Dhinakaran"
The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 states if PSR was
active. The frame counter could also have stalled if PSR was active in case
there was no DMC. The frame counter resetting h
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes
Core returns a u64 vblank count and intel_crtc_get_vblank_counter()
expects a 32-bit value. Make the typecast explicit to add clarity.
Cc: Keith Packard
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
From: "Pandiyan, Dhinakaran"
Updating vblank counts requires register reads and these reads may not
return meaningful values if the device was in a low power state after
vblank interrupts were last disabled. So, update the count only if vblank
interrupts are enabled. Secondly, this means the regi
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this
down to u32 either fixes
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64.
The flip ioctl receives a 32-bit target sequence from user space and is
compared against the current sequence from drm_crtc_vblank_count(). So,
typecast return from drm_crtc_vblank_
From: "Pandiyan, Dhinakaran"
The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negat
On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> > 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
94 matches
Mail list logo
