Hi Sean,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.15-rc1 next-20210914]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch
Am 13.09.21 um 14:41 schrieb Thomas Hellström:
[SNIP]
Let's say you have a struct ttm_object_vram and a struct
ttm_object_gtt, both subclassing drm_gem_object. Then I'd say a
driver would want to subclass those to attach identical data,
extend functionality and provide a single i915_gem_object
On Thu, Aug 19, 2021 at 03:59:25PM +0200, Maxime Ripard wrote:
> Hi,
>
> This series aims at fixing a complete and silent hang when one tries to use
> CEC
> while the display output is off.
>
> This can be tested with:
>
> echo off > /sys/class/drm/card0-HDMI-A-1/status
> cec-ctl --tuner -p 1.0
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> > [SNIP]
> > > > > Let's say you have a struct ttm_object_vram and a struct
> > > > > ttm_object_gtt, both subclassing drm_gem_object. Then I'd say
> > > > > a
> > > > > driver would want
Hi,
On Mon, Sep 13, 2021 at 07:45:03PM +0300, Jani Nikula wrote:
> On Tue, 31 Aug 2021, Jani Nikula wrote:
> > v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
> > check and an OUI helper patch added.
>
> Maarten, Maxime, Thomas - may I have an ack for merging this via
> d
On 13/09/2021 17:50, Matthew Brost wrote:
On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
On 10/09/2021 20:49, Matthew Brost wrote:
On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin wrote:
On 20/08/2021 23:44, Matthew Brost wrote:
Add logical engine mapping. This is
On 13/09/2021 18:12, Matthew Brost wrote:
On Mon, Sep 13, 2021 at 10:55:59AM +0100, Tvrtko Ursulin wrote:
On 20/08/2021 23:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight.
FIXME: Move locking
On Sun, Sep 12, 2021 at 10:32 PM Dave Airlie wrote:
>
> On Sun, 12 Sept 2021 at 23:55, Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Sep 10, 2021 at 06:10:27PM +0200, Daniel Vetter wrote:
> > > Forgot to add dri-devel.
> > >
> > > On Fri, Sep 10, 2021 at 6:09 PM Daniel Vetter
> > > wrote:
> > > >
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, September 2, 2021 6:00 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter
> ; Sea
Hi,
On Sun, Sep 12, 2021 at 09:46:46PM +0200, Sam Ravnborg wrote:
> On Fri, Sep 10, 2021 at 03:09:41PM +0200, Maxime Ripard wrote:
> > The new devm_drm_of_get_bridge removes most of the boilerplate we
> > have to deal with. Let's switch to it.
> >
> > Signed-off-by: Maxime Ripard
>
> With the i
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we should skip the ttm_pages_allocated accounting, since
such tt objects should already be reachable, and potentially reclaimable
by some shrinker, if
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/d
Enable shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f02037a8cebd..
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 -
We currently just evict lmem objects to system memory when under memory
pressure. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
Am 14.09.21 um 10:27 schrieb Thomas Hellström:
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
Am 13.09.21 um 14:41 schrieb Thomas Hellström:
[SNIP]
Let's say you have a struct ttm_object_vram and a struct
ttm_object_gtt, both subclassing drm_gem_object. Then I'd say
a
driver would w
Am 14.09.21 um 10:50 schrieb Matthew Auld:
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we should skip the ttm_pages_allocated accounting, since
such tt objects should already be reachable, and
On 9/10/21 16:10, Imran Khan wrote:
> This change is in response to discussion at [1].
> The patch has been created on top of my earlier changes [2] and [3].
> If needed I can resend all of these patches together, though my
> earlier patches have been Acked.
I think you sent those at the beginning
Hello Jernej,
On Mon, Sep 13, 2021 at 07:21:54PM +0200, Jernej Skrabec wrote:
> Recent rework, which made HDMI PHY driver a platform device, inadvertely
> reversed clock setup order. HW is very touchy about it. Proper way is to
> handle controllers resets and clocks first and HDMI PHYs second.
>
On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
> Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> control brightness, apparently needs a delay before setting brightness
> after power on. Without this delay the panel does accept the setting
> and may come up with some arbitr
On Wed, 08 Sep 2021, Lucas De Marchi wrote:
> We shouldn't be using debugfs_ namespace for this functionality. Rename
> debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions,
> defines and structs follow suit.
>
> While at it and since we are renaming the header, sort the includes
> alp
Hi,
This is a follow-up of the discussion here:
https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
This implements a mechanism to raise and lower clock rates based on consumer
workloads, with an example of such an implementation for the RaspberryPi4 HDMI
controller.
There
It's not unusual to find clocks being shared across multiple devices
that need to change the rate depending on what the device is doing at a
given time.
The SoC found on the RaspberryPi4 (BCM2711) is in such a situation
between its two HDMI controllers that share a clock that needs to be
raised de
The new clock request API allows us to increase the rate of the HSM
clock to match our pixel rate requirements while decreasing it when
we're done, resulting in a better power-efficiency.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
drivers/gpu/drm/vc4/vc
From: Dom Cobley
The new clock request API allows us to increase the rate of the
core clock as required during mode set while decreasing it when
we're done, resulting in a better power-efficiency.
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 5 +++
The documentation of the drm_helper_hpd_irq_event() function didn't
document the value that function was returning. Add that part as well.
Signed-off-by: Maxime Ripard
---
Changes from v2:
- new patch
---
drivers/gpu/drm/drm_probe_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
The drm_helper_hpd_irq_event() function is iterating over all the
connectors when an hotplug event is detected.
During that iteration, it will call each connector detect function and
figure out if its status changed.
Finally, if any connector changed, it will notify the user-space and the
clients
The drm_helper_hpd_irq_event() documentation states that this function
is "useful for drivers which can't or don't track hotplug interrupts for
each connector." and that "Drivers which support hotplug interrupts for
each connector individually and which have a more fine-grained detect
logic should
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/g
On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
> Am 14.09.21 um 10:27 schrieb Thomas Hellström:
> > On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> > > Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> > > > [SNIP]
> > > > > > > Let's say you have a struct ttm_object_vram and
Am 14.09.21 um 12:26 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/dri
Hi Maxime,
On Tue, Sep 14, 2021 at 12:17:23PM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that iteration, it will call each connector detect function and
> figure out if its status chang
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Signed-off-by: Christian König
---
drivers/dm
On 14/09/2021 11:39, Christian König wrote:
Am 14.09.21 um 12:26 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 i
Hi,
Am Mittwoch, 8. September 2021, 15:53:56 CEST schrieb Chris Morgan:
> From: Chris Morgan
>
> After commit 928f9e268611 ("clk: fractional-divider: Hide
> clk_fractional_divider_ops from wide audience") was merged it appears
> that the DSI panel on my Odroid Go Advance stopped working. Upon cl
Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Sig
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
> Introduce a powerpc version of the cc_platform_has() function. This will
> be used to replace the powerpc mem_encrypt_active() implementation, so
> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
> attribute.
>
Hi Ezequiel,
On Fri, 2021-09-03 at 11:08 +0800, yunfei.d...@mediatek.com wrote:
> Hi Ezequiel,
>
> Thanks for your suggestion.
> On Thu, 2021-09-02 at 13:30 -0300, Ezequiel Garcia wrote:
> > On Wed, 1 Sept 2021 at 05:32, Yunfei Dong > >
> > wrote:
> > >
> > > This series adds support for multi
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Also, FWIW, I submitted a patch to remove this function altogether since
its IMO pretty useless, just failed in getting an
Am 14.09.21 um 14:27 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Yeah, exactly that. I also wondered for a second if rcu_read_lock() can
nest
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/driv
Op 14-09-2021 om 08:50 schreef Peter Zijlstra:
> On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
>
>>> +/**
>>> + * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire
>>> context
>>> + * @ww: mutex to lock
>>> + * @ww_ctx: optional w/w acquire context
>>> +
On 14/09/2021 13:32, Christian König wrote:
Am 14.09.21 um 14:27 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Yeah, exactly that. I also won
On 14/09/2021 12:25, Christian König wrote:
Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences wher
On 13/09/2021 14:16, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions
On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
> > I rebased it and fixed it up here:
> >
> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
> >
> > Can you try again?
>
> That does address the crash, but then why is it processing a BROKEN
> event? Seems problematic.
The stuff
On Thu, Sep 09, 2021 at 08:22:59AM +0200, Christian König wrote:
> Am 08.09.21 um 19:45 schrieb Daniel Vetter:
> > On Fri, Sep 03, 2021 at 11:47:55AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > As the finished fence is the one that is exposed to userspace, and
> > > therefore the on
On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote:
> On Wed, 8 Sep 2021 18:27:09 +0200
> Daniel Vetter wrote:
>
> > On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 7 Sep 2021 14:42:56 +0200
> > > Hans de Goede wrote:
> > >
> > > > Hi,
> > > >
> > > > On 9
On Thu, Sep 09, 2021 at 08:37:23AM +1000, Ben Skeggs wrote:
> On Thu, 9 Sept 2021 at 04:19, Daniel Vetter wrote:
> >
> > On Mon, Sep 06, 2021 at 10:56:27AM +1000, Ben Skeggs wrote:
> > > From: Ben Skeggs
> > >
> > > We don't currently have any kind of real acceleration on Ampere GPUs,
> > > but t
On Thu, Sep 09, 2021 at 09:10:39AM +0200, Christian König wrote:
> Am 08.09.21 um 20:27 schrieb Daniel Vetter:
> > On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König wrote:
> > > Am 07.09.21 um 11:05 schrieb Daniel Vetter:
> > > > On Tue, Sep 07, 2021 at 08:22:20AM +0200, Christian König wro
On Tue, Sep 14, 2021 at 02:43:02PM +0200, Maarten Lankhorst wrote:
> Op 14-09-2021 om 08:50 schreef Peter Zijlstra:
> > On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
> >
> >>> +/**
> >>> + * ww_mutex_trylock - tries to acquire the w/w mutex with optional
> >>> acquire context
On Thu, Sep 09, 2021 at 02:37:41AM +, John Stultz wrote:
> When trying to do mid-order allocations, set __GFP_NOWARN to
> avoid warning messages if the allocation fails, as we will
> still fall back to single page allocatitions in that case.
> This is the similar to what we already do for large
On Tue, Sep 14, 2021 at 12:38:00PM +0200, Thomas Hellström wrote:
> On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
> > Am 14.09.21 um 10:27 schrieb Thomas Hellström:
> > > On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> > > > Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> >
On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> Hi,
> Re-sending this patch-set following the release of our user-space TPC
> compiler and runtime library.
>
> I would appreciate a review on this.
I think the big open we have is the entire revoke discussions. Having the
option to l
On Mon, Sep 13, 2021 at 10:09:54PM -0700, Matthew Brost wrote:
> An error capture allocates memory, memory allocations depend on resets,
> and resets need to flush the G2H handlers to seal several races. If the
> error capture is done from the G2H handler this creates a circular
> dependency. To wo
The previous parameters caused an unbalanced yellow tint.
Signed-off-by: Christophe Branchereau
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
b/drivers/gpu/drm/panel/panel-abt
On Mon, Sep 13, 2021 at 10:09:56PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> When i915 receives a context reset notification from GuC, it triggers
> an error capture before resetting any outstanding requsts of that
> context. Unfortunately, the error capture is not a time bound
> oper
On Tue, Sep 14, 2021 at 12:17:24PM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() documentation states that this function
> is "useful for drivers which can't or don't track hotplug interrupts for
> each connector." and that "Drivers which support hotplug interrupts for
> each connect
Hi,
On Mon, Sep 13, 2021 at 08:29:37AM +0200, Andrzej Hajda wrote:
>
> W dniu 10.09.2021 o 12:11, Maxime Ripard pisze:
> > Interactions between bridges, panels, MIPI-DSI host and the component
> > framework are not trivial and can lead to probing issues when
> > implementing a display driver. Let
On Fri, Sep 10, 2021 at 10:26:42AM +0200, Christian König wrote:
> Abstract the complexity of iterating over all the fences
> in a dma_resv object.
>
> The new loop handles the whole RCU and retry dance and
> returns only fences where we can be sure we grabbed the
> right one.
>
> Signed-off-by:
On Tue, Sep 14, 2021 at 12:16:13PM +0300, Jani Nikula wrote:
On Wed, 08 Sep 2021, Lucas De Marchi wrote:
We shouldn't be using debugfs_ namespace for this functionality. Rename
debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions,
defines and structs follow suit.
While at it and si
Le 14/09/2021 à 13:58, Borislav Petkov a écrit :
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote:
> Yes, see
> https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t
Aha, more compiler magic stuff ;-\
Oh well, I guess that fix will land upstream soon.
Thx.
--
Regards/Gruss,
Boris.
https://pe
Thanks John!
On Tue, 14 Sept 2021 at 19:26, Daniel Vetter wrote:
>
> On Thu, Sep 09, 2021 at 02:37:41AM +, John Stultz wrote:
> > When trying to do mid-order allocations, set __GFP_NOWARN to
> > avoid warning messages if the allocation fails, as we will
> > still fall back to single page allo
On Tue, Sep 14, 2021 at 5:18 PM Daniel Vetter wrote:
>
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I think the big
Hi Daniel,
On Tue, Sep 14, 2021 at 04:34:08PM +0200, Daniel Vetter wrote:
> On Tue, Sep 14, 2021 at 12:17:24PM +0200, Maxime Ripard wrote:
> > The drm_helper_hpd_irq_event() documentation states that this function
> > is "useful for drivers which can't or don't track hotplug interrupts for
> > eac
On Tue, 14 Sep 2021, Lucas De Marchi wrote:
> On Tue, Sep 14, 2021 at 12:16:13PM +0300, Jani Nikula wrote:
>>On Wed, 08 Sep 2021, Lucas De Marchi wrote:
>>> We shouldn't be using debugfs_ namespace for this functionality. Rename
>>> debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions
Hi Sam,
On Tue, Sep 14, 2021 at 12:41:55PM +0200, Sam Ravnborg wrote:
> On Tue, Sep 14, 2021 at 12:17:23PM +0200, Maxime Ripard wrote:
> > The drm_helper_hpd_irq_event() function is iterating over all the
> > connectors when an hotplug event is detected.
> >
> > During that iteration, it will cal
As discussed at [1] rockchip_drm_endpoint_is_subdriver will currently always
return -ENODEV for non-platform-devices (e.g. external i2c bridges), what
makes them never being considered in rockchip_rgb_init.
As suggested at [1] this additionally adds a of_device_is_available for
the node found, whi
On Tue, Aug 24, 2021 at 3:54 PM Nathan Chancellor wrote:
>
> This warning helps catch uninitialized variables. It should have been
> enabled at the same time as commit b2423184ac33 ("drm/i915: Enable
> -Wuninitialized") but I did not realize they were disabled separately.
> Enable it now that i915
On Tue, Sep 14, 2021 at 05:06:41PM +0200, Maxime Ripard wrote:
> Hi Sam,
>
> On Tue, Sep 14, 2021 at 12:41:55PM +0200, Sam Ravnborg wrote:
> > On Tue, Sep 14, 2021 at 12:17:23PM +0200, Maxime Ripard wrote:
> > > The drm_helper_hpd_irq_event() function is iterating over all the
> > > connectors whe
On Tue, Sep 14, 2021 at 12:17:22PM +0200, Maxime Ripard wrote:
> The documentation of the drm_helper_hpd_irq_event() function didn't
> document the value that function was returning. Add that part as well.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
>
> ---
>
> Changes from v2:
Hi Maxime,
On Tue, Sep 14, 2021 at 12:17:24PM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() documentation states that this function
> is "useful for drivers which can't or don't track hotplug interrupts for
> each connector." and that "Drivers which support hotplug interrupts for
>
On Fri, Sep 10, 2021 at 01:42:45PM +0300, Mikko Perttunen wrote:
> Add YAML device tree bindings for NVDEC, now in a more appropriate
> place compared to the old textual Host1x bindings.
>
> Signed-off-by: Mikko Perttunen
> ---
> v5:
> * Changed from nvidia,instance to nvidia,host1x-class optiona
On 9/14/21 4:07 PM, Daniel Vetter wrote:
On Tue, Sep 14, 2021 at 12:38:00PM +0200, Thomas Hellström wrote:
On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
Am 14.09.21 um 10:27 schrieb Thomas Hellström:
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
Am 13.09.21 um 14:41
Hi!
Dne torek, 14. september 2021 ob 10:59:22 CEST je Ondřej Jirman napisal(a):
> Hello Jernej,
>
> On Mon, Sep 13, 2021 at 07:21:54PM +0200, Jernej Skrabec wrote:
> > Recent rework, which made HDMI PHY driver a platform device, inadvertely
> > reversed clock setup order. HW is very touchy about
On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> On Tue, 14 Sept 2021 at 14:55, Matthew Brost wrote:
> >
> > From: Venkata Sandeep Dhanalakota
> >
> > Defining vma on stack can cause stack overflow, if
> > vma gets populated with new fields.
>
> Is there some higher level locking s
On Fri, Sep 10 2021, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
>> +
>> +private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
>> +if (!private)
>> +return ERR_PTR(-ENOMEM);
>
> Nit: there is no need to add GFP_KERNEL when
Thanks Dexuan, for the patch. A minor comment below.
On Mon, Sep 13, 2021 at 11:27 AM Dexuan Cui wrote:
>
> It looks like Hyper-V supports a hardware cursor feature. It is not used
> by Linux VM, but the Hyper-V host still draws a point as an extra mouse
> pointer, which is unwanted, especially w
> -Original Message-
> From: Deepak Rawat
> Sent: Tuesday, September 14, 2021 11:59 AM
> To: Dexuan Cui
> Cc: Haiyang Zhang ; David Airlie
> ; Daniel Vetter ; Thomas Zimmermann
> ; dri-devel@lists.freedesktop.org; linux-
> hyp...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject:
On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I thin
Hi,
On Mon, Sep 13, 2021 at 8:23 PM yangcong
wrote:
>
> Compared to v5, squash this with patch #3 in the series in
> drm/panel: boe-tv101wum-nl6
>
> yangcong (4):
> drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail
> dt-bindings: drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V ra
On 2021-09-07 10:03, Simon Ser wrote:
> Hi all,
>
> Recently I've been discussing with various people [1] [2] about amdgpu's
> handling of KMS planes. AMD hardware is a bit special when it comes to
> the cursor plane, and it's not always 100% clear how that maps with the
> KMS API.
>
> Up until n
On Fri, Sep 10, 2021 at 10:26:42AM +0200, Christian König wrote:
> Abstract the complexity of iterating over all the fences
> in a dma_resv object.
>
> The new loop handles the whole RCU and retry dance and
> returns only fences where we can be sure we grabbed the
> right one.
>
> Signed-off-by:
On Mon, 13 Sep 2021, Nathan Chancellor wrote:
> On Tue, Aug 24, 2021 at 03:54:24PM -0700, Nathan Chancellor wrote:
>> Commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings")
>> disabled -Wsometimes-uninitialized as noisy but there have been a few
>> fixes to clang that make the false p
On Tue, 14 Sept 2021 at 10:03, Christian König wrote:
>
> Am 14.09.21 um 10:50 schrieb Matthew Auld:
> > Add new flag to indicate special shmem based tt, which can directly
> > handle swapping itself, and should be visible to some shrinker.
> >
> > As part of this we should skip the ttm_pages_allo
Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 3000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012] Un
,On Mon, Sep 13, 2021 at 6:57 PM Gurchetan Singh
wrote:
>
>
>
>
> On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
>>
>> .
>>
>> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
>> wrote:
>> >
>> >
>> >
>> > On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
>> >>
>> >> On Wed, Sep 8, 2021 at 6
On Wed, 08 Sep 2021, Doug Anderson wrote:
> Hi,
>
> On Mon, Sep 6, 2021 at 3:05 AM Jani Nikula
> wrote:
>>
>> > +{
>> > + struct edid *edid;
>> > + u32 val;
>> > +
>> > + edid = drm_do_get_edid_blk0(drm_do_probe_ddc_edid, adapter, NULL,
>> > NULL);
>> > +
>> > + /*
>> > + *
On Tue, Sep 14, 2021 at 05:50:25PM +0200, Cornelia Huck wrote:
> On Fri, Sep 10 2021, Christoph Hellwig wrote:
>
> > On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> >> +
> >> + private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
> >> + if (!private)
> >> + ret
Appears to match latest BSPEC
Reviewed-by: Clint Taylor
-Clint
On 9/3/21 5:35 PM, Matt Roper wrote:
From: Lucas De Marchi
Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined t
On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
>
> On 13/09/2021 17:50, Matthew Brost wrote:
> > On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 10/09/2021 20:49, Matthew Brost wrote:
> > > > On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin
Hi Christophe,
Le mar., sept. 14 2021 at 11:27:16 +0200, Christophe Branchereau
a écrit :
The previous parameters caused an unbalanced yellow tint.
Signed-off-by: Christophe Branchereau
Acked-by: Paul Cercueil
Cheers,
-Paul
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++--
1
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> In the patch ("drm/edid: Allow the querying/working with the panel ID
> from the EDID") we introduced a different way of working with the
> panel ID stored in the EDID. Let's use this new way for the quirks
> code.
>
> Advantages of the new style:
> *
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 18fe19916bc3..4b54a2377821 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char
Hi,
On Tue, Sep 14, 2021 at 11:16 AM Jani Nikula
wrote:
>
> On Thu, 09 Sep 2021, Douglas Anderson wrote:
> > In the patch ("drm/edid: Allow the querying/working with the panel ID
> > from the EDID") we introduced a different way of working with the
> > panel ID stored in the EDID. Let's use this
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> A future change wants to be able to read just block 0 of the EDID, so
> break it out of drm_do_get_edid() into a sub-function.
>
> This is intended to be a no-op change--just code movement.
>
> Signed-off-by: Douglas Anderson
> Acked-by: Sam Ravnborg
On Thu, 09 Sep 2021, Douglas Anderson wrote:
> EDIDs have 32-bits worth of data which is intended to be used to
> uniquely identify the make/model of a panel. This has historically
> been used only internally in the EDID processing code to identify
> quirks with panels.
>
> We'd like to use this p
1 - 100 of 182 matches
Mail list logo
