This series adds gem_pxp tests for the new PXP subsystem currently
being reviewed at https://patchwork.freedesktop.org/series/90504/.
This series currently includes 4 groups of tests addressing the
features and restrictions described by Daniele's series :
1. test i915 interfaces for allocation o
On Mon, May 17, 2021 at 02:57:33PM +0300, Jani Nikula wrote:
On Mon, 12 Apr 2021, Matthew Auld wrote:
From: Anshuman Gupta
Sanitize OPROM header, CPD signature and OPROM PCI version.
OPROM_HEADER, EXPANSION_ROM_HEADER and OPROM_MEU_BLOB structures
and PCI struct offsets are provided by GSC co
PXP (Protected Xe Path) is an i915 component, available on
GEN12 and newer platforms, that helps to establish the hardware
protected session and manage the status of the alive software session,
as well as its life cycle.
changes from v9:
- Patch #3 - change comments from "Gen12+" to "Gen12 and new
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Saturday, September 18, 2021 12:16 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/2] MAINTAINERS
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915. Bisections converge convincingly, but arrive at different
and surprising "culprits", none of them the actual culprit.
netconsole (with init_netconsole() hacked to call i915_init() when
logging has
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915. Bisections converge convincingly, but arrive at different
and surprising "culprits", none of them the actual culprit.
netconsole (with init_netconsole() hacked to call i915_init() when
logging has
On Mon, Apr 12, 2021 at 10:05:20AM +0100, Matthew Auld wrote:
From: Clint Taylor
Read OPROM SPI through MMIO and find VBT entry since we can't use
OpRegion and PCI mapping may not work on some systems due to the BIOS
not leaving the Option ROM mapped.
I was surprised to see we still don't hav
> Can we remove drm_modeset_lock_all[_ctx] now? If so, let's queue that up as
> part
> of the set.
>
drm_modeset_lock_all() and drm_modeset_unlock_all() can be removed (I'll do that
on v2 of this patch series).
drm_modset_lock_all_ctx() is a different story and there are still two places
(one i
> > + struct drm_modeset_acquire_ctx ctx;
> > int r;
> > + int ret;
>
> Relocate ret with r please
Done!
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> You should check ret here
Done!
> > int r;
> > + int ret;
>
> Relocate ret with r
Hi
On Tue, Sep 14, 2021 at 5:57 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-14 16:28:45)
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index 8d3e7a147170..dc349d729f5a 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>
> > int i;
> > + int ret;
>
> Please move up with i
Done!
> > + DRM_MODESET_LOCK_ALL_END((&dev_priv->drm), ctx, ret);
> >
> > return 0;
>
> Return ret here
Done!
> > + struct drm_modeset_acquire_ctx ctx;
> > int i;
> > + int ret;
>
> Please move up with i
Done!
> >
Hi
On Thu, Sep 16, 2021 at 1:31 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Sep 16, 2021 at 1:15 PM Stephen Boyd wrote:
> >
> > > > > + return ret;
> > > > > + }
> > > > > +
> > > > > + /* Assume it's good */
> > > > > + msg->reply = 0;
> > > > > +
> > > > > +
Hi Doug and Stephen,
Thanks for the review.
Before we reach a consensus on the best logging option, I'll just
remove the printouts from this patch and just return PTR_ERR.
Once we reach a consensus, we can probably improve logging in a separate patch.
On Fri, Sep 17, 2021 at 8:02 AM Doug Anderson
Hi Stephen,
Based on the discussion in [1], this patch is not really needed for now.
So I'll just remove this patch from v4.
Thanks.
[1]
https://patchwork.kernel.org/project/dri-devel/patch/20210914162825.v3.2.Ib06997ddd73e2ac29e185f039d85cfa8e760d641@changeid/
On Tue, Sep 14, 2021 at 5:27 PM S
> > int i, out_width;
> > + int ret;
>
> Please put ret with i & out_width
Done!
> > - drm_modeset_unlock_all(crtc->dev);
> > + DRM_MODESET_LOCK_ALL_END(crtc->dev, ctx, ret);
> >
> > return 0;
>
> Return ret here
Done!
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
Signed-off-by: Philip Chen
---
Changes in v4:
- Fix aux_transfer function:
- Replace dev_err with DRM_DEV_ERROR
- Reorg the bit manipulation around address/len/request regist
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Reviewed-by: Douglas Anderson
Signed-off-by: Philip Chen
---
Changes in v4:
- Remove excessive error logging from the probe function
Changes in v3:
- Fix the nits fro
> > - drm_modeset_unlock_all(fb->dev);
> > + DRM_MODESET_LOCK_ALL_END(fb->dev, ctx, ret);
> >
> > return 0;
>
> Return ret here.
Done!
> > int err = 0;
> > + int ret;
>
> You can use err here instead.
Done!
> > + struct drm_modeset_acquire_ctx ctx;
> > int i, r;
> > + int ret;
>
> Could you please tuck this up with i & r?
Done!
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> You should check ret here
Would it be save to return at this point if th
>
> Could you please fix the subject, changing dmr to drm?
>
Ups! Sure, I'll fix that. Thanks for noticing.
>
> I think you can just reuse 'ret' instead of creating a new variable. That
> ensures if the lock fails we return the error from the macros.
>
I didn't reuse "ret" because otherwise
Hi Gurchetan,
>
> Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event
> to the DRM file descriptor when a fence on a specific ring is
> signaled.
>
> One difference is the event is not exposed via the UAPI -- this is
> because host responses are on a shared memory buffer of type
> B
On 21/09/17 05:24PM, Daniel Vetter wrote:
>
> Can we at least replace those with drm_modeset_lock_all_ctx and delete
> drm_modeset_lock_all? That would be really nice goal to make sure these
> don't spread further.
I just checked and turns out no one else is using "drm_modeset_lock_all()"
anymore.
On Thu, Sep 16, 2021 at 11:00:25PM -0700, Stephen Boyd wrote:
> Quoting Sean Paul (2021-09-15 13:38:32)
/snip
> > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > index 2f6247e80e9d..de16fca8782a 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > +++
https://bugzilla.kernel.org/show_bug.cgi?id=211807
--- Comment #8 from Parker Reed (parker.l.r...@gmail.com) ---
Just built 5.15 rc1 (master) and I'm hung up right after bootloader. Maybe
someone else can test that patch. I'll be unable to get back around to this
until next week.
Thanks for the
On Fri, 17 Sep 2021 14:59:42 +0200, Alexandre Bailon wrote:
> This adds the device tree bindings for the APU DRM driver.
>
> Signed-off-by: Alexandre Bailon
> ---
> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 +++
> 1 file changed, 38 insertions(+)
> create mode 100644 Do
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=211807
--- Comment #6 from Parker Reed (parker.l.r...@gmail.com) ---
Created attachment 298867
--> https://bugzilla.kernel.org/attachment.cgi?id=298867&action=edit
dmesg 5.14.5
I can reliably get both 1440p monitors working now with pure DP but only a
On 2021-09-17 1:53 p.m., Zack Rusin wrote:
On some hardware, in particular in virtualized environments, the
system memory can be shared with the "hardware". In those cases
the BO's allocated through the ttm system manager might be
busy during ttm_bo_put which results in them being scheduled
for
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
The atomic state is printed if the DRM_UT_STATE is active, but it's
printed at INFO level. This patch converts it to use the debug
category printer so:
a- it's consistent with other DRM_UT_STATE logging
b- it's properly routed through drm_t
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
This patch adds a new printer which will select the appropriate output
for a given debug category. Currently there is only one output target,
which is syslog. However in the future we'll have tracefs and it will
be
useful to print to syslog
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to
selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Reviewed
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to
selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Reviewed
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
The debug messages shouldn't be logged as errors when debug categories
are enabled. Use the drm logging helpers to do the right thing
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
Link:
https://patchwork.freedesktop.org/patch/msgi
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instanc
By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge()
introduces a circular dependency between the modules drm (where
devm_drm_of_get_bridge() ends up) and drm_kms_helper (where
devm_drm_panel_bridge_add() is).
Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus
On some hardware, in particular in virtualized environments, the
system memory can be shared with the "hardware". In those cases
the BO's allocated through the ttm system manager might be
busy during ttm_bo_put which results in them being scheduled
for a delayed deletion.
The problem is that that
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
Hi all,
I just had the pleasure of rebasing this set on our CrOS downstream
kernel and wanted to resend it for consideration once again. There
hasn't been any resistence to the set AFAIK, just perhaps not enough
motivation for anyone to hit
Sorry about the slow response, this week XDC has been going on and I've been
mostly paying attention to that.
On Tue, 2021-09-14 at 08:46 +, Lin, Wayne wrote:
> [Public]
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Thursday, September 2, 2021 6:00 AM
> > To: Lin, Wayne ; d
On Thu, Sep 16, 2021 at 08:53:50PM -0700, Stephen Boyd wrote:
> Quoting Sean Paul (2021-09-15 13:38:29)
> > From: Sean Paul
> >
> > encoder->commit() was being misused because there were some global
> > resources which needed to be tweaked in encoder->enable() which were not
> > accessible in dpu_
From: Venkata Sandeep Dhanalakota
Support for multiple GT's within a single i915 device will be arriving
soon. Since each GT may have its own fusing and require different
workarounds, we need to make the GT workaround functions and multicast
steering setup per-gt.
Cc: Tvrtko Ursulin
Cc: Daniel
On Fri, Sep 17, 2021 at 06:42:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/17/21 6:25 PM, Ville Syrjälä wrote:
> > On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> >>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de G
On Fri, Sep 17, 2021 at 03:54:23PM +0300, Jani Nikula wrote:
> On Thu, 09 Sep 2021, Jani Nikula wrote:
> > v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
> > and the already merged patches obviously dropped.
> >
> > Jani Nikula (13):
> > drm/dp: add DP 2.0 UHBR link rate
On Fri, Sep 17, 2021 at 11:49:45AM +0800, Kai-Heng Feng wrote:
> On Fri, Sep 17, 2021 at 12:38 AM Bjorn Helgaas wrote:
> >
> > [+cc Huacai, linux-pci]
> >
> > On Wed, May 19, 2021 at 09:57:23PM +0800, Kai-Heng Feng wrote:
> > > Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assume
Hi,
On 9/17/21 6:25 PM, Ville Syrjälä wrote:
> On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
>>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
Add support for eDP panels with a built-in privacy screen usin
On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> > On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> >> Add support for eDP panels with a built-in privacy screen using the
> >> new drm_privacy_screen class.
> >>
> >>
On Fri, Sep 17, 2021 at 6:15 PM Alex Deucher wrote:
>
> Now that the scheduler is being used by more and more
> drivers, we need someone to maintain it. Andrey has
> stepped up to maintain the scheduler.
>
> Cc: Andrey Grodzovsky
> Cc: airl...@gmail.com
> Cc: daniel.vet...@ffwll.ch
> Signed-off-
Now that the scheduler is being used by more and more
drivers, we need someone to maintain it. Andrey has
stepped up to maintain the scheduler.
Cc: Andrey Grodzovsky
Cc: airl...@gmail.com
Cc: daniel.vet...@ffwll.ch
Signed-off-by: Alex Deucher
---
MAINTAINERS | 8
1 file changed, 8 ins
Fix the path to cover both the older powerplay infrastructure
and the newer SwSMU infrastructure.
Signed-off-by: Alex Deucher
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 851255b71ccc..379092f34fff 100644
--- a/MAINTAINER
On Xe_HP and beyond the SFC unit may be fused off, even if the
corresponding media engines are present. Check the SFC-specific fusing
before trying to dump the SFC_DONE instances.
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_gpu_error.c | 6 --
1 file c
Xe_HP adds some new fuse bits to indicate whether an SFC unit is fused
off. We should utilize these when initializing VD/VE SFC access and
also when capturing/dumping SFC_DONE for the error state.
Matt Roper (2):
drm/i915/xehp: Check new fuse bits for SFC availability
drm/i915: Check SFC fusi
Xe_HP adds some new bits to the FUSE1 register to let us know whether a
given SFC unit is present. We should take this into account while
initializing SFC availability to our VCS and VECS engines.
While we're at it, update the FUSE1 register definition to use
REG_GENMASK / REG_FIELD_GET notation.
On Thu, Sep 16, 2021 at 11:15:52PM +0200, Fernando Ramos wrote:
> The previous commits do exactly what this entry in the TODO file asks
> for, thus we can remove it now as it is no longer applicable.
Thanks for doing this work!
Can we remove drm_modeset_lock_all[_ctx] now? If so, let's queue that
On Thu, Sep 16, 2021 at 11:15:51PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/amd/amdgpu/a
On Thu, Sep 16, 2021 at 11:15:50PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/gma500/psb_d
On Thu, Sep 16, 2021 at 11:15:49PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/i915/display
On Thu, Sep 16, 2021 at 11:15:48PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/msm/disp/dpu
On Thu, Sep 16, 2021 at 11:15:47PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/nouveau/disp
On Thu, Sep 16, 2021 at 11:15:46PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/omapdrm/omap
On Thu, Sep 16, 2021 at 11:15:46PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/omapdrm/omap
On Fri, Aug 13, 2021 at 10:53:02PM +0800, Kevin Tang wrote:
> Adds dsi host controller support for the Unisoc's display subsystem.
> Adds dsi phy support for the Unisoc's display subsystem.
> Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> in the feature.
>
> v1:
> - Remove dphy a
On Thu, Sep 16, 2021 at 11:15:45PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/radeon/radeo
On Thu, Sep 16, 2021 at 11:15:44PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:43PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/tegra/dsi.c
On Thu, Sep 16, 2021 at 11:15:42PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
Reviewed-by: Sean Paul
> Signed-off-by: Fernando Ramos
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:41PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:39PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
With the subject fixed (s/dmr/drm),
Reviewed-by
On Thu, Sep 16, 2021 at 11:15:40PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
With the subject fixed (s/dmr/drm/),
Reviewed-b
On Thu, Sep 16, 2021 at 11:15:38PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
Hi Fernando,
Thank you for your patch. Could you
On Thu, Sep 16, 2021 at 11:15:37PM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of chang
Hi,
On Thu, Sep 16, 2021 at 11:12 PM Stephen Boyd wrote:
>
> > > > In the case of devm_regmap_init_i2c(), the driver could be fine but
> > > > you might be trying to instantiate it on a system whose i2c bus lacks
> > > > the needed functionality. That's not a bug in the bridge driver but an
> > >
Hi,
On Fri, Aug 13, 2021 at 10:53:00PM +0800, Kevin Tang wrote:
> Adds DPU(Display Processor Unit) support for the Unisoc's display
> subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> v2:
> - Use drm_xxx to replace all DRM_XXX.
> - Use kzalloc to repl
On Fri, Sep 17, 2021 at 02:35:13PM +0200, Christian König wrote:
> Heureka, that's finally not used any more.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> include/linux/dma-resv.h | 26 --
> 1 file changed, 26 deletions(-)
>
> diff --git a/inc
On Fri, Sep 17, 2021 at 02:35:08PM +0200, Christian König wrote:
> Makes the handling a bit more complex, but avoids the use of
> dma_resv_get_excl_unlocked().
>
> v2: add missing rcu_read_lock()/unlock()
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem_atomic_helper.c | 14 ++
On Fri, Sep 17, 2021 at 02:35:07PM +0200, Christian König wrote:
> Simplifying the code a bit.
>
> v2: add missing rcu_read_lock()/unlock()
>
> Signed-off-by: Christian König
This will be gone as soon as I can land the last conversion patches. Plus
it's always called with dma_resv_lock held.
I
On Fri, Sep 17, 2021 at 02:34:59PM +0200, Christian König wrote:
> Simplifying the code a bit.
>
> v2: use dma_resv_for_each_fence
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 26 ++
> 1 file changed, 6 insertions(+), 20 deletions(-
On Fri, Sep 17, 2021 at 02:34:54PM +0200, Christian König wrote:
> This is probably a fix since we didn't even grabed a reference to the
> fences.
It's rcu protected, and we only care about speeding things up a bit. I
think this wont have any impact on correctness, and I don't think any
driver cou
Hi,
On 9/16/21 8:15 PM, Thomas Zimmermann wrote:
> Add devm_arch_phys_wc_add() and devm_arch_io_reserve_memtype_wc() for
> automatic cleanup of writecombine setup.
>
> Several DRM drivers use the non-managed functions for setting their
> framebuffer memory to write-combine access. Convert ast, mg
On Fri, Sep 17, 2021 at 02:34:53PM +0200, Christian König wrote:
> This makes the function much simpler since the complex
> retry logic is now handled elsewhere.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 56 ++
> 1 file changed, 9
On Fri, Sep 17, 2021 at 02:34:52PM +0200, Christian König wrote:
> This makes the function much simpler since the complex
> retry logic is now handled elsewhere.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 68 ++
> 1 file changed, 1
On Fri, Sep 17, 2021 at 02:34:51PM +0200, Christian König wrote:
> This makes the function much simpler since the complex
> retry logic is now handled elsewhere.
>
> v2: use sizeof(void*) instead
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 112 +--
On Fri, Sep 17 2021, Jason Gunthorpe wrote:
> On Fri, Sep 17, 2021 at 01:59:16PM +0200, Cornelia Huck wrote:
>> >ret = cio_cancel_halt_clear(sch, &iretry);
>> > -
>> >if (ret == -EIO) {
>> >pr_err("vfio_ccw: could not quiesce subchannel
>> > 0.%x.%04x!
Hi,
On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> One thing which stands out here is the addition of these 2 lines to
>> intel_a
Hi, Markus:
Markus Schneider-Pargmann 於 2021年9月17日 週五 下午9:33寫道：
>
> Hi Chun-Kuang,
>
> On Tue, Sep 14, 2021 at 07:25:48AM +0800, Chun-Kuang Hu wrote:
> > Hi, Markus:
> >
> > Markus Schneider-Pargmann 於 2021年9月10日 週五 下午1:36寫道：
> > >
> > > Hi Chun-Kuang,
> > >
> > > On Fri, Sep 10, 2021 at 07:37:5
On Fri, Sep 17, 2021 at 02:34:50PM +0200, 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/dma-buf/dma-resv.c | 86 --
> 1 file changed,
On Fri, Sep 17, 2021 at 03:27:55PM +0200, Daniel Vetter wrote:
> On Fri, Sep 17, 2021 at 02:34:49PM +0200, Christian König wrote:
> > A simpler version of the iterator to be used when the dma_resv object is
> > locked.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/dma-buf/dma-resv.c
Hi,
On 9/16/21 4:04 PM, Ville Syrjälä wrote:
> On Thu, Sep 16, 2021 at 12:40:11PM +0300, Jani Nikula wrote:
>>
>> Cc: Ville for input here, see question inline.
>>
>> On Mon, 06 Sep 2021, Hans de Goede wrote:
>>> Add support for eDP panels with a built-in privacy screen using the
>>> new drm_priv
On 17/09/2021 13:43, Daniel Vetter wrote:
On Wed, Sep 15, 2021 at 12:41:53PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is not very useful to have code which tries to report a rapidly
transient state which will not report anything majority of the time,
especially since it is curren
Hi Chun-Kuang,
On Tue, Sep 14, 2021 at 07:25:48AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年9月10日 週五 下午1:36寫道：
> >
> > Hi Chun-Kuang,
> >
> > On Fri, Sep 10, 2021 at 07:37:50AM +0800, Chun-Kuang Hu wrote:
> > > Hi, Markus:
> > >
> > > Markus Schneider-Pargman
On 17 9月 21 14:15:29, Daniel Thompson wrote:
> On Fri, Sep 17, 2021 at 08:53:23PM +0800, Cai Huoqing wrote:
> > When possible use dev_err_probe help to properly deal with the
> > PROBE_DEFER error, the benefit is that DEFER issue will be logged
> > in the devices_deferred debugfs file.
> > Using de
On Fri, Sep 17, 2021 at 02:34:49PM +0200, Christian König wrote:
> A simpler version of the iterator to be used when the dma_resv object is
> locked.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 33 +
> include/linux/dma-resv.h | 17 ++
On Fri, Sep 17, 2021 at 02:34:48PM +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.
>
> v2: fix accessi
On Fri, Sep 17, 2021 at 08:53:23PM +0800, Cai Huoqing wrote:
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> Using dev_err_probe() can reduce code size, and the error value
On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
>
> > > For merge logistics, can we pls have a stable branch? I expect that the
> > > i915 patches will be ready for 5.16.
> > >
> > > Or send it in for -rc2 so that
On Thu, Sep 09, 2021 at 03:51:57PM +0300, Jani Nikula wrote:
> Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register
> conflicts with FDI. Since we have to deal with both meanings in the same
> code, for different platforms, clarify the macro name so we don't
> forget.
>
> Bspec:
On Thu, 09 Sep 2021, Jani Nikula wrote:
> v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
> and the already merged patches obviously dropped.
>
> Jani Nikula (13):
> drm/dp: add DP 2.0 UHBR link rate and bw code conversions
> drm/dp: use more of the extended receiver ca
On Thu, Sep 09, 2021 at 03:52:04PM +0300, Jani Nikula wrote:
> There's a new register pair for 128b/132b mode where you need to set the
> pixel clock in Hz.
>
> v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper
>
> Bspec: 54128
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> --
When possible use dev_err_probe help to properly deal with the
PROBE_DEFER error, the benefit is that DEFER issue will be logged
in the devices_deferred debugfs file.
Using dev_err_probe() can reduce code size, and the error value
gets printed.
Signed-off-by: Cai Huoqing
---
v1->v2: backlight pat
On Wed, 15 Sep 2021, Sean Paul wrote:
> From: Sean Paul
>
> Hello again,
> This is the second version of the HDCP helper patchset. See version 1
> here: https://patchwork.freedesktop.org/series/94623/
>
> In this second version, I've fixed up the oopsies exposed by 0-day and
> yamllint and incorp
On Thu, Sep 09, 2021 at 03:52:03PM +0300, Jani Nikula wrote:
> 128b/132b has a separate transcoder DDI mode, which also requires the
> MST transport select to be set. Note that we'll use DP MST also for
> single-stream 128b/132b.
>
> Having the FDI and 128b/132b modes share the register mode value
1 - 100 of 153 matches
Mail list logo
