[PATCH v2] drm/sched: Avoid infinite waits in the drm_sched_entity_destroy() path
If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. v2: - Add Steven's R-b Signed-off-by: Boris Brezillon Reviewed-by: Steven Price --- This is something I noticed while debugging another issue on panfrost causing the scheduler to be in a weird state where new entities were no longer scheduled. This was causing all userspace threads trying to close their DRM fd to be blocked in kernel space waiting for this "entity is idle" event. I don't know if that fix is legitimate (now that we fixed the other bug we don't seem to end up in that state anymore), but I thought I'd share it anyway. --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 146380118962..f8ec277a6aa8 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -73,6 +73,9 @@ int drm_sched_entity_init(struct drm_sched_entity *entity, init_completion(&entity->entity_idle); + /* We start in an idle state. */ + complete(&entity->entity_idle); + spin_lock_init(&entity->rq_lock); spsc_queue_init(&entity->job_queue); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 0/1] drm/ttm: Allocate transparent huge pages without clearing __GFP_COMP
Hi Alex,
adding Daniel as well.
Am 01.10.20 um 20:45 schrieb Alex Goins:
Hi Christian,
On Thu, 1 Oct 2020, Christian König wrote:
Hi Alex,
first of all accessing the underlying page of an exported DMA-buf is
illegal! So I'm not 100% sure what you're intentions are here, please
explain further.
We have some mapping requirements that I was hoping I could address by mapping
these pages manually.
Are you sure that it's illegal to access the underlying pages of an exported
DMA-BUF?
yes, I'm 100% sure of that. This was discussed multiple times now on the
mailing list.
There appears to be quite a few usages of this already. See the usage
of drm_prime_sg_to_page_addr_arrays() in vgem, vkms, msm, xen, and etnaviv.
drm_gem_prime_import_dev() uses driver->gem_prime_import_sg_table() when
importing a DMA-BUF from another driver, and the listed drivers then extract the
pages from the given SGT using drm_prime_sg_to_page_addr_arrays(). These pages
can then be mapped and faulted in.
No, exactly that doesn't work correctly.
You are corrupting internal state in struct page while doing so and risk
that userspace is accessing freed up memory.
We really need to find a way to fix the few drivers already doing this.
See commit af33a9190d02 ('drm/vgem: Enable dmabuf import interfaces'). After
importing the pages from the SGT, vgem can fault them in, taking a refcount with
get_page() first. get_page() throws a BUG if the refcount is zero, which it will
hit on each of the 'tail' pages from TTM THP allocations.
All of this currently works fine with TTM DMA-BUFs when the kernel is built with
!CONFIG_TRANSPARENT_HUGEPAGE. However, 'echo never >
/sys/kernel/mm/transparent_hugepage/enabled' doesn't change how TTM allocates
pages.
You need to redirect the mapping to dma_buf_mmap() instead.
Regards,
Christian.
Then the reason for TTM not using compound pages is that we can't
guarantee that they are mapped as a whole to userspace.
The result is that the kernel sometimes tried to de-compound them which
created a bunch of problems.
So yes this is completely intentional.
Understood, I figured something like that was the case, so I wanted to get your
input first. Do you know what the problems were, exactly? Practical issues
aside, it seems strange to call something a transparent huge page if it's
non-compound.
Besides making these pages compound, would it be reasonable to split them before
sharing them, in e.g. amdgpu_dma_buf_map (and in other drivers that use TTM)?
That's where it's supposed to make sure that the shared DMA-BUF is accessible by
the target device.
Thanks,
Alex
Regards,
Christian.
Am 01.10.20 um 00:18 schrieb Alex Goins:
Hi Christian,
I've been looking into the DMA-BUFs exported from AMDGPU / TTM. Would
you mind giving some input on this?
I noticed that your changes implementing transparent huge page support
in TTM are allocating them as non-compound. I understand that using
multiorder non-compound pages is common in device drivers, but I think
this can cause a problem when these pages are exported to other drivers.
It's possible for other drivers to access the DMA-BUF's pages via
gem_prime_import_sg_table(), but without context from TTM, it's
impossible for the importing driver to make sense of them; they simply
appear as individual pages, with only the first page having a non-zero
refcount. Making TTM's THP allocations compound puts them more in line
with the standard definition of a THP, and allows DMA-BUF-importing
drivers to make sense of the pages within.
I would like to propose making these allocations compound, but based on
patch history, it looks like the decision to make them non-compound was
intentional, as there were difficulties figuring out how to map them
into CPU page tables. I did some cursory testing with compound THPs, and
nothing seems obviously broken. I was also able to map compound THP
DMA-BUFs into userspace without issue, and access their contents. Are
you aware of any other potential consequences?
Commit 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages") should
probably also be reverted if this is applied.
Thanks,
Alex
Alex Goins (1):
drm-ttm: Allocate compound transparent huge pages
drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 14/14] drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: warning: no previous prototype for function 'lspcon_init'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-randconfig-a003-20201001 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
bcd05599d0e53977a963799d6ee4f6e0bc21331b)
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 remote add drm-intel git://anongit.freedesktop.org/drm-intel
git fetch --no-tags drm-intel drm-intel-next-queued
git checkout f542d671ffcec772a561cd41c7e2394392d9dafb
# 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/i915/display/intel_lspcon.c:533:6: warning: no previous
>> prototype for function 'lspcon_init' [-Wmissing-prototypes]
bool lspcon_init(struct intel_digital_port *dig_port)
^
drivers/gpu/drm/i915/display/intel_lspcon.c:533:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
bool lspcon_init(struct intel_digital_port *dig_port)
^
static
1 warning generated.
vim +/lspcon_init +533 drivers/gpu/drm/i915/display/intel_lspcon.c
357c0ae9198ad7f drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-11-21 532
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 @533 bool lspcon_init(struct intel_digital_port *dig_port)
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 534 {
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 535 struct intel_dp *dp = &dig_port->dp;
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 536 struct intel_lspcon *lspcon = &dig_port->lspcon;
668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 537 struct drm_connector *connector =
&dp->attached_connector->base;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 538
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 539 lspcon->active = false;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 540 lspcon->mode = DRM_LSPCON_MODE_INVALID;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 541
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 542 if (!lspcon_probe(lspcon)) {
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 543 DRM_ERROR("Failed to probe lspcon\n");
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 544 return false;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 545 }
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 546
b9936121d95b012 drivers/gpu/drm/i915/display/intel_lspcon.c Lyude Paul
2020-08-26 547 if (drm_dp_read_dpcd_caps(&dp->aux, dp->dpcd) != 0) {
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 548 DRM_ERROR("LSPCON DPCD read failed\n");
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 549 return false;
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 550 }
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 551
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 552 if (!lspcon_detect_vendor(lspcon)) {
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 553 DRM_ERROR("LSPCON vendor detection failed\n");
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 554 return false;
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 555 }
12a47a422862214 drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 556
668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 557 connector->ycbcr_420_allowed = true;
96e35598cead98d drivers/gpu/drm/i915/intel_ls
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
between commit:
b19515253623 ("drm/amd/pm: setup APU dpm clock table in SMU HW
initialization")
from the Linus tree and commits:
82cac71c1b64 ("drm/amd/pm: put Navi1X umc cdr workaround in post_smu_init")
236b156f7388 ("drm/amd/pm: apply no power source workaround if dc reported by
gpio")
1653a179c822 ("drm/amd/pm: move NAVI1X power mode switching workaround to
post_init")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 8dc5abb6931e,5c4b74f964fc..
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@@ -955,35 -1013,6 +1002,17 @@@ static int smu_smc_hw_setup(struct smu_
return ret;
}
- ret = smu_disable_umc_cdr_12gbps_workaround(smu);
- if (ret) {
- dev_err(adev->dev, "Workaround failed to disable UMC CDR
feature on 12Gbps SKU!\n");
- return ret;
- }
-
- /*
-* For Navi1X, manually switch it to AC mode as PMFW
-* may boot it with DC mode.
-*/
- ret = smu_set_power_source(smu,
- adev->pm.ac_power ? SMU_POWER_SOURCE_AC :
- SMU_POWER_SOURCE_DC);
- if (ret) {
- dev_err(adev->dev, "Failed to switch to %s mode!\n",
adev->pm.ac_power ? "AC" : "DC");
- return ret;
- }
-
+ /*
+ * Set initialized values (get from vbios) to dpm tables context such as
+ * gfxclk, memclk, dcefclk, and etc. And enable the DPM feature for each
+ * type of clks.
+ */
+ ret = smu_set_default_dpm_table(smu);
+ if (ret) {
+ dev_err(adev->dev, "Failed to setup default dpm clock
tables!\n");
+ return ret;
+ }
+
ret = smu_notify_display_change(smu);
if (ret)
return ret;
pgpSuB_Jf6zSR.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm: add support for taking drm atomic state snapshot
Add support to capture the drm atomic state snapshot which
can then be wired up with the devcoredump of the relevant display
errors to give useful information to debug the issues.
Since the devcoredump is read by usermode and it is allowed
upto 5 minutes to read the coredump, capturing the snapshot that
time will not result in an accurate result.
Rather we should capture the snapshot right after the error
happened. Hence add support for capturing this snapshot by
re-using the drm_atomic_helper_duplicate_state() API to support
a non-context version.
Also add nolock versions of the drm_atomic_get_***_state() APIs
which can be used to get snapshot of the drm atomic state of
display drivers.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_atomic.c| 154 ++--
drivers/gpu/drm/drm_atomic_helper.c | 28 -
include/drm/drm_atomic.h| 10 ++
include/drm/drm_atomic_helper.h | 2 +
4 files changed, 136 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9ccfbf213d72..4e805157100b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -272,37 +272,23 @@ void __drm_atomic_state_free(struct kref *ref)
}
EXPORT_SYMBOL(__drm_atomic_state_free);
-/**
- * drm_atomic_get_crtc_state - get CRTC state
- * @state: global atomic state object
- * @crtc: CRTC to get state object for
- *
- * This function returns the CRTC state for the given CRTC, allocating it if
- * needed. It will also grab the relevant CRTC lock to make sure that the state
- * is consistent.
- *
- * Returns:
- *
- * Either the allocated state or the error code encoded into the pointer. When
- * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
- * entire atomic sequence must be restarted. All other errors are fatal.
- */
-struct drm_crtc_state *
-drm_atomic_get_crtc_state(struct drm_atomic_state *state,
- struct drm_crtc *crtc)
+static struct drm_crtc_state *
+__drm_atomic_get_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc, bool take_lock)
{
int ret, index = drm_crtc_index(crtc);
struct drm_crtc_state *crtc_state;
- WARN_ON(!state->acquire_ctx);
-
crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
if (crtc_state)
return crtc_state;
- ret = drm_modeset_lock(&crtc->mutex, state->acquire_ctx);
- if (ret)
- return ERR_PTR(ret);
+ if (take_lock) {
+ WARN_ON(!state->acquire_ctx);
+ ret = drm_modeset_lock(&crtc->mutex, state->acquire_ctx);
+ if (ret)
+ return ERR_PTR(ret);
+ }
crtc_state = crtc->funcs->atomic_duplicate_state(crtc);
if (!crtc_state)
@@ -319,8 +305,37 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
return crtc_state;
}
+
+/**
+ * drm_atomic_get_crtc_state - get CRTC state
+ * @state: global atomic state object
+ * @crtc: CRTC to get state object for
+ *
+ * This function returns the CRTC state for the given CRTC, allocating it if
+ * needed. It will also grab the relevant CRTC lock to make sure that the state
+ * is consistent.
+ *
+ * Returns:
+ *
+ * Either the allocated state or the error code encoded into the pointer. When
+ * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
+ * entire atomic sequence must be restarted. All other errors are fatal.
+ */
+struct drm_crtc_state *
+drm_atomic_get_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ return __drm_atomic_get_crtc_state(state, crtc, true);
+}
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
+struct drm_crtc_state *
+drm_atomic_get_crtc_state_nl(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ return __drm_atomic_get_crtc_state(state, crtc, false);
+}
+
static int drm_atomic_crtc_check(const struct drm_crtc_state *old_crtc_state,
const struct drm_crtc_state *new_crtc_state)
{
@@ -445,30 +460,13 @@ static int drm_atomic_connector_check(struct
drm_connector *connector,
return 0;
}
-/**
- * drm_atomic_get_plane_state - get plane state
- * @state: global atomic state object
- * @plane: plane to get state object for
- *
- * This function returns the plane state for the given plane, allocating it if
- * needed. It will also grab the relevant plane lock to make sure that the
state
- * is consistent.
- *
- * Returns:
- *
- * Either the allocated state or the error code encoded into the pointer. When
- * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
- * entire atomic sequence must be restarted. All other errors are fatal.
- */
-struct drm_plane_state *
-drm_atomic_get_plane_state(struct drm_atomic_state *state,
- struct drm_plane *plane)
+static struct drm_plane_
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #6 from Robert M. Muncrief (rmuncr...@humanavance.com) --- Created attachment 292755 --> https://bugzilla.kernel.org/attachment.cgi?id=292755&action=edit Full Xorg resume fail output for kernel 5.8.12 Here is the Xorg.0.log log output for the resume fail. -- 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
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #5 from Robert M. Muncrief (rmuncr...@humanavance.com) --- Created attachment 292753 --> https://bugzilla.kernel.org/attachment.cgi?id=292753&action=edit Full dmesg resume fail output for kernel 5.8.12 I suspended my computer during dinner and when I tried to resume it failed. I've attached the full dmesg output to this message. The full Xorg log will follow. -- 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 1/3] drm/msm: add MSM_BO_CACHED_COHERENT
On Wed, Sep 30, 2020 at 08:27:04PM -0400, Jonathan Marek wrote:
> Add a new cache mode for creating coherent host-cached BOs.
Reviewed-by: Jordan Crouse
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> drivers/gpu/drm/msm/msm_gem.c | 8
> include/uapi/drm/msm_drm.h | 5 ++---
> 4 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 9eeb46bf2a5d..2aa707546254 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -410,6 +410,7 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> config.rev.minor, config.rev.patchid);
>
> priv->is_a2xx = config.rev.core == 2;
> + priv->has_cached_coherent = config.rev.core >= 6;
>
> gpu = info->init(drm);
> if (IS_ERR(gpu)) {
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 2c3225bc1794..6384844b1696 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -167,6 +167,7 @@ struct msm_drm_private {
> struct msm_file_private *lastctx;
> /* gpu is only set on open(), but we need this info earlier */
> bool is_a2xx;
> + bool has_cached_coherent;
>
> struct drm_fb_helper *fbdev;
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index b2f49152b4d4..ad9a627493ae 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -431,6 +431,9 @@ static int msm_gem_pin_iova(struct drm_gem_object *obj,
> if (msm_obj->flags & MSM_BO_MAP_PRIV)
> prot |= IOMMU_PRIV;
>
> + if (msm_obj->flags & MSM_BO_CACHED_COHERENT)
> + prot |= IOMMU_CACHE;
> +
> WARN_ON(!mutex_is_locked(&msm_obj->lock));
>
> if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
> @@ -998,6 +1001,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
> uint32_t size, uint32_t flags,
> struct drm_gem_object **obj)
> {
> + struct msm_drm_private *priv = dev->dev_private;
> struct msm_gem_object *msm_obj;
>
> switch (flags & MSM_BO_CACHE_MASK) {
> @@ -1005,6 +1009,10 @@ static int msm_gem_new_impl(struct drm_device *dev,
> case MSM_BO_CACHED:
> case MSM_BO_WC:
> break;
> + case MSM_BO_CACHED_COHERENT:
> + if (priv->has_cached_coherent)
> + break;
> + /* fallthrough */
It confused me that this kind of implicitly fell into the else clause in
msm_gem_mmap_obj, but I'm on board. This is a good solution since it only allows
I/O coherence with caching.
> default:
> DRM_DEV_ERROR(dev->dev, "invalid cache flag: %x\n",
> (flags & MSM_BO_CACHE_MASK));
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index a6c1f3eb2623..474497e8743a 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -94,12 +94,11 @@ struct drm_msm_param {
> #define MSM_BO_CACHED0x0001
> #define MSM_BO_WC0x0002
> #define MSM_BO_UNCACHED 0x0004
> +#define MSM_BO_CACHED_COHERENT 0x08
>
> #define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
>MSM_BO_GPU_READONLY | \
> - MSM_BO_CACHED | \
> - MSM_BO_WC | \
> - MSM_BO_UNCACHED)
> + MSM_BO_CACHE_MASK)
>
> struct drm_msm_gem_new {
> __u64 size; /* in */
> --
> 2.26.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Wed, Sep 30, 2020 at 08:27:05PM -0400, Jonathan Marek wrote:
> This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
> which otherwise doesn't provide any method for cleaning/invalidating the
> cache to sync with the device.
>
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/msm_drv.c | 21 +
> drivers/gpu/drm/msm/msm_drv.h | 2 ++
> drivers/gpu/drm/msm/msm_gem.c | 15 +++
> include/uapi/drm/msm_drm.h| 20
> 4 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9716210495fc..305db1db1064 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -964,6 +964,26 @@ static int msm_ioctl_submitqueue_close(struct drm_device
> *dev, void *data,
> return msm_submitqueue_remove(file->driver_priv, id);
> }
>
> +static int msm_ioctl_gem_sync_cache(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_msm_gem_sync_cache *args = data;
> + struct drm_gem_object *obj;
> +
> + if (args->flags & ~MSM_GEM_SYNC_CACHE_FLAGS)
> + return -EINVAL;
> +
> + obj = drm_gem_object_lookup(file, args->handle);
> + if (!obj)
> + return -ENOENT;
> +
> + msm_gem_sync_cache(obj, args->flags, args->offset, args->end);
> +
> + drm_gem_object_put(obj);
> +
> + return 0;
> +}
> +
> static const struct drm_ioctl_desc msm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new,
> DRM_RENDER_ALLOW),
> @@ -976,6 +996,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(MSM_GEM_SYNC_CACHE,msm_ioctl_gem_sync_cache,
> DRM_RENDER_ALLOW),
> };
>
> static const struct vm_operations_struct vm_ops = {
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 6384844b1696..5e932dae453f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -314,6 +314,8 @@ void msm_gem_move_to_active(struct drm_gem_object *obj,
> void msm_gem_move_to_inactive(struct drm_gem_object *obj);
> int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
> *timeout);
> int msm_gem_cpu_fini(struct drm_gem_object *obj);
> +void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
> + size_t range_start, size_t range_end);
> void msm_gem_free_object(struct drm_gem_object *obj);
> int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
> uint32_t size, uint32_t flags, uint32_t *handle, char *name);
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index ad9a627493ae..93da88b3fc50 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -808,6 +809,20 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj)
> return 0;
> }
>
> +void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
> + size_t range_start, size_t range_end)
> +{
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> +
> + /* TODO: sync only the required range, and don't invalidate on clean */
> +
> + if (flags & MSM_GEM_SYNC_CACHE_CLEAN)
Curious why you would rename these - I feel like the to_device / to_cpu model is
pretty well baked into our thought process. I know from personal experience that
I have to stop and think to remember which direction is which.
Jordan
> + sync_for_device(msm_obj);
> +
> + if (flags & MSM_GEM_SYNC_CACHE_INVALIDATE)
> + sync_for_cpu(msm_obj);
> +}
> +
> #ifdef CONFIG_DEBUG_FS
> static void describe_fence(struct dma_fence *fence, const char *type,
> struct seq_file *m)
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index 474497e8743a..1dfafa71fc94 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -319,6 +319,24 @@ struct drm_msm_submitqueue_query {
> __u32 pad;
> };
>
> +/*
> + * Host cache maintenance (relevant for MSM_BO_CACHED)
> + * driver may both clean/invalidate (flush) for clean
> + */
> +
> +#define MSM_GEM_SYNC_CACHE_CLEAN 0x1
> +#define MSM_GEM_SYNC_CACHE_INVALIDATE0x2
> +
> +#define MSM_GEM_SYNC_CACHE_FLAGS (MSM_GEM_SYNC_CACHE_CLEAN | \
> + MSM_GEM_SYNC_CACHE_INVALIDATE)
> +
> +struct drm_msm_gem_sync_cache {
> + __u32 handle;
> + __u32 flags;
> +
[drm-intel:drm-intel-next-queued 14/14] drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: warning: no previous prototype for 'lspcon_init'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-rhel (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git fetch --no-tags drm-intel drm-intel-next-queued
git checkout f542d671ffcec772a561cd41c7e2394392d9dafb
# save the attached .config to linux build tree
make W=1 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/i915/display/intel_lspcon.c:533:6: warning: no previous
>> prototype for 'lspcon_init' [-Wmissing-prototypes]
533 | bool lspcon_init(struct intel_digital_port *dig_port)
| ^~~
vim +/lspcon_init +533 drivers/gpu/drm/i915/display/intel_lspcon.c
357c0ae9198ad7f drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-11-21 532
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 @533 bool lspcon_init(struct intel_digital_port *dig_port)
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 534 {
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 535 struct intel_dp *dp = &dig_port->dp;
7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi
2020-06-30 536 struct intel_lspcon *lspcon = &dig_port->lspcon;
668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 537 struct drm_connector *connector =
&dp->attached_connector->base;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 538
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 539 lspcon->active = false;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 540 lspcon->mode = DRM_LSPCON_MODE_INVALID;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 541
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 542 if (!lspcon_probe(lspcon)) {
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 543 DRM_ERROR("Failed to probe lspcon\n");
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 544 return false;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 545 }
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 546
b9936121d95b012 drivers/gpu/drm/i915/display/intel_lspcon.c Lyude Paul
2020-08-26 547 if (drm_dp_read_dpcd_caps(&dp->aux, dp->dpcd) != 0) {
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 548 DRM_ERROR("LSPCON DPCD read failed\n");
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 549 return false;
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 550 }
24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 551
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 552 if (!lspcon_detect_vendor(lspcon)) {
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 553 DRM_ERROR("LSPCON vendor detection failed\n");
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 554 return false;
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 555 }
12a47a422862214 drivers/gpu/drm/i915/intel_lspcon.c Imre Deak
2016-10-24 556
668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 557 connector->ycbcr_420_allowed = true;
96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2018-10-12 558 lspcon->active = true;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 559 DRM_DEBUG_KMS("Success: LSPCON init\n");
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 560 return true;
dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma
2016-10-14 561 }
f542d671ffcec77 drivers/gpu/drm/i915/display/intel_lspcon.c Kai-Heng Feng
2020-06-10 562
:: The code at line 533 was first introduced by commit
:: 7801f3b792b0fd171b02f2cb974e758295e68e0f drm/i915/display: prefer
dig_port to reference intel_digital_port
:: TO: Lucas De Marchi
:: CC: Lucas De Marchi
Re: [RFC][PATCH 5/6] dma-buf: system_heap: Add pagepool support to system heap
On Tue, Sep 29, 2020 at 9:46 PM Chris Goldsworthy
wrote:
>
> On 2020-09-25 21:24, John Stultz wrote:
> > Reuse/abuse the pagepool code from the network code to speed
> > up allocation performance.
> >
> > This is similar to the ION pagepool usage, but tries to
> > utilize generic code instead of a custom implementation.
> >
> > Cc: Sumit Semwal
> > Cc: Liam Mark
> > Cc: Laura Abbott
> > Cc: Brian Starkey
> > Cc: Hridya Valsaraju
> > Cc: Suren Baghdasaryan
> > Cc: Sandeep Patil
> > Cc: Ørjan Eide
> > Cc: Robin Murphy
> > Cc: Ezequiel Garcia
> > Cc: Simon Ser
> > Cc: James Jones
> > Cc: linux-me...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: John Stultz
> > ---
> > drivers/dma-buf/heaps/Kconfig | 1 +
> > drivers/dma-buf/heaps/system_heap.c | 32 +
> > 2 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma-buf/heaps/Kconfig
> > b/drivers/dma-buf/heaps/Kconfig
> > index a5eef06c4226..f13cde4321b1 100644
> > --- a/drivers/dma-buf/heaps/Kconfig
> > +++ b/drivers/dma-buf/heaps/Kconfig
> > @@ -1,6 +1,7 @@
> > config DMABUF_HEAPS_SYSTEM
> > bool "DMA-BUF System Heap"
> > depends on DMABUF_HEAPS
> > + select PAGE_POOL
> > help
> > Choose this option to enable the system dmabuf heap. The system
> > heap
> > is backed by pages from the buddy allocator. If in doubt, say Y.
> > diff --git a/drivers/dma-buf/heaps/system_heap.c
> > b/drivers/dma-buf/heaps/system_heap.c
> > index 882a632e9bb7..9f57b4c8ae69 100644
> > --- a/drivers/dma-buf/heaps/system_heap.c
> > +++ b/drivers/dma-buf/heaps/system_heap.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > struct dma_heap *sys_heap;
> >
> > @@ -46,6 +47,7 @@ struct dma_heap_attachment {
> > static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP,
> > LOW_ORDER_GFP};
> > static const unsigned int orders[] = {8, 4, 0};
> > #define NUM_ORDERS ARRAY_SIZE(orders)
> > +struct page_pool *pools[NUM_ORDERS];
> >
> > static struct sg_table *dup_sg_table(struct sg_table *table)
> > {
> > @@ -264,13 +266,17 @@ static void system_heap_dma_buf_release(struct
> > dma_buf *dmabuf)
> > struct system_heap_buffer *buffer = dmabuf->priv;
> > struct sg_table *table;
> > struct scatterlist *sg;
> > - int i;
> > + int i, j;
> >
> > table = &buffer->sg_table;
> > for_each_sg(table->sgl, sg, table->nents, i) {
> > struct page *page = sg_page(sg);
> >
> > - __free_pages(page, compound_order(page));
> > + for (j = 0; j < NUM_ORDERS; j++) {
> > + if (compound_order(page) == orders[j])
> > + break;
> > + }
> > + page_pool_put_full_page(pools[j], page, false);
> > }
> > sg_free_table(table);
> > kfree(buffer);
> > @@ -300,8 +306,7 @@ static struct page
> > *alloc_largest_available(unsigned long size,
> > continue;
> > if (max_order < orders[i])
> > continue;
> > -
> > - page = alloc_pages(order_flags[i], orders[i]);
> > + page = page_pool_alloc_pages(pools[i], order_flags[i]);
> > if (!page)
> > continue;
> > return page;
> > @@ -406,6 +411,25 @@ static const struct dma_heap_ops system_heap_ops =
> > {
> > static int system_heap_create(void)
> > {
> > struct dma_heap_export_info exp_info;
> > + int i;
> > +
> > + for (i = 0; i < NUM_ORDERS; i++) {
> > + struct page_pool_params pp;
> > +
> > + memset(&pp, 0, sizeof(pp));
> > + pp.order = orders[i];
> > + pp.dma_dir = DMA_BIDIRECTIONAL;
> > + pools[i] = page_pool_create(&pp);
> > +
> > + if (IS_ERR(pools[i])) {
> > + int j;
> > +
> > + pr_err("%s: page pool creation failed!\n", __func__);
> > + for (j = 0; j < i; j++)
> > + page_pool_destroy(pools[j]);
> > + return PTR_ERR(pools[i]);
> > + }
> > + }
> >
> > exp_info.name = "system";
> > exp_info.ops = &system_heap_ops;
>
> This is cool, I didn't know about this pooling code under /net/core.
> Nice and compact.
Oh, bummer. I just realized when allocating w/ __GFP_ZERO from the
page-pool, the logic doesn't actually clear pages when pulling from
the cache.
So unfortunately this is what accounts for much of the performance
benefit I was seeing with this approach, so I'll have to retract my
claim on the performance gain with this. :(
I've got a first pass at zeroing the pages we put into the pool, but
the numbers are not so great just yet so I've got some further work to
do.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
[PATCH v3 0/2] drm/i915/jsl: Update JSL Voltage swing table
Patch series covers following thigns: 1. Split and differentiate between EHL and JSL platfrom 2. Update voltage swing table for eDP on JSL platform Changes since V2 : - Added IS_EHL_JSL to replace IS_ELKHARTLAKE - EHL/JSL PCI ids split added - Rebased to drm master commit Changes since V1 : - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively - Reverted EHL/JSL PCI ids split change Tejas Upadhyay (2): drm/i915/jsl: Split EHL/JSL platform info and PCI ids drm/i915/edp/jsl: Update vswing table for HBR and HBR2 drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 4 +- .../gpu/drm/i915/display/intel_combo_phy.c| 6 +- drivers/gpu/drm/i915/display/intel_ddi.c | 95 +-- drivers/gpu/drm/i915/display/intel_display.c | 8 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_pci.c | 9 ++ drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_pch.c | 6 +- include/drm/i915_pciids.h | 9 +- 15 files changed, 134 insertions(+), 36 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
- Changes rebased as per new drm top commit
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/intel_ddi.c | 95 ++--
1 file changed, 89 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b4c520348b3b..6c67232247ec 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans jsl_combo_phy_ddi_translations_edp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[] = {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1167,6 +1195,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
}
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (crtc_state->port_clock > 27) {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
+ return jsl_combo_phy_ddi_translations_edp_hbr;
+ }
+ }
+
+ return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ return jsl_get_combo_buf_trans_hdmi(encoder, crtc_state,
n
[PATCH v3 1/2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 5 +++--
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 6 +++---
include/drm/i915_pciids.h | 9 ++---
14 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index fe946a2e2082..fee23ac14edd 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_EHL_JSL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_EHL_JSL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..2f39a4dc72f9 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_EHL_JSL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_EHL_JSL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 157d8c8c605a..acc7b0098026 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_EHL_JSL(i915) ||
IS_ROCKETLAKE(i915))
return phy < PHY_C;
@@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_EHL_JSL(dev_priv)) {
if (ehl_vbt_ddi_d_present(dev_priv))
expected_val = ICL_PHY_MISC_MUX_DDID;
@@ -376,7 +376,7 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
* "internal" child devices.
*/
val = intel_de_read(dev_priv, ICL_
[Bug 209417] kernel-5.8*, amdgpu - Blank screen shortly after boot, "fixed" with suspend and wake up
https://bugzilla.kernel.org/show_bug.cgi?id=209417 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Please change the component to Video(DRI - Intel) -- 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
[Bug 209417] kernel-5.8*, amdgpu - Blank screen shortly after boot, "fixed" with suspend and wake up
https://bugzilla.kernel.org/show_bug.cgi?id=209417 Juan (juantxor...@gmail.com) changed: What|Removed |Added CC||juantxor...@gmail.com --- Comment #5 from Juan (juantxor...@gmail.com) --- Created attachment 292745 --> https://bugzilla.kernel.org/attachment.cgi?id=292745&action=edit bad-commit I finally get to do the bisect. I attach the result of the guilty commit. I wrongly assumed that it was a problem of amdgpu, but apparently is related to the intel i915 drivers. I guess I should move this bug to the proper place. -- 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
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #4 from Robert M. Muncrief (rmuncr...@humanavance.com) --- You are correct, the restored 5.8.5 dmesg output doesn't have the full output either, and it's the only other output I can find in my backups. I apologize for my error. Unfortunately I can't remove my VFIO setup for any extended period of time because I'm working on a project with other musicians that demands I use my Windows 10 VM daily for software that has no Linux alternative. There is other almost-equivalent software that could have been used (which I actually prefer) but the other musicians aren't willing to switch to Linux. In their defense they did all try quite awhile ago, but it was just to difficult for them, and their frustration ended up causing anger and contention among our group. In any case here's my VFIO passthrough setup: /etc/default/grub boot command line: GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 video=efifb:off audit=0 acpi_enforce_resources=lax rd.modules-load=vfio-pci amd_iommu=on iommu= pt" /etc/modprobe.d/kvm.conf: options kvm_amd avic=1 /etc/modprobe.d/vfio.conf: options vfio-pci disable_vga=1 softdep amdgpu pre: vfio-pci softdep radeon pre: vfio-pci softdep ahci pre: vfio-pci softdep xhci_pci pre: vfio-pci install vfio-pci /usr/local/bin/vfio-pci-override.sh /usr/local/bin/vfio-pci-override.sh ``` #!/bin/sh DEVS=":0b:00.0 :0b:00.1" if [ ! -z "$(ls -A /sys/class/iommu)" ]; then for DEV in $DEVS; do echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override done fi modprobe -i vfio-pci ``` -- 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
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- Looks like you attached the wrong file? Can you elaborate on how you use your GPUs? If you take vfio out of the picture, do you still have the issues? -- 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 RFC 0/1] drm/ttm: Allocate transparent huge pages without clearing __GFP_COMP
Hi Christian,
On Thu, 1 Oct 2020, Christian König wrote:
> Hi Alex,
>
> first of all accessing the underlying page of an exported DMA-buf is
> illegal! So I'm not 100% sure what you're intentions are here, please
> explain further.
We have some mapping requirements that I was hoping I could address by mapping
these pages manually.
Are you sure that it's illegal to access the underlying pages of an exported
DMA-BUF? There appears to be quite a few usages of this already. See the usage
of drm_prime_sg_to_page_addr_arrays() in vgem, vkms, msm, xen, and etnaviv.
drm_gem_prime_import_dev() uses driver->gem_prime_import_sg_table() when
importing a DMA-BUF from another driver, and the listed drivers then extract the
pages from the given SGT using drm_prime_sg_to_page_addr_arrays(). These pages
can then be mapped and faulted in.
See commit af33a9190d02 ('drm/vgem: Enable dmabuf import interfaces'). After
importing the pages from the SGT, vgem can fault them in, taking a refcount with
get_page() first. get_page() throws a BUG if the refcount is zero, which it will
hit on each of the 'tail' pages from TTM THP allocations.
All of this currently works fine with TTM DMA-BUFs when the kernel is built with
!CONFIG_TRANSPARENT_HUGEPAGE. However, 'echo never >
/sys/kernel/mm/transparent_hugepage/enabled' doesn't change how TTM allocates
pages.
> Then the reason for TTM not using compound pages is that we can't
> guarantee that they are mapped as a whole to userspace.
>
> The result is that the kernel sometimes tried to de-compound them which
> created a bunch of problems.
>
> So yes this is completely intentional.
Understood, I figured something like that was the case, so I wanted to get your
input first. Do you know what the problems were, exactly? Practical issues
aside, it seems strange to call something a transparent huge page if it's
non-compound.
Besides making these pages compound, would it be reasonable to split them before
sharing them, in e.g. amdgpu_dma_buf_map (and in other drivers that use TTM)?
That's where it's supposed to make sure that the shared DMA-BUF is accessible by
the target device.
Thanks,
Alex
> Regards,
> Christian.
>
> Am 01.10.20 um 00:18 schrieb Alex Goins:
> > Hi Christian,
> >
> > I've been looking into the DMA-BUFs exported from AMDGPU / TTM. Would
> > you mind giving some input on this?
> >
> > I noticed that your changes implementing transparent huge page support
> > in TTM are allocating them as non-compound. I understand that using
> > multiorder non-compound pages is common in device drivers, but I think
> > this can cause a problem when these pages are exported to other drivers.
> >
> > It's possible for other drivers to access the DMA-BUF's pages via
> > gem_prime_import_sg_table(), but without context from TTM, it's
> > impossible for the importing driver to make sense of them; they simply
> > appear as individual pages, with only the first page having a non-zero
> > refcount. Making TTM's THP allocations compound puts them more in line
> > with the standard definition of a THP, and allows DMA-BUF-importing
> > drivers to make sense of the pages within.
> >
> > I would like to propose making these allocations compound, but based on
> > patch history, it looks like the decision to make them non-compound was
> > intentional, as there were difficulties figuring out how to map them
> > into CPU page tables. I did some cursory testing with compound THPs, and
> > nothing seems obviously broken. I was also able to map compound THP
> > DMA-BUFs into userspace without issue, and access their contents. Are
> > you aware of any other potential consequences?
> >
> > Commit 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages") should
> > probably also be reverted if this is applied.
> >
> > Thanks,
> > Alex
> >
> > Alex Goins (1):
> >drm-ttm: Allocate compound transparent huge pages
> >
> > drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
>
> ___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #2 from Robert M. Muncrief (rmuncr...@humanavance.com) --- Created attachment 292741 --> https://bugzilla.kernel.org/attachment.cgi?id=292741&action=edit Resume failure, full dmesg output from kernel 5.8.5 The last full dmesg output I have is from kernel 5.8.5, and I've attached it to this response. However the messages haven't changed since then. Going forward would you rather I run the current 5.8 (on arch it's 5.8.12) or the 5.9 RC release candidates (currently 5.9-rc6) to capture the next event? I can bisect, but don't know how to bisect a random issue like this. It's difficult to say how often it happens, but I'd estimate one out of seven to twelve times. I actually tried purposely going through multiple suspend/resume cycles sometime ago in hopes of gathering more info for a bug report, but got to 20 cycles with no errors so I gave up. So it seems the issue only occurs if my computer has been suspended for a significant period of time, as it only occurs when my computer has been suspended overnight. It's also significant to note that I have two identical XFX Radeon RX 580 GTS XXX Edition GPUs, and one is passed through via VFIO at boot. In any case I'll be happy to assist on this issue in any way I can. I've seen multiple complaints about it online, but saw other bug reports that I assumed were already addressing it or I would have filed a new bug report sooner. I wasn't aware of my error until this morning. -- 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: [RFC][PATCH 5/6] dma-buf: system_heap: Add pagepool support to system heap
On Thu, Oct 1, 2020 at 7:49 AM Chris Goldsworthy
wrote:
> On 2020-09-29 21:46, Chris Goldsworthy wrote:
> > On 2020-09-25 21:24, John Stultz wrote:
> >> Reuse/abuse the pagepool code from the network code to speed
> >> up allocation performance.
> >>
> >> This is similar to the ION pagepool usage, but tries to
> >> utilize generic code instead of a custom implementation.
> >>
> >> Cc: Sumit Semwal
> >> Cc: Liam Mark
> >> Cc: Laura Abbott
> >> Cc: Brian Starkey
> >> Cc: Hridya Valsaraju
> >> Cc: Suren Baghdasaryan
> >> Cc: Sandeep Patil
> >> Cc: Ørjan Eide
> >> Cc: Robin Murphy
> >> Cc: Ezequiel Garcia
> >> Cc: Simon Ser
> >> Cc: James Jones
> >> Cc: linux-me...@vger.kernel.org
> >> Cc: dri-devel@lists.freedesktop.org
> >> Signed-off-by: John Stultz
> >> ---
> >> drivers/dma-buf/heaps/Kconfig | 1 +
> >> drivers/dma-buf/heaps/system_heap.c | 32
> >> +
> >> 2 files changed, 29 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/heaps/Kconfig
> >> b/drivers/dma-buf/heaps/Kconfig
> >> index a5eef06c4226..f13cde4321b1 100644
> >> --- a/drivers/dma-buf/heaps/Kconfig
> >> +++ b/drivers/dma-buf/heaps/Kconfig
> >> @@ -1,6 +1,7 @@
> >> config DMABUF_HEAPS_SYSTEM
> >> bool "DMA-BUF System Heap"
> >> depends on DMABUF_HEAPS
> >> +select PAGE_POOL
> >> help
> >>Choose this option to enable the system dmabuf heap. The system
> >> heap
> >>is backed by pages from the buddy allocator. If in doubt, say Y.
> >> diff --git a/drivers/dma-buf/heaps/system_heap.c
> >> b/drivers/dma-buf/heaps/system_heap.c
> >> index 882a632e9bb7..9f57b4c8ae69 100644
> >> --- a/drivers/dma-buf/heaps/system_heap.c
> >> +++ b/drivers/dma-buf/heaps/system_heap.c
> >> @@ -20,6 +20,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> struct dma_heap *sys_heap;
> >>
> >> @@ -46,6 +47,7 @@ struct dma_heap_attachment {
> >> static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP,
> >> LOW_ORDER_GFP};
> >> static const unsigned int orders[] = {8, 4, 0};
> >> #define NUM_ORDERS ARRAY_SIZE(orders)
> >> +struct page_pool *pools[NUM_ORDERS];
> >>
> >> static struct sg_table *dup_sg_table(struct sg_table *table)
> >> {
> >> @@ -264,13 +266,17 @@ static void system_heap_dma_buf_release(struct
> >> dma_buf *dmabuf)
> >> struct system_heap_buffer *buffer = dmabuf->priv;
> >> struct sg_table *table;
> >> struct scatterlist *sg;
> >> -int i;
> >> +int i, j;
> >>
> >> table = &buffer->sg_table;
> >> for_each_sg(table->sgl, sg, table->nents, i) {
> >> struct page *page = sg_page(sg);
> >>
> >> -__free_pages(page, compound_order(page));
> >> +for (j = 0; j < NUM_ORDERS; j++) {
> >> +if (compound_order(page) == orders[j])
> >> +break;
> >> +}
> >> +page_pool_put_full_page(pools[j], page, false);
> >> }
> >> sg_free_table(table);
> >> kfree(buffer);
> >> @@ -300,8 +306,7 @@ static struct page
> >> *alloc_largest_available(unsigned long size,
> >> continue;
> >> if (max_order < orders[i])
> >> continue;
> >> -
> >> -page = alloc_pages(order_flags[i], orders[i]);
> >> +page = page_pool_alloc_pages(pools[i], order_flags[i]);
> >> if (!page)
> >> continue;
> >> return page;
> >> @@ -406,6 +411,25 @@ static const struct dma_heap_ops system_heap_ops
> >> = {
> >> static int system_heap_create(void)
> >> {
> >> struct dma_heap_export_info exp_info;
> >> +int i;
> >> +
> >> +for (i = 0; i < NUM_ORDERS; i++) {
> >> +struct page_pool_params pp;
> >> +
> >> +memset(&pp, 0, sizeof(pp));
> >> +pp.order = orders[i];
> >> +pp.dma_dir = DMA_BIDIRECTIONAL;
>
> Hey John,
>
> Correct me if I'm wrong, but I think that in order for pp.dma_dir to be
> used in either page_pool_alloc_pages() or page_pool_put_full_page(), we
> need to at least have PP_FLAG_DMA_MAP set (to have
> page_pool_dma_sync_for_device() called, PP_FLAG_DMA_SYNC_DEV should also
> be set I think). I think you'd also need to to have pp->dev set. Are
> we setting dma_dir with the intention of doing the necessary CMOs before
> we start using the page?
Looking, I think my setting of the dma_dir there on the pool is
unnecessary (and as you point out, it doesn't have much effect as long
as the PP_FLAG_DMA_MAP isn't set).
I'm really only using the pagepool as a page cache, and the dmabuf ops
are still used for mapping and syncing operations.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Nouveau wiki migration
On Thu, Oct 1, 2020 at 7:53 PM Sam Ravnborg wrote: > > Hi Karol. > > On Thu, Oct 01, 2020 at 01:36:52PM +0200, Karol Herbst wrote: > > On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote: > > > > > > Hi everybody, > > > > > > I think it's time to finally move our wiki from the old infrastructure > > > over to gitlab pages. > > > > > > This comes with several benefits: > > > * full control through git over the ikiwiki pipeline (setup files, > > > plugins, system packages, ...) > > > * random users are able to create MRs against the wiki as long as they > > > are willing to create a gitlab account. > > > * possible to migrate over to a different wiki generator or mix and > > > match or whatever. > > > * no CGI stuff on the wiki as we don't use ikiwiki for the git > > > operations anymore > > > > > > To view the migrate wiki visit this URL: > > > https://nouveau.pages.freedesktop.org/wiki/ > > I poked around a little - almost all of it looked good. > > The FAQ points back to some pages on https://nouveau.freedesktop.org - > like https://nouveau.freedesktop.org/wiki/XvMC/ > I guess this is a bug. > The migration includes using the old subdomain with gitlab pages and most of the links are auto-generated anyway, so this should just work after migration. I just have to prepare accordingly. > But in general looks good. > > > I did some further changes, like ensuring backwards compatibility to > > existing links and already started to clean up some bits, like > > removing the google translate stuff. > > > > Now I'd like to get the subdomain changed of the current wiki over to > > the gitlab stuff and wanted to ask for acks/nacks on this > > No ack/nack here - as I really do not know what to ack/nack. > But maybe the above counts like an ack??? > > But looks good and I hope that others find it simple to help > with the pages from the gitlab repo. > > Sam > ___ > 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 v7 2/4] drm/kmb: Add support for KeemBay Display
Hi Daniel,
I was finally able to test the driver with 5.9 kernel with minor changes in the
driver.
Ran the igt_vblank test and it passed/skipped all the subtests except the
pipe-A-accuracy-idle test.
Results are attached. Investigated the failing test and it seems like
drm_handle_vblank() is taking too long sometimes. I can work on this after we
merge.
Will send out V8 with the minor changes and device tree YAML binding file ASAP.
Will work on the rest of the review comments after.
Thanks,
Anitha
> From: Daniel Vetter
> Sent: Thursday, September 10, 2020 1:31 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel
> Subject: Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
>
> On Mon, Aug 31, 2020 at 01:02:50PM -0700, Anitha Chrisanthus wrote:
> > This is a basic KMS atomic modesetting display driver for KeemBay family
> of
> > SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> > driver at the connector level.
> >
> > Single CRTC with LCD controller->mipi DSI-> ADV bridge
> >
> > Only 1080p resolution and single plane is supported at this time.
> >
> > v2: moved extern to .h, removed license text
> > use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
> >
> > v3: Squashed all 59 commits to one
> >
> > v4: review changes from Sam Ravnborg
> > renamed dev_p to kmb
> > moved clocks under kmb_clock, consolidated clk initializations
> > use drmm functions
> > use DRM_GEM_CMA_DRIVER_OPS_VMAP
> >
> > v5: corrected spellings
> > v6: corrected checkpatch warnings
> > v7: review changes Sam Ravnborg and Thomas Zimmerman
> > removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
> > renamed mode_set, kmb_load, inlined unload (Thomas)
> > moved remaining logging to drm_*(Thomas)
> > re-orged driver initialization (Thomas)
> > moved plane_status to drm_private (Sam)
> > removed unnecessary logs and defines and ifdef codes (Sam)
> > call helper_check in plane_atomic_check (Sam)
> > renamed set to get for bpp and format functions(Sam)
> > use drm helper functions for reset, duplicate/destroy state instead
> > of kmb functions (Sam)
> > removed kmb_priv from kmb_plane and removed kmb_plane_state
> (Sam)
> >
> > Cc: Sam Ravnborg
> > Signed-off-by: Anitha Chrisanthus
> > Reviewed-by: Bob Paauwe
>
> Sam asked me to take a look at this too, looks reasonable overall. I've
> spotted a few small things plus a potential functional issue around
> vblank/event handling. I strongly recommend running the igt test suite
> over the driver to see whether it all works reasonably ok. See below for
> details.
>
> > ---
> > drivers/gpu/drm/kmb/kmb_crtc.c | 224 +
> > drivers/gpu/drm/kmb/kmb_drv.c | 676
>
> > drivers/gpu/drm/kmb/kmb_drv.h | 170 ++
> > drivers/gpu/drm/kmb/kmb_plane.c | 480
>
> > drivers/gpu/drm/kmb/kmb_plane.h | 110 +++
> > 5 files changed, 1660 insertions(+)
> > create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
> > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
> >
> > diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c
> b/drivers/gpu/drm/kmb/kmb_crtc.c
> > new file mode 100644
> > index 000..a684331
> > --- /dev/null
> > +++ b/drivers/gpu/drm/kmb/kmb_crtc.c
> > @@ -0,0 +1,224 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2018-2020 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "kmb_drv.h"
> > +#include "kmb_dsi.h"
> > +#include "kmb_plane.h"
> > +#include "kmb_regs.h"
> > +
> > +struct kmb_crtc_timing {
> > + u32 vfront_porch;
> > + u32 vback_porch;
> > + u32 vsync_len;
> > + u32 hfront_porch;
> > + u32 hback_porch;
> > + u32 hsync_len;
> > +};
> > +
> > +static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > + struct kmb_drm_private *kmb = to_kmb(dev);
> > +
> > + /* Clear interrupt */
> > + kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
> > + /* Set which interval to generate vertical interrupt */
> > + kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
> > + LCD_VSTATUS_COMPARE_VSYNC);
> > + /* Enable vertical interrupt */
> > + kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
> > + LCD_INT_VERT_COMP);
> > + return 0;
> > +}
> > +
> > +static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > + struct kmb_drm_private
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output from boot. Can you bisect? -- 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
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #74 from Robert M. Muncrief (rmuncr...@humanavance.com) --- (In reply to Lahfa Samy from comment #73) > (In reply to Robert M. Muncrief from comment #72) > > (In reply to Alex Deucher from comment #71) > > > The original issue reported in this bug was fixed long ago. If you are > > > having issues, please file a new report. > > > > I just filed a new bug for the resume issue at your request. It's 209457. > > My issue seems unrelated to your bug report, my suspend/resume freeze issue > is related to my Intel Wireless AC9260 not to my AMD Ryzen 7 3700U with > integrated graphics Vega RX10. > > Disabling the wireless card in the BIOS fixes the suspend/resume problem for > my specific configuration (Thinkpad T495 20NK model). > > Although your issue seems to be with the AMDGPU driver and related to your > graphics card I suppose. Yes, I filed a new bug for my issue at https://bugzilla.kernel.org/show_bug.cgi?id=209457. Hopefully this bug will be closed to avoid further confusion for users, and relieve the hard working developers from our confusion as well :) -- 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: Nouveau wiki migration
Hi Karol. On Thu, Oct 01, 2020 at 01:36:52PM +0200, Karol Herbst wrote: > On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote: > > > > Hi everybody, > > > > I think it's time to finally move our wiki from the old infrastructure > > over to gitlab pages. > > > > This comes with several benefits: > > * full control through git over the ikiwiki pipeline (setup files, > > plugins, system packages, ...) > > * random users are able to create MRs against the wiki as long as they > > are willing to create a gitlab account. > > * possible to migrate over to a different wiki generator or mix and > > match or whatever. > > * no CGI stuff on the wiki as we don't use ikiwiki for the git > > operations anymore > > > > To view the migrate wiki visit this URL: > > https://nouveau.pages.freedesktop.org/wiki/ I poked around a little - almost all of it looked good. The FAQ points back to some pages on https://nouveau.freedesktop.org - like https://nouveau.freedesktop.org/wiki/XvMC/ I guess this is a bug. But in general looks good. > I did some further changes, like ensuring backwards compatibility to > existing links and already started to clean up some bits, like > removing the google translate stuff. > > Now I'd like to get the subdomain changed of the current wiki over to > the gitlab stuff and wanted to ask for acks/nacks on this No ack/nack here - as I really do not know what to ack/nack. But maybe the above counts like an ack??? But looks good and I hope that others find it simple to help with the pages from the gitlab repo. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm amdgpu + vmwgfx fixes for 5.9-rc8
The pull request you sent on Thu, 1 Oct 2020 16:10:22 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-01-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fcadab740480e0e0e9fa9bd272acd409884d431a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #73 from Lahfa Samy (s...@lahfa.xyz) --- (In reply to Robert M. Muncrief from comment #72) > (In reply to Alex Deucher from comment #71) > > The original issue reported in this bug was fixed long ago. If you are > > having issues, please file a new report. > > I just filed a new bug for the resume issue at your request. It's 209457. My issue seems unrelated to your bug report, my suspend/resume freeze issue is related to my Intel Wireless AC9260 not to my AMD Ryzen 7 3700U with integrated graphics Vega RX10. Disabling the wireless card in the BIOS fixes the suspend/resume problem for my specific configuration (Thinkpad T495 20NK model). Although your issue seems to be with the AMDGPU driver and related to your graphics card I suppose. -- 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
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #72 from Robert M. Muncrief (rmuncr...@humanavance.com) --- (In reply to Alex Deucher from comment #71) > The original issue reported in this bug was fixed long ago. If you are > having issues, please file a new report. I just filed a new bug for the resume issue at your request. It's 209457. -- 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
[Bug 209457] New: AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 Bug ID: 209457 Summary: AMDGPU resume fail with RX 580 GPU Product: Drivers Version: 2.5 Kernel Version: 5.8.12 to 5.9-rc6 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: rmuncr...@humanavance.com Regression: No Created attachment 292739 --> https://bugzilla.kernel.org/attachment.cgi?id=292739&action=edit dmesg resume fail output with kernel 5.9.0-rc6 I've been having random resume problems from around kernel 5.5, and it persists even up to 5.9-rc6. When this occurs I can still login to SSH and give a reboot command, but though SSH disconnects my computer doesn't reboot and I have to press the reset button. I have an ASUS Gaming TUF X570 motherboard, R7 3700X CPU, RX 580 GPU, and 16GB of RAM. The primary error recorded over and over in dmesg is: [x.xx] amdgpu: failed to send message 201 ret is 65535 [x.xx] amdgpu: last message was failed ret is 65535 I've included the part of dmesg beginning with suspend event through the resume failure for kernel 5.9-rc6. -- 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 v6] drm/i915: Init lspcon after HPD in intel_dp_detect()
On Wed, Jun 10, 2020 at 03:55:10PM +0800, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port
> D
>
> Seems like the lspcon chip on the system only gets powered after the
> cable is plugged.
>
> Consilidate lspcon_init() into lspcon_resume() to dynamically init
> lspcon chip, and make HDMI port work.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v6:
> - Rebase on latest for-linux-next.
>
> v5:
> - Consolidate lspcon_resume() with lspcon_init().
> - Move more logic into lspcon code.
>
> v4:
> - Trust VBT in intel_infoframe_init().
> - Init lspcon in intel_dp_detect().
>
> v3:
> - Make sure it's handled under long HPD case.
>
> v2:
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
Hoisted the changelog above --- where it belongs in drm land,
amended with
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/203
and pushed the patch to dinq.
Thanks, and sorry for the horrendous latency.
PS. This will cause some headache for Uma's lspcon HDR stuff, but
so be it.
>
> drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +-
> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
> drivers/gpu/drm/i915/display/intel_lspcon.h | 3 +-
> 5 files changed, 43 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa22465bb56e..af755b1aa24b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4805,7 +4805,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> {
> struct intel_digital_port *intel_dig_port;
> struct intel_encoder *encoder;
> - bool init_hdmi, init_dp, init_lspcon = false;
> + bool init_hdmi, init_dp;
> enum phy phy = intel_port_to_phy(dev_priv, port);
>
> init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
> @@ -4819,7 +4819,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
>* is initialized before lspcon.
>*/
> init_dp = true;
> - init_lspcon = true;
> init_hdmi = false;
> drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
> port_name(port));
> @@ -4904,22 +4903,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> goto err;
> }
>
> - if (init_lspcon) {
> - if (lspcon_init(intel_dig_port))
> - /* TODO: handle hdmi info frame part */
> - drm_dbg_kms(&dev_priv->drm,
> - "LSPCON init success on port %c\n",
> - port_name(port));
> - else
> - /*
> - * LSPCON init faied, but DP init was success, so
> - * lets try to drive as DP++ port.
> - */
> - drm_err(&dev_priv->drm,
> - "LSPCON init failed on port %c\n",
> - port_name(port));
> - }
> -
> if (INTEL_GEN(dev_priv) >= 11) {
> if (intel_phy_is_tc(dev_priv, phy))
> intel_dig_port->connected = intel_tc_port_connected;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ed9e53c373a7..398a104158a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5962,15 +5962,14 @@ static enum drm_connector_status
> intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> u8 *dpcd = intel_dp->dpcd;
> u8 type;
>
> if (WARN_ON(intel_dp_is_edp(intel_dp)))
> return connector_status_connected;
>
> - if (lspcon->active)
> - lspcon_resume(lspcon);
> + lspcon_resume(dig_port);
>
> if (!intel_dp_get_dpcd(intel_dp))
> return connector_status_disconnected;
> @@ -7056,14 +7055,13 @@ void intel_dp_encoder_reset(struct drm_encoder
> *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
> - struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> intel_wakeref_t wakeref;
>
Re: [PATCH] panfrost: Fix job timeout handling
On 01/10/2020 16:49, Boris Brezillon wrote:
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but still blocks something in scheduler
thus leading to repetitive timeouts when new jobs are queued.
Let's make sure all bad jobs are properly handled by the thread acquiring
the lock.
Signed-off-by: Boris Brezillon
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
---
drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 30e7b7196dab..e87edca51d84 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -25,7 +25,7 @@
struct panfrost_queue_state {
struct drm_gpu_scheduler sched;
-
+ struct drm_sched_job *bad;
u64 fence_context;
u64 emit_seqno;
};
@@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
job_read(pfdev, JS_TAIL_LO(js)),
sched_job);
+ /*
+* Collect the bad job here so it can be processed by the thread
+* acquiring the reset lock.
+*/
+ pfdev->js->queue[js].bad = sched_job;
+
if (!mutex_trylock(&pfdev->reset_lock))
return;
for (i = 0; i < NUM_JOB_SLOTS; i++) {
struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
- drm_sched_stop(sched, sched_job);
if (js != i)
/* Ensure any timeouts on other slots have finished */
cancel_delayed_work_sync(&sched->work_tdr);
- }
- drm_sched_increase_karma(sched_job);
+ drm_sched_stop(sched, pfdev->js->queue[i].bad);
So I can see that the call to drm_sched_stop() needs to move below the
cancel_delayed_work_sync() to ensure that the update to queue->bad is
synchronised. What I'm not so sure about is whether it's possible for
the scheduler to make progress between the 'cancel' and the 'stop' -
there is a reason I wrote it the other way round...
Ok, I think see what you mean now. So, there's indeed a race between
the cancel_delayed_work_sync() and drm_sched_stop() calls, and a
timeout might go undetected because of that. This being said, the only
problem I see is that we would not increase karma on that job. In any
case the job will be re-queued, and unless we keep having timeouts on
the other queues it should be detected at some point. I can also try to
retrieve the deadline before canceling the delayed work and check it
before stopping the scheduler, but I'm not sure it's worth it.
Yes - well explained, I was trying to write an explanation but you beat
me to it ;)
However I think it's worse than just the karma - the second timeout of a
job could take a while to execute and actually execute *after* the first
timeout has completed. I'm wondering whether we just need something like:
cancel_delayed_work_sync()
drm_sched_stop()
cancel_delayed_work_sync()
that way we ensure that any other timeouts will definitely have
completed before performing the reset.
There's still a minor race regarding the karma - but that shouldn't
matter as you mention.
Steve
The hole for things to go round is clearly much smaller with this
change, but I'm not sure it's completely plugged. Am I missing something?
+
+ if (pfdev->js->queue[i].bad)
+ drm_sched_increase_karma(pfdev->js->queue[i].bad);
+
+ pfdev->js->queue[i].bad = NULL;
+ }
spin_lock_irqsave(&pfdev->js->job_lock, flags);
for (i = 0; i < NUM_JOB_SLOTS; i++) {
While we're on potential holes... some more context:
if (pfdev->jobs[i]) {
pm_runtime_put_noidle(pfdev->dev);
panfrost_devfreq_record_idle(pfdev);
pfdev->jobs[i] = NULL;
}
}
spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
panfrost_device_reset(pfdev);
for (i = 0; i < NUM_JOB_SLOTS; i++)
drm_sched_resubmit_jobs(&pfdev->js->queue[i].sched);
/* restart scheduler after GPU is usable again */
for (i = 0; i < NUM_JOB_SLOTS; i++)
drm_sched_start(&pfdev->js->queue[i].sched, true);
mutex_unlock(&pfdev->reset_lock);
I'm wondering whether the mutex_unlock() should actually happen before
the drm_sched_start() - in the (admittedly very unlikely) case where a
timeout occurs before all the drm_sched_start() calls have completed
it's possible for the timeout to be completely mi
Re: [PATCH tip/core/rcu 11/15] drm/i915: Cleanup PREEMPT_COUNT leftovers
On Thu, Oct 01, 2020 at 10:25:06AM +0200, Thomas Gleixner wrote: > On Thu, Oct 01 2020 at 10:17, Joonas Lahtinen wrote: > > Quoting paul...@kernel.org (2020-09-29 02:30:58) > >> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be > >> removed. Cleanup the leftovers before doing so. > > > > Change looks fine: > > > > Reviewed-by: Joonas Lahtinen Applied, thank you! > > Are you looking for us to merge or merge through another tree? > > > > If us, did the base patch always enabling PREEMPT_COUNT go into 5.9 or is > > it heading to 5.10? We can queue this earliest for 5.11 as drm-next closed > > for 5.10 at week of -rc5. > > If at all it goes through rcu/tip because it depends on the earlier patches. I was figuring on sending a pull request later today, Pacific Time. Thanx, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] panfrost: Fix job timeout handling
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangling state where it's no longer
> > part of the scheduling queue, but still blocks something in scheduler
> > thus leading to repetitive timeouts when new jobs are queued.
> >
> > Let's make sure all bad jobs are properly handled by the thread acquiring
> > the lock.
> >
> > Signed-off-by: Boris Brezillon
> > Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> > Cc:
> > ---
> > drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > index 30e7b7196dab..e87edca51d84 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > @@ -25,7 +25,7 @@
> >
> > struct panfrost_queue_state {
> > struct drm_gpu_scheduler sched;
> > -
> > + struct drm_sched_job *bad;
> > u64 fence_context;
> > u64 emit_seqno;
> > };
> > @@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct
> > drm_sched_job *sched_job)
> > job_read(pfdev, JS_TAIL_LO(js)),
> > sched_job);
> >
> > + /*
> > +* Collect the bad job here so it can be processed by the thread
> > +* acquiring the reset lock.
> > +*/
> > + pfdev->js->queue[js].bad = sched_job;
> > +
> > if (!mutex_trylock(&pfdev->reset_lock))
> > return;
> >
> > for (i = 0; i < NUM_JOB_SLOTS; i++) {
> > struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
> >
> > - drm_sched_stop(sched, sched_job);
> > if (js != i)
> > /* Ensure any timeouts on other slots have finished */
> > cancel_delayed_work_sync(&sched->work_tdr);
> > - }
> >
> > - drm_sched_increase_karma(sched_job);
> > + drm_sched_stop(sched, pfdev->js->queue[i].bad);
>
> So I can see that the call to drm_sched_stop() needs to move below the
> cancel_delayed_work_sync() to ensure that the update to queue->bad is
> synchronised. What I'm not so sure about is whether it's possible for
> the scheduler to make progress between the 'cancel' and the 'stop' -
> there is a reason I wrote it the other way round...
Ok, I think see what you mean now. So, there's indeed a race between
the cancel_delayed_work_sync() and drm_sched_stop() calls, and a
timeout might go undetected because of that. This being said, the only
problem I see is that we would not increase karma on that job. In any
case the job will be re-queued, and unless we keep having timeouts on
the other queues it should be detected at some point. I can also try to
retrieve the deadline before canceling the delayed work and check it
before stopping the scheduler, but I'm not sure it's worth it.
>
> The hole for things to go round is clearly much smaller with this
> change, but I'm not sure it's completely plugged. Am I missing something?
>
> > +
> > + if (pfdev->js->queue[i].bad)
> > + drm_sched_increase_karma(pfdev->js->queue[i].bad);
> > +
> > + pfdev->js->queue[i].bad = NULL;
> > + }
> >
> > spin_lock_irqsave(&pfdev->js->job_lock, flags);
> > for (i = 0; i < NUM_JOB_SLOTS; i++) {
> >
>
> While we're on potential holes... some more context:
>
> > if (pfdev->jobs[i]) {
> > pm_runtime_put_noidle(pfdev->dev);
> > panfrost_devfreq_record_idle(pfdev);
> > pfdev->jobs[i] = NULL;
> > }
> > }
> > spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
> >
> > panfrost_device_reset(pfdev);
> >
> > for (i = 0; i < NUM_JOB_SLOTS; i++)
> > drm_sched_resubmit_jobs(&pfdev->js->queue[i].sched);
> >
> > /* restart scheduler after GPU is usable again */
> > for (i = 0; i < NUM_JOB_SLOTS; i++)
> > drm_sched_start(&pfdev->js->queue[i].sched, true);
> >
> > mutex_unlock(&pfdev->reset_lock);
>
> I'm wondering whether the mutex_unlock() should actually happen before
> the drm_sched_start() - in the (admittedly very unlikely) case where a
> timeout occurs before all the drm_sched_start() calls have completed
> it's possible for the timeout to be completely missed because the mutex
> is still held.
>
> Thanks,
>
> Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote: > > > > > > From: Rob Clark > > > > > > The android userspace treats the display pipeline as a realtime problem. > > > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > > > it is. (See https://lwn.net/Articles/809545/ for the best explaination > > > that I found.) > > > > > > But this presents a problem with using workqueues for non-blocking > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) can > > > preempt the worker. Which is not really the outcome you want.. once > > > the required fences are scheduled, you want to push the atomic commit > > > down to hw ASAP. > > > > > > But the decision of whether commit_work should be RT or not really > > > depends on what userspace is doing. For a pure CFS userspace display > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers are > > > used to avoid serializing commits when userspace is using a per-CRTC > > > update loop. And the last patch exposes the task id to userspace as > > > a CRTC property, so that userspace can adjust the priority and sched > > > policy to fit it's needs. > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > favor of exposing the kworker tid to userspace so that user- > > > space can set priority/policy. > > > > Yeah I think this looks more reasonable. Still a bit irky interface, > > so I'd like to get some kworker/rt ack on this. Other opens: > > - needs userspace, the usual drill > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > userspace will become a standalone helper or daemon, mostly because > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm > still entertaining the possibility of switching between rt and cfs > depending on what is in the foreground (ie. only do rt for android > apps). > > > - we need this also for vblank workers, otherwise this wont work for > > drivers needing those because of another priority inversion. > > I have a thought on that, see below.. Hm, not seeing anything about vblank worker below? > > - we probably want some indication of whether this actually does > > something useful, not all drivers use atomic commit helpers. Not sure > > how to do that. > > I'm leaning towards converting the other drivers over to use the > per-crtc kwork, and then dropping the 'commit_work` from atomic state. > I can add a patch to that, but figured I could postpone that churn > until there is some by-in on this whole idea. i915 has its own commit code, it's not even using the current commit helpers (nor the commit_work). Not sure how much other fun there is. > > - not sure whether the vfunc is an awesome idea, I'd frankly just > > open-code this inline. We have similar special cases already for e.g. > > dpms (and in multiple places), this isn't the worst. > > I could introduce a "PID" property type. This would be useful if we > wanted to also expose the vblank workers. Hm right, but I think we need at most 2 for commit thread and vblank thread (at least with the current design). So open-coded if with two if (prop == crtc_worker_pid_prop || prop == crtc_vblank_worker_pid_prop) doesn't seem too horrible to me. Otherwise people start creating really funny stuff in their drivers with this backend, and I don't want to spend all the time making sure they don't abuse this :-) > > - still feeling we could at least change the default to highpriority > > niceness. > > AFAIU this would still be preempted by something that is SCHED_FIFO. > Also, with cfs/SCHED_NORMAL, you can still be preempted by lower > priority things that haven't had a chance to run for a while. i915 uses highprio workqueue, so I guess to avoid regressions we need that (it's also not using the commit helpers right now, but no reason not to afaics, stuff simply happened in parallel back then. > > - there's still the problem that commit works can overlap, and a > > single worker can't do that anymore. So rolling that out for everyone > > as-is feels a bit risky. > > That is why it is per-CRTC.. I'm not sure there is a need to overlap > work for a single CRTC? > > We could OFC make this a driver knob, and keep the old 'commit_work' > option, but that doesn't really feel like the right direction drm_atomic_helper_commit_hw_done is what unblocks the next worker on the same set of crtc. It's before we do all the buffer cleanup, which has a full vblank stall beforehand. Most drivers also have the same vblank stall in their next commit, plus generally the fb cleanup is cheap, but neither is a requirement. So yeah you can get overlapping commit work on the same crtc, and that was kinda intentional. Maybe was overkil
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote: > The fix of flagging state->modeset whenever distrust_bios_wm is set > causes a regression when initializing display(s) attached to a Lenovo > USB-C docking station. The display remains blank until the dock is > reattached. Revert to bring the behavior of the functional v5.6 stable. > > This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9. > > BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442 > Signed-off-by: Stefan Joosten > --- > drivers/gpu/drm/i915/display/intel_display.c | 14 -- > 1 file changed, 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index b18c5ac2934d..ece1c28278f7 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev, > if (ret) > goto fail; > > - /* > - * distrust_bios_wm will force a full dbuf recomputation > - * but the hardware state will only get updated accordingly > - * if state->modeset==true. Hence distrust_bios_wm==true && > - * state->modeset==false is an invalid combination which > - * would cause the hardware and software dbuf state to get > - * out of sync. We must prevent that. > - * > - * FIXME clean up this mess and introduce better > - * state tracking for dbuf. > - */ > - if (dev_priv->wm.distrust_bios_wm) > - any_ms = true; > - Argh. If only I had managed to land the full dbuf rework and nuke this mess before it came back to bite us... This is definitely going to break something else, so not great. Can you file an upstream bug at https://gitlab.freedesktop.org/drm/intel/issues/new and attach dmesgs from booting both good and bad kernels with drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len= if necessary to capture the full log. > intel_fbc_choose_crtc(dev_priv, state); > ret = calc_watermark_data(state); > if (ret) > -- > 2.25.4 > > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] panfrost: Fix job timeout handling
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangling state where it's no longer
> > part of the scheduling queue, but still blocks something in scheduler
> > thus leading to repetitive timeouts when new jobs are queued.
> >
> > Let's make sure all bad jobs are properly handled by the thread acquiring
> > the lock.
> >
> > Signed-off-by: Boris Brezillon
> > Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> > Cc:
> > ---
> > drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > index 30e7b7196dab..e87edca51d84 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > @@ -25,7 +25,7 @@
> >
> > struct panfrost_queue_state {
> > struct drm_gpu_scheduler sched;
> > -
> > + struct drm_sched_job *bad;
> > u64 fence_context;
> > u64 emit_seqno;
> > };
> > @@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct
> > drm_sched_job *sched_job)
> > job_read(pfdev, JS_TAIL_LO(js)),
> > sched_job);
> >
> > + /*
> > +* Collect the bad job here so it can be processed by the thread
> > +* acquiring the reset lock.
> > +*/
> > + pfdev->js->queue[js].bad = sched_job;
> > +
> > if (!mutex_trylock(&pfdev->reset_lock))
> > return;
> >
> > for (i = 0; i < NUM_JOB_SLOTS; i++) {
> > struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
> >
> > - drm_sched_stop(sched, sched_job);
> > if (js != i)
> > /* Ensure any timeouts on other slots have finished */
> > cancel_delayed_work_sync(&sched->work_tdr);
> > - }
> >
> > - drm_sched_increase_karma(sched_job);
> > + drm_sched_stop(sched, pfdev->js->queue[i].bad);
>
> So I can see that the call to drm_sched_stop() needs to move below the
> cancel_delayed_work_sync() to ensure that the update to queue->bad is
> synchronised.
Exactly, and it probably deserves a comment :-).
> What I'm not so sure about is whether it's possible for
> the scheduler to make progress between the 'cancel' and the 'stop' -
> there is a reason I wrote it the other way round...
Hm, we should probably stop the queue on which the timeout happened
before acquiring the lock, this way we guarantee that nothing executes
on queues that reported a timeout until the reset actually happens.
That leaves queues on which no timeout was reported, and I wonder why
it'd be bad to let those continue executing jobs. Do you see any case
where that'd be a problem?
>
> The hole for things to go round is clearly much smaller with this
> change, but I'm not sure it's completely plugged. Am I missing something?
>
> > +
> > + if (pfdev->js->queue[i].bad)
> > + drm_sched_increase_karma(pfdev->js->queue[i].bad);
> > +
> > + pfdev->js->queue[i].bad = NULL;
> > + }
> >
> > spin_lock_irqsave(&pfdev->js->job_lock, flags);
> > for (i = 0; i < NUM_JOB_SLOTS; i++) {
> >
>
> While we're on potential holes... some more context:
>
> > if (pfdev->jobs[i]) {
> > pm_runtime_put_noidle(pfdev->dev);
> > panfrost_devfreq_record_idle(pfdev);
> > pfdev->jobs[i] = NULL;
> > }
> > }
> > spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
> >
> > panfrost_device_reset(pfdev);
> >
> > for (i = 0; i < NUM_JOB_SLOTS; i++)
> > drm_sched_resubmit_jobs(&pfdev->js->queue[i].sched);
> >
> > /* restart scheduler after GPU is usable again */
> > for (i = 0; i < NUM_JOB_SLOTS; i++)
> > drm_sched_start(&pfdev->js->queue[i].sched, true);
> >
> > mutex_unlock(&pfdev->reset_lock);
>
> I'm wondering whether the mutex_unlock() should actually happen before
> the drm_sched_start() - in the (admittedly very unlikely) case where a
> timeout occurs before all the drm_sched_start() calls have completed
> it's possible for the timeout to be completely missed because the mutex
> is still held.
Oh, good catch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote: > > > > From: Rob Clark > > > > The android userspace treats the display pipeline as a realtime problem. > > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > > it is. (See https://lwn.net/Articles/809545/ for the best explaination > > that I found.) > > > > But this presents a problem with using workqueues for non-blocking > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) can > > preempt the worker. Which is not really the outcome you want.. once > > the required fences are scheduled, you want to push the atomic commit > > down to hw ASAP. > > > > But the decision of whether commit_work should be RT or not really > > depends on what userspace is doing. For a pure CFS userspace display > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > kthread workers, instead of system_unbound_wq. Per-CRTC workers are > > used to avoid serializing commits when userspace is using a per-CRTC > > update loop. And the last patch exposes the task id to userspace as > > a CRTC property, so that userspace can adjust the priority and sched > > policy to fit it's needs. > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > favor of exposing the kworker tid to userspace so that user- > > space can set priority/policy. > > Yeah I think this looks more reasonable. Still a bit irky interface, > so I'd like to get some kworker/rt ack on this. Other opens: > - needs userspace, the usual drill fwiw, right now the userspace is "modetest + chrt".. *probably* the userspace will become a standalone helper or daemon, mostly because the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm still entertaining the possibility of switching between rt and cfs depending on what is in the foreground (ie. only do rt for android apps). > - we need this also for vblank workers, otherwise this wont work for > drivers needing those because of another priority inversion. I have a thought on that, see below.. > - we probably want some indication of whether this actually does > something useful, not all drivers use atomic commit helpers. Not sure > how to do that. I'm leaning towards converting the other drivers over to use the per-crtc kwork, and then dropping the 'commit_work` from atomic state. I can add a patch to that, but figured I could postpone that churn until there is some by-in on this whole idea. > - not sure whether the vfunc is an awesome idea, I'd frankly just > open-code this inline. We have similar special cases already for e.g. > dpms (and in multiple places), this isn't the worst. I could introduce a "PID" property type. This would be useful if we wanted to also expose the vblank workers. > - still feeling we could at least change the default to highpriority niceness. AFAIU this would still be preempted by something that is SCHED_FIFO. Also, with cfs/SCHED_NORMAL, you can still be preempted by lower priority things that haven't had a chance to run for a while. > - there's still the problem that commit works can overlap, and a > single worker can't do that anymore. So rolling that out for everyone > as-is feels a bit risky. That is why it is per-CRTC.. I'm not sure there is a need to overlap work for a single CRTC? We could OFC make this a driver knob, and keep the old 'commit_work' option, but that doesn't really feel like the right direction BR, -R > Cheers, Daniel > > > > > Rob Clark (3): > > drm/crtc: Introduce per-crtc kworker > > drm/atomic: Use kthread worker for nonblocking commits > > drm: Expose CRTC's kworker task id > > > > drivers/gpu/drm/drm_atomic_helper.c | 13 > > drivers/gpu/drm/drm_crtc.c | 14 + > > drivers/gpu/drm/drm_mode_config.c | 14 + > > drivers/gpu/drm/drm_mode_object.c | 4 > > include/drm/drm_atomic.h| 31 + > > include/drm/drm_crtc.h | 8 > > include/drm/drm_mode_config.h | 9 + > > include/drm/drm_property.h | 9 + > > 8 files changed, 98 insertions(+), 4 deletions(-) > > > > -- > > 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: linux-next: manual merge of the akpm tree with the drm-intel tree
On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula wrote:
>
> On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
> >>
> >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> >> > Hi all,
> >> >
> >> > Today's linux-next merge of the akpm tree got a conflict in:
> >> >
> >> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> >> >
> >> > between commit:
> >> >
> >> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on
> >> > x86-32")
> >> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if
> >> > PAT is not supported")
> >
> > Uh these patches shouldn't be in linux-next because they're for 5.11,
> > not the 5.10 merge window that will open soon. Joonas?
>
> I don't know anything else, but both are tagged Cc: stable.
Uh right I got confused, they're on -fixes now. Well -next-fixes,
which seems like the wrong one for a cc: stable, I guess this should
go into 5.9 even. Apologies for my confusion.
-Daniel
>
> BR,
> Jani.
>
> >
> >> > from the drm-intel tree and patch:
> >> >
> >> > "drm/i915: use vmap in i915_gem_object_map"
> >> >
> >> > from the akpm tree.
> >> >
> >> > I fixed it up (I just dropped the changes in the former commits) and
> >>
> >> Sigh. The solution is a bit more complicated, but I just redid my
> >> patches to not depend on the above ones. I can revert back to the old
> >> version, though. Andrew, let me know what works for you.
> >
> > Imo ignore, rebasing onto linux-next without those intel patches was
> > the right thing for the 5.10 merge window.
> > -Daniel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
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: linux-next: manual merge of the akpm tree with the drm-intel tree
On Thu, 01 Oct 2020, Daniel Vetter wrote:
> On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
>>
>> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > Today's linux-next merge of the akpm tree got a conflict in:
>> >
>> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> >
>> > between commit:
>> >
>> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
>> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT
>> > is not supported")
>
> Uh these patches shouldn't be in linux-next because they're for 5.11,
> not the 5.10 merge window that will open soon. Joonas?
I don't know anything else, but both are tagged Cc: stable.
BR,
Jani.
>
>> > from the drm-intel tree and patch:
>> >
>> > "drm/i915: use vmap in i915_gem_object_map"
>> >
>> > from the akpm tree.
>> >
>> > I fixed it up (I just dropped the changes in the former commits) and
>>
>> Sigh. The solution is a bit more complicated, but I just redid my
>> patches to not depend on the above ones. I can revert back to the old
>> version, though. Andrew, let me know what works for you.
>
> Imo ignore, rebasing onto linux-next without those intel patches was
> the right thing for the 5.10 merge window.
> -Daniel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sched: Avoid infinite waits in the drm_sched_entity_destroy() path
On 01/10/2020 15:12, Boris Brezillon wrote: If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. Signed-off-by: Boris Brezillon This seems reasonable to me - it looks like in theory if you very quickly open, submit a job and close you could trigger this (i.e. if drm_sched_main() never actually enters the while loop). You should CC some other folk as this doesn't just affect Panfrost. Reviewed-by: Steven Price --- This is something I noticed while debugging another issue on panfrost causing the scheduler to be in a weird state where new entities were no longer scheduled. This was causing all userspace threads trying to close their DRM fd to be blocked in kernel space waiting for this "entity is idle" event. I don't know if that fix is legitimate (now that we fixed the other bug we don't seem to end up in that state anymore), but I thought I'd share it anyway. --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 146380118962..f8ec277a6aa8 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -73,6 +73,9 @@ int drm_sched_entity_init(struct drm_sched_entity *entity, init_completion(&entity->entity_idle); + /* We start in an idle state. */ + complete(&entity->entity_idle); + spin_lock_init(&entity->rq_lock); spsc_queue_init(&entity->job_queue); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #71 from Alex Deucher (alexdeuc...@gmail.com) --- The original issue reported in this bug was fixed long ago. If you are having issues, please file a new report. -- 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] panfrost: Fix job timeout handling
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but still blocks something in scheduler
thus leading to repetitive timeouts when new jobs are queued.
Let's make sure all bad jobs are properly handled by the thread acquiring
the lock.
Signed-off-by: Boris Brezillon
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
---
drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 30e7b7196dab..e87edca51d84 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -25,7 +25,7 @@
struct panfrost_queue_state {
struct drm_gpu_scheduler sched;
-
+ struct drm_sched_job *bad;
u64 fence_context;
u64 emit_seqno;
};
@@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
job_read(pfdev, JS_TAIL_LO(js)),
sched_job);
+ /*
+* Collect the bad job here so it can be processed by the thread
+* acquiring the reset lock.
+*/
+ pfdev->js->queue[js].bad = sched_job;
+
if (!mutex_trylock(&pfdev->reset_lock))
return;
for (i = 0; i < NUM_JOB_SLOTS; i++) {
struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
- drm_sched_stop(sched, sched_job);
if (js != i)
/* Ensure any timeouts on other slots have finished */
cancel_delayed_work_sync(&sched->work_tdr);
- }
- drm_sched_increase_karma(sched_job);
+ drm_sched_stop(sched, pfdev->js->queue[i].bad);
So I can see that the call to drm_sched_stop() needs to move below the
cancel_delayed_work_sync() to ensure that the update to queue->bad is
synchronised. What I'm not so sure about is whether it's possible for
the scheduler to make progress between the 'cancel' and the 'stop' -
there is a reason I wrote it the other way round...
The hole for things to go round is clearly much smaller with this
change, but I'm not sure it's completely plugged. Am I missing something?
+
+ if (pfdev->js->queue[i].bad)
+ drm_sched_increase_karma(pfdev->js->queue[i].bad);
+
+ pfdev->js->queue[i].bad = NULL;
+ }
spin_lock_irqsave(&pfdev->js->job_lock, flags);
for (i = 0; i < NUM_JOB_SLOTS; i++) {
While we're on potential holes... some more context:
if (pfdev->jobs[i]) {
pm_runtime_put_noidle(pfdev->dev);
panfrost_devfreq_record_idle(pfdev);
pfdev->jobs[i] = NULL;
}
}
spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
panfrost_device_reset(pfdev);
for (i = 0; i < NUM_JOB_SLOTS; i++)
drm_sched_resubmit_jobs(&pfdev->js->queue[i].sched);
/* restart scheduler after GPU is usable again */
for (i = 0; i < NUM_JOB_SLOTS; i++)
drm_sched_start(&pfdev->js->queue[i].sched, true);
mutex_unlock(&pfdev->reset_lock);
I'm wondering whether the mutex_unlock() should actually happen before
the drm_sched_start() - in the (admittedly very unlikely) case where a
timeout occurs before all the drm_sched_start() calls have completed
it's possible for the timeout to be completely missed because the mutex
is still held.
Thanks,
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the akpm tree with the drm-intel tree
On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
>
> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> >
> > between commit:
> >
> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT
> > is not supported")
Uh these patches shouldn't be in linux-next because they're for 5.11,
not the 5.10 merge window that will open soon. Joonas?
> > from the drm-intel tree and patch:
> >
> > "drm/i915: use vmap in i915_gem_object_map"
> >
> > from the akpm tree.
> >
> > I fixed it up (I just dropped the changes in the former commits) and
>
> Sigh. The solution is a bit more complicated, but I just redid my
> patches to not depend on the above ones. I can revert back to the old
> version, though. Andrew, let me know what works for you.
Imo ignore, rebasing onto linux-next without those intel patches was
the right thing for the 5.10 merge window.
-Daniel
--
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
[PATCH] drm/sched: Avoid infinite waits in the drm_sched_entity_destroy() path
If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. Signed-off-by: Boris Brezillon --- This is something I noticed while debugging another issue on panfrost causing the scheduler to be in a weird state where new entities were no longer scheduled. This was causing all userspace threads trying to close their DRM fd to be blocked in kernel space waiting for this "entity is idle" event. I don't know if that fix is legitimate (now that we fixed the other bug we don't seem to end up in that state anymore), but I thought I'd share it anyway. --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 146380118962..f8ec277a6aa8 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -73,6 +73,9 @@ int drm_sched_entity_init(struct drm_sched_entity *entity, init_completion(&entity->entity_idle); + /* We start in an idle state. */ + complete(&entity->entity_idle); + spin_lock_init(&entity->rq_lock); spsc_queue_init(&entity->job_queue); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] panfrost: Fix job timeout handling
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but still blocks something in scheduler
thus leading to repetitive timeouts when new jobs are queued.
Let's make sure all bad jobs are properly handled by the thread acquiring
the lock.
Signed-off-by: Boris Brezillon
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
---
drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 30e7b7196dab..e87edca51d84 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -25,7 +25,7 @@
struct panfrost_queue_state {
struct drm_gpu_scheduler sched;
-
+ struct drm_sched_job *bad;
u64 fence_context;
u64 emit_seqno;
};
@@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
job_read(pfdev, JS_TAIL_LO(js)),
sched_job);
+ /*
+* Collect the bad job here so it can be processed by the thread
+* acquiring the reset lock.
+*/
+ pfdev->js->queue[js].bad = sched_job;
+
if (!mutex_trylock(&pfdev->reset_lock))
return;
for (i = 0; i < NUM_JOB_SLOTS; i++) {
struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
- drm_sched_stop(sched, sched_job);
if (js != i)
/* Ensure any timeouts on other slots have finished */
cancel_delayed_work_sync(&sched->work_tdr);
- }
- drm_sched_increase_karma(sched_job);
+ drm_sched_stop(sched, pfdev->js->queue[i].bad);
+
+ if (pfdev->js->queue[i].bad)
+ drm_sched_increase_karma(pfdev->js->queue[i].bad);
+
+ pfdev->js->queue[i].bad = NULL;
+ }
spin_lock_irqsave(&pfdev->js->job_lock, flags);
for (i = 0; i < NUM_JOB_SLOTS; i++) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] panfrost: Fix job timeout handling
Oops, the prefix should be "drm/panfrost", will fix that in v2.
On Thu, 1 Oct 2020 16:01:43 +0200
Boris Brezillon wrote:
> If more than two or more jobs end up timeout-ing concurrently, only one
> of them (the one attached to the scheduler acquiring the lock) is fully
> handled. The other one remains in a dangling state where it's no longer
> part of the scheduling queue, but still blocks something in scheduler
> thus leading to repetitive timeouts when new jobs are queued.
>
> Let's make sure all bad jobs are properly handled by the thread acquiring
> the lock.
>
> Signed-off-by: Boris Brezillon
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc:
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 30e7b7196dab..e87edca51d84 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -25,7 +25,7 @@
>
> struct panfrost_queue_state {
> struct drm_gpu_scheduler sched;
> -
> + struct drm_sched_job *bad;
> u64 fence_context;
> u64 emit_seqno;
> };
> @@ -392,19 +392,29 @@ static void panfrost_job_timedout(struct drm_sched_job
> *sched_job)
> job_read(pfdev, JS_TAIL_LO(js)),
> sched_job);
>
> + /*
> + * Collect the bad job here so it can be processed by the thread
> + * acquiring the reset lock.
> + */
> + pfdev->js->queue[js].bad = sched_job;
> +
> if (!mutex_trylock(&pfdev->reset_lock))
> return;
>
> for (i = 0; i < NUM_JOB_SLOTS; i++) {
> struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched;
>
> - drm_sched_stop(sched, sched_job);
> if (js != i)
> /* Ensure any timeouts on other slots have finished */
> cancel_delayed_work_sync(&sched->work_tdr);
> - }
>
> - drm_sched_increase_karma(sched_job);
> + drm_sched_stop(sched, pfdev->js->queue[i].bad);
> +
> + if (pfdev->js->queue[i].bad)
> + drm_sched_increase_karma(pfdev->js->queue[i].bad);
> +
> + pfdev->js->queue[i].bad = NULL;
> + }
>
> spin_lock_irqsave(&pfdev->js->job_lock, flags);
> for (i = 0; i < NUM_JOB_SLOTS; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: bridge: cdns-mhdp8546: fix compile warning
Hi Dave,
Can you pick this up to drm-next? Fixes the x64 build warnings for the recent
cdns-mhdp-5.10 pull.
Tomi
On 29/09/2020 12:19, Tomi Valkeinen wrote:
> On x64 we get:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> conversion from 'long unsigned int' to 'unsigned int' changes value from
> '18446744073709551613' to '4294967293' [-Woverflow]
>
> The registers are 32 bit, so fix by casting to u32.
>
> Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP
> bridge")
> Signed-off-by: Tomi Valkeinen
> Reported-by: Stephen Rothwell
> Reviewed-by: Swapnil Jakhade
> Acked-by: Laurent Pinchart
> ---
>
> v2:
>
> No changes to code, added tags.
>
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 621ebdbff8a3..d0c65610ebb5 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -748,7 +748,7 @@ static int cdns_mhdp_fw_activate(const struct firmware
> *fw,
>* bridge should already be detached.
>*/
> if (mhdp->bridge_attached)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> mhdp->regs + CDNS_APB_INT_MASK);
>
> spin_unlock(&mhdp->start_lock);
> @@ -1689,7 +1689,7 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
>
> /* Enable SW event interrupts */
> if (hw_ready)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> mhdp->regs + CDNS_APB_INT_MASK);
>
> return 0;
> @@ -2122,7 +2122,7 @@ static void cdns_mhdp_bridge_hpd_enable(struct
> drm_bridge *bridge)
>
> /* Enable SW event interrupts */
> if (mhdp->bridge_attached)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> mhdp->regs + CDNS_APB_INT_MASK);
> }
>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/panfrost: simplify the return expression of panfrost_devfreq_target()
On 01/10/2020 12:25, Daniel Vetter wrote: On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote: On 21/09/2020 14:10, Qinglang Miao wrote: Simplify the return expression. Signed-off-by: Qinglang Miao Reviewed-by: Steven Price As committer/maintainer for this please indicate whether you'll merge this or not, with just an r-b patches are in an awkward limbo state. Since Qinglang isn't committer you probably want to merge their patches, for otherwise they get lost. -Daniel Sorry, I should have said - I'll push this (and the other similar patch [1]) to drm-misc-next. Steve [1] https://lore.kernel.org/r/20200921131019.91558-1-miaoqingl...@huawei.com/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Nouveau wiki migration
On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote: > > Hi everybody, > > I think it's time to finally move our wiki from the old infrastructure > over to gitlab pages. > > This comes with several benefits: > * full control through git over the ikiwiki pipeline (setup files, > plugins, system packages, ...) > * random users are able to create MRs against the wiki as long as they > are willing to create a gitlab account. > * possible to migrate over to a different wiki generator or mix and > match or whatever. > * no CGI stuff on the wiki as we don't use ikiwiki for the git > operations anymore > > To view the migrate wiki visit this URL: > https://nouveau.pages.freedesktop.org/wiki/ > the gitlab project lives here: https://gitlab.freedesktop.org/nouveau/wiki > > There are a couple of changes I already made: > * convert the perl ikiwiki setup file to yaml: > https://gitlab.freedesktop.org/nouveau/wiki/-/blob/master/nouveau.yml > * reworked the setup file to throw out unused plugins and adjust > settings for gitlab > * enabled HTML5 (does change the style slightly, but also fixed some > regressions) > * pulled in external sources (from the fdo.org server) > * moved mdwn files into their own subdirectory > > For now I changed everything inside one big commit: > https://gitlab.freedesktop.org/nouveau/wiki/-/commit/6f2d1669884af186863718ad827f65372a0c5c43 > > There are a couple of remaining issues/questions: > * the gitlab CI pipeline fails quite a bit, which could be annoying > * there is a delay between editing and changes going live (usually > below a minute though) > * should we disallow direct editing of files for project members so we > could CI the changes are still valid? > > Next steps: > * verify everything still works > * fix remaining issues > * final step: point the subdomain to the new gitlab pages URL > > If anybody else is interested in moving their wikis over, don't > hesitate to ask me questions or just copy whatever I did :) I did some further changes, like ensuring backwards compatibility to existing links and already started to clean up some bits, like removing the google translate stuff. Now I'd like to get the subdomain changed of the current wiki over to the gitlab stuff and wanted to ask for acks/nacks on this ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
This is not something drivers should use.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++-
{include => drivers/gpu}/drm/ttm/ttm_set_memory.h | 0
3 files changed, 4 insertions(+), 2 deletions(-)
rename {include => drivers/gpu}/drm/ttm/ttm_set_memory.h (100%)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..912c30dcc9db 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -47,7 +47,8 @@
#include
#include
-#include
+
+#include "ttm_set_memory.h"
#define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *))
#define SMALL_ALLOCATION 16
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 5e2df11685e7..1045a5c26ee3 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -49,7 +49,8 @@
#include
#include
#include
-#include
+
+#include "ttm_set_memory.h"
#define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *))
#define SMALL_ALLOCATION 4
diff --git a/include/drm/ttm/ttm_set_memory.h
b/drivers/gpu/drm/ttm/ttm_set_memory.h
similarity index 100%
rename from include/drm/ttm/ttm_set_memory.h
rename to drivers/gpu/drm/ttm/ttm_set_memory.h
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/ttm: nuke caching placement flags
Changing the caching on the fly never really worked flawlessly. So stop this completely and just let drivers specific the desired caching in the tt or bus object. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 ++ drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--- drivers/gpu/drm/nouveau/nouveau_bo.c | 36 + drivers/gpu/drm/qxl/qxl_object.c | 10 ++--- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 46 +- drivers/gpu/drm/radeon/radeon_ttm.c| 18 ++--- drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +- drivers/gpu/drm/ttm/ttm_bo.c | 44 ++--- drivers/gpu/drm/ttm/ttm_bo_util.c | 10 ++--- drivers/gpu/drm/ttm/ttm_tt.c | 29 -- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 30 +++--- include/drm/ttm/ttm_placement.h| 14 --- include/drm/ttm/ttm_tt.h | 15 --- 15 files changed, 61 insertions(+), 234 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 80bc7177cd45..964f9512dd6e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -137,7 +137,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].fpfn = 0; places[c].lpfn = 0; places[c].mem_type = TTM_PL_VRAM; - places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED; + places[c].flags = 0; if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) places[c].lpfn = visible_pfn; @@ -154,11 +154,6 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].lpfn = 0; places[c].mem_type = TTM_PL_TT; places[c].flags = 0; - if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) - places[c].flags |= TTM_PL_FLAG_WC | - TTM_PL_FLAG_UNCACHED; - else - places[c].flags |= TTM_PL_FLAG_CACHED; c++; } @@ -167,11 +162,6 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].lpfn = 0; places[c].mem_type = TTM_PL_SYSTEM; places[c].flags = 0; - if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) - places[c].flags |= TTM_PL_FLAG_WC | - TTM_PL_FLAG_UNCACHED; - else - places[c].flags |= TTM_PL_FLAG_CACHED; c++; } @@ -179,7 +169,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].fpfn = 0; places[c].lpfn = 0; places[c].mem_type = AMDGPU_PL_GDS; - places[c].flags = TTM_PL_FLAG_UNCACHED; + places[c].flags = 0; c++; } @@ -187,7 +177,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].fpfn = 0; places[c].lpfn = 0; places[c].mem_type = AMDGPU_PL_GWS; - places[c].flags = TTM_PL_FLAG_UNCACHED; + places[c].flags = 0; c++; } @@ -195,7 +185,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].fpfn = 0; places[c].lpfn = 0; places[c].mem_type = AMDGPU_PL_OA; - places[c].flags = TTM_PL_FLAG_UNCACHED; + places[c].flags = 0; c++; } @@ -203,7 +193,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) places[c].fpfn = 0; places[c].lpfn = 0; places[c].mem_type = TTM_PL_SYSTEM; - places[c].flags = TTM_PL_MASK_CACHING; + places[c].flags = 0; c++; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 5b56a66063fd..8cdec58b9106 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -92,7 +92,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo, .fpfn = 0, .lpfn = 0, .mem_type = TTM_PL_SYSTEM, - .flags = TTM_PL_MASK_CACHING + .flags = 0 }; /* Don't handle scatter gather BOs */ @@ -538,19 +538,13 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object *bo, bool evict, placements.fpfn = 0; placements.lpfn = 0; placements.mem_type = TTM_PL_TT; - placements.flags = TTM_PL_MASK_CACH
[PATCH 6/8] drm/ttm: add caching state to ttm_bus_placement
And implement setting it up correctly in the drivers.
This allows getting rid of the placement flags for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 +++
drivers/gpu/drm/qxl/qxl_ttm.c | 2 ++
drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
include/drm/ttm/ttm_resource.h | 8 +---
7 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7f41a47e7353..5b56a66063fd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -769,6 +769,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
mem->bus.offset += adev->gmc.aper_base;
mem->bus.is_iomem = true;
+ mem->bus.caching = ttm_write_combined;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 62235926e077..79151b1c157c 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -961,6 +961,7 @@ static int bo_driver_io_mem_reserve(struct ttm_bo_device
*bdev,
case TTM_PL_VRAM:
mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm->vram_base;
mem->bus.is_iomem = true;
+ mem->bus.caching = ttm_write_combined;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1d4b16c0e353..8ed30f471ec7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1124,6 +1124,8 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct nvkm_device *device = nvxx_device(&drm->client.device);
struct nouveau_mem *mem = nouveau_mem(reg);
+ struct nvif_mmu *mmu = &drm->client.mmu;
+ const u8 type = mmu->type[drm->ttm.type_vram].type;
int ret;
mutex_lock(&drm->ttm.io_reserve_mutex);
@@ -1139,6 +1141,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
reg->bus.offset = (reg->start << PAGE_SHIFT) +
drm->agp.base;
reg->bus.is_iomem = !drm->agp.cma;
+ reg->bus.caching = ttm_write_combined;
}
#endif
if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 ||
@@ -1152,6 +1155,14 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
reg->bus.offset = (reg->start << PAGE_SHIFT) +
device->func->resource_addr(device, 1);
reg->bus.is_iomem = true;
+
+ /* Some BARs do not support being ioremapped WC */
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA &&
+ type & NVIF_MEM_UNCACHED)
+ reg->bus.caching = ttm_uncached;
+ else
+ reg->bus.caching = ttm_write_combined;
+
if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
union {
struct nv50_mem_map_v0 nv50;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index dcf4ac1480c7..e79d4df99790 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -83,11 +83,13 @@ int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
case TTM_PL_VRAM:
mem->bus.is_iomem = true;
mem->bus.offset = (mem->start << PAGE_SHIFT) + qdev->vram_base;
+ mem->bus.caching = ttm_cached;
break;
case TTM_PL_PRIV:
mem->bus.is_iomem = true;
mem->bus.offset = (mem->start << PAGE_SHIFT) +
qdev->surfaceram_base;
+ mem->bus.caching = ttm_cached;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 130a7cea35c3..9b53a1d80632 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -372,6 +372,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
mem->bus.offset = (mem->start << PAGE_SHIFT) +
rdev->mc.agp_base;
mem->bus.is_iomem = !rdev->ddev->agp->cant_use_aperture;
+ mem->bus.caching = ttm_write_combined;
}
#endif
[PATCH 7/8] drm/ttm: use caching instead of placement for ttm_io_prot
Instead of the placement flags use the caching of the bus
mapping or tt object for the page protection flags.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 23 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
include/drm/ttm/ttm_bo_driver.h | 6 --
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bdee4df1f3f2..0542097dc419 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -279,13 +279,11 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
for (i = 0; i < new_mem->num_pages; ++i) {
page = i * dir + add;
if (old_iomap == NULL) {
- pgprot_t prot = ttm_io_prot(old_mem->placement,
- PAGE_KERNEL);
+ pgprot_t prot = ttm_io_prot(bo, old_mem, PAGE_KERNEL);
ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
prot);
} else if (new_iomap == NULL) {
- pgprot_t prot = ttm_io_prot(new_mem->placement,
- PAGE_KERNEL);
+ pgprot_t prot = ttm_io_prot(bo, new_mem, PAGE_KERNEL);
ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
prot);
} else {
@@ -384,21 +382,28 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
return 0;
}
-pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
+pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource *res,
+pgprot_t tmp)
{
+ struct ttm_resource_manager *man;
+ enum ttm_caching caching;
+
+ man = ttm_manager_type(bo->bdev, res->mem_type);
+ caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
+
/* Cached mappings need no adjustment */
- if (caching_flags & TTM_PL_FLAG_CACHED)
+ if (caching == ttm_cached)
return tmp;
#if defined(__i386__) || defined(__x86_64__)
- if (caching_flags & TTM_PL_FLAG_WC)
+ if (caching == ttm_write_combined)
tmp = pgprot_writecombine(tmp);
else if (boot_cpu_data.x86 > 3)
tmp = pgprot_noncached(tmp);
#endif
#if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \
defined(__powerpc__) || defined(__mips__)
- if (caching_flags & TTM_PL_FLAG_WC)
+ if (caching == ttm_write_combined)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
@@ -466,7 +471,7 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
* We need to use vmap to get the desired page protection
* or to make the buffer object look contiguous.
*/
- prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
map->bo_kmap_type = ttm_bo_map_vmap;
map->virtual = vmap(ttm->pages + start_page, num_pages,
0, prot);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 87ee8f0ca08e..eeaca5d1efe3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -310,7 +310,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
if (unlikely(page_offset >= bo->num_pages))
return VM_FAULT_SIGBUS;
- prot = ttm_io_prot(bo->mem.placement, prot);
+ prot = ttm_io_prot(bo, &bo->mem, prot);
if (!bo->mem.bus.is_iomem) {
struct ttm_operation_ctx ctx = {
.interruptible = false,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index ea2f2f937eb3..f21881e087db 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -484,8 +484,8 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
d.src_pages = src->ttm->pages;
d.dst_num_pages = dst->num_pages;
d.src_num_pages = src->num_pages;
- d.dst_prot = ttm_io_prot(dst->mem.placement, PAGE_KERNEL);
- d.src_prot = ttm_io_prot(src->mem.placement, PAGE_KERNEL);
+ d.dst_prot = ttm_io_prot(dst, &dst->mem, PAGE_KERNEL);
+ d.src_prot = ttm_io_prot(src, &src->mem, PAGE_KERNEL);
d.diff = diff;
for (j = 0; j < h; ++j) {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 9897a16c0a9d..a028b418c6b4 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -666,13 +666,15 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo);
/**
* ttm_io_prot
*
- *
[PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
Remove unused parameters, shorten the function name.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 912c30dcc9db..111031cbb6df 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -467,11 +467,11 @@ static int ttm_set_pages_caching(struct page **pages,
* any pages that have changed their caching state already put them to the
* pool.
*/
-static void ttm_handle_caching_state_failure(struct list_head *pages,
- int ttm_flags, enum ttm_caching_state cstate,
- struct page **failed_pages, unsigned cpages)
+static void ttm_handle_caching_failure(struct page **failed_pages,
+ unsigned cpages)
{
unsigned i;
+
/* Failed pages have to be freed */
for (i = 0; i < cpages; ++i) {
list_del(&failed_pages[i]->lru);
@@ -517,9 +517,8 @@ static int ttm_alloc_new_pages(struct list_head *pages,
gfp_t gfp_flags,
r = ttm_set_pages_caching(caching_array,
cstate, cpages);
if (r)
- ttm_handle_caching_state_failure(pages,
- ttm_flags, cstate,
- caching_array, cpages);
+
ttm_handle_caching_failure(caching_array,
+ cpages);
}
r = -ENOMEM;
goto out;
@@ -542,9 +541,8 @@ static int ttm_alloc_new_pages(struct list_head *pages,
gfp_t gfp_flags,
r = ttm_set_pages_caching(caching_array,
cstate, cpages);
if (r) {
- ttm_handle_caching_state_failure(pages,
- ttm_flags, cstate,
- caching_array, cpages);
+
ttm_handle_caching_failure(caching_array,
+ cpages);
goto out;
}
cpages = 0;
@@ -555,9 +553,7 @@ static int ttm_alloc_new_pages(struct list_head *pages,
gfp_t gfp_flags,
if (cpages) {
r = ttm_set_pages_caching(caching_array, cstate, cpages);
if (r)
- ttm_handle_caching_state_failure(pages,
- ttm_flags, cstate,
- caching_array, cpages);
+ ttm_handle_caching_failure(caching_array, cpages);
}
out:
kfree(caching_array);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE
Not used any more. Signed-off-by: Christian König --- include/drm/ttm/ttm_tt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 91691240a509..5d1835d44084 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -34,7 +34,6 @@ struct ttm_resource; struct ttm_buffer_object; struct ttm_operation_ctx; -#define TTM_PAGE_FLAG_WRITE (1 << 3) #define TTM_PAGE_FLAG_SWAPPED (1 << 4) #define TTM_PAGE_FLAG_ZERO_ALLOC (1 << 6) #define TTM_PAGE_FLAG_DMA32 (1 << 7) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/ttm: rename TTM caching enum
Cleanup the enum name and its values and give it a separate header file.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 +++---
drivers/gpu/drm/ttm/ttm_tt.c | 17 ++--
include/drm/ttm/ttm_caching.h| 34
include/drm/ttm/ttm_tt.h | 9 ++-
8 files changed, 70 insertions(+), 42 deletions(-)
create mode 100644 include/drm/ttm/ttm_caching.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 213ef090bb0e..3c5ad69eff19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_dma_tt *ttm;
- if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
+ if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 399961035ae6..2af24cf39e94 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1525,7 +1525,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm,
struct ttm_resource *mem)
if (mem && mem->mem_type == TTM_PL_TT) {
flags |= AMDGPU_PTE_SYSTEM;
- if (ttm->caching_state == tt_cached)
+ if (ttm->caching == ttm_cached)
flags |= AMDGPU_PTE_SNOOPED;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 63e38b05a5bc..f01e74113f40 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -546,7 +546,7 @@ static int radeon_ttm_backend_bind(struct ttm_bo_device
*bdev,
WARN(1, "nothing to bind %lu pages for mreg %p back %p!\n",
ttm->num_pages, bo_mem, ttm);
}
- if (ttm->caching_state == tt_cached)
+ if (ttm->caching == ttm_cached)
flags |= RADEON_GART_PAGE_SNOOP;
r = radeon_gart_bind(rdev, gtt->offset, ttm->num_pages,
ttm->pages, gtt->ttm.dma_address, flags);
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 111031cbb6df..c8f6790962b9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -220,14 +220,14 @@ static struct ttm_pool_manager *_manager;
/**
* Select the right pool or requested caching state and ttm flags. */
static struct ttm_page_pool *ttm_get_pool(int flags, bool huge,
- enum ttm_caching_state cstate)
+ enum ttm_caching cstate)
{
int pool_index;
- if (cstate == tt_cached)
+ if (cstate == ttm_cached)
return NULL;
- if (cstate == tt_wc)
+ if (cstate == ttm_write_combined)
pool_index = 0x0;
else
pool_index = 0x1;
@@ -441,17 +441,17 @@ static void ttm_pool_mm_shrink_fini(struct
ttm_pool_manager *manager)
}
static int ttm_set_pages_caching(struct page **pages,
- enum ttm_caching_state cstate, unsigned cpages)
+ enum ttm_caching cstate, unsigned cpages)
{
int r = 0;
/* Set page caching */
switch (cstate) {
- case tt_uncached:
+ case ttm_uncached:
r = ttm_set_pages_array_uc(pages, cpages);
if (r)
pr_err("Failed to set %d pages to uc!\n", cpages);
break;
- case tt_wc:
+ case ttm_write_combined:
r = ttm_set_pages_array_wc(pages, cpages);
if (r)
pr_err("Failed to set %d pages to wc!\n", cpages);
@@ -486,7 +486,7 @@ static void ttm_handle_caching_failure(struct page
**failed_pages,
* pages returned in pages array.
*/
static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
- int ttm_flags, enum ttm_caching_state cstate,
+ int ttm_flags, enum ttm_caching cstate,
unsigned count, unsigned order)
{
struct page **caching_array;
@@ -566,7 +566,7 @@ static int ttm_alloc_new_pages(struct list_head *pages,
gfp_t gfp_flags,
* pages is small.
*/
static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, int
ttm_flags,
- enum ttm_caching_state cstate,
+
[PATCH 5/8] drm/ttm: set the tt caching state at creation time
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 -
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 14 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 16 +---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
include/drm/ttm/ttm_tt.h | 7 ---
9 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 2af24cf39e94..7f41a47e7353 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
struct amdgpu_ttm_tt *gtt;
+ enum ttm_caching caching;
gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
if (gtt == NULL) {
@@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_buffer_object *bo,
}
gtt->gobj = &bo->base;
+ if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
+ caching = ttm_write_combined;
+ else
+ caching = ttm_cached;
+
/* allocate space for the uninitialized page entries */
- if (ttm_sg_tt_init(>t->ttm, bo, page_flags)) {
+ if (ttm_sg_tt_init(>t->ttm, bo, page_flags, caching)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3fe4b326e18e..62235926e077 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -910,7 +910,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
ttm_buffer_object *bo,
if (!tt)
return NULL;
- ret = ttm_tt_init(tt, bo, page_flags);
+ ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
if (ret < 0)
goto err_ttm_tt_init;
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 806d9ec310f5..cd6fdebae795 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -5,6 +5,7 @@
#include "nouveau_drv.h"
#include "nouveau_mem.h"
#include "nouveau_ttm.h"
+#include "nouveau_bo.h"
struct nouveau_sgdma_be {
/* this has to be the first field so populate/unpopulated in
@@ -67,13 +68,23 @@ nouveau_sgdma_unbind(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct ttm_tt *
nouveau_sgdma_create_ttm(struct ttm_buffer_object *bo, uint32_t page_flags)
{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_sgdma_be *nvbe;
+ enum ttm_caching caching;
+
+ if (nvbo->force_coherent)
+ caching = ttm_uncached;
+ else if (drm->agp.bridge)
+ caching = ttm_write_combined;
+ else
+ caching = ttm_cached;
nvbe = kzalloc(sizeof(*nvbe), GFP_KERNEL);
if (!nvbe)
return NULL;
- if (ttm_dma_tt_init(&nvbe->ttm, bo, page_flags)) {
+ if (ttm_dma_tt_init(&nvbe->ttm, bo, page_flags, caching)) {
kfree(nvbe);
return NULL;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 2c35ca4270c6..dcf4ac1480c7 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -146,7 +146,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
ttm_buffer_object *bo,
if (gtt == NULL)
return NULL;
gtt->qdev = qdev;
- if (ttm_tt_init(>t->ttm, bo, page_flags)) {
+ if (ttm_tt_init(>t->ttm, bo, page_flags, ttm_cached)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f01e74113f40..130a7cea35c3 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -590,6 +590,10 @@ static struct ttm_tt *radeon_ttm_tt_create(struct
ttm_buffer_object *bo,
{
struct radeon_device *rdev;
struct radeon_ttm_tt *gtt;
+ enum ttm_caching caching;
+ struct radeon_bo *rbo;
+
+ rbo = container_of(bo, struct radeon_bo, tbo);
rdev = radeon_get_rdev(bo->bdev);
#if IS_ENABLED(CONFIG_AGP)
@@ -603,7 +607,15 @@ static struct ttm_tt *radeon_ttm_tt_create(struct
ttm_buff
Re: [PATCH -next] drm/panfrost: simplify the return expression of panfrost_devfreq_target()
On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote:
>
> On 21/09/2020 14:10, Qinglang Miao wrote:
> > Simplify the return expression.
> >
> > Signed-off-by: Qinglang Miao
>
> Reviewed-by: Steven Price
As committer/maintainer for this please indicate whether you'll merge
this or not, with just an r-b patches are in an awkward limbo state.
Since Qinglang isn't committer you probably want to merge their
patches, for otherwise they get lost.
-Daniel
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 +--
> > 1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > index 8ab025d00..913eaa6d0 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > @@ -29,18 +29,13 @@ static int panfrost_devfreq_target(struct device *dev,
> > unsigned long *freq,
> > u32 flags)
> > {
> > struct dev_pm_opp *opp;
> > - int err;
> >
> > opp = devfreq_recommended_opp(dev, freq, flags);
> > if (IS_ERR(opp))
> > return PTR_ERR(opp);
> > dev_pm_opp_put(opp);
> >
> > - err = dev_pm_opp_set_rate(dev, *freq);
> > - if (err)
> > - return err;
> > -
> > - return 0;
> > + return dev_pm_opp_set_rate(dev, *freq);
> > }
> >
> > static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq)
> >
>
--
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 -next] drm/panfrost: simplify the return expression of panfrost_devfreq_target()
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 8ab025d00..913eaa6d0 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -29,18 +29,13 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
u32 flags)
{
struct dev_pm_opp *opp;
- int err;
opp = devfreq_recommended_opp(dev, freq, flags);
if (IS_ERR(opp))
return PTR_ERR(opp);
dev_pm_opp_put(opp);
- err = dev_pm_opp_set_rate(dev, *freq);
- if (err)
- return err;
-
- return 0;
+ return dev_pm_opp_set_rate(dev, *freq);
}
static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/panfrost: simplify the return expression of cz_ih_hw_init()
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index e68967338..ea8d31863 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -18,19 +18,13 @@
static int panfrost_reset_init(struct panfrost_device *pfdev)
{
- int err;
-
pfdev->rstc = devm_reset_control_array_get(pfdev->dev, false, true);
if (IS_ERR(pfdev->rstc)) {
dev_err(pfdev->dev, "get reset failed %ld\n",
PTR_ERR(pfdev->rstc));
return PTR_ERR(pfdev->rstc);
}
- err = reset_control_deassert(pfdev->rstc);
- if (err)
- return err;
-
- return 0;
+ return reset_control_deassert(pfdev->rstc);
}
static void panfrost_reset_fini(struct panfrost_device *pfdev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: bridge: cdns-mhdp8546: fix compile warning
On Thu, Oct 01, 2020 at 12:57:46PM +0300, Tomi Valkeinen wrote:
> Hi Dave,
>
> Can you pick this up to drm-next? Fixes the x64 build warnings for the recent
> cdns-mhdp-5.10 pull.
Applied, hopefully that's fast enough before sfr does the next round of
linux-next.
-Daniel
>
> Tomi
>
> On 29/09/2020 12:19, Tomi Valkeinen wrote:
> > On x64 we get:
> >
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> > conversion from 'long unsigned int' to 'unsigned int' changes value from
> > '18446744073709551613' to '4294967293' [-Woverflow]
> >
> > The registers are 32 bit, so fix by casting to u32.
> >
> > Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP
> > bridge")
> > Signed-off-by: Tomi Valkeinen
> > Reported-by: Stephen Rothwell
> > Reviewed-by: Swapnil Jakhade
> > Acked-by: Laurent Pinchart
> > ---
> >
> > v2:
> >
> > No changes to code, added tags.
> >
> >
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > index 621ebdbff8a3..d0c65610ebb5 100644
> > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > @@ -748,7 +748,7 @@ static int cdns_mhdp_fw_activate(const struct firmware
> > *fw,
> > * bridge should already be detached.
> > */
> > if (mhdp->bridge_attached)
> > - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> > + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> >mhdp->regs + CDNS_APB_INT_MASK);
> >
> > spin_unlock(&mhdp->start_lock);
> > @@ -1689,7 +1689,7 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
> >
> > /* Enable SW event interrupts */
> > if (hw_ready)
> > - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> > + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> >mhdp->regs + CDNS_APB_INT_MASK);
> >
> > return 0;
> > @@ -2122,7 +2122,7 @@ static void cdns_mhdp_bridge_hpd_enable(struct
> > drm_bridge *bridge)
> >
> > /* Enable SW event interrupts */
> > if (mhdp->bridge_attached)
> > - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> > + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
> >mhdp->regs + CDNS_APB_INT_MASK);
> > }
> >
> >
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> ___
> 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
linux-next: manual merge of the akpm tree with the drm-intel tree
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_pages.c
between commit:
4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is
not supported")
from the drm-intel tree and patch:
"drm/i915: use vmap in i915_gem_object_map"
from the akpm tree.
I fixed it up (I just dropped the changes in the former commits) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpGVfRpJKhGZ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the drm tree
Hi all,
On Wed, 23 Sep 2020 13:36:01 +1000 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_fw_activate':
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> conversion from 'long unsigned int' to 'unsigned int' changes value from
> '18446744073709551613' to '4294967293' [-Woverflow]
> 751 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_attach':
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1692:10: warning:
> conversion from 'long unsigned int' to 'unsigned int' changes value from
> '18446744073709551613' to '4294967293' [-Woverflow]
> 1692 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_bridge_hpd_enable':
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:2125:10: warning:
> conversion from 'long unsigned int' to 'unsigned int' changes value from
> '18446744073709551613' to '4294967293' [-Woverflow]
> 2125 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
>
> Introduced by commit
>
> fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
I am still getting these warnings ...
--
Cheers,
Stephen Rothwell
pgp1H44JiSv5r.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix regression in ttm moves
I don't see the patch, can you point me to it?
Thanks,
Christian.
Am 01.10.20 um 07:25 schrieb Dave Airlie:
Tracked it down to my init mem type changes, patch is on the list.
Dave.
On Wed, 30 Sep 2020 at 18:28, Christian König wrote:
That sounds like the same problem I've got when drm-next was merged into
drm-misc-next.
I've fixed it in this commit:
commit 0b06286579b81449b1e8f14f88d3a8db091fd443
Author: Christian König
Date: Wed Aug 19 15:27:48 2020 +0200
drm/ttm: fix broken merge between drm-next and drm-misc-next
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
Reviewed-by: Dave Airlie
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F386628%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C9f3aa2353f0441ccefa408d865ca66e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637371267277998534&sdata=43ZGNw5IrGmbMsVzm75WXk%2Bp55CIK0Lj%2BVXFCZRSqxE%3D&reserved=0
Not sure why it should cause problems with drm-fixes and drm-next as well.
Regards,
Christian.
Am 30.09.20 um 09:09 schrieb Dave Airlie:
just FYI I'm seeing a regression on vmwgfx with drm-fixes and drm-next
merged into it.
I'm going take some time to dig through and work out where, the
regression is a command failure and a ioremap failure.
Dave.
On Wed, 30 Sep 2020 at 16:26, Dave Airlie wrote:
Uggh this is part of the mess with the revert, I'm not sure how best
to dig out of this one yet.
Dave.
On Wed, 30 Sep 2020 at 15:55, Dave Airlie wrote:
From: Dave Airlie
This fixes a bug introduced in be1213a341a289afc51f89181c310e368fba0b66
drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2
On vmwgfx this causes a Command buffer error WARN to trigger.
This is because the old code used to check if bo->ttm was true,
and the new code doesn't, fix it code to add back the check resolves
the issue.
Fixes: be1213a341a2 ("drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 70b3bee27850..e8aa2fe8e9d1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -251,9 +251,11 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
/* Zero init the new TTM structure if the old location should
* have used one as well.
*/
- ret = ttm_tt_create(bo, old_man->use_tt);
- if (ret)
- goto out_err;
+ if (!bo->ttm) {
+ ret = ttm_tt_create(bo, old_man->use_tt);
+ if (ret)
+ goto out_err;
+ }
ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
if (ret)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C9f3aa2353f0441ccefa408d865ca66e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637371267277998534&sdata=Epqzw7O0bZ6G3JjXRdc2KtSug3JVucUbvlhJLtDMkzA%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3 v3] backlight: Add Kinetic KTD253 backlight driver
On Wed, 30 Sep 2020, Linus Walleij wrote: > On Fri, Aug 28, 2020 at 12:47 PM Lee Jones wrote: > > > > create mode 100644 drivers/video/backlight/ktd253-backlight.c > > > > Applied, thanks. > > Not to unnecessarily nag but I can't see this in linux-next and since we > are at -rc7 it makes me a bit nervous, is it still gonna be in v5.10? Heh, you're right. Apologies, tested and pushed now. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Add and export function drm_gem_cma_create_noalloc
On Wed, Sep 30, 2020 at 07:16:42PM +0200, Paul Cercueil wrote:
> Add and export the function drm_gem_cma_create_noalloc(), which is just
> __drm_gem_cma_create() renamed.
>
> This function can be used by drivers that need to create a GEM object
> without allocating the backing memory.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 11 ++-
> include/drm/drm_gem_cma_helper.h | 3 +++
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 59b9ca207b42..6abc4b306832 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -34,7 +34,7 @@
> */
>
> /**
> - * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
> + * drm_gem_cma_create_noalloc - Create a GEM CMA object without allocating
> memory
> * @drm: DRM device
> * @size: size of the object to allocate
> *
> @@ -45,8 +45,8 @@
> * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative
> * error code on failure.
> */
> -static struct drm_gem_cma_object *
> -__drm_gem_cma_create(struct drm_device *drm, size_t size)
> +struct drm_gem_cma_object *
> +drm_gem_cma_create_noalloc(struct drm_device *drm, size_t size)
> {
> struct drm_gem_cma_object *cma_obj;
> struct drm_gem_object *gem_obj;
> @@ -76,6 +76,7 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
> kfree(cma_obj);
> return ERR_PTR(ret);
> }
> +EXPORT_SYMBOL_GPL(drm_gem_cma_create_noalloc);
This feels a bit awkward, since for drivers who want to roll their own we
can do that already.
I think the better approach is to export a cma function which allocates
non-coherent dma memory.
-Daniel
>
> /**
> * drm_gem_cma_create - allocate an object with the given size
> @@ -98,7 +99,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
>
> size = round_up(size, PAGE_SIZE);
>
> - cma_obj = __drm_gem_cma_create(drm, size);
> + cma_obj = drm_gem_cma_create_noalloc(drm, size);
> if (IS_ERR(cma_obj))
> return cma_obj;
>
> @@ -476,7 +477,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
> return ERR_PTR(-EINVAL);
>
> /* Create a CMA GEM buffer. */
> - cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
> + cma_obj = drm_gem_cma_create_noalloc(dev, attach->dmabuf->size);
> if (IS_ERR(cma_obj))
> return ERR_CAST(cma_obj);
>
> diff --git a/include/drm/drm_gem_cma_helper.h
> b/include/drm/drm_gem_cma_helper.h
> index 2bfa2502607a..be2b8e3a8ab2 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -83,6 +83,9 @@ int drm_gem_cma_mmap(struct file *filp, struct
> vm_area_struct *vma);
> struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> size_t size);
>
> +struct drm_gem_cma_object *
> +drm_gem_cma_create_noalloc(struct drm_device *drm, size_t size);
> +
> extern const struct vm_operations_struct drm_gem_cma_vm_ops;
>
> #ifndef CONFIG_MMU
> --
> 2.28.0
>
> ___
> 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 0/4] Add a RPMsg driver to support AI Processing Unit (APU)
On Wed, Sep 30, 2020 at 01:53:46PM +0200, Alexandre Bailon wrote: > This adds a RPMsg driver that implements communication between the CPU and an > APU. > This uses VirtIO buffer to exchange messages but for sharing data, this uses > a dmabuf, mapped to be shared between CPU (userspace) and APU. > The driver is relatively generic, and should work with any SoC implementing > hardware accelerator for AI if they use support remoteproc and VirtIO. > > For the people interested by the firmware or userspace library, > the sources are available here: > https://github.com/BayLibre/open-amp/tree/v2020.01-mtk/apps/examples/apu Since this has open userspace (from a very cursory look), and smells very much like an acceleration driver, and seems to use dma-buf for memory management: Why is this not just a drm driver? -Daniel > > Alexandre Bailon (3): > Add a RPMSG driver for the APU in the mt8183 > rpmsg: apu_rpmsg: update the way to store IOMMU mapping > rpmsg: apu_rpmsg: Add an IOCTL to request IOMMU mapping > > Julien STEPHAN (1): > rpmsg: apu_rpmsg: Add support for async apu request > > drivers/rpmsg/Kconfig | 9 + > drivers/rpmsg/Makefile | 1 + > drivers/rpmsg/apu_rpmsg.c | 752 + > drivers/rpmsg/apu_rpmsg.h | 52 +++ > include/uapi/linux/apu_rpmsg.h | 47 +++ > 5 files changed, 861 insertions(+) > create mode 100644 drivers/rpmsg/apu_rpmsg.c > create mode 100644 drivers/rpmsg/apu_rpmsg.h > create mode 100644 include/uapi/linux/apu_rpmsg.h > > -- > 2.26.2 > > ___ > 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: [PATCH 1/2] drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active
On Thu, Sep 24, 2020 at 05:08:56PM +0900, Hoegeun Kwon wrote: > Hi Maxime, > > On 9/18/20 11:59 PM, Maxime Ripard wrote: > > The HVS has three FIFOs that can be assigned to a number of PixelValves > > through a mux. > > > > However, changing that FIFO requires that we disable and then enable the > > pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not > > just the active ones. > > Thanks for the patch. > > There is a problem when doing page flip. > After connecting 2 HDMIs without hotplug and booting.(Same thing when > using hotplug.) > > When executing page flip for each of HDMI 0 and 1 in modetest > operation does not work normally. (crtc irq does not occur, so timeout > occurs.) > Sometimes both hdmi 0 or 1 work or not. > > LOGs: > root:~> modetest -Mvc4 -s 32:1280x720 -v > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > failed to set gamma: Invalid argument > freq: 60.24Hz > freq: 60.00Hz > > root:~> modetest -Mvc4 -s 38:1280x720 -v > setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69 > failed to set gamma: Invalid argument > select timed out or error (ret 0) > select timed out or error (ret 0) > > Could you please check it? I'll look into it, thanks :) Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm: bump up the uapi version
Increase the minor version to indicate the presence of new features.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 305db1db1064..502aafe7d1e6 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -38,9 +38,10 @@
* GEM object's debug name
* - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
* - 1.6.0 - Syncobj support
+ * - 1.7.0 - MSM_BO_CACHED_COHERENT and DRM_IOCTL_MSM_GEM_SYNC_CACHE
*/
#define MSM_VERSION_MAJOR 1
-#define MSM_VERSION_MINOR 6
+#define MSM_VERSION_MINOR 7
#define MSM_VERSION_PATCHLEVEL 0
static const struct drm_mode_config_funcs mode_config_funcs = {
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: add voltage corners voting support base on dp link rate
Quoting Kuogee Hsieh (2020-09-29 10:10:26)
> Set link rate by using OPP set rate api so that CX level will be set
> accordingly base on the link rate.
s/base/based/
>
> Signed-off-by: Kuogee Hsieh
> ---
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 2e3e1917351f..e1595d829e04 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1849,6 +1853,21 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
> dp_link *link,
> return ERR_PTR(-ENOMEM);
> }
>
> + ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
> +
> + if (IS_ERR(ctrl->opp_table)) {
> + dev_err(dev, "invalid DP OPP table in device tree\n");
> + ctrl->opp_table = NULL;
> + } else {
> + /* OPP table is optional */
> + ret = dev_pm_opp_of_add_table(dev);
> + if (ret && ret != -ENODEV) {
> + dev_err(dev, "add DP OPP table\n");
This is debug noise right?
> + dev_pm_opp_put_clkname(ctrl->opp_table);
> + ctrl->opp_table = NULL;
> + }
> + }
> +
> init_completion(&ctrl->idle_comp);
> init_completion(&ctrl->video_comp);
>
> @@ -1864,6 +1883,18 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
> dp_link *link,
> return &ctrl->dp_ctrl;
> }
>
> -void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
> +void dp_ctrl_put(struct device *dev, struct dp_ctrl *dp_ctrl)
> {
> + struct dp_ctrl_private *ctrl;
> +
> + if (!dp_ctrl)
Can this happen?
> + return;
> +
> + ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
> +
> + if (ctrl->opp_table != NULL) {
This is usually written as
if (ctrl->opp_table)
> + dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_clkname(ctrl->opp_table);
> + ctrl->opp_table = NULL;
> + }
> }
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h
> b/drivers/gpu/drm/msm/dp/dp_ctrl.h
> index f60ba93c8678..19b412a93e02 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
> @@ -31,6 +31,6 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
> dp_link *link,
> struct dp_panel *panel, struct drm_dp_aux *aux,
> struct dp_power *power, struct dp_catalog *catalog,
> struct dp_parser *parser);
> -void dp_ctrl_put(struct dp_ctrl *dp_ctrl);
> +void dp_ctrl_put(struct device *dev, struct dp_ctrl *dp_ctrl);
Is 'dev' not inside 'dp_ctrl'?
>
> #endif /* _DP_CTRL_H_ */
> diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
> b/drivers/gpu/drm/msm/dp/dp_power.c
> index 17c1fc6a2d44..3d75bf09e38f 100644
> --- a/drivers/gpu/drm/msm/dp/dp_power.c
> +++ b/drivers/gpu/drm/msm/dp/dp_power.c
> @@ -8,12 +8,14 @@
> #include
> #include
> #include
> +#include
> #include "dp_power.h"
> #include "msm_drv.h"
>
> struct dp_power_private {
> struct dp_parser *parser;
> struct platform_device *pdev;
> + struct device *dev;
> struct clk *link_clk_src;
> struct clk *pixel_provider;
> struct clk *link_provider;
> @@ -148,18 +150,49 @@ static int dp_power_clk_deinit(struct dp_power_private
> *power)
> return 0;
> }
>
> +static int dp_power_clk_set_link_rate(struct dp_power_private *power,
> + struct dss_clk *clk_arry, int num_clk, int enable)
> +{
> + u32 rate;
> + int i, rc = 0;
> +
> + for (i = 0; i < num_clk; i++) {
> + if (clk_arry[i].clk) {
> + if (clk_arry[i].type == DSS_CLK_PCLK) {
> + if (enable)
> + rate = clk_arry[i].rate;
> + else
> + rate = 0;
> +
> + rc = dev_pm_opp_set_rate(power->dev, rate);
Why do we keep going if rc is non-zero?
> + }
> +
> + }
> + }
> + return rc;
> +}
> +
> static int dp_power_clk_set_rate(struct dp_power_private *power,
> enum dp_pm_type module, bool enable)
> {
> int rc = 0;
> struct dss_module_power *mp = &power->parser->mp[module];
>
> - if (enable) {
> - rc = msm_dss_clk_set_rate(mp->clk_config, mp->num_clk);
> + if (module == DP_CTRL_PM) {
> + rc = dp_power_clk_set_link_rate(power, mp->clk_config,
> mp->num_clk, enable);
> if (rc) {
> - DRM_ERROR("failed to set clks rate.\n");
> + DRM_ERROR("failed to set link clks rate.\n");
> return rc;
> }
> + } else {
> +
> + if (enable) {
> + rc = msm_dss_clk_set_rate(mp->clk_config,
> mp
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Stefan,
On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote:
> Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> >> Hi Nathan,
> >>
> >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more
> specific
> clock setup.
>
> Reviewed-by: Dave Stevenson
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
> >>> Apologies if this has already been reported or have a solution but this
> >>> patch (and presumably series) breaks output to the serial console after
> >>> a certain point during init. On Raspbian, I see systemd startup messages
> >>> then the output just turns into complete garbage. It looks like this
> >>> patch is merged first in linux-next, which is why my bisect fell on the
> >>> DRM merge. I am happy to provide whatever information could be helpful
> >>> for debugging this. I am on the latest version of the firmware
> >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241).
> >> Unfortunately, the miniUART is in the same clock tree than the core
> >> clock and will thus have those kind of issues when the core clock is
> >> changed (which is also something that one should expect when using the
> >> DRM or other drivers).
> >>
> >> The only real workaround there would be to switch to one of the PL011
> >> UARTs. I guess we can also somehow make the UART react to the core clock
> >> frequency changes, but that's going to require some effort
> >>
> >> Maxime
> > Ack, thank you for the reply! There does not really seem to be a whole
> > ton of documentation around using one of the other PL011 UARTs so for
> > now, I will just revert this commit locally.
>
> there was a patch series & discussion about this topic, but we finally
> didn't find a rock solid solution.
>
> You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier
> to follow clock changes" from 3.4.2019 on linux-rpi-kernel.
I couldn't find that discussion on the archive, but based on the title I
guess there's some patches that have been merged this cycle for the 8250
driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock
update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks
usage race condition")).
However, I'm not entirely sure the clock notifier works in our case with
the firmware / MMIO clocks duality
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 4/4] rpmsg: apu_rpmsg: Add an IOCTL to request IOMMU mapping
Currently, the kernel is automatically doing an IOMMU memory mapping.
But we want to do it automatically for two reasons:
- to reduce the overhead of each APU operation
- to get the device address and use it as input for an operation
This adds 2 IOCTL to manually IOMMU map and unmap memory.
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/apu_rpmsg.c | 52 ++
include/uapi/linux/apu_rpmsg.h | 7 +
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/rpmsg/apu_rpmsg.c b/drivers/rpmsg/apu_rpmsg.c
index 343bd08a859a..4c064feddf5a 100644
--- a/drivers/rpmsg/apu_rpmsg.c
+++ b/drivers/rpmsg/apu_rpmsg.c
@@ -114,7 +114,7 @@ static int apu_rpmsg_callback(struct rpmsg_device *rpdev,
void *data, int count,
}
static struct apu_buffer *apu_device_memory_map(struct rpmsg_apu *apu,
- uint32_t fd, struct rpmsg_request *rpmsg_req)
+ uint32_t fd)
{
struct rpmsg_device *rpdev = apu->rpdev;
struct apu_buffer *buffer;
@@ -129,10 +129,6 @@ static struct apu_buffer *apu_device_memory_map(struct
rpmsg_apu *apu,
list_for_each_entry(buffer, &apu->buffers, node) {
if (buffer->fd == fd) {
kref_get(&buffer->refcount);
- if (rpmsg_req)
- list_add(&buffer->req_node,
-&rpmsg_req->buffers);
-
return buffer;
}
}
@@ -230,6 +226,44 @@ static void apu_device_memory_unmap(struct kref *ref)
kfree(buffer);
}
+static int apu_iommu_mmap_ioctl(struct rpmsg_apu *apu, void __user *argp)
+{
+ struct apu_iommu_mmap apu_iommu_mmap;
+ struct apu_buffer *buffer;
+ int ret;
+
+ if (copy_from_user(&apu_iommu_mmap, argp, sizeof(apu_iommu_mmap)))
+ return -EFAULT;
+
+ buffer = apu_device_memory_map(apu, apu_iommu_mmap.fd);
+ if (!buffer)
+ return -ENOMEM;
+
+ apu_iommu_mmap.da = buffer->iova;
+ if (copy_to_user(argp, &apu_iommu_mmap, sizeof(apu_iommu_mmap)))
+ ret = -EFAULT;
+
+ return 0;
+}
+
+static int apu_iommu_munmap_ioctl(struct rpmsg_apu *apu, void __user *argp)
+{
+ u32 fd;
+ struct apu_buffer *buffer, *tmp;
+
+ if (copy_from_user(&fd, argp, sizeof(fd)))
+ return -EFAULT;
+
+ list_for_each_entry_safe(buffer, tmp, &apu->buffers, node) {
+ if (buffer->fd == fd) {
+ kref_put(&buffer->refcount, apu_device_memory_unmap);
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
static int apu_send_request(struct rpmsg_apu *apu,
struct apu_request *req)
{
@@ -266,7 +300,7 @@ static int apu_send_request(struct rpmsg_apu *apu,
INIT_LIST_HEAD(&rpmsg_req->buffers);
for (i = 0; i < req->count; i++) {
- buffer = apu_device_memory_map(apu, fd[i], rpmsg_req);
+ buffer = apu_device_memory_map(apu, fd[i]);
if (IS_ERR(buffer)) {
ret = PTR_ERR(buffer);
goto err_free_memory;
@@ -417,6 +451,12 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned
int cmd,
}
spin_unlock_irqrestore(&apu->ctx_lock, flags);
+ break;
+ case APU_IOMMU_MMAP:
+ ret = apu_iommu_mmap_ioctl(apu, argp);
+ break;
+ case APU_IOMMU_MUNMAP:
+ ret = apu_iommu_munmap_ioctl(apu, argp);
break;
default:
ret = -EINVAL;
diff --git a/include/uapi/linux/apu_rpmsg.h b/include/uapi/linux/apu_rpmsg.h
index f61207520254..e9b841dcbcb4 100644
--- a/include/uapi/linux/apu_rpmsg.h
+++ b/include/uapi/linux/apu_rpmsg.h
@@ -31,10 +31,17 @@ struct apu_request {
__u8 data[0];
};
+struct apu_iommu_mmap {
+ __u32 fd;
+ __u32 da;
+};
+
/* Send synchronous request to an APU */
#define APU_SEND_REQ_IOCTL _IOW(0xb7, 0x2, struct apu_request)
#define APU_GET_NEXT_AVAILABLE_IOCTL _IOR(0xb7, 0x3, __u16)
#define APU_GET_RESP _IOWR(0xb7, 0x4, struct apu_request)
+#define APU_IOMMU_MMAP _IOWR(0xb7, 0x5, struct apu_iommu_mmap)
+#define APU_IOMMU_MUNMAP _IOWR(0xb7, 0x6, __u32)
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
The fix of flagging state->modeset whenever distrust_bios_wm is set causes a regression when initializing display(s) attached to a Lenovo USB-C docking station. The display remains blank until the dock is reattached. Revert to bring the behavior of the functional v5.6 stable. This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442 Signed-off-by: Stefan Joosten --- drivers/gpu/drm/i915/display/intel_display.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index b18c5ac2934d..ece1c28278f7 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev, if (ret) goto fail; - /* -* distrust_bios_wm will force a full dbuf recomputation -* but the hardware state will only get updated accordingly -* if state->modeset==true. Hence distrust_bios_wm==true && -* state->modeset==false is an invalid combination which -* would cause the hardware and software dbuf state to get -* out of sync. We must prevent that. -* -* FIXME clean up this mess and introduce better -* state tracking for dbuf. -*/ - if (dev_priv->wm.distrust_bios_wm) - any_ms = true; - intel_fbc_choose_crtc(dev_priv, state); ret = calc_watermark_data(state); if (ret) -- 2.25.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
>
> On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> > > On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > > > On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > > > > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct
> > > > > ib_device *device,
> > > > > goto umem_release;
> > > > >
> > > > > cur_base += ret * PAGE_SIZE;
> > > > > - npages -= ret;
> > > > > -
> > > > > - sg = ib_umem_add_sg_table(sg, page_list, ret,
> > > > > - dma_get_max_seg_size(device->dma_device),
> > > > > - &umem->sg_nents);
> > > > > + npages -= ret;
> > > > > + sg = __sg_alloc_table_from_pages(
> > > > > + &umem->sg_head, page_list, ret, 0, ret <<
> > > > > PAGE_SHIFT,
> > > > > + dma_get_max_seg_size(device->dma_device), sg,
> > > > > npages,
> > > > > + GFP_KERNEL);
> > > > > + umem->sg_nents = umem->sg_head.nents;
> > > > > + if (IS_ERR(sg)) {
> > > > > + unpin_user_pages_dirty_lock(page_list, ret, 0);
> > > > > + ret = PTR_ERR(sg);
> > > > > + goto umem_release;
> > > > > + }
> > > > > }
> > > > >
> > > > > sg_mark_end(sg);
> > > > Does it still need the sg_mark_end?
> > > It is preserved here for correctness, the release logic doesn't rely on
> > > this marker, but it is better to leave it.
> > I mean, my read of __sg_alloc_table_from_pages() is that it already
> > placed it, the final __alloc_table() does it?
>
> It marks the last allocated sge, but not the last populated sge (with page).
Why are those different?
It looks like the last iteration calls __alloc_table() with an exact
number of sges
+ if (!prv) {
+ /* Only the last allocation could be less than the maximum */
+ table_size = left_pages ? SG_MAX_SINGLE_ALLOC : chunks;
+ ret = sg_alloc_table(sgt, table_size, gfp_mask);
+ if (unlikely(ret))
+ return ERR_PTR(ret);
+ }
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vc4: hdmi: Disable Wifi Frequencies
Hi Daniel, On Mon, Sep 28, 2020 at 11:02:11AM +0200, Daniel Vetter wrote: > On Mon, Sep 28, 2020 at 9:06 AM Maxime Ripard wrote: > > > > There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi > > chip and some resolutions, most notably 1440p at 60Hz. > > > > In such a case, we can either reject entirely the mode, or lower slightly > > the pixel frequency to remove the overlap. Let's go for the latter. > > > > Signed-off-by: Maxime Ripard > > --- > > .../bindings/display/brcm,bcm2711-hdmi.yaml| 6 ++ > > drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +- > > drivers/gpu/drm/vc4/vc4_hdmi.h | 8 > > 3 files changed, 27 insertions(+), 1 deletion(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > > b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > > index 03a76729d26c..63e7fe999c0a 100644 > > --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > > @@ -76,6 +76,12 @@ properties: > >resets: > > maxItems: 1 > > > > + raspberrypi,disable-wifi-frequencies: > > +type: boolean > > +description: > > > + Should the pixel frequencies in the WiFi frequencies range be > > + avoided? > > + > > required: > >- compatible > >- reg > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > > index acfb4e235214..74da7c00ecd0 100644 > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > > @@ -877,13 +877,22 @@ static int vc4_hdmi_encoder_atomic_check(struct > > drm_encoder *encoder, > > struct vc4_hdmi_connector_state *vc4_state = > > conn_state_to_vc4_hdmi_conn_state(conn_state); > > struct drm_display_mode *mode = &crtc_state->adjusted_mode; > > struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder); > > - unsigned long long pixel_rate = mode->clock * 1000; > > + unsigned long long pixel_rate; > > > > if (vc4_hdmi->variant->broken_odd_h_timings && > > ((mode->hdisplay % 2) || (mode->hsync_start % 2) || > > (mode->hsync_end % 2) || (mode->htotal % 2))) > > return -EINVAL; > > > > + /* > > +* The 1440p@60 pixel rate is in the same range than the WiFi > > +* channels. Slightly lower the frequency to bring it out of the > > +* WiFi range. > > +*/ > > + if (vc4_hdmi->disable_wifi_frequencies && mode->clock == 241500) > > + mode->clock = 238560; > > Don't you want to map for a (narrow) range of frequencies here? Just > for that infamous 60p vs 59.99p thing and similar. And I think that > would still be in that band you want to avoid. Testing for a range seems better indeed, I'll send a new version Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
which otherwise doesn't provide any method for cleaning/invalidating the
cache to sync with the device.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 21 +
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 15 +++
include/uapi/drm/msm_drm.h| 20
4 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9716210495fc..305db1db1064 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -964,6 +964,26 @@ static int msm_ioctl_submitqueue_close(struct drm_device
*dev, void *data,
return msm_submitqueue_remove(file->driver_priv, id);
}
+static int msm_ioctl_gem_sync_cache(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_msm_gem_sync_cache *args = data;
+ struct drm_gem_object *obj;
+
+ if (args->flags & ~MSM_GEM_SYNC_CACHE_FLAGS)
+ return -EINVAL;
+
+ obj = drm_gem_object_lookup(file, args->handle);
+ if (!obj)
+ return -ENOENT;
+
+ msm_gem_sync_cache(obj, args->flags, args->offset, args->end);
+
+ drm_gem_object_put(obj);
+
+ return 0;
+}
+
static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new,
DRM_RENDER_ALLOW),
@@ -976,6 +996,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MSM_GEM_SYNC_CACHE,msm_ioctl_gem_sync_cache,
DRM_RENDER_ALLOW),
};
static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 6384844b1696..5e932dae453f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -314,6 +314,8 @@ void msm_gem_move_to_active(struct drm_gem_object *obj,
void msm_gem_move_to_inactive(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end);
void msm_gem_free_object(struct drm_gem_object *obj);
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index ad9a627493ae..93da88b3fc50 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
@@ -808,6 +809,20 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj)
return 0;
}
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+ size_t range_start, size_t range_end)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+ /* TODO: sync only the required range, and don't invalidate on clean */
+
+ if (flags & MSM_GEM_SYNC_CACHE_CLEAN)
+ sync_for_device(msm_obj);
+
+ if (flags & MSM_GEM_SYNC_CACHE_INVALIDATE)
+ sync_for_cpu(msm_obj);
+}
+
#ifdef CONFIG_DEBUG_FS
static void describe_fence(struct dma_fence *fence, const char *type,
struct seq_file *m)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 474497e8743a..1dfafa71fc94 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -319,6 +319,24 @@ struct drm_msm_submitqueue_query {
__u32 pad;
};
+/*
+ * Host cache maintenance (relevant for MSM_BO_CACHED)
+ * driver may both clean/invalidate (flush) for clean
+ */
+
+#define MSM_GEM_SYNC_CACHE_CLEAN 0x1
+#define MSM_GEM_SYNC_CACHE_INVALIDATE 0x2
+
+#define MSM_GEM_SYNC_CACHE_FLAGS (MSM_GEM_SYNC_CACHE_CLEAN | \
+MSM_GEM_SYNC_CACHE_INVALIDATE)
+
+struct drm_msm_gem_sync_cache {
+ __u32 handle;
+ __u32 flags;
+ __u64 offset;
+ __u64 end; /* offset + size */
+};
+
#define DRM_MSM_GET_PARAM 0x00
/* placeholder:
#define DRM_MSM_SET_PARAM 0x01
@@ -336,6 +354,7 @@ struct drm_msm_submitqueue_query {
#define DRM_MSM_SUBMITQUEUE_NEW0x0A
#define DRM_MSM_SUBMITQUEUE_CLOSE 0x0B
#define DRM_MSM_SUBMITQUEUE_QUERY 0x0C
+#define DRM_MSM_GEM_SYNC_CACHE 0x0D
#define DRM_IOCTL_MSM_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE +
DRM_MSM_GET_
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
@@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
*device,
goto umem_release;
cur_base += ret * PAGE_SIZE;
- npages -= ret;
-
- sg = ib_umem_add_sg_table(sg, page_list, ret,
- dma_get_max_seg_size(device->dma_device),
- &umem->sg_nents);
+ npages -= ret;
+ sg = __sg_alloc_table_from_pages(
+ &umem->sg_head, page_list, ret, 0, ret << PAGE_SHIFT,
+ dma_get_max_seg_size(device->dma_device), sg, npages,
+ GFP_KERNEL);
+ umem->sg_nents = umem->sg_head.nents;
+ if (IS_ERR(sg)) {
+ unpin_user_pages_dirty_lock(page_list, ret, 0);
+ ret = PTR_ERR(sg);
+ goto umem_release;
+ }
}
sg_mark_end(sg);
Does it still need the sg_mark_end?
It is preserved here for correctness, the release logic doesn't rely on
this marker, but it is better to leave it.
I mean, my read of __sg_alloc_table_from_pages() is that it already
placed it, the final __alloc_table() does it?
Jason
It marks the last allocated sge, but not the last populated sge (with page).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct
> > > ib_device *device,
> > > goto umem_release;
> > >
> > > cur_base += ret * PAGE_SIZE;
> > > - npages -= ret;
> > > -
> > > - sg = ib_umem_add_sg_table(sg, page_list, ret,
> > > - dma_get_max_seg_size(device->dma_device),
> > > - &umem->sg_nents);
> > > + npages -= ret;
> > > + sg = __sg_alloc_table_from_pages(
> > > + &umem->sg_head, page_list, ret, 0, ret << PAGE_SHIFT,
> > > + dma_get_max_seg_size(device->dma_device), sg, npages,
> > > + GFP_KERNEL);
> > > + umem->sg_nents = umem->sg_head.nents;
> > > + if (IS_ERR(sg)) {
> > > + unpin_user_pages_dirty_lock(page_list, ret, 0);
> > > + ret = PTR_ERR(sg);
> > > + goto umem_release;
> > > + }
> > > }
> > >
> > > sg_mark_end(sg);
> >
> > Does it still need the sg_mark_end?
>
> It is preserved here for correctness, the release logic doesn't rely on
> this marker, but it is better to leave it.
I mean, my read of __sg_alloc_table_from_pages() is that it already
placed it, the final __alloc_table() does it?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/4] rpmsg: apu_rpmsg: Add support for async apu request
From: Julien STEPHAN
In order to improve performances and flexibility,
add support of async request.
Signed-off-by: Julien STEPHAN
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/apu_rpmsg.c | 208 ++---
include/uapi/linux/apu_rpmsg.h | 6 +-
2 files changed, 144 insertions(+), 70 deletions(-)
diff --git a/drivers/rpmsg/apu_rpmsg.c b/drivers/rpmsg/apu_rpmsg.c
index 5131b8b8e1f2..e14597c467d7 100644
--- a/drivers/rpmsg/apu_rpmsg.c
+++ b/drivers/rpmsg/apu_rpmsg.c
@@ -34,11 +34,16 @@ struct rpmsg_apu {
struct iommu_domain *domain;
struct iova_domain *iovad;
int iova_limit_pfn;
+ wait_queue_head_t waitqueue;
+ u8 available_response;
+ spinlock_t ctx_lock;
+ struct list_head requests;
};
struct rpmsg_request {
- struct completion completion;
+ u8 ready;
struct list_head node;
+ struct apu_buffer *buffer;
void *req;
};
@@ -68,25 +73,35 @@ static dev_t rpmsg_major;
static DEFINE_IDA(rpmsg_ctrl_ida);
static DEFINE_IDA(rpmsg_minor_ida);
static DEFINE_IDA(req_ida);
-static LIST_HEAD(requests);
static struct apu_iova_domain *apu_iovad;
-static int apu_rpmsg_callback(struct rpmsg_device *dev, void *data, int count,
+
+static int apu_rpmsg_callback(struct rpmsg_device *rpdev, void *data, int
count,
void *priv, u32 addr)
{
+ struct rpmsg_apu *apu = dev_get_drvdata(&rpdev->dev);
struct rpmsg_request *rpmsg_req;
struct apu_dev_request *hdr = data;
+ unsigned long flags;
- list_for_each_entry(rpmsg_req, &requests, node) {
- struct apu_dev_request *tmp_hdr = rpmsg_req->req;
+ spin_lock_irqsave(&apu->ctx_lock, flags);
+ list_for_each_entry(rpmsg_req, &apu->requests, node) {
+ struct apu_request *tmp_hdr = rpmsg_req->req;
if (hdr->id == tmp_hdr->id) {
- memcpy(rpmsg_req->req, data, count);
- complete(&rpmsg_req->completion);
-
- return 0;
+ rpmsg_req->ready = 1;
+ apu->available_response++;
+ tmp_hdr->result = hdr->result;
+ tmp_hdr->size_in = hdr->size_in;
+ tmp_hdr->size_out = hdr->size_out;
+ memcpy(tmp_hdr->data, hdr->data,
+ hdr->size_in+hdr->size_out);
+
+ wake_up_interruptible(&apu->waitqueue);
+ break;
}
}
+ spin_unlock_irqrestore(&apu->ctx_lock, flags);
return 0;
}
@@ -177,48 +192,6 @@ static void apu_device_memory_unmap(struct rpmsg_apu *apu,
dma_buf_put(buffer->dma_buf);
}
-static int _apu_send_request(struct rpmsg_apu *apu,
-struct rpmsg_device *rpdev,
-struct apu_dev_request *req, int len)
-{
-
- struct rpmsg_request *rpmsg_req;
- int ret = 0;
-
- req->id = ida_simple_get(&req_ida, 0, 0x, GFP_KERNEL);
- if (req->id < 0)
- return ret;
-
- rpmsg_req = kzalloc(sizeof(*rpmsg_req), GFP_KERNEL);
- if (!rpmsg_req)
- return -ENOMEM;
-
- rpmsg_req->req = req;
- init_completion(&rpmsg_req->completion);
- list_add(&rpmsg_req->node, &requests);
-
- ret = rpmsg_send(rpdev->ept, req, len);
- if (ret)
- goto free_req;
-
- /* be careful with race here between timeout and callback*/
- ret = wait_for_completion_timeout(&rpmsg_req->completion,
- msecs_to_jiffies(1000));
- if (!ret)
- ret = -ETIMEDOUT;
- else
- ret = 0;
-
- ida_simple_remove(&req_ida, req->id);
-
-free_req:
-
- list_del(&rpmsg_req->node);
- kfree(rpmsg_req);
-
- return ret;
-}
-
static int apu_send_request(struct rpmsg_apu *apu,
struct apu_request *req)
{
@@ -226,6 +199,8 @@ static int apu_send_request(struct rpmsg_apu *apu,
struct rpmsg_device *rpdev = apu->rpdev;
struct apu_dev_request *dev_req;
struct apu_buffer *buffer;
+ struct rpmsg_request *rpmsg_req;
+ unsigned long flags;
int size = req->size_in + req->size_out +
sizeof(u32) * req->count * 2 + sizeof(*dev_req);
@@ -257,24 +232,63 @@ static int apu_send_request(struct rpmsg_apu *apu,
dev_req_buffer_size[i] = buffer_size[i];
}
- ret = _apu_send_request(apu, rpdev, dev_req, size);
+ ret = ida_simple_get(&req_ida, 0, 0x, GFP_KERNEL);
+ if (ret < 0)
+ goto err_free_memory;
+
+ dev_req->id = ret;
+
+ rpmsg_req = kzalloc(sizeof(*rpmsg_req), GFP_KERNEL);
+ if (!rpmsg_req) {
+ ret = -ENOMEM;
+ goto err_ida_remove;
+ }
+ req->id = dev_req->id;
+
[PATCH 0/3] drm/msm: support for host-cached BOs
This is to support cached and cached-coherent memory types in vulkan. I made a corresponding WIP merge request [1] which shows usage of this. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6949 Jonathan Marek (3): drm/msm: add MSM_BO_CACHED_COHERENT drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance drm/msm: bump up the uapi version drivers/gpu/drm/msm/adreno/adreno_device.c | 1 + drivers/gpu/drm/msm/msm_drv.c | 24 - drivers/gpu/drm/msm/msm_drv.h | 3 +++ drivers/gpu/drm/msm/msm_gem.c | 23 include/uapi/drm/msm_drm.h | 25 +++--- 5 files changed, 72 insertions(+), 4 deletions(-) -- 2.26.1 ___ 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 tree
Le mer. 30 sept. 2020 à 18:11, Christoph Hellwig a écrit : On Wed, Sep 30, 2020 at 03:33:13PM +0200, Paul Cercueil wrote: One thing missing for remap_pfn_range(), I have no alternative for this: vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, DMA_ATTR_NON_CONSISTENT); So I have to do: vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK; pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT; And that will only compile on MIPS, because these _CACHE_* macros are only defined there. I would need something like a pgprot_noncoherent(), I think. dma_alloc_pages gives you cached memory, so you can't just use an uncached protection for the userspace mmap here. If you want uncached memory you need to use dma_alloc_coherent paired with dma_mmap_coherent. Or dma_alloc_wc for a slightly different flavor of uncached. (both of the map to dma_alloc_attrs / dma_mmap_attrs eventually). I don't want uncached memory, I want non-coherent cached memory. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/4] Add a RPMSG driver for the APU in the mt8183
This adds a driver to communicate with the APU available
in the mt8183. The driver is generic and could be used for other APU.
It mostly provides a userspace interface to send messages and
and share big buffers with the APU.
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/apu_rpmsg.c | 606 +
drivers/rpmsg/apu_rpmsg.h | 52 +++
include/uapi/linux/apu_rpmsg.h | 36 ++
5 files changed, 704 insertions(+)
create mode 100644 drivers/rpmsg/apu_rpmsg.c
create mode 100644 drivers/rpmsg/apu_rpmsg.h
create mode 100644 include/uapi/linux/apu_rpmsg.h
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f96716893c2a..3437c6fc8647 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -64,4 +64,13 @@ config RPMSG_VIRTIO
select RPMSG
select VIRTIO
+config RPMSG_APU
+ tristate "APU RPMSG driver"
+ help
+ This provides a RPMSG driver that provides some facilities to
+ communicate with an accelerated processing unit (APU).
+ This creates one or more char files that could be used by userspace
+ to send a message to an APU. In addition, this also take care of
+ sharing the memory buffer with the APU.
+
endmenu
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ffe932ef6050..93e0f3de99c9 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
obj-$(CONFIG_RPMSG_QCOM_GLINK_SMEM) += qcom_glink_smem.o
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
+obj-$(CONFIG_RPMSG_APU)+= apu_rpmsg.o
diff --git a/drivers/rpmsg/apu_rpmsg.c b/drivers/rpmsg/apu_rpmsg.c
new file mode 100644
index ..5131b8b8e1f2
--- /dev/null
+++ b/drivers/rpmsg/apu_rpmsg.c
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright 2020 BayLibre SAS
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rpmsg_internal.h"
+
+#include
+
+#include "apu_rpmsg.h"
+
+/* Maximum of APU devices supported */
+#define APU_DEV_MAX 2
+
+#define dev_to_apu(dev) container_of(dev, struct rpmsg_apu, dev)
+#define cdev_to_apu(i_cdev) container_of(i_cdev, struct rpmsg_apu, cdev)
+
+struct rpmsg_apu {
+ struct rpmsg_device *rpdev;
+ struct cdev cdev;
+ struct device dev;
+
+ struct rproc *rproc;
+ struct iommu_domain *domain;
+ struct iova_domain *iovad;
+ int iova_limit_pfn;
+};
+
+struct rpmsg_request {
+ struct completion completion;
+ struct list_head node;
+ void *req;
+};
+
+struct apu_buffer {
+ int fd;
+ struct dma_buf *dma_buf;
+ struct dma_buf_attachment *attachment;
+ struct sg_table *sg_table;
+ u32 iova;
+};
+
+/*
+ * Shared IOVA domain.
+ * The MT8183 has two VP6 core but they are sharing the IOVA.
+ * They could be used alone, or together. In order to avoid conflict,
+ * create an IOVA domain that could be shared by those two core.
+ * @iovad: The IOVA domain to share between the APU cores
+ * @refcount: Allow to automatically release the IOVA domain once all the APU
+ *cores has been stopped
+ */
+struct apu_iova_domain {
+ struct iova_domain iovad;
+ struct kref refcount;
+};
+
+static dev_t rpmsg_major;
+static DEFINE_IDA(rpmsg_ctrl_ida);
+static DEFINE_IDA(rpmsg_minor_ida);
+static DEFINE_IDA(req_ida);
+static LIST_HEAD(requests);
+static struct apu_iova_domain *apu_iovad;
+
+static int apu_rpmsg_callback(struct rpmsg_device *dev, void *data, int count,
+ void *priv, u32 addr)
+{
+ struct rpmsg_request *rpmsg_req;
+ struct apu_dev_request *hdr = data;
+
+ list_for_each_entry(rpmsg_req, &requests, node) {
+ struct apu_dev_request *tmp_hdr = rpmsg_req->req;
+
+ if (hdr->id == tmp_hdr->id) {
+ memcpy(rpmsg_req->req, data, count);
+ complete(&rpmsg_req->completion);
+
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
+static int apu_device_memory_map(struct rpmsg_apu *apu,
+struct apu_buffer *buffer)
+{
+ struct rpmsg_device *rpdev = apu->rpdev;
+ phys_addr_t phys;
+ int total_buf_space;
+ int iova_pfn;
+ int ret;
+
+ if (!buffer->fd)
+ return 0;
+
+ buffer->dma_buf = dma_buf_get(buffer->fd);
+ if (IS_ERR(buffer->dma_buf)) {
+ dev_err(&rpdev->dev, "Failed to get dma_buf from fd: %ld\n",
+ PTR_ERR(buffer->dma_buf));
+ return PTR_ERR(buffer->dma_buf);
+ }
+
+ buffer->attachment = dma_buf_attach(buffer->dma_buf, &rpdev->dev);
+ if (IS_ERR(buffer->attachment)) {
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On 9/30/2020 6:14 PM, Jason Gunthorpe wrote: On Wed, Sep 30, 2020 at 06:05:15PM +0300, Maor Gottlieb wrote: This is right only for the last iteration. E.g. in the first iteration in case that there are more pages (left_pages), then we allocate SG_MAX_SINGLE_ALLOC. We don't know how many pages from the second iteration will be squashed to the SGE from the first iteration. Well, it is 0 or 1 SGE's. Check if the first page is mergable and subtract one from the required length? I dislike this sg_mark_end() it is something that should be internal, IMHO. I can move it to __sg_alloc_table_from_pages: sgt->nents = tmp_nents; + if (!left_pages) + sg_mark_end(s); out: return s; Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/ingenic: Alloc cached GEM buffers with dma_alloc_noncoherent
It turns out that if you want to mmap GEM buffers fully cached, then
they should be allocated as such as well. Who would have known?
Introduce a custom .dumb_create callback, that will behave just like
drm_gem_cma_dumb_create(), except that it will allocate the GEM buffer
using dma_alloc_noncoherent() if non-coherent memory is what we want.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 48 ++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 07a1da7266e4..8ece269c040f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -794,6 +794,52 @@ static int ingenic_drm_gem_cma_mmap(struct file *filp,
return ingenic_drm_gem_mmap(vma->vm_private_data, vma);
}
+static int ingenic_drm_gem_cma_dumb_create(struct drm_file *file_priv,
+ struct drm_device *drm,
+ struct drm_mode_create_dumb *args)
+{
+ /*
+* This is basically a copy of drm_gem_cma_dumb_create, which supports
+* creating fully cached GEM buffers.
+*/
+ struct drm_gem_cma_object *cma_obj;
+ struct drm_gem_object *gem_obj;
+ size_t size;
+ int ret;
+
+ args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ args->size = args->pitch * args->height;
+
+ size = PAGE_ALIGN(args->size);
+
+ cma_obj = drm_gem_cma_create_noalloc(drm, size);
+ if (IS_ERR(cma_obj))
+ return PTR_ERR(cma_obj);
+
+ if (ingenic_drm_cached_gem_buf) {
+ cma_obj->vaddr = dma_alloc_noncoherent(drm->dev, size,
+ &cma_obj->paddr,
+ DMA_TO_DEVICE,
+ GFP_KERNEL |
__GFP_NOWARN);
+ } else {
+ cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
+ GFP_KERNEL | __GFP_NOWARN);
+ }
+ if (!cma_obj->vaddr) {
+ dev_err(drm->dev, "Failed to allocate buffer with size %zu\n",
size);
+ ret = -ENOMEM;
+ goto out_gem_object_put;
+ }
+
+ gem_obj = &cma_obj->base;
+
+ ret = drm_gem_handle_create(file_priv, gem_obj, &args->handle);
+
+out_gem_object_put:
+ drm_gem_object_put(gem_obj);
+ return ret;
+}
+
static const struct file_operations ingenic_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -816,7 +862,7 @@ static struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
.fops = &ingenic_drm_fops,
- DRM_GEM_CMA_DRIVER_OPS,
+
DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(ingenic_drm_gem_cma_dumb_create),
.irq_handler= ingenic_drm_irq_handler,
};
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells
While the signal on GPIO4 to drive the backlight controller indeed is pulse width modulated its purpose is specifically to control the brightness of a backlight. Drop the #pwm-cells and instead expose a new property to configure the granularity of the backlight PWM signal. Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index f8622bd0f61e..e380218b4646 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -66,9 +66,12 @@ properties: 1-based to match the datasheet. See ../../gpio/gpio.txt for more information. - '#pwm-cells': -const: 1 -description: See ../../pwm/pwm.yaml for description of the cell formats. + ti,backlight-scale: +description: + The granularity of brightness for the PWM signal provided on GPIO4, if + this property is specified. +minimum: 0 +maximum: 65535 ports: type: object -- 2.28.0 ___ 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 tree
Le mer. 30 sept. 2020 à 18:40, Christoph Hellwig a écrit : On Wed, Sep 30, 2020 at 06:39:18PM +0200, Paul Cercueil wrote: dma_alloc_pages gives you cached memory, so you can't just use an uncached protection for the userspace mmap here. If you want uncached memory you need to use dma_alloc_coherent paired with dma_mmap_coherent. Or dma_alloc_wc for a slightly different flavor of uncached. (both of the map to dma_alloc_attrs / dma_mmap_attrs eventually). I don't want uncached memory, I want non-coherent cached memory. We don't have such a thing in the Linux API at all. dma_pgprot(dev, vma->vm_page_prot, DMA_ATTR_NON_CONSISTENT); That was giving me non-coherent cached memory, and now I don't have an alternative. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/4] Add a RPMsg driver to support AI Processing Unit (APU)
This adds a RPMsg driver that implements communication between the CPU and an APU. This uses VirtIO buffer to exchange messages but for sharing data, this uses a dmabuf, mapped to be shared between CPU (userspace) and APU. The driver is relatively generic, and should work with any SoC implementing hardware accelerator for AI if they use support remoteproc and VirtIO. For the people interested by the firmware or userspace library, the sources are available here: https://github.com/BayLibre/open-amp/tree/v2020.01-mtk/apps/examples/apu Alexandre Bailon (3): Add a RPMSG driver for the APU in the mt8183 rpmsg: apu_rpmsg: update the way to store IOMMU mapping rpmsg: apu_rpmsg: Add an IOCTL to request IOMMU mapping Julien STEPHAN (1): rpmsg: apu_rpmsg: Add support for async apu request drivers/rpmsg/Kconfig | 9 + drivers/rpmsg/Makefile | 1 + drivers/rpmsg/apu_rpmsg.c | 752 + drivers/rpmsg/apu_rpmsg.h | 52 +++ include/uapi/linux/apu_rpmsg.h | 47 +++ 5 files changed, 861 insertions(+) create mode 100644 drivers/rpmsg/apu_rpmsg.c create mode 100644 drivers/rpmsg/apu_rpmsg.h create mode 100644 include/uapi/linux/apu_rpmsg.h -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells
On 9/30/20 5:35 PM, Bjorn Andersson wrote: > While the signal on GPIO4 to drive the backlight controller indeed is > pulse width modulated its purpose is specifically to control the > brightness of a backlight. > > Drop the #pwm-cells and instead expose a new property to configure the > granularity of the backlight PWM signal. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > index f8622bd0f61e..e380218b4646 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > @@ -66,9 +66,12 @@ properties: >1-based to match the datasheet. See ../../gpio/gpio.txt for more >information. > > - '#pwm-cells': > -const: 1 > -description: See ../../pwm/pwm.yaml for description of the cell formats. > + ti,backlight-scale: > +description: > + The granularity of brightness for the PWM signal provided on GPIO4, if > + this property is specified. > +minimum: 0 > +maximum: 65535 > >ports: > type: object Tested-By: Steev Klimaszewski ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Expose backlight controls
On 9/30/20 5:35 PM, Bjorn Andersson wrote:
> The TI SN65DSI86 can be configured to generate a PWM pulse on GPIO4,
> to be used to drive a backlight driver.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/bridge/Kconfig| 1 +
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 143 +-
> 2 files changed, 140 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 43271c21d3fc..eea310bd88e1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -195,6 +195,7 @@ config DRM_TI_SN65DSI86
> select REGMAP_I2C
> select DRM_PANEL
> select DRM_MIPI_DSI
> + select BACKLIGHT_CLASS_DEVICE
> help
> Texas Instruments SN65DSI86 DSI to eDP Bridge driver
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 5b6e19ecbc84..41e24d0dbd18 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -68,6 +68,7 @@
> #define SN_GPIO_MUX_OUTPUT 1
> #define SN_GPIO_MUX_SPECIAL 2
> #define SN_GPIO_MUX_MASK0x3
> +#define SN_GPIO_MUX_SHIFT(gpio) ((gpio) * 2)
> #define SN_AUX_WDATA_REG(x) (0x64 + (x))
> #define SN_AUX_ADDR_19_16_REG0x74
> #define SN_AUX_ADDR_15_8_REG 0x75
> @@ -86,6 +87,12 @@
> #define SN_ML_TX_MODE_REG0x96
> #define ML_TX_MAIN_LINK_OFF 0
> #define ML_TX_NORMAL_MODE BIT(0)
> +#define SN_PWM_PRE_DIV_REG 0xA0
> +#define SN_BACKLIGHT_SCALE_REG 0xA1
> +#define SN_BACKLIGHT_REG 0xA3
> +#define SN_PWM_CTL_REG 0xA5
> +#define SN_PWM_ENABLE BIT(1)
> +#define SN_PWM_INVERT BIT(0)
> #define SN_AUX_CMD_STATUS_REG0xF4
> #define AUX_IRQ_STATUS_AUX_RPLY_TOUTBIT(3)
> #define AUX_IRQ_STATUS_AUX_SHORTBIT(5)
> @@ -155,6 +162,8 @@ struct ti_sn_bridge {
> struct gpio_chipgchip;
> DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
> #endif
> + u32 brightness;
> + u32 max_brightness;
> };
>
> static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> @@ -173,6 +182,18 @@ static const struct regmap_config
> ti_sn_bridge_regmap_config = {
> .cache_type = REGCACHE_NONE,
> };
>
> +static void ti_sn_bridge_read_u16(struct ti_sn_bridge *pdata,
> + unsigned int reg, u16 *val)
> +{
> + unsigned int high;
> + unsigned int low;
> +
> + regmap_read(pdata->regmap, reg, &low);
> + regmap_read(pdata->regmap, reg + 1, &high);
> +
> + *val = high << 8 | low;
> +}
> +
> static void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata,
> unsigned int reg, u16 val)
> {
> @@ -180,6 +201,50 @@ static void ti_sn_bridge_write_u16(struct ti_sn_bridge
> *pdata,
> regmap_write(pdata->regmap, reg + 1, val >> 8);
> }
>
> +static int ti_sn_backlight_update(struct ti_sn_bridge *pdata)
> +{
> + unsigned int pre_div;
> +
> + if (!pdata->max_brightness)
> + return 0;
> +
> + /* Enable PWM on GPIO4 */
> + regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
> +SN_GPIO_MUX_MASK << SN_GPIO_MUX_SHIFT(4 - 1),
> +SN_GPIO_MUX_SPECIAL << SN_GPIO_MUX_SHIFT(4 - 1));
> +
> + if (pdata->brightness) {
> + /* Set max brightness */
> + ti_sn_bridge_write_u16(pdata, SN_BACKLIGHT_SCALE_REG,
> pdata->max_brightness);
> +
> + /* Set brightness */
> + ti_sn_bridge_write_u16(pdata, SN_BACKLIGHT_REG,
> pdata->brightness);
> +
> + /*
> + * The PWM frequency is derived from the refclk as:
> + * PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1)
> + *
> + * A hand wavy estimate based on 12MHz refclk and 500Hz desired
> + * PWM frequency gives us a pre_div resulting in a PWM
> + * frequency of between 500 and 1600Hz, depending on the actual
> + * refclk rate.
> + *
> + * One is added to avoid high BACKLIGHT_SCALE values to produce
> + * a pre_div of 0 - which cancels out the large BACKLIGHT_SCALE
> + * value.
> + */
> + pre_div = 1200 / (500 * pdata->max_brightness) + 1;
> + regmap_write(pdata->regmap, SN_PWM_PRE_DIV_REG, pre_div);
> +
> + /* Enable PWM */
> + regmap_update_bits(pdata->regmap, SN_PWM_CTL_REG,
> SN_PWM_ENABLE, SN_PWM_ENABLE);
> + } else {
> + regmap_update_bit
[PATCH 2/3] drm/ingenic: Update code to mmap GEM buffers cached
The DMA API changed at the same time commit 37054fc81443 ("gpu/drm:
ingenic: Add option to mmap GEM buffers cached") was added. Rework the
code to work with the new DMA API.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 24 +++
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 0225dc1f5eb8..07a1da7266e4 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -526,12 +526,10 @@ void ingenic_drm_sync_data(struct device *dev,
struct drm_plane_state *state)
{
const struct drm_format_info *finfo = state->fb->format;
- struct ingenic_drm *priv = dev_get_drvdata(dev);
struct drm_atomic_helper_damage_iter iter;
unsigned int offset, i;
struct drm_rect clip;
dma_addr_t paddr;
- void *addr;
if (!ingenic_drm_cached_gem_buf)
return;
@@ -541,12 +539,11 @@ void ingenic_drm_sync_data(struct device *dev,
drm_atomic_for_each_plane_damage(&iter, &clip) {
for (i = 0; i < finfo->num_planes; i++) {
paddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
- addr = phys_to_virt(paddr);
/* Ignore x1/x2 values, invalidate complete lines */
offset = clip.y1 * state->fb->pitches[i];
- dma_cache_sync(priv->dev, addr + offset,
+ dma_sync_single_for_device(dev, paddr + offset,
(clip.y2 - clip.y1) *
state->fb->pitches[i],
DMA_TO_DEVICE);
}
@@ -766,14 +763,6 @@ static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
- struct device *dev = cma_obj->base.dev->dev;
- unsigned long attrs;
- int ret;
-
- if (ingenic_drm_cached_gem_buf)
- attrs = DMA_ATTR_NON_CONSISTENT;
- else
- attrs = DMA_ATTR_WRITE_COMBINE;
/*
* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -784,12 +773,13 @@ static int ingenic_drm_gem_mmap(struct drm_gem_object
*obj,
vma->vm_pgoff = 0;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
- ret = dma_mmap_attrs(dev, vma, cma_obj->vaddr, cma_obj->paddr,
-vma->vm_end - vma->vm_start, attrs);
- if (ret)
- drm_gem_vm_close(vma);
+ if (!ingenic_drm_cached_gem_buf)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
- return ret;
+ return remap_pfn_range(vma, vma->vm_start,
+ cma_obj->paddr >> PAGE_SHIFT,
+ vma->vm_end - vma->vm_start,
+ vma->vm_page_prot);
}
static int ingenic_drm_gem_cma_mmap(struct file *filp,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: ti-sn65dsi86: remove redundant null check
Because clk_disable_unprepare already checked NULL clock parameter,
so the additional checks are unnecessary, just remove it
Signed-off-by: Xu Wang
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 5b6e19ecbc84..1b01836f1eb1 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -819,8 +819,7 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
*bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
- if (pdata->refclk)
- clk_disable_unprepare(pdata->refclk);
+ clk_disable_unprepare(pdata->refclk);
pm_runtime_put_sync(pdata->dev);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote: > Hi Nathan, > > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: > > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: > > > Now that all the drivers have been adjusted for it, let's bring in the > > > necessary device tree changes. > > > > > > The VEC and PV3 are left out for now, since it will require a more > > > specific > > > clock setup. > > > > > > Reviewed-by: Dave Stevenson > > > Tested-by: Chanwoo Choi > > > Tested-by: Hoegeun Kwon > > > Tested-by: Stefan Wahren > > > Signed-off-by: Maxime Ripard > > > > Apologies if this has already been reported or have a solution but this > > patch (and presumably series) breaks output to the serial console after > > a certain point during init. On Raspbian, I see systemd startup messages > > then the output just turns into complete garbage. It looks like this > > patch is merged first in linux-next, which is why my bisect fell on the > > DRM merge. I am happy to provide whatever information could be helpful > > for debugging this. I am on the latest version of the firmware > > (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). > > Unfortunately, the miniUART is in the same clock tree than the core > clock and will thus have those kind of issues when the core clock is > changed (which is also something that one should expect when using the > DRM or other drivers). > > The only real workaround there would be to switch to one of the PL011 > UARTs. I guess we can also somehow make the UART react to the core clock > frequency changes, but that's going to require some effort > > Maxime Ack, thank you for the reply! There does not really seem to be a whole ton of documentation around using one of the other PL011 UARTs so for now, I will just revert this commit locally. Cheers, Nathan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: ti-sn65dsi86: Expose backlight controls
The TI SN65DSI86 can be configured to generate a PWM pulse on GPIO4,
to be used to drive a backlight driver.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 143 +-
2 files changed, 140 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..eea310bd88e1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -195,6 +195,7 @@ config DRM_TI_SN65DSI86
select REGMAP_I2C
select DRM_PANEL
select DRM_MIPI_DSI
+ select BACKLIGHT_CLASS_DEVICE
help
Texas Instruments SN65DSI86 DSI to eDP Bridge driver
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 5b6e19ecbc84..41e24d0dbd18 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -68,6 +68,7 @@
#define SN_GPIO_MUX_OUTPUT1
#define SN_GPIO_MUX_SPECIAL 2
#define SN_GPIO_MUX_MASK 0x3
+#define SN_GPIO_MUX_SHIFT(gpio) ((gpio) * 2)
#define SN_AUX_WDATA_REG(x)(0x64 + (x))
#define SN_AUX_ADDR_19_16_REG 0x74
#define SN_AUX_ADDR_15_8_REG 0x75
@@ -86,6 +87,12 @@
#define SN_ML_TX_MODE_REG 0x96
#define ML_TX_MAIN_LINK_OFF 0
#define ML_TX_NORMAL_MODE BIT(0)
+#define SN_PWM_PRE_DIV_REG 0xA0
+#define SN_BACKLIGHT_SCALE_REG 0xA1
+#define SN_BACKLIGHT_REG 0xA3
+#define SN_PWM_CTL_REG 0xA5
+#define SN_PWM_ENABLE BIT(1)
+#define SN_PWM_INVERT BIT(0)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
@@ -155,6 +162,8 @@ struct ti_sn_bridge {
struct gpio_chipgchip;
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
#endif
+ u32 brightness;
+ u32 max_brightness;
};
static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
@@ -173,6 +182,18 @@ static const struct regmap_config
ti_sn_bridge_regmap_config = {
.cache_type = REGCACHE_NONE,
};
+static void ti_sn_bridge_read_u16(struct ti_sn_bridge *pdata,
+ unsigned int reg, u16 *val)
+{
+ unsigned int high;
+ unsigned int low;
+
+ regmap_read(pdata->regmap, reg, &low);
+ regmap_read(pdata->regmap, reg + 1, &high);
+
+ *val = high << 8 | low;
+}
+
static void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata,
unsigned int reg, u16 val)
{
@@ -180,6 +201,50 @@ static void ti_sn_bridge_write_u16(struct ti_sn_bridge
*pdata,
regmap_write(pdata->regmap, reg + 1, val >> 8);
}
+static int ti_sn_backlight_update(struct ti_sn_bridge *pdata)
+{
+ unsigned int pre_div;
+
+ if (!pdata->max_brightness)
+ return 0;
+
+ /* Enable PWM on GPIO4 */
+ regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
+ SN_GPIO_MUX_MASK << SN_GPIO_MUX_SHIFT(4 - 1),
+ SN_GPIO_MUX_SPECIAL << SN_GPIO_MUX_SHIFT(4 - 1));
+
+ if (pdata->brightness) {
+ /* Set max brightness */
+ ti_sn_bridge_write_u16(pdata, SN_BACKLIGHT_SCALE_REG,
pdata->max_brightness);
+
+ /* Set brightness */
+ ti_sn_bridge_write_u16(pdata, SN_BACKLIGHT_REG,
pdata->brightness);
+
+ /*
+* The PWM frequency is derived from the refclk as:
+* PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1)
+*
+* A hand wavy estimate based on 12MHz refclk and 500Hz desired
+* PWM frequency gives us a pre_div resulting in a PWM
+* frequency of between 500 and 1600Hz, depending on the actual
+* refclk rate.
+*
+* One is added to avoid high BACKLIGHT_SCALE values to produce
+* a pre_div of 0 - which cancels out the large BACKLIGHT_SCALE
+* value.
+*/
+ pre_div = 1200 / (500 * pdata->max_brightness) + 1;
+ regmap_write(pdata->regmap, SN_PWM_PRE_DIV_REG, pre_div);
+
+ /* Enable PWM */
+ regmap_update_bits(pdata->regmap, SN_PWM_CTL_REG,
SN_PWM_ENABLE, SN_PWM_ENABLE);
+ } else {
+ regmap_update_bits(pdata->regmap, SN_PWM_CTL_REG,
SN_PWM_ENABLE, 0);
+ }
+
+ return 0;
+}
+
static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
{
struct ti_sn_bridge *pdata = dev_get_drvd
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Nathan, On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: > > Now that all the drivers have been adjusted for it, let's bring in the > > necessary device tree changes. > > > > The VEC and PV3 are left out for now, since it will require a more specific > > clock setup. > > > > Reviewed-by: Dave Stevenson > > Tested-by: Chanwoo Choi > > Tested-by: Hoegeun Kwon > > Tested-by: Stefan Wahren > > Signed-off-by: Maxime Ripard > > Apologies if this has already been reported or have a solution but this > patch (and presumably series) breaks output to the serial console after > a certain point during init. On Raspbian, I see systemd startup messages > then the output just turns into complete garbage. It looks like this > patch is merged first in linux-next, which is why my bisect fell on the > DRM merge. I am happy to provide whatever information could be helpful > for debugging this. I am on the latest version of the firmware > (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). Unfortunately, the miniUART is in the same clock tree than the core clock and will thus have those kind of issues when the core clock is changed (which is also something that one should expect when using the DRM or other drivers). The only real workaround there would be to switch to one of the PL011 UARTs. I guess we can also somehow make the UART react to the core clock frequency changes, but that's going to require some effort Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Add and export function drm_gem_cma_create_noalloc
Add and export the function drm_gem_cma_create_noalloc(), which is just
__drm_gem_cma_create() renamed.
This function can be used by drivers that need to create a GEM object
without allocating the backing memory.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 11 ++-
include/drm/drm_gem_cma_helper.h | 3 +++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 59b9ca207b42..6abc4b306832 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -34,7 +34,7 @@
*/
/**
- * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
+ * drm_gem_cma_create_noalloc - Create a GEM CMA object without allocating
memory
* @drm: DRM device
* @size: size of the object to allocate
*
@@ -45,8 +45,8 @@
* A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative
* error code on failure.
*/
-static struct drm_gem_cma_object *
-__drm_gem_cma_create(struct drm_device *drm, size_t size)
+struct drm_gem_cma_object *
+drm_gem_cma_create_noalloc(struct drm_device *drm, size_t size)
{
struct drm_gem_cma_object *cma_obj;
struct drm_gem_object *gem_obj;
@@ -76,6 +76,7 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
kfree(cma_obj);
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(drm_gem_cma_create_noalloc);
/**
* drm_gem_cma_create - allocate an object with the given size
@@ -98,7 +99,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
size = round_up(size, PAGE_SIZE);
- cma_obj = __drm_gem_cma_create(drm, size);
+ cma_obj = drm_gem_cma_create_noalloc(drm, size);
if (IS_ERR(cma_obj))
return cma_obj;
@@ -476,7 +477,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(-EINVAL);
/* Create a CMA GEM buffer. */
- cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
+ cma_obj = drm_gem_cma_create_noalloc(dev, attach->dmabuf->size);
if (IS_ERR(cma_obj))
return ERR_CAST(cma_obj);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 2bfa2502607a..be2b8e3a8ab2 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -83,6 +83,9 @@ int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct
*vma);
struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
size_t size);
+struct drm_gem_cma_object *
+drm_gem_cma_create_noalloc(struct drm_device *drm, size_t size);
+
extern const struct vm_operations_struct drm_gem_cma_vm_ops;
#ifndef CONFIG_MMU
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Wed, Sep 30, 2020 at 01:52:11PM +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote: > > On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye wrote: > > > Yes, and built-in fonts don't use refcount. Or maybe we can let > > > find_font() and get_default_font() kmalloc() a copy of built-in font > > > data, then keep track of refcount for both user and built-in fonts, but > > > that will waste a few K of memory for each built-in font we use... > > > > A possible trick for this would be to make sure built-in fonts start > > out with a refcount of 1. So never get freed. Plus maybe a check that > > if the name is set, then it's a built-in font and if we ever underflow > > the refcount we just WARN, but don't free anything. > > > > Another trick would be kern_font_get/put wrappers (we'd want those > > anyway if the userspace fonts are refcounted) and if kern_font->name > > != NULL (i.e. built-in font with name) then we simply don't call > > kref_get/put. > > Ick, don't do that, the first trick of having them start out with an > increased reference count is the best way here. Makes the code simpler > and no special cases for the tear-down path. I see, I'll just let them start out with 1, and only check `->name != NULL` in kern_font_put(). Thank you! Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On 9/30/2020 2:58 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
@@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
*device,
goto umem_release;
cur_base += ret * PAGE_SIZE;
- npages -= ret;
-
- sg = ib_umem_add_sg_table(sg, page_list, ret,
- dma_get_max_seg_size(device->dma_device),
- &umem->sg_nents);
+ npages -= ret;
+ sg = __sg_alloc_table_from_pages(
+ &umem->sg_head, page_list, ret, 0, ret << PAGE_SHIFT,
+ dma_get_max_seg_size(device->dma_device), sg, npages,
+ GFP_KERNEL);
+ umem->sg_nents = umem->sg_head.nents;
+ if (IS_ERR(sg)) {
+ unpin_user_pages_dirty_lock(page_list, ret, 0);
+ ret = PTR_ERR(sg);
+ goto umem_release;
+ }
}
sg_mark_end(sg);
Does it still need the sg_mark_end?
It is preserved here for correctness, the release logic doesn't rely on
this marker, but it is better to leave it.
I mean, my read of __sg_alloc_table_from_pages() is that it already
placed it, the final __alloc_table() does it?
It marks the last allocated sge, but not the last populated sge (with page).
Why are those different?
It looks like the last iteration calls __alloc_table() with an exact
number of sges
+ if (!prv) {
+ /* Only the last allocation could be less than the maximum */
+ table_size = left_pages ? SG_MAX_SINGLE_ALLOC : chunks;
+ ret = sg_alloc_table(sgt, table_size, gfp_mask);
+ if (unlikely(ret))
+ return ERR_PTR(ret);
+ }
Jason
This is right only for the last iteration. E.g. in the first iteration
in case that there are more pages (left_pages), then we allocate
SG_MAX_SINGLE_ALLOC. We don't know how many pages from the second
iteration will be squashed to the SGE from the first iteration.
___
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 tree
Hi Christoph, Le mer. 30 sept. 2020 à 11:02, Christoph Hellwig a écrit : On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote: It's allocated with dma_alloc_wc, but then it's only accessed as non-coherent. Anyway, for the time being I guess you could revert 37054fc81443. But I have patches on top of it in drm-misc-next so it's going to be a mess. If we have time I can come up with a custom dumb_create() fonction, to make sure that the GEM buffers are allocated with dma_alloc_noncoherent(). Is there a dma_mmap_noncoherent() too? Please use the lower-level dma_alloc_pages and then just insert the pages directly using remap_pfn_range. Although it might make sense to eventually create a wrapper around remap_pfn_range for all the vma sizing sanity checks. One thing missing for remap_pfn_range(), I have no alternative for this: vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, DMA_ATTR_NON_CONSISTENT); So I have to do: vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK; pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT; And that will only compile on MIPS, because these _CACHE_* macros are only defined there. I would need something like a pgprot_noncoherent(), I think. -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ingenic: remove redundant null check
Because clk_disable_unprepare already checked NULL clock parameter,
so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index b7074161ccf0..9dce02e779ad 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -932,8 +932,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
return 0;
err_devclk_disable:
- if (priv->lcd_clk)
- clk_disable_unprepare(priv->lcd_clk);
+ clk_disable_unprepare(priv->lcd_clk);
err_pixclk_disable:
clk_disable_unprepare(priv->pix_clk);
return ret;
@@ -953,8 +952,7 @@ static void ingenic_drm_unbind(struct device *dev)
{
struct ingenic_drm *priv = dev_get_drvdata(dev);
- if (priv->lcd_clk)
- clk_disable_unprepare(priv->lcd_clk);
+ clk_disable_unprepare(priv->lcd_clk);
clk_disable_unprepare(priv->pix_clk);
drm_dev_unregister(&priv->drm);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
