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 relates to finilizing and
releasing driver data structures can be kept until
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
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
Maybe split that up into more patches.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/d
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page
per drm_file instance or imported GEM object.
v4:
Update for modified ttm_bo_vm_dummy_page
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgp
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finilizing post physical device extraction.
v5: Use newly added pci_driver.dev_groups directly
Signed-off-by: Andrey Grodzovsky
Looks l
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
Signed-off-by: Andrey Grodzovsky
---
dr
Filizing the fences? You mean finishing the fences, don't you? :)
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 chance another job sneaked
in after the wait.
Signed-off-by: Andrey Grodzovsk
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 fence handling
Christian.
Am 28.04.21 um 17:11 schrieb
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.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
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 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Ja
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:
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplify
the c
On 28/04/2021 18:26, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
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 i
On 29/04/2021 03:34, 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 accuracy.
To improve t
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 i915_active tracking")
Cc: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c| 2 +-
2 files changed,
Hi Dave, Daniel,
Here's this week drm-misc-next-fixes PR
Maxime
drm-misc-next-fixes-2021-04-29:
Two patches in drm-misc-next-fixes this week, one to fix the error
handling in TTM when a BO can't be swapped out and one to prevent a
wrong dereference in efifb.
The following changes since commit a4
From: Tvrtko Ursulin
Some cleanups and improvements to checks being done when building workaround
lists. First five patches are small cleanups while the last one contains the
actual story of what gets improved.
Test-with: 20210429084130.850426-1-tvrtko.ursu...@linux.intel.com
Tvrtko Ursulin (6)
From: Tvrtko Ursulin
In order to stop conflating the validation via readback with the
workaround mask I need to expose the read mask separately so
gem_workarounds IGT can continue operating correctly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file change
From: Tvrtko Ursulin
We distinguish masked registers from other workarounds by the mask (clr)
being zero for the former.
To avoid callers of the low-level wa_add having to know that, and be
passing this zero explicitly, add a wa_masked_add low-level helper
which embeds this knowledge.
Signed-of
From: Tvrtko Ursulin
Add a new helper wa_write_no_verify for Wa_1604278689:icl,ehl which is
a write only register. This allows the mask to correctly reflect what
bits the workaround writes versus which bits it will verify during read-
back. In turn this will allow more safety checks to be added i
From: Tvrtko Ursulin
In current code we check that a workaround is not completely
overwriting the existing one, but for instance partial conflict in some
bits would get missed, as would problems involving masked registers,
courtesy of the mask (wa->clr) being forced to zero for such registers and
From: Tvrtko Ursulin
Same workaround was listed two times - once under the Gen7 block and once
under the Haswell section.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workaround
From: Tvrtko Ursulin
Instead of "open coding" WaEnableFloatBlendOptimization:icl via
wa_write_clr_set, which should be for non-masked workarounds, add a new
helper wa_masked_en_no_verify and use it.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 +---
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Tuesday, April 27, 2021 7:02 PM
To: Kuo-Hsiang Chou ;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v5] drm/ast: Fixed CVE for DP501
Hi Thomas,
Hi
Am 21.04.21 um 10:58 sc
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:
> >> >>
> >> >>> +
> >> >>> mutex_unlock(&dp->event_mutex);
> >> >>>
> >> >>>
On Tue, 27 Apr 2021, "Ruhl, Michael J" wrote:
>>-Original Message-
>>From: Thomas Zimmermann
>>Sent: Tuesday, April 27, 2021 1:49 PM
>>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi,
>>Rodrigo
>>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>>; Ruhl, Michael
On Wed, Apr 28, 2021 at 04:57:26PM -0400, Alex Deucher wrote:
> On Mon, Apr 26, 2021 at 3:35 AM Maxime Ripard wrote:
> >
> > Hi Alex,
> >
> > On Thu, Apr 22, 2021 at 12:40:10PM -0400, Alex Deucher wrote:
> > > On Thu, Apr 22, 2021 at 12:33 PM Maxime Ripard wrote:
> > > >
> > > > Hi Dave, Daniel,
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine res
On Wed, Apr 28, 2021 at 3:29 PM Sebastian Reichel
wrote:
>
> Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
> modules SQW clock output defaults to 32768 Hz. This behaviour is
> used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
> the clock is disabled and all i.
On Wed, Apr 21, 2021 at 01:18:03PM +0300, Dan Carpenter wrote:
> Cppcheck complains that the declaration doesn't match the function
> definition. Obviously "left" should come before "right". The caller
> and the function implementation are done this way, it's just the
> declaration which is wrong
On Fri, Apr 16, 2021 at 11:00:39AM +0200, Thomas Zimmermann wrote:
> This patchset adds support for simple-framebuffer platform devices and
> a handover mechanism for native drivers to take-over control of the
> hardware.
>
> The new driver, called simpledrm, binds to a simple-frambuffer platform
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(D
In the next patch we want to expose the supported regions to userspace,
which can then be fed into the gem_create_ext placement extensions. For
now treat stolen memory as private from userspace pov.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
v2(Daniel & Jason):
- Add some kernel-doc, including example usage.
- Drop all the extra rsvd
v3(Jason & Tvrtko)
- add back rsvd
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joon
With the upcoming gem_create_ext we want to be able create a "vanilla"
object upfront and pass that directly to the extensions, before actually
initialising the object. Functionally this should be the same expect we
now feed the object into the lower-level region specific init_object.
Signed-off-b
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases.
v2:(Chris)
- Use separate ioctl number for gem_create_ext, instead of hijacking
the existing gem_create ioctl, otherwise we run into the issue
with being unable to detect
Add new extension to support setting an immutable-priority-list of
potential placements, at creation time.
If we use the normal gem_create or gem_create_ext without the
extensions/placements then we still get the old behaviour with only
placing the object in system memory.
v2(Daniel & Jason):
For some internal device local-memory objects it would be useful to have
an option to CPU clear the pages upon gathering the backing store. Note
that this might be before the blitter is useable, which is the case for
some internal GuC objects.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc:
All userspace objects must be cleared when allocating the backing store,
before they are potentially visible to userspace. For now use simple
CPU based clearing to do this for device local-memory objects, note that
in the near future this will instead use the blitter engine.
Signed-off-by: Matthe
Treat it the same as the fake local-memory stuff, where it is disabled
for normal kernels, in case some random UMD is tempted to use this. Once
we have all the other bits and pieces in place, like the TTM conversion,
we can turn this on for real.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
C
Adding the previous list of CCs.
On Thu, 29 Apr 2021 10:32:58 +
"Sharma, Shashank" wrote:
> Hello Pekka, Daniel
>
> As discussed over IRC, I have prepared the first version of the EDID parsing
> library, which is hosted here:
> https://github.com/contactshashanksharma/libedid/tree/master
>
Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
from struct drm_device.dev to get the PCI device structure.
Signed-off-by: Thomas Zimmermann
Fixes: ba4e0339a6a3 ("drm/ast: Fixed CVE for DP501")
Cc: KuoHsiang Chou
Cc: kernel test robot
Cc: Thomas Zimmermann
Cc: Dave Airlie
V8 of the patchset fixes more bitrot and some commit messages.
The pdev field in struct drm_device points to a PCI device structure and
goes back to UMS-only days when all DRM drivers were for PCI devices.
Meanwhile we also support USB, SPI and platform devices. Each of those
uses the generic devi
References to struct drm_device.pdev should not be used any longer as
the field will be moved into the struct's legacy section. Fix a rsp
comment.
v8:
* fix commit message (Michael)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
1 file changed, 1 in
References to struct drm_device.pdev should not be used any longer as
the field will be moved into the struct's legacy section. Add a fix
for the rsp commit.
v8:
* fix commit message (Michael)
Signed-off-by: Thomas Zimmermann
Fixes: a50ca39fbd01 ("drm/i915: setup the LMEM region")
Cc: Lu
Struct drm_device.pdev is being moved to legacy status as only legacy
DRM drivers use it. A possible follow-up patchset could remove pdev
entirely.
v4:
* rebased
Signed-off-by: Thomas Zimmermann
Reviewed-by: Chris Wilson
Acked-by: Sam Ravnborg
---
include/drm/drm_device.h | 6 +++---
Using struct drm_device.pdev is deprecated. Don't assign it. Users
should upcast from struct drm_device.dev.
v6:
* also fix the assignment in selftests in this patch (Chris)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
On Fri, Apr 23, 2021 at 01:04:23PM +, pgeiem wrote:
> Dear all,
>
> On a custom board I have a simple DPI panel. Panel's backlight is
> drive with an I2C led driver (PCA9632). led-backlight driver is sued
> to manage this as a backlight.
>
> When using brightness-levels and default-brightness
On Wed, Apr 28, 2021 at 04:45:01PM +0200, Christian König wrote:
> Am 28.04.21 um 16:34 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wro
On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote:
> On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christi
On Wed, Apr 28, 2021 at 11:43:22AM +0300, Jani Nikula wrote:
> On Tue, 27 Apr 2021, 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
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 supports graceful unplug
> we enclose entire IOCTL in SRCU critical section.
>
> Signed-off-by: Andrey Grodzo
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 supports graceful unplug
> > we enclo
On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
> Userspace could hold open a reference to the connector->kdev device,
> through e.g. holding a sysfs-atrtribute open after
> drm_sysfs_connector_remove() has been called. In this case the connector
> could be free-ed while the connecto
On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
> > Userspace could hold open a reference to the connector->kdev device,
> > through e.g. holding a sysfs-atrtribute open after
> > drm_sysfs_connector_remove() has been c
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 +0200, Hans de Goede wrote:
> > > Userspace could hold open a reference to the connector->kdev device,
> > > through e.g. holdi
Nice catch!
Are you using any tool to identify this problem?
Reviewed-by: Rodrigo Siqueira
On 04/29, Wan Jiabing wrote:
> In commit 482812d56698e ("drm/amd/display: Set max TTU on
> DPG enable"), "hubp.h" was added which caused the duplicate include.
> To be on the safe side, remove the later d
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
On Thu, Apr 29, 2021 at 11:31:20AM +, pgeiem wrote:
> On Thursday, April 29, 2021 1:00 PM, Daniel Thompson
> wrote:
>
> > On Fri, Apr 23, 2021 at 01:04:23PM +, pgeiem wrote:
> >
> > > Dear all,
> > > On a custom board I have a simple DPI panel. Panel's backlight is
> > > drive with an I2
Hi Wan,
Instead of remove the first dc_state, remove the second one.
Thanks
On 04/29, Wan Jiabing wrote:
> There are two declarations of struct dc_state here.
> The later one is closer to its user. Remove the former duplicate.
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/gpu/drm/amd/display
On Thu, Apr 29, 2021 at 09:06:47AM +0100, Tvrtko Ursulin wrote:
>
> On 28/04/2021 18:26, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 23/04/2021 23:31, Jason Ekstrand wrote:
> > > > This API is entirely unnecessary and I'd love to get
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 at 12:26 PM Matthew Brost
> > > wrote:
> > > > Jumping on here mid-thread. For
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 08:51:08AM -0500, Jason Ekstrand wrote:
> > > > I sent a v2 of this patch becau
On Wed, Apr 28, 2021 at 01:22:14PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 5:27 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 23, 2021 at 05:31:21PM -0500, Jason Ekstrand wrote:
> > > As far as I can tell, the only real reason for this is to avoid taking a
> > > reference to the i915_
>Nice catch!
>
>Are you using any tool to identify this problem?
Yes, I have a robot including many detecting scripts :)
>Reviewed-by: Rodrigo Siqueira
>
>On 04/29, Wan Jiabing wrote:
>> In commit 482812d56698e ("drm/amd/display: Set max TTU on
>> DPG enable"), "hubp.h" was added which caused
On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
>
> On 23/04/2021 23:31, Jason Ekstrand wrote:
> > 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 en
Hi,
On 4/29/21 1:40 PM, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
>> Userspace could hold open a reference to the connector->kdev device,
>> through e.g. holding a sysfs-atrtribute open after
>> drm_sysfs_connector_remove() has been called. In this case
>Hi Wan,
>
>Instead of remove the first dc_state, remove the second one.
>
>Thanks
Hi Rodrigo,
Thanks for your reply.
OK, in fact, there are no functions using struct dc_state between two
struct declarations. So I think removing anyone is OK.
Remove the first one to make it more closer to user
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 +0200, Hans de Goede wrote:
Userspace could hold open a reference to the
https://bugzilla.kernel.org/show_bug.cgi?id=212881
Bug ID: 212881
Summary: nouveau: BUG: kernel NULL pointer dereference in
nouveau_bo_sync_for_device
Product: Drivers
Version: 2.5
Kernel Version: 5.11.0
Hardware: Intel
On Fri, Apr 23, 2021 at 05:31:25PM -0500, Jason Ekstrand wrote:
> There's a big comment saying how useful it is but no one is using this
> for anything.
>
> Signed-off-by: Jason Ekstrand
I was trying to find anything before all your deletions, but alas nothing.
I did spent a bit of time on this,
https://bugzilla.kernel.org/show_bug.cgi?id=212881
dave.muel...@gmx.ch changed:
What|Removed |Added
Regression|No |Yes
--
You may reply to this email
There are two declarations of struct dc_state here.
Remove the later duplicate more secure.
Signed-off-by: Wan Jiabing
---
Changelog:
v2:
- Remove the later duplicate instead of the former.
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm
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 removing the global "required:
resets". All SoCs that do have "resets" properties already have
SoC-specific rules making i
"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]+'
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dt.yaml: display@feb0:
'power-domains' does not match any of the regexes: 'pinctrl-[
On 29/04/2021 13:24, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to an
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 uapi with setparam and sharing
setparams between create_ext and s
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 i915_gem_context_lookup and we may start having more
> errors than -ENOENT.
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/
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 setting "power_dpm_force_performance_level" to
"high". Following the l
Op 29-04-2021 om 15:28 schreef Matthew Auld:
> On Thu, 29 Apr 2021 at 11:10, Maarten Lankhorst
> wrote:
>> This will allow us to explicitly pass the ww to pin_pages,
>> when it starts taking it.
>>
>> This allows us to finally kill off the explicit passing of ww
>> by retrieving it from the obj.
>
Reviewed-by: Rodrigo Siqueira
On 04/29, Wan Jiabing wrote:
> There are two declarations of struct dc_state here.
> Remove the later duplicate more secure.
>
> Signed-off-by: Wan Jiabing
> ---
> Changelog:
> v2:
> - Remove the later duplicate instead of the former.
> ---
> drivers/gpu/drm/amd/d
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 misc up to review and/or apply these two
patches?
Doug? I bet you have some
Applied to amd-staging-drm-next.
Thanks
On 04/29, Rodrigo Siqueira wrote:
> Reviewed-by: Rodrigo Siqueira
>
> On 04/29, Wan Jiabing wrote:
> > There are two declarations of struct dc_state here.
> > Remove the later duplicate more secure.
> >
> > Signed-off-by: Wan Jiabing
> > ---
> > Changel
Is your robot public available?
btw, applied to amd-staging-drm-next.
Thanks
On 04/29, Jiabing Wan wrote:
>
> >Nice catch!
> >
> >Are you using any tool to identify this problem?
>
> Yes, I have a robot including many detecting scripts :)
>
> >Reviewed-by: Rodrigo Siqueira
> >
> >On 04/29,
On Wed, Apr 28, 2021 at 04:04:14PM +0300, Andy Shevchenko wrote:
> @@ -75,20 +75,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
> struct gpio_desc **gpiop)
> {
> struct device *dev = par->info->device;
> - int ret = 0;
>
> *gpiop =
On Thu, Apr 29, 2021 at 7:08 AM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 09:06:47AM +0100, Tvrtko Ursulin wrote:
> >
> > On 28/04/2021 18:26, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
> > > wrote:
> > > >
> > > >
> > > > On 23/04/2021 23:31, Jason Ekstran
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:
> >>> Instead of handling it like a context param, unconditionally set it when
> >>
>Is your robot public available?
Sorry, I started to write the robot just one week ago.
It is not strong and complete enough so it is not public available now.
But I am still working on it. If complete, it can be public available.
In fact, this patch is catched by the script called checkinclude
Well if you are bored we quite often have the problem of unused fields
in structures.
If your robot could find fields which are never read, that would be
quite helpful I think.
There probably will be a lot of false positives for things like padding,
but maybe that yields something.
Christi
On Thu, Apr 29, 2021 at 7:37 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:25PM -0500, Jason Ekstrand wrote:
> > There's a big comment saying how useful it is but no one is using this
> > for anything.
> >
> > Signed-off-by: Jason Ekstrand
>
> I was trying to find anything before all
On Thu, Apr 29, 2021 at 2:44 AM Felix Kuehling wrote:
>
> On 2021-04-27 7:27, Fabio M. De Francesco wrote:
> > In the documentation of functions, removed excess parameters, described
> > undocumented ones, and fixed syntax errors.
> >
> > Signed-off-by: Fabio M. De Francesco
> > ---
> >
> > Chang
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 i915_gem_context_lookup and we may start having more
> > errors than -ENOENT.
> >
>
On Thursday, April 29, 2021 1:00 PM, Daniel Thompson
wrote:
> On Fri, Apr 23, 2021 at 01:04:23PM +, pgeiem wrote:
>
> > Dear all,
> > On a custom board I have a simple DPI panel. Panel's backlight is
> > drive with an I2C led driver (PCA9632). led-backlight driver is sued
> > to manage this
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:
> > @@ -75,20 +75,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
> > struct gpio_desc **gpiop)
> > {
> > struct device
On Thu, Apr 29, 2021 at 7:54 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 13:24, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 23/04/2021 23:31, Jason Ekstrand wrote:
> >>> This adds a bunch of complexity which the media driver has never
> >>
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 removing
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 --
> dr
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 08:51:
>-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, Ja
>-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: intel-...@lists.freedesktop.or
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 su
1 - 100 of 197 matches
Mail list logo
