On Tue, 12 Sep 2023 18:20:32 +0200
Thomas Hellström wrote:
> > +/**
> > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > + * @__gpuvm: The GPU VM
> > + * @__list_name: The name of the list we're iterating on
> > + * @__local_list: A pointer to the local list used to store already
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 18:20:32 +0200
> Thomas Hellström wrote:
>
> > > +/**
> > > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > > + * @__gpuvm: The GPU VM
> > > + * @__list_name: The name of the list we're iterating on
> >
On Wed, 13 Sep 2023 17:05:42 +1000
Dave Airlie wrote:
> On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 18:20:32 +0200
> > Thomas Hellström wrote:
> >
> > > > +/**
> > > > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > > > + * @__gpuvm: The
* Andreas Kemnade [230913 06:59]:
> Some 3.0 source has it set behind a if (omap4).
> Maybe it is helpful maybe not, at least in the omap4460
> trm these bits are marked as reserved.
> But maybe some dsi video mode panel starts magically working.
Interesting. So Andreas mentioned that dsi video m
Some 3.0 source has it set behind a if (omap4).
Maybe it is helpful maybe not, at least in the omap4460
trm these bits are marked as reserved.
But maybe some dsi video mode panel starts magically working.
Signed-off-by: Andreas Kemnade
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed
On Tue, 12 Sep 2023 19:14:35 -0700
Rob Clark wrote:
> On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> >
> > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > wrote:
> > >
> > > On Tue, 12 Sep 2023 09:37:00 +0100
> > > Adrián Larumbe wrote:
> > >
> > > > The current implementation will
* Laurent Pinchart [230412 11:59]:
> On Wed, Apr 12, 2023 at 11:55:34AM +0300, Tomi Valkeinen wrote:
> > On 12/04/2023 11:50, Laurent Pinchart wrote:
> > > Hi Tony,
> > >
> > > Thank you for the patch.
> > >
> > > On Wed, Apr 12, 2023 at 10:39:53AM +0300, Tony Lindgren wrote:
> > >> We may not h
On Wed, 13 Sep 2023 03:56:14 +0300
Dmitry Osipenko wrote:
> On 9/5/23 11:03, Boris Brezillon wrote:
> >>* But
> >> + * acquiring the obj lock in
> >> drm_gem_shmem_release_pages_locked() can
> >> + * cause a locking order inversion between
> >> reservation_ww
On Thu, Aug 31, 2023 at 3:12 PM Fei Shao wrote:
>
> On Tue, Aug 22, 2023 at 10:27 PM Jason-JH.Lin
> wrote:
> >
> > Add spinlock protection to avoid race condition on vblank event
> > between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip().
> >
> > Fixes: 119f5173628a ("drm/mediatek: A
Hi Thomas,
On Tue, Sep 12, 2023 at 5:32 PM Thomas Zimmermann wrote:
> Rename the fbdev mmap helper fb_pgprotect() to pgprot_framebuffer(
> The helper sets VMA page-access flags for framebuffers in device I/O
> memory.
>
> Also clean up the helper's parameters and return value. Instead of
> the VM
On 12/09/2023 17:57, Michel Dänzer wrote:
On 9/11/23 10:38, Pekka Paalanen wrote:
On Fri, 8 Sep 2023 17:10:46 +0200
Thomas Zimmermann wrote:
Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
On Fri, 8 Sep 2023 15:56:51 +0200
Thomas Zimmermann wrote:
I have a number of concerns. My point it not
On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> preempt disable section over the hardware reset callback to prepare the
> driver for being able to reset from atomic contexts.
…
This missed the
Move the check for "if (IS_ERR(obj))" in front of the call to
i915_gem_object_set_cache_coherency() which dereferences "obj".
Otherwise it will lead to a crash.
Fixes: 43aa755eae2c ("drm/i915/mtl: Update cache coherency setting for context
structure")
Signed-off-by: Dan Carpenter
---
drivers/gp
Am 12.09.23 um 16:58 schrieb Nicolas Dufresne:
Le mardi 12 septembre 2023 à 16:46 +0200, Christian König a écrit :
Am 12.09.23 um 10:52 schrieb Yong Wu (吴勇):
[SNIP]
But what we should try to avoid is that newly merged drivers provide
both a driver specific UAPI and DMA-heaps. The justification
Il 22/08/23 15:26, Jason-JH.Lin ha scritto:
Add spinlock protection to avoid race condition on vblank event
between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip().
Hello Jason,
Can you please provide more information about this race condition?
(check below)
Fixes: 119f5173628a (
On 13/09/2023 10:39, Moudy Ho (何宗原) wrote:
>>> @@ -63,7 +64,6 @@ properties:
>>> required:
>>>- compatible
>>>- reg
>>> - - interrupts
>>
>> Why? commit msg tells nothing about it. Why interrupt is not erquired
>> in
>> mt8173? How dropping such requirement is anyhow related to mt8195?
>
Hi Dan,
On Wed, Sep 13, 2023 at 11:17:41AM +0300, Dan Carpenter wrote:
> Move the check for "if (IS_ERR(obj))" in front of the call to
> i915_gem_object_set_cache_coherency() which dereferences "obj".
> Otherwise it will lead to a crash.
>
> Fixes: 43aa755eae2c ("drm/i915/mtl: Update cache cohere
On Wed, Sep 13, 2023 at 11:09:39AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/mediatek/mtk_dpi.c
>
> between commits:
>
> 47d4bb6bbcdb ("drm/mediatek: mtk_dpi: Simplify with devm_drm_bridge_add()")
> 90c95c3892dd ("
Hi!
On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote:
> On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote:
> >
> > On 9/12/23 18:50, Danilo Krummrich wrote:
> > > On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote:
> > > > Hi, Danilo,
> > > >
> > > > On 9/9/
Hi Dmitry,
On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> On 12/09/2023 14:05, Heikki Krogerus wrote:
> > On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
> > > On 06/09/2023 16:38, Heikki Krogerus wrote:
> > > > On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitr
Hi everyone,
gentle ping - is there any feedback you can give me for moving this series
forward?
Best regards
Johannes
On 7/28/23 16:16, Johannes Zink wrote:
Some LVDS panels, such as the innolux,g101ice-l01 support multiple LVDS
data mapping modes, which can be configured by strapping a data
On 12/09/2023 19:39, Dmitry Baryshkov wrote:
On 12/09/2023 14:05, Heikki Krogerus wrote:
On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
On 06/09/2023 16:38, Heikki Krogerus wrote:
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
On Wed, 6 Sept 2023 at 15:44
Hi,
On Wed, Sep 13, 2023 at 11:32:23AM +0300, José Pekkarinen wrote:
> Running drm_exec_test by modprobing the module I
> observe the following output:
>
> [ 424.471936] KTAP version 1
> [ 424.471942] 1..1
> [ 424.472446] KTAP version 1
> [ 424.472450] # Subtest: drm_exec
> [ 424.472
Hi Heikki,
On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
wrote:
> On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > On 12/09/2023 14:05, Heikki Krogerus wrote:
> > > On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
> > > > On 06/09/2023 16:38, Heikki Krogerus
Hi Neil,
On Wed, Sep 13, 2023 at 11:38:19AM +0200, Neil Armstrong wrote:
> On new platforms (starting from SM8450) UCSI is mandatory to have
> pmic_glink_altmode events triggering.
You can also populate the typec devices conditionally, only if UCSI is
not supported.
However, I took a peek at dri
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Dave Airlie wrote:
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
On Tue, 12 Sep 2023 18:20:32 +0200
Thomas Hellström wrote:
+/**
+ * get_next_vm_bo_from_list() - get the next vm_bo element
+ * @__gp
On Fri, Aug 18, 2023 at 09:04:34AM +0200, Johannes Zink wrote:
> Hi Dan,
>
> do you have any input on this for me?
>
Sorry, I was out of office and the truth is that I'm never going to
catch up on all the email I missed. :/
Looks okay to me. I can't remember what I said about this code in v3
Hi Dan,
On 9/13/23 13:14, Dan Carpenter wrote:
On Fri, Aug 18, 2023 at 09:04:34AM +0200, Johannes Zink wrote:
Hi Dan,
do you have any input on this for me?
Sorry, I was out of office and the truth is that I'm never going to
catch up on all the email I missed. :/
nevermind, that's why I
On Tue, Sep 5, 2023 at 3:28 PM Stanislaw Gruszka
wrote:
>
> On Mon, Sep 04, 2023 at 09:18:36PM +0200, Christophe JAILLET wrote:
> > snprintf() returns the "number of characters which *would* be generated for
> > the given input", not the size *really* generated.
> >
> > In order to avoid too large
On Fri, 8 Sep 2023 11:02:26 -0400
Harry Wentland wrote:
> Signed-off-by: Harry Wentland
> Cc: Ville Syrjala
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Cc: Harry Wentland
> Cc: Melissa Wen
> Cc: Jonas Ådahl
> Cc: Sebastian Wick
> Cc: Shashank Sharma
> Cc: Alexander Goins
> Cc: Joshua Ashton
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
> Hi,
>
> On 9/13/23 09:19, Boris Brezillon wrote:
> > On Wed, 13 Sep 2023 17:05:42 +1000
> > Dave Airlie wrote:
> >
> >> On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
> >> wrote:
> >>> On Tue, 12 Sep 2023 18:20:32 +0200
> >>> Tho
On Fri, 8 Sep 2023 16:38:44 -0400
Harry Wentland wrote:
> On 2023-09-08 15:30, Sebastian Wick wrote:
> > Hey Harry,
> >
> > Thank you and Simon for this great document. Really happy about it, but
> > obviously I've got a few notes and questions inline.
> >
> > On Fri, Sep 08, 2023 at 11:02:26AM
On 12/04/2023 10:39, Tony Lindgren wrote:
We may not have dsi->dsidev initialized during probe, and that can
lead into various dsi related warnings as omap_dsi_host_detach() gets
called with dsi->dsidev set to NULL.
The warnings can be "Fixed dependency cycle(s)" followed by a
WARNING: CPU: 0 PI
After some more discussion with Boris on IRC, he seems to be willing to drop
GPUVM
updates from the async path. If everyone agrees I'm fine to go ahead and drop
this
use case for GPUVM.
@Thomas: I will reply to your last mail only considering GPUVM updates from
within
the IOCTL.
- Danilo
On
On 13/09/2023 10:37, Tony Lindgren wrote:
* Laurent Pinchart [230412 11:59]:
On Wed, Apr 12, 2023 at 11:55:34AM +0300, Tomi Valkeinen wrote:
On 12/04/2023 11:50, Laurent Pinchart wrote:
Hi Tony,
Thank you for the patch.
On Wed, Apr 12, 2023 at 10:39:53AM +0300, Tony Lindgren wrote:
We may
On 13/09/2023 09:59, Andreas Kemnade wrote:
Some 3.0 source has it set behind a if (omap4).
Maybe it is helpful maybe not, at least in the omap4460
trm these bits are marked as reserved.
But maybe some dsi video mode panel starts magically working.
Sorry, what does this mean? That this fixes so
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than GPUVM updates from the IOCTL.
On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote:
> Hi!
>
> On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote:
> > On Tue, S
On Tue, Aug 29, 2023 at 02:39:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc for all output types that don't already
> do so, and clean up a bunch of code as a result of having the
> ddc i2c adapter in easy reach. And this also provides the sysfs
> "ddc" symlin
Hi Matthew,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.6-rc1
next-20230913]
[cannot apply to drm-misc/drm-misc-next drm
* Tomi Valkeinen [230913 12:11]:
> I'm somewhat sure that the upstream driver used to work on omap4 sdp, which
> has two DSI panels. But I can't even remember what omap4 version it had.
I think those were both dsi command mode panels though, not video mode?
Regards,
Tony
* Tomi Valkeinen [230913 11:59]:
> On 12/04/2023 10:39, Tony Lindgren wrote:
> > We may not have dsi->dsidev initialized during probe, and that can
> > lead into various dsi related warnings as omap_dsi_host_detach() gets
> > called with dsi->dsidev set to NULL.
> >
> > The warnings can be "Fixed
On 25/08/2023 02:56, Dmitry Baryshkov wrote:
Note, numbering for this series starts from v5, since there were several
revisions for this patchset under a different series title ([1]).
USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the
On 13/09/2023 15:48, Tony Lindgren wrote:
* Tomi Valkeinen [230913 12:11]:
I'm somewhat sure that the upstream driver used to work on omap4 sdp, which
has two DSI panels. But I can't even remember what omap4 version it had.
I think those were both dsi command mode panels though, not video mod
https://bugzilla.kernel.org/show_bug.cgi?id=213983
Cyp (cyp...@gmail.com) changed:
What|Removed |Added
CC||cyp...@gmail.com
--- Comment #8
On Wed, Sep 13, 2023 at 01:26:14PM +0300, Dmitry Baryshkov wrote:
> Hi Heikki,
>
> On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
> wrote:
> > On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > > On 12/09/2023 14:05, Heikki Krogerus wrote:
> > > > On Tue, Sep 12, 2023 at 12:15:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Dave Airlie wrote:
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
On Tue, 12 Sep 2023 18:20:32 +
c drm-misc-next
patch link:
https://lore.kernel.org/r/20230911023038.30649-6-yong.wu%40mediatek.com
patch subject: [PATCH 5/9] dma-buf: heaps: mtk_sec_heap: Initialise tee session
config: loongarch-allmodconfig
(https://download.01.org/0day-ci/archive/20230913/202309132148.uabrshab-...@intel.
On Wed, 13 Sept 2023 at 16:15, Heikki Krogerus
wrote:
>
> On Wed, Sep 13, 2023 at 01:26:14PM +0300, Dmitry Baryshkov wrote:
> > Hi Heikki,
> >
> > On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
> > wrote:
> > > On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > > > On 12/09/202
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
> On 9/13/23 13:33, Boris Brezillon wrote:
> > On Wed, 13 Sep 2023 12:39:01 +0200
> > Thomas Hellström wrote:
> >
> >> Hi,
> >>
> >> On 9/13/23 09:19, Boris Brezillon wrote:
> >>> On Wed, 13 Sep 2023 17:05:42 +1000
> >>> Dave Airlie
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is incorrect.
Vulkan is just once specific use case, but this here sh
On 9/13/23 16:01, Boris Brezillon wrote:
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Dave
On Thu, May 25, 2023 at 12:51:28PM +0300, Luca Coelho wrote:
> On Wed, 2023-05-03 at 14:36 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Track DP enhanced framing properly in the crtc state instead
> > of relying just on the cached DPCD everywhere, and hook it
> > up into the state
On Wed, Sep 13, 2023 at 05:01:40PM +0300, José Pekkarinen wrote:
> On 2023-09-13 12:50, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Sep 13, 2023 at 11:32:23AM +0300, José Pekkarinen wrote:
> > > Running drm_exec_test by modprobing the module I
> > > observe the following output:
> > >
> > > [ 4
On Thu, May 25, 2023 at 11:09:30AM +0300, Luca Coelho wrote:
> On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > ICL doesn't support FEC with a x1 DP link. Make sure
> > we don't try to enable FEC in such cases.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
On Wed, Sep 13, 2023 at 03:19:00PM +0300, José Pekkarinen wrote:
> Similarly to the drm_exec_test module, the drm_modes_test
> shows the following output on dmesg on load:
>
> [ 5556.674834] KTAP version 1
> [ 5556.674841] 1..1
> [ 5556.675317] KTAP version 1
> [ 5556.675321] # Subtest: dr
hi, Arvind Yadav,
we know this commit is quite old, but it shows persistent low rate issue and
parent keeps clean even when we run both this commit and parent up to ~300
times.
the config to build both kernel is a randconfig as in
https://download.01.org/0day-ci/archive/20230913
On 11/09/23 03:46, Matthew Auld wrote:
On 09/09/2023 17:09, Arunpravin Paneer Selvam wrote:
Problem statement: The current method roundup_power_of_two()
to allocate contiguous address triggers -ENOSPC in some cases
even though we have enough free spaces and so to help with
that we introduce a
Move functions within intel_fbdev.c to simplify later updates. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 154 ++---
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb
Convert i915's fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups.
As with most other driver's fbdev emulation, fbdev in i915 is now
just another DRM client that runs after the DRM device has been
registered. This allows to remove
Initialize i915's fbdev client by giving an instance of struct
drm_client_funcs to drm_client_init(). Also clean up with
drm_client_release().
Doing this in i915 prevents fbdev helpers from initializing and
releasing the client internally (see drm_fb_helper_init()). No
functional change yet; the c
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display.
The DRM core calls both, the old callbacks and the new client
helpers, from the same places. The new functions perform
Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to i915_fbdev_setup() after i915 has registered its
DRM device. Just like similar code in other drivers, i915 fbdev
emulation now acts as a regular DRM client.
Am 12.09.23 um 04:16 schrieb Matthew Brost:
Provide documentation to guide in ways to teardown an entity.
Signed-off-by: Matthew Brost
---
Documentation/gpu/drm-mm.rst | 6 ++
drivers/gpu/drm/scheduler/sched_entity.c | 19 +++
2 files changed, 25 insertions(
Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
It looks like this locking pattern remains as of 6.6-rc1. Please fix.
void drm_crtc_vblank_off(struct drm_crtc *crtc) {
spin_lock_irq(&dev->event_lock);
drm_vblank_disable_and_save(dev, pipe) {
__disable_vblank(dev, pipe) {
cr
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is incorrect.
Well, more p
On Wed, 13 Sep 2023 16:29:30 +0200
Thomas Hellström wrote:
> On 9/13/23 16:01, Boris Brezillon wrote:
> > On Wed, 13 Sep 2023 15:22:56 +0200
> > Thomas Hellström wrote:
> >
> >> On 9/13/23 13:33, Boris Brezillon wrote:
> >>> On Wed, 13 Sep 2023 12:39:01 +0200
> >>> Thomas Hellström wrote:
>
Hi Christian
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is incorrect.
Am 13.09.23 um 17:13 schrieb Thomas Hellström:
Hi Christian
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the IOC
Am 13.09.23 um 17:15 schrieb Danilo Krummrich:
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think
Hi,
On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote:
>
> Hi,
>
> On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle)
> wrote:
> >
> > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > > Based on grepping through the source code this driver appears to be
> > > missing a ca
On 9/13/23 17:33, Christian König wrote:
Am 13.09.23 um 17:15 schrieb Danilo Krummrich:
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Nathan Chancellor
yload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
Hi,
On Wed, Sep 6, 2023 at 1:39 AM Maxime Ripard wrote:
>
> On Tue, Sep 05, 2023 at 01:16:08PM -0700, Doug Anderson wrote:
> > > > ---
> > > > This commit is only compile-time tested.
> > > >
> > > > NOTE: this patch touches a lot more than other similar patches since
> > > > the bind() function
Hi,
On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson wrote:
>
> Paul,
>
> On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil wrote:
> >
> > Hi Douglas,
> >
> > Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a écrit :
> > > Based on grepping through the source code this driver appears to be
Hi,
This is an update of previous RFC [0] improving the data collection of
Gamma Correction and Blend Gamma color blocks.
As I mentioned in the last version, I'm updating the color state part of
DTN log to match DCN3.0 HW better. Currently, the DTN log considers the
DCN10 color pipeline, which is
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dc
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
rfc-v2:
- detail RAM mode for gamcor and blnd gamma blocks
Signed-off-by: Melissa Wen
---
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git a/d
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 19:14:35 -0700
> Rob Clark wrote:
>
> > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > >
> > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > wrote:
> > > >
> > > > On Tue, 12 Sep 2023 09:37:00 +0100
>
On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
wrote:
>
> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>
> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
> spin_lock_irq(&dev->event_lock);
> drm_vblank_disable
r, mst_state, old_payload,
new_payload);
+new_payload, &old_payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitia
On Wed, 13 Sep 2023 15:11:08 +0300
Tomi Valkeinen wrote:
> On 13/09/2023 09:59, Andreas Kemnade wrote:
> > Some 3.0 source has it set behind a if (omap4).
> > Maybe it is helpful maybe not, at least in the omap4460
> > trm these bits are marked as reserved.
> > But maybe some dsi video mode panel
On 9/13/23 10:14, Jocelyn Falempe wrote:
> On 12/09/2023 17:57, Michel Dänzer wrote:
>> On 9/11/23 10:38, Pekka Paalanen wrote:
>>> On Fri, 8 Sep 2023 17:10:46 +0200
>>> Thomas Zimmermann wrote:
Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
> On Fri, 8 Sep 2023 15:56:51 +0200
> Thomas
On Wed, 13 Sept 2023 at 18:48, Sebastian Andrzej Siewior
wrote:
>
> On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> > preempt disable section over the hardware reset callback to prepare t
On Wed, 13 Sep 2023 09:46:45 -0700
Rob Clark wrote:
> On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 19:14:35 -0700
> > Rob Clark wrote:
> >
> > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > > >
> > > > On Tue, Sep 12, 2023 at 2:32 AM Boris B
Hi Doug,
Le mercredi 13 septembre 2023 à 09:25 -0700, Doug Anderson a écrit :
> Hi,
>
> On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson
> wrote:
> >
> > Paul,
> >
> > On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil
> > wrote:
> > >
> > > Hi Douglas,
> > >
> > > Le vendredi 01 septembre 2023 à 16:
Hi,
On Wed, Sep 6, 2023 at 7:28 AM Douglas Anderson wrote:
>
> As per the discussion on the lists [1], changes to this driver
> generally flow through drm-misc. If they need to be coordinated with
> v4l2 they sometimes go through Philipp Zabel's tree instead. List both
> trees in MAINTAINERS. Als
Hi,
On Tue, Sep 5, 2023 at 2:14 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 4, 2023 at 12:55 AM Maxime Ripard wrote:
> >
> > On Fri, 1 Sep 2023 16:39:52 -0700, Douglas Anderson wrote:
> > > As with other places in the Linux kernel--kfree(NULL) being the most
> > > famous example--it's conven
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if s
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if s
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if s
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly powere
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that
Hi,
On Thu, Sep 7, 2023 at 7:15 AM Maxime Ripard wrote:
>
> > a) Block landing the change to "panel-tdo-tl070wsh30.c" until after
> > all drivers properly call drm_atomic_helper_shutdown().
>
> I don't think we care about all drivers here. Only the driver it's
> enabled with would be a blocker. L
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
>
> NOTE: in order to avoid email sending limits on the cover letter, I've
> split this patch series in two. Patches that target drm-misc and ones
> that don't. The cover letter of the two is identical other than this note.
>
> This pat
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-ini
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-ini
1 - 100 of 151 matches
Mail list logo
