On 2/26/2020 8:03 PM, Rob Herring wrote:
On Wed, Feb 26, 2020 at 5:17 AM Sharat Masetty wrote:
On 2/21/2020 2:05 AM, Rob Herring wrote:
On Thu, 20 Feb 2020 13:42:22 +0530, Sharat Masetty wrote:
This patch adds a clock definition needed for powering on the GPU TBUs
and the GPU TCU.
Signed-o
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too
Hi Dave,
Just three fixups - fix a kernel oops and regulator warning
at booting time, and correct to print out an error message.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit f091bf39700dd086ab244c823f389556fed0c513:
Merge tag
On Sun, Mar 1, 2020 at 2:49 PM Nicolas Dufresne wrote:
>
> Hi Jason,
>
> I personally think the suggestion are still a relatively good
> brainstorm data for those implicated. Of course, those not implicated
> in the CI scripting itself, I'd say just keep in mind that nothing is
> black and white a
On Thu, Feb 27, 2020 at 9:21 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > So I'd like to push patches 1+2 to -fixes and sort everything else later
> > > in -next. OK?
> >
> > OK with me.
>
> Done.
>
> >> [ context: why shmem helpers use pgprot_writecombine + pgprot_decrypted?
> >>we get
On Sun, 01 Mar 2020 22:22:25 +
Chris Wilson wrote:
> > I'm curious to why we need it to be anonymous. Why not allow them to be
> > visible from the tracing directory. This could allow for easier
> > debugging. Note, the trace instances have ref counters thus they can't
> > be removed if somet
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/virtio/virtgpu_object.c
between commit:
6be7e0733548 ("drm/virtio: fix mmap page attributes")
from the drm-misc-fixes tree and commit:
18b39fb975b7 ("drm/virtio: add virtio_gpu_is_shmem helper")
from th
syzbot writes:
#syz fix: kasan: fix crashes on access to memory mapped by vm_map_ram()
> This bug is marked as fixed by commit:
> kasan: support vmalloc backing of vm_map_ram()
> But I can't find it in any tested tree for more than 90 days.
> Is it a correct commit? Please update it by replying:
Quoting Steven Rostedt (2020-03-01 18:18:16)
> On Sun, 1 Mar 2020 15:52:47 +
> Chris Wilson wrote:
>
> > To facilitate construction of per-client event ringbuffers, in
> > particular for a per-client debug and error report log, it would be
> > extremely useful to create an anonymous file tha
[AMD Official Use Only - Internal Distribution Only]
The one suggestion I saw that definitely seemed worth looking at was adding
download caches if the larger CI systems didn't already have them.
Then again do we know that CI traffic is generating the bulk of the costs ? My
guess would have bee
I don't think we need to worry so much about the cost of CI that we need to
micro-optimize to to get the minimal number of CI runs. We especially
shouldn't if it begins to impact coffee quality, people's ability to merge
patches in a timely manner, or visibility into what went wrong when CI
fai
One idea for Marge-bot (don't know if you already do this):
Rust-lang has their bot (bors) automatically group together a few merge
requests into a single merge commit, which it then tests, then, then the
tests pass, it merges. This could help reduce CI runs to once a day (or
some other rate). If t
On Sun, 1 Mar 2020 15:52:47 +
Chris Wilson wrote:
> To facilitate construction of per-client event ringbuffers, in
> particular for a per-client debug and error report log, it would be
> extremely useful to create an anonymous file that can be handed to
> userspace so that it can see its and
Quoting Lionel Landwerlin (2020-03-01 16:27:24)
> On 01/03/2020 17:52, Chris Wilson wrote:
> > Rather than put sensitive, and often voluminous, user details into a
> > global dmesg, report the error and debug messages directly back to the
> > user via the kernel tracing mechanism.
>
>
> Sounds re
On 01/03/2020 17:52, Chris Wilson wrote:
Rather than put sensitive, and often voluminous, user details into a
global dmesg, report the error and debug messages directly back to the
user via the kernel tracing mechanism.
Sounds really nice. Don't you want the existing global tracing to be the
Rather than put sensitive, and often voluminous, user details into a
global dmesg, report the error and debug messages directly back to the
user via the kernel tracing mechanism.
Signed-off-by: Chris Wilson
Cc: Steven Rostedt (VMware)
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 104
To facilitate construction of per-client event ringbuffers, in
particular for a per-client debug and error report log, it would be
extremely useful to create an anonymous file that can be handed to
userspace so that it can see its and only its events. trace already
provides a means of encapsulating
https://bugzilla.kernel.org/show_bug.cgi?id=206725
mombelli.ma...@gmail.com changed:
What|Removed |Added
Hardware|All |x86-64
Regression|No
https://bugzilla.kernel.org/show_bug.cgi?id=206725
Bug ID: 206725
Summary: [REGRESSION] AMDGPU Severe artifact/tearing on 5700xt
Product: Drivers
Version: 2.5
Kernel Version: 5.6.0-rc1 to 5.6.0-rc3
Hardware: All
OS: Linux
On Sun, 2020-03-01 at 21:49 +0800, Hillf Danton wrote:
> On Thu, 20 Feb 2020 13:27:15 +0100 Thomas Hellstrom wrote:
> > +
> > +static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
> > + enum page_entry_size pe_size)
> > +{
> > + struct vm_area_struct *vma
On 2020-02-29 8:46 p.m., Nicolas Dufresne wrote:
> Le samedi 29 février 2020 à 19:14 +0100, Timur Kristóf a écrit :
>>
>> 1. I think we should completely disable running the CI on MRs which are
>> marked WIP. Speaking from personal experience, I usually make a lot of
>> changes to my MRs before the
Hi Maxime,
Am 24.02.20 um 10:06 schrieb Maxime Ripard:
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
>
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would be tedious to
https://bugzilla.kernel.org/show_bug.cgi?id=206393
--- Comment #11 from Bjoern Franke (b...@nord-west.org) ---
(In reply to Alex Deucher from comment #10)
> (In reply to Bjoern Franke from comment #9)
> > Issue seems to be fixed in 5.6.0-rc3, so it will be hopefully backported
> > into the 5.5 bra
23 matches
Mail list logo
