[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
[How]
Remove the exception
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/drm_edid.c | 3 ---
1
[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
Current code doesn't take
https://bugs.freedesktop.org/show_bug.cgi?id=111796
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=112086
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110600
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111637
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111630
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111638
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111651
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111329
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110754
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110619
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111011
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110580
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110598
Bug 110598 depends on bug 110597, which changed state.
Bug 110597 Summary: [IGT runner] allow attachments to results.json
https://bugs.freedesktop.org/show_bug.cgi?id=110597
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=110598
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110597
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110320
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110599
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109941
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110313
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109607
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110521
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109719
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110249
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108891
Martin Peres changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102670
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107310
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108044
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=99426
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Nov 11, 2019 at 04:06:46PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*()
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #22 from Haxk20 (haxk...@gmail.com) ---
(In reply to Michel Dänzer from comment #21)
> (In reply to Haxk20 from comment #20)
> > Not only that but it started happening in video too on firefox and that is
> > really horrible.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=205497
Bug ID: 205497
Summary: Attempt to read amd gpu id causes a freeze
Product: Drivers
Version: 2.5
Kernel Version: 5.3.9
Hardware: All
OS: Linux
Tree: Mainline
On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
[]
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
>
Not sure if this was suggested before -- I couldn't find any relevant
threads from a google search:
One solution to the problem of applications submitting a frame scheduled a
long ways into the future then immediately after that getting user input
and wanting to present a new frame right away is
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
https://bugzilla.kernel.org/show_bug.cgi?id=204609
--- Comment #3 from Guido Winkelmann (guido-kern-b...@unknownsite.de) ---
Created attachment 285867
--> https://bugzilla.kernel.org/attachment.cgi?id=285867=edit
dmesg output from another system
--
You are receiving this mail because:
You are
Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
have been converted to pin_longterm_pages(), lock it down:
1) Add an assertion to get_user_pages(), preventing callers from
passing FOLL_LONGTERM (in addition to the existing assertion that
prevents FOLL_PIN).
2) Remove the
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
https://bugzilla.kernel.org/show_bug.cgi?id=204609
Guido Winkelmann (guido-kern-b...@unknownsite.de) changed:
What|Removed |Added
CC|
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages().
Note that this effectively changes the
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Hi,
The cover letter is long, so the more important stuff is first:
* Jason, if you or someone could look at the the VFIO cleanup (patch 8)
and conversion to FOLL_PIN (patch 18), to make sure it's use of
remote and longterm gup matches what we discussed during the review
of v2, I'd
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented.
The pin_longterm*() variants also set FOLL_LONGTERM, in addition
to FOLL_PIN:
pin_user_pages()
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Ira Weiny
Cc: Jason Gunthorpe
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 17
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Signed-off-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=112234
Matt Coffin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 2:44 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 11/11/19 11:46, Mikita Lipski wrote:
> >
> > Thanks for catching it!
> >
>
> Glad to help out. :)
>
> > Reviewed-by: Mikita Lipski
> >
>
> Thanks
> --
> Gustavo
>
> >
> > On 11.11.2019 12:25, Gustavo
On 11/10/19 2:10 AM, Hans Verkuil wrote:
> On 11/3/19 10:17 PM, John Hubbard wrote:
>> After DMA is complete, and the device and CPU caches are synchronized,
>> it's still required to mark the CPU pages as dirty, if the data was
>> coming from the device. However, this driver was just issuing a
>>
https://bugzilla.kernel.org/show_bug.cgi?id=205491
--- Comment #1 from Łukasz Żarnowiecki (luk...@zarnowiecki.pl) ---
Created attachment 285865
--> https://bugzilla.kernel.org/attachment.cgi?id=285865=edit
lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205491
Bug ID: 205491
Summary: Green external display after wake up
Product: Drivers
Version: 2.5
Kernel Version: 5.3.10
Hardware: All
OS: Linux
Tree: Mainline
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #18 from Daniel Suarez ---
(In reply to Jaap Buurman from comment #17)
> (In reply to takios+fdbugs from comment #16)
> > I ran into the same issue but after installing linux kernel 5.4rc2 it was
> > fixed.
>
> That's good to hear!
On Mon, Nov 11, 2019 at 1:01 PM Alex Deucher wrote:
>
> Applied. Thanks!
I've dropped this as it leads to a warning in the code since
get_color_depth is no longer used. Care to fix that up as well?
Thanks!
Alex
>
> Alex
>
> On Sun, Nov 10, 2019 at 9:30 PM YueHaibing wrote:
> >
> > Fixes
https://bugzilla.kernel.org/show_bug.cgi?id=205185
--- Comment #2 from Stijn Tintel (stijn+b...@linux-ipv6.be) ---
Thanks. Enabling that symbol fixes the compile failure. This wasn't a problem
in 5.3.0 - 5.3.4, so there's a regression introduced in 5.3.5, which should
still be fixed. Probably
On 11/11/19 11:46, Mikita Lipski wrote:
>
> Thanks for catching it!
>
Glad to help out. :)
> Reviewed-by: Mikita Lipski
>
Thanks
--
Gustavo
>
> On 11.11.2019 12:25, Gustavo A. R. Silva wrote:
>> Currenly, the error check below on variable*vcpi_slots* is always
>> false because it is a
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" was apparently a typo.
That mask included the high order bit of Transmit Margin, the
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
I don't intend the Target Link Speed patch to change anything, so it should
be straightforward to review.
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly unconventional ioremap()
behavior, everywhere else this is the same as ioremap() anyway.
Change the only driver that still references ioremap_uc() to only do so
on x86-32/ia64 in order to
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #9 from Marek Olšák ---
Userspace doesn't know when suspend/resume is happening, so it can't hang on
suspend/resume. My guess is it's something in DAL.
--
You are receiving this mail because:
You are the assignee for the
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 607b18ba116eb1642b01fb9d38a164cc492e9044 [2158/2834] drm/amdkcl: Test
whether vm_fault->{address/vma} is available
config: x86_64-randconfig-a004-201944 (attached
Applied. Thanks!
Alex
On Sun, Nov 10, 2019 at 9:30 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> get_pbn_from_timing:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11:
Applied. thanks!
Alex
On Sun, Nov 10, 2019 at 9:29 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
> dp_wa_power_up_0010FA:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2320:35:
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 3:07 AM zhengbin wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c: In function
> fiji_populate_single_graphic_level:
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c:943:11:
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 9:11 AM zhengbin wrote:
>
> Move the static keyword to the front of declarations.
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Applied. Thanks!
Alex
On Sun, Nov 10, 2019 at 11:04 PM Quan, Evan wrote:
>
> Series is reviewed-by: Evan Quan
>
> > -Original Message-
> > From: zhengbin
> > Sent: Monday, November 11, 2019 11:46 AM
> > To: rex@amd.com; Quan, Evan ; Deucher,
> > Alexander ; Koenig, Christian
> >
Currenly, the error check below on variable *vcpi_slots* is always
false because it is a uint64_t type variable, hence, the values
this variable can hold are never less than zero:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
4870 if (dm_new_connector_state->vcpi_slots < 0) {
4871
Thanks for catching it!
Reviewed-by: Mikita Lipski
On 11.11.2019 12:25, Gustavo A. R. Silva wrote:
Currenly, the error check below on variable*vcpi_slots* is always
false because it is a uint64_t type variable, hence, the values
this variable can hold are never less than zero:
https://bugzilla.kernel.org/show_bug.cgi?id=205185
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #8 from Alex Deucher ---
(In reply to Pierre Ossman from comment #7)
> I finally got a build environment set up, and the winner is:
>
> > df8368be1382b442384507a5147c89978cd60702 is the first bad commit
> > commit
On 11/11/19 9:57 AM, Thomas Zimmermann wrote:
Hi John
Am 08.11.19 um 19:07 schrieb John Donnelly:
On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
Hi
Am 08.11.19 um 13:55 schrieb John Donnelly:
On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote:
Hi John
Am 07.11.19 um 23:14
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 8:38 AM Kazlauskas, Nicholas
wrote:
>
> On 2019-11-09 10:49 a.m., Colin King wrote:
> > From: Colin Ian King
> >
> > There is comparison expression that is duplicated and hence one
> > of the expressions can be removed. Remove it.
> >
> >
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 8:37 AM Kazlauskas, Nicholas
wrote:
>
> On 2019-11-09 2:49 p.m., Colin King wrote:
> > From: Colin Ian King
> >
> > There are spelling mistakes in a DC_ERROR message and a comment.
> > Fix these.
> >
> > Signed-off-by: Colin Ian King
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=205185
Stijn Tintel (stijn+b...@linux-ipv6.be) changed:
What|Removed |Added
Kernel Version|5.3.5 - 5.3.6 |5.3.5 - 5.3.10
Hi,
On 11-11-2019 13:53, Maxime Ripard wrote:
Hi Hans,
Thanks for this series (and thanks for bouncing the mails too).
All the previous patches are
Acked-by: Maxime Ripard
Thank you for the review.
On Sun, Nov 10, 2019 at 04:40:58PM +0100, Hans de Goede wrote:
Sometimes we want to
Hi,
On 11-11-2019 16:40, Daniel Vetter wrote:
On Mon, Nov 11, 2019 at 12:06 PM Hans de Goede wrote:
Hi Daniel,
On 11-11-2019 11:26, Daniel Vetter wrote:
On Mon, Nov 11, 2019 at 10:50 AM Hans de Goede wrote:
Hi,
On 11-11-2019 10:25, Daniel Vetter wrote:
On Sun, Nov 10, 2019 at 7:41 PM
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 57d7e98d0257bd9795dd3f438d19aa5476554685 [2114/2834] drm/amdkcl: Test
whether drm_{mm_print/debug_printer} is available
config: x86_64-randconfig-a004-201944
Most kernel interfaces that take a timespec require normalized
representation with tv_nsec between 0 and NSEC_PER_SEC.
Passing values larger than 0x1ull further behaves differently
on 32-bit and 64-bit kernels, and can cause the latter to spend a long
time counting seconds in
struct timespec is being removed from the kernel because it often leads
to code that is not y2038-safe.
In the etnaviv driver, monotonic timestamps are used, which do not suffer
from overflow, but the usage of timespec here gets in the way of removing
the interface completely.
Pass down the
On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach wrote:
> >
> > > If that's the case then we should never encounter a genuine 0 timeout
> > > and this change would be okay.
> >
> > That's quite likely, I'd say any program passing {0,0} as a timeout without
> > ETNA_WAIT_NONBLOCK is already broken,
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 769e4dc19ad658720b779070764db2fc10a0bbac [2104/2834] drm/amdkcl: Test
whether drm_mm_insert_mode is available
config: x86_64-randconfig-a004-201944 (attached as
Hi John
Am 08.11.19 um 19:07 schrieb John Donnelly:
>
>
>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 08.11.19 um 13:55 schrieb John Donnelly:
>>>
>>>
On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote:
Hi John
Am 07.11.19 um 23:14 schrieb
On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> It's possible to get multiple events in a single frame/flip, so add an
> option to print them all.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
> Signed-off-by: Mihail Atanassov
For the whole series:
Acked-by:
On Thu, Nov 07, 2019 at 11:42:28AM +, Mihail Atanassov wrote:
> Named 'err_verbosity', currently with only 1 active bit in that
> replicates the existing level - print error events once per flip.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
> Signed-off-by: Mihail Atanassov
On Mon, Nov 11, 2019 at 2:11 PM Steven Price wrote:
>
> On 04/11/2019 17:37, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> > really no business
1 - 100 of 158 matches
Mail list logo
