Re: [PATCH v2 5/9] docs: move nommu-mmap.txt to admin-guide and rename to ReST
On Tue, Jun 23, 2020 at 11:52:58AM +0200, Mauro Carvalho Chehab wrote:
> The nommu-mmap.txt file provides description of user visible
> behaviuour. So, move it to the admin-guide.
>
> As it is already at the ReST, also rename it.
>
> Suggested-by: Mike Rapoport
> Suggested-by: Jonathan Corbet
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Mike Rapoport
> ---
> Documentation/admin-guide/mm/index.rst | 1 +
> Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} | 0
> Documentation/admin-guide/sysctl/vm.rst | 2 +-
> Documentation/gpu/drm-mm.rst| 2 +-
> init/Kconfig| 2 +-
> mm/Kconfig | 2 +-
> mm/nommu.c | 2 +-
> 7 files changed, 6 insertions(+), 5 deletions(-)
> rename Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} (100%)
>
> diff --git a/Documentation/admin-guide/mm/index.rst
> b/Documentation/admin-guide/mm/index.rst
> index 11db46448354..774dad6d3d29 100644
> --- a/Documentation/admin-guide/mm/index.rst
> +++ b/Documentation/admin-guide/mm/index.rst
> @@ -31,6 +31,7 @@ the Linux memory management.
> idle_page_tracking
> ksm
> memory-hotplug
> + nommu-map
> numa_memory_policy
> numaperf
> pagemap
> diff --git a/Documentation/nommu-mmap.txt
> b/Documentation/admin-guide/mm/nommu-mmap.rst
> similarity index 100%
> rename from Documentation/nommu-mmap.txt
> rename to Documentation/admin-guide/mm/nommu-mmap.rst
> diff --git a/Documentation/admin-guide/sysctl/vm.rst
> b/Documentation/admin-guide/sysctl/vm.rst
> index 4b7c496199ca..4b9d2e8e9142 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -598,7 +598,7 @@ trimming of allocations is initiated.
>
> The default value is 1.
>
> -See Documentation/nommu-mmap.txt for more information.
> +See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
>
>
> numa_zonelist_order
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 8d10e6b38918..9abee1589c1e 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -311,7 +311,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill
> the struct
> a pointer on drm_gem_cma_get_unmapped_area().
>
> More detailed information about get_unmapped_area can be found in
> -Documentation/nommu-mmap.txt
> +Documentation/admin-guide/mm/nommu-mmap.rst
>
> Memory Coherency
>
> diff --git a/init/Kconfig b/init/Kconfig
> index a46aa8f3174d..2dd5531dae98 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1957,7 +1957,7 @@ config MMAP_ALLOW_UNINITIALIZED
> userspace. Since that isn't generally a problem on no-MMU systems,
> it is normally safe to say Y here.
>
> - See Documentation/nommu-mmap.txt for more information.
> + See Documentation/mm/nommu-mmap.rst for more information.
>
> config SYSTEM_DATA_VERIFICATION
> def_bool n
> diff --git a/mm/Kconfig b/mm/Kconfig
> index f2104cc0d35c..d41f3fa7e923 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -387,7 +387,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
> This option specifies the initial value of this option. The default
> of 1 says that all excess pages should be trimmed.
>
> - See Documentation/nommu-mmap.txt for more information.
> + See Documentation/mm/nommu-mmap.rst for more information.
>
> config TRANSPARENT_HUGEPAGE
> bool "Transparent Hugepage Support"
> diff --git a/mm/nommu.c b/mm/nommu.c
> index f32a69095d50..314174817b04 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -5,7 +5,7 @@
> * Replacement code for mm functions to support CPU's that don't
> * have any form of memory management unit (thus no virtual memory).
> *
> - * See Documentation/nommu-mmap.txt
> + * See Documentation/mm/nommu-mmap.rst
> *
> * Copyright (c) 2004-2008 David Howells
> * Copyright (c) 2000-2003 David McCullough
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/3] drm: Introduce epoch counter to drm_connector
From: Stanislav Lisovskiy
This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for example hotplug event.
Also now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v2: Added documentation for the new counter. Rename change_counter to
epoch_counter.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105540
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_connector.c| 16 +
drivers/gpu/drm/drm_edid.c | 6 -
drivers/gpu/drm/drm_probe_helper.c | 38 ++
include/drm/drm_connector.h| 2 ++
4 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b7bd46033807..332686297e45 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -269,6 +269,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(&connector->modes);
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
+ connector->epoch_counter = 0;
connector->tile_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
@@ -1979,6 +1980,7 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
struct drm_device *dev = connector->dev;
size_t size = 0;
int ret;
+ const struct edid *old_edid;
/* ignore requests to set edid when overridden */
if (connector->override_edid)
@@ -2002,6 +2004,20 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
drm_update_tile_info(connector, edid);
+ if (connector->edid_blob_ptr) {
+ old_edid = (const struct edid *)connector->edid_blob_ptr->data;
+ if (old_edid) {
+ if (!drm_edid_are_equal(edid, old_edid)) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
changed.\n",
+ connector->base.id, connector->name);
+
+ connector->epoch_counter += 1;
+ DRM_DEBUG_KMS("Updating change counter to
%llu\n",
+ connector->epoch_counter);
+ }
+ }
+ }
+
drm_object_property_set_value(&connector->base,
dev->mode_config.non_desktop_property,
connector->display_info.non_desktop);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 34cabfddcdd3..d029cbd5d037 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2050,13 +2050,17 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
+ struct edid *edid;
+
if (connector->force == DRM_FORCE_OFF)
return NULL;
if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
return NULL;
- return drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
+ edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
+ drm_connector_update_edid_property(connector, edid);
+ return edid;
}
EXPORT_SYMBOL(drm_get_edid);
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 26e997f1524f..1d5f319d6213 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -290,6 +290,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
*connector, bool force)
if (WARN_ON(ret < 0))
ret = connector_status_unknown;
+ if (ret != connector->status)
+ connector->epoch_counter += 1;
+
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
@@ -323,11 +326,16 @@ drm_helper_probe_detect(struct drm_connector *connector,
return ret;
if (funcs->detect_ctx)
- return funcs->detect_ctx(connector, ctx, force);
+ ret = funcs->detect_ctx(connector, ctx, force);
else if (connector->funcs->detect)
- return connector->funcs->detect(connector, force);
+ ret = connector->funcs->detect(connector, force);
else
- return connector_status_connected;
+ ret = connector_status_connected;
+
+ if (ret != co
Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> > >
> > > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > > > to use to keep the excessive caches in check). For mmu notifier
> > > > recursions we do have lockdep annotations since 23b68395c7c7
> > > > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> > > >
> > > > But these only fire if a path actually results in some pte
> > > > invalidation - for most small allocations that's very rarely the case.
> > > > The other trouble is that pte invalidation can happen any time when
> > > > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > > > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > > > recursion.
> > > >
> > > > I was pondering whether we should just do the general annotation, but
> > > > there's always the risk for false positives. Plus I'm assuming that
> > > > the core fs and io code is a lot better reviewed and tested than
> > > > random mmu notifier code in drivers. Hence why I decide to only
> > > > annotate for that specific case.
> > > >
> > > > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > > > still need to explicit pull in the mmu notifier map - there's a lot
> > > > more places that do pte invalidation than just direct reclaim, these
> > > > two contexts arent the same.
> > > >
> > > > Note that the mmu notifiers needing their own independent lockdep map
> > > > is also the reason we can't hold them from fs_reclaim_acquire to
> > > > fs_reclaim_release - it would nest with the acquistion in the pte
> > > > invalidation code, causing a lockdep splat. And we can't remove the
> > > > annotations from pte invalidation and all the other places since
> > > > they're called from many other places than page reclaim. Hence we can
> > > > only do the equivalent of might_lock, but on the raw lockdep map.
> > > >
> > > > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > > > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > > > strictly more powerful.
> > > >
> > > > v2: Review from Thomas Hellstrom:
> > > > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > > > but it didn't blow up because I inverted it immediately
> > > > - fix compiling for !CONFIG_MMU_NOTIFIER
> > > >
> > > > Cc: Thomas Hellström (Intel)
> > > > Cc: Andrew Morton
> > > > Cc: Jason Gunthorpe
> > > > Cc: linux...@kvack.org
> > > > Cc: linux-r...@vger.kernel.org
> > > > Cc: Maarten Lankhorst
> > > > Cc: Christian König
> > > > Signed-off-by: Daniel Vetter
> > >
> > > Replying the right patch here...
> > >
> > > Reverting this commit [1] fixed the lockdep warning below while applying
> > > some memory pressure.
> > >
> > > [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in
> > > fs_reclaim_acquire/release")
> >
> > Hm, then I'm confused because
> > - there's not mmut notifier lockdep map in the splat at a..
> > - the patch is supposed to not change anything for fs_reclaim (but the
> > interim version got that wrong)
> > - looking at the paths it's kmalloc vs kswapd, both places I totally
> > expect fs_reflaim to be used.
> >
> > But you're claiming reverting this prevents the lockdep splat. If
> > that's right, then my reasoning above is broken somewhere. Someone
> > less blind than me having an idea?
> >
> > Aside this is the first email I've typed, until I realized the first
> > report was against the broken patch and that looked like a much more
> > reasonable explanation (but didn't quite match up with the code
> > paths).
>
> Below diff should undo the functional change in my patch. Can you pls test
> whether the lockdep splat is really gone with that? Might need a lot of
> testing and memory pressure to be sure, since all these reclaim paths
> aren't very deterministic.
No, this patch does not help but reverting the whole patch still fixed
the splat.
> -Daniel
>
> ---
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d807587c9ae6..27ea763c6155 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4191,11 +4191,6 @@ void fs_reclaim_acquire(gfp_t gfp_mask)
> if (gfp_mask & __GFP_FS)
> __fs_reclaim_acquire();
>
> -#ifdef CONFIG_MMU_NOTIFIER
> - lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> - lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> -#endif
> -
> }
> }
> EXPORT_SYMBOL_GPL(fs_reclaim_acquire);
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
[PATCH v6 3/3] drm/i915: Send hotplug event if edid had changed
From: Stanislav Lisovskiy
Added epoch counter checking to intel_encoder_hotplug
in order to be able process all the connector changes,
besides connection status. Also now any change in connector
would result in epoch counter change, so no multiple checks
are needed.
v2: Renamed change counter to epoch counter. Fixed type name.
v3: Fixed rebase conflict
v4: Remove duplicate drm_edid_equal checks from hdmi and dp,
lets use only once edid property is getting updated and
increment epoch counter from there.
Also lets now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v5: Fixed const modifiers, removed blank line
v6: Removed drm specific part from this patch, leaving only
i915 specific changes here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 26 +++-
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 2e94c1413c02..393813494523 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -283,6 +283,8 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
{
struct drm_device *dev = connector->base.dev;
enum drm_connector_status old_status;
+u64 old_epoch_counter;
+bool ret = false;
drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
old_status = connector->base.status;
@@ -290,17 +292,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
connector->base.status =
drm_helper_probe_detect(&connector->base, NULL, false);
- if (old_status == connector->base.status)
- return INTEL_HOTPLUG_UNCHANGED;
-
- drm_dbg_kms(&to_i915(dev)->drm,
- "[CONNECTOR:%d:%s] status updated from %s to %s\n",
- connector->base.base.id,
- connector->base.name,
- drm_get_connector_status_name(old_status),
- drm_get_connector_status_name(connector->base.status));
-
- return INTEL_HOTPLUG_CHANGED;
+if (old_epoch_counter != connector->base.epoch_counter)
+ret = true;
+
+if(ret) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s(epoch counter %llu)\n",
+ connector->base.base.id,
+ connector->base.name,
+ drm_get_connector_status_name(old_status),
+
drm_get_connector_status_name(connector->base.status),
+ connector->base.epoch_counter);
+ return INTEL_HOTPLUG_CHANGED;
+}
+return INTEL_HOTPLUG_UNCHANGED;
}
static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: ps8640: Rework power state handling
Hi Sam,
Many thanks for your feedback. See my answers below.
On 20/6/20 23:42, Sam Ravnborg wrote:
> Hi Enric.
>
> On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>> drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>> -> ps8640_bridge_get_edid
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before.
> Is it correct to fix this in the driver?
> Why not just fail and tell user-sapce to try again later?
> (Dunno what error-code to use - there must be one).
>
My undestanding, I might be wrong, is that userspace should don't know which
bits, regulators, etc, are needed to get the EDID with an ioctl. Is the kernel
that should make sure that all is set properly (the required regulators, etc)
when userspace wants to read the EDID.
> Then we avoid complicating drivers fro somethign we really should
> fix in user-space.
>
>> The side effect of this, for example, is
>> that you see anything when `Frecon` starts, neither the splash screen,
> that you do not see ...
>
> (Otherwise I do not parse the above).
>
>> until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again the
>>device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent calls
>>to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
> Step 3. looks like an ugly hack too
>
It is, but I don't have enough hardware details to be able to answer why we need
to do this. What is well tested is that, if I don't power the panel before
powering on the bridge, it doesn't get a proper EDID. Seems that when the bridge
goes up, the firmware tries to read the EDID and caches somehow. Well not sure.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
>> 1 file changed, 73 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>> index 9f7b7a9c53c52..ca651480891df 100644
>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -65,6 +65,7 @@ struct ps8640 {
>> struct regulator_bulk_data supplies[2];
>> struct gpio_desc *gpio_reset;
>> struct gpio_desc *gpio_powerdown;
>> +bool powered;
>> };
>>
>> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,25 @@ static int ps8640_bridge_vdo_control(struct ps8640
>> *ps_bridge,
>> return 0;
>> }
>>
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>> +struct drm_bridge *panel;
>> unsigned long timeout;
>> int ret, status;
>>
>> +if (ps_bridge->powered)
>> +return;
>> +
>> +/*
>> + * That seems to be specific to this chip, and a weird behaviour, but
>> + * we need to call drm_panel_prepare before issuing a poweron cycle. If
>> + * we don't do this, the chip is not able to read properly the EDID.
>> + */
>> +panel = ps_bridge->panel_bridge;
>> +if (panel->funcs && panel->funcs->pre_enable)
>> +panel->funcs->pre_enable(panel);
>> +
>> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>> ps_bridge->supplies);
>> if (ret < 0) {
>> @@ -164,6 +177,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>> goto err_regulators_disable;
>> }
>>
>> +ps_bridge->powered = true;
>> +
>> return;
>>
>> err_regulators_disable:
>> @@ -171,12 +186,13 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge)
>> ps_bridge->supplies);
>> }
>>
>> -static void ps8640_post_disable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +struct drm_bridge *panel;
>> int ret;
>>
>> -ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (!
Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
> On Jun 23, 2020, at 6:13 PM, Daniel Vetter wrote: > > Ok I tested this. I can't use your script to repro because > - I don't have a setup with xfs, and the splat points at an issue in xfs > - reproducing lockdep splats in shrinker callbacks is always a bit tricky What’s xfs setup are you talking about? This is simple xfs rootfs and then trigger swapping. Nothing tricky here as it hit on multiple machines within a few seconds on linux-next. > Summary: Everything is working as expected, there's no change in the > lockdep annotations. > I really think the problem is that either your testcase doesn't hit > the issue reliably enough, or that you're not actually testing the > same kernels and there's some other changes (xfs most likely, but > really it could be anywhere) which is causing this regression. I'm > rather convinced now after this test that it's not my stuff. Well, the memory pressure workloads have been running for years on daily linux-next builds and never saw this one happened once. Also, the reverting is ONLY to revert your patch on the top of linux-next will stop the splat, so there is no not testing the same kernel at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
On Sun, Jun 21, 2020 at 01:42:05PM -0400, Qian Cai wrote:
> On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > fs_reclaim_acquire/release nicely catch recursion issues when
> > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > to use to keep the excessive caches in check). For mmu notifier
> > recursions we do have lockdep annotations since 23b68395c7c7
> > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> >
> > But these only fire if a path actually results in some pte
> > invalidation - for most small allocations that's very rarely the case.
> > The other trouble is that pte invalidation can happen any time when
> > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > recursion.
> >
> > I was pondering whether we should just do the general annotation, but
> > there's always the risk for false positives. Plus I'm assuming that
> > the core fs and io code is a lot better reviewed and tested than
> > random mmu notifier code in drivers. Hence why I decide to only
> > annotate for that specific case.
> >
> > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > still need to explicit pull in the mmu notifier map - there's a lot
> > more places that do pte invalidation than just direct reclaim, these
> > two contexts arent the same.
> >
> > Note that the mmu notifiers needing their own independent lockdep map
> > is also the reason we can't hold them from fs_reclaim_acquire to
> > fs_reclaim_release - it would nest with the acquistion in the pte
> > invalidation code, causing a lockdep splat. And we can't remove the
> > annotations from pte invalidation and all the other places since
> > they're called from many other places than page reclaim. Hence we can
> > only do the equivalent of might_lock, but on the raw lockdep map.
> >
> > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > strictly more powerful.
> >
> > v2: Review from Thomas Hellstrom:
> > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > but it didn't blow up because I inverted it immediately
> > - fix compiling for !CONFIG_MMU_NOTIFIER
> >
> > Cc: Thomas Hellström (Intel)
> > Cc: Andrew Morton
> > Cc: Jason Gunthorpe
> > Cc: linux...@kvack.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: Maarten Lankhorst
> > Cc: Christian König
> > Signed-off-by: Daniel Vetter
>
> Replying the right patch here...
>
> Reverting this commit [1] fixed the lockdep warning below while applying
> some memory pressure.
>
> [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in
> fs_reclaim_acquire/release")
>
> [ 190.455003][ T369] WARNING: possible circular locking dependency detected
> [ 190.487291][ T369] 5.8.0-rc1-next-20200621 #1 Not tainted
> [ 190.512363][ T369] --
> [ 190.543354][ T369] kswapd3/369 is trying to acquire lock:
> [ 190.568523][ T369] 889fcf694528
> (&xfs_nondir_ilock_class){}-{3:3}, at: xfs_reclaim_inode+0xdf/0x860
> spin_lock at include/linux/spinlock.h:353
> (inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
> (inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
> (inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
> [ 190.614359][ T369]
> [ 190.614359][ T369] but task is already holding lock:
> [ 190.647763][ T369] b50ced00 (fs_reclaim){+.+.}-{0:0}, at:
> __fs_reclaim_acquire+0x0/0x30
> __fs_reclaim_acquire at mm/page_alloc.c:4200
> [ 190.687845][ T369]
> [ 190.687845][ T369] which lock already depends on the new lock.
> [ 190.687845][ T369]
> [ 190.734890][ T369]
> [ 190.734890][ T369] the existing dependency chain (in reverse order) is:
> [ 190.775991][ T369]
> [ 190.775991][ T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
> [ 190.808150][ T369]fs_reclaim_acquire+0x77/0x80
> [ 190.832152][ T369]slab_pre_alloc_hook.constprop.52+0x20/0x120
> slab_pre_alloc_hook at mm/slab.h:507
> [ 190.862173][ T369]kmem_cache_alloc+0x43/0x2a0
> [ 190.885602][ T369]kmem_zone_alloc+0x113/0x3ef
> kmem_zone_alloc at fs/xfs/kmem.c:129
> [ 190.908702][ T369]xfs_inode_item_init+0x1d/0xa0
> xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
> [ 190.934461][ T369]xfs_trans_ijoin+0x96/0x100
> xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
> [ 190.961530][ T369]xfs_setattr_nonsize+0x1a6/0xcd0
OK, this patch has royally screwed something up if this path thinks
it can enter memory reclaim. This path is inside a transaction, so
it is running under PF_MEMALLOC_NOFS context, so should *never*
enter memory reclaim.
I'd suggest that whatever mods were made to fs_reclaim_acquire by
this patch broke it's basic functionality
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > in
[PATCH v6 1/3] drm: Add helper to compare edids.
From: Stanislav Lisovskiy
Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.
v2: Added documentation for this function.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_edid.h | 9 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d8372d63851b..34cabfddcdd3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1615,6 +1615,39 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
return true;
}
+/**
+ * drm_edid_are_equal - compare two edid blobs.
+ * @edid1: pointer to first blob
+ * @edid2: pointer to second blob
+ * This helper can be used during probing to determine if
+ * edid had changed.
+ */
+bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2)
+{
+ int edid1_len, edid2_len;
+ bool edid1_present = edid1 != NULL;
+ bool edid2_present = edid2 != NULL;
+
+ if (edid1_present != edid2_present)
+ return false;
+
+ if (edid1) {
+
+ edid1_len = EDID_LENGTH * (1 + edid1->extensions);
+ edid2_len = EDID_LENGTH * (1 + edid2->extensions);
+
+ if (edid1_len != edid2_len)
+ return false;
+
+ if (memcmp(edid1, edid2, edid1_len))
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_edid_are_equal);
+
+
/**
* drm_edid_block_valid - Sanity check the EDID block (base or extension)
* @raw_edid: pointer to raw EDID block
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 34b15e3d070c..5c26cc65b786 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -359,6 +359,15 @@ drm_load_edid_firmware(struct drm_connector *connector)
}
#endif
+/**
+ * drm_edid_are_equal - compare two edid blobs.
+ * @edid1: pointer to first blob
+ * @edid2: pointer to second blob
+ * This helper can be used during probing to determine if
+ * edid had changed.
+ */
+bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2);
+
int
drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
struct drm_connector *connector,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/9] Convert the remaining text files to ReST and add SPDX for GFDL
On Tue, Jun 23, 2020 at 4:53 AM Mauro Carvalho Chehab
wrote:
>
> The main goal of this series is to finish the ReST conversion. After this
> series, we have just those files still in plain old format:
>
> - Documentation/RCU/RTFP.txt
> - Documentation/atomic_bitops.txt
> - Documentation/memory-barriers.txt
> - Documentation/atomic_t.txt
> - Documentation/filesystems/dax.txt
> - Documentation/filesystems/path-lookup.txt
> - Documentation/virt/kvm/devices/README
>
> PS.: I'm using a script to remove false-positives and ignore non-converted
> translated files.
>
> It is worth to mention that this fseries contain licenses for the two
> GFDL licenses used within the Kernel: GFDL-1.1+ and GFDL-1.2.
>
> Those licenses are the result of long discussions with the SPDX legal
> team, and are part of this commit, to be added for the future
> SPDX 3.10 version:
>
> https://github.com/spdx/license-list-XML/pull/1048/commits/f695d2ac65230d0f4161ba58fff2f9d87bb5a053
>
> Mauro Carvalho Chehab (9):
> docs: dt: convert booting-without-of.txt to ReST format
> LICENSES: add GFDL licenses
> media: docs: use SPDX GFDL-1.1-or-later-no-invariants
The identifier "GFDL-1.1-or-later-no-invariants" isn't following expected
construction (or-later and -only at the end) and the pull request is
still under
discussion on the SPDX license list, so please hold off on applying this
until the correct identifier is figured out there.
> docs: trace: ring-buffer-design.txt: convert to ReST format
> docs: move nommu-mmap.txt to admin-guide and rename to ReST
> docs: move mailbox.txt to driver-api and rename it
> docs: move other kAPI documents to core-api
> docs: Add remaining Documentation/*.txt at staging/index.rst
> docs: staging: use small font for literal includes
>
> Documentation/admin-guide/mm/index.rst| 1 +
> .../mm/nommu-mmap.rst}| 0
> Documentation/admin-guide/sysctl/vm.rst | 2 +-
> Documentation/arm/booting.rst | 2 +-
> .../bus-virt-phys-mapping.rst}| 0
> Documentation/core-api/index.rst | 3 +
> .../this_cpu_ops.rst} | 0
> .../unaligned-memory-access.rst | 0
> ...-without-of.txt => booting-without-of.rst} | 298 ---
> Documentation/devicetree/index.rst| 1 +
> Documentation/driver-api/index.rst| 1 +
> .../{mailbox.txt => driver-api/mailbox.rst} | 0
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/staging/index.rst | 24 +
> Documentation/trace/index.rst | 1 +
> ...ffer-design.txt => ring-buffer-design.rst} | 778 +-
> Documentation/translations/zh_CN/arm/Booting | 2 +-
> .../userspace-api/media/cec/cec-api.rst | 9 +-
> .../media/cec/cec-func-close.rst | 9 +-
> .../media/cec/cec-func-ioctl.rst | 9 +-
> .../userspace-api/media/cec/cec-func-open.rst | 9 +-
> .../userspace-api/media/cec/cec-func-poll.rst | 9 +-
> .../userspace-api/media/cec/cec-funcs.rst | 9 +-
> .../userspace-api/media/cec/cec-header.rst| 9 +-
> .../userspace-api/media/cec/cec-intro.rst | 9 +-
> .../media/cec/cec-ioc-adap-g-caps.rst | 9 +-
> .../media/cec/cec-ioc-adap-g-log-addrs.rst| 9 +-
> .../media/cec/cec-ioc-adap-g-phys-addr.rst| 9 +-
> .../media/cec/cec-ioc-dqevent.rst | 9 +-
> .../media/cec/cec-ioc-g-mode.rst | 9 +-
> .../media/cec/cec-ioc-receive.rst | 9 +-
> .../media/cec/cec-pin-error-inj.rst | 9 +-
> .../dvb/audio-bilingual-channel-select.rst| 9 +-
> .../media/dvb/audio-channel-select.rst| 9 +-
> .../media/dvb/audio-clear-buffer.rst | 9 +-
> .../media/dvb/audio-continue.rst | 9 +-
> .../userspace-api/media/dvb/audio-fclose.rst | 9 +-
> .../userspace-api/media/dvb/audio-fopen.rst | 9 +-
> .../userspace-api/media/dvb/audio-fwrite.rst | 9 +-
> .../media/dvb/audio-get-capabilities.rst | 9 +-
> .../media/dvb/audio-get-status.rst| 9 +-
> .../userspace-api/media/dvb/audio-pause.rst | 9 +-
> .../userspace-api/media/dvb/audio-play.rst| 9 +-
> .../media/dvb/audio-select-source.rst | 9 +-
> .../media/dvb/audio-set-av-sync.rst | 9 +-
> .../media/dvb/audio-set-bypass-mode.rst | 9 +-
> .../userspace-api/media/dvb/audio-set-id.rst | 9 +-
> .../media/dvb/audio-set-mixer.rst | 9 +-
> .../media/dvb/audio-set-mute.rst | 9 +-
> .../media/dvb/audio-set-streamtype.rst| 9 +-
> .../userspace-api/media/dvb/audio-stop.rst| 9 +-
> .../userspace-api/media/dvb/audio.rst | 9 +-
> .../media/dvb/audio_data_types.rst| 9 +-
> .../media/dvb/audio_function_calls.rst| 9 +-
> .../userspace-api/
[PATCH v6 0/3] Send a hotplug when edid changes
From: Stanislav Lisovskiy This series introduce to drm a way to determine if something else except connection_status had changed during probing, which can be used by other drivers as well. Another i915 specific part uses this approach to determine if edid had changed without changing the connection status and send a hotplug event. Stanislav Lisovskiy (3): drm: Add helper to compare edids. drm: Introduce epoch counter to drm_connector drm/i915: Send hotplug event if edid had changed drivers/gpu/drm/drm_connector.c | 16 drivers/gpu/drm/drm_edid.c | 39 +++- drivers/gpu/drm/drm_probe_helper.c | 38 --- drivers/gpu/drm/i915/display/intel_hotplug.c | 26 +++-- include/drm/drm_connector.h | 2 + include/drm/drm_edid.h | 9 + 6 files changed, 113 insertions(+), 17 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] XDC 2020: Registration & Call for Proposals now open!
Hi, This is a kindly reminder that the CFP deadline is in less than two weeks :) On Fri, 2020-05-15 at 14:15 +, Szwichtenberg, Radoslaw wrote: > Hello! > > Registration & Call for Proposals are now open for XDC 2020, which > will > take place at the Gdańsk University of Technology in Gdańsk, Poland > on September 16-18, 2020. > > Thanks to LWN.net for hosting the website again this year! > > https://xdc2020.x.org > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as > early as possible! However, don't book any travel or hotel until the > organization decides if we keep the conference as it is or there is > any change. Please read this message on the website for more > information: > > https://xdc2020.x.org/event/9/page/78-covid-19 > > In order to register as attendee, you will therefore need to register > via the XDC > website. However, as XDC is sharing the same Indico infrastructure as > LPC, if you previously registered on the LPC website > (linuxplumbersconference.org) or on the XDC 2019 website > (xdc2019.x.org), then you already have an active account > and can use the same username & password to login! > > https://xdc2020.x.org/event/9/registrations/7/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2020. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org > developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from > the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://xdc2020.x.org/event/9/abstracts/ > > The deadline for submissions is Sunday, 5 July 2020. > > Notice that the event may end up being postponed, converted to a > fully online conference, or even a hybrid one (physical event + some > remote talks). It depends on how COVID-19 situation evolves in the > different countries and the restrictions we will have at that time. > Also, some people may decide to skip the physical conference to avoid > any risk of infection. Because of that, please indicate in your talk > submission if you prefer to give a remote talk in the case that XDC > keeps being a physical event this year. Similarly, if you think that > your talk makes no sense if XDC ends up being a fully-virtual > conference, please indicate that in the notes of the talk submission. > We are gathering all the information in order to make a decision at the beginning of July. Stay tuned [0]! Sam [0] https://xdc2020.x.org/event/9/page/78-covid-19 > If COVID-19 situation allows it, we are looking forward to seeing you > in Gdańsk! If you have any questions, please send me an email to > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > (board at foundation.x.org). > > And don't forget, you can follow us on Twitter for all the latest > updates and to stay connected: > > https://twitter.com/xdc2020 > > Best, > > Radek > > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
Thanks Mike for the inputs.
On 6/22/2020 5:10 PM, Ruhl, Michael J wrote:
>> -Original Message-
>> From: charante=codeaurora@mg.codeaurora.org
>> On Behalf Of Charan Teja
>> Kalla
>> Sent: Monday, June 22, 2020 5:26 AM
>> To: Ruhl, Michael J ; Sumit Semwal
>> ; david.lai...@aculab.com; open list:DMA
>> BUFFER SHARING FRAMEWORK ; DRI mailing
>> list
>> Cc: Linaro MM SIG ; LKML > ker...@vger.kernel.org>
>> Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>>
>> Hello Mike,
>>
>> On 6/19/2020 7:11 PM, Ruhl, Michael J wrote:
-Original Message-
From: charante=codeaurora@mg.codeaurora.org
On Behalf Of Charan
>> Teja
Kalla
Sent: Friday, June 19, 2020 7:57 AM
To: Sumit Semwal ; Ruhl, Michael J
; david.lai...@aculab.com; open list:DMA
BUFFER SHARING FRAMEWORK ; DRI
>> mailing
list
Cc: Linaro MM SIG ; LKML >>> ker...@vger.kernel.org>
Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
There exists a sleep-while-atomic bug while accessing the dmabuf->name
under mutex in the dmabuffs_dname(). This is caused from the SELinux
permissions checks on a process where it tries to validate the inherited
files from fork() by traversing them through iterate_fd() (which
traverse files under spin_lock) and call
match_file(security/selinux/hooks.c) where the permission checks
>> happen.
This audit information is logged using dump_common_audit_data() where
>> it
calls d_path() to get the file path name. If the file check happen on
the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
access dmabuf->name. The flow will be like below:
flush_unauthorized_files()
iterate_fd()
spin_lock() --> Start of the atomic section.
match_file()
file_has_perm()
avc_has_perm()
avc_audit()
slow_avc_audit()
common_lsm_audit()
dump_common_audit_data()
audit_log_d_path()
d_path()
dmabuffs_dname()
mutex_lock()--> Sleep while atomic.
Call trace captured (on 4.19 kernels) is below:
___might_sleep+0x204/0x208
__might_sleep+0x50/0x88
__mutex_lock_common+0x5c/0x1068
__mutex_lock_common+0x5c/0x1068
mutex_lock_nested+0x40/0x50
dmabuffs_dname+0xa0/0x170
d_path+0x84/0x290
audit_log_d_path+0x74/0x130
common_lsm_audit+0x334/0x6e8
slow_avc_audit+0xb8/0xf8
avc_has_perm+0x154/0x218
file_has_perm+0x70/0x180
match_file+0x60/0x78
iterate_fd+0x128/0x168
selinux_bprm_committing_creds+0x178/0x248
security_bprm_committing_creds+0x30/0x48
install_exec_creds+0x1c/0x68
load_elf_binary+0x3a4/0x14e0
search_binary_handler+0xb0/0x1e0
So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
Cc: [5.3+]
Signed-off-by: Charan Teja Reddy
---
Changes in V2: Addressed review comments from Ruhl, Michael J
Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/
drivers/dma-buf/dma-buf.c | 11 +++
include/linux/dma-buf.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125..d81d298 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry
>> *dentry,
char *buffer, int buflen)
size_t ret = 0;
dmabuf = dentry->d_fsdata;
- dma_resv_lock(dmabuf->resv, NULL);
+ spin_lock(&dmabuf->name_lock);
if (dmabuf->name)
ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
- dma_resv_unlock(dmabuf->resv);
+ spin_unlock(&dmabuf->name_lock);
return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
dentry->d_name.name, ret > 0 ? name : "");
@@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf
*dmabuf, const char __user *buf)
kfree(name);
goto out_unlock;
}
+ spin_lock(&dmabuf->name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
+ spin_unlock(&dmabuf->name_lock);
>>>
>>> While this code path is ok, I would have separated the protection of the
>>> attachment list and the name manipulation.
>>>
>>> dma_resv_lock(resv)
>>> if (!list_empty(attachment)
>>> ret = -EBUSY
>>> dma_resv_unlock(resv)
>>>
>>> if (ret) {
>>> kfree(name)
>>> return ret;
>>> }
>>
>> Is it that the name should be visible before importer attaches to the
>> dmabuf,(using dma_buf_attach()), thus _buf_set_name() is under the
>> _resv_lock() as well?
>
> That is the name that was being freed in the error path of the lock block.
> Alternatively:
>
Re: [PATCH 01/14] drm/ast: Move cursor functions to ast_cursor.c
Hi Sam
Am 23.06.20 um 18:55 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, Jun 23, 2020 at 10:18:48AM +0200, Thomas Zimmermann wrote:
>> The cursor manipulation functions are unrelated to modesetting. Move
>> them into their own file.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/ast/Makefile | 3 +-
>> drivers/gpu/drm/ast/ast_cursor.c | 218 +++
>> drivers/gpu/drm/ast/ast_drv.h| 9 ++
>> drivers/gpu/drm/ast/ast_mode.c | 195 ---
>> 4 files changed, 229 insertions(+), 196 deletions(-)
>> create mode 100644 drivers/gpu/drm/ast/ast_cursor.c
>>
>> diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
>> index 561f7c4199e4..6a5b3b247316 100644
>> --- a/drivers/gpu/drm/ast/Makefile
>> +++ b/drivers/gpu/drm/ast/Makefile
>> @@ -3,6 +3,7 @@
>> # Makefile for the drm device driver. This driver provides support for the
>> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>>
>> -ast-y := ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o ast_dp501.o
>> +ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
>> + ast_dp501.o
>>
>> obj-$(CONFIG_DRM_AST) := ast.o
>> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
>> b/drivers/gpu/drm/ast/ast_cursor.c
>> new file mode 100644
>> index ..53bb6eebc7cd
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ast/ast_cursor.c
>> @@ -0,0 +1,218 @@
>> +/*
>> + * Copyright 2012 Red Hat Inc.
>> + * Parts based on xf86-video-ast
>> + * Copyright (c) 2005 ASPEED Technology Inc.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
>> CLAIM,
>> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
>> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial portions
>> + * of the Software.
>
> SPDX for new files?
> I guess this boilerplate was copied from the old file.
Yes, I copied the license text from the old file. I wasn't sure if I can
just add the SPDX tag. If that's not a problem, I'll add it in the next
iteration.
Best regards
Thomas
>
> Acked-by: Sam Ravnborg
>
>> + */
>> +/*
>> + * Authors: Dave Airlie
>> + */
>> +
>> +#include
>> +
>> +#include "ast_drv.h"
>> +
>> +/*
>> + * Allocate cursor BOs and pins them at the end of VRAM.
>> + */
>> +int ast_cursor_init(struct drm_device *dev)
>> +{
>> +struct ast_private *ast = to_ast_private(dev);
>> +size_t size, i;
>> +struct drm_gem_vram_object *gbo;
>> +int ret;
>> +
>> +size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
>> +
>> +for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
>> +gbo = drm_gem_vram_create(dev, size, 0);
>> +if (IS_ERR(gbo)) {
>> +ret = PTR_ERR(gbo);
>> +goto err_drm_gem_vram_put;
>> +}
>> +ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
>> +DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
>> +if (ret) {
>> +drm_gem_vram_put(gbo);
>> +goto err_drm_gem_vram_put;
>> +}
>> +
>> +ast->cursor.gbo[i] = gbo;
>> +}
>> +
>> +return 0;
>> +
>> +err_drm_gem_vram_put:
>> +while (i) {
>> +--i;
>> +gbo = ast->cursor.gbo[i];
>> +drm_gem_vram_unpin(gbo);
>> +drm_gem_vram_put(gbo);
>> +ast->cursor.gbo[i] = NULL;
>> +}
>> +return ret;
>> +}
>> +
>> +void ast_cursor_fini(struct drm_device *dev)
>> +{
>> +struct ast_private *ast = to_ast_private(dev);
>> +size_t i;
>> +struct drm_gem_vram_object *gbo;
>> +
>> +for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
>> +gbo = ast->cursor.gbo[i];
>> +drm_gem_vram_unpin(gbo);
>> +drm_gem_vram_put(gbo);
>> +}
>> +}
>> +
>> +static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
>> +{
>> +union {
>> +u32 ul;
>> +u8 b[4];
>> +
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On Tue, Jun 23, 2020 at 11:04:30PM -0400, Andrey Grodzovsky wrote: > > On 6/23/20 2:05 AM, Greg KH wrote: > > On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote: > > > On 6/22/20 12:45 PM, Greg KH wrote: > > > > On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote: > > > > > On 6/22/20 7:21 AM, Greg KH wrote: > > > > > > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote: > > > > > > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote: > > > > > > > > Track sysfs files in a list so they all can be removed during > > > > > > > > pci remove > > > > > > > > since otherwise their removal after that causes crash because > > > > > > > > parent > > > > > > > > folder was already removed during pci remove. > > > > > > Huh? That should not happen, do you have a backtrace of that crash? > > > > > 2 examples in the attached trace. > > > > Odd, how did you trigger these? > > > > > > By manually triggering PCI remove from sysfs > > > > > > cd /sys/bus/pci/devices/\:05\:00.0 && echo 1 > remove > > For some reason, I didn't think that video/drm devices could handle > > hot-remove like this. The "old" PCI hotplug specification explicitly > > said that video devices were not supported, has that changed? > > > > And this whole issue is probably tied to the larger issue that Daniel > > was asking me about, when it came to device lifetimes and the drm layer, > > so odds are we need to fix that up first before worrying about trying to > > support this crazy request, right? :) > > > > > > > [ 925.738225 <0.188086>] BUG: kernel NULL pointer dereference, > > > > > address: 0090 > > > > > [ 925.738232 <0.07>] #PF: supervisor read access in kernel > > > > > mode > > > > > [ 925.738236 <0.04>] #PF: error_code(0x) - not-present > > > > > page > > > > > [ 925.738240 <0.04>] PGD 0 P4D 0 > > > > > [ 925.738245 <0.05>] Oops: [#1] SMP PTI > > > > > [ 925.738249 <0.04>] CPU: 7 PID: 2547 Comm: amdgpu_test > > > > > Tainted: GW OE 5.5.0-rc7-dev-kfd+ #50 > > > > > [ 925.738256 <0.07>] Hardware name: System manufacturer > > > > > System Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013 > > > > > [ 925.738266 <0.10>] RIP: 0010:kernfs_find_ns+0x18/0x110 > > > > > [ 925.738270 <0.04>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f > > > > > 1f 84 00 00 00 00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 > > > > > 49 89 fd 55 53 49 89 d4 <0f> b7 af 90 00 00 00 8b 05 8f ee 6b 01 48 > > > > > 8b 5f 68 66 83 e5 20 41 > > > > > [ 925.738282 <0.12>] RSP: 0018:ad6d0118fb00 EFLAGS: > > > > > 00010246 > > > > > [ 925.738287 <0.05>] RAX: RBX: > > > > > RCX: 2098a12076864b7e > > > > > [ 925.738292 <0.05>] RDX: RSI: > > > > > b6606b31 RDI: > > > > > [ 925.738297 <0.05>] RBP: b6606b31 R08: > > > > > b5379d10 R09: > > > > > [ 925.738302 <0.05>] R10: ad6d0118fb38 R11: > > > > > 9a75f64820a8 R12: > > > > > [ 925.738307 <0.05>] R13: R14: > > > > > b6606b31 R15: 9a7612b06130 > > > > > [ 925.738313 <0.06>] FS: 7f3eca4e8700() > > > > > GS:9a763dbc() knlGS: > > > > > [ 925.738319 <0.06>] CS: 0010 DS: ES: CR0: > > > > > 80050033 > > > > > [ 925.738323 <0.04>] CR2: 0090 CR3: > > > > > 35e5a005 CR4: 000606e0 > > > > > [ 925.738329 <0.06>] Call Trace: > > > > > [ 925.738334 <0.05>] kernfs_find_and_get_ns+0x2e/0x50 > > > > > [ 925.738339 <0.05>] sysfs_remove_group+0x25/0x80 > > > > > [ 925.738344 <0.05>] sysfs_remove_groups+0x29/0x40 > > > > > [ 925.738350 <0.06>] free_msi_irqs+0xf5/0x190 > > > > > [ 925.738354 <0.04>] pci_disable_msi+0xe9/0x120 > > > > So the PCI core is trying to clean up attributes that it had registered, > > > > which is fine. But we can't seem to find the attributes? Were they > > > > already removed somewhere else? > > > > > > > > that's odd. > > > > > > Yes, as i pointed above i am emulating device remove from sysfs and this > > > triggers pci device remove sequence and as part of that my specific device > > > folder (05:00.0) is removed from the sysfs tree. > > But why are things being removed twice? > > > Not sure I understand what removed twice ? I remove only once per sysfs > attribute. This code path shows that the kernel is trying to remove a file that is not present, so someone removed it already... thanks, gre k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 419/491] drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5212:45: warning: unused variable 'gfx_v7_0_ip_block'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: fadef51a438279ca660dbce31c26e787d6680149
commit: a9601cd4a0355f07df6d6b89d5d7add7be9b15c6 [419/491] drm/amdgpu: label
internally used symbols as static
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
1d4c87335d5236ea1f35937e1014980ba961ae34)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout a9601cd4a0355f07df6d6b89d5d7add7be9b15c6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5212:45: warning: unused variable
>> 'gfx_v7_0_ip_block' [-Wunused-const-variable]
static const struct amdgpu_ip_block_version gfx_v7_0_ip_block =
^
1 warning generated.
vim +/gfx_v7_0_ip_block +5212 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
5211
> 5212 static const struct amdgpu_ip_block_version gfx_v7_0_ip_block =
5213 {
5214 .type = AMD_IP_BLOCK_TYPE_GFX,
5215 .major = 7,
5216 .minor = 0,
5217 .rev = 0,
5218 .funcs = &gfx_v7_0_ip_funcs,
5219 };
5220
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On Wed, 24 Jun 2020 at 11:36, Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 17 Jun 2020 10:59:29 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> > 'amdgpu_amdkfd_gpuvm_free_memory_of_gpu':
> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1357:2: error: implicit
> > declaration of function 'drm_gem_object_put_unlocked'; did you mean
> > 'drm_gem_object_put_locked'? [-Werror=implicit-function-declaration]
> > 1357 | drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> > | ^~~
> > | drm_gem_object_put_locked
> >
> > Caused by commit
> >
> > ab15d56e27be ("drm: remove transient drm_gem_object_put_unlocked()")
> >
> > interacting with commit
> >
> > fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
> >
> > from Linus' tree.
> >
> > I have applied the following merge fix up patch for today.
> >
> > From: Stephen Rothwell
> > Date: Wed, 17 Jun 2020 10:55:32 +1000
> > Subject: [PATCH] drm/amdgpu: remove stray drm_gem_object_put_unlocked
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> > index b91b5171270f..9015c7b76d60 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> > @@ -1354,7 +1354,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
> > }
> >
> > /* Free the BO*/
> > - drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> > + drm_gem_object_put(&mem->bo->tbo.base);
> > mutex_destroy(&mem->lock);
> > kfree(mem);
> >
> > --
> > 2.26.2
>
> This fix is now needed when I merge the drm tree :-(
>
> Given that the drm tree is based on v5.8-rc2 and the commit from Linus'
> tree above was merged before v5.8-rc1, the above patch should be
> applied to the drm tree (and should have been part of the patch that
> merged the drm-misc tree). I am a bit suprised that the drm tree
> currently passes CI.
My bad, my local builds passed, as I had made the change but forgot
the commit --amend
Pushed out a new head with it in it now.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 198/491] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:268:17: sparse: sparse: cast removes address space '' of expression
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: fadef51a438279ca660dbce31c26e787d6680149
commit: e14661af4e9f48d5e4380bfb5497ee2e640c5508 [198/491] drm/amdkfd: Support
Sienna_Cichlid KFD v4
config: x86_64-randconfig-s021-20200623 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
git checkout e14661af4e9f48d5e4380bfb5497ee2e640c5508
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:268:17: sparse: sparse:
>> cast removes address space '' of expression
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:270:17: sparse: sparse:
cast removes address space '' of expression
vim +268 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
192
193 static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, uint32_t
pipe_id,
194 uint32_t queue_id, uint32_t __user *wptr,
195 uint32_t wptr_shift, uint32_t wptr_mask,
196 struct mm_struct *mm)
197 {
198 struct amdgpu_device *adev = get_amdgpu_device(kgd);
199 struct v10_compute_mqd *m;
200 uint32_t *mqd_hqd;
201 uint32_t reg, hqd_base, data;
202
203 m = get_mqd(mqd);
204
205 pr_debug("Load hqd of pipe %d queue %d\n", pipe_id, queue_id);
206 acquire_queue(kgd, pipe_id, queue_id);
207
208 /* HIQ is set during driver init period with vmid set to 0*/
209 if (m->cp_hqd_vmid == 0) {
210 uint32_t value, mec, pipe;
211
212 mec = (pipe_id / adev->gfx.mec.num_pipe_per_mec) + 1;
213 pipe = (pipe_id % adev->gfx.mec.num_pipe_per_mec);
214
215 pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
216 mec, pipe, queue_id);
217 value = RREG32(SOC15_REG_OFFSET(GC, 0,
mmRLC_CP_SCHEDULERS));
218 value = REG_SET_FIELD(value, RLC_CP_SCHEDULERS,
scheduler1,
219 ((mec << 5) | (pipe << 3) | queue_id | 0x80));
220 WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS),
value);
221 }
222
223 /* HQD registers extend from CP_MQD_BASE_ADDR to
CP_HQD_EOP_WPTR_MEM. */
224 mqd_hqd = &m->cp_mqd_base_addr_lo;
225 hqd_base = SOC15_REG_OFFSET(GC, 0, mmCP_MQD_BASE_ADDR);
226
227 for (reg = hqd_base;
228 reg <= SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI); reg++)
229 WREG32(reg, mqd_hqd[reg - hqd_base]);
230
231
232 /* Activate doorbell logic before triggering WPTR poll. */
233 data = REG_SET_FIELD(m->cp_hqd_pq_doorbell_control,
234 CP_HQD_PQ_DOORBELL_CONTROL, DOORBELL_EN,
1);
235 WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL),
data);
236
237 if (wptr) {
238 /* Don't read wptr with get_user because the user
239 * context may not be accessible (if this function
240 * runs in a work queue). Instead trigger a one-shot
241 * polling read from memory in the CP. This assumes
242 * that wptr is GPU-accessible in the queue's VMID via
243 * ATC or SVM. WPTR==RPTR before starting the poll so
244 * the CP starts fetching new commands from the right
245 * place.
246 *
247 * Guessing a 64-bit WPTR from a 32-bit RPTR is a bit
248 * tricky. Assume that the queue didn't overflow. The
249 * number of valid bits in the 32-bit RPTR depends on
250 * the queue size. The remaining bits are taken from
251 * the saved 64-bit WPTR. If the WPTR wrapped, add the
252 * queue size.
253 */
254 uint32_t queue_size =
255 2 << REG_GET_FIELD(m->cp_hqd_pq_control,
256 CP_HQD_PQ_CONTROL,
QUEUE_SIZE);
257 uint64_t guessed_wptr = m->cp_hqd_pq_rptr & (queue_size
- 1);
258
259 if ((m->cp_hqd_pq_wptr_lo & (queue_size - 1)) <
guessed_wptr)
260 guessed_wptr += que
Re: [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page.
On 6/22/20 5:41 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
On device removal reroute all CPU mappings to dummy page per drm_file
instance or imported GEM object.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 -
1 file changed, 57 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b..2f8bf5e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -35,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
Hm I think diff and code flow look a bit bad now. What about renaming the
current function to __ttm_bo_vm_fault and then having something like the
below:
ttm_bo_vm_fault(args) {
if (drm_dev_enter()) {
__ttm_bo_vm_fault(args);
drm_dev_exit();
} else {
drm_gem_insert_dummy_pfn();
}
}
I think drm_gem_insert_dummy_pfn(); should be portable across drivers, so
another nice point to try to unifiy drivers as much as possible.
-Daniel
pgprot_t prot;
struct ttm_buffer_object *bo = vma->vm_private_data;
vm_fault_t ret;
+ int idx;
+ struct drm_device *ddev = bo->base.dev;
- ret = ttm_bo_vm_reserve(bo, vmf);
- if (ret)
- return ret;
+ if (drm_dev_enter(ddev, &idx)) {
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ goto exit;
+
+ prot = vma->vm_page_prot;
- prot = vma->vm_page_prot;
- ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
- if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ ret = ttm_bo_vm_fault_reserved(vmf, prot,
TTM_BO_VM_NUM_PREFAULT);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags &
FAULT_FLAG_RETRY_NOWAIT))
+ goto exit;
+
+ dma_resv_unlock(bo->base.resv);
+
+exit:
+ drm_dev_exit(idx);
return ret;
+ } else {
- dma_resv_unlock(bo->base.resv);
+ struct drm_file *file = NULL;
+ struct page *dummy_page = NULL;
+ int handle;
- return ret;
+ /* We are faulting on imported BO from dma_buf */
+ if (bo->base.dma_buf && bo->base.import_attach) {
+ dummy_page = bo->base.dummy_page;
+ /* We are faulting on non imported BO, find drm_file owning the
BO*/
Uh, we can't fish that out of the vma->vm_file pointer somehow? Or is that
one all wrong? Doing this kind of list walk looks pretty horrible.
If the vma doesn't have the right pointer I guess next option is that we
store the drm_file page in gem_bo->dummy_page, and replace it on first
export. But that's going to be tricky to track ...
+ } else {
+ struct drm_gem_object *gobj;
+
+ mutex_lock(&ddev->filelist_mutex);
+ list_for_each_entry(file, &ddev->filelist, lhead) {
+ spin_lock(&file->table_lock);
+ idr_for_each_entry(&file->object_idr, gobj,
handle) {
+ if (gobj == &bo->base) {
+ dummy_page = file->dummy_page;
+ break;
+ }
+ }
+ spin_unlock(&file->table_lock);
+ }
+ mutex_unlock(&ddev->filelist_mutex);
+ }
+
+ if (dummy_page) {
+ /*
+* Let do_fault complete the PTE install e.t.c using
vmf->page
+*
+* TODO - should i call free_page somewhere ?
Nah, instead don't call get_page. The page will be around as long as
there's a reference for the drm_file or gem_bo, which is longer than any
mmap. Otherwise yes this would like really badly.
So actually that was my thinking in the first place and I indeed avoided taking
reference and this ended up
with multiple BUG_ONs as seen bellow where refcount:-63 mapcount:-48 for a page
are deep into negative
values... Those warnings were gone once i added get_page(dummy) which in my
opinion implies that there
is a page reference per each PTE and that when there is unmapping of the process
address
space and PTEs are deleted there is also put_page somewhere in mm core and the
get_page per mapping
keeps it balanced.
Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762929] BUG: Bad page map in
process glxgear:disk$0 pte:800132284867 pmd:15aaec067
Jun 20 01:36:43 ubuntu-1604-test kerne
Re: [PATCH v2 0/8] RFC Support hot device unplug in amdgpu
Tried, didn't have any impact Andrey On 6/23/20 5:04 AM, Michel Dänzer wrote: On 2020-06-23 7:14 a.m., Andrey Grodzovsky wrote: I am fighting with Thunderbird to make limit a line to 80 chars but nothing helps. Any suggestions please. Maybe try disabling mail.compose.default_to_paragraph, or check other *wrap* settings. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.
On 6/23/20 9:16 AM, Christian König wrote: Am 23.06.20 um 12:22 schrieb Daniel Vetter: On Mon, Jun 22, 2020 at 03:48:29PM -0400, Alex Deucher wrote: On Mon, Jun 22, 2020 at 3:38 PM Christian König wrote: Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky: Use the new TTM interface to invalidate all exsisting BO CPU mappings form all user proccesses. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König I think those two patches could already land in amd-staging-drm-next since they are a good idea independent of how else we fix the other issues. Please make sure they land in drm-misc as well. Not sure that's much use, since without any of the fault side changes you just blow up on the first refault. Seems somewhat silly to charge ahead on this with the other bits still very much under discussion. Well what I wanted to say is that we don't need to send out those simple patches once more. Plus I suggested a possible bikeshed here :-) No bikeshed, but indeed a rather good idea to not make this a TTM function. Christian. So i will incorporate the changes suggested to turn the TTM part into generic DRM helper and will resend both patches as part of V3 (which might take a while now due to a context switch I am doing for another task). Andrey -Daniel Alex --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 43592dc..6932d75 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev) struct drm_device *dev = pci_get_drvdata(pdev); drm_dev_unplug(dev); + ttm_bo_unmap_virtual_address_space(&adev->mman.bdev); amdgpu_driver_unload_kms(dev); pci_disable_device(pdev); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
On 6/23/20 2:05 AM, Greg KH wrote: On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote: On 6/22/20 12:45 PM, Greg KH wrote: On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote: On 6/22/20 7:21 AM, Greg KH wrote: On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote: On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote: Track sysfs files in a list so they all can be removed during pci remove since otherwise their removal after that causes crash because parent folder was already removed during pci remove. Huh? That should not happen, do you have a backtrace of that crash? 2 examples in the attached trace. Odd, how did you trigger these? By manually triggering PCI remove from sysfs cd /sys/bus/pci/devices/\:05\:00.0 && echo 1 > remove For some reason, I didn't think that video/drm devices could handle hot-remove like this. The "old" PCI hotplug specification explicitly said that video devices were not supported, has that changed? And this whole issue is probably tied to the larger issue that Daniel was asking me about, when it came to device lifetimes and the drm layer, so odds are we need to fix that up first before worrying about trying to support this crazy request, right? :) [ 925.738225 <0.188086>] BUG: kernel NULL pointer dereference, address: 0090 [ 925.738232 <0.07>] #PF: supervisor read access in kernel mode [ 925.738236 <0.04>] #PF: error_code(0x) - not-present page [ 925.738240 <0.04>] PGD 0 P4D 0 [ 925.738245 <0.05>] Oops: [#1] SMP PTI [ 925.738249 <0.04>] CPU: 7 PID: 2547 Comm: amdgpu_test Tainted: G W OE 5.5.0-rc7-dev-kfd+ #50 [ 925.738256 <0.07>] Hardware name: System manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013 [ 925.738266 <0.10>] RIP: 0010:kernfs_find_ns+0x18/0x110 [ 925.738270 <0.04>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 49 89 fd 55 53 49 89 d4 <0f> b7 af 90 00 00 00 8b 05 8f ee 6b 01 48 8b 5f 68 66 83 e5 20 41 [ 925.738282 <0.12>] RSP: 0018:ad6d0118fb00 EFLAGS: 00010246 [ 925.738287 <0.05>] RAX: RBX: RCX: 2098a12076864b7e [ 925.738292 <0.05>] RDX: RSI: b6606b31 RDI: [ 925.738297 <0.05>] RBP: b6606b31 R08: b5379d10 R09: [ 925.738302 <0.05>] R10: ad6d0118fb38 R11: 9a75f64820a8 R12: [ 925.738307 <0.05>] R13: R14: b6606b31 R15: 9a7612b06130 [ 925.738313 <0.06>] FS: 7f3eca4e8700() GS:9a763dbc() knlGS: [ 925.738319 <0.06>] CS: 0010 DS: ES: CR0: 80050033 [ 925.738323 <0.04>] CR2: 0090 CR3: 35e5a005 CR4: 000606e0 [ 925.738329 <0.06>] Call Trace: [ 925.738334 <0.05>] kernfs_find_and_get_ns+0x2e/0x50 [ 925.738339 <0.05>] sysfs_remove_group+0x25/0x80 [ 925.738344 <0.05>] sysfs_remove_groups+0x29/0x40 [ 925.738350 <0.06>] free_msi_irqs+0xf5/0x190 [ 925.738354 <0.04>] pci_disable_msi+0xe9/0x120 So the PCI core is trying to clean up attributes that it had registered, which is fine. But we can't seem to find the attributes? Were they already removed somewhere else? that's odd. Yes, as i pointed above i am emulating device remove from sysfs and this triggers pci device remove sequence and as part of that my specific device folder (05:00.0) is removed from the sysfs tree. But why are things being removed twice? Not sure I understand what removed twice ? I remove only once per sysfs attribute. Andrey [ 925.738406 <0.52>] amdgpu_irq_fini+0xe3/0xf0 [amdgpu] [ 925.738453 <0.47>] tonga_ih_sw_fini+0xe/0x30 [amdgpu] [ 925.738490 <0.37>] amdgpu_device_fini_late+0x14b/0x440 [amdgpu] [ 925.738529 <0.39>] amdgpu_driver_release_kms+0x16/0x40 [amdgpu] [ 925.738548 <0.19>] drm_dev_put+0x5b/0x80 [drm] [ 925.738558 <0.10>] drm_release+0xc6/0xd0 [drm] [ 925.738563 <0.05>] __fput+0xc6/0x260 [ 925.738568 <0.05>] task_work_run+0x79/0xb0 [ 925.738573 <0.05>] do_exit+0x3d0/0xc60 [ 925.738578 <0.05>] do_group_exit+0x47/0xb0 [ 925.738583 <0.05>] get_signal+0x18b/0xc30 [ 925.738589 <0.06>] do_signal+0x36/0x6a0 [ 925.738593 <0.04>] ? force_sig_info_to_task+0xbc/0xd0 [ 925.738597 <0.04>] ? signal_wake_up_state+0x15/0x30 [ 925.738603 <0.06>] exit_to_usermode_loop+0x6f/0xc0 [ 925.738608 <0.05>] prepare_exit_to_usermode+0xc7/0x110 [ 925.738613 <0.05>] ret_from_intr+0x25/0x35 [ 925.738617 <0.04>] RIP: 0033:0x417369 [ 925.738621 <0.04>] Code: Bad RIP value. [ 9
[radeon-alex:drm-next 41/491] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: fadef51a438279ca660dbce31c26e787d6680149
commit: 32cb59f3136248c40062f6fe3edfba13c516b30c [41/491] drm/amdkfd: Track
SDMA utilization per process
config: x86_64-randconfig-s021-20200623 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
git checkout 32cb59f3136248c40062f6fe3edfba13c516b30c
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:140:6:
sparse: sparse: symbol 'increment_queue_count' was not declared. Should it be
static?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:148:6:
sparse: sparse: symbol 'decrement_queue_count' was not declared. Should it be
static?
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
>> sparse: sparse: incorrect type in argument 1 (different address spaces) @@
>> expected void const volatile [noderef] * @@ got unsigned long
>> long [usertype] * @@
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
>> sparse: expected void const volatile [noderef] *
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
sparse: got unsigned long long [usertype] *
vim +172 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c
155
156 int read_sdma_queue_counter(struct queue *q, uint64_t *val)
157 {
158 int ret;
159 uint64_t tmp = 0;
160
161 if (!q || !val)
162 return -EINVAL;
163 /*
164 * SDMA activity counter is stored at queue's RPTR + 0x8
location.
165 */
166 if (!access_ok((const void __user
*)((uint64_t)q->properties.read_ptr +
167 sizeof(uint64_t)),
sizeof(uint64_t))) {
168 pr_err("Can't access sdma queue activity counter\n");
169 return -EFAULT;
170 }
171
> 172 ret = get_user(tmp, (uint64_t
> *)((uint64_t)(q->properties.read_ptr) +
173 sizeof(uint64_t)));
174 if (!ret) {
175 *val = tmp;
176 }
177
178 return ret;
179 }
180
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Wed, 17 Jun 2020 10:59:29 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> 'amdgpu_amdkfd_gpuvm_free_memory_of_gpu':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1357:2: error: implicit
> declaration of function 'drm_gem_object_put_unlocked'; did you mean
> 'drm_gem_object_put_locked'? [-Werror=implicit-function-declaration]
> 1357 | drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> | ^~~
> | drm_gem_object_put_locked
>
> Caused by commit
>
> ab15d56e27be ("drm: remove transient drm_gem_object_put_unlocked()")
>
> interacting with commit
>
> fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
>
> from Linus' tree.
>
> I have applied the following merge fix up patch for today.
>
> From: Stephen Rothwell
> Date: Wed, 17 Jun 2020 10:55:32 +1000
> Subject: [PATCH] drm/amdgpu: remove stray drm_gem_object_put_unlocked
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index b91b5171270f..9015c7b76d60 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1354,7 +1354,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
> }
>
> /* Free the BO*/
> - drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> + drm_gem_object_put(&mem->bo->tbo.base);
> mutex_destroy(&mem->lock);
> kfree(mem);
>
> --
> 2.26.2
This fix is now needed when I merge the drm tree :-(
Given that the drm tree is based on v5.8-rc2 and the commit from Linus'
tree above was merged before v5.8-rc1, the above patch should be
applied to the drm tree (and should have been part of the patch that
merged the drm-misc tree). I am a bit suprised that the drm tree
currently passes CI.
Sorry, Dave, for not cc'ing you in the original report.
--
Cheers,
Stephen Rothwell
pgp2tmS2ARp4L.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
Hi Sam,
On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> > The DRM CRTC helpers add default modes to connectors in the connected
> > state if no mode can be retrieved from the connector. This behaviour is
> > useful for VGA or DVI outputs that have no connected DDC bus. However,
> > in such cases, the status of the output usually can't be retrieved and
> > is reported as connector_status_unknown.
> >
> > Extend the addition of default modes to connectors in an unknown state
> > to support outputs that can retrieve neither the modes nor the
> > connection status.
> >
> > Signed-off-by: Laurent Pinchart
>
> From your description sounds like an OK approach.
> But this is not something I feel too familiar with.
> Acked-by: Sam Ravnborg
Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback on this
too.
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > include/drm/drm_modeset_helper_vtables.h | 8 +++-
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index f5d141e0400f..9055d9573c90 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -491,7 +491,8 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > if (count == 0 && connector->status == connector_status_connected)
> > count = drm_add_override_edid_modes(connector);
> >
> > - if (count == 0 && connector->status == connector_status_connected)
> > + if (count == 0 && (connector->status == connector_status_connected ||
> > + connector->status == connector_status_unknown))
> > count = drm_add_modes_noedid(connector, 1024, 768);
> > count += drm_helper_probe_add_cmdline_mode(connector);
> > if (count == 0)
> > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 421a30f08463..afe55e2e93d2 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
> > * The usual way to implement this is to cache the EDID retrieved in the
> > * probe callback somewhere in the driver-private connector structure.
> > * In this function drivers then parse the modes in the EDID and add
> > -* them by calling drm_add_edid_modes(). But connectors that driver a
> > +* them by calling drm_add_edid_modes(). But connectors that drive a
> > * fixed panel can also manually add specific modes using
> > * drm_mode_probed_add(). Drivers which manually add modes should also
> > * make sure that the &drm_connector.display_info,
> > * &drm_connector.width_mm and &drm_connector.height_mm fields are
> > * filled in.
> > *
> > +* Note that the caller function will automatically add standard VESA
> > +* DMT modes up to 1024x768 if the .get_modes() helper operation returns
> > +* no mode and if the connector status is connector_status_connected or
> > +* connector_status_unknown. There is no need to call
> > +* drm_add_edid_modes() manually in that case.
> > +*
> > * Virtual drivers that just want some standard VESA mode with a given
> > * resolution can call drm_add_modes_noedid(), and mark the preferred
> > * one using drm_set_preferred_mode().
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #22 from Duncan (1i5t5.dun...@cox.net) --- (In reply to rtmasura+kernel from comment #21) > OK. I've uninstalled the vast majority of KDE and am using a vanilla XFCE4. > It's been about 12 hours on 5.7.4-arch1-1 and I have yet to have a crash. It > is looking like it may be something with KDE. Note that it is possible to run kwin (kwin_x11 being the actual executable) on another desktop, or conversely, a different WM on plasma. To run kwin and make it replace the existing WM you'd simply type in (in the xfce runner or terminal window, it can be done from a different VT as well but then you gotta feed kwin the display information too) kwin_x11 --replace. Presumably other WMs have a similar command-line option. I've never actually done it on a non-plasma desktop (tho I run live-git plasma and frameworks so I must always be prepared to restart it or various other plasma components, to the point I have non-kde-invoked shortcuts setup to do it there), but I /think/ kwin would continue to use the configuration setup on kde, the various window rules, configured kwin keyboard shortcuts and effects, etc. That could prove whether it's actually kwin triggering or not (tho it's a kernel bug regardless), tho I suspect the proof is academic at this point given that you've demonstrated that the trigger does appear to be kde/plasma related, at least. IMO kwin triggering is a reasonably safe assumption given that. But it does explain why the bug isn't widely reported, plasma being the apparent biggest trigger and limited to specific now older generations of hardware means few people, even of those running the latest kernels, are going to see it. Meanwhile, I actually got a log-dump on the 4th crash of the kernel at that bisect step, confirming it is indeed this bug, and have advanced a bisect step. But git says I still have ~11 steps, 1000+ commits, so it's still well too large to start trying to pick out candidate buggy commits from the remainder. Slow going indeed. At this rate a full bisect and fix could well be after 5.8 release, giving us two full bad release cycles and kernels before a fix. Not good. =:^( -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
On Wed, Jun 24, 2020 at 12:31 AM Dave Chinner wrote:
>
> On Sun, Jun 21, 2020 at 01:42:05PM -0400, Qian Cai wrote:
> > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > > to use to keep the excessive caches in check). For mmu notifier
> > > recursions we do have lockdep annotations since 23b68395c7c7
> > > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> > >
> > > But these only fire if a path actually results in some pte
> > > invalidation - for most small allocations that's very rarely the case.
> > > The other trouble is that pte invalidation can happen any time when
> > > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > > recursion.
> > >
> > > I was pondering whether we should just do the general annotation, but
> > > there's always the risk for false positives. Plus I'm assuming that
> > > the core fs and io code is a lot better reviewed and tested than
> > > random mmu notifier code in drivers. Hence why I decide to only
> > > annotate for that specific case.
> > >
> > > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > > still need to explicit pull in the mmu notifier map - there's a lot
> > > more places that do pte invalidation than just direct reclaim, these
> > > two contexts arent the same.
> > >
> > > Note that the mmu notifiers needing their own independent lockdep map
> > > is also the reason we can't hold them from fs_reclaim_acquire to
> > > fs_reclaim_release - it would nest with the acquistion in the pte
> > > invalidation code, causing a lockdep splat. And we can't remove the
> > > annotations from pte invalidation and all the other places since
> > > they're called from many other places than page reclaim. Hence we can
> > > only do the equivalent of might_lock, but on the raw lockdep map.
> > >
> > > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > > strictly more powerful.
> > >
> > > v2: Review from Thomas Hellstrom:
> > > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > > but it didn't blow up because I inverted it immediately
> > > - fix compiling for !CONFIG_MMU_NOTIFIER
> > >
> > > Cc: Thomas Hellström (Intel)
> > > Cc: Andrew Morton
> > > Cc: Jason Gunthorpe
> > > Cc: linux...@kvack.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: Maarten Lankhorst
> > > Cc: Christian König
> > > Signed-off-by: Daniel Vetter
> >
> > Replying the right patch here...
> >
> > Reverting this commit [1] fixed the lockdep warning below while applying
> > some memory pressure.
> >
> > [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in
> > fs_reclaim_acquire/release")
> >
> > [ 190.455003][ T369] WARNING: possible circular locking dependency
> > detected
> > [ 190.487291][ T369] 5.8.0-rc1-next-20200621 #1 Not tainted
> > [ 190.512363][ T369]
> > --
> > [ 190.543354][ T369] kswapd3/369 is trying to acquire lock:
> > [ 190.568523][ T369] 889fcf694528
> > (&xfs_nondir_ilock_class){}-{3:3}, at: xfs_reclaim_inode+0xdf/0x860
> > spin_lock at include/linux/spinlock.h:353
> > (inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
> > (inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
> > (inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
> > [ 190.614359][ T369]
> > [ 190.614359][ T369] but task is already holding lock:
> > [ 190.647763][ T369] b50ced00 (fs_reclaim){+.+.}-{0:0}, at:
> > __fs_reclaim_acquire+0x0/0x30
> > __fs_reclaim_acquire at mm/page_alloc.c:4200
> > [ 190.687845][ T369]
> > [ 190.687845][ T369] which lock already depends on the new lock.
> > [ 190.687845][ T369]
> > [ 190.734890][ T369]
> > [ 190.734890][ T369] the existing dependency chain (in reverse order) is:
> > [ 190.775991][ T369]
> > [ 190.775991][ T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
> > [ 190.808150][ T369]fs_reclaim_acquire+0x77/0x80
> > [ 190.832152][ T369]slab_pre_alloc_hook.constprop.52+0x20/0x120
> > slab_pre_alloc_hook at mm/slab.h:507
> > [ 190.862173][ T369]kmem_cache_alloc+0x43/0x2a0
> > [ 190.885602][ T369]kmem_zone_alloc+0x113/0x3ef
> > kmem_zone_alloc at fs/xfs/kmem.c:129
> > [ 190.908702][ T369]xfs_inode_item_init+0x1d/0xa0
> > xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
> > [ 190.934461][ T369]xfs_trans_ijoin+0x96/0x100
> > xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
> > [ 190.961530][ T369]xfs_setattr_nonsize+0x1a6/0xcd0
>
> OK, this patch has royally screwed something up if this path thinks
> it can enter memory reclaim. This path is inside a transaction, so
> it is run
Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
On Tue, Jun 23, 2020 at 6:18 PM Qian Cai wrote:
>
> On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> > > >
> > > > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > > > > to use to keep the excessive caches in check). For mmu notifier
> > > > > recursions we do have lockdep annotations since 23b68395c7c7
> > > > > ("mm/mmu_notifiers: add a lockdep map for
> > > > > invalidate_range_start/end").
> > > > >
> > > > > But these only fire if a path actually results in some pte
> > > > > invalidation - for most small allocations that's very rarely the case.
> > > > > The other trouble is that pte invalidation can happen any time when
> > > > > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > > > > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > > > > recursion.
> > > > >
> > > > > I was pondering whether we should just do the general annotation, but
> > > > > there's always the risk for false positives. Plus I'm assuming that
> > > > > the core fs and io code is a lot better reviewed and tested than
> > > > > random mmu notifier code in drivers. Hence why I decide to only
> > > > > annotate for that specific case.
> > > > >
> > > > > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > > > > still need to explicit pull in the mmu notifier map - there's a lot
> > > > > more places that do pte invalidation than just direct reclaim, these
> > > > > two contexts arent the same.
> > > > >
> > > > > Note that the mmu notifiers needing their own independent lockdep map
> > > > > is also the reason we can't hold them from fs_reclaim_acquire to
> > > > > fs_reclaim_release - it would nest with the acquistion in the pte
> > > > > invalidation code, causing a lockdep splat. And we can't remove the
> > > > > annotations from pte invalidation and all the other places since
> > > > > they're called from many other places than page reclaim. Hence we can
> > > > > only do the equivalent of might_lock, but on the raw lockdep map.
> > > > >
> > > > > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > > > > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > > > > strictly more powerful.
> > > > >
> > > > > v2: Review from Thomas Hellstrom:
> > > > > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > > > > but it didn't blow up because I inverted it immediately
> > > > > - fix compiling for !CONFIG_MMU_NOTIFIER
> > > > >
> > > > > Cc: Thomas Hellström (Intel)
> > > > > Cc: Andrew Morton
> > > > > Cc: Jason Gunthorpe
> > > > > Cc: linux...@kvack.org
> > > > > Cc: linux-r...@vger.kernel.org
> > > > > Cc: Maarten Lankhorst
> > > > > Cc: Christian König
> > > > > Signed-off-by: Daniel Vetter
> > > >
> > > > Replying the right patch here...
> > > >
> > > > Reverting this commit [1] fixed the lockdep warning below while applying
> > > > some memory pressure.
> > > >
> > > > [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in
> > > > fs_reclaim_acquire/release")
> > >
> > > Hm, then I'm confused because
> > > - there's not mmut notifier lockdep map in the splat at a..
> > > - the patch is supposed to not change anything for fs_reclaim (but the
> > > interim version got that wrong)
> > > - looking at the paths it's kmalloc vs kswapd, both places I totally
> > > expect fs_reflaim to be used.
> > >
> > > But you're claiming reverting this prevents the lockdep splat. If
> > > that's right, then my reasoning above is broken somewhere. Someone
> > > less blind than me having an idea?
> > >
> > > Aside this is the first email I've typed, until I realized the first
> > > report was against the broken patch and that looked like a much more
> > > reasonable explanation (but didn't quite match up with the code
> > > paths).
> >
> > Below diff should undo the functional change in my patch. Can you pls test
> > whether the lockdep splat is really gone with that? Might need a lot of
> > testing and memory pressure to be sure, since all these reclaim paths
> > aren't very deterministic.
>
> No, this patch does not help but reverting the whole patch still fixed
> the splat.
Ok I tested this. I can't use your script to repro because
- I don't have a setup with xfs, and the splat points at an issue in xfs
- reproducing lockdep splats in shrinker callbacks is always a bit tricky
So instead I made a quick test to validate whether the fs_reclaim
annotations work correctly, and nothing has changed:
+ printk("GFP_NOFS block\n");
+ fs_reclaim_acquire(GFP_NOFS);
+ printk("allocate atomic\n");
+ kfree(kmalloc(16, GFP_ATOMIC));
+ printk("allocate noio\n");
+ kfree(kmalloc(16, GFP_
[radeon-alex:drm-next 41/491] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15: sparse: got unsigned long long COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS M
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: fadef51a438279ca660dbce31c26e787d6680149
commit: 32cb59f3136248c40062f6fe3edfba13c516b30c [41/491] drm/amdkfd: Track
SDMA utilization per process
config: x86_64-randconfig-s021-20200623 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
git checkout 32cb59f3136248c40062f6fe3edfba13c516b30c
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:140:6:
sparse: sparse: symbol 'increment_queue_count' was not declared. Should it be
static?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:148:6:
sparse: sparse: symbol 'decrement_queue_count' was not declared. Should it be
static?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
sparse: sparse: incorrect type in argument 1 (different address spaces) @@
expected void const volatile [noderef] * @@ got unsigned long long
[usertype] * @@
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
sparse: expected void const volatile [noderef] *
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
>> sparse: got unsigned long long [usertype] *
vim +172 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c
155
156 int read_sdma_queue_counter(struct queue *q, uint64_t *val)
157 {
158 int ret;
159 uint64_t tmp = 0;
160
161 if (!q || !val)
162 return -EINVAL;
163 /*
164 * SDMA activity counter is stored at queue's RPTR + 0x8
location.
165 */
166 if (!access_ok((const void __user
*)((uint64_t)q->properties.read_ptr +
167 sizeof(uint64_t)),
sizeof(uint64_t))) {
168 pr_err("Can't access sdma queue activity counter\n");
169 return -EFAULT;
170 }
171
> 172 ret = get_user(tmp, (uint64_t
> *)((uint64_t)(q->properties.read_ptr) +
173 sizeof(uint64_t)));
174 if (!ret) {
175 *val = tmp;
176 }
177
178 return ret;
179 }
180
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amd: fix potential memleak in err branch
Am 2020-06-20 um 4:54 a.m. schrieb Bernard Zhao:
> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These changes are to add kobject_put in kobject_init_and_add
> failed branch, fix potential memleak.
>
> Signed-off-by: Bernard Zhao
The patch is
Reviewed-by: Felix Kuehling
I'll apply it to amd-staging-drm-next.
Thanks,
Felix
> ---
> Changes since V1:
> *Remove duplicate changed file kfd_topology.c, this file`s fix
> already applied to the main line.
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index d27221ddcdeb..5ee4d6cfb16d 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -124,6 +124,7 @@ void kfd_procfs_init(void)
> if (ret) {
> pr_warn("Could not create procfs proc folder");
> /* If we fail to create the procfs, clean up */
> + kobject_put(procfs.kobj);
> kfd_procfs_shutdown();
> }
> }
> @@ -428,6 +429,7 @@ struct kfd_process *kfd_create_process(struct file *filep)
> (int)process->lead_thread->pid);
> if (ret) {
> pr_warn("Creating procfs pid directory failed");
> + kobject_put(process->kobj);
> goto out;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Tue, Jun 23, 2020 at 02:44:24PM -0400, Felix Kuehling wrote: > Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter: > > On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling > > wrote: > >> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > >>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > > I still have my doubts about allowing fence waiting from within > > shrinkers. > > IMO ideally they should use a trywait approach, in order to allow memory > > allocation during command submission for drivers that > > publish fences before command submission. (Since early reservation > > object > > release requires that). > Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > with a mempool to make sure it can handle it's allocations. > > > But since drivers are already waiting from within shrinkers and I take > > your > > word for HMM requiring this, > Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > one, the shrinker one is a lot less established. > >>> I really question if HW that needs something like DMA fence should > >>> even be using mmu notifiers - the best use is HW that can fence the > >>> DMA directly without having to get involved with some command stream > >>> processing. > >>> > >>> Or at the very least it should not be a generic DMA fence but a > >>> narrowed completion tied only into the same GPU driver's command > >>> completion processing which should be able to progress without > >>> blocking. > >>> > >>> The intent of notifiers was never to endlessly block while vast > >>> amounts of SW does work. > >>> > >>> Going around and switching everything in a GPU to GFP_ATOMIC seems > >>> like bad idea. > >>> > I've pinged a bunch of armsoc gpu driver people and ask them how much > this > hurts, so that we have a clear answer. On x86 I don't think we have much > of a choice on this, with userptr in amd and i915 and hmm work in nouveau > (but nouveau I think doesn't use dma_fence in there). > >> Soon nouveau will get company. We're working on a recoverable page fault > >> implementation for HMM in amdgpu where we'll need to update page tables > >> using the GPUs SDMA engine and wait for corresponding fences in MMU > >> notifiers. > > Can you pls cc these patches to dri-devel when they show up? Depending > > upon how your hw works there's and endless amount of bad things that > > can happen. > > Yes, I'll do that. > > > > > > Also I think (again depending upon how the hw exactly works) this > > stuff would be a perfect example for the dma_fence annotations. > > We have already applied your patch series to our development branch. I > haven't looked into what annotations we'd have to add to our new code yet. > > > > > > The worst case is if your hw cannot preempt while a hw page fault is > > pending. That means none of the dma_fence will ever signal (the amdkfd > > preempt ctx fences wont, and the classic fences from amdgpu might be > > also stall). At least when you're unlucky and the fence you're waiting > > on somehow (anywhere in its dependency chain really) need the engine > > that's currently blocked waiting for the hw page fault. > > Our HW can preempt while handling a page fault, at least on the GPU > generation we're working on now. On other GPUs we haven't included in > our initial effort, we will not be able to preempt while a page fault is > in progress. This is problematic, but that's for reasons related to our > GPU hardware scheduler and unrelated to fences. Well the trouble is if the page fault holds up a preempt, then there's no way for a dma_fence to complete while your hw page fault handler is stuck doing whatever. That means the entire hw page fault becomes a fence signalling critical section, with the consequence that there's almost nothing you can actually do. System memory becomes GFP_ATOMIC only, and for vram you need to make sure that you never evict anything that might be in active use. So not enabling these platforms sounds like a very good plan to me :-) > > That in turn means anything you do in your hw page fault handler is in > > the critical section for dma fence signalling, which has far reaching > > implications. > > I'm not sure I agree, at least for KFD. The only place where KFD uses > fences that depend on preemptions is eviction fences. And we can get rid > of those if we can preempt GPU access to specific BOs by invalidating > GPU PTEs. That way we don't need to preempt the GPU queues while a page > fault is in progress. Instead we would create more page faults. The big problem isn't pure kfd workloads, all the trouble comes in when you mix kfd and amdgpu workloads. kfd alone is easy, just make sure there's no fences to begin with, and there will be no problems. > That assumes that we can invalidate GPU PTEs without depending on > fences. We've discussed possible deadlocks due to memory allocations > neede
Re: [PATCH 00/27] Converter R-Car DU to the DRM bridge connector helper
Hi Laurent. On Tue, May 26, 2020 at 04:14:38AM +0300, Laurent Pinchart wrote: > Hello, > > This patch series converts the R-Car DU driver to use the DRM bridge > connector helper drm_bridge_connector_init(). > > The bulk of the series is conversion of the adv7511, simple-bridge, > rcar-lbds and dw-hdmi drivers to make connector creation optional > (through the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag). > > The series starts with the adv7511 driver, previously posted as "[PATCH > 0/4] drm: bridge: adv7511: Enable usage with DRM bridge connector > helper" ([1]). Patches 01/27 to 04/27 incorporate all the received > review comments. > > The next three patches address the simple-bridge driver, previously > posted as "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage with DRM > bridge connector helper". Patch 05/27 is an additional fix that stems > from the review, and patches 06/27 and 07/27 incorporate all the > received review comments. > > Patch 08/27 is a new patch that addresses the rcar-lvds driver. Instead > of implementing direct support for DRM_BRIDGE_ATTACH_NO_CONNECTOR, it > simply removes code that shouldn't have been in the driver in the first > place by switching to the panel bridge helper. > > Patches 09/27 to 22/27 then address the dw-hdmi driver. That's a more > sizeable rework, due to the fact that the driver implements a mid-layer > for platform-specific glue, with the internal drm_connector being used > throughout the whole code. There's no rocket science there, but patch > 10/27 should be noted for adding a new argument to the > drm_bridge_funcs.mode_valid() function. Please see individual patches > for details. > > Patch 23/27 adds support to the dw-hdmi driver to attach to a downstream > bridge if one is specified in DT. As the DT port number corresponding to > the video output differs between platforms that integrate the dw-hdmi > (some of them even don't have a video output port, which should probably > be fixed, but that's out of scope for this series), the port number has > to be specified by the platform glue layer. Patch 24/27 does so for the > R-Car dw-hdmi driver. > > Patch 25/27 is a drive-by fix for an error path issue in the rcar-du > driver. Patch 26/27 finally makes use of the drm_bridge_connector_init() > helper. > > Unfortunately, this breaks the VGA output on R-Car Gen3 platforms. On > those platforms, the VGA DDC lines are not connected, and there is no > mean for software to detect the VGA output connection status. When the > simple-bridge driver creates a connector, it automatically adds default > modes when no DDC is available. This behavious is also present int the > DRM probe helper drm_helper_probe_single_connector_modes(), but only > when the connector status is connector_status_connected. As the driver > (rightfully) reports connector_status_unconnected, no modes are added. > Patch 27/27 fixes this issue by extending addition of default modes in > drm_helper_probe_single_connector_modes() when the output status is > unknown. An alternative approach would be to implement this behaviour in > the bridge connector helper (drm_bridge_connector.c). > > All the modified drivers have been compile-tested, and the series has > been tested on a Renesas R-Car Salvator-XS board with the VGA, HDMI and > LVDS outputs. > > [1] > https://lore.kernel.org/dri-devel/20200409004610.12346-1-laurent.pinchart+rene...@ideasonboard.com/ > [2] > https://lore.kernel.org/dri-devel/20200409003636.11792-1-laurent.pinchart+rene...@ideasonboard.com/ As we briefly discussed on IRC the first 21 patches are now applied to drm-misc-next. The rcar-du specific patches was left out and the last patch was likewise not applied in this round- mostly because it was the coming after several rcar-du patches and I was not sure if there was some dependencies to consider. With this set in we have more examples in the tree how to do proper bridges which is good. While applying the new r-bs was ofc added. Sam > > Laurent Pinchart (27): > drm: bridge: adv7511: Split EDID read to a separate function > drm: bridge: adv7511: Split connector creation to a separate function > drm: bridge: adv7511: Implement bridge connector operations > drm: bridge: adv7511: Make connector creation optional > drm: bridge: Return NULL on error from drm_bridge_get_edid() > drm: bridge: simple-bridge: Delegate operations to next bridge > drm: bridge: simple-bridge: Make connector creation optional > drm: rcar-du: lvds: Convert to DRM panel bridge helper > drm: edid: Constify connector argument to infoframe functions > drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid() > drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid() > drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy() > drm: bridge: dw-hdmi: Remove unused field from dw_hdmi_plat_data > drm: meson: dw-hdmi: Use dw_hdmi context to replace hack > drm: bridge: dw-hdmi: Pass drm_display
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter: > On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote: >> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: >>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > I still have my doubts about allowing fence waiting from within shrinkers. > IMO ideally they should use a trywait approach, in order to allow memory > allocation during command submission for drivers that > publish fences before command submission. (Since early reservation object > release requires that). Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up with a mempool to make sure it can handle it's allocations. > But since drivers are already waiting from within shrinkers and I take > your > word for HMM requiring this, Yeah the big trouble is HMM and mmu notifiers. That's the really awkward one, the shrinker one is a lot less established. >>> I really question if HW that needs something like DMA fence should >>> even be using mmu notifiers - the best use is HW that can fence the >>> DMA directly without having to get involved with some command stream >>> processing. >>> >>> Or at the very least it should not be a generic DMA fence but a >>> narrowed completion tied only into the same GPU driver's command >>> completion processing which should be able to progress without >>> blocking. >>> >>> The intent of notifiers was never to endlessly block while vast >>> amounts of SW does work. >>> >>> Going around and switching everything in a GPU to GFP_ATOMIC seems >>> like bad idea. >>> I've pinged a bunch of armsoc gpu driver people and ask them how much this hurts, so that we have a clear answer. On x86 I don't think we have much of a choice on this, with userptr in amd and i915 and hmm work in nouveau (but nouveau I think doesn't use dma_fence in there). >> Soon nouveau will get company. We're working on a recoverable page fault >> implementation for HMM in amdgpu where we'll need to update page tables >> using the GPUs SDMA engine and wait for corresponding fences in MMU >> notifiers. > Can you pls cc these patches to dri-devel when they show up? Depending > upon how your hw works there's and endless amount of bad things that > can happen. Yes, I'll do that. > > Also I think (again depending upon how the hw exactly works) this > stuff would be a perfect example for the dma_fence annotations. We have already applied your patch series to our development branch. I haven't looked into what annotations we'd have to add to our new code yet. > > The worst case is if your hw cannot preempt while a hw page fault is > pending. That means none of the dma_fence will ever signal (the amdkfd > preempt ctx fences wont, and the classic fences from amdgpu might be > also stall). At least when you're unlucky and the fence you're waiting > on somehow (anywhere in its dependency chain really) need the engine > that's currently blocked waiting for the hw page fault. Our HW can preempt while handling a page fault, at least on the GPU generation we're working on now. On other GPUs we haven't included in our initial effort, we will not be able to preempt while a page fault is in progress. This is problematic, but that's for reasons related to our GPU hardware scheduler and unrelated to fences. > > That in turn means anything you do in your hw page fault handler is in > the critical section for dma fence signalling, which has far reaching > implications. I'm not sure I agree, at least for KFD. The only place where KFD uses fences that depend on preemptions is eviction fences. And we can get rid of those if we can preempt GPU access to specific BOs by invalidating GPU PTEs. That way we don't need to preempt the GPU queues while a page fault is in progress. Instead we would create more page faults. That assumes that we can invalidate GPU PTEs without depending on fences. We've discussed possible deadlocks due to memory allocations needed on that code paths for IBs or page tables. We've already eliminated page table allocations and reservation locks on the PTE invalidation code path. And we're using a separate scheduler entity so we can't get stuck behind other IBs that depend on fences. IIRC, Christian also implemented a separate memory pool for IBs for this code path. Regards, Felix > -Daniel > >> Regards, >> Felix >> >> >>> Right, nor will RDMA ODP. >>> >>> Jason >>> ___ >>> amd-gfx mailing list >>> amd-...@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 03/15] drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()
From: Denis Efremov [ Upstream commit 43a562774fceba867e8eebba977d7d42f8a2eac7 ] Use kfree() instead of kvfree() to free rgb_user in calculate_user_regamma_ramp() because the memory is allocated with kcalloc(). Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 962900932beed..11ea1a0e629bd 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1561,7 +1561,7 @@ bool calculate_user_regamma_ramp(struct dc_transfer_func *output_tf, kfree(rgb_regamma); rgb_regamma_alloc_fail: - kvfree(rgb_user); + kfree(rgb_user); rgb_user_alloc_fail: return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 03/24] drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()
From: Denis Efremov [ Upstream commit 43a562774fceba867e8eebba977d7d42f8a2eac7 ] Use kfree() instead of kvfree() to free rgb_user in calculate_user_regamma_ramp() because the memory is allocated with kcalloc(). Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 2d8f14b691174..9997382b0a025 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1862,7 +1862,7 @@ bool calculate_user_regamma_ramp(struct dc_transfer_func *output_tf, kfree(rgb_regamma); rgb_regamma_alloc_fail: - kvfree(rgb_user); + kfree(rgb_user); rgb_user_alloc_fail: return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.7 03/28] drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()
From: Denis Efremov [ Upstream commit 43a562774fceba867e8eebba977d7d42f8a2eac7 ] Use kfree() instead of kvfree() to free rgb_user in calculate_user_regamma_ramp() because the memory is allocated with kcalloc(). Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index cac09d500fda9..2c2caa7d335c8 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1777,7 +1777,7 @@ bool calculate_user_regamma_ramp(struct dc_transfer_func *output_tf, kfree(rgb_regamma); rgb_regamma_alloc_fail: - kvfree(rgb_user); + kfree(rgb_user); rgb_user_alloc_fail: return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5 02/10] drm/vblank: Add vblank works
On Mon, Jun 22, 2020 at 04:07:22PM -0400, Lyude Paul wrote:
> Add some kind of vblank workers. The interface is similar to regular
> delayed works, and is mostly based off kthread_work. It allows for
> scheduling delayed works that execute once a particular vblank sequence
> has passed. It also allows for accurate flushing of scheduled vblank
> works - in that flushing waits for both the vblank sequence and job
> execution to complete, or for the work to get cancelled - whichever
> comes first.
>
> Whatever hardware programming we do in the work must be fast (must at
> least complete during the vblank or scanout period, sometimes during the
> first few scanlines of the vblank). As such we use a high-priority
> per-CRTC thread to accomplish this.
>
> [based off patches from Ville Syrjälä ,
> change below to signoff later]
>
> Changes since v4:
> * Get rid of kthread interfaces we tried adding and move all of the
> locking into drm_vblank.c. For implementing drm_vblank_work_flush(),
> we now use a wait_queue and sequence counters in order to
> differentiate between multiple work item executions.
> * Get rid of drm_vblank_work_cancel() - this would have been pretty
> difficult to actually reimplement and it occurred to me that neither
> nouveau or i915 are even planning to use this function. Since there's
> also no async cancel function for most of the work interfaces in the
> kernel, it seems a bit unnecessary anyway.
> * Get rid of to_drm_vblank_work() since we now are also able to just
> pass the struct drm_vblank_work to work item callbacks anyway
> Changes since v3:
> * Use our own spinlocks, don't integrate so tightly with kthread_works
> Changes since v2:
> * Use kthread_workers instead of reinventing the wheel.
>
> Cc: Daniel Vetter
> Cc: Tejun Heo
> Cc: Ville Syrjälä
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lyude Paul
Ok, I think this melted my brain a bit, but I tried to review this
carefully. Bunch of suggestions to simplify the flow, but might also
simply be that I missed something and my suggestions dont work at all.
Thanks for doing all this!
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 266 +++
> include/drm/drm_vblank.h | 49 +++
> 2 files changed, 315 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index ce5c1e1d29963..4d76eb2fed5e9 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -25,7 +25,9 @@
> */
>
> #include
> +#include
> #include
> +#include
>
> #include
> #include
> @@ -155,6 +157,8 @@
> static bool
> drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> ktime_t *tvblank, bool in_vblank_irq);
> +static int drm_vblank_get(struct drm_device *dev, unsigned int pipe);
> +static void drm_vblank_put(struct drm_device *dev, unsigned int pipe);
>
> static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
>
> @@ -490,6 +494,35 @@ static void vblank_disable_fn(struct timer_list *t)
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> }
>
> +static void drm_vblank_work_release(struct drm_vblank_crtc *vblank)
> +{
> + struct kthread_worker *worker = vblank->worker;
> + struct drm_vblank_work *work, *tmp;
> + bool wake = false;
> +
> + if (!worker)
> + return;
> +
> + spin_lock_irq(&vblank->work_lock);
> + vblank->worker = NULL;
> +
> + list_for_each_entry_safe(work, tmp, &vblank->pending_work, node) {
> + drm_vblank_put(vblank->dev, vblank->pipe);
> + list_del(&work->node);
> +
> + if (!--work->pending) {
> + write_seqcount_invalidate(&work->seqcount);
> + wake = true;
> + }
> + }
> +
> + spin_unlock_irq(&vblank->work_lock);
> +
> + if (wake)
> + wake_up_all(&vblank->work_wait_queue);
So drmm_ is for cleaning up software stuff, but the above is for cleaning
up vblank callbacks and things. Those should all be cleaned up and stop
after the hardware is gone.
If you look at drm_crtc_vblank_off, that already has code to send out any
pending vblank events. I think that's also where we should clean up any
leaked vblank worker things, to make sure they don't get re-queued. Once
the vblank is off it shouldn't be possible to have new stuff enqueued.
In vblank_off we probably want an additional kthrea_flush_worker() to make
sure nothing spills out.
> + kthread_destroy_worker(worker);
This one looks good here I think, but maybe just inline it since it's
just one line after you moved the cleanup.
> +}
> +
> static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
> {
> struct drm_vblank_crtc *vblank = ptr;
> @@ -497,9 +530,66 @@ static void drm_vblank_init_release(struct drm_device
> *dev, void *ptr)
> drm_WARN_ON(dev, RE
Re: [PATCH 02/14] drm/ast: Pass struct ast_private instance to cursor init/fini functions
Hi Thomas.
On Tue, Jun 23, 2020 at 10:18:49AM +0200, Thomas Zimmermann wrote:
> Removes some typecasting.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_cursor.c | 7 +++
> drivers/gpu/drm/ast/ast_drv.h| 4 ++--
> drivers/gpu/drm/ast/ast_mode.c | 6 --
> 3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> b/drivers/gpu/drm/ast/ast_cursor.c
> index 53bb6eebc7cd..1d4f51a7fe22 100644
> --- a/drivers/gpu/drm/ast/ast_cursor.c
> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> @@ -34,9 +34,9 @@
> /*
> * Allocate cursor BOs and pins them at the end of VRAM.
> */
> -int ast_cursor_init(struct drm_device *dev)
> +int ast_cursor_init(struct ast_private *ast)
> {
> - struct ast_private *ast = to_ast_private(dev);
> + struct drm_device *dev = ast->dev;
> size_t size, i;
> struct drm_gem_vram_object *gbo;
> int ret;
> @@ -72,9 +72,8 @@ int ast_cursor_init(struct drm_device *dev)
> return ret;
> }
>
> -void ast_cursor_fini(struct drm_device *dev)
> +void ast_cursor_fini(struct ast_private *ast)
> {
> - struct ast_private *ast = to_ast_private(dev);
> size_t i;
> struct drm_gem_vram_object *gbo;
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 245ed2e2d775..f7b120f862a8 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -316,8 +316,8 @@ void ast_init_3rdtx(struct drm_device *dev);
> void ast_release_firmware(struct drm_device *dev);
>
> /* ast_cursor.c */
> -int ast_cursor_init(struct drm_device *dev);
> -void ast_cursor_fini(struct drm_device *dev);
> +int ast_cursor_init(struct ast_private *ast);
> +void ast_cursor_fini(struct ast_private *ast);
> int ast_cursor_update(void *dst, void *src, unsigned int width,
> unsigned int height);
> void ast_cursor_set_base(struct ast_private *ast, u64 address);
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index c8399699d773..243715e9c237 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -1149,7 +1149,7 @@ int ast_mode_init(struct drm_device *dev)
> drm_plane_helper_add(&ast->cursor_plane,
>&ast_cursor_plane_helper_funcs);
>
> - ast_cursor_init(dev);
> + ast_cursor_init(ast);
> ast_crtc_init(dev);
> ast_encoder_init(dev);
> ast_connector_init(dev);
> @@ -1159,7 +1159,9 @@ int ast_mode_init(struct drm_device *dev)
>
> void ast_mode_fini(struct drm_device *dev)
> {
> - ast_cursor_fini(dev);
> + struct ast_private *ast = dev->dev_private;
Better to use to_ast_private(dev), to avoid the deprecated dev_private.
With this fixed:
Acked-by: Sam Ravnborg
> +
> + ast_cursor_fini(ast);
> }
>
> static int get_clock(void *i2c_priv)
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/14] drm/ast: Move cursor functions to ast_cursor.c
Hi Thomas.
On Tue, Jun 23, 2020 at 10:18:48AM +0200, Thomas Zimmermann wrote:
> The cursor manipulation functions are unrelated to modesetting. Move
> them into their own file.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/Makefile | 3 +-
> drivers/gpu/drm/ast/ast_cursor.c | 218 +++
> drivers/gpu/drm/ast/ast_drv.h| 9 ++
> drivers/gpu/drm/ast/ast_mode.c | 195 ---
> 4 files changed, 229 insertions(+), 196 deletions(-)
> create mode 100644 drivers/gpu/drm/ast/ast_cursor.c
>
> diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
> index 561f7c4199e4..6a5b3b247316 100644
> --- a/drivers/gpu/drm/ast/Makefile
> +++ b/drivers/gpu/drm/ast/Makefile
> @@ -3,6 +3,7 @@
> # Makefile for the drm device driver. This driver provides support for the
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> -ast-y := ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o ast_dp501.o
> +ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
> + ast_dp501.o
>
> obj-$(CONFIG_DRM_AST) := ast.o
> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> b/drivers/gpu/drm/ast/ast_cursor.c
> new file mode 100644
> index ..53bb6eebc7cd
> --- /dev/null
> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> @@ -0,0 +1,218 @@
> +/*
> + * Copyright 2012 Red Hat Inc.
> + * Parts based on xf86-video-ast
> + * Copyright (c) 2005 ASPEED Technology Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
> CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
SPDX for new files?
I guess this boilerplate was copied from the old file.
Acked-by: Sam Ravnborg
> + */
> +/*
> + * Authors: Dave Airlie
> + */
> +
> +#include
> +
> +#include "ast_drv.h"
> +
> +/*
> + * Allocate cursor BOs and pins them at the end of VRAM.
> + */
> +int ast_cursor_init(struct drm_device *dev)
> +{
> + struct ast_private *ast = to_ast_private(dev);
> + size_t size, i;
> + struct drm_gem_vram_object *gbo;
> + int ret;
> +
> + size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
> +
> + for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
> + gbo = drm_gem_vram_create(dev, size, 0);
> + if (IS_ERR(gbo)) {
> + ret = PTR_ERR(gbo);
> + goto err_drm_gem_vram_put;
> + }
> + ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
> + DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
> + if (ret) {
> + drm_gem_vram_put(gbo);
> + goto err_drm_gem_vram_put;
> + }
> +
> + ast->cursor.gbo[i] = gbo;
> + }
> +
> + return 0;
> +
> +err_drm_gem_vram_put:
> + while (i) {
> + --i;
> + gbo = ast->cursor.gbo[i];
> + drm_gem_vram_unpin(gbo);
> + drm_gem_vram_put(gbo);
> + ast->cursor.gbo[i] = NULL;
> + }
> + return ret;
> +}
> +
> +void ast_cursor_fini(struct drm_device *dev)
> +{
> + struct ast_private *ast = to_ast_private(dev);
> + size_t i;
> + struct drm_gem_vram_object *gbo;
> +
> + for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
> + gbo = ast->cursor.gbo[i];
> + drm_gem_vram_unpin(gbo);
> + drm_gem_vram_put(gbo);
> + }
> +}
> +
> +static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
> +{
> + union {
> + u32 ul;
> + u8 b[4];
> + } srcdata32[2], data32;
> + union {
> + u16 us;
> + u8 b[2];
> + } data16;
> + u32 csum = 0;
> + s32 alpha_dst_delta, last_alpha_dst_delta;
> + u8 *srcxor, *dstxor;
> + int i, j;
> + u32 per_pixel_copy, two_pixel_copy;
> +
> + alpha_dst_delta = AST_MAX_HWC_WIDTH << 1;
> + l
Re: [PATCH] drm/radeon: fix fb_div check in ni_init_smc_spll_table()
On Mon, Jun 22, 2020 at 5:56 PM Denis Efremov wrote:
>
> clk_s is checked twice in a row in ni_init_smc_spll_table().
> fb_div should be checked instead.
>
> Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Denis Efremov
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/ni_dpm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
> index b57c37ddd164..c7fbb7932f37 100644
> --- a/drivers/gpu/drm/radeon/ni_dpm.c
> +++ b/drivers/gpu/drm/radeon/ni_dpm.c
> @@ -2127,7 +2127,7 @@ static int ni_init_smc_spll_table(struct radeon_device
> *rdev)
> if (clk_s & ~(SMC_NISLANDS_SPLL_DIV_TABLE_CLKS_MASK >>
> SMC_NISLANDS_SPLL_DIV_TABLE_CLKS_SHIFT))
> ret = -EINVAL;
>
> - if (clk_s & ~(SMC_NISLANDS_SPLL_DIV_TABLE_CLKS_MASK >>
> SMC_NISLANDS_SPLL_DIV_TABLE_CLKS_SHIFT))
> + if (fb_div & ~(SMC_NISLANDS_SPLL_DIV_TABLE_FBDIV_MASK >>
> SMC_NISLANDS_SPLL_DIV_TABLE_FBDIV_SHIFT))
> ret = -EINVAL;
>
> if (clk_v & ~(SMC_NISLANDS_SPLL_DIV_TABLE_CLKV_MASK >>
> SMC_NISLANDS_SPLL_DIV_TABLE_CLKV_SHIFT))
> --
> 2.26.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #19 from Lyude Paul (ly...@redhat.com) --- Hi! Ben Skeggs pushed a fix for this to their kernel repository: https://github.com/skeggsb/nouveau/commit/2b9345f98be41e2145f561f6cfecc99686f4ef71.patch You should be able to apply it (you will need to pass --directory=drivers/gpu/ to git am for it to apply), would you mind testing this and letting me know if it fixes your issue? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Fix direction check in psb_accel_2d_copy()
On Mon, Jun 22, 2020 at 10:45 PM Denis Efremov wrote:
>
> psb_accel_2d_copy() checks direction PSB_2D_COPYORDER_BR2TL twice.
> Based on psb_accel_2d_copy_direction() results, PSB_2D_COPYORDER_TL2BR
> should be checked instead in the second direction check.
>
> Fixes: 4d8d096e9ae8 ("gma500: introduce the framebuffer support code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Denis Efremov
> ---
> drivers/gpu/drm/gma500/accel_2d.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/accel_2d.c
> b/drivers/gpu/drm/gma500/accel_2d.c
> index adc0507545bf..8dc86aac54d2 100644
> --- a/drivers/gpu/drm/gma500/accel_2d.c
> +++ b/drivers/gpu/drm/gma500/accel_2d.c
> @@ -179,8 +179,8 @@ static int psb_accel_2d_copy(struct drm_psb_private
> *dev_priv,
> src_x += size_x - 1;
> dst_x += size_x - 1;
> }
> - if (direction == PSB_2D_COPYORDER_BR2TL ||
> - direction == PSB_2D_COPYORDER_BL2TR) {
> + if (direction == PSB_2D_COPYORDER_BL2TR ||
> + direction == PSB_2D_COPYORDER_TL2BR) {
Hi Denis,
Sorry, I don't follow. The code seems already correct to me.
src_x and dst_x gets adjusted when going from right to left
src_y and dst_y gets adjusted when going from bottom to top.
PSB_2D_COPYORDER_TL2BR needs no adjustment because it is the normal
blit direction.
Thanks
Patrik
> src_y += size_y - 1;
> dst_y += size_y - 1;
> }
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi, > > > > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp; > > > > + msg->vram.is_vram_gpa_specified = 1; > > > > + synthvid_send(hdev, msg); > > > > > > That suggests it is possible to define multiple framebuffers in vram, > > > then pageflip by setting vram.vram_gpa. If that is the case I'm > > > wondering whenever vram helpers are a better fit maybe? You don't > > > have > > > to blit each and every display update then. > > > > Thanks for the review. Unfortunately only the first vmbus message take > > effect and subsequent calls are ignored. I originally implemented using > > vram helpers but I figured out calling this vmbus message again won't > > change the vram location. /me notices there also is user_ctx. What is this? > I think that needs a very big comment. Maybe even enforce that with a > "vram_gpa_set" boolean in the device structure, and complain if we try to > do that twice. > > Also I guess congrats to microsoft for defining things like that :-/ I would be kind of surprised if the virtual device doesn't support pageflips. Maybe setting vram_gpa just isn't the correct way to do it. Is there a specification available? There are a number of microsoft folks in Cc: Anyone willing to comment? thanks, Gerd PS: And, yes, in case pageflips really don't work going with shmem helpers + blits is reasonable. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5 01/10] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc
On Mon, Jun 22, 2020 at 04:07:21PM -0400, Lyude Paul wrote:
> Since we'll be allocating resources for kthread_create_worker() in the
> next commit (which could fail and require us to clean up the mess),
> let's simplify the cleanup process a bit by registering a
> drm_vblank_init_release() action for each drm_vblank_crtc so they're
> still cleaned up if we fail to initialize one of them.
>
> Changes since v3:
> * Use drmm_add_action_or_reset() - Daniel Vetter
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_vblank.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 85e5f2db16085..ce5c1e1d29963 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -492,16 +492,12 @@ static void vblank_disable_fn(struct timer_list *t)
>
> static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
> {
> - unsigned int pipe;
> -
> - for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
> - struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> + struct drm_vblank_crtc *vblank = ptr;
>
> - drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
> - drm_core_check_feature(dev, DRIVER_MODESET));
> + drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
> + drm_core_check_feature(dev, DRIVER_MODESET));
>
> - del_timer_sync(&vblank->disable_timer);
> - }
> + del_timer_sync(&vblank->disable_timer);
> }
>
> /**
> @@ -511,7 +507,7 @@ static void drm_vblank_init_release(struct drm_device
> *dev, void *ptr)
> *
> * This function initializes vblank support for @num_crtcs display pipelines.
> * Cleanup is handled automatically through a cleanup function added with
> - * drmm_add_action().
> + * drmm_add_action_or_reset().
> *
> * Returns:
> * Zero on success or a negative error code on failure.
> @@ -530,10 +526,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
> num_crtcs)
>
> dev->num_crtcs = num_crtcs;
>
> - ret = drmm_add_action(dev, drm_vblank_init_release, NULL);
> - if (ret)
> - return ret;
> -
> for (i = 0; i < num_crtcs; i++) {
> struct drm_vblank_crtc *vblank = &dev->vblank[i];
>
> @@ -542,6 +534,11 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
> num_crtcs)
> init_waitqueue_head(&vblank->queue);
> timer_setup(&vblank->disable_timer, vblank_disable_fn, 0);
> seqlock_init(&vblank->seqlock);
> +
> + ret = drmm_add_action_or_reset(dev, drm_vblank_init_release,
> +vblank);
> + if (ret)
> + return ret;
> }
>
> return 0;
Reviewed-by: Daniel Vetter
> --
> 2.26.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/mtk: Use __drm_atomic_helper_crtc_reset
Hi, Daniel:
Daniel Vetter 於 2020年6月13日 週六 上午12:01寫道：
>
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
>
Acked-by: Chun-Kuang Hu
> Signed-off-by: Daniel Vetter
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a7dba4ced902..d654c7d514bd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -112,19 +112,15 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> {
> struct mtk_crtc_state *state;
>
> - if (crtc->state) {
> + if (crtc->state)
> __drm_atomic_helper_crtc_destroy_state(crtc->state);
>
> - state = to_mtk_crtc_state(crtc->state);
> - memset(state, 0, sizeof(*state));
> - } else {
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (!state)
> - return;
> - crtc->state = &state->base;
> - }
> + kfree(to_mtk_crtc_state(crtc->state));
> + crtc->state = NULL;
>
> - state->base.crtc = crtc;
> + state = kzalloc(sizeof(*state), GFP_KERNEL);
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
> }
>
> static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc
> *crtc)
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 02/17] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-s...@poorly.run
#v6
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f26fee3b4624..9f530b2f3606 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = &connector->hdcp;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 04/17] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-s...@poorly.run
#v6
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 63 -
1 file changed, 29 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3df5d901dd9d..b30846e9e634 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1563,6 +1563,20 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
@@ -1570,6 +1584,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1590,7 +1605,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1613,7 +1628,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -6398,17 +6413,9 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
u8 *an)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&intel_dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
- /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -6419,31 +6426,19 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as
[PATCH v7 01/17] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-s...@poorly.run
#v6
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 815b054bb167..f26fee3b4624 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -336,8 +336,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -435,7 +437,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -450,17 +452,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]
[PATCH v7 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-11-s...@poorly.run
#v6
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 536299f902b9..29f1f552e8d8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3907,13 +3907,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_panel_update_backlight(state, encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(state, encoder, crtc_state,
conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 0a8950f744f6..6352c7e97e3b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -17,6 +17,7 @@ struct drm_encoder;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
+struct intel_atomic_state;
struct intel_connector;
struct intel_crtc_state;
struct intel_digital_port;
@@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 9308b5920780..0675825dcc20 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -836,6 +836,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->compute_config_late = intel_dp_mst_compute_config_late;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 05/17] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-s...@poorly.run
#v6
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 16 +---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8a03c58cbd31..4153a0d1e07d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,12 +1737,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1751,19 +1751,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 077e9dbbe367..f5fb62fc9400 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_atomic_state *state,
struct intel_encoder *intel_encoder,
@@ -43,6 +44,7 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4b0aaa3081c9..fc0befd55420 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -314,6 +314,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b30846e9e634..d0fea51f5dec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6597,6 +6597,7 @@ int intel_dp_hdcp_read_v_prime_part(stru
[PATCH v7 07/17] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-s...@poorly.run
#v6
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 88500a0bd77e..62cab3aea745 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -888,8 +888,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -981,6 +983,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1860,6 +1864,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2178,12 +2185,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 09/17] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 +++
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 33 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 ++
5 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4153a0d1e07d..536299f902b9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4884,6 +4884,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(&intel_dig_port->hdcp_mutex);
+ intel_dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index fc0befd55420..1503403a808b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1410,6 +1410,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d0fea51f5dec..d98e45a09c28 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -8276,6 +8276,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 16bf0fbe5f17..5679877c6b4c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -801,6 +801,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (intel_dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv,
[PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
#v6
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-Use FIELD_PREP to generate request buffer bitfields (Lyude)
-Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
Changes in v7:
-None
---
drivers/gpu/drm/drm_dp_mst_topology.c | 142 ++
.../drm/selftests/test-drm_dp_mst_helper.c| 17 +++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_helper.h | 44 ++
4 files changed, 206 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b2f5a84b4cfb..fc68478eaeb4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -20,11 +20,13 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -419,6 +421,22 @@ drm_dp_encode_sideband_req(const struct
drm_dp_sideband_msg_req_body *req,
memcpy(&buf[idx], req->u.i2c_write.bytes,
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+ case DP_QUERY_STREAM_ENC_STATUS: {
+ const struct drm_dp_query_stream_enc_status *msg;
+
+ msg = &req->u.enc_status;
+ buf[idx] = msg->stream_id;
+ idx++;
+ memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
+ idx += sizeof(msg->client_id);
+ buf[idx] = 0;
+ buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
+ buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
+ buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
+ buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
+ idx++;
+ }
+ break;
}
raw->cur_len = idx;
}
@@ -547,6 +565,20 @@ drm_dp_decode_sideband_req(const struct
drm_dp_sideband_msg_tx *raw,
return -ENOMEM;
}
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ req->u.enc_status.stream_id = buf[idx++];
+ for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
+ req->u.enc_status.client_id[i] = buf[idx++];
+
+ req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
+ buf[idx]);
+ req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
+buf[idx]);
+ req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
+ buf[idx]);
+ req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
+ buf[idx]);
+ break;
}
return 0;
@@ -625,6 +657,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
drm_dp_sideband_msg_req_body *req
req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
req->u.i2c_write.bytes);
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ P("stream_id=%u client_id=%*ph stream_event=%x "
+ "valid_event=%d stream_behavior=%x valid_behavior=%d",
+ req->u.enc_status.stream_id,
+ (int)ARRAY_SIZE(req->u.enc_status.client_id),
+ req->u.enc_status.client_id, req->u.enc_status.stream_event,
+ req->u.enc_status.valid_stream_event,
+ req->u.enc_status.stream_behavior,
+ req->u.enc_status.valid_stream_behavior);
+ break;
default:
P("???\n");
break;
@@ -925,6 +967,34 @@ static bool
drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
return true;
}
+static bool
+drm_dp_sideband_parse_query_stream_enc_status(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_reply_body *repmsg)
+{
+ struct drm_dp_query_stream_enc_status_ack_reply *reply;
+
+ reply = &repmsg->u.enc_status;
+
+ reply->stream_id = raw->msg[3];
+
+ reply->reply_signed = raw->msg[2] & BIT(0);
+
+ reply->hdcp_1x_device_present = raw->msg[2] & BIT(3);
+ reply->hdcp_2x_device_present = raw->msg[2] & BIT(4);
+
+ reply->query_capable_device_present = raw->msg[2] & BIT(5);
+ reply->
[PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
#v6
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 43446a6cae8d..3f67bd27fc3c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
+ int ret;
+
+ if (!enable)
+ usleep_range(6, 60); /* Bspec says >= 6us */
+
+ ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ drm_dbg_kms(&i915->drm, "%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
+{
+ struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct drm_dp_query_stream_enc_status_ack_reply reply;
+ int ret;
+
+ if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
+ return false;
+
+ ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
+ connector->port, &reply);
+ if (ret) {
+ drm_dbg_kms(&i915->drm,
+ "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
+ connector->base.base.id, connector->base.name, ret);
+ return false;
+ }
+
+ return reply.auth_completed && reply.encryption_enabled;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_mst_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
{
@@ -630,7 +691,10 @@ int intel_dp_init_hdcp(struct intel_digital_port
*intel_dig_port,
if (!is_hdcp_supported(dev_priv, port))
[PATCH v7 10/17] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-s...@poorly.run
#v6
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1503403a808b..811085ef3fba 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1525,6 +1525,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1533,6 +1545,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1543,13 +1557,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 16/17] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-s...@poorly.run
#v6
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
Changes in v6:
-None
Changes in v7:
-None
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d1cb48b3f462..1f748a480eb2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -598,6 +598,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -609,6 +614,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -625,10 +631,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
&intel_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -646,10 +648,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -705,6 +703,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -2026,10 +2027,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 13/17] drm/i915: Plumb port through hdcp init
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
#v6
Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0e06a1066d61..e26a45f880cb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -630,7 +630,8 @@ int intel_dp_init_hdcp(struct intel_digital_port
*intel_dig_port,
return 0;
if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ return intel_hdcp_init(intel_connector, port,
+ &intel_dp_hdcp_shim);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 5679877c6b4c..d79d4142aea7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1955,6 +1955,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
cpu_transcoder)
}
static int initialize_hdcp_port_data(struct intel_connector *connector,
+enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1962,8 +1963,7 @@ static int initialize_hdcp_port_data(struct
intel_connector *connector,
struct hdcp_port_data *data = &hdcp->port_data;
if (INTEL_GEN(dev_priv) < 12)
- data->fw_ddi =
-
intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
+ data->fw_ddi = intel_get_mei_fw_ddi_index(port);
else
/*
* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
@@ -2033,14 +2033,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector,
+static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, shim);
+ ret = initialize_hdcp_port_data(connector, port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2050,6 +2050,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector,
}
int intel_hdcp_init(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2060,7 +2061,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector, shim);
+ intel_hdcp2_init(connector, port, shim);
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 86bbaec120cc..1bbf5b67ed0a 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -22,7 +22,7 @@ enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector,
+int intel_hdcp_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index a59acfff456e..ca71ee3dd1c7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3260,7 +3260,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
[PATCH v7 03/17] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä Cc: Daniel Vetter Reviewed-by: Ramalingam C Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-s...@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-s...@poorly.run #v6 Changes in v2: -Added to the set in lieu of just clearing the bit Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Rebased, variable name changed from 'ctl' to 'val' --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 73d6cc29291a..8a03c58cbd31 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -1708,6 +1708,8 @@ void intel_ddi_disable_transcoder_func(const struct intel_crtc_state *crtc_state ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)); + drm_WARN_ON(crtc->base.dev, ctl & TRANS_DDI_HDCP_SIGNALLING); + ctl &= ~TRANS_DDI_FUNC_ENABLE; if (IS_GEN_RANGE(dev_priv, 8, 10)) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 00/17] drm/i915: Add support for HDCP 1.4 over MST
From: Sean Paul No functional changes, this set has the following changes since v6: - rebased on drm-tip - split "drm/i915: Clean up intel_hdcp_disable" out of "drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it" - remove hdcp2 dpmst stubs Regarding "level of testing" questions, I've tested with multiple MST hubs and displays. I don't have any compliance gear so all of this is desk tested and works for me. Sean Sean Paul (17): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Clean up intel_hdcp_disable drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 142 drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- drivers/gpu/drm/i915/display/intel_dp.h | 9 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 702 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + drivers/gpu/drm/i915/display/intel_hdcp.c | 218 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- .../drm/selftests/test-drm_dp_mst_helper.c| 17 + include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 17 files changed, 1191 insertions(+), 722 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-s...@poorly.run
#v6
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 811085ef3fba..94211b8fc159 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -318,7 +318,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *intel_dig_port);
+ bool (*check_link)(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index e26a45f880cb..43446a6cae8d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -223,7 +223,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
ssize_t ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index d79d4142aea7..6bd0e4616ee1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -953,7 +953,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(intel_dig_port)) {
+ if (hdcp->shim->check_link(intel_dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ca71ee3dd1c7..b12f1af0611d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- struct intel_connector *connector =
- intel_dig_port->hdmi.attached_connector;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 08/17] drm/i915: Clean up intel_hdcp_disable
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Changes in v7:
-Split into separate patch (Ramalingam)
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 62cab3aea745..16bf0fbe5f17 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2113,16 +2113,17 @@ int intel_hdcp_disable(struct intel_connector
*connector)
mutex_lock(&hdcp->mutex);
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
- false);
- if (hdcp->hdcp2_encrypted)
- ret = _intel_hdcp2_disable(connector);
- else if (hdcp->hdcp_encrypted)
- ret = _intel_hdcp_disable(connector);
- }
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED, false);
+ if (hdcp->hdcp2_encrypted)
+ ret = _intel_hdcp2_disable(connector);
+ else if (hdcp->hdcp_encrypted)
+ ret = _intel_hdcp_disable(connector);
+
+out:
mutex_unlock(&hdcp->mutex);
cancel_delayed_work_sync(&hdcp->check_work);
return ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 06/17] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-s...@poorly.run
#v6
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 39715abf2ce4..88500a0bd77e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -877,6 +877,21 @@ static struct intel_connector
*intel_hdcp_to_connector(struct intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -904,15 +919,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -924,16 +940,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1769,16 +1787,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_C
[PATCH v7 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-12-s...@poorly.run
#v6
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-Rebased patch
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 606 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 636 +++
4 files changed, 641 insertions(+), 605 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 41a27fd5dbc7..cba4ddb95ab1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -233,6 +233,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d98e45a09c28..78ce5e41d559 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include "i915_debugfs.h"
@@ -6396,609 +6395,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
- u8 *an)
-{
- struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
- u8 *bksv)
-{
- struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- ssize_t ret;
-
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port
*intel_dig_port,
- u8 *bstatus)
-{
- struct drm_i915_private *i915 = to_i915(intel_dig_port->base
[PATCH] drm/fb-helper: Fix vt restore
In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, because drm master controls access to the display resources.
Unfortunately this breaks existing userspace, specifically Xorg. When
exiting Xorg first restores the console to text mode using the KDSET
ioctl on the vt. This does nothing, because a drm master is still
around. Then it drops the drm master status, which again does nothing,
because logind is keeping additional drm fd open to be able to
orchestrate vt switches. In the past this is the point where fbdev was
restored, as part of the ->lastclose hook on the drm side.
Now to fix this regression we don't want to go back to letting fbdev
restore things whenever it feels like, or to the pile of hacks we've
had before. Instead try and go with a minimal exception to make the
KDSET case work again, and nothing else.
This means that if userspace does a KDSET call when switching between
graphical compositors, there will be some flickering with fbcon
showing up for a bit. But a) that's not a regression and b) userspace
can fix it by improving the vt switching dance - logind should have
all the information it needs.
While pondering all this I'm also wondering wheter we should have a
SWITCH_MASTER ioctl to allow race-free master status handover. But
that's for another day.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
Cc: shl...@fastmail.com
Reported-and-Tested-by: shl...@fastmail.com
Cc: Michel Dänzer
Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores")
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 63 +---
drivers/video/fbdev/core/fbcon.c | 3 +-
include/uapi/linux/fb.h | 1 +
3 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 170aa7689110..ae69bf8e9bcc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/**
- * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: driver-allocated fbdev helper, can be NULL
- *
- * This should be called from driver's drm &drm_driver.lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * RETURNS:
- * Zero if everything went ok, negative error code otherwise.
- */
-int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+static int
+__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper,
+ bool force)
{
bool do_delayed;
int ret;
@@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
return 0;
mutex_lock(&fb_helper->lock);
- ret = drm_client_modeset_commit(&fb_helper->client);
+ if (force) {
+ /*
+* Yes this is the _locked version which expects the master lock
+* to be held. But for forced restores we're intentionally
+* racing here, see drm_fb_helper_set_par().
+*/
+ ret = drm_client_modeset_commit_locked(&fb_helper->client);
+ } else {
+ ret = drm_client_modeset_commit(&fb_helper->client);
+ }
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
@@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
return ret;
}
+
+/**
+ * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
+ *
+ * This should be called from driver's drm &drm_driver.lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ *
+ * RETURNS:
+ * Zero if everything went ok, negative error code otherwise.
+ */
+int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+{
+ return __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper, false);
+}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
#ifdef CONFIG_MAGIC_SYSRQ
@@ -1318,6 +1334,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
struct fb_var_screeninfo *var = &info->var;
+ bool force;
if (oops_in_progress)
return -EBUSY;
@@ -1327,7 +13
[kbuild] Re: [PATCH v7 33/36] rapidio: fix common struct sg_table related issues
Hi Marek,
url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-184302
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: i386-randconfig-m021-20200623 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/rapidio/devices/rio_mport_cdev.c:939 rio_dma_transfer() error:
uninitialized symbol 'nents'.
#
https://github.com/0day-ci/linux/commit/c99597eab54307f46248273962da0c23a9a88b76
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout c99597eab54307f46248273962da0c23a9a88b76
vim +/nents +939 drivers/rapidio/devices/rio_mport_cdev.c
e8de370188d098 Alexandre Bounine 2016-03-22 804 static int
4e1016dac1ccce Alexandre Bounine 2016-05-05 805 rio_dma_transfer(struct file
*filp, u32 transfer_mode,
e8de370188d098 Alexandre Bounine 2016-03-22 806enum
rio_transfer_sync sync, enum dma_data_direction dir,
e8de370188d098 Alexandre Bounine 2016-03-22 807struct
rio_transfer_io *xfer)
e8de370188d098 Alexandre Bounine 2016-03-22 808 {
e8de370188d098 Alexandre Bounine 2016-03-22 809 struct mport_cdev_priv
*priv = filp->private_data;
e8de370188d098 Alexandre Bounine 2016-03-22 810 unsigned long nr_pages
= 0;
e8de370188d098 Alexandre Bounine 2016-03-22 811 struct page **page_list
= NULL;
e8de370188d098 Alexandre Bounine 2016-03-22 812 struct mport_dma_req
*req;
e8de370188d098 Alexandre Bounine 2016-03-22 813 struct mport_dev *md =
priv->md;
e8de370188d098 Alexandre Bounine 2016-03-22 814 struct dma_chan *chan;
67446283d89467 John Hubbard 2020-06-04 815 int ret;
e8de370188d098 Alexandre Bounine 2016-03-22 816 int nents;
^
e8de370188d098 Alexandre Bounine 2016-03-22 817
e8de370188d098 Alexandre Bounine 2016-03-22 818 if (xfer->length == 0)
e8de370188d098 Alexandre Bounine 2016-03-22 819 return -EINVAL;
e8de370188d098 Alexandre Bounine 2016-03-22 820 req =
kzalloc(sizeof(*req), GFP_KERNEL);
e8de370188d098 Alexandre Bounine 2016-03-22 821 if (!req)
e8de370188d098 Alexandre Bounine 2016-03-22 822 return -ENOMEM;
e8de370188d098 Alexandre Bounine 2016-03-22 823
e8de370188d098 Alexandre Bounine 2016-03-22 824 ret =
get_dma_channel(priv);
e8de370188d098 Alexandre Bounine 2016-03-22 825 if (ret) {
e8de370188d098 Alexandre Bounine 2016-03-22 826 kfree(req);
e8de370188d098 Alexandre Bounine 2016-03-22 827 return ret;
e8de370188d098 Alexandre Bounine 2016-03-22 828 }
c5157b76869ba9 Ioan Nicu 2018-04-20 829 chan = priv->dmach;
c5157b76869ba9 Ioan Nicu 2018-04-20 830
c5157b76869ba9 Ioan Nicu 2018-04-20 831
kref_init(&req->refcount);
c5157b76869ba9 Ioan Nicu 2018-04-20 832
init_completion(&req->req_comp);
c5157b76869ba9 Ioan Nicu 2018-04-20 833 req->dir = dir;
c5157b76869ba9 Ioan Nicu 2018-04-20 834 req->filp = filp;
c5157b76869ba9 Ioan Nicu 2018-04-20 835 req->priv = priv;
c5157b76869ba9 Ioan Nicu 2018-04-20 836 req->dmach = chan;
c5157b76869ba9 Ioan Nicu 2018-04-20 837 req->sync = sync;
e8de370188d098 Alexandre Bounine 2016-03-22 838
e8de370188d098 Alexandre Bounine 2016-03-22 839 /*
e8de370188d098 Alexandre Bounine 2016-03-22 840* If parameter
loc_addr != NULL, we are transferring data from/to
e8de370188d098 Alexandre Bounine 2016-03-22 841* data buffer
allocated in user-space: lock in memory user-space
e8de370188d098 Alexandre Bounine 2016-03-22 842* buffer pages and
build an SG table for DMA transfer request
e8de370188d098 Alexandre Bounine 2016-03-22 843*
e8de370188d098 Alexandre Bounine 2016-03-22 844* Otherwise (loc_addr
== NULL) contiguous kernel-space buffer is
e8de370188d098 Alexandre Bounine 2016-03-22 845* used for DMA data
transfers: build single entry SG table using
e8de370188d098 Alexandre Bounine 2016-03-22 846* offset within the
internal buffer specified by handle parameter.
e8de370188d098 Alexandre Bounine 2016-03-22 847*/
e8de370188d098 Alexandre Bounine 2016-03-22 848 if (xfer->loc_addr) {
c4860ad6056483 Tvrtko Ursulin 2017-07-31 849 unsigned int
offset;
e8de370188d098 Alexandre Bounine 2016-03-22 850 long pinned;
e8de370188d098 Alexandre Bounine 2016-03-22 851
c4860ad6056483 Tvrtko Ursulin 2017-07-31 852 offset =
lower_32_bits(offset_in_page(xfer->loc_
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #21 from rtmasura+ker...@hotmail.com --- OK. I've uninstalled the vast majority of KDE and am using a vanilla XFCE4. It's been about 12 hours on 5.7.4-arch1-1 and I have yet to have a crash. It is looking like it may be something with KDE. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm/fourcc: document modifier uniqueness requirements
There have suggestions to bake pitch alignment, address alignement,
contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
constraints into modifiers. Last time this was brought up it seemed
like the consensus was to not allow this. Document this in drm_fourcc.h.
There are several reasons for this.
- Encoding all of these constraints in the modifiers would explode the
search space pretty quickly (we only have 64 bits to work with).
- Modifiers need to be unambiguous: a buffer can only have a single
modifier.
- Modifier users aren't expected to parse modifiers (except drivers).
v2: add paragraph about aliases (Daniel)
v3: fix unrelated changes sent with the patch
v4: disambiguate users between driver and higher-level programs (Brian,
Daniel)
v5: fix AFBC example (Brian, Daniel)
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Daniel Stone
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Marek Olšák
Cc: Alex Deucher
Cc: Neil Armstrong
Cc: Michel Dänzer
Cc: Brian Starkey
---
include/uapi/drm/drm_fourcc.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 490143500a50..8296197189bf 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -58,6 +58,34 @@ extern "C" {
* may preserve meaning - such as number of planes - from the fourcc code,
* whereas others may not.
*
+ * Modifiers must uniquely encode buffer layout. In other words, a buffer must
+ * match only a single modifier. A modifier must not be a subset of layouts of
+ * another modifier. For instance, it's incorrect to encode pitch alignment in
+ * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
+ * aligned modifier. That said, modifiers can have implicit minimal
+ * requirements.
+ *
+ * For modifiers where the combination of fourcc code and modifier can alias,
+ * a canonical pair needs to be defined and used by all drivers. An example
+ * is AFBC, where both ARGB and ABGR have the exact same compressed layout.
+ *
+ * For modifiers where the combination of fourcc code and modifier can alias,
+ * a canonical pair needs to be defined and used by all drivers. Preferred
+ * combinations are also encouraged where all combinations might lead to
+ * confusion and unnecessarily reduced interoperability. An example for the
+ * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
+ *
+ * There are two kinds of modifier users:
+ *
+ * - Kernel and user-space drivers: for drivers it's important that modifiers
+ * don't alias, otherwise two drivers might support the same format but use
+ * different aliases, preventing them from sharing buffers in an efficient
+ * format.
+ * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users
+ * see modifiers as opaque tokens they can check for equality and intersect.
+ * These users musn't need to know to reason about the modifier value
+ * (i.e. they are not expected to extract information out of the modifier).
+ *
* Vendors should document their modifier usage in as much detail as
* possible, to ensure maximum compatibility across devices, drivers and
* applications.
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208179] [amdgpu] black screen after exiting X
https://bugzilla.kernel.org/show_bug.cgi?id=208179 --- Comment #3 from Shlomo (shl...@fastmail.com) --- Yes, this fixes the bug. (tested on top of v5.8-rc2) -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-graphics-maintainer] [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
At least for the vmwgfx bits, no objections here, Reviewed-by: Roland Scheidegger Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > Most of the DRM drivers uAPI headers are licensed under the MIT license, > and carry copies of the license with slight variations. Replace them > with SPDX headers. > > Signed-off-by: Laurent Pinchart > --- > include/uapi/drm/amdgpu_drm.h | 19 +-- > include/uapi/drm/i915_drm.h| 22 +- > include/uapi/drm/mga_drm.h | 20 +--- > include/uapi/drm/msm_drm.h | 20 +--- > include/uapi/drm/nouveau_drm.h | 20 +--- > include/uapi/drm/qxl_drm.h | 20 +--- > include/uapi/drm/r128_drm.h| 20 +--- > include/uapi/drm/radeon_drm.h | 20 +--- > include/uapi/drm/savage_drm.h | 20 +--- > include/uapi/drm/sis_drm.h | 21 + > include/uapi/drm/tegra_drm.h | 19 +-- > include/uapi/drm/v3d_drm.h | 20 +--- > include/uapi/drm/vc4_drm.h | 20 +--- > include/uapi/drm/vgem_drm.h| 22 +- > include/uapi/drm/via_drm.h | 20 +--- > include/uapi/drm/virtgpu_drm.h | 20 +--- > include/uapi/drm/vmwgfx_drm.h | 21 + > 17 files changed, 17 insertions(+), 327 deletions(-) > > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h > index 4e873dcbe68f..c6adda72bec7 100644 > --- a/include/uapi/drm/amdgpu_drm.h > +++ b/include/uapi/drm/amdgpu_drm.h > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: MIT */ > /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*- > * > * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > @@ -5,24 +6,6 @@ > * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > * Copyright 2014 Advanced Micro Devices, Inc. > * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the "Software"), > - * to deal in the Software without restriction, including without limitation > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > - * and/or sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following conditions: > - * > - * The above copyright notice and this permission notice shall be included in > - * all copies or substantial portions of the Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > - * > * Authors: > *Kevin E. Martin > *Gareth Hughes > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 14b67cd6b54b..c29e3acb3026 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -1,27 +1,7 @@ > +/* SPDX-License-Identifier: MIT */ > /* > * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. > * All Rights Reserved. > - * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the > - * "Software"), to deal in the Software without restriction, including > - * without limitation the rights to use, copy, modify, merge, publish, > - * distribute, sub license, and/or sell copies of the Software, and to > - * permit persons to whom the Software is furnished to do so, subject to > - * the following conditions: > - * > - * The above copyright notice and this permission notice (including the > - * next paragraph) shall be included in all copies or substantial portions > - * of the Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > - * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. > - * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR > - * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, > - * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE > - * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > - * > */ > > #ifndef _UAPI_I915_DRM_H_ > diff --git a/include/uapi/drm/mga_drm.h b/include/uapi/drm/mga_drm.h > index 8c4337548ab5..4415efefe0cf 100644 > --- a/include/uapi/drm/mga_drm.h > +++ b/include/uapi/drm/mga_drm.h > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: MIT */ > /* mga_drm.h -- Public header
[RFC v6] drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 20 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 712 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + dr
[Bug 208179] [amdgpu] black screen after exiting X
https://bugzilla.kernel.org/show_bug.cgi?id=208179 --- Comment #2 from Daniel Vetter (dan...@ffwll.ch) --- Created attachment 289849 --> https://bugzilla.kernel.org/attachment.cgi?id=289849&action=edit polished fix, hopefully works -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>-Original Message- >From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan Teja >Kalla >Sent: Tuesday, June 23, 2020 7:34 AM >To: Ruhl, Michael J ; Sumit Semwal >; david.lai...@aculab.com; open list:DMA >BUFFER SHARING FRAMEWORK ; DRI mailing >list >Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org> >Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name > >Thanks Mike for the inputs. > >On 6/22/2020 5:10 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: charante=codeaurora@mg.codeaurora.org >>> On Behalf Of Charan >Teja >>> Kalla >>> Sent: Monday, June 22, 2020 5:26 AM >>> To: Ruhl, Michael J ; Sumit Semwal >>> ; david.lai...@aculab.com; open list:DMA >>> BUFFER SHARING FRAMEWORK ; DRI >mailing >>> list >>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org> >>> Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name >>> >>> Hello Mike, >>> >>> On 6/19/2020 7:11 PM, Ruhl, Michael J wrote: > -Original Message- > From: charante=codeaurora@mg.codeaurora.org > On Behalf Of Charan >>> Teja > Kalla > Sent: Friday, June 19, 2020 7:57 AM > To: Sumit Semwal ; Ruhl, Michael J > ; david.lai...@aculab.com; open >list:DMA > BUFFER SHARING FRAMEWORK ; DRI >>> mailing > list > Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org> > Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name > > There exists a sleep-while-atomic bug while accessing the dmabuf- >>name > under mutex in the dmabuffs_dname(). This is caused from the SELinux > permissions checks on a process where it tries to validate the inherited > files from fork() by traversing them through iterate_fd() (which > traverse files under spin_lock) and call > match_file(security/selinux/hooks.c) where the permission checks >>> happen. > This audit information is logged using dump_common_audit_data() >where >>> it > calls d_path() to get the file path name. If the file check happen on > the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex >to > access dmabuf->name. The flow will be like below: > flush_unauthorized_files() > iterate_fd() >spin_lock() --> Start of the atomic section. > match_file() >file_has_perm() > avc_has_perm() >avc_audit() > slow_avc_audit() > common_lsm_audit() > dump_common_audit_data() > audit_log_d_path() > d_path() >dmabuffs_dname() > mutex_lock()--> Sleep while atomic. > > Call trace captured (on 4.19 kernels) is below: > ___might_sleep+0x204/0x208 > __might_sleep+0x50/0x88 > __mutex_lock_common+0x5c/0x1068 > __mutex_lock_common+0x5c/0x1068 > mutex_lock_nested+0x40/0x50 > dmabuffs_dname+0xa0/0x170 > d_path+0x84/0x290 > audit_log_d_path+0x74/0x130 > common_lsm_audit+0x334/0x6e8 > slow_avc_audit+0xb8/0xf8 > avc_has_perm+0x154/0x218 > file_has_perm+0x70/0x180 > match_file+0x60/0x78 > iterate_fd+0x128/0x168 > selinux_bprm_committing_creds+0x178/0x248 > security_bprm_committing_creds+0x30/0x48 > install_exec_creds+0x1c/0x68 > load_elf_binary+0x3a4/0x14e0 > search_binary_handler+0xb0/0x1e0 > > So, use spinlock to access dmabuf->name to avoid sleep-while-atomic. > > Cc: [5.3+] > Signed-off-by: Charan Teja Reddy > --- > > Changes in V2: Addressed review comments from Ruhl, Michael J > > Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/ > > drivers/dma-buf/dma-buf.c | 11 +++ > include/linux/dma-buf.h | 1 + > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 01ce125..d81d298 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry >>> *dentry, > char *buffer, int buflen) > size_t ret = 0; > > dmabuf = dentry->d_fsdata; > - dma_resv_lock(dmabuf->resv, NULL); > + spin_lock(&dmabuf->name_lock); > if (dmabuf->name) > ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); > - dma_resv_unlock(dmabuf->resv); > + spin_unlock(&dmabuf->name_lock); > > return dynamic_dname(dentry, buffer, buflen, "/%s:%s", >dentry->d_name.name, ret > 0 ? name : ""); > @@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf > *dmabuf, const char __user *buf) > kfree(name); > goto out_unlock; > } > + spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > dmabuf->name = name; > + spin_unlock(&dmabuf->name_lock); While this code path is ok, I would have separated the
Re: [PATCH v2 0/9] Convert the remaining text files to ReST and add SPDX for GFDL
Hi Kate, Em Tue, 23 Jun 2020 06:58:55 -0500 Kate Stewart escreveu: > On Tue, Jun 23, 2020 at 4:53 AM Mauro Carvalho Chehab > wrote: > > > > The main goal of this series is to finish the ReST conversion. After this > > series, we have just those files still in plain old format: > > > > - Documentation/RCU/RTFP.txt > > - Documentation/atomic_bitops.txt > > - Documentation/memory-barriers.txt > > - Documentation/atomic_t.txt > > - Documentation/filesystems/dax.txt > > - Documentation/filesystems/path-lookup.txt > > - Documentation/virt/kvm/devices/README > > > > PS.: I'm using a script to remove false-positives and ignore non-converted > > translated files. > > > > It is worth to mention that this fseries contain licenses for the two > > GFDL licenses used within the Kernel: GFDL-1.1+ and GFDL-1.2. > > > > Those licenses are the result of long discussions with the SPDX legal > > team, and are part of this commit, to be added for the future > > SPDX 3.10 version: > > > > https://github.com/spdx/license-list-XML/pull/1048/commits/f695d2ac65230d0f4161ba58fff2f9d87bb5a053 > > > > Mauro Carvalho Chehab (9): > > docs: dt: convert booting-without-of.txt to ReST format > > LICENSES: add GFDL licenses > > media: docs: use SPDX GFDL-1.1-or-later-no-invariants > > The identifier "GFDL-1.1-or-later-no-invariants" isn't following expected > construction (or-later and -only at the end) and the pull request is > still under > discussion on the SPDX license list, so please hold off on applying this > until the correct identifier is figured out there. Thanks for checking this. I assumed that the discussions on SPDX were finished. For now, I'll keep using a license text at the Kernel (on media and on another file dual-licensed GPL and GFDL). I'm keeping the patches changing the license on a temp branch. I'll re-submit them once the patch gets merged at SPDX specs tree. Btw, another file using both GPL and GFDL was just added via the media tree[1]. I need to remember that when re-submitting this one, as otherwise it would be a left-over. [1] Due to historic reasons, media userspace API is licensed under GFDL. We're using a dual-license model for newer files at the media uAPI book. Thanks! Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hi! > > > > Would it not be better to have one st7703 driver that suipports both > > > > panels? > > > > > > > > The driver would need dedicated init functions depending on the panel. > > > > But a lot could also be shared. > > > > > > I guess I can move the code there. > > In the same process the river should then be renamed to follow other > > sitronix based drivers. > > So the next developer will recognize this and use the correct driver. > > Are driver/module names considered kernel ABI? Or is it possible to > change them? I believe you can get away with changing them. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] Convert the remaining text files to ReST
The main goal of this series is to finish the ReST conversion. After this
series, we have just those files still in plain old format:
- Documentation/RCU/RTFP.txt
- Documentation/atomic_bitops.txt
- Documentation/memory-barriers.txt
- Documentation/atomic_t.txt
- Documentation/filesystems/dax.txt
- Documentation/filesystems/path-lookup.txt
- Documentation/virt/kvm/devices/README
PS.: I'm using a script to remove false-positives and ignore non-converted
translated files.
---
- v3: removed SPDX patches, because upstream discussion about GFDL is not
finished yet. So, for now, use the old way to specify dual-licensed GPL and
GFDL
files.
I have already a tree ready for submission once upstream pushes this feat
on SPDX specs.
Mauro Carvalho Chehab (7):
docs: dt: convert booting-without-of.txt to ReST format
docs: trace: ring-buffer-design.txt: convert to ReST format
docs: move nommu-mmap.txt to admin-guide and rename to ReST
docs: move mailbox.txt to driver-api and rename it
docs: move other kAPI documents to core-api
docs: Add remaining Documentation/*.txt at staging/index.rst
docs: staging: use small font for literal includes
Documentation/admin-guide/mm/index.rst| 1 +
.../mm/nommu-mmap.rst}| 0
Documentation/admin-guide/sysctl/vm.rst | 2 +-
Documentation/arm/booting.rst | 2 +-
.../bus-virt-phys-mapping.rst}| 0
Documentation/core-api/index.rst | 3 +
.../this_cpu_ops.rst} | 0
.../unaligned-memory-access.rst | 0
...-without-of.txt => booting-without-of.rst} | 298 ---
Documentation/devicetree/index.rst| 1 +
Documentation/driver-api/index.rst| 1 +
.../{mailbox.txt => driver-api/mailbox.rst} | 0
Documentation/gpu/drm-mm.rst | 2 +-
Documentation/staging/index.rst | 24 +
Documentation/trace/index.rst | 1 +
...ffer-design.txt => ring-buffer-design.rst} | 802 ++
Documentation/translations/zh_CN/arm/Booting | 2 +-
arch/Kconfig | 2 +-
init/Kconfig | 2 +-
mm/Kconfig| 2 +-
mm/nommu.c| 2 +-
21 files changed, 631 insertions(+), 516 deletions(-)
rename Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} (100%)
rename Documentation/{bus-virt-phys-mapping.txt =>
core-api/bus-virt-phys-mapping.rst} (100%)
rename Documentation/{this_cpu_ops.txt => core-api/this_cpu_ops.rst} (100%)
rename Documentation/{process => core-api}/unaligned-memory-access.rst (100%)
rename Documentation/devicetree/{booting-without-of.txt =>
booting-without-of.rst} (90%)
rename Documentation/{mailbox.txt => driver-api/mailbox.rst} (100%)
rename Documentation/trace/{ring-buffer-design.txt => ring-buffer-design.rst}
(55%)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] docs: move nommu-mmap.txt to admin-guide and rename to ReST
The nommu-mmap.txt file provides description of user visible
behaviuour. So, move it to the admin-guide.
As it is already at the ReST, also rename it.
Suggested-by: Mike Rapoport
Suggested-by: Jonathan Corbet
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/mm/index.rst | 1 +
Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} | 0
Documentation/admin-guide/sysctl/vm.rst | 2 +-
Documentation/gpu/drm-mm.rst| 2 +-
init/Kconfig| 2 +-
mm/Kconfig | 2 +-
mm/nommu.c | 2 +-
7 files changed, 6 insertions(+), 5 deletions(-)
rename Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} (100%)
diff --git a/Documentation/admin-guide/mm/index.rst
b/Documentation/admin-guide/mm/index.rst
index 11db46448354..774dad6d3d29 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -31,6 +31,7 @@ the Linux memory management.
idle_page_tracking
ksm
memory-hotplug
+ nommu-map
numa_memory_policy
numaperf
pagemap
diff --git a/Documentation/nommu-mmap.txt
b/Documentation/admin-guide/mm/nommu-mmap.rst
similarity index 100%
rename from Documentation/nommu-mmap.txt
rename to Documentation/admin-guide/mm/nommu-mmap.rst
diff --git a/Documentation/admin-guide/sysctl/vm.rst
b/Documentation/admin-guide/sysctl/vm.rst
index 4b7c496199ca..4b9d2e8e9142 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -598,7 +598,7 @@ trimming of allocations is initiated.
The default value is 1.
-See Documentation/nommu-mmap.txt for more information.
+See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
numa_zonelist_order
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 8d10e6b38918..9abee1589c1e 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -311,7 +311,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill
the struct
a pointer on drm_gem_cma_get_unmapped_area().
More detailed information about get_unmapped_area can be found in
-Documentation/nommu-mmap.txt
+Documentation/admin-guide/mm/nommu-mmap.rst
Memory Coherency
diff --git a/init/Kconfig b/init/Kconfig
index a46aa8f3174d..2dd5531dae98 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1957,7 +1957,7 @@ config MMAP_ALLOW_UNINITIALIZED
userspace. Since that isn't generally a problem on no-MMU systems,
it is normally safe to say Y here.
- See Documentation/nommu-mmap.txt for more information.
+ See Documentation/mm/nommu-mmap.rst for more information.
config SYSTEM_DATA_VERIFICATION
def_bool n
diff --git a/mm/Kconfig b/mm/Kconfig
index f2104cc0d35c..d41f3fa7e923 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -387,7 +387,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
This option specifies the initial value of this option. The default
of 1 says that all excess pages should be trimmed.
- See Documentation/nommu-mmap.txt for more information.
+ See Documentation/mm/nommu-mmap.rst for more information.
config TRANSPARENT_HUGEPAGE
bool "Transparent Hugepage Support"
diff --git a/mm/nommu.c b/mm/nommu.c
index f32a69095d50..314174817b04 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -5,7 +5,7 @@
* Replacement code for mm functions to support CPU's that don't
* have any form of memory management unit (thus no virtual memory).
*
- * See Documentation/nommu-mmap.txt
+ * See Documentation/mm/nommu-mmap.rst
*
* Copyright (c) 2004-2008 David Howells
* Copyright (c) 2000-2003 David McCullough
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.
Am 23.06.20 um 12:22 schrieb Daniel Vetter: On Mon, Jun 22, 2020 at 03:48:29PM -0400, Alex Deucher wrote: On Mon, Jun 22, 2020 at 3:38 PM Christian König wrote: Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky: Use the new TTM interface to invalidate all exsisting BO CPU mappings form all user proccesses. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König I think those two patches could already land in amd-staging-drm-next since they are a good idea independent of how else we fix the other issues. Please make sure they land in drm-misc as well. Not sure that's much use, since without any of the fault side changes you just blow up on the first refault. Seems somewhat silly to charge ahead on this with the other bits still very much under discussion. Well what I wanted to say is that we don't need to send out those simple patches once more. Plus I suggested a possible bikeshed here :-) No bikeshed, but indeed a rather good idea to not make this a TTM function. Christian. -Daniel Alex --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 43592dc..6932d75 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev) struct drm_device *dev = pci_get_drvdata(pdev); drm_dev_unplug(dev); + ttm_bo_unmap_virtual_address_space(&adev->mman.bdev); amdgpu_driver_unload_kms(dev); pci_disable_device(pdev); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] Host1x/TegraDRM UAPI
# Host1x/TegraDRM UAPI proposal
This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace
the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in
many ways.
I haven't written any implementation yet -- I'll do that once there is
some agreement on the high-level design.
Current open items:
* The syncpoint UAPI allows userspace to create sync_file FDs with
arbitrary syncpoint fences. dma_fence code currently seems to assume all
fences will be signaled, which would not necessarily be the case with
this interface.
* Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
Not sure if they are still needed.
## Introduction to the hardware
Tegra Host1x is a hardware block providing the following capabilities:
* Syncpoints, a unified whole-system synchronization primitive, allowing
synchronization of work between graphics, compute and multimedia
engines, CPUs including cross-VM synchronization, and devices on the
PCIe bus, without incurring CPU overhead.
* Channels, a command DMA mechanism allowing asynchronous programming of
various engines, integrating with syncpoints.
* Hardware virtualization support for syncpoints and channels. (On
Tegra186 and newer)
This proposal defines APIs for userspace access to syncpoints and
channels. Kernel drivers can additionally use syncpoints and channels
internally, providing other userspace interfaces (e.g. V4L2).
Syncpoint and channel interfaces are split into separate parts, as
syncpoints are useful as a system synchronization primitive even without
using the engine drivers provided through TegraDRM. For example, a
computer vision pipeline consisting of video capture, CPU processing and
GPU processing would not necessarily use the engines provided by
TegraDRM. See the Example workflows section for more details.
## Syncpoint interface
Syncpoints are a set of 32-bit values providing the following operations:
* Atomically increment value by one
* Read current value
* Wait until value reaches specified threshold. For waiting, the 32-bit
value space is treated modulo 2^32; e.g. if the current value is
0x, then value 0x0 is considered to be one increment in the future.
Each syncpoint is identified by a system-global ID ranging between [0,
number of syncpoints supported by hardware). The entire system has
read-only access to all syncpoints based on their ID.
Syncpoints are managed through the device node /dev/host1x provided by
the gpu/host1x driver.
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing it.
Only the owner of the file descriptor is allowed to mutate the value of
the syncpoint.
```
struct host1x_ctrl_allocate_syncpoint {
/**
* @fd:
*
* [out] New file descriptor representing the allocated syncpoint.
*/
__s32 fd;
__u32 reserved[3];
};
```
### IOCTL HOST1X_SYNCPOINT_INFO (on syncpoint file descriptor)
Allows retrieval of system-global syncpoint ID corresponding to syncpoint.
Use cases:
* Passing ID to other system components that identify syncpoints by ID
* Debugging and testing
```
struct host1x_syncpoint_info {
/**
* @id:
*
* [out] System-global ID of the syncpoint.
*/
__u32 id;
__u32 reserved[3];
};
```
### IOCTL HOST1X_SYNCPOINT_INCREMENT (on syncpoint file descriptor)
Allows incrementing of the syncpoint value.
Use cases:
* Signalling work completion when executing a pipeline step on the CPU
* Debugging and testing
```
struct host1x_syncpoint_increment {
/**
* @count:
*
* [in] Number of times to increment syncpoint. Value can be
* observed in in-between values, but increments are atomic.
*/
__u32 count;
};
```
### IOCTL HOST1X_READ_SYNCPOINT (on /dev/host1x)
Read the value of a syncpoint based on its ID.
Use cases:
* Allows more fine-grained tracking of task progression for debugging
purposes
```
struct host1x_ctrl_read_syncpoint {
/**
* @id:
*
* [in] ID of syncpoint to read.
*/
__u32 id;
/**
* @value:
*
* [out] Value of the syncpoint.
*/
__u32 value;
};
```
### IOCTL HOST1X_CREATE_FENCE (on /dev/host1x)
Creates a new SYNC_FILE fence file descriptor for the specified
syncpoint ID and threshold.
Use cases:
* Creating a fence when receiving ID/threshold pair from another system
component
* Creating a postfence when executing a pipeline step on the CPU
* Creating a postfence when executing a pipeline step controlled by
userspace (e.g. GPU userspace submission)
```
struct host1x_ctrl_create_fence {
/**
* @id:
*
* [in] ID of the syncpoint for which to create a fence.
*/
__u32 id;
/**
* @threshold:
*
* [in] Threshold value for fence.
*/
Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space
Am 23.06.20 um 12:25 schrieb Daniel Vetter:
On Tue, Jun 23, 2020 at 01:00:02AM -0400, Andrey Grodzovsky wrote:
On 6/22/20 5:45 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
This seems to be missing the code to invalidate all the dma-buf mmaps?
Probably needs more testcases if you're not yet catching this. Or am I
missing something, and we're exchanging the the address space also for
dma-buf?
-Daniel
IMHO the device address space includes all user clients having a CPU view of
the BO either from direct mapping though drm file or by mapping through
imported BO's FD.
Uh this is all very confusing and very much midlayer-y thanks to ttm.
I think a much better solution would be to have a core gem helper for
this (well not even gem really, this is core drm), which directly uses
drm_device->anon_inode->i_mapping.
Then
a) it clearly matches what drm_prime.c does on export
b) can be reused across all drivers, not just ttm
So much better.
What's more, we could then very easily make the generic
drm_dev_unplug_and_unmap helper I've talked about for the amdgpu patch,
which I think would be really neat&pretty.
Good point, that is indeed a rather nice idea.
Christian.
Thoughts?
-Daniel
Andrey
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
include/drm/ttm/ttm_bo_driver.h | 7 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c5b516f..926a365 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
ttm_bo_unmap_virtual_locked(bo);
ttm_mem_io_unlock(man);
}
-
-
EXPORT_SYMBOL(ttm_bo_unmap_virtual);
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)
+{
+ unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
+}
+EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
+
int ttm_bo_wait(struct ttm_buffer_object *bo,
bool interruptible, bool no_wait)
{
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd0..39ea44f 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
/**
+ * ttm_bo_unmap_virtual_address_space
+ *
+ * @bdev: tear down all the virtual mappings for this device
+ */
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
+
+/**
* ttm_bo_unmap_virtual
*
* @bo: tear down the virtual mappings for this BO
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Deepak Rawat > Sent: Monday, June 22, 2020 4:06 AM > > DRM driver for hyperv synthetic video device, based on hyperv_fb > framebuffer driver. Also added config option "DRM_HYPERV" to enabled > this driver. Hi Deepak, I had a quick look and overall the patch as v1 looks good to me. Some quick comments: 1. hyperv_vmbus_probe() assumes the existence of the PCI device, which is not true in a Hyper-V Generation-2 VM. 2. It looks some other functionality in the hyperv_fb driver has not been implemented in this new driver either, e.g. the handling of the SYNTHVID_FEATURE_CHANGE msg. Thanks, -- Dexuan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [igt-dev] [Intel-gfx] [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Mon, Jun 22, 2020 at 06:31:24PM +0300, Jani Nikula wrote: > On Tue, 16 Jun 2020, ramadevi.ga...@intel.com wrote: > > From: Gandi Ramadevi > > > > Add DG1 PCI ID > > There are no DG1 PCI IDs in kernel. So please don't add them here > either. Also, do we have anything left using libdrm-intel? -Daniel > > BR, > Jani. > > > > > > Signed-off-by: Gandi Ramadevi > > --- > > intel/i915_pciids.h | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h > > index 662d8351..724e68a0 100644 > > --- a/intel/i915_pciids.h > > +++ b/intel/i915_pciids.h > > @@ -605,4 +605,9 @@ > > INTEL_VGA_DEVICE(0x9AD9, info), \ > > INTEL_VGA_DEVICE(0x9AF8, info) > > > > +/* DG1 */ > > +#define INTEL_DG1_IDS(info) \ > > +INTEL_VGA_DEVICE(0x4905, info), \ > > +INTEL_VGA_DEVICE(0x4906, info) > > + > > #endif /* _I915_PCIIDS_H */ > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: panel-orientation-quirks: Add quirk for Asus T101HA panel
Hi, On 5/31/20 7:25 PM, Emil Velikov wrote: On Sun, 31 May 2020 at 10:30, Hans de Goede wrote: Like the Asus T100HA the Asus T101HA also uses a panel which has been mounted 90 degrees rotated, add a quirk for this. Reading the commit message, made me wonder: If it's similar why it doesn't use the same quirk? Something like the following helps: ... 90 degrees rotated, albeit in the opposite direction. Add a quirk for this. With that the series is: Reviewed-by: Emil Velikov Thank you, I've ammended the commit msg with your suggestion and pushed the 2 patches to drm-misc-fixes. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/18] drm/amdgpu: add dma-fence annotations to atomic commit path
Hi Roland & vmwgfx maintainers, Thomas has played around with these annotations on his vmwgfx setup, and found some issues. Apparently in the atomic_commit_tail path when handling the dirty rectangle stuff you acquire a ttm reservation, which is a no-go since it could deadlock with other paths - atomic commits can produce a dma_fence. This patch here highlights that with the new annotations, and apparently causes a lockdep splat if you go through the dirty rect paths (not sure if it also happens otherwise, Thomas can fill you in with the details). Can you pls take a look at this? I'm happy to help out with analyzing any lockdep splats. For actual fixes Thomas is better since I don't understand a lot of how drm/vmwgfx works internally. Cheers, Daniel On Thu, Jun 4, 2020 at 10:12 AM Daniel Vetter wrote: > > I need a canary in a ttm-based atomic driver to make sure the > dma_fence_begin/end_signalling annotations actually work. > > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index bdba0bfd6df1..adabfa929f42 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -57,6 +57,7 @@ > > #include "ivsrcid/ivsrcid_vislands30.h" > > +#include > #include > #include > #include > @@ -7320,6 +7321,9 @@ static void amdgpu_dm_atomic_commit_tail(struct > drm_atomic_state *state) > struct drm_connector_state *old_con_state, *new_con_state; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; > int crtc_disable_count = 0; > + bool fence_cookie; > + > + fence_cookie = dma_fence_begin_signalling(); > > drm_atomic_helper_update_legacy_modeset_state(dev, state); > > @@ -7600,6 +7604,8 @@ static void amdgpu_dm_atomic_commit_tail(struct > drm_atomic_state *state) > /* Signal HW programming completion */ > drm_atomic_helper_commit_hw_done(state); > > + dma_fence_end_signalling(fence_cookie); > + > if (wait_for_vblank) > drm_atomic_helper_wait_for_flip_done(dev, state); > > -- > 2.26.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space
On Tue, Jun 23, 2020 at 01:00:02AM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:45 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
> > > Helper function to be used to invalidate all BOs CPU mappings
> > > once device is removed.
> > >
> > > Signed-off-by: Andrey Grodzovsky
> > This seems to be missing the code to invalidate all the dma-buf mmaps?
> >
> > Probably needs more testcases if you're not yet catching this. Or am I
> > missing something, and we're exchanging the the address space also for
> > dma-buf?
> > -Daniel
>
>
> IMHO the device address space includes all user clients having a CPU view of
> the BO either from direct mapping though drm file or by mapping through
> imported BO's FD.
Uh this is all very confusing and very much midlayer-y thanks to ttm.
I think a much better solution would be to have a core gem helper for
this (well not even gem really, this is core drm), which directly uses
drm_device->anon_inode->i_mapping.
Then
a) it clearly matches what drm_prime.c does on export
b) can be reused across all drivers, not just ttm
So much better.
What's more, we could then very easily make the generic
drm_dev_unplug_and_unmap helper I've talked about for the amdgpu patch,
which I think would be really neat&pretty.
Thoughts?
-Daniel
>
> Andrey
>
>
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
> > > include/drm/ttm/ttm_bo_driver.h | 7 +++
> > > 2 files changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index c5b516f..926a365 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct
> > > ttm_buffer_object *bo)
> > > ttm_bo_unmap_virtual_locked(bo);
> > > ttm_mem_io_unlock(man);
> > > }
> > > -
> > > -
> > > EXPORT_SYMBOL(ttm_bo_unmap_virtual);
> > > +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)
> > > +{
> > > + unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
> > > +}
> > > +EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
> > > +
> > > int ttm_bo_wait(struct ttm_buffer_object *bo,
> > > bool interruptible, bool no_wait)
> > > {
> > > diff --git a/include/drm/ttm/ttm_bo_driver.h
> > > b/include/drm/ttm/ttm_bo_driver.h
> > > index c9e0fd0..39ea44f 100644
> > > --- a/include/drm/ttm/ttm_bo_driver.h
> > > +++ b/include/drm/ttm/ttm_bo_driver.h
> > > @@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> > > void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
> > > /**
> > > + * ttm_bo_unmap_virtual_address_space
> > > + *
> > > + * @bdev: tear down all the virtual mappings for this device
> > > + */
> > > +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
> > > +
> > > +/**
> > >* ttm_bo_unmap_virtual
> > >*
> > >* @bo: tear down the virtual mappings for this BO
> > > --
> > > 2.7.4
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.
On Mon, Jun 22, 2020 at 03:48:29PM -0400, Alex Deucher wrote: > On Mon, Jun 22, 2020 at 3:38 PM Christian König > wrote: > > > > Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky: > > > Use the new TTM interface to invalidate all exsisting BO CPU mappings > > > form all user proccesses. > > > > > > Signed-off-by: Andrey Grodzovsky > > > > Reviewed-by: Christian König > > > > I think those two patches could already land in amd-staging-drm-next > > since they are a good idea independent of how else we fix the other issues. > > Please make sure they land in drm-misc as well. Not sure that's much use, since without any of the fault side changes you just blow up on the first refault. Seems somewhat silly to charge ahead on this with the other bits still very much under discussion. Plus I suggested a possible bikeshed here :-) -Daniel > > Alex > > > > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > index 43592dc..6932d75 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev) > > > struct drm_device *dev = pci_get_drvdata(pdev); > > > > > > drm_dev_unplug(dev); > > > + ttm_bo_unmap_virtual_address_space(&adev->mman.bdev); > > > amdgpu_driver_unload_kms(dev); > > > > > > pci_disable_device(pdev); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements
On Tue, Jun 23, 2020 at 10:45:51AM +0200, Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 11:20:51AM +0100, Brian Starkey wrote:
> > On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > > > Hi Simon,
> > > >
> > > > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > > > There have suggestions to bake pitch alignment, address alignement,
> > > > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > > > constraints into modifiers. Last time this was brought up it seemed
> > > > > like the consensus was to not allow this. Document this in
> > > > > drm_fourcc.h.
> > > > >
> > > > > There are several reasons for this.
> > > > >
> > > > > - Encoding all of these constraints in the modifiers would explode the
> > > > > search space pretty quickly (we only have 64 bits to work with).
> > > > > - Modifiers need to be unambiguous: a buffer can only have a single
> > > > > modifier.
> > > > > - Modifier users aren't expected to parse modifiers (except drivers).
> > > > >
> > > > > v2: add paragraph about aliases (Daniel)
> > > > >
> > > > > v3: fix unrelated changes sent with the patch
> > > > >
> > > > > v4: disambiguate users between driver and higher-level programs
> > > > > (Brian,
> > > > > Daniel)
> > > > >
> > > > > Signed-off-by: Simon Ser
> > > > > Reviewed-by: Daniel Vetter
> > > > > Cc: Daniel Stone
> > > > > Cc: Bas Nieuwenhuizen
> > > > > Cc: Dave Airlie
> > > > > Cc: Marek Olšák
> > > > > Cc: Alex Deucher
> > > > > Cc: Neil Armstrong
> > > > > Cc: Michel Dänzer
> > > > > Cc: Brian Starkey
> > > > > ---
> > > > > include/uapi/drm/drm_fourcc.h | 22 ++
> > > > > 1 file changed, 22 insertions(+)
> > > > >
> > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > index 490143500a50..4d3f819dca0b 100644
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -58,6 +58,28 @@ extern "C" {
> > > > > * may preserve meaning - such as number of planes - from the fourcc
> > > > > code,
> > > > > * whereas others may not.
> > > > > *
> > > > > + * Modifiers must uniquely encode buffer layout. In other words, a
> > > > > buffer must
> > > > > + * match only a single modifier. A modifier must not be a subset of
> > > > > layouts of
> > > > > + * another modifier. For instance, it's incorrect to encode pitch
> > > > > alignment in
> > > > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > > > > 32-pixel
> > > > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > > > + * requirements.
> > > > > + *
> > > > > + * For modifiers where the combination of fourcc code and modifier
> > > > > can alias,
> > > > > + * a canonical pair needs to be defined and used by all drivers. An
> > > > > example
> > > > > + * is AFBC, where both ARGB and ABGR have the exact same compressed
> > > > > layout.
> > > >
> > > > I still don't agree with this sentence. ARGB and ABGR have different
> > > > compressed layouts in AFBC.
> > >
> > > Hm then maybe I got confused for the exact reason why afbc has defined
> > > canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> > > BGR versions, no RGB anywhere to be found.
> > >
> > > What's the reason then behind the "Formats which are not listed should be
> > > avoided." in that doc? That's the case I wanted to refer to here.
> >
> > Basically there's hardware which supports only BGR, hardware which
> > "ignores" swizzle (treats all as BGR), and hardware which supports
> > both BGR and RGB. Even amongst first-party implementations it's
> > inconsistent.
> >
> > This leads to a potentially confusing situation where someone with
> > hardware which "ignores" swizzle assumes that's always the case.
> >
> > To avoid that, we wanted to be explicit that ordering is important:
> >
> > | The assignment of input/output color channels must be consistent
> > | between the encoder and the decoder for correct operation, otherwise
> > | the consumer will interpret the decoded data incorrectly.
> > | ...
> > | The component ordering is communicated via the fourcc code in the
> > | fourcc:modifier pair. In general, component '0' is considered to
> > | reside in the least-significant bits of the corresponding linear
> > | format. For example, COMP(bits):
> >
> > And, to try and ensure best cross compatibility, we want BGR to be
> > used most often. We expect that to be supported by the most hardware:
> >
> > | For maximum compatibility across devices, the table below defines
> > | canonical formats for use between AFBC-enabled devices. Formats which
> > | are listed here must be used exactly as specified when using the AFBC
> > | modifiers. Formats which are not listed should be avoided.
>
> Ok, so not such an example. Simon, maybe we could go with something like
[PATCH v2 0/9] Convert the remaining text files to ReST and add SPDX for GFDL
The main goal of this series is to finish the ReST conversion. After this
series, we have just those files still in plain old format:
- Documentation/RCU/RTFP.txt
- Documentation/atomic_bitops.txt
- Documentation/memory-barriers.txt
- Documentation/atomic_t.txt
- Documentation/filesystems/dax.txt
- Documentation/filesystems/path-lookup.txt
- Documentation/virt/kvm/devices/README
PS.: I'm using a script to remove false-positives and ignore non-converted
translated files.
It is worth to mention that this fseries contain licenses for the two
GFDL licenses used within the Kernel: GFDL-1.1+ and GFDL-1.2.
Those licenses are the result of long discussions with the SPDX legal
team, and are part of this commit, to be added for the future
SPDX 3.10 version:
https://github.com/spdx/license-list-XML/pull/1048/commits/f695d2ac65230d0f4161ba58fff2f9d87bb5a053
Mauro Carvalho Chehab (9):
docs: dt: convert booting-without-of.txt to ReST format
LICENSES: add GFDL licenses
media: docs: use SPDX GFDL-1.1-or-later-no-invariants
docs: trace: ring-buffer-design.txt: convert to ReST format
docs: move nommu-mmap.txt to admin-guide and rename to ReST
docs: move mailbox.txt to driver-api and rename it
docs: move other kAPI documents to core-api
docs: Add remaining Documentation/*.txt at staging/index.rst
docs: staging: use small font for literal includes
Documentation/admin-guide/mm/index.rst| 1 +
.../mm/nommu-mmap.rst}| 0
Documentation/admin-guide/sysctl/vm.rst | 2 +-
Documentation/arm/booting.rst | 2 +-
.../bus-virt-phys-mapping.rst}| 0
Documentation/core-api/index.rst | 3 +
.../this_cpu_ops.rst} | 0
.../unaligned-memory-access.rst | 0
...-without-of.txt => booting-without-of.rst} | 298 ---
Documentation/devicetree/index.rst| 1 +
Documentation/driver-api/index.rst| 1 +
.../{mailbox.txt => driver-api/mailbox.rst} | 0
Documentation/gpu/drm-mm.rst | 2 +-
Documentation/staging/index.rst | 24 +
Documentation/trace/index.rst | 1 +
...ffer-design.txt => ring-buffer-design.rst} | 778 +-
Documentation/translations/zh_CN/arm/Booting | 2 +-
.../userspace-api/media/cec/cec-api.rst | 9 +-
.../media/cec/cec-func-close.rst | 9 +-
.../media/cec/cec-func-ioctl.rst | 9 +-
.../userspace-api/media/cec/cec-func-open.rst | 9 +-
.../userspace-api/media/cec/cec-func-poll.rst | 9 +-
.../userspace-api/media/cec/cec-funcs.rst | 9 +-
.../userspace-api/media/cec/cec-header.rst| 9 +-
.../userspace-api/media/cec/cec-intro.rst | 9 +-
.../media/cec/cec-ioc-adap-g-caps.rst | 9 +-
.../media/cec/cec-ioc-adap-g-log-addrs.rst| 9 +-
.../media/cec/cec-ioc-adap-g-phys-addr.rst| 9 +-
.../media/cec/cec-ioc-dqevent.rst | 9 +-
.../media/cec/cec-ioc-g-mode.rst | 9 +-
.../media/cec/cec-ioc-receive.rst | 9 +-
.../media/cec/cec-pin-error-inj.rst | 9 +-
.../dvb/audio-bilingual-channel-select.rst| 9 +-
.../media/dvb/audio-channel-select.rst| 9 +-
.../media/dvb/audio-clear-buffer.rst | 9 +-
.../media/dvb/audio-continue.rst | 9 +-
.../userspace-api/media/dvb/audio-fclose.rst | 9 +-
.../userspace-api/media/dvb/audio-fopen.rst | 9 +-
.../userspace-api/media/dvb/audio-fwrite.rst | 9 +-
.../media/dvb/audio-get-capabilities.rst | 9 +-
.../media/dvb/audio-get-status.rst| 9 +-
.../userspace-api/media/dvb/audio-pause.rst | 9 +-
.../userspace-api/media/dvb/audio-play.rst| 9 +-
.../media/dvb/audio-select-source.rst | 9 +-
.../media/dvb/audio-set-av-sync.rst | 9 +-
.../media/dvb/audio-set-bypass-mode.rst | 9 +-
.../userspace-api/media/dvb/audio-set-id.rst | 9 +-
.../media/dvb/audio-set-mixer.rst | 9 +-
.../media/dvb/audio-set-mute.rst | 9 +-
.../media/dvb/audio-set-streamtype.rst| 9 +-
.../userspace-api/media/dvb/audio-stop.rst| 9 +-
.../userspace-api/media/dvb/audio.rst | 9 +-
.../media/dvb/audio_data_types.rst| 9 +-
.../media/dvb/audio_function_calls.rst| 9 +-
.../userspace-api/media/dvb/ca-fclose.rst | 9 +-
.../userspace-api/media/dvb/ca-fopen.rst | 9 +-
.../userspace-api/media/dvb/ca-get-cap.rst| 9 +-
.../media/dvb/ca-get-descr-info.rst | 9 +-
.../userspace-api/media/dvb/ca-get-msg.rst| 9 +-
.../media/dvb/ca-get-slot-info.rst| 9 +-
.../userspace-api/media/dvb/ca-reset.rst | 9 +-
.../userspace-api/media/dvb/ca-send-msg.rst | 9 +-
.../userspace-api/media/dvb/ca-set-descr.rst | 9 +-
Documentation/userspace-api/med
[PATCH v2 5/9] docs: move nommu-mmap.txt to admin-guide and rename to ReST
The nommu-mmap.txt file provides description of user visible
behaviuour. So, move it to the admin-guide.
As it is already at the ReST, also rename it.
Suggested-by: Mike Rapoport
Suggested-by: Jonathan Corbet
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/mm/index.rst | 1 +
Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} | 0
Documentation/admin-guide/sysctl/vm.rst | 2 +-
Documentation/gpu/drm-mm.rst| 2 +-
init/Kconfig| 2 +-
mm/Kconfig | 2 +-
mm/nommu.c | 2 +-
7 files changed, 6 insertions(+), 5 deletions(-)
rename Documentation/{nommu-mmap.txt => admin-guide/mm/nommu-mmap.rst} (100%)
diff --git a/Documentation/admin-guide/mm/index.rst
b/Documentation/admin-guide/mm/index.rst
index 11db46448354..774dad6d3d29 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -31,6 +31,7 @@ the Linux memory management.
idle_page_tracking
ksm
memory-hotplug
+ nommu-map
numa_memory_policy
numaperf
pagemap
diff --git a/Documentation/nommu-mmap.txt
b/Documentation/admin-guide/mm/nommu-mmap.rst
similarity index 100%
rename from Documentation/nommu-mmap.txt
rename to Documentation/admin-guide/mm/nommu-mmap.rst
diff --git a/Documentation/admin-guide/sysctl/vm.rst
b/Documentation/admin-guide/sysctl/vm.rst
index 4b7c496199ca..4b9d2e8e9142 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -598,7 +598,7 @@ trimming of allocations is initiated.
The default value is 1.
-See Documentation/nommu-mmap.txt for more information.
+See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
numa_zonelist_order
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 8d10e6b38918..9abee1589c1e 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -311,7 +311,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill
the struct
a pointer on drm_gem_cma_get_unmapped_area().
More detailed information about get_unmapped_area can be found in
-Documentation/nommu-mmap.txt
+Documentation/admin-guide/mm/nommu-mmap.rst
Memory Coherency
diff --git a/init/Kconfig b/init/Kconfig
index a46aa8f3174d..2dd5531dae98 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1957,7 +1957,7 @@ config MMAP_ALLOW_UNINITIALIZED
userspace. Since that isn't generally a problem on no-MMU systems,
it is normally safe to say Y here.
- See Documentation/nommu-mmap.txt for more information.
+ See Documentation/mm/nommu-mmap.rst for more information.
config SYSTEM_DATA_VERIFICATION
def_bool n
diff --git a/mm/Kconfig b/mm/Kconfig
index f2104cc0d35c..d41f3fa7e923 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -387,7 +387,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
This option specifies the initial value of this option. The default
of 1 says that all excess pages should be trimmed.
- See Documentation/nommu-mmap.txt for more information.
+ See Documentation/mm/nommu-mmap.rst for more information.
config TRANSPARENT_HUGEPAGE
bool "Transparent Hugepage Support"
diff --git a/mm/nommu.c b/mm/nommu.c
index f32a69095d50..314174817b04 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -5,7 +5,7 @@
* Replacement code for mm functions to support CPU's that don't
* have any form of memory management unit (thus no virtual memory).
*
- * See Documentation/nommu-mmap.txt
+ * See Documentation/mm/nommu-mmap.rst
*
* Copyright (c) 2004-2008 David Howells
* Copyright (c) 2000-2003 David McCullough
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Mon, Jun 22, 2020 at 03:20:34PM -0700, Deepak Rawat wrote:
> On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > +/* Should be done only once during init and resume */
> > > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > > + phys_addr_t vram_pp)
> > > +{
> > > + struct hyperv_device *hv = hv_get_drvdata(hdev);
> > > + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> > > + unsigned long t;
> > > + int ret = 0;
> > > +
> > > + memset(msg, 0, sizeof(struct synthvid_msg));
> > > + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> > > + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> > > + sizeof(struct synthvid_vram_location);
> > > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> > > + msg->vram.is_vram_gpa_specified = 1;
> > > + synthvid_send(hdev, msg);
> >
> > That suggests it is possible to define multiple framebuffers in vram,
> > then pageflip by setting vram.vram_gpa. If that is the case I'm
> > wondering whenever vram helpers are a better fit maybe? You don't
> > have
> > to blit each and every display update then.
>
> Thanks for the review. Unfortunately only the first vmbus message take
> effect and subsequent calls are ignored. I originally implemented using
> vram helpers but I figured out calling this vmbus message again won't
> change the vram location.
I think that needs a very big comment. Maybe even enforce that with a
"vram_gpa_set" boolean in the device structure, and complain if we try to
do that twice.
Also I guess congrats to microsoft for defining things like that :-/
-Daniel
>
> >
> > FYI: cirrus goes the blit route because (a) the amount of vram is
> > very
> > small so trying to store multiple framebuffers there is out of
> > question,
> > and (b) cirrus converts formats on the fly to hide some hardware
> > oddities.
> >
> > take care,
> > Gerd
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 23.06.20 um 11:12 schrieb Deepak Rawat: > On Tue, 2020-06-23 at 09:59 +0200, Thomas Zimmermann wrote: >> Hi Deepak >> >> I did not receive you pat series, so I can only comment on Sam's >> reply. >> See below for some points. > > Hi Thomas, Thanks for the review. I wanted to add you in cc list but > messed it up with final git send-email. Sorry about that. I am not sure > why you didn't received it via dri-devel. The patch series do show up > in dri-devel archive. I wonder if other people also have similar > issues. I think it's related to a problem on my side. Some of my email infrastructure was not available over the weekend. Best regards Thomas > > + struct hv_device *hdev; +}; + +#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev) >> >> Could this be a function? > > Is there a reason to use a function here? > >> + +/* --- --- */ +/* Hyper-V Synthetic Video Protocol */ >> >> The comments look awkward. Unless this style has been used within >> DRM, >> maybe just use >> >> /* >> * ... >> */ >> > > This style is copy-paste from cirrus, and bochs also have same style. > Perhaps historical. Anyway I agree to I should get rid of this. > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Tue, 2020-06-23 at 09:59 +0200, Thomas Zimmermann wrote: > Hi Deepak > > I did not receive you pat series, so I can only comment on Sam's > reply. > See below for some points. Hi Thomas, Thanks for the review. I wanted to add you in cc list but messed it up with final git send-email. Sorry about that. I am not sure why you didn't received it via dri-devel. The patch series do show up in dri-devel archive. I wonder if other people also have similar issues. > > > > > > + struct hv_device *hdev; > > > +}; > > > + > > > +#define to_hv(_dev) container_of(_dev, struct hyperv_device, > > > dev) > > Could this be a function? Is there a reason to use a function here? > > > > + > > > +/* --- > > > --- */ > > > +/* Hyper-V Synthetic Video > > > Protocol */ > > The comments look awkward. Unless this style has been used within > DRM, > maybe just use > > /* > * ... > */ > This style is copy-paste from cirrus, and bochs also have same style. Perhaps historical. Anyway I agree to I should get rid of this. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/8] RFC Support hot device unplug in amdgpu
On 2020-06-23 7:14 a.m., Andrey Grodzovsky wrote: > I am fighting with Thunderbird to make limit a line to 80 chars but > nothing helps. Any suggestions please. Maybe try disabling mail.compose.default_to_paragraph, or check other *wrap* settings. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements
On Mon, Jun 22, 2020 at 11:20:51AM +0100, Brian Starkey wrote:
> On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > > Hi Simon,
> > >
> > > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > > There have suggestions to bake pitch alignment, address alignement,
> > > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > > constraints into modifiers. Last time this was brought up it seemed
> > > > like the consensus was to not allow this. Document this in drm_fourcc.h.
> > > >
> > > > There are several reasons for this.
> > > >
> > > > - Encoding all of these constraints in the modifiers would explode the
> > > > search space pretty quickly (we only have 64 bits to work with).
> > > > - Modifiers need to be unambiguous: a buffer can only have a single
> > > > modifier.
> > > > - Modifier users aren't expected to parse modifiers (except drivers).
> > > >
> > > > v2: add paragraph about aliases (Daniel)
> > > >
> > > > v3: fix unrelated changes sent with the patch
> > > >
> > > > v4: disambiguate users between driver and higher-level programs (Brian,
> > > > Daniel)
> > > >
> > > > Signed-off-by: Simon Ser
> > > > Reviewed-by: Daniel Vetter
> > > > Cc: Daniel Stone
> > > > Cc: Bas Nieuwenhuizen
> > > > Cc: Dave Airlie
> > > > Cc: Marek Olšák
> > > > Cc: Alex Deucher
> > > > Cc: Neil Armstrong
> > > > Cc: Michel Dänzer
> > > > Cc: Brian Starkey
> > > > ---
> > > > include/uapi/drm/drm_fourcc.h | 22 ++
> > > > 1 file changed, 22 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 490143500a50..4d3f819dca0b 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -58,6 +58,28 @@ extern "C" {
> > > > * may preserve meaning - such as number of planes - from the fourcc
> > > > code,
> > > > * whereas others may not.
> > > > *
> > > > + * Modifiers must uniquely encode buffer layout. In other words, a
> > > > buffer must
> > > > + * match only a single modifier. A modifier must not be a subset of
> > > > layouts of
> > > > + * another modifier. For instance, it's incorrect to encode pitch
> > > > alignment in
> > > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > > > 32-pixel
> > > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > > + * requirements.
> > > > + *
> > > > + * For modifiers where the combination of fourcc code and modifier can
> > > > alias,
> > > > + * a canonical pair needs to be defined and used by all drivers. An
> > > > example
> > > > + * is AFBC, where both ARGB and ABGR have the exact same compressed
> > > > layout.
> > >
> > > I still don't agree with this sentence. ARGB and ABGR have different
> > > compressed layouts in AFBC.
> >
> > Hm then maybe I got confused for the exact reason why afbc has defined
> > canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> > BGR versions, no RGB anywhere to be found.
> >
> > What's the reason then behind the "Formats which are not listed should be
> > avoided." in that doc? That's the case I wanted to refer to here.
>
> Basically there's hardware which supports only BGR, hardware which
> "ignores" swizzle (treats all as BGR), and hardware which supports
> both BGR and RGB. Even amongst first-party implementations it's
> inconsistent.
>
> This leads to a potentially confusing situation where someone with
> hardware which "ignores" swizzle assumes that's always the case.
>
> To avoid that, we wanted to be explicit that ordering is important:
>
> | The assignment of input/output color channels must be consistent
> | between the encoder and the decoder for correct operation, otherwise
> | the consumer will interpret the decoded data incorrectly.
> | ...
> | The component ordering is communicated via the fourcc code in the
> | fourcc:modifier pair. In general, component '0' is considered to
> | reside in the least-significant bits of the corresponding linear
> | format. For example, COMP(bits):
>
> And, to try and ensure best cross compatibility, we want BGR to be
> used most often. We expect that to be supported by the most hardware:
>
> | For maximum compatibility across devices, the table below defines
> | canonical formats for use between AFBC-enabled devices. Formats which
> | are listed here must be used exactly as specified when using the AFBC
> | modifiers. Formats which are not listed should be avoided.
Ok, so not such an example. Simon, maybe we could go with something like:
* For modifiers where the combination of fourcc code and modifier can alias,
* a canonical pair needs to be defined and used by all drivers. Preferred
* combinations are also encourage where all combinations might
* lead to confusion and unecessarily reduced interoperability. An example
*
Re: [PATCH] drm/mgag200: Enable caching for SHMEM pages
On 6/22/20 11:12 PM, Thomas Zimmermann wrote:
Hi
Am 22.06.20 um 17:00 schrieb Rong Chen:
Hi Thomas,
I tested the patch based on commit 24b806b0a1dd3, the regression
Thanks!
of phoronix-test-suite.glmark2.1024x768.score still exists:
I expected that the test is related to drawing onto the screen.
Hi Thomas,
This server doesn't connect a monitor.
Do you
know what exactly it is testing?
It's a glmark2 test, please see
https://openbenchmarking.org/test/pts/glmark2
the test command is ./glmark2 --annotate -s 1024x768
Best Regards,
Rong Chen
Best regards
Thomas
1f58fcaf27cb7 drm/mgag200: Enable caching for SHMEM pages
2 2 2
24b806b0a1dd3 drm-tip: 2020y-06m-22d-07h-52m-06s UTC integration manifest
2 2 2 2 2
913ec479bb5cc drm/mgag200: Replace VRAM helpers with SHMEM helpers
2 2 2 2 2
88fabb75ea9ed drm/mgag200: Convert to simple KMS helper
165 168 167 165 164
Best Regards,
Rong Chen
On Thu, Jun 18, 2020 at 03:34:35PM +0200, Thomas Zimmermann wrote:
We've had reports about performance regressions after switching
mgag200 from VRAM helpers to SHMEM helpers. SHMEM pages use
writecombine caching by default, but can also use the platform's
default page caching. Doing so improves the performance of I/O
on the framebuffer.
Mgag200's hardware does not access framebuffer pages directly (i.e.,
via DMA), so enabling caching does not have an effect on consistency
of the framebuffer memory or the displayed data.
Signed-off-by: Thomas Zimmermann
Fixes: 913ec479bb5c ("drm/mgag200: Replace VRAM helpers with SHMEM helpers")
Cc: Thomas Zimmermann
Cc: Emil Velikov
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Krzysztof Kozlowski
Cc: Gerd Hoffmann
Cc: Sam Ravnborg
Cc: Rong Chen
Cc: John Donnelly
Link: https://lore.kernel.org/dri-devel/20200617092252.GA5279@shao2-debian/
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index e19660f4a637..7189c7745baf 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -36,6 +36,7 @@ static struct drm_driver mgag200_driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
+ .gem_create_object = drm_gem_shmem_create_object_cached,
DRM_GEM_SHMEM_DRIVER_OPS,
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/14] drm/ast: Move cursor functions to ast_cursor.c
The cursor manipulation functions are unrelated to modesetting. Move
them into their own file.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Makefile | 3 +-
drivers/gpu/drm/ast/ast_cursor.c | 218 +++
drivers/gpu/drm/ast/ast_drv.h| 9 ++
drivers/gpu/drm/ast/ast_mode.c | 195 ---
4 files changed, 229 insertions(+), 196 deletions(-)
create mode 100644 drivers/gpu/drm/ast/ast_cursor.c
diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 561f7c4199e4..6a5b3b247316 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,6 +3,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-ast-y := ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o ast_dp501.o
+ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
+ast_dp501.o
obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
new file mode 100644
index ..53bb6eebc7cd
--- /dev/null
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright 2012 Red Hat Inc.
+ * Parts based on xf86-video-ast
+ * Copyright (c) 2005 ASPEED Technology Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ */
+/*
+ * Authors: Dave Airlie
+ */
+
+#include
+
+#include "ast_drv.h"
+
+/*
+ * Allocate cursor BOs and pins them at the end of VRAM.
+ */
+int ast_cursor_init(struct drm_device *dev)
+{
+ struct ast_private *ast = to_ast_private(dev);
+ size_t size, i;
+ struct drm_gem_vram_object *gbo;
+ int ret;
+
+ size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
+
+ for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ gbo = drm_gem_vram_create(dev, size, 0);
+ if (IS_ERR(gbo)) {
+ ret = PTR_ERR(gbo);
+ goto err_drm_gem_vram_put;
+ }
+ ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
+ DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
+ if (ret) {
+ drm_gem_vram_put(gbo);
+ goto err_drm_gem_vram_put;
+ }
+
+ ast->cursor.gbo[i] = gbo;
+ }
+
+ return 0;
+
+err_drm_gem_vram_put:
+ while (i) {
+ --i;
+ gbo = ast->cursor.gbo[i];
+ drm_gem_vram_unpin(gbo);
+ drm_gem_vram_put(gbo);
+ ast->cursor.gbo[i] = NULL;
+ }
+ return ret;
+}
+
+void ast_cursor_fini(struct drm_device *dev)
+{
+ struct ast_private *ast = to_ast_private(dev);
+ size_t i;
+ struct drm_gem_vram_object *gbo;
+
+ for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ gbo = ast->cursor.gbo[i];
+ drm_gem_vram_unpin(gbo);
+ drm_gem_vram_put(gbo);
+ }
+}
+
+static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
+{
+ union {
+ u32 ul;
+ u8 b[4];
+ } srcdata32[2], data32;
+ union {
+ u16 us;
+ u8 b[2];
+ } data16;
+ u32 csum = 0;
+ s32 alpha_dst_delta, last_alpha_dst_delta;
+ u8 *srcxor, *dstxor;
+ int i, j;
+ u32 per_pixel_copy, two_pixel_copy;
+
+ alpha_dst_delta = AST_MAX_HWC_WIDTH << 1;
+ last_alpha_dst_delta = alpha_dst_delta - (width << 1);
+
+ srcxor = src;
+ dstxor = (u8 *)dst + last_alpha_dst_delta + (AST_MAX_HWC_HEIGHT -
height) * alpha_dst_delta;
+ per_pixel_copy = width & 1;
+ two_pixel_copy = width >> 1;
+
+ for (j = 0; j < height; j++) {
+ for (i = 0; i < two_pixel_copy; i++) {
+
[PATCH 04/14] drm/ast: Update cursor image and checksum from same function
Cursor image and checksum go hand in hand. Update both in the same
place. The helper cannot fail, so remove the return type.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 8f94d4712f66..7474baddf048 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -84,7 +84,7 @@ void ast_cursor_fini(struct ast_private *ast)
}
}
-static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
+static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int
height)
{
union {
u32 ul;
@@ -96,7 +96,8 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int
height)
} data16;
u32 csum = 0;
s32 alpha_dst_delta, last_alpha_dst_delta;
- u8 *srcxor, *dstxor;
+ u8 __iomem *dstxor;
+ const u8 *srcxor;
int i, j;
u32 per_pixel_copy, two_pixel_copy;
@@ -137,16 +138,6 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width,
int height)
}
dstxor += last_alpha_dst_delta;
}
- return csum;
-}
-
-static int ast_cursor_update(void *dst, void *src, unsigned int width,
-unsigned int height)
-{
- u32 csum;
-
- /* do data transfer to cursor cache */
- csum = copy_cursor_image(src, dst, width, height);
/* write checksum + signature */
dst += AST_HWC_SIZE;
@@ -155,8 +146,6 @@ static int ast_cursor_update(void *dst, void *src, unsigned
int width,
writel(height, dst + AST_HWC_SIGNATURE_SizeY);
writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTX);
writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTY);
-
- return 0;
}
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
@@ -188,9 +177,8 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
goto err_drm_gem_vram_vunmap_src;
}
- ret = ast_cursor_update(dst, src, fb->width, fb->height);
- if (ret)
- goto err_drm_gem_vram_vunmap_dst;
+ /* do data transfer to cursor BO */
+ update_cursor_image(dst, src, fb->width, fb->height);
/*
* Always unmap buffers here. Destination buffers are
@@ -203,8 +191,6 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
return 0;
-err_drm_gem_vram_vunmap_dst:
- drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
err_drm_gem_vram_vunmap_src:
drm_gem_vram_vunmap(gbo, src);
err_drm_gem_vram_unpin:
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/14] drm/ast: Replace ast_cursor_move() with ast_cursor_show()
Having a cursor move function is misleading, as it actually enables the
cursor's image for displaying. So rename it to ast_cursor_show(). It's
semantics is to show a cursor at the specified location on the screen.
The displayed cursor is always the image in the cursor front BO.
This change also simplifies struct ast_crtc to being a mere wrapper around
around struct drm_crtc. It will be removed by a later patch.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 42
drivers/gpu/drm/ast/ast_drv.h| 4 +--
drivers/gpu/drm/ast/ast_mode.c | 12 -
3 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 815d95b2f392..8f8fdc831830 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -227,12 +227,27 @@ void ast_cursor_page_flip(struct ast_private *ast)
ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
}
-int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
+static void ast_cursor_set_location(struct ast_private *ast, u16 x, u16 y,
+ u8 x_offset, u8 y_offset)
+{
+ u8 x0 = (x & 0x00ff);
+ u8 x1 = (x & 0x0f00) >> 8;
+ u8 y0 = (y & 0x00ff);
+ u8 y1 = (y & 0x0700) >> 8;
+
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc2, x_offset);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc3, y_offset);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc4, x0);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc5, x1);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc6, y0);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
+}
+
+int ast_cursor_show(struct ast_private *ast, int x, int y,
+ unsigned int offset_x, unsigned int offset_y)
{
- struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
- struct ast_private *ast = to_ast_private(crtc->dev);
struct drm_gem_vram_object *gbo;
- int x_offset, y_offset;
+ u8 x_offset, y_offset;
u8 *dst, *sig;
u8 jreg;
@@ -245,23 +260,20 @@ int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
writel(x, sig + AST_HWC_SIGNATURE_X);
writel(y, sig + AST_HWC_SIGNATURE_Y);
- x_offset = ast_crtc->offset_x;
- y_offset = ast_crtc->offset_y;
if (x < 0) {
- x_offset = (-x) + ast_crtc->offset_x;
+ x_offset = (-x) + offset_x;
x = 0;
+ } else {
+ x_offset = offset_x;
}
-
if (y < 0) {
- y_offset = (-y) + ast_crtc->offset_y;
+ y_offset = (-y) + offset_y;
y = 0;
+ } else {
+ y_offset = offset_y;
}
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc2, x_offset);
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc3, y_offset);
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc4, (x & 0xff));
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc5, ((x >> 8) & 0x0f));
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc6, (y & 0xff));
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, ((y >> 8) & 0x07));
+
+ ast_cursor_set_location(ast, x, y, x_offset, y_offset);
/* dummy write to fire HWC */
jreg = 0x02 |
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index e973c1ab96cb..b00091798ef5 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -239,7 +239,6 @@ struct ast_connector {
struct ast_crtc {
struct drm_crtc base;
- u8 offset_x, offset_y;
};
#define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
@@ -320,6 +319,7 @@ int ast_cursor_init(struct ast_private *ast);
void ast_cursor_fini(struct ast_private *ast);
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
void ast_cursor_page_flip(struct ast_private *ast);
-int ast_cursor_move(struct drm_crtc *crtc, int x, int y);
+int ast_cursor_show(struct ast_private *ast, int x, int y,
+ unsigned int offset_x, unsigned int offset_y);
#endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 90a4050ef1c4..05bbd79b03ca 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -661,21 +661,21 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *old_state)
{
struct drm_plane_state *state = plane->state;
- struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
- struct ast_private *ast = to_ast_private(plane->dev);
- struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
+ struct ast_private *ast = plane->dev->dev_private;
+ unsigned int offset_x, offset_y;
u8 jreg;
- ast_crtc->offset_x = AST_MAX_HWC_WIDTH - fb->width;
- ast_crtc->offset_y = AST_MAX_HWC_WIDTH - fb->height;
+
[PATCH 12/14] drm/ast: Replace struct ast_crtc with struct drm_crtc
Struct ast_crtc has been cleaned up and it's now a wrapper around the
DRM CRTC structure struct drm_crtc. This patch converts the driver to
struct drm_crtc and removes struct ast_crtc.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 5 -
drivers/gpu/drm/ast/ast_mode.c | 11 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ea4de3dce2c4..77226e2fd7c0 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -238,11 +238,6 @@ struct ast_connector {
struct ast_i2c_chan *i2c;
};
-struct ast_crtc {
- struct drm_crtc base;
-};
-
-#define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
#define to_ast_connector(x) container_of(x, struct ast_connector, base)
struct ast_vbios_stdtable {
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 89d9ee0a9e81..43c9686ba0f7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -881,21 +881,22 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
static int ast_crtc_init(struct drm_device *dev)
{
struct ast_private *ast = to_ast_private(dev);
- struct ast_crtc *crtc;
+ struct drm_crtc *crtc;
int ret;
- crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
+ crtc = kzalloc(sizeof(*crtc), GFP_KERNEL);
if (!crtc)
return -ENOMEM;
- ret = drm_crtc_init_with_planes(dev, &crtc->base, &ast->primary_plane,
+ ret = drm_crtc_init_with_planes(dev, crtc, &ast->primary_plane,
&ast->cursor_plane, &ast_crtc_funcs,
NULL);
if (ret)
goto err_kfree;
- drm_mode_crtc_set_gamma_size(&crtc->base, 256);
- drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
+ drm_mode_crtc_set_gamma_size(crtc, 256);
+ drm_crtc_helper_add(crtc, &ast_crtc_helper_funcs);
+
return 0;
err_kfree:
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/14] drm/ast: Keep cursor HW BOs mapped
Updating the image in a cursor's HW BO requires a mapping of the BO's
buffer in the kernel's address space. Cursor image updates can happen
frequently and create CPU overhead.
As cursor HW BOs are small and never move, they are now map exactly
once during the initialization and the mapping is used throughout the
driver's lifetime.
This change also removes a possible source of failures from
ast_cursor_show(). As the helper does not establish mappings, it cannot
fail. As a result, the cursor plane's atomic-update helper does not
call any failable interfaces. All failures are detected before trying
to update the cursor plane.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 44 +---
drivers/gpu/drm/ast/ast_drv.h| 5 ++--
2 files changed, 21 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 5421241015d6..35680402e410 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -39,6 +39,7 @@ int ast_cursor_init(struct ast_private *ast)
struct drm_device *dev = ast->dev;
size_t size, i;
struct drm_gem_vram_object *gbo;
+ void __iomem *vaddr;
int ret;
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
@@ -55,8 +56,16 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_put(gbo);
goto err_drm_gem_vram_put;
}
+ vaddr = drm_gem_vram_vmap(gbo);
+ if (IS_ERR(vaddr)) {
+ ret = PTR_ERR(vaddr);
+ drm_gem_vram_unpin(gbo);
+ drm_gem_vram_put(gbo);
+ goto err_drm_gem_vram_put;
+ }
ast->cursor.gbo[i] = gbo;
+ ast->cursor.vaddr[i] = vaddr;
}
return 0;
@@ -65,9 +74,11 @@ int ast_cursor_init(struct ast_private *ast)
while (i) {
--i;
gbo = ast->cursor.gbo[i];
+ drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
ast->cursor.gbo[i] = NULL;
+ ast->cursor.vaddr[i] = NULL;
}
return ret;
}
@@ -79,6 +90,7 @@ void ast_cursor_fini(struct ast_private *ast)
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
gbo = ast->cursor.gbo[i];
+ drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -154,7 +166,7 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
struct drm_gem_vram_object *gbo;
int ret;
void *src;
- void *dst;
+ void __iomem *dst;
if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
@@ -171,28 +183,16 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
goto err_drm_gem_vram_unpin;
}
- dst = drm_gem_vram_vmap(ast->cursor.gbo[ast->cursor.next_index]);
- if (IS_ERR(dst)) {
- ret = PTR_ERR(dst);
- goto err_drm_gem_vram_vunmap_src;
- }
+ dst = ast->cursor.vaddr[ast->cursor.next_index];
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
- /*
-* Always unmap buffers here. Destination buffers are
-* perma-pinned while the driver is active. We're only
-* changing ref-counters here.
-*/
- drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
drm_gem_vram_vunmap(gbo, src);
drm_gem_vram_unpin(gbo);
return 0;
-err_drm_gem_vram_vunmap_src:
- drm_gem_vram_vunmap(gbo, src);
err_drm_gem_vram_unpin:
drm_gem_vram_unpin(gbo);
return ret;
@@ -243,18 +243,14 @@ static void ast_cursor_set_location(struct ast_private
*ast, u16 x, u16 y,
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
}
-int ast_cursor_show(struct ast_private *ast, int x, int y,
- unsigned int offset_x, unsigned int offset_y)
+void ast_cursor_show(struct ast_private *ast, int x, int y,
+unsigned int offset_x, unsigned int offset_y)
{
- struct drm_gem_vram_object *gbo;
u8 x_offset, y_offset;
- u8 *dst, *sig;
+ u8 __iomem *dst, __iomem *sig;
u8 jreg;
- gbo = ast->cursor.gbo[ast->cursor.next_index];
- dst = drm_gem_vram_vmap(gbo);
- if (IS_ERR(dst))
- return PTR_ERR(dst);
+ dst = ast->cursor.vaddr[ast->cursor.next_index];
sig = dst + AST_HWC_SIZE;
writel(x, sig + AST_HWC_SIGNATURE_X);
@@ -279,10 +275,6 @@ int ast_cursor_show(struct ast_private *ast, int x, int y,
jreg =
[PATCH 02/14] drm/ast: Pass struct ast_private instance to cursor init/fini functions
Removes some typecasting.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 7 +++
drivers/gpu/drm/ast/ast_drv.h| 4 ++--
drivers/gpu/drm/ast/ast_mode.c | 6 --
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 53bb6eebc7cd..1d4f51a7fe22 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -34,9 +34,9 @@
/*
* Allocate cursor BOs and pins them at the end of VRAM.
*/
-int ast_cursor_init(struct drm_device *dev)
+int ast_cursor_init(struct ast_private *ast)
{
- struct ast_private *ast = to_ast_private(dev);
+ struct drm_device *dev = ast->dev;
size_t size, i;
struct drm_gem_vram_object *gbo;
int ret;
@@ -72,9 +72,8 @@ int ast_cursor_init(struct drm_device *dev)
return ret;
}
-void ast_cursor_fini(struct drm_device *dev)
+void ast_cursor_fini(struct ast_private *ast)
{
- struct ast_private *ast = to_ast_private(dev);
size_t i;
struct drm_gem_vram_object *gbo;
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 245ed2e2d775..f7b120f862a8 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -316,8 +316,8 @@ void ast_init_3rdtx(struct drm_device *dev);
void ast_release_firmware(struct drm_device *dev);
/* ast_cursor.c */
-int ast_cursor_init(struct drm_device *dev);
-void ast_cursor_fini(struct drm_device *dev);
+int ast_cursor_init(struct ast_private *ast);
+void ast_cursor_fini(struct ast_private *ast);
int ast_cursor_update(void *dst, void *src, unsigned int width,
unsigned int height);
void ast_cursor_set_base(struct ast_private *ast, u64 address);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c8399699d773..243715e9c237 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1149,7 +1149,7 @@ int ast_mode_init(struct drm_device *dev)
drm_plane_helper_add(&ast->cursor_plane,
&ast_cursor_plane_helper_funcs);
- ast_cursor_init(dev);
+ ast_cursor_init(ast);
ast_crtc_init(dev);
ast_encoder_init(dev);
ast_connector_init(dev);
@@ -1159,7 +1159,9 @@ int ast_mode_init(struct drm_device *dev)
void ast_mode_fini(struct drm_device *dev)
{
- ast_cursor_fini(dev);
+ struct ast_private *ast = dev->dev_private;
+
+ ast_cursor_fini(ast);
}
static int get_clock(void *i2c_priv)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/14] drm/ast: Move cursor pageflip into helper
The new helper ast_cursor_page_flip() switches the cursor's front and
back BOs. This simplifies the cursor plane's update helper.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 20 +++-
drivers/gpu/drm/ast/ast_drv.h| 2 +-
drivers/gpu/drm/ast/ast_mode.c | 12 +---
3 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 7474baddf048..815d95b2f392 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -198,7 +198,7 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
return ret;
}
-void ast_cursor_set_base(struct ast_private *ast, u64 address)
+static void ast_cursor_set_base(struct ast_private *ast, u64 address)
{
u8 addr0 = (address >> 3) & 0xff;
u8 addr1 = (address >> 11) & 0xff;
@@ -209,6 +209,24 @@ void ast_cursor_set_base(struct ast_private *ast, u64
address)
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xca, addr2);
}
+void ast_cursor_page_flip(struct ast_private *ast)
+{
+ struct drm_device *dev = ast->dev;
+ struct drm_gem_vram_object *gbo;
+ s64 off;
+
+ gbo = ast->cursor.gbo[ast->cursor.next_index];
+
+ off = drm_gem_vram_offset(gbo);
+ if (drm_WARN_ON_ONCE(dev, off < 0))
+ return; /* Bug: we didn't pin the cursor HW BO to VRAM. */
+
+ ast_cursor_set_base(ast, off);
+
+ ++ast->cursor.next_index;
+ ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
+}
+
int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
{
struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9bc1bb76ec91..e973c1ab96cb 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -319,7 +319,7 @@ void ast_release_firmware(struct drm_device *dev);
int ast_cursor_init(struct ast_private *ast);
void ast_cursor_fini(struct ast_private *ast);
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
-void ast_cursor_set_base(struct ast_private *ast, u64 address);
+void ast_cursor_page_flip(struct ast_private *ast);
int ast_cursor_move(struct drm_crtc *crtc, int x, int y);
#endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 8d5ba28c25d7..90a4050ef1c4 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -660,14 +660,11 @@ static void
ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
- struct drm_device *dev = plane->dev;
struct drm_plane_state *state = plane->state;
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = to_ast_private(plane->dev);
struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
- struct drm_gem_vram_object *gbo;
- s64 off;
u8 jreg;
ast_crtc->offset_x = AST_MAX_HWC_WIDTH - fb->width;
@@ -675,14 +672,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
- gbo = ast->cursor.gbo[ast->cursor.next_index];
- off = drm_gem_vram_offset(gbo);
- if (drm_WARN_ON_ONCE(dev, off < 0))
- return; /* Bug: we didn't pin cursor HW BO to VRAM. */
- ast_cursor_set_base(ast, off);
-
- ++ast->cursor.next_index;
- ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
+ ast_cursor_page_flip(ast);
}
ast_cursor_move(crtc, state->crtc_x, state->crtc_y);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
