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
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"
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
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
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"
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=104888
Robin Kauffman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTABUG
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
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
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
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
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,
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
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
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
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
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
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
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
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=104920
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/AMDgpu
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=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=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
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
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
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
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
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/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
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
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 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, 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
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 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.
>
>
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
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
_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
_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
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
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
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 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 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 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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=104902
Michel Dänzer changed:
What|Removed |Added
CC||rtf...@gmail.com
--- Comment #2 from Mi
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
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/
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
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
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 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:
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
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 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
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 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
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 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
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 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
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
+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
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
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
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
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 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
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
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;
}
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:
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
https://bugs.freedesktop.org/show_bug.cgi?id=104902
João Henrique changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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
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
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
94 matches
Mail list logo
