Hi Suraj,
On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> Hi Abhinav,
>
> > Based on the discussion in this thread [1] , it seems like having
> > drm_encoder
> > as a pointer seems to have merits for both of us and also in agreement with
> > the folks on this thread and has a b
Hi Rob,
On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > >> > On
Hi Dmitry,
On Mon, Feb 28, 2022 at 11:07:41AM +0300, Dmitry Baryshkov wrote:
> On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> > > Hi Abhinav,
> > >
> > > > Based on the discussion in this thread [1] , it seems like having
Psr_debug has already similar functionality you are introducing here.
Values we used there are different. Maybe we should consider dropping
that setting? Still for this patch:
Reviewed-by: Jouni Högander
On Thu, 2022-02-24 at 12:25 -0800, José Roberto de Souza wrote:
> Some users are suffering w
Hi,
On 25/02/2022 23:03, Sebastian Andrzej Siewior wrote:
On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote:
There are a few sections in the driver which are not compatible with
PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
Disable the i915 dr
On 25/02/2022 17:58, Ville Syrjälä wrote:
On Fri, Feb 25, 2022 at 05:41:17PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Use lockdep_assert_not_held to simplify and correct the code. Otherwise
false positive are hit if lock state is uknown like after a previous
taint.
Signed-off-by: T
Hi Vivek,
On 27/02/2022 17:29, Vivek Kasireddy wrote:
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in
On 2022-02-28 10:10:48 [+], Tvrtko Ursulin wrote:
> Hi,
Hi,
> Could you paste a link to the queue of i915 patches pending for a quick
> overview of how much work there is and in what areas?
Last post to the list:
https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-big
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later
On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> If the list does not contain the expected element, the value of
> list_for_each_entry() iterator will not point to a valid structure.
> To avoid type confusion in such case, the list iterator
> scope will be limited to list_for_each_e
On Mon, Feb 28, 2022 at 12:08:17PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index 9040a0561466..0fd0307bc07b 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -150,13 +150,14 @
On Mon, Feb 28, 2022 at 12:08:19PM +0100, Jakob Koschel wrote:
> The list iterator value will *always* be set by list_for_each_entry().
> It is incorrect to assume that the iterator value will be NULL if the
> list is empty.
>
> Instead of checking the pointer it should be checked if
> the list is
Mark actually has a tree that switches to gnu99 with a lot of the
issues already sortd out and keeping sane default for things like the
absolutely horrible declarations in the middle of code here:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=697e436ae0
On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> Hi Rob,
>
> On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
>> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
>> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
>> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
>> > >> O
Hi Jani,
On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > > On
If we need to make room for some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hope
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable pla
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will re
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
v3:
- For testing purposes allow forcing the io_size such that we can
exercise the allocation + migrati
On Mon, 28 Feb 2022, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
>
> Link:
> https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds
> Cc:
On Mon, Feb 28, 2022 at 12:08:22PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/infiniband/hw/hfi1/tid_rdma.c
> b/drivers/infiniband/hw/hfi1/tid_rdma.c
> index 2a7abf7a1f7f..a069847b56aa 100644
> --- a/drivers/infiniband/hw/hfi1/tid_rdma.c
> +++ b/drivers/infiniband/hw/hfi1/tid_rdma.c
> @@ -
On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/scsi/scsi_transport_sas.c
> b/drivers/scsi/scsi_transport_sas.c
> index 4ee578b181da..a8cbd90db9d2 100644
> --- a/drivers/scsi/scsi_transport_sas.c
> +++ b/drivers/scsi/scsi_transport_sas.c
> @@ -1060,26 +1060,29
On Mon, Feb 28, 2022 at 01:03:36PM +0100, Jakob Koschel wrote:
> >> @@ -954,7 +957,6 @@ net2272_dequeue(struct usb_ep *_ep, struct usb_request
> >> *_req)
> >>dev_dbg(ep->dev->dev, "unlink (%s) pio\n", _ep->name);
> >>net2272_done(ep, req, -ECONNRESET);
> >>}
> >> - re
On Mon, Feb 28, 2022 at 02:01:06PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula
> wrote:
> > >
> > > One minor issue that remains is an added gcc warning for shifts of
> > > negative integers when building with -Werror, which happens with the
> > > 'make W=1' option,
Hello,
On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> > On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> > >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikul
== Series Details ==
Series: Fix prime_mmap to work when using LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/100737/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, 2022-02-22 at 17:14 +, Patchwork wrote:
> Patch Details
> Series:drm/i915: Clarify vma lifetime
> (rev2)URL:https://patchwork.freedesktop.org/series/99948/State:failur
> e
> Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22350/index.html
> CI Bug Log - changes from CI_DRM_11
On Mon, Feb 28, 2022 at 12:25 PM Mark Rutland wrote:
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> >
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > workaround.
>
> FWIW, I ha
On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
wrote:
>
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11 in
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will *always* be a bogus
pointer computed based on the head element.
To avoid type confusion use the actual list head directly instead of last
iterator value.
Signed-off-by: Jakob
On 2/27/22 3:52 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other
On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart
wrote:
>
> Hi Suraj,
>
> On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> > Hi Abhinav,
> >
> > > Based on the discussion in this thread [1] , it seems like having
> > > drm_encoder
> > > as a pointer seems to have merits for both of
On Mon, Feb 28, 2022 at 6:32 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standard
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element, either with list_entry_is_
Hi Arnd,
This is great!
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. Whi
On Mon, Feb 28, 2022 at 12:04 AM Alex Elder wrote:
> On 2/27/22 3:52 PM, Arnd Bergmann wrote: From: Arnd Bergmann
> > I put the suggestion into patch form, based on what we discussed
> > in the thread. I only gave it minimal testing, but it would
> > be good to have it in linux-next if we want
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
If the list representing the request queue does not contain the expected
request, the value of list_for_each_entry() iterator will not point to a
valid structure. To avoid type confusion in such case, the list iterator
scope will be limited to list_for_each_entry() loop.
In preparation to limiting
The list iterator value will *always* be set by list_for_each_entry().
It is incorrect to assume that the iterator value will be NULL if the
list is empty.
Instead of checking the pointer it should be checked if
the list is empty.
In acpi_get_pmu_hw_inf() instead of setting the pointer to NULL
on
This is a bit more work (and a lot more noise), but I'd prefer if
this were split into as many patches as there are components.
I'm not going to review the parts of the patches that don't concern me,
and if something turns out to be a problem later one (it shouldn't but
one never knows) it'll be m
On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula wrote:
> >
> > One minor issue that remains is an added gcc warning for shifts of
> > negative integers when building with -Werror, which happens with the
> > 'make W=1' option, as well as for three drivers in the kernel that always
> > enable -Werror, b
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already availa
If the list does not contain the expected element, the value of
list_for_each_entry() iterator will not point to a valid structure.
To avoid type confusion in such case, the list iterator
scope will be limited to list_for_each_entry() loop.
In preparation to limiting scope of a list iterator to th
> On 28. Feb 2022, at 12:24, Dan Carpenter wrote:
>
> On Mon, Feb 28, 2022 at 12:08:17PM +0100, Jakob Koschel wrote:
>> diff --git a/drivers/usb/gadget/udc/at91_udc.c
>> b/drivers/usb/gadget/udc/at91_udc.c
>> index 9040a0561466..0fd0307bc07b 100644
>> --- a/drivers/usb/gadget/udc/at91_udc.c
>
The list iterator variable will be a bogus pointer if no break was hit.
Dereferencing it could load *any* out-of-bounds/undefined value
making it unsafe to use that in the comparision to determine if the
specific element was found.
This is fixed by using a separate list iterator variable for the l
> On 28. Feb 2022, at 12:20, Greg KH wrote:
>
> On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
>> If the list does not contain the expected element, the value of
>> list_for_each_entry() iterator will not point to a valid structure.
>> To avoid type confusion in such case, the
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already availa
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote:
>
> On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu99, which allows using variable
> >
This is the first patch removing several categories of use cases of
the list iterator variable past the loop.
This is follow up to the discussion in:
https://lore.kernel.org/all/20220217184829.1991035-1-jakobkosc...@gmail.com/
As concluded in:
https://lore.kernel.org/all/yhdfeiwi4edth...@kroah.com
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote:
> On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote:
>
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > workaround.
>
> On the topic of Wdeclara
On 2/27/22 5:11 PM, Linus Torvalds wrote:
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote:
Glancing at the Greybus code, I don't believe there's any
reason it needs to shift a negative value. Such warnings
could be fixed by making certain variables unsigned, for
example.
As mentioned in th
On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later
== Series Details ==
Series: Fix prime_mmap to work when using LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/100737/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11297 -> Patchwork_22432
Summary
---
**S
Reviewed-by: Nirmoy Das
On 25/02/2022 14:13, Gwan-gyeong Mun wrote:
The dma_buf_ops.unmap_dma_buf callback used in i915,
i915_gem_unmap_dma_buf(), has the same code as drm_gem_unmap_dma_buf().
In order to eliminate defining and using duplicate function, it updates
the dma_buf_ops.unmap_dma_buf
On 25/02/2022 19:03, John Harrison wrote:
On 2/25/2022 10:29, Tvrtko Ursulin wrote:
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wro
This is just to try to repro the execlist selftest failure I'm seeing on
my local DG1 with GuC submission disabled.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/
On 25/02/2022 17:39, John Harrison wrote:
On 2/25/2022 09:06, Tvrtko Ursulin wrote:
On 24/02/2022 19:19, John Harrison wrote:
[snip]
./gt/uc/intel_guc_fwif.h: u32 execution_quantum;
./gt/uc/intel_guc_submission.c: desc->execution_quantum =
engine->props.timeslice_duration_ms * 1000;
./
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register said lists
of global, engi
On 25/02/2022 18:48, John Harrison wrote:
On 2/25/2022 10:14, Tvrtko Ursulin wrote:
I'll try to simplify the discussion here:
On 24/02/2022 19:45, John Harrison wrote:
On 2/24/2022 03:41, Tvrtko Ursulin wrote:
On 23/02/2022 20:00, John Harrison wrote:
On 2/23/2022 05:58, Tvrtko Ursulin w
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register said lists
of global, engi
The Xe_HP architecture introduces compute engines as a new engine class.
These compute command streamers (CCS) are similar to the render engine,
except that they're intended for GPGPU usage and lack support for the 3D
pipeline.
For now we're just sending some initial "under the hood" preparation f
Add execlists and GuC interrupts for compute CS into existing IRQ handlers.
All compute command streamers belong to the same compute class, so the
only change needed to enable their interrupts is to program their GT engine
interrupt mask registers.
CCS0 shares the register with CCS1, while CCS2 a
The compute engine handles the same commands the render engine can
(except 3D pipeline), so it makes sense that CCS is more similar to RCS
than non-render engines.
The CCS context state (lrc) is also similar to the render one, so reuse
it. Note that the compute engine has its own CTX_R_PWR_CLK_STA
Introduce a Compute Command Streamer (CCS), which has access to
the media and GPGPU pipelines (but not the 3D pipeline).
To begin with, define the compute class/engine common functions, based
on the existing render ones.
v2:
- Add kerneldoc for drm_i915_gem_engine_class since we're adding a new
The reset domain is shared between render and all compute engines,
so resetting one will affect the others.
Note: Before performing a reset on an RCS or CCS engine, the GuC will
attempt to preempt-to-idle the other non-hung RCS/CCS engines to avoid
impacting other clients (since some shared modul
This is a more appropriate header for these definitions.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 34 ---
drivers/gpu/drm/i915/gt/intel_lrc.h | 34 +++
3 files changed
In Dual Context mode the EUs are shared between render and compute
command streamers. The hardware provides a field in the lrc descriptor
to indicate the prioritization of the thread dispatch associated to the
corresponding context.
The context priority is set to 'low' at creation time and relies
Additional workarounds are required once we start exposing CCS engines.
Note that we have a number of workarounds that update registers in the
shared render/compute reset domain. Historically we've just added such
registers to the RCS engine's workaround list. But going forward we
should be more
From: Daniele Ceraolo Spurio
CCS will reuse the RCS functions for breadcrumb and flush emission.
However, CCS pipe_control has additional programming restrictions:
- Command Streamer Stall Enable must be always set
- Post Sync Operations must not be set to Write PS Depth Count
- 3D-related bit
From: Matthew Brost
A different emit breadcrumbs ring programming is required for compute /
render and we don't have UMD user so just reject parallel submission for
these engine classes.
Signed-off-by: Matthew Brost
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c
From: Srinivasan Shanmugam
Registers that exist in the shared render/compute reset domain need to
be placed on an engine workaround list to ensure that they are properly
re-applied whenever an RCS or CCS engine is reset. We have a number of
workarounds (updating registers MLTICTXCTL, L3SQCREG1_C
We have to specify in the Render Control Unit Mode register
when CCS is enabled.
v2:
- Move RCU_MODE programming to a helper function. (Tvrtko)
- Clean up and clarify comments. (Tvrtko)
- Add RCU_MODE to the GuC save/restore list. (Daniele)
Bspec: 46034
Original-author: Michel Thierry
Cc: D
From: Daniele Ceraolo Spurio
HW resources are divided across the active CCS engines at the compute
slice level, with each CCS having priority on one of the cslices.
If a compute slice has no enabled DSS, its paired compute engine is not
usable in full parallel execution because the other ones alr
From: Daniele Ceraolo Spurio
Tell GuC that CCS is enabled by setting a bit in its ADS.
Cc: Vinay Belgaumkar
Original-author: Michel Thierry
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 +++
drivers/gpu/drm/i915/gt/uc/intel
== Series Details ==
Series: Fix prime_mmap to work when using LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/100737/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11297_full -> Patchwork_22432_full
Summary
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
On 2/28/2022 08:11, Tvrtko Ursulin wrote:
On 25/02/2022 17:39, John Harrison wrote:
On 2/25/2022 09:06, Tvrtko Ursulin wrote:
On 24/02/2022 19:19, John Harrison wrote:
[snip]
./gt/uc/intel_guc_fwif.h: u32 execution_quantum;
./gt/uc/intel_guc_submission.c: desc->execution_quantum =
engine-
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change
I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user b
On 2/28/2022 09:12, Tvrtko Ursulin wrote:
On 25/02/2022 18:48, John Harrison wrote:
On 2/25/2022 10:14, Tvrtko Ursulin wrote:
I'll try to simplify the discussion here:
On 24/02/2022 19:45, John Harrison wrote:
On 2/24/2022 03:41, Tvrtko Ursulin wrote:
On 23/02/2022 20:00, John Harrison wrot
Hi Tvrtko,
>
> Hi Vivek,
>
> On 27/02/2022 17:29, Vivek Kasireddy wrote:
> > This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
> > functions to identify suitable holes for an allocation of a given
> > size by efficiently traversing the rbtree associated with the given
> > alloca
On 2/28/2022 07:32, Tvrtko Ursulin wrote:
On 25/02/2022 19:03, John Harrison wrote:
On 2/25/2022 10:29, Tvrtko Ursulin wrote:
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby
The first patch is a drm core patch that replaces the for loop in
drm_mm_insert_node_in_range() with the iterator and would not
cause any functional changes. The second patch is a i915 driver
specific patch that also uses the iterator but solves a different
problem.
v2:
- Added a new patch to this
On 2/24/2022 20:43, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* Prep work for next GuC release (rev3)
*URL:* https://patchwork.freedesktop.org/series/99805/
*State:*success
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22404/index.html
On 17.02.2022 15:41, Andi Shyti wrote:
> With the upcoming multitile support each tile will have its own
> local memory. Mark the current LMEM with the suffix '0' to
> emphasise that it belongs to the root tile.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/g
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
>
> I don't think that using the extra variable makes the code in any way
> more reliable or easier to read.
So I think the next step is to do the attached patch (which requires
that "-std=gnu11" that was discussed in the original thread).
T
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware
URL : https://patchwork.freedesktop.org/series/100818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11299 -> Patchwork_22433
=
On 17.02.2022 15:41, Andi Shyti wrote:
> The "gt_is_root(struct intel_gt *gt)" helper return true if the
> gt is the root gt, which means that its id is 0. Return false
> otherwise.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_gt.h | 5
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds
wrote:
>
> I do wish we could actually poison the 'pos' value after the loop
> somehow - but clearly the "might be uninitialized" I was hoping for
> isn't the way to do it.
Side note: we do need *some* way to do it.
Because if we make that change,
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
wrote:
>
> Side note: we do need *some* way to do it.
Ooh.
This patch is a work of art.
And I mean that in the worst possible way.
We can do
typeof(pos) pos
in the 'for ()' loop, and never use __iter at all.
That means that inside the
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted
DPCD register values when reading from the 0xF- LTTPR range with an
AUX transaction block size bigger than 1. The DP standard requires 0 to
be returned - as for any other reserved/invalid addresses - but these
monitors retu
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds
wrote:
>
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
The thing that makes me throw up in my mouth a bit is that in t
On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
Then we can never use -Wshadow ;-( I'd love to be abl
On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote:
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'p
On 17.02.2022 15:41, Andi Shyti wrote:
> From: Sujaritha Sundaresan
>
> This patch adds the following new sysfs frequency attributes;
> - punit_req_freq_mhz
> - throttle_reason_status
> - throttle_reason_pl1
> - throttle_reason_pl2
> - throttle_reason_pl4
>
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
>
> Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> it catches real bugs.
Oh, we already can never use -Wshadow regardless of things like this.
That bridge hasn't just been burned, it never existed in the first
place.
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg
wrote:
>
> If we're willing to change the API for the macro, we could do
>
> list_for_each_entry(type, pos, head, member)
>
> and then actually take advantage of -Wshadow?
See my reply to Willy. There is no way -Wshadow will ever happen.
I conside
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > wrote:
> > > I don't think that using the extra variable makes the code in any
> > > way
> > > more reliable or easier to read.
> > So I
1 - 100 of 147 matches
Mail list logo
