[AMD Official Use Only - Internal Distribution Only]
That looks better to me :) As more things get added, I don't know how long you
will be able to hold sw/hw cleanup separate and the name could confuse
eventually.
Thanks,
Lijo
___
dri-devel mailing
On Thu, 29 Apr 2021, Lyude Paul wrote:
> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
> today if there's no objections
Thanks for the heads-up, I think this breaks i915. See my review
comments elsewhere in the thread.
BR,
Jani.
>
> On Wed, 2021-04-28 at 19:43
On Wed, 28 Apr 2021, Nikola Cornij wrote:
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space must be used. Without
> doing that, the three DPCD values that differ will be wrong, leading to
> incorrect or limited
On 2021-04-30 1:19 a.m., Lazar, Lijo wrote:
[AMD Official Use Only - Internal Distribution Only]
sysfs cleanup is a sw cleanup to me but done inside hw fini. sw/hw
separation is not strictly followed, or name it like stage1/stage2 fini.
The thing is that it was called early_fini and
[AMD Official Use Only - Internal Distribution Only]
sysfs cleanup is a sw cleanup to me but done inside hw fini. sw/hw separation
is not strictly followed, or name it like stage1/stage2 fini.
Thanks,
Lijo
From: amd-gfx on behalf of Andrey
Grodzovsky
Sent:
Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue
doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and
another one is 4K 30Hz (pixelclock 297MHz).
The issue is gone after setting "power_dpm_force_performance_level" to
"high". Following the indication, we found
On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 01:17:27PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wrote:
> > > > On Wed, Apr 28, 2021
Hi Linus,
Looks like I missed a tegra feature request for next, but should still
be fine since it's pretty self contained. It does contain one
fixes->next merge with no merge justification so I've pushed back on
Thierry about not doing that in the future, but let it go now as
rebasing might be
On Wed, Apr 28, 2021 at 11:13 AM Andrey Grodzovsky
wrote:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group is removed.
>
> v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
>
> Signed-off-by: Andrey Grodzovsky
> ---
>
Quoting khs...@codeaurora.org (2021-04-29 10:23:31)
> On 2021-04-29 02:26, Stephen Boyd wrote:
> > Quoting khs...@codeaurora.org (2021-04-28 10:38:11)
> >> On 2021-04-27 17:00, Stephen Boyd wrote:
> >> > Quoting aravi...@codeaurora.org (2021-04-21 11:55:21)
> >> >> On 2021-04-21 10:26,
On Thu, Apr 29, 2021 at 3:04 AM Christian König
wrote:
>
>
>
> Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
> > Some of the stuff in amdgpu_device_fini such as HW interrupts
> > disable and pending fences finilization must be done right away on
> > pci_remove while most of the stuff which
Hi,
On Thu, Apr 29, 2021 at 5:58 PM Linus Walleij wrote:
>
> On Fri, Apr 23, 2021 at 6:59 PM Douglas Anderson
> wrote:
>
> > In commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to
> > avoid excessive unprepare / prepare") we started using pm_runtime, but
> > my patch neglected to
On Fri, Apr 30, 2021 at 3:25 AM Doug Anderson wrote:
> > I think pm_runtime_disable(); need to be added there?
>
> I'm a bit confused. You're saying that I need to add
> pm_runtime_disable() to panel_simple_remove()? Doesn't this patch do
> that?
It does, sorry, too late at night :D
I was
On Fri, Apr 23, 2021 at 6:59 PM Douglas Anderson wrote:
> In commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to
> avoid excessive unprepare / prepare") we started using pm_runtime, but
> my patch neglected to add the proper pm_runtime_disable(). Doh! Add
> them now.
>
> Fixes:
Hi all,
On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
wrote:
>
> On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/display/intel_sprite.c
> >
> > between commit:
> >
>
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a
Change history:
v10:
- Removed mistakenly added temporary file
v9:
- Actually send the changes under v8 below (missed to commit
before sending v8)
v8:
- Chaged link lanes and rate parameters to u8
v7:
- Fixed formatting
- Fixed 'unused variable' compile warning
- Fixed comment format
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Apr 29, 2021 at 10:51 AM Daniel
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a
Change history:
v9:
- Actually send the changes under v8 below (missed to commit
before sending v8)
v8:
- Chaged link lanes and rate parameters to u8
v7:
- Fixed formatting
- Fixed 'unused variable' compile warning
- Fixed comment format
v6:
- Submited from (hopefully) the correct
Hi,
On Thu, Apr 29, 2021 at 11:04 AM Rob Herring wrote:
>
> On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> > Add bindings for DisplayPort aux backlight driver.
> >
> > Changes in v2:
> > - New
> >
> > Signed-off-by: Rajeev Nandan
> > ---
> >
On 2021-04-29 3:23 p.m., Bjorn Helgaas wrote:
On Thu, Apr 29, 2021 at 12:53:15PM -0400, Andrey Grodzovsky wrote:
On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
This is exact copy of 'USB: add support for dev_groups to
On 2021-04-29 3:05 p.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
Hi,
On Thu, Apr 29, 2021 at 7:34 AM Linus Walleij wrote:
>
> On Tue, Apr 6, 2021 at 1:47 AM Linus Walleij wrote:
>
> > This adds device tree bindings for the Samsung LMS397KF04
> > RGB DPI display panel.
> >
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Linus Walleij
>
> Someone on DRM
Hi,
On Thu, Apr 29, 2021 at 8:39 AM Linus Walleij wrote:
>
> This adds device tree bindings for the Samsung LMS397KF04
> RGB DPI display panel.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
> Reviewed-by: Rob Herring
> ---
> .../display/panel/samsung,lms397kf04.yaml |
Hi,
On Thu, Apr 29, 2021 at 8:40 AM Linus Walleij
> @@ -33,6 +33,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> panel-raspberrypi-touchscreen
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
>
On Thu, Apr 29, 2021 at 9:40 AM Kai-Heng Feng
wrote:
>
> Screen flickers rapidly when two 4K 60Hz monitors are connected to an
> Oland card. This issue doesn't happen when one monitor is 4K 60Hz
> (pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz).
>
> The issue is gone after
Hi Daniel,
Many thanks for your patch,
Acked-by: Philippe Cornu
Philippe :-)
De : Daniel Vetter
Envoyé : mardi 27 avril 2021 11:20
À : DRI Development
Cc : Intel Graphics Development; Daniel Vetter; Daniel Vetter; Yannick FERTRE -
foss; Philippe CORNU -
On Thu, Apr 29, 2021 at 12:53:15PM -0400, Andrey Grodzovsky wrote:
> On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
> > On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
> > > This is exact copy of 'USB: add support for dev_groups to
> > > struct usb_device_driver' patch by Greg
Hi
Am 29.04.21 um 18:04 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Thomas Zimmermann
Sent: Thursday, April 29, 2021 6:51 AM
To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
wrote:
>
>
> On 28/04/2021 18:09, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
> > wrote:
> >> On 28/04/2021 15:02, Daniel Vetter wrote:
> >>> On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
>
>
On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/29/21 2:04 PM, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg Kroah-Hartman wrote:
> >> On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter wrote:
> >>> On Wed, Apr 28, 2021 at 11:52:49PM
On Wed, Apr 28, 2021 at 7:34 PM Umesh Nerlige Ramappa
wrote:
>
> Perf measurements rely on CPU and engine timestamps to correlate
> events of interest across these time domains. Current mechanisms get
> these timestamps separately and the calculated delta between these
> timestamps lack enough
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > > > + ret =
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
> > > > With this calling
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed,
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us git rid of the complex VM setting code.
Signed-off-by: Jason
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed,
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 302
1 file changed, 302 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a80d36c2a2663..dd066b5009fe7 100644
---
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 files changed,
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 5 -
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > >
> > > I think we should have a FIXME here of not
JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
today if there's no objections
On Wed, 2021-04-28 at 19:43 -0400, Nikola Cornij wrote:
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space
On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
> > > + ret = set_proto_ctx_param(file_priv, pc, args);
> >
> > I think we should have a FIXME here of not allowing this on some future
> > platforms because just use
On Thu, Apr 29, 2021 at 12:13 PM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 07:12:05PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 09:54:15AM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > > wrote:
> > > >
> > > >
> > > > On 28/04/2021
On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:
>
> Yeah this needs some text to explain what/why you're doing this, and maybe
> some rough sketch of the locking design.
Yup. Will add.
>
> On Fri, Apr 23, 2021 at 05:31:26PM -0500, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand
On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> Add bindings for DisplayPort aux backlight driver.
>
> Changes in v2:
> - New
>
> Signed-off-by: Rajeev Nandan
> ---
> .../bindings/leds/backlight/dp-aux-backlight.yaml | 49
> ++
> 1 file changed, 49
On 29/04/2021 17:31, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.
Signed-off-by: Tvrtko Ursulin
Fixes: a21ce8ad12d2
On Thu, Apr 29, 2021 at 07:31:43PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > __i915_active_call annotation is required on the retire callback to ensure
> > correct function alignment.
> >
> > Signed-off-by:
On Fri, Apr 23, 2021 at 05:31:31PM -0500, Jason Ekstrand wrote:
> Now that we have the whole engine set and VM at context creation time,
> we can just assign those fields instead of creating first and handling
> the VM and engines later. This lets us avoid creating useless VMs and
> engine sets
On 2021-04-29 02:26, Stephen Boyd wrote:
Quoting khs...@codeaurora.org (2021-04-28 10:38:11)
On 2021-04-27 17:00, Stephen Boyd wrote:
> Quoting aravi...@codeaurora.org (2021-04-21 11:55:21)
>> On 2021-04-21 10:26, khs...@codeaurora.org wrote:
>> >>
>> >>> +
>> >>>
Hi Laurent,
On Thu, Apr 29, 2021 at 5:59 PM Laurent Pinchart
wrote:
> On Thu, Apr 29, 2021 at 02:47:56PM +0200, Geert Uytterhoeven wrote:
> > "make dtbs_check" complains:
> >
> > arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display@fff8:
> > 'power-domains' does not match any of the
On Fri, Apr 23, 2021 at 05:31:28PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
I think with the additions move in here and commit message explaining a
bit what's going on this looks all reasonable.
I think minimally you should explain the audit you've done here and which
On Fri, Apr 23, 2021 at 05:31:30PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
Maybe spend a few words on explaining why in these two selftest patches
instead of letting me guess :-)
-Daniel
> ---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
> 1 file
On Thu, Apr 29, 2021 at 10:29:51AM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 8:27 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 23, 2021 at 05:31:24PM -0500, Jason Ekstrand wrote:
> > > We're about to start doing lazy context creation which means contexts
> > > get created in
On Thu, Apr 29, 2021 at 11:02:27AM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 7:16 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > On Wed, Apr 28, 2021
On Thu, Apr 29, 2021 at 07:12:05PM +0200, Daniel Vetter wrote:
> On Thu, Apr 29, 2021 at 09:54:15AM -0500, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 28/04/2021 18:24, Jason Ekstrand wrote:
> > > > On Wed, Apr 28, 2021 at 10:55 AM
On 2021-04-29 3:15 a.m., Christian König wrote:
Filizing the fences? You mean finishing the fences, don't you? :)
Yes, my bad.
Andrey
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
No point calling amdgpu_fence_wait_empty before stopping the
SW scheduler otherwise there is always a
On Thu, Apr 29, 2021 at 09:54:15AM -0500, Jason Ekstrand wrote:
> On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 28/04/2021 18:24, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
> > > wrote:
> > >> On 23/04/2021 23:31, Jason Ekstrand wrote:
>
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another look at this part when I don't have a massive
headache any more.
Maybe split the patch set up into different parts, something like:
1. Adding general infrastructure.
2. Making sure all memory is unpolated.
3. Job and
https://bugzilla.kernel.org/show_bug.cgi?id=212107
Martin (martin...@gmx.com) changed:
What|Removed |Added
Status|CLOSED |REOPENED
On Thu, Apr 29, 2021 at 05:42:44PM +0300, Dan Carpenter wrote:
> On Wed, Apr 28, 2021 at 04:04:14PM +0300, Andy Shevchenko wrote:
> > + if (IS_ERR(*gpiop))
> > + dev_err_probe(dev, PTR_ERR(*gpiop), "Failed to request %s
> > GPIO\n", name);
>
> This should be a return statement:
>
>
On 2021-04-29 3:19 a.m., Christian König wrote:
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
Access to those must be prevented post pci_remove
That is certainly a no-go. We want to get rid of the kernel pointers in
BOs, not add another one.
Christian.
As we discussed internally,
On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
In subject:
s/PCI: add support/PCI: Add support/
to match convention ("git log --oneline drivers/pci/pci-driver.c" to
learn this).
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
This is exact copy of 'USB: add support for
On Thu, Apr 29, 2021 at 8:02 AM Daniel Vetter wrote:
>
> The commit introducing a new data structure really should have a solid
> intro in the commit message about. Please cover
>
> - that ctx really should be immutable, safe for exceptions like priority
>
> - that unfortunately we butchered the
On 2021-04-29 12:29 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:21 p.m. schrieb Andrey Grodzovsky:
On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
So as I understand your preferred approach is that I scope any
back_end, HW
On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> __i915_active_call annotation is required on the retire callback to ensure
> correct function alignment.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using
Hi Bernard,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.12 next-20210429]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
Am 2021-04-29 um 12:21 p.m. schrieb Andrey Grodzovsky:
>
>
> On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
>> Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
>>> So as I understand your preferred approach is that I scope any
>>> back_end, HW specific function with drm_dev_enter/exit
On 28.04.21 16:16, Marek Vasut wrote:
On 4/28/21 11:24 AM, Neil Armstrong wrote:
[...]
+static int sn65dsi83_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = >dev;
+ enum sn65dsi83_model model;
+ struct sn65dsi83 *ctx;
+ int
On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
So as I understand your preferred approach is that I scope any
back_end, HW specific function with drm_dev_enter/exit because that
where MMIO
access takes place. But besides explicit MMIO
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
> So as I understand your preferred approach is that I scope any
> back_end, HW specific function with drm_dev_enter/exit because that
> where MMIO
> access takes place. But besides explicit MMIO access thorough
> register accessors in the HW
Hi Geert,
Thank you for the patch.
On Thu, Apr 29, 2021 at 02:47:56PM +0200, Geert Uytterhoeven wrote:
> "make dtbs_check" complains:
>
> arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display@fff8:
> 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+'
>
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: lkp ;
On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
With this calling drm_dev_unplug will flush and block
all in flight IOCTLs
Also, add feature such that if device
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc:
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: Winiarski, Michal ; Nikula,
On Thu, Apr 29, 2021 at 7:16 AM Daniel Vetter wrote:
>
> On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Apr 27, 2021 at
Yeah this needs some text to explain what/why you're doing this, and maybe
some rough sketch of the locking design.
On Fri, Apr 23, 2021 at 05:31:26PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 657 --
>
Hi Geert,
Thank you for the patch.
On Thu, Apr 29, 2021 at 02:47:31PM +0200, Geert Uytterhoeven wrote:
> The "resets" property is not present on R-Car Gen1 SoCs.
> Supporting it would require migrating from renesas,cpg-clocks to
> renesas,cpg-mssr.
>
> Reflect this in the DT bindings by
1 - 100 of 195 matches
Mail list logo
