[PATCH] drm/rockchip: vop_reg: add PX30 version info
To reduce memory various Rockchip VOP versions share
common reg structures. However more recent added SoCs not
always have to same futures as the old ones.
Add PX30 missing version info, so all VOP version checks
work correct if needed in the future.
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a..0697057e7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -312,6 +312,7 @@ static const struct vop_win_data px30_vop_big_win_data[] = {
};
static const struct vop_data px30_vop_big = {
+ .version = VOP_VERSION(2, 6),
.intr = &px30_intr,
.feature = VOP_FEATURE_INTERNAL_RGB,
.common = &px30_common,
@@ -327,6 +328,7 @@ static const struct vop_win_data px30_vop_lit_win_data[] = {
};
static const struct vop_data px30_vop_lit = {
+ .version = VOP_VERSION(2, 5),
.intr = &px30_intr,
.feature = VOP_FEATURE_INTERNAL_RGB,
.common = &px30_common,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/rockchip: vop_reg: add rk3036 hdmi support
A Rockchip Inno HDMI driver was added, but the rk3036
VOP regs with HDMI support in the manufacturer tree never
made it to the mainline kernel.
This patch adds only hdmi_en and hdmi_dclk_pol.
The inno hdmi driver must set hdmi_pin_pol in
GRF_SOC_CON2.
Signed-off-by: Johan Jonker
---
Not tested with hardware
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 0697057e7..c164690a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -147,6 +147,8 @@ static const struct vop_modeset rk3036_modeset = {
static const struct vop_output rk3036_output = {
.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+ .hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+ .hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
};
static const struct vop_common rk3036_common = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/mdp5: Fix wait-for-commit for cmd panels
On Wed, Jan 27, 2021 at 05:24:40PM +0200, Iskren Chernev wrote:
> Before the offending commit in msm_atomic_commit_tail wait_flush was
> called once per frame, after the commit was submitted. After it
> wait_flush is also called at the beginning to ensure previous
> potentially async commits are done.
>
> For cmd panels the source of wait_flush is a ping-pong irq notifying
> a completion. The completion needs to be notified with complete_all so
> multiple waiting parties (new async committers) can proceed.
>
> Signed-off-by: Iskren Chernev
> Suggested-by: Rob Clark
> Fixes: 2d99ced787e3d ("drm/msm: async commit support")
Nice job tracking down this fix!
Reviewed-by: Brian Masney
Tested-by: Brian Masney
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove unreachable code
On Sat, Jan 30, 2021 at 9:45 AM Chris Wilson wrote:
>
> Quoting Vinicius Tinti (2021-01-30 12:34:11)
> > On Fri, Jan 29, 2021 at 08:55:54PM +, Chris Wilson wrote:
> > > Quoting Vinicius Tinti (2021-01-29 18:15:19)
> > > > By enabling -Wunreachable-code-aggressive on Clang the following code
> > > > paths are unreachable.
> > >
> > > That code exists as commentary and, especially for sdvo, library
> > > functions that we may need in future.
> >
> > I would argue that this code could be removed since it is in git history.
> > It can be restored when needed.
> >
> > This will make the code cleaner.
>
> It doesn't change the control flow, so no complexity argument. It
> removes documentation from the code, so I have the opposite opinion.
The last change in sdvo related to this function is from commit
ce22c320b8ca ("drm/i915/sdvo: convert to encoder disable/enable"), which
dates from 2012.
It has not been used or changed for a long time. I think it could be
converted to a block comment. This will preserve the documentation
purpose. What do you think?
All this will avoid having "if (0)".
> > > The ivb-gt1 case => as we now set the gt level for ivb, should we not
> > > enable the optimisation for ivb unaffected by the w/a? Just no one has
> > > taken the time to see if it causes a regression.
> >
> > I don't know. I just found out that the code is unreachable.
> >
> > > For error state, the question remains whether we should revert to
> > > uncompressed data if the compressed stream is larger than the original.
> >
> > I don't know too.
> >
> > In this last two cases the code could be commented and the decisions
> > and problems explained in the comment section.
>
> They already are, that is the point.
I meant making them a block comment. For example:
/*
* Enabling HiZ Raw Stall Optimization, at this point, causes corruption.
*
* Calling wa_masked_dis with the arguments wal, CACHE_MODE_0_GEN7,
* HIZ_RAW_STALL_OPT_DISABLE will cause an HiZ corruption on ivb:g1.
*/
/*
* Should fallback to uncompressed if we increase size
* (zstream->total_out > zstream->total_in) by returning -E2BIG?
*/
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/mdp5: Fix wait-for-commit for cmd panels
Hi Iskren,
On Mittwoch, 27. Jänner 2021 16:24:40 CET Iskren Chernev wrote:
> Before the offending commit in msm_atomic_commit_tail wait_flush was
> called once per frame, after the commit was submitted. After it
> wait_flush is also called at the beginning to ensure previous
> potentially async commits are done.
>
> For cmd panels the source of wait_flush is a ping-pong irq notifying
> a completion. The completion needs to be notified with complete_all so
> multiple waiting parties (new async committers) can proceed.
>
> Signed-off-by: Iskren Chernev
> Suggested-by: Rob Clark
> Fixes: 2d99ced787e3d ("drm/msm: async commit support")
> ---
I've tested this now on fairphone-fp2 and lge-nexus5-hammerhead, works great!
Tested-by: Luca Weiss
Regards
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/mdp5: Fix wait-for-commit for cmd panels
On 1/27/21 6:24 PM, Iskren Chernev wrote:
Before the offending commit in msm_atomic_commit_tail wait_flush was
called once per frame, after the commit was submitted. After it
wait_flush is also called at the beginning to ensure previous
potentially async commits are done.
For cmd panels the source of wait_flush is a ping-pong irq notifying
a completion. The completion needs to be notified with complete_all so
multiple waiting parties (new async committers) can proceed.
Signed-off-by: Iskren Chernev
Suggested-by: Rob Clark
Fixes: 2d99ced787e3d ("drm/msm: async commit support")
Tested on msm8974pro samsung-klte, finally got 60 fps instead of 13
in kmscube.
Tested-by: Alexey Minnekhanov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/panfrost: MMU fixes
Hello, Here are 2 fixes and one improvement for the page fault handling. Those bugs were found while working on indirect draw supports which requires the allocation of a big heap buffer for varyings, and the vertex/tiler shaders seem to have access pattern that trigger those issues. I remember discussing the first issue with Steve or Robin a while back, but we never hit it before (now we do :)). The last patch is a perf improvement: no need to re-enable hardware interrupts if we know the threaded irq handler will be woken up right away. Regards, Boris Boris Brezillon (3): drm/panfrost: Clear MMU irqs before handling the fault drm/panfrost: Don't try to map pages that are already mapped drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs drivers/gpu/drm/panfrost/panfrost_mmu.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/panfrost: Don't try to map pages that are already mapped
We allocate 2MB chunks at a time, so it might appear that a page fault
has already been handled by a previous page fault when we reach
panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the
same area twice.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 904d63450862..21e552d1ac71 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -488,8 +488,14 @@ static int panfrost_mmu_map_fault_addr(struct
panfrost_device *pfdev, int as,
}
bo->base.pages = pages;
bo->base.pages_use_count = 1;
- } else
+ } else {
pages = bo->base.pages;
+ if (pages[page_offset]) {
+ /* Pages are already mapped, bail out. */
+ mutex_unlock(&bo->base.pages_lock);
+ goto out;
+ }
+ }
mapping = bo->base.base.filp->f_mapping;
mapping_set_unevictable(mapping);
@@ -522,6 +528,7 @@ static int panfrost_mmu_map_fault_addr(struct
panfrost_device *pfdev, int as,
dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr);
+out:
panfrost_gem_mapping_put(bomapping);
return 0;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/panfrost: Clear MMU irqs before handling the fault
When a fault is handled it will unblock the GPU which will continue
executing its shader and might fault almost immediately on a different
page. If we clear interrupts after handling the fault we might miss new
faults, so clear them before.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 7c1b3481b785..904d63450862 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -593,6 +593,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
+ mmu_write(pfdev, MMU_INT_CLEAR, mask);
+
/* Page fault only */
ret = -1;
if ((status & mask) == BIT(i) && (exception_type & 0xF8) ==
0xC0)
@@ -616,8 +618,6 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
access_type, access_type_name(pfdev,
fault_status),
source_id);
- mmu_write(pfdev, MMU_INT_CLEAR, mask);
-
status &= ~mask;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 21e552d1ac71..65bc20628c4e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -580,6 +580,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
int i, ret;
+again:
+
for (i = 0; status; i++) {
u32 mask = BIT(i) | BIT(i + 16);
u64 addr;
@@ -628,6 +630,11 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int
irq, void *data)
status &= ~mask;
}
+ /* If we received new MMU interrupts, process them before returning. */
+ status = mmu_read(pfdev, MMU_INT_RAWSTAT);
+ if (status)
+ goto again;
+
mmu_write(pfdev, MMU_INT_MASK, ~0);
return IRQ_HANDLED;
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/gma500: Remove Medfield support
Hi Patrik Am 29.01.21 um 15:25 schrieb Patrik Jakobsson: On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann wrote: Medfield is an outdated mobile platform with apparently no users left. Remove it from gma500. Signed-off-by: Thomas Zimmermann Great, finally we get rid of that DSI code :) Signed-off-by: Patrik Jakobsson I'm not sure about the meaning of the S-o-b tag here. Can I count this as an A-b? Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] v5.11-rc5 BUG kmalloc-1k (Not tainted): Redzone overwritten
Quoting Jani Nikula (2021-01-28 13:23:48)
>
> A number of our CI systems are hitting redzone overwritten errors after
> s2idle, with the errors introduced between v5.11-rc4 and v5.11-rc5. See
> snippet below, full logs for one affected machine at [1].
>
> Known issue?
Fwiw, I think this should be fixed by
commit 08d60e5999540110576e7c1346d486220751b7f9
Author: John Ogness
Date: Sun Jan 24 21:33:28 2021 +0106
printk: fix string termination for record_print_text()
Commit f0e386ee0c0b ("printk: fix buffer overflow potential for
print_text()") added string termination in record_print_text().
However it used the wrong base pointer for adding the terminator.
This led to a 0-byte being written somewhere beyond the buffer.
Use the correct base pointer when adding the terminator.
Fixes: f0e386ee0c0b ("printk: fix buffer overflow potential for
print_text()")
Reported-by: Sven Schnelle
Signed-off-by: John Ogness
Signed-off-by: Petr Mladek
Link:
https://lore.kernel.org/r/20210124202728.4718-1-john.ogn...@linutronix.de
din should be rolled forward, but there's yet another regression in rc6
breaking suspend on all machines.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/29] drm/i915: Avoid comma separated statements
On Sat, 30 Jan 2021, Joe Perches wrote:
> On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
>> Use semicolons and braces.
>
> Ping?
Seems to have fallen between the cracks.
The first two hunks have been fixed, the last two are still there. Care
to respin and rebase against drm-tip (or linux-next) please?
BR,
Jani.
>
>> Signed-off-by: Joe Perches
>> ---
>> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +---
>> drivers/gpu/drm/i915/gt/intel_gt_requests.c| 6 --
>> drivers/gpu/drm/i915/gt/selftest_workarounds.c | 6 --
>> drivers/gpu/drm/i915/intel_runtime_pm.c| 6 --
>> 4 files changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> index 699125928272..114c13285ff1 100644
>> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> @@ -323,10 +323,12 @@ static int __gen8_ppgtt_alloc(struct
>> i915_address_space * const vm,
>> }
>>
>>
>> spin_lock(&pd->lock);
>> -if (likely(!pd->entry[idx]))
>> +if (likely(!pd->entry[idx])) {
>> set_pd_entry(pd, idx, pt);
>> -else
>> -alloc = pt, pt = pd->entry[idx];
>> +} else {
>> +alloc = pt;
>> +pt = pd->entry[idx];
>> +}
>> }
>>
>>
>> if (lvl) {
>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
>> b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
>> index 66fcbf9d0fdd..54408d0b5e6e 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
>> @@ -139,8 +139,10 @@ long intel_gt_retire_requests_timeout(struct intel_gt
>> *gt, long timeout)
>> LIST_HEAD(free);
>>
>>
>> interruptible = true;
>> -if (unlikely(timeout < 0))
>> -timeout = -timeout, interruptible = false;
>> +if (unlikely(timeout < 0)) {
>> +timeout = -timeout;
>> +interruptible = false;
>> +}
>>
>>
>> flush_submission(gt, timeout); /* kick the ksoftirqd tasklets */
>> spin_lock(&timelines->lock);
>> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> index febc9e6692ba..3e4cbeed20bd 100644
>> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> @@ -521,8 +521,10 @@ static int check_dirty_whitelist(struct intel_context
>> *ce)
>>
>>
>> srm = MI_STORE_REGISTER_MEM;
>> lrm = MI_LOAD_REGISTER_MEM;
>> -if (INTEL_GEN(engine->i915) >= 8)
>> -lrm++, srm++;
>> +if (INTEL_GEN(engine->i915) >= 8) {
>> +lrm++;
>> +srm++;
>> +}
>>
>>
>> pr_debug("%s: Writing garbage to %x\n",
>> engine->name, reg);
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 153ca9e65382..f498f1c80755 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -201,8 +201,10 @@ __print_intel_runtime_pm_wakeref(struct drm_printer *p,
>> unsigned long rep;
>>
>>
>> rep = 1;
>> -while (i + 1 < dbg->count && dbg->owners[i + 1] == stack)
>> -rep++, i++;
>> +while (i + 1 < dbg->count && dbg->owners[i + 1] == stack) {
>> +rep++;
>> +i++;
>> +}
>> __print_depot_stack(stack, buf, PAGE_SIZE, 2);
>> drm_printf(p, "Wakeref x%lu taken at:\n%s", rep, buf);
>> }
>
>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d/v3d_sched: fix scheduler callbacks return status
Looks like this was not correctly adjusted.
Signed-off-by: Christian König
Fixes: a6a1f036c74e ("drm/scheduler: Job timeout handler returns status (v3)")
---
drivers/gpu/drm/v3d/v3d_sched.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index ef2338a294ca..ceb33f8e4379 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -259,7 +259,7 @@ v3d_cache_clean_job_run(struct drm_sched_job *sched_job)
return NULL;
}
-static enum drm_gpu_sched_status
+static enum drm_gpu_sched_stat
v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job)
{
enum v3d_queue q;
@@ -294,7 +294,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct
drm_sched_job *sched_job)
* could fail if the GPU got in an infinite loop in the CL, but that
* is pretty unlikely outside of an i-g-t testcase.
*/
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
u32 *timedout_ctca, u32 *timedout_ctra)
{
@@ -312,7 +312,7 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum
v3d_queue q,
return v3d_gpu_reset_for_timeout(v3d, sched_job);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_bin_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_bin_job *job = to_bin_job(sched_job);
@@ -321,7 +321,7 @@ v3d_bin_job_timedout(struct drm_sched_job *sched_job)
&job->timedout_ctca, &job->timedout_ctra);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_render_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_render_job *job = to_render_job(sched_job);
@@ -330,7 +330,7 @@ v3d_render_job_timedout(struct drm_sched_job *sched_job)
&job->timedout_ctca, &job->timedout_ctra);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_generic_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_job *job = to_v3d_job(sched_job);
@@ -338,7 +338,7 @@ v3d_generic_job_timedout(struct drm_sched_job *sched_job)
return v3d_gpu_reset_for_timeout(job->v3d, sched_job);
}
-static enum drm_task_status
+static enum drm_gpu_sched_stat
v3d_csd_job_timedout(struct drm_sched_job *sched_job)
{
struct v3d_csd_job *job = to_csd_job(sched_job);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/gma500: Remove Medfield support
On Mon, Feb 1, 2021 at 9:23 AM Thomas Zimmermann wrote: > > Hi Patrik > > Am 29.01.21 um 15:25 schrieb Patrik Jakobsson: > > On Fri, Jan 29, 2021 at 10:56 AM Thomas Zimmermann > > wrote: > >> > >> Medfield is an outdated mobile platform with apparently no users left. > >> Remove it from gma500. > >> > >> Signed-off-by: Thomas Zimmermann > > > > Great, finally we get rid of that DSI code :) > > > > Signed-off-by: Patrik Jakobsson > > I'm not sure about the meaning of the S-o-b tag here. Can I count this > as an A-b? It means I'll take the patch through my path (which is drm-misc in this case). I normally A-b stuff that is part of a wider series that I will not take myself and S-o-b when I'll take it. -Patrik > > Best regards > Thomas > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d/v3d_sched: fix scheduler callbacks return status
On Mon, Feb 1, 2021 at 10:12 AM Christian König
wrote:
>
> Looks like this was not correctly adjusted.
shoulda compile test before pushing :-)
> Signed-off-by: Christian König
> Fixes: a6a1f036c74e ("drm/scheduler: Job timeout handler returns status (v3)")
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/v3d/v3d_sched.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index ef2338a294ca..ceb33f8e4379 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -259,7 +259,7 @@ v3d_cache_clean_job_run(struct drm_sched_job *sched_job)
> return NULL;
> }
>
> -static enum drm_gpu_sched_status
> +static enum drm_gpu_sched_stat
> v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job
> *sched_job)
> {
> enum v3d_queue q;
> @@ -294,7 +294,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct
> drm_sched_job *sched_job)
> * could fail if the GPU got in an infinite loop in the CL, but that
> * is pretty unlikely outside of an i-g-t testcase.
> */
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
> u32 *timedout_ctca, u32 *timedout_ctra)
> {
> @@ -312,7 +312,7 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum
> v3d_queue q,
> return v3d_gpu_reset_for_timeout(v3d, sched_job);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_bin_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_bin_job *job = to_bin_job(sched_job);
> @@ -321,7 +321,7 @@ v3d_bin_job_timedout(struct drm_sched_job *sched_job)
>&job->timedout_ctca, &job->timedout_ctra);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_render_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_render_job *job = to_render_job(sched_job);
> @@ -330,7 +330,7 @@ v3d_render_job_timedout(struct drm_sched_job *sched_job)
>&job->timedout_ctca, &job->timedout_ctra);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_generic_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_job *job = to_v3d_job(sched_job);
> @@ -338,7 +338,7 @@ v3d_generic_job_timedout(struct drm_sched_job *sched_job)
> return v3d_gpu_reset_for_timeout(job->v3d, sched_job);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_csd_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_csd_job *job = to_csd_job(sched_job);
> --
> 2.25.1
>
> ___
> 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 v3 1/4] dp/dp_mst: Add support for sink event notify messages
Hi Lyude,
Daniel referred me to you as the best person to review the MST parts of this
series.
I can commit this, but then I prefer to have a Reviewed-by or Acked-by from
someone for the first 3 DP MST patches. Alternatively, you can take the whole
series (I've reviewed the 4th CEC patch).
Regards,
Hans
On 12/01/2021 10:24, Hans Verkuil wrote:
> Hi Sam,
>
> This series still hasn't been merged. It still applies cleanly to v5.11-rc1.
>
> Daniel, can you merge this series for 5.12? Or Ack this series so I can merge
> it?
>
> The first three patches deal with DP MST support, and this needs review from
> you or David.
>
> Regards,
>
> Hans
>
> On 23/09/2020 04:13, Sam McNally wrote:
>> Sink event notify messages are used for MST CEC IRQs. Add parsing
>> support for sink event notify messages in preparation for handling MST
>> CEC IRQs.
>>
>> Signed-off-by: Sam McNally
>> ---
>>
>> (no changes since v1)
>>
>> drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
>> include/drm/drm_dp_mst_helper.h | 14 ++
>> 2 files changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 17dbed0a9800..15b6cc39a754 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1027,6 +1027,30 @@ static bool
>> drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
>> return false;
>> }
>>
>> +static bool drm_dp_sideband_parse_sink_event_notify(
>> +struct drm_dp_sideband_msg_rx *raw,
>> +struct drm_dp_sideband_msg_req_body *msg)
>> +{
>> +int idx = 1;
>> +
>> +msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
>> +idx++;
>> +if (idx > raw->curlen)
>> +goto fail_len;
>> +
>> +memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
>> +idx += 16;
>> +if (idx > raw->curlen)
>> +goto fail_len;
>> +
>> +msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
>> +idx++;
>> +return true;
>> +fail_len:
>> +DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx,
>> raw->curlen);
>> +return false;
>> +}
>> +
>> static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
>>struct drm_dp_sideband_msg_req_body *msg)
>> {
>> @@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct
>> drm_dp_sideband_msg_rx *raw,
>> return drm_dp_sideband_parse_connection_status_notify(raw, msg);
>> case DP_RESOURCE_STATUS_NOTIFY:
>> return drm_dp_sideband_parse_resource_status_notify(raw, msg);
>> +case DP_SINK_EVENT_NOTIFY:
>> +return drm_dp_sideband_parse_sink_event_notify(raw, msg);
>> default:
>> DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
>>drm_dp_mst_req_type_str(msg->req_type));
>> @@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct
>> drm_dp_mst_topology_mgr *mgr,
>> guid = msg->u.conn_stat.guid;
>> else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
>> guid = msg->u.resource_stat.guid;
>> +else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
>> +guid = msg->u.sink_event.guid;
>>
>> if (guid)
>> mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
>> @@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct
>> drm_dp_mst_topology_mgr *mgr)
>> drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
>>
>> if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
>> -up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
>> +up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
>> +up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
>> DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
>>up_req->msg.req_type);
>> kfree(up_req);
>> @@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct
>> drm_dp_mst_topology_mgr *mgr)
>> DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
>>res_stat->port_number,
>>res_stat->available_pbn);
>> +} else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
>> +const struct drm_dp_sink_event_notify *sink_event =
>> +&up_req->msg.u.sink_event;
>> +
>> +DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
>> + sink_event->port_number, sink_event->event_id);
>> }
>>
>> up_req->hdr = mgr->up_req_recv.initial_hdr;
>> diff --git a/include/drm/drm_dp_mst_helper.h
>> b/include/drm/drm_dp_mst_helper.h
>> index 6ae5860d8644..c7c79e0ced18 100644
>> --- a/include/drm/drm_dp_mst_helper.h
>> +++ b/include/drm/drm_dp_mst_helper.h
>> @@ -402,6 +402,19 @@ struct d
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > On 2021-01-29 14:35, Will Deacon wrote: > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > Add a new page protection flag IOMMU_LLC which can be used > > > by non-coherent masters to set cacheable memory attributes > > > for an outer level of cache called as last-level cache or > > > system cache. Initial user of this page protection flag is > > > the adreno gpu and then can later be used by other clients > > > such as video where this can be used for per-buffer based > > > mapping. > > > > > > Signed-off-by: Sai Prakash Ranjan > > > --- > > > drivers/iommu/io-pgtable-arm.c | 3 +++ > > > include/linux/iommu.h | 6 ++ > > > 2 files changed, 9 insertions(+) > > > > > > diff --git a/drivers/iommu/io-pgtable-arm.c > > > b/drivers/iommu/io-pgtable-arm.c > > > index 7439ee7fdcdb..ebe653ef601b 100644 > > > --- a/drivers/iommu/io-pgtable-arm.c > > > +++ b/drivers/iommu/io-pgtable-arm.c > > > @@ -415,6 +415,9 @@ static arm_lpae_iopte > > > arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, > > > else if (prot & IOMMU_CACHE) > > > pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE > > > << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > + else if (prot & IOMMU_LLC) > > > + pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE > > > + << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > } > > > > > > if (prot & IOMMU_CACHE) > > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > > index ffaa389ea128..1f82057df531 100644 > > > --- a/include/linux/iommu.h > > > +++ b/include/linux/iommu.h > > > @@ -31,6 +31,12 @@ > > > * if the IOMMU page table format is equivalent. > > > */ > > > #define IOMMU_PRIV (1 << 5) > > > +/* > > > + * Non-coherent masters can use this page protection flag to set > > > cacheable > > > + * memory attributes for only a transparent outer level of cache, > > > also known as > > > + * the last-level or system cache. > > > + */ > > > +#define IOMMU_LLC(1 << 6) > > > > On reflection, I'm a bit worried about exposing this because I think it > > will > > introduce a mismatched virtual alias with the CPU (we don't even have a > > MAIR > > set up for this memory type). Now, we also have that issue for the PTW, > > but > > since we always use cache maintenance (i.e. the streaming API) for > > publishing the page-tables to a non-coheren walker, it works out. > > However, > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > allocation, then they're potentially in for a nasty surprise due to the > > mismatched outer-cacheability attributes. > > > > Can't we add the syscached memory type similar to what is done on android? Maybe. How does the GPU driver map these things on the CPU side? Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/dp_mst: Don't report ports connected if nothing is attached to them
Reporting a port as connected if nothing is attached to them leads to
any i2c transactions on this port trying to use an uninitialized i2c
adapter, fix this.
Let's account for this case even if branch devices have no good reason
to report a port as unplugged with their peer device type set to 'none'.
Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2987
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1963
Cc: Wayne Lin
Cc: Lyude Paul
Cc: # v5.5+
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e82b596d646c..deb7995f42fa 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4224,6 +4224,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
switch (port->pdt) {
case DP_PEER_DEVICE_NONE:
+ break;
case DP_PEER_DEVICE_MST_BRANCHING:
if (!port->mcs)
ret = connector_status_connected;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
Caching EDIDs for physical ports prevents updating the EDID if a port
gets reconnected via a Connection Status Notification message, fix this.
Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
Cc: Wayne Lin
Cc: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index deb7995f42fa..309afe61afdd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2302,7 +2302,8 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
*mstb,
}
if (port->pdt != DP_PEER_DEVICE_NONE &&
- drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
+ drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
+ port->port_num >= DP_MST_LOGICAL_PORT_0) {
port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
drm_connector_set_tile_property(port->connector);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/dp_mst: Use DP_MST_LOGICAL_PORT_0 instead of magic number
Use the macro defined for the first logical port instead of the
corresponding magic number.
Cc: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 43a40660136c..0a54506c2773 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4232,9 +4232,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
case DP_PEER_DEVICE_SST_SINK:
ret = connector_status_connected;
/* for logical ports - cache the EDID */
- if (port->port_num >= 8 && !port->cached_edid) {
+ if (port->port_num >= DP_MST_LOGICAL_PORT_0 &&
!port->cached_edid)
port->cached_edid = drm_get_edid(connector,
&port->aux.ddc);
- }
break;
case DP_PEER_DEVICE_DP_LEGACY_CONV:
if (port->ldps)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/dp_mst: Remove redundant tile property setting
drm_get_edid() already updates the tile property since
commit 2de3a078497b ("drm/dp: Set the connector's TILE property even for DP SST
connectors")
so no need to update it after calling this function.
Cc: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 309afe61afdd..43a40660136c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2303,11 +2303,9 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
*mstb,
if (port->pdt != DP_PEER_DEVICE_NONE &&
drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
- port->port_num >= DP_MST_LOGICAL_PORT_0) {
+ port->port_num >= DP_MST_LOGICAL_PORT_0)
port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
- drm_connector_set_tile_property(port->connector);
- }
drm_connector_register(port->connector);
return;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/13] module: use RCU to synchronize find_module
+++ Miroslav Benes [29/01/21 16:29 +0100]: On Thu, 28 Jan 2021, Christoph Hellwig wrote: Allow for a RCU-sched critical section around find_module, following the lower level find_module_all helper, and switch the two callers outside of module.c to use such a RCU-sched critical section instead of module_mutex. That's a nice idea. @@ -57,7 +58,7 @@ static void klp_find_object_module(struct klp_object *obj) if (!klp_is_module(obj)) return; - mutex_lock(&module_mutex); + rcu_read_lock_sched(); /* * We do not want to block removal of patched modules and therefore * we do not take a reference here. The patches are removed by @@ -74,7 +75,7 @@ static void klp_find_object_module(struct klp_object *obj) if (mod && mod->klp_alive) RCU always baffles me a bit, so I'll ask. Don't we need rcu_dereference_sched() here? "mod" comes from a RCU-protected list, so I wonder. Same here :-) I had to double check the RCU documentation. For our modules list case I believe the rcu list API should take care of that for us. Worth noting is this snippet from Documentation/RCU/whatisRCU.txt: rcu_dereference() is typically used indirectly, via the _rcu list-manipulation primitives, such as list_for_each_entry_rcu() ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/panfrost: Clear MMU irqs before handling the fault
On 01/02/2021 08:21, Boris Brezillon wrote:
When a fault is handled it will unblock the GPU which will continue
executing its shader and might fault almost immediately on a different
page. If we clear interrupts after handling the fault we might miss new
faults, so clear them before.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
Good catch (although this oddly rings a bell - so perhaps it was me you
discussed it with before)
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 7c1b3481b785..904d63450862 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -593,6 +593,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
+ mmu_write(pfdev, MMU_INT_CLEAR, mask);
+
/* Page fault only */
ret = -1;
if ((status & mask) == BIT(i) && (exception_type & 0xF8) ==
0xC0)
@@ -616,8 +618,6 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
access_type, access_type_name(pfdev,
fault_status),
source_id);
- mmu_write(pfdev, MMU_INT_CLEAR, mask);
-
status &= ~mask;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/panfrost: Don't try to map pages that are already mapped
On 01/02/2021 08:21, Boris Brezillon wrote:
We allocate 2MB chunks at a time, so it might appear that a page fault
has already been handled by a previous page fault when we reach
panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the
same area twice.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 904d63450862..21e552d1ac71 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -488,8 +488,14 @@ static int panfrost_mmu_map_fault_addr(struct
panfrost_device *pfdev, int as,
}
bo->base.pages = pages;
bo->base.pages_use_count = 1;
- } else
+ } else {
pages = bo->base.pages;
+ if (pages[page_offset]) {
+ /* Pages are already mapped, bail out. */
+ mutex_unlock(&bo->base.pages_lock);
+ goto out;
+ }
+ }
mapping = bo->base.base.filp->f_mapping;
mapping_set_unevictable(mapping);
@@ -522,6 +528,7 @@ static int panfrost_mmu_map_fault_addr(struct
panfrost_device *pfdev, int as,
dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr);
+out:
panfrost_gem_mapping_put(bomapping);
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs
On 01/02/2021 08:21, Boris Brezillon wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezillon
Looks fine to me, but I'm interested to know if you actually saw a
performance improvement. Back-to-back MMU faults should (hopefully) be
fairly uncommon.
Regardless:
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 21e552d1ac71..65bc20628c4e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -580,6 +580,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
int i, ret;
+again:
+
for (i = 0; status; i++) {
u32 mask = BIT(i) | BIT(i + 16);
u64 addr;
@@ -628,6 +630,11 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int
irq, void *data)
status &= ~mask;
}
+ /* If we received new MMU interrupts, process them before returning. */
+ status = mmu_read(pfdev, MMU_INT_RAWSTAT);
+ if (status)
+ goto again;
+
mmu_write(pfdev, MMU_INT_MASK, ~0);
return IRQ_HANDLED;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs
On Mon, 1 Feb 2021 12:13:49 +
Steven Price wrote:
> On 01/02/2021 08:21, Boris Brezillon wrote:
> > Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
> > in the threaded irq handler as long as we can.
> >
> > Signed-off-by: Boris Brezillon
>
> Looks fine to me, but I'm interested to know if you actually saw a
> performance improvement. Back-to-back MMU faults should (hopefully) be
> fairly uncommon.
I actually didn't check the perf improvement or the actual number of
back-to-back MMU faults, but
dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_1000x1000_drawcount_5000
seemed to generate a few of those, so I thought it'd be good to
optimize that case given how trivial it is.
>
> Regardless:
>
> Reviewed-by: Steven Price
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > index 21e552d1ac71..65bc20628c4e 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > @@ -580,6 +580,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int
> > irq, void *data)
> > u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
> > int i, ret;
> >
> > +again:
> > +
> > for (i = 0; status; i++) {
> > u32 mask = BIT(i) | BIT(i + 16);
> > u64 addr;
> > @@ -628,6 +630,11 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int
> > irq, void *data)
> > status &= ~mask;
> > }
> >
> > + /* If we received new MMU interrupts, process them before returning. */
> > + status = mmu_read(pfdev, MMU_INT_RAWSTAT);
> > + if (status)
> > + goto again;
> > +
> > mmu_write(pfdev, MMU_INT_MASK, ~0);
> > return IRQ_HANDLED;
> > };
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs
On 01/02/2021 12:59, Boris Brezillon wrote:
On Mon, 1 Feb 2021 12:13:49 +
Steven Price wrote:
On 01/02/2021 08:21, Boris Brezillon wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezillon
Looks fine to me, but I'm interested to know if you actually saw a
performance improvement. Back-to-back MMU faults should (hopefully) be
fairly uncommon.
I actually didn't check the perf improvement or the actual number of
back-to-back MMU faults, but
dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_1000x1000_drawcount_5000
seemed to generate a few of those, so I thought it'd be good to
optimize that case given how trivial it is.
Fair enough! I was just a little concerned that Panfrost was somehow
provoking enough interrupts that this was a measurable performance
improvement.
I assume you'll push these to drm-misc-next (/fixes) as appropriate.
Thanks,
Steve
Regardless:
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 21e552d1ac71..65bc20628c4e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -580,6 +580,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq,
void *data)
u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
int i, ret;
+again:
+
for (i = 0; status; i++) {
u32 mask = BIT(i) | BIT(i + 16);
u64 addr;
@@ -628,6 +630,11 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int
irq, void *data)
status &= ~mask;
}
+ /* If we received new MMU interrupts, process them before returning. */
+ status = mmu_read(pfdev, MMU_INT_RAWSTAT);
+ if (status)
+ goto again;
+
mmu_write(pfdev, MMU_INT_MASK, ~0);
return IRQ_HANDLED;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/gma500/cdv: Remove unused code for crt init
Clearly never been used so just remove it.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index c48c9d322dfb..4a9bb4994a26 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -248,8 +248,6 @@ void cdv_intel_crt_init(struct drm_device *dev,
struct drm_connector *connector;
struct drm_encoder *encoder;
- u32 i2c_reg;
-
gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
if (!gma_encoder)
return;
@@ -269,24 +267,13 @@ void cdv_intel_crt_init(struct drm_device *dev,
gma_connector_attach_encoder(gma_connector, gma_encoder);
/* Set up the DDC bus. */
- i2c_reg = GPIOA;
- /* Remove the following code for CDV */
- /*
- if (dev_priv->crt_ddc_bus != 0)
- i2c_reg = dev_priv->crt_ddc_bus;
- }*/
- gma_encoder->ddc_bus = psb_intel_i2c_create(dev,
- i2c_reg, "CRTDDC_A");
+ gma_encoder->ddc_bus = psb_intel_i2c_create(dev, GPIOA, "CRTDDC_A");
if (!gma_encoder->ddc_bus) {
dev_printk(KERN_ERR, dev->dev, "DDC bus registration
failed.\n");
goto failed_ddc;
}
gma_encoder->type = INTEL_OUTPUT_ANALOG;
- /*
- psb_intel_output->clone_mask = (1 << INTEL_ANALOG_CLONE_BIT);
- psb_intel_output->crtc_mask = (1 << 0) | (1 << 1);
- */
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/gma500: Remove unused DPST support
DPST never got enabled so remove it. We keep the reg save/restore code
just for safety.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h | 4 -
drivers/gpu/drm/gma500/psb_intel_reg.h | 32 ---
drivers/gpu/drm/gma500/psb_irq.c | 110 -
drivers/gpu/drm/gma500/psb_irq.h | 4 -
4 files changed, 150 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 020a71b91577..d4f14a5d509b 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -622,13 +622,9 @@ static inline struct drm_psb_private *psb_priv(struct
drm_device *dev)
/* psb_irq.c */
extern irqreturn_t psb_irq_handler(int irq, void *arg);
-extern int psb_irq_enable_dpst(struct drm_device *dev);
-extern int psb_irq_disable_dpst(struct drm_device *dev);
extern void psb_irq_preinstall(struct drm_device *dev);
extern int psb_irq_postinstall(struct drm_device *dev);
extern void psb_irq_uninstall(struct drm_device *dev);
-extern void psb_irq_turn_on_dpst(struct drm_device *dev);
-extern void psb_irq_turn_off_dpst(struct drm_device *dev);
extern void psb_irq_uninstall_islands(struct drm_device *dev, int hw_islands);
extern int psb_vblank_wait2(struct drm_device *dev, unsigned int *sequence);
diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index 364ea8f06f9c..ced7b433befb 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -550,38 +550,6 @@
#define HISTOGRAM_INT_CTRL_CLEAR (1UL << 30)
#define DPST_YUV_LUMA_MODE 0
-struct dpst_ie_histogram_control {
- union {
- uint32_t data;
- struct {
- uint32_t bin_reg_index:7;
- uint32_t reserved:4;
- uint32_t bin_reg_func_select:1;
- uint32_t sync_to_phase_in:1;
- uint32_t alt_enhancement_mode:2;
- uint32_t reserved1:1;
- uint32_t sync_to_phase_in_count:8;
- uint32_t histogram_mode_select:1;
- uint32_t reserved2:4;
- uint32_t ie_pipe_assignment:1;
- uint32_t ie_mode_table_enabled:1;
- uint32_t ie_histogram_enable:1;
- };
- };
-};
-
-struct dpst_guardband {
- union {
- uint32_t data;
- struct {
- uint32_t guardband:22;
- uint32_t guardband_interrupt_delay:8;
- uint32_t interrupt_status:1;
- uint32_t interrupt_enable:1;
- };
- };
-};
-
#define PIPEAFRAMEHIGH 0x70040
#define PIPEAFRAMEPIXEL0x70044
#define PIPEBFRAMEHIGH 0x71040
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index ae9b100e640b..104009e78487 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -101,30 +101,6 @@ psb_disable_pipestat(struct drm_psb_private *dev_priv, int
pipe, u32 mask)
}
}
-static void mid_enable_pipe_event(struct drm_psb_private *dev_priv, int pipe)
-{
- if (gma_power_begin(dev_priv->dev, false)) {
- u32 pipe_event = mid_pipe_event(pipe);
- dev_priv->vdc_irq_mask |= pipe_event;
- PSB_WVDC32(~dev_priv->vdc_irq_mask, PSB_INT_MASK_R);
- PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
- gma_power_end(dev_priv->dev);
- }
-}
-
-static void mid_disable_pipe_event(struct drm_psb_private *dev_priv, int pipe)
-{
- if (dev_priv->pipestat[pipe] == 0) {
- if (gma_power_begin(dev_priv->dev, false)) {
- u32 pipe_event = mid_pipe_event(pipe);
- dev_priv->vdc_irq_mask &= ~pipe_event;
- PSB_WVDC32(~dev_priv->vdc_irq_mask, PSB_INT_MASK_R);
- PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
- gma_power_end(dev_priv->dev);
- }
- }
-}
-
/*
* Display controller interrupt handler for pipe event.
*/
@@ -392,92 +368,6 @@ void psb_irq_uninstall(struct drm_device *dev)
spin_unlock_irqrestore(&dev_priv->irqmask_lock, irqflags);
}
-void psb_irq_turn_on_dpst(struct drm_device *dev)
-{
- struct drm_psb_private *dev_priv =
- (struct drm_psb_private *) dev->dev_private;
- u32 hist_reg;
- u32 pwm_reg;
-
- if (gma_power_begin(dev, false)) {
- PSB_WVDC32(1 << 31, HISTOGRAM_LOGIC_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_LOGIC_CONTROL);
- PSB_WVDC32(1 << 31, HISTOGRAM_INT_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_INT_CONTROL);
-
- PSB_WVDC32(0x80010100, PWM_CONTROL_LO
[PATCH 3/6] drm/gma500/cdv: Remove unused tv out paths
Afaik tv out is not available on Cedarview and the code isn't doing
anything so remove it.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 5d3302249779..aac776fab36d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -582,7 +582,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct gma_clock_t clock;
u32 dpll = 0, dspcntr, pipeconf;
bool ok;
- bool is_lvds = false, is_tv = false;
+ bool is_lvds = false;
bool is_dp = false;
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
@@ -603,9 +603,6 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
case INTEL_OUTPUT_LVDS:
is_lvds = true;
break;
- case INTEL_OUTPUT_TVOUT:
- is_tv = true;
- break;
case INTEL_OUTPUT_ANALOG:
case INTEL_OUTPUT_HDMI:
break;
@@ -660,12 +657,6 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
}
dpll = DPLL_VGA_MODE_DIS;
- if (is_tv) {
- /* XXX: just matching BIOS for now */
-/* dpll |= PLL_REF_INPUT_TVCLKINBC; */
- dpll |= 3;
- }
-/* dpll |= PLL_REF_INPUT_DREFCLK; */
if (is_dp || is_edp) {
cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/gma500: Unify crtc helpers
CDV crtc helpers are identical to other chips so use gma_ prefix for the
crtc helper struct and remove the CDV copy.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_device.c| 2 +-
drivers/gpu/drm/gma500/cdv_device.h| 1 -
drivers/gpu/drm/gma500/cdv_intel_display.c | 12
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/psb_device.c| 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
7 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 19e055dbd4c2..1342e7fb382f 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -603,7 +603,7 @@ const struct psb_ops cdv_chip_ops = {
.errata = cdv_errata,
.crtc_helper = &cdv_intel_helper_funcs,
- .crtc_funcs = &cdv_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.clock_funcs = &cdv_clock_funcs,
.output_init = cdv_output_init,
diff --git a/drivers/gpu/drm/gma500/cdv_device.h
b/drivers/gpu/drm/gma500/cdv_device.h
index 37e4bdc84c03..504d717385cd 100644
--- a/drivers/gpu/drm/gma500/cdv_device.h
+++ b/drivers/gpu/drm/gma500/cdv_device.h
@@ -8,7 +8,6 @@ struct drm_device;
struct psb_intel_mode_device;
extern const struct drm_crtc_helper_funcs cdv_intel_helper_funcs;
-extern const struct drm_crtc_funcs cdv_intel_crtc_funcs;
extern const struct gma_clock_funcs cdv_clock_funcs;
extern void cdv_intel_crt_init(struct drm_device *dev,
struct psb_intel_mode_device *mode_dev);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index aac776fab36d..c3a9f6b3c848 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -961,18 +961,6 @@ const struct drm_crtc_helper_funcs cdv_intel_helper_funcs
= {
.disable = gma_crtc_disable,
};
-const struct drm_crtc_funcs cdv_intel_crtc_funcs = {
- .cursor_set = gma_crtc_cursor_set,
- .cursor_move = gma_crtc_cursor_move,
- .gamma_set = gma_crtc_gamma_set,
- .set_config = gma_crtc_set_config,
- .destroy = gma_crtc_destroy,
- .page_flip = gma_crtc_page_flip,
- .enable_vblank = psb_enable_vblank,
- .disable_vblank = psb_disable_vblank,
- .get_vblank_counter = psb_get_vblank_counter,
-};
-
const struct gma_clock_funcs cdv_clock_funcs = {
.clock = cdv_intel_clock,
.limit = cdv_intel_limit,
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 08cd5f73c868..9650588c7223 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -548,7 +548,7 @@ const struct psb_ops oaktrail_chip_ops = {
.chip_setup = oaktrail_chip_setup,
.chip_teardown = oaktrail_teardown,
.crtc_helper = &oaktrail_helper_funcs,
- .crtc_funcs = &psb_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.output_init = oaktrail_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_device.c
b/drivers/gpu/drm/gma500/psb_device.c
index 2d21f8ec595f..951725a0f7a3 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -329,7 +329,7 @@ const struct psb_ops psb_chip_ops = {
.chip_teardown = psb_chip_teardown,
.crtc_helper = &psb_intel_helper_funcs,
- .crtc_funcs = &psb_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.clock_funcs = &psb_clock_funcs,
.output_init = psb_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index d4f14a5d509b..697f64e0f2f4 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -672,7 +672,7 @@ extern void oaktrail_lvds_init(struct drm_device *dev,
/* psb_intel_display.c */
extern const struct drm_crtc_helper_funcs psb_intel_helper_funcs;
-extern const struct drm_crtc_funcs psb_intel_crtc_funcs;
+extern const struct drm_crtc_funcs gma_intel_crtc_funcs;
/* psb_intel_lvds.c */
extern const struct drm_connector_helper_funcs
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9c3cb1b80bbd..359606429316 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -426,7 +426,7 @@ const struct drm_crtc_helper_funcs psb_intel_helper_funcs =
{
.disable = gma_crtc_disable,
};
-const struct drm_crtc_funcs psb_intel_crtc_funcs = {
+const struct drm_crtc_funcs gma_intel_crtc_funcs = {
.cursor_set = gma_crtc_cursor_set,
.cursor_move = gma_crtc_cursor_move,
.gamma_set = gma_crtc_gamma_set,
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedeskto
[PATCH 6/6] drm/gma500: Never wait for blits
Blits cannot happen anymore since we removed the 2d accel code. Stop
checking for a busy blitter and remove the remaining blitter code.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Makefile | 1 -
drivers/gpu/drm/gma500/blitter.c | 43
drivers/gpu/drm/gma500/blitter.h | 16
drivers/gpu/drm/gma500/gtt.c | 11
4 files changed, 71 deletions(-)
delete mode 100644 drivers/gpu/drm/gma500/blitter.c
delete mode 100644 drivers/gpu/drm/gma500/blitter.h
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 6ee1ef389979..8c649d3ef6a4 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -5,7 +5,6 @@
gma500_gfx-y += \
backlight.o \
- blitter.o \
cdv_device.o \
cdv_intel_crt.o \
cdv_intel_display.o \
diff --git a/drivers/gpu/drm/gma500/blitter.c b/drivers/gpu/drm/gma500/blitter.c
deleted file mode 100644
index cb2504a4a15f..
--- a/drivers/gpu/drm/gma500/blitter.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2014, Patrik Jakobsson
- * All Rights Reserved.
- *
- * Authors: Patrik Jakobsson
- */
-
-#include "psb_drv.h"
-
-#include "blitter.h"
-#include "psb_reg.h"
-
-/* Wait for the blitter to be completely idle */
-int gma_blt_wait_idle(struct drm_psb_private *dev_priv)
-{
- unsigned long stop = jiffies + HZ;
- int busy = 1;
-
- /* NOP for Cedarview */
- if (IS_CDV(dev_priv->dev))
- return 0;
-
- /* First do a quick check */
- if ((PSB_RSGX32(PSB_CR_2D_SOCIF) == _PSB_C2_SOCIF_EMPTY) &&
- ((PSB_RSGX32(PSB_CR_2D_BLIT_STATUS) & _PSB_C2B_STATUS_BUSY) == 0))
- return 0;
-
- do {
- busy = (PSB_RSGX32(PSB_CR_2D_SOCIF) != _PSB_C2_SOCIF_EMPTY);
- } while (busy && !time_after_eq(jiffies, stop));
-
- if (busy)
- return -EBUSY;
-
- do {
- busy = ((PSB_RSGX32(PSB_CR_2D_BLIT_STATUS) &
- _PSB_C2B_STATUS_BUSY) != 0);
- } while (busy && !time_after_eq(jiffies, stop));
-
- /* If still busy, we probably have a hang */
- return (busy) ? -EBUSY : 0;
-}
diff --git a/drivers/gpu/drm/gma500/blitter.h b/drivers/gpu/drm/gma500/blitter.h
deleted file mode 100644
index 8d67dabd9ba3..
--- a/drivers/gpu/drm/gma500/blitter.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (c) 2014, Patrik Jakobsson
- * All Rights Reserved.
- *
- * Authors: Patrik Jakobsson
- */
-
-#ifndef __BLITTER_H
-#define __BLITTER_H
-
-struct drm_psb_private;
-
-extern int gma_blt_wait_idle(struct drm_psb_private *dev_priv);
-
-#endif
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index e884750bc123..df9b611b856a 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -11,7 +11,6 @@
#include
-#include "blitter.h"
#include "psb_drv.h"
@@ -229,18 +228,9 @@ void psb_gtt_unpin(struct gtt_range *gt)
struct drm_device *dev = gt->gem.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
u32 gpu_base = dev_priv->gtt.gatt_start;
- int ret;
- /* While holding the gtt_mutex no new blits can be initiated */
mutex_lock(&dev_priv->gtt_mutex);
- /* Wait for any possible usage of the memory to be finished */
- ret = gma_blt_wait_idle(dev_priv);
- if (ret) {
- DRM_ERROR("Failed to idle the blitter, unpin failed!");
- goto out;
- }
-
WARN_ON(!gt->in_gart);
gt->in_gart--;
@@ -251,7 +241,6 @@ void psb_gtt_unpin(struct gtt_range *gt)
psb_gtt_detach_pages(gt);
}
-out:
mutex_unlock(&dev_priv->gtt_mutex);
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/gma500: psb_spank() doesn't need it's own file
Since everything else in accel_2d.c got removed we can move psb_spank()
into psb_drv.c where it is used.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Makefile | 1 -
drivers/gpu/drm/gma500/accel_2d.c | 60 ---
drivers/gpu/drm/gma500/psb_drv.c | 31
3 files changed, 31 insertions(+), 61 deletions(-)
delete mode 100644 drivers/gpu/drm/gma500/accel_2d.c
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 884ab1f9063e..6ee1ef389979 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -4,7 +4,6 @@
#
gma500_gfx-y += \
- accel_2d.o \
backlight.o \
blitter.o \
cdv_device.o \
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
deleted file mode 100644
index 437bbb6af9e6..
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ /dev/null
@@ -1,60 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/**
- * Copyright (c) 2007-2011, Intel Corporation.
- * All Rights Reserved.
- *
- * Intel funded Tungsten Graphics (http://www.tungstengraphics.com) to
- * develop this driver.
- *
- **/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include "psb_drv.h"
-#include "psb_reg.h"
-
-/**
- * psb_spank - reset the 2D engine
- * @dev_priv: our PSB DRM device
- *
- * Soft reset the graphics engine and then reload the necessary registers.
- * We use this at initialisation time but it will become relevant for
- * accelerated X later
- */
-void psb_spank(struct drm_psb_private *dev_priv)
-{
- PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
- _PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
- _PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
- _PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
- PSB_RSGX32(PSB_CR_SOFT_RESET);
-
- msleep(1);
-
- PSB_WSGX32(0, PSB_CR_SOFT_RESET);
- wmb();
- PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
- PSB_CR_BIF_CTRL);
- wmb();
- (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
-
- msleep(1);
- PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
- PSB_CR_BIF_CTRL);
- (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
- PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
-}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 0bcab065242c..bd55b0c4f4b3 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
@@ -92,6 +93,36 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static const struct drm_ioctl_desc psb_ioctls[] = {
};
+/**
+ * psb_spank - reset the 2D engine
+ * @dev_priv: our PSB DRM device
+ *
+ * Soft reset the graphics engine and then reload the necessary registers.
+ */
+void psb_spank(struct drm_psb_private *dev_priv)
+{
+ PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
+ _PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
+ _PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
+ _PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
+ PSB_RSGX32(PSB_CR_SOFT_RESET);
+
+ msleep(1);
+
+ PSB_WSGX32(0, PSB_CR_SOFT_RESET);
+ wmb();
+ PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
+ PSB_CR_BIF_CTRL);
+ wmb();
+ (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
+
+ msleep(1);
+ PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
+ PSB_CR_BIF_CTRL);
+ (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
+ PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
+}
+
static int psb_do_init(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver,
thanks for the patch :)
On 21-01-29 20:09, Oliver Graute wrote:
> Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> to panel-simple.
>
> The panel spec from Variscite can be found at:
> https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
>
> Signed-off-by: Oliver Graute
> Cc: Marco Felsch
> Cc: Fabio Estevam
> ---
>
> v2:
>
> - changed bpc to 6
> - set max value of pixelclock
> - increased hfront_porch and hback_porch
> - dropped connector-type
>
> adding of bus_format = MEDIA_BUS_FMT_RGB666_1X18 results in wrong colors.
> omitting bus_format and using some default is good (Tux Pinguin is colored
> fine)
>
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 2be358f..c129a8c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3336,6 +3336,28 @@ static const struct panel_desc satoz_sat050at40h12r2 =
> {
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> +static const struct display_timing sgd_gktw70sdad1sd_timing = {
> + .pixelclock = {3000, 3000, 4000},
> + .hactive = { 800, 800, 800},
> + .hfront_porch = {40, 40, 40},
> + .hback_porch = {40, 40, 40},
> + .hsync_len = {48, 48, 48},
> + .vactive = {480, 480, 480},
> + .vfront_porch = {13, 13, 13},
> + .vback_porch = {29, 29, 29},
> + .vsync_len = {3, 3, 3},
Please add also:
.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE,
> +};
> +
> +static const struct panel_desc sgd_gktw70sdad1sd = {
> + .timings = &sgd_gktw70sdad1sd_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 153,
> + .height = 86,
> + },
and:
.delay = {
.prepare = 20 + 20 + 10 + 10, /* T0 + T2 + T3 + T4 */
.enable = 50, /* T5 */
.disable = 50, /* T5 */
.unprepare = 10 + 10 + 20 + 20, /* T4 + T3 + T2 + T0 */
};
Regards,
Marco
> +};
> +
> static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
> .clock = 168480,
> .hdisplay = 1920,
> @@ -4222,6 +4244,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "satoz,sat050at40h12r2",
> .data = &satoz_sat050at40h12r2,
> }, {
> + .compatible = "sgd,gktw70sdad1sd",
> + .data = &sgd_gktw70sdad1sd,
> + }, {
> .compatible = "sharp,ld-d5116z01b",
> .data = &sharp_ld_d5116z01b,
> }, {
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: enable dither function
Hi, Hsin-Yi:
Chun-Kuang Hu 於 2021年2月1日 週一 上午12:20寫道：
>
> Hi, Hsin-Yi:
>
> Hsin-Yi Wang 於 2021年1月31日 週日 下午1:11寫道：
> >
> > From: Yongqiang Niu
> >
> > Enable dither function to improve the display quality.
>
> Reviewed-by: Chun-Kuang Hu
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
> >
> > Signed-off-by: Yongqiang Niu
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > Previous version:
> > https://patchwork.kernel.org/project/linux-mediatek/patch/20210129092209.2584718-7-hsi...@chromium.org/
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index c730029ac8fc7..0444b429daf00 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -53,6 +53,7 @@
> > #define DITHER_EN BIT(0)
> > #define DISP_DITHER_CFG0x0020
> > #define DITHER_RELAY_MODE BIT(0)
> > +#define DITHER_ENGINE_EN BIT(1)
> > #define DISP_DITHER_SIZE 0x0030
> >
> > #define LUT_10BIT_MASK 0x03ff
> > @@ -315,8 +316,12 @@ static void mtk_dither_config(struct device *dev,
> > unsigned int w,
> > {
> > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> >
> > - mtk_ddp_write(cmdq_pkt, h << 16 | w, &priv->cmdq_reg, priv->regs,
> > DISP_DITHER_SIZE);
> > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, &priv->cmdq_reg,
> > priv->regs, DISP_DITHER_CFG);
> > + mtk_ddp_write(cmdq_pkt, h << 16 | w, &priv->cmdq_reg, priv->regs,
> > + DISP_DITHER_SIZE);
> > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, &priv->cmdq_reg,
> > priv->regs,
> > + DISP_DITHER_CFG);
> > + mtk_dither_set_common(priv->regs, &priv->cmdq_reg, bpc,
> > DISP_DITHER_CFG,
> > + DITHER_ENGINE_EN, cmdq_pkt);
> > }
> >
> > static void mtk_dither_start(struct device *dev)
> > --
> > 2.30.0.365.g02bc693789-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs
On Mon, 1 Feb 2021 13:24:00 +
Steven Price wrote:
> On 01/02/2021 12:59, Boris Brezillon wrote:
> > On Mon, 1 Feb 2021 12:13:49 +
> > Steven Price wrote:
> >
> >> On 01/02/2021 08:21, Boris Brezillon wrote:
> >>> Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
> >>> in the threaded irq handler as long as we can.
> >>>
> >>> Signed-off-by: Boris Brezillon
> >>
> >> Looks fine to me, but I'm interested to know if you actually saw a
> >> performance improvement. Back-to-back MMU faults should (hopefully) be
> >> fairly uncommon.
> >
> > I actually didn't check the perf improvement or the actual number of
> > back-to-back MMU faults, but
> > dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_1000x1000_drawcount_5000
> > seemed to generate a few of those, so I thought it'd be good to
> > optimize that case given how trivial it is.
>
> Fair enough! I was just a little concerned that Panfrost was somehow
> provoking enough interrupts that this was a measurable performance
> improvement.
>
> I assume you'll push these to drm-misc-next (/fixes) as appropriate.
I think I'll just queue everything to misc-next and let the stable
maintainers backport the fixes (no one complained about this issue so
far).
>
> Thanks,
>
> Steve
>
> >>
> >> Regardless:
> >>
> >> Reviewed-by: Steven Price
> >>
> >>> ---
> >>>drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
> >>>1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >>> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >>> index 21e552d1ac71..65bc20628c4e 100644
> >>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >>> @@ -580,6 +580,8 @@ static irqreturn_t
> >>> panfrost_mmu_irq_handler_thread(int irq, void *data)
> >>> u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
> >>> int i, ret;
> >>>
> >>> +again:
> >>> +
> >>> for (i = 0; status; i++) {
> >>> u32 mask = BIT(i) | BIT(i + 16);
> >>> u64 addr;
> >>> @@ -628,6 +630,11 @@ static irqreturn_t
> >>> panfrost_mmu_irq_handler_thread(int irq, void *data)
> >>> status &= ~mask;
> >>> }
> >>>
> >>> + /* If we received new MMU interrupts, process them before returning. */
> >>> + status = mmu_read(pfdev, MMU_INT_RAWSTAT);
> >>> + if (status)
> >>> + goto again;
> >>> +
> >>> mmu_write(pfdev, MMU_INT_MASK, ~0);
> >>> return IRQ_HANDLED;
> >>>};
> >>>
> >>
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-core v7 4/6] pyverbs: Add dma-buf based MR support
On Mon, Feb 1, 2021 at 7:16 AM Leon Romanovsky wrote: > > On Sun, Jan 31, 2021 at 05:31:16PM +0200, Gal Pressman wrote: > > On 25/01/2021 21:57, Jianxin Xiong wrote: > > > Define a new sub-class of 'MR' that uses dma-buf object for the memory > > > region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation > > > mechanism implemented in C. > > > > > > Update the cmake function for cython modules to allow building modules > > > with mixed cython and c source files. > > > > > > Signed-off-by: Jianxin Xiong > > > --- > > > buildlib/pyverbs_functions.cmake | 78 +++ > > > pyverbs/CMakeLists.txt | 11 +- > > > pyverbs/dmabuf.pxd | 15 +++ > > > pyverbs/dmabuf.pyx | 73 ++ > > > pyverbs/dmabuf_alloc.c | 278 > > > +++ > > > pyverbs/dmabuf_alloc.h | 19 +++ > > > pyverbs/libibverbs.pxd | 2 + > > > pyverbs/mr.pxd | 6 + > > > pyverbs/mr.pyx | 105 ++- > > > 9 files changed, 557 insertions(+), 30 deletions(-) > > > create mode 100644 pyverbs/dmabuf.pxd > > > create mode 100644 pyverbs/dmabuf.pyx > > > create mode 100644 pyverbs/dmabuf_alloc.c > > > create mode 100644 pyverbs/dmabuf_alloc.h > > <...> > > > > index 000..05eae75 > > > --- /dev/null > > > +++ b/pyverbs/dmabuf_alloc.c > > > @@ -0,0 +1,278 @@ > > > +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB > > > +/* > > > + * Copyright 2020 Intel Corporation. All rights reserved. See COPYING > > > file > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > > I assume these should come from the kernel headers package, right? > > This is gross, all kernel headers should be placed in kernel-headers/* > and "update" script needs to be extended to take drm/* files too :(. drm kernel headers are in the libdrm package. You need that anyway for doing the ioctls (if you don't hand-roll the restarting yourself). Also our userspace has gone over to just outright copying the driver headers. Not the generic headers, but for the rendering side of gpus, which is the topic here, there's really not much generic stuff. > Jianxin, are you fixing it? So fix is either to depend upon libdrm for building, or have copies of the headers included in the package for the i915/amdgpu/radeon headers (drm/drm.h probably not so good idea). Cheers, Daniel > > Thanks > ___ > 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 v2 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel
On Mon, 01 Feb 2021 12:37:10 +0200, Iskren Chernev wrote: > The Samsung S6E3FA2 AMOLED cmd LCD panel is used on the Samsung Galaxy > S5 (klte). > > Signed-off-by: Iskren Chernev > --- > OK, miraculously the panel turns on and off now, so the simple-panel can > graduate into its own driver. > > v1: https://lkml.org/lkml/2020/12/30/293 > > Changes in v2: > - move bindings to separate file, add 2 regulators > - add standalone panel driver > > .../display/panel/samsung,s6e3fa2.yaml| 62 +++ > 1 file changed, 62 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.example.dts:28.50-51 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:344: Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1370: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1434112 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/gma500: Remove dependency on TTM
The gma500 driver does not use TTM. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/gma500/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index c1f6e12cd3ea..cd3138ed8006 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,7 +3,6 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER - select DRM_TTM # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/gma500: Remove Medfield
(was: drm/gma500: Remove Moorestown/Medfield) Support for the Medfield platform is being removed fromthe kernel. So here's a patch to remove the related code from the gma500 driver. On top of that I also cleaned up the configuration a bit. Note that Poulsbo, Oak Trail and Cedar Trail is still there and will remain. With Medfield gone, there might be a chance of cleaning up the remaining code. I smoke tested the patchset by running Xorg and Weston on a Cedartrail system. v2: * restore Moorestown/Oak Trail in the patchset (Patrik) Thomas Zimmermann (4): drm/gma500: Remove Medfield support drm/gma500: Drop DRM_GMA600 and DRM_GMA3600 config options drm/gma500: Remove CONFIG_X86 conditionals from source files drm/gma500: Remove dependency on TTM drivers/gpu/drm/gma500/Kconfig| 28 +- drivers/gpu/drm/gma500/Makefile | 50 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c |4 - drivers/gpu/drm/gma500/mdfld_device.c | 564 - drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 1017 - drivers/gpu/drm/gma500/mdfld_dsi_dpi.h| 79 -- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 603 -- drivers/gpu/drm/gma500/mdfld_dsi_output.h | 377 -- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 679 --- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h | 80 -- drivers/gpu/drm/gma500/mdfld_intel_display.c | 966 drivers/gpu/drm/gma500/mdfld_output.c | 74 -- drivers/gpu/drm/gma500/mdfld_output.h | 76 -- drivers/gpu/drm/gma500/mdfld_tmd_vid.c| 197 drivers/gpu/drm/gma500/mdfld_tpo_vid.c| 83 -- drivers/gpu/drm/gma500/mmu.c | 21 - drivers/gpu/drm/gma500/psb_drv.c | 19 +- drivers/gpu/drm/gma500/psb_drv.h | 67 -- drivers/gpu/drm/gma500/psb_intel_drv.h|4 - drivers/gpu/drm/gma500/psb_intel_reg.h| 12 +- drivers/gpu/drm/gma500/psb_irq.c | 72 +- drivers/gpu/drm/gma500/psb_irq.h |2 - drivers/gpu/drm/gma500/psb_reg.h | 14 - drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c| 805 - drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h| 38 - 25 files changed, 27 insertions(+), 5904 deletions(-) delete mode 100644 drivers/gpu/drm/gma500/mdfld_device.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_dpi.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_output.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_output.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_intel_display.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_output.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_output.h delete mode 100644 drivers/gpu/drm/gma500/mdfld_tmd_vid.c delete mode 100644 drivers/gpu/drm/gma500/mdfld_tpo_vid.c delete mode 100644 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c delete mode 100644 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h base-commit: f9173d6435c6a9bb0b0076ebf9122d876da208ae prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/gma500: Drop DRM_GMA600 and DRM_GMA3600 config options
With support for the MID-only Medfield chips removed, simply build
the complete driver if DRM_GMA500 has been selected. Anyone who wants
to enable one of the chips would probably also want the rest.
v2:
* also drop CONFIG_DRM_GMA600
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/Kconfig | 20 +++-
drivers/gpu/drm/gma500/Makefile | 40 +++-
drivers/gpu/drm/gma500/psb_drv.c | 7 +++---
3 files changed, 25 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index b05116f15d97..c1f6e12cd3ea 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_GMA500
- tristate "Intel GMA5/600 KMS Framebuffer"
+ tristate "Intel GMA500/600/3600/3650 KMS Framebuffer"
depends on DRM && PCI && X86 && MMU
select DRM_KMS_HELPER
select DRM_TTM
@@ -10,19 +10,5 @@ config DRM_GMA500
select INPUT if ACPI
help
Say yes for an experimental 2D KMS framebuffer driver for the
- Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
- devices.
-
-config DRM_GMA600
- bool "Intel GMA600 support (Experimental)"
- depends on DRM_GMA500
- help
- Say yes to include support for GMA600 (Intel Moorestown/Oaktrail)
- platforms with LVDS ports. MIPI is not currently supported.
-
-config DRM_GMA3600
- bool "Intel GMA3600/3650 support (Experimental)"
- depends on DRM_GMA500
- help
- Say yes to include basic support for Intel GMA3600/3650 (Intel
- Cedar Trail) platforms.
+ Intel GMA500 ('Poulsbo'), Intel GMA600 (Moorestown/Oak Trail) and
+ Intel GMA3600/3650 (Intel Cedar Trail).
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index f7dded3784fb..0518cff60740 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -6,41 +6,39 @@
gma500_gfx-y += \
accel_2d.o \
backlight.o \
+ blitter.o \
+ cdv_device.o \
+ cdv_intel_crt.o \
+ cdv_intel_display.o \
+ cdv_intel_dp.o \
+ cdv_intel_hdmi.o \
+ cdv_intel_lvds.o \
framebuffer.o \
gem.o \
+ gma_device.o \
+ gma_display.o \
gtt.o \
intel_bios.o \
- intel_i2c.o \
intel_gmbus.o \
+ intel_i2c.o \
+ mid_bios.o \
mmu.o \
- blitter.o \
+ oaktrail_crtc.o \
+ oaktrail_device.o \
+ oaktrail_hdmi.o \
+ oaktrail_hdmi_i2c.o \
+ oaktrail_lvds.o \
+ oaktrail_lvds_i2c.o \
power.o \
+ psb_device.o \
psb_drv.o \
- gma_display.o \
- gma_device.o \
psb_intel_display.o \
psb_intel_lvds.o \
psb_intel_modes.o \
psb_intel_sdvo.o \
- psb_lid.o \
psb_irq.o \
- psb_device.o \
- mid_bios.o
+ psb_lid.o
gma500_gfx-$(CONFIG_ACPI) += opregion.o \
-gma500_gfx-$(CONFIG_DRM_GMA3600) += cdv_device.o \
- cdv_intel_crt.o \
- cdv_intel_display.o \
- cdv_intel_hdmi.o \
- cdv_intel_lvds.o \
- cdv_intel_dp.o
-
-gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \
- oaktrail_crtc.o \
- oaktrail_lvds.o \
- oaktrail_lvds_i2c.o \
- oaktrail_hdmi.o \
- oaktrail_hdmi_i2c.o
-
obj-$(CONFIG_DRM_GMA500) += gma500_gfx.o
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index b083b3f815b9..538974c37adb 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -51,9 +51,10 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
* N2800
*/
static const struct pci_device_id pciidlist[] = {
+ /* Poulsbo */
{ 0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops },
{ 0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops },
-#if defined(CONFIG_DRM_GMA600)
+ /* Oak Trail */
{ 0x8086, 0x4100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
{ 0x8086, 0x4101, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
{ 0x8086, 0x4102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
@@ -63,8 +64,7 @@ static const struct pci_device_id pciidlist[] = {
{ 0x8086, 0x4106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
{ 0x8086, 0x4107, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
{ 0x8086, 0x4108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long)
&oaktrail_chip_ops },
-#endif
-#if defined(CONFIG_DRM_GMA3600)
+ /* Cedar Trail */
{ 0x8086, 0x0be0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops },
{ 0x8086, 0x0be1, P
[PATCH v2 3/4] drm/gma500: Remove CONFIG_X86 conditionals from source files
Remove the CONFIG_X86 conditionals from the source code. The driver
already depends on X86 in the Kconfig file. Also, no one has been
trying to build it on a non-x86 platform recently, or they would have
noticed that drm_ttm_cache_flush() doesn't exist.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/mmu.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
index 13aff19aae9b..d856580b8111 100644
--- a/drivers/gpu/drm/gma500/mmu.c
+++ b/drivers/gpu/drm/gma500/mmu.c
@@ -48,7 +48,6 @@ static inline uint32_t psb_mmu_pd_index(uint32_t offset)
return offset >> PSB_PDE_SHIFT;
}
-#if defined(CONFIG_X86)
static inline void psb_clflush(void *addr)
{
__asm__ __volatile__("clflush (%0)\n" : : "r"(addr) : "memory");
@@ -63,13 +62,6 @@ static inline void psb_mmu_clflush(struct psb_mmu_driver
*driver, void *addr)
psb_clflush(addr);
mb();
}
-#else
-
-static inline void psb_mmu_clflush(struct psb_mmu_driver *driver, void *addr)
-{;
-}
-
-#endif
static void psb_mmu_flush_pd_locked(struct psb_mmu_driver *driver, int force)
{
@@ -293,7 +285,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
*ptes++ = pd->invalid_pte;
-#if defined(CONFIG_X86)
if (pd->driver->has_clflush && pd->hw_context != -1) {
mb();
for (i = 0; i < clflush_count; ++i) {
@@ -302,7 +293,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
}
mb();
}
-#endif
kunmap_atomic(v);
spin_unlock(lock);
@@ -459,7 +449,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
driver->has_clflush = 0;
-#if defined(CONFIG_X86)
if (boot_cpu_has(X86_FEATURE_CLFLUSH)) {
uint32_t tfms, misc, cap0, cap4, clflush_size;
@@ -476,7 +465,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
driver->clflush_mask = driver->clflush_add - 1;
driver->clflush_mask = ~driver->clflush_mask;
}
-#endif
up_write(&driver->sem);
return driver;
@@ -486,7 +474,6 @@ struct psb_mmu_driver *psb_mmu_driver_init(struct
drm_device *dev,
return NULL;
}
-#if defined(CONFIG_X86)
static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd, unsigned long address,
uint32_t num_pages, uint32_t desired_tile_stride,
uint32_t hw_tile_stride)
@@ -534,14 +521,6 @@ static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd,
unsigned long address,
}
mb();
}
-#else
-static void psb_mmu_flush_ptes(struct psb_mmu_pd *pd, unsigned long address,
- uint32_t num_pages, uint32_t desired_tile_stride,
- uint32_t hw_tile_stride)
-{
- drm_ttm_cache_flush();
-}
-#endif
void psb_mmu_remove_pfn_sequence(struct psb_mmu_pd *pd,
unsigned long address, uint32_t num_pages)
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/gma500/cdv: Remove unused code for crt init
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
Clearly never been used so just remove it.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index c48c9d322dfb..4a9bb4994a26 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -248,8 +248,6 @@ void cdv_intel_crt_init(struct drm_device *dev,
struct drm_connector *connector;
struct drm_encoder *encoder;
- u32 i2c_reg;
-
gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
if (!gma_encoder)
return;
@@ -269,24 +267,13 @@ void cdv_intel_crt_init(struct drm_device *dev,
gma_connector_attach_encoder(gma_connector, gma_encoder);
/* Set up the DDC bus. */
- i2c_reg = GPIOA;
- /* Remove the following code for CDV */
- /*
- if (dev_priv->crt_ddc_bus != 0)
- i2c_reg = dev_priv->crt_ddc_bus;
- }*/
- gma_encoder->ddc_bus = psb_intel_i2c_create(dev,
- i2c_reg, "CRTDDC_A");
+ gma_encoder->ddc_bus = psb_intel_i2c_create(dev, GPIOA, "CRTDDC_A");
if (!gma_encoder->ddc_bus) {
dev_printk(KERN_ERR, dev->dev, "DDC bus registration
failed.\n");
goto failed_ddc;
}
gma_encoder->type = INTEL_OUTPUT_ANALOG;
- /*
- psb_intel_output->clone_mask = (1 << INTEL_ANALOG_CLONE_BIT);
- psb_intel_output->crtc_mask = (1 << 0) | (1 << 1);
- */
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/gma500: Remove unused DPST support
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
DPST never got enabled so remove it. We keep the reg save/restore code
just for safety.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.h | 4 -
drivers/gpu/drm/gma500/psb_intel_reg.h | 32 ---
drivers/gpu/drm/gma500/psb_irq.c | 110 -
drivers/gpu/drm/gma500/psb_irq.h | 4 -
4 files changed, 150 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 020a71b91577..d4f14a5d509b 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -622,13 +622,9 @@ static inline struct drm_psb_private *psb_priv(struct
drm_device *dev)
/* psb_irq.c */
extern irqreturn_t psb_irq_handler(int irq, void *arg);
-extern int psb_irq_enable_dpst(struct drm_device *dev);
-extern int psb_irq_disable_dpst(struct drm_device *dev);
extern void psb_irq_preinstall(struct drm_device *dev);
extern int psb_irq_postinstall(struct drm_device *dev);
extern void psb_irq_uninstall(struct drm_device *dev);
-extern void psb_irq_turn_on_dpst(struct drm_device *dev);
-extern void psb_irq_turn_off_dpst(struct drm_device *dev);
extern void psb_irq_uninstall_islands(struct drm_device *dev, int hw_islands);
extern int psb_vblank_wait2(struct drm_device *dev, unsigned int *sequence);
diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index 364ea8f06f9c..ced7b433befb 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -550,38 +550,6 @@
#define HISTOGRAM_INT_CTRL_CLEAR (1UL << 30)
#define DPST_YUV_LUMA_MODE0
-struct dpst_ie_histogram_control {
- union {
- uint32_t data;
- struct {
- uint32_t bin_reg_index:7;
- uint32_t reserved:4;
- uint32_t bin_reg_func_select:1;
- uint32_t sync_to_phase_in:1;
- uint32_t alt_enhancement_mode:2;
- uint32_t reserved1:1;
- uint32_t sync_to_phase_in_count:8;
- uint32_t histogram_mode_select:1;
- uint32_t reserved2:4;
- uint32_t ie_pipe_assignment:1;
- uint32_t ie_mode_table_enabled:1;
- uint32_t ie_histogram_enable:1;
- };
- };
-};
-
-struct dpst_guardband {
- union {
- uint32_t data;
- struct {
- uint32_t guardband:22;
- uint32_t guardband_interrupt_delay:8;
- uint32_t interrupt_status:1;
- uint32_t interrupt_enable:1;
- };
- };
-};
-
#define PIPEAFRAMEHIGH0x70040
#define PIPEAFRAMEPIXEL 0x70044
#define PIPEBFRAMEHIGH0x71040
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index ae9b100e640b..104009e78487 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -101,30 +101,6 @@ psb_disable_pipestat(struct drm_psb_private *dev_priv, int
pipe, u32 mask)
}
}
-static void mid_enable_pipe_event(struct drm_psb_private *dev_priv, int pipe)
-{
- if (gma_power_begin(dev_priv->dev, false)) {
- u32 pipe_event = mid_pipe_event(pipe);
- dev_priv->vdc_irq_mask |= pipe_event;
- PSB_WVDC32(~dev_priv->vdc_irq_mask, PSB_INT_MASK_R);
- PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
- gma_power_end(dev_priv->dev);
- }
-}
-
-static void mid_disable_pipe_event(struct drm_psb_private *dev_priv, int pipe)
-{
- if (dev_priv->pipestat[pipe] == 0) {
- if (gma_power_begin(dev_priv->dev, false)) {
- u32 pipe_event = mid_pipe_event(pipe);
- dev_priv->vdc_irq_mask &= ~pipe_event;
- PSB_WVDC32(~dev_priv->vdc_irq_mask, PSB_INT_MASK_R);
- PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
- gma_power_end(dev_priv->dev);
- }
- }
-}
-
/*
* Display controller interrupt handler for pipe event.
*/
@@ -392,92 +368,6 @@ void psb_irq_uninstall(struct drm_device *dev)
spin_unlock_irqrestore(&dev_priv->irqmask_lock, irqflags);
}
-void psb_irq_turn_on_dpst(struct drm_device *dev)
-{
- struct drm_psb_private *dev_priv =
- (struct drm_psb_private *) dev->dev_private;
- u32 hist_reg;
- u32 pwm_reg;
-
- if (gma_power_begin(dev, false)) {
- PSB_WVDC32(1 << 31, HISTOGRAM_LOGIC_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_LOGIC_CONTROL);
- PSB_WVDC32(1 << 31, HISTOGRAM_I
Re: [PATCH 3/6] drm/gma500/cdv: Remove unused tv out paths
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
Afaik tv out is not available on Cedarview and the code isn't doing
anything so remove it.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 5d3302249779..aac776fab36d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -582,7 +582,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct gma_clock_t clock;
u32 dpll = 0, dspcntr, pipeconf;
bool ok;
- bool is_lvds = false, is_tv = false;
+ bool is_lvds = false;
bool is_dp = false;
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
@@ -603,9 +603,6 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
case INTEL_OUTPUT_LVDS:
is_lvds = true;
break;
- case INTEL_OUTPUT_TVOUT:
- is_tv = true;
- break;
case INTEL_OUTPUT_ANALOG:
case INTEL_OUTPUT_HDMI:
break;
@@ -660,12 +657,6 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
}
dpll = DPLL_VGA_MODE_DIS;
- if (is_tv) {
- /* XXX: just matching BIOS for now */
-/* dpll |= PLL_REF_INPUT_TVCLKINBC; */
- dpll |= 3;
- }
-/* dpll |= PLL_REF_INPUT_DREFCLK; */
if (is_dp || is_edp) {
cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/gma500: Unify crtc helpers
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
CDV crtc helpers are identical to other chips so use gma_ prefix for the
crtc helper struct and remove the CDV copy.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_device.c| 2 +-
drivers/gpu/drm/gma500/cdv_device.h| 1 -
drivers/gpu/drm/gma500/cdv_intel_display.c | 12
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/psb_device.c| 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
7 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 19e055dbd4c2..1342e7fb382f 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -603,7 +603,7 @@ const struct psb_ops cdv_chip_ops = {
.errata = cdv_errata,
.crtc_helper = &cdv_intel_helper_funcs,
- .crtc_funcs = &cdv_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.clock_funcs = &cdv_clock_funcs,
.output_init = cdv_output_init,
diff --git a/drivers/gpu/drm/gma500/cdv_device.h
b/drivers/gpu/drm/gma500/cdv_device.h
index 37e4bdc84c03..504d717385cd 100644
--- a/drivers/gpu/drm/gma500/cdv_device.h
+++ b/drivers/gpu/drm/gma500/cdv_device.h
@@ -8,7 +8,6 @@ struct drm_device;
struct psb_intel_mode_device;
extern const struct drm_crtc_helper_funcs cdv_intel_helper_funcs;
-extern const struct drm_crtc_funcs cdv_intel_crtc_funcs;
extern const struct gma_clock_funcs cdv_clock_funcs;
extern void cdv_intel_crt_init(struct drm_device *dev,
struct psb_intel_mode_device *mode_dev);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index aac776fab36d..c3a9f6b3c848 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -961,18 +961,6 @@ const struct drm_crtc_helper_funcs cdv_intel_helper_funcs
= {
.disable = gma_crtc_disable,
};
-const struct drm_crtc_funcs cdv_intel_crtc_funcs = {
- .cursor_set = gma_crtc_cursor_set,
- .cursor_move = gma_crtc_cursor_move,
- .gamma_set = gma_crtc_gamma_set,
- .set_config = gma_crtc_set_config,
- .destroy = gma_crtc_destroy,
- .page_flip = gma_crtc_page_flip,
- .enable_vblank = psb_enable_vblank,
- .disable_vblank = psb_disable_vblank,
- .get_vblank_counter = psb_get_vblank_counter,
-};
-
const struct gma_clock_funcs cdv_clock_funcs = {
.clock = cdv_intel_clock,
.limit = cdv_intel_limit,
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 08cd5f73c868..9650588c7223 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -548,7 +548,7 @@ const struct psb_ops oaktrail_chip_ops = {
.chip_setup = oaktrail_chip_setup,
.chip_teardown = oaktrail_teardown,
.crtc_helper = &oaktrail_helper_funcs,
- .crtc_funcs = &psb_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.output_init = oaktrail_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_device.c b/drivers/gpu/drm/gma500/psb_device.c
index 2d21f8ec595f..951725a0f7a3 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -329,7 +329,7 @@ const struct psb_ops psb_chip_ops = {
.chip_teardown = psb_chip_teardown,
.crtc_helper = &psb_intel_helper_funcs,
- .crtc_funcs = &psb_intel_crtc_funcs,
+ .crtc_funcs = &gma_intel_crtc_funcs,
.clock_funcs = &psb_clock_funcs,
.output_init = psb_output_init,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index d4f14a5d509b..697f64e0f2f4 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -672,7 +672,7 @@ extern void oaktrail_lvds_init(struct drm_device *dev,
/* psb_intel_display.c */
extern const struct drm_crtc_helper_funcs psb_intel_helper_funcs;
-extern const struct drm_crtc_funcs psb_intel_crtc_funcs;
+extern const struct drm_crtc_funcs gma_intel_crtc_funcs;
/* psb_intel_lvds.c */
extern const struct drm_connector_helper_funcs
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9c3cb1b80bbd..359606429316 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -426,7 +426,7 @@ const struct drm_crtc_helper_funcs psb_intel_helper_funcs =
{
.disable = gma_crtc_disable,
};
-const struct drm_crtc_funcs psb_intel_crtc_funcs = {
+const struct drm_crtc_funcs gma_intel_crtc_funcs = {
.cursor_set = gma_crtc_cursor_set,
.cursor_move = gma_crtc_cursor_move,
.gamma_set = gma_crtc_gamma_set,
--
Th
Re: [PATCH 5/6] drm/gma500: psb_spank() doesn't need it's own file
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
Since everything else in accel_2d.c got removed we can move psb_spank()
into psb_drv.c where it is used.
Nit: I think one says 'it is being used'.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/Makefile | 1 -
drivers/gpu/drm/gma500/accel_2d.c | 60 ---
drivers/gpu/drm/gma500/psb_drv.c | 31
3 files changed, 31 insertions(+), 61 deletions(-)
delete mode 100644 drivers/gpu/drm/gma500/accel_2d.c
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 884ab1f9063e..6ee1ef389979 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -4,7 +4,6 @@
#
gma500_gfx-y += \
- accel_2d.o \
backlight.o \
blitter.o \
cdv_device.o \
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
deleted file mode 100644
index 437bbb6af9e6..
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ /dev/null
@@ -1,60 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/**
- * Copyright (c) 2007-2011, Intel Corporation.
- * All Rights Reserved.
- *
- * Intel funded Tungsten Graphics (http://www.tungstengraphics.com) to
- * develop this driver.
- *
- **/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include "psb_drv.h"
-#include "psb_reg.h"
-
-/**
- * psb_spank - reset the 2D engine
- * @dev_priv: our PSB DRM device
- *
- * Soft reset the graphics engine and then reload the necessary registers.
- * We use this at initialisation time but it will become relevant for
- * accelerated X later
- */
-void psb_spank(struct drm_psb_private *dev_priv)
-{
- PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
- _PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
- _PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
- _PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
- PSB_RSGX32(PSB_CR_SOFT_RESET);
-
- msleep(1);
-
- PSB_WSGX32(0, PSB_CR_SOFT_RESET);
- wmb();
- PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
- PSB_CR_BIF_CTRL);
- wmb();
- (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
-
- msleep(1);
- PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
- PSB_CR_BIF_CTRL);
- (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
- PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
-}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 0bcab065242c..bd55b0c4f4b3 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
@@ -92,6 +93,36 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static const struct drm_ioctl_desc psb_ioctls[] = {
};
+/**
+ * psb_spank - reset the 2D engine
+ * @dev_priv: our PSB DRM device
+ *
+ * Soft reset the graphics engine and then reload the necessary registers.
+ */
+void psb_spank(struct drm_psb_private *dev_priv)
+{
+ PSB_WSGX32(_PSB_CS_RESET_BIF_RESET | _PSB_CS_RESET_DPM_RESET |
+ _PSB_CS_RESET_TA_RESET | _PSB_CS_RESET_USE_RESET |
+ _PSB_CS_RESET_ISP_RESET | _PSB_CS_RESET_TSP_RESET |
+ _PSB_CS_RESET_TWOD_RESET, PSB_CR_SOFT_RESET);
+ PSB_RSGX32(PSB_CR_SOFT_RESET);
+
+ msleep(1);
+
+ PSB_WSGX32(0, PSB_CR_SOFT_RESET);
+ wmb();
+ PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) | _PSB_CB_CTRL_CLEAR_FAULT,
+ PSB_CR_BIF_CTRL);
+ wmb();
+ (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
+
+ msleep(1);
+ PSB_WSGX32(PSB_RSGX32(PSB_CR_BIF_CTRL) & ~_PSB_CB_CTRL_CLEAR_FAULT,
+ PSB_CR_BIF_CTRL);
+ (void) PSB_RSGX32(PSB_CR_BIF_CTRL);
+ PSB_WSGX32(dev_priv->gtt.gatt_start, PSB_CR_BIF_TWOD_REQ_BASE);
+}
+
static int psb_do_init(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/gma500: Never wait for blits
Am 01.02.21 um 14:26 schrieb Patrik Jakobsson:
Blits cannot happen anymore since we removed the 2d accel code. Stop
checking for a busy blitter and remove the remaining blitter code.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/Makefile | 1 -
drivers/gpu/drm/gma500/blitter.c | 43
drivers/gpu/drm/gma500/blitter.h | 16
drivers/gpu/drm/gma500/gtt.c | 11
4 files changed, 71 deletions(-)
delete mode 100644 drivers/gpu/drm/gma500/blitter.c
delete mode 100644 drivers/gpu/drm/gma500/blitter.h
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 6ee1ef389979..8c649d3ef6a4 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -5,7 +5,6 @@
gma500_gfx-y += \
backlight.o \
- blitter.o \
cdv_device.o \
cdv_intel_crt.o \
cdv_intel_display.o \
diff --git a/drivers/gpu/drm/gma500/blitter.c b/drivers/gpu/drm/gma500/blitter.c
deleted file mode 100644
index cb2504a4a15f..
--- a/drivers/gpu/drm/gma500/blitter.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2014, Patrik Jakobsson
- * All Rights Reserved.
- *
- * Authors: Patrik Jakobsson
- */
-
-#include "psb_drv.h"
-
-#include "blitter.h"
-#include "psb_reg.h"
-
-/* Wait for the blitter to be completely idle */
-int gma_blt_wait_idle(struct drm_psb_private *dev_priv)
-{
- unsigned long stop = jiffies + HZ;
- int busy = 1;
-
- /* NOP for Cedarview */
- if (IS_CDV(dev_priv->dev))
- return 0;
-
- /* First do a quick check */
- if ((PSB_RSGX32(PSB_CR_2D_SOCIF) == _PSB_C2_SOCIF_EMPTY) &&
- ((PSB_RSGX32(PSB_CR_2D_BLIT_STATUS) & _PSB_C2B_STATUS_BUSY) == 0))
- return 0;
-
- do {
- busy = (PSB_RSGX32(PSB_CR_2D_SOCIF) != _PSB_C2_SOCIF_EMPTY);
- } while (busy && !time_after_eq(jiffies, stop));
-
- if (busy)
- return -EBUSY;
-
- do {
- busy = ((PSB_RSGX32(PSB_CR_2D_BLIT_STATUS) &
- _PSB_C2B_STATUS_BUSY) != 0);
- } while (busy && !time_after_eq(jiffies, stop));
-
- /* If still busy, we probably have a hang */
- return (busy) ? -EBUSY : 0;
-}
diff --git a/drivers/gpu/drm/gma500/blitter.h b/drivers/gpu/drm/gma500/blitter.h
deleted file mode 100644
index 8d67dabd9ba3..
--- a/drivers/gpu/drm/gma500/blitter.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (c) 2014, Patrik Jakobsson
- * All Rights Reserved.
- *
- * Authors: Patrik Jakobsson
- */
-
-#ifndef __BLITTER_H
-#define __BLITTER_H
-
-struct drm_psb_private;
-
-extern int gma_blt_wait_idle(struct drm_psb_private *dev_priv);
-
-#endif
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index e884750bc123..df9b611b856a 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -11,7 +11,6 @@
#include
-#include "blitter.h"
#include "psb_drv.h"
@@ -229,18 +228,9 @@ void psb_gtt_unpin(struct gtt_range *gt)
struct drm_device *dev = gt->gem.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
u32 gpu_base = dev_priv->gtt.gatt_start;
- int ret;
- /* While holding the gtt_mutex no new blits can be initiated */
mutex_lock(&dev_priv->gtt_mutex);
- /* Wait for any possible usage of the memory to be finished */
- ret = gma_blt_wait_idle(dev_priv);
- if (ret) {
- DRM_ERROR("Failed to idle the blitter, unpin failed!");
- goto out;
- }
-
WARN_ON(!gt->in_gart);
gt->in_gart--;
@@ -251,7 +241,6 @@ void psb_gtt_unpin(struct gtt_range *gt)
psb_gtt_detach_pages(gt);
}
-out:
mutex_unlock(&dev_priv->gtt_mutex);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL
Adding gpu folks. On Tue, Nov 03, 2020 at 03:28:05PM -0800, Alexei Starovoitov wrote: > On Tue, Nov 03, 2020 at 05:57:47PM -0500, Kenny Ho wrote: > > On Tue, Nov 3, 2020 at 4:04 PM Alexei Starovoitov > > wrote: > > > > > > On Tue, Nov 03, 2020 at 02:19:22PM -0500, Kenny Ho wrote: > > > > On Tue, Nov 3, 2020 at 12:43 AM Alexei Starovoitov > > > > wrote: > > > > > On Mon, Nov 2, 2020 at 9:39 PM Kenny Ho wrote: > > > > > > Sounds like either bpf_lsm needs to be made aware of cgv2 (which would > > > be a great thing to have regardless) or cgroup-bpf needs a drm/gpu > > > specific hook. > > > I think generic ioctl hook is too broad for this use case. > > > I suspect drm/gpu internal state would be easier to access inside > > > bpf program if the hook is next to gpu/drm. At ioctl level there is > > > 'file'. > > > It's probably too abstract for the things you want to do. > > > Like how VRAM/shader/etc can be accessed through file? > > > Probably possible through a bunch of lookups and dereferences, but > > > if the hook is custom to GPU that info is likely readily available. > > > Then such cgroup-bpf check would be suitable in execution paths where > > > ioctl-based hook would be too slow. > > Just to clarify, when you say drm specific hook, did you mean just a > > unique attach_type or a unique prog_type+attach_type combination? (I > > am still a bit fuzzy on when a new prog type is needed vs a new attach > > type. I think prog type is associated with a unique type of context > > that the bpf prog will get but I could be missing some nuances.) > > > > When I was thinking of doing an ioctl wide hook, the file would be the > > device file and the thinking was to have a helper function provided by > > device drivers to further disambiguate. For our (AMD's) driver, we > > have a bunch of ioctls for set/get/create/destroy > > (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c#L1763) > > so the bpf prog can make the decision after the disambiguation. For > > example, we have an ioctl called "kfd_ioctl_set_cu_mask." You can > > Thanks for the pointer. > That's one monster ioctl. So much copy_from_user. > BPF prog would need to be sleepable to able to examine the args in such depth. > After quick glance at the code I would put a new hook into > kfd_ioctl() right before > retcode = func(filep, process, kdata); > At this point kdata is already copied from user space > and usize, that is cmd specific, is known. > So bpf prog wouldn't need to copy that data again. > That will save one copy. > To drill into details of kfd_ioctl_set_cu_mask() the prog would > need to be sleepable to do second copy_from_user of cu_mask. > At least it's not that big. > Yes, the attachment point will be amd driver specific, > but the program doesn't need to be. > It can be generic tracing prog that is agumented to use BTF. > Something like writeable tracepoint with BTF support would do. > So on the bpf side there will be minimal amount of changes. > And in the driver you'll add one or few writeable tracepoints > and the result of the tracepoint will gate > retcode = func(filep, process, kdata); > call in kfd_ioctl(). > The writeable tracepoint would need to be cgroup-bpf based. > So that's the only tricky part. BPF infra doesn't have > cgroup+tracepoint scheme. It's probably going to be useful > in other cases like this. See trace_nbd_send_request. Yeah I think this proposal doesn't work: - inspecting ioctl arguments that need copying outside of the driver/subsystem doing that copying is fundamentally racy - there's been a pile of cgroups proposal to manage gpus at the drm subsystem level, some by Kenny, and frankly this at least looks a bit like a quick hack to sidestep the consensus process for that. So once we push this into drivers it's not going to be a bpf hook anymore I think. Cheers, 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
Re: [PATCH] efifb: Ensure graphics device for efifb stays at PCI D0
On Sat, Jan 30, 2021 at 6:27 AM Kai-Heng Feng wrote: > > We are seeing root ports on some desktop boards support D3cold for > discrete graphics card. So when efifb is in use while graphics device > isn't bound to a driver, PCI and ACPI will put the graphics to D3cold > when runtime suspend kicks in, makes efifb stop working. > > So ensure the graphics device won't be runtime suspended, to keep efifb > work all the time. > > Signed-off-by: Kai-Heng Feng Reviewed-by: Alex Deucher > --- > drivers/video/fbdev/efifb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index e57c00824965..19edd7206409 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include /* For drm_get_panel_orientation_quirk */ > @@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev) > goto err_fb_dealoc; > } > fb_info(info, "%s frame buffer device\n", info->fix.id); > + pm_runtime_get_sync(&efifb_pci_dev->dev); > return 0; > > err_fb_dealoc: > @@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev) > unregister_framebuffer(info); > sysfs_remove_groups(&pdev->dev.kobj, efifb_groups); > framebuffer_release(info); > + pm_runtime_put(&efifb_pci_dev->dev); > > return 0; > } > -- > 2.29.2 > > ___ > 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 3/5] drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler
On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
wrote:
>
> Il 31/01/21 20:50, Rob Clark ha scritto:
> > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > wrote:
> >>
> >> The VCO rate was being miscalculated due to a big overlook during
> >> the process of porting this driver from downstream to upstream:
> >> here we are really recalculating the rate of the VCO by reading
> >> the appropriate registers and returning a real frequency, while
> >> downstream the driver was doing something entirely different.
> >>
> >> In our case here, the recalculated rate was wrong, as it was then
> >> given back to the set_rate function, which was erroneously doing
> >> a division on the fractional value, based on the prescaler being
> >> either enabled or disabled: this was actually producing a bug for
> >> which the final VCO rate was being doubled, causing very obvious
> >> issues when trying to drive a DSI panel because the actual divider
> >> value was multiplied by two!
> >>
> >> To make things work properly, remove the multiplication of the
> >> reference clock by two from function dsi_pll_calc_dec_frac and
> >> account for the prescaler enablement in the vco_recalc_rate (if
> >> the prescaler is enabled, then the hardware will divide the rate
> >> by two).
> >>
> >> This will make the vco_recalc_rate function to pass the right
> >> frequency to the (clock framework) set_rate function when called,
> >> which will - in turn - program the right values in both the
> >> DECIMAL_DIV_START_1 and the FRAC_DIV_START_{LOW/MID/HIGH}_1
> >> registers, finally making the PLL to output the right clock.
> >>
> >> Also, while at it, remove the prescaler TODO by also adding the
> >> possibility of disabling the prescaler on the PLL (it is in the
> >> PLL_ANALOG_CONTROLS_ONE register).
> >> Of course, both prescaler-ON and OFF cases were tested.
> >
> > This somehow breaks things on sc7180 (display gets stuck at first
> > frame of splash screen). (This is a setup w/ an ti-sn65dsi86 dsi->eDP
> > bridge)
> >
>
> First frame of the splash means that something is "a bit" wrong...
> ...like the DSI clock is a little off.
>
> I don't have such hardware, otherwise I would've tried... but what you
> describe is a bit strange.
> Is there any other older qcom platform using this chip? Any other
> non-qcom platform? Is the driver for the SN65DSI86 surely fine?
> Anyway, as you know, I would never propose untested patches nor
> partially working ones for any reason: I'm sorry that this happened.
I don't think there is anything publicly avail w/ sc7180 (yet.. but very soon)
The ti-sn65dsi86 bridge is used on a bunch of 845/850 devices (like
the snapdragon windows laptops).. and I think also the older 835
laptops.. ofc that doesn't mean that there isn't some bug, but I'd
guess maybe more likely that there is some small difference in DSI vs
older devices, or some cmd vs video mode difference.
Anyways, seems like the screen did eventually recover so that gives me
a bit of confidence to bisect this series, which I'll do a bit later
today.
> In any case, just to be perfectly transparent, while being here waiting
> for review, this patch series got tested on more smartphones, even ones
> that I don't personally own, with different displays.
>
> For your reference, here's a list (all MSM8998..):
> - OnePlus 5 (1920x1080)
> - F(x)Tec Pro 1 (2160x1080)
> - Sony Xperia XZ1 Compact (1280x720)
> - Sony Xperia XZ1 (1920x1080)
> - Sony Xperia XZ Premium (3840x2160)
>
Yeah, no worries, I wasn't trying to imply that the patch was untested.
Out of curiosity, are any of those video mode panels?
>
> > Also, something (I assume DSI related) that I was testing on
> > msm-next-staging seems to have effected the colors on the panel (ie.
> > they are more muted).. which seems to persist across reboots (ie. when
>
> So much "fun". This makes me think something about the PCC block doing
> the wrong thing (getting misconfigured).
>
> > switching back to a good kernel), and interestingly if I reboot from a
> > good kernel I see part of the login prompt (or whatever was previously
> > on-screen) in the firmware ui screen !?! (so maybe somehow triggered
> > the display to think it is in PSR mode??)
> >
>
> From a fast read, the SN65DSI86 is on I2C.. giving it a wrong dsi clock
> cannot produce (logically, at least) this, so I say that it is very
> unlikely for this to be a consequence of the 10nm pll fixes...
>
Note that the bridge can also be programmed via dsi cmd mode packets,
which I believe is the case on the 835 laptops (or at least one of
them).. but all the things I have are using i2c as the control path.
> ...unless the bootloader is not configuring the DSI rates, but that's
> also very unlikely (it always does, or it always does not).
I haven't looked at the bootloader display code, but booting back to
an old/good kernel didn't change anything.. even powering off didn't.
But the ghost image
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > On 2021-01-29 14:35, Will Deacon wrote: > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > > Add a new page protection flag IOMMU_LLC which can be used > > > > by non-coherent masters to set cacheable memory attributes > > > > for an outer level of cache called as last-level cache or > > > > system cache. Initial user of this page protection flag is > > > > the adreno gpu and then can later be used by other clients > > > > such as video where this can be used for per-buffer based > > > > mapping. > > > > > > > > Signed-off-by: Sai Prakash Ranjan > > > > --- > > > > drivers/iommu/io-pgtable-arm.c | 3 +++ > > > > include/linux/iommu.h | 6 ++ > > > > 2 files changed, 9 insertions(+) > > > > > > > > diff --git a/drivers/iommu/io-pgtable-arm.c > > > > b/drivers/iommu/io-pgtable-arm.c > > > > index 7439ee7fdcdb..ebe653ef601b 100644 > > > > --- a/drivers/iommu/io-pgtable-arm.c > > > > +++ b/drivers/iommu/io-pgtable-arm.c > > > > @@ -415,6 +415,9 @@ static arm_lpae_iopte > > > > arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, > > > > else if (prot & IOMMU_CACHE) > > > > pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE > > > > << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > > + else if (prot & IOMMU_LLC) > > > > + pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE > > > > + << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > > } > > > > > > > > if (prot & IOMMU_CACHE) > > > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > > > index ffaa389ea128..1f82057df531 100644 > > > > --- a/include/linux/iommu.h > > > > +++ b/include/linux/iommu.h > > > > @@ -31,6 +31,12 @@ > > > > * if the IOMMU page table format is equivalent. > > > > */ > > > > #define IOMMU_PRIV (1 << 5) > > > > +/* > > > > + * Non-coherent masters can use this page protection flag to set > > > > cacheable > > > > + * memory attributes for only a transparent outer level of cache, > > > > also known as > > > > + * the last-level or system cache. > > > > + */ > > > > +#define IOMMU_LLC(1 << 6) > > > > > > On reflection, I'm a bit worried about exposing this because I think it > > > will > > > introduce a mismatched virtual alias with the CPU (we don't even have a > > > MAIR > > > set up for this memory type). Now, we also have that issue for the PTW, > > > but > > > since we always use cache maintenance (i.e. the streaming API) for > > > publishing the page-tables to a non-coheren walker, it works out. > > > However, > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > > allocation, then they're potentially in for a nasty surprise due to the > > > mismatched outer-cacheability attributes. > > > > > > > Can't we add the syscached memory type similar to what is done on android? > > Maybe. How does the GPU driver map these things on the CPU side? Currently we use writecombine mappings for everything, although there are some cases that we'd like to use cached (but have not merged patches that would give userspace a way to flush/invalidate) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL
On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter wrote: > > - there's been a pile of cgroups proposal to manage gpus at the drm > subsystem level, some by Kenny, and frankly this at least looks a bit > like a quick hack to sidestep the consensus process for that. > No Daniel, this is quick *draft* to get a conversation going. Bpf was actually a path suggested by Tejun back in 2018 so I think you are mischaracterizing this quite a bit. "2018-11-20 Kenny Ho: To put the questions in more concrete terms, let say a user wants to expose certain part of a gpu to a particular cgroup similar to the way selective cpu cores are exposed to a cgroup via cpuset, how should we go about enabling such functionality? 2018-11-20 Tejun Heo: Do what the intel driver or bpf is doing? It's not difficult to hook into cgroup for identification purposes." Kenny ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL
[Resent in plain text.] On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter wrote: > - there's been a pile of cgroups proposal to manage gpus at the drm > subsystem level, some by Kenny, and frankly this at least looks a bit > like a quick hack to sidestep the consensus process for that. No Daniel, this is quick *draft* to get a conversation going. Bpf was actually a path suggested by Tejun back in 2018 so I think you are mischaracterizing this quite a bit. "2018-11-20 Kenny Ho: To put the questions in more concrete terms, let say a user wants to expose certain part of a gpu to a particular cgroup similar to the way selective cpu cores are exposed to a cgroup via cpuset, how should we go about enabling such functionality? 2018-11-20 Tejun Heo: Do what the intel driver or bpf is doing? It's not difficult to hook into cgroup for identification purposes." Kenny ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge
On Tue, 15 Sep 2020 21:40:40 +0200, Andrzej Hajda wrote: > W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze: > > On 14.09.2020 22:01, Michael Tretter wrote: > >> On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote: > >>> On 14.09.2020 10:29, Marek Szyprowski wrote: > On 11.09.2020 15:54, Michael Tretter wrote: > > Make the exynos_dsi driver a full drm bridge that can be found and > > used > > from other drivers. > > > > Other drivers can only attach to the bridge, if a mipi dsi device > > already attached to the bridge. This allows to defer the probe of the > > display pipe until the downstream bridges are available, too. > > > > Signed-off-by: Michael Tretter > This one (and the whole series applied) still fails on Exynos boards: > > [drm] Exynos DRM: using 11c0.fimd device for DMA mapping > operations > exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) > OF: graph: no port node found in /soc/dsi@11c8 > 8<--- cut here --- > Unable to handle kernel NULL pointer dereference at virtual address > 0084 > pgd = (ptrval) > [0084] *pgd= > Internal error: Oops: 5 [#1] PREEMPT SMP ARM > Modules linked in: > CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc4-next-20200911-00010-g417dc70d70ec #1608 > Hardware name: Samsung Exynos (Flattened Device Tree) > PC is at drm_bridge_attach+0x18/0x164 > LR is at exynos_dsi_bind+0x88/0xa8 > pc : [] lr : [] psr: 2013 > sp : ef0dfca8 ip : 0002 fp : c13190e0 > r10: r9 : ee46d580 r8 : c13190e0 > r7 : ee438800 r6 : 0018 r5 : ef253810 r4 : ef39e840 > r3 : r2 : 0018 r1 : ef39e888 r0 : ef39e840 > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5387d Table: 4000404a DAC: 0051 > Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) > Stack: (0xef0dfca8 to 0xef0e) > ... > [] (drm_bridge_attach) from [] > (exynos_dsi_bind+0x88/0xa8) > [] (exynos_dsi_bind) from [] > (component_bind_all+0xfc/0x290) > [] (component_bind_all) from [] > (exynos_drm_bind+0xe4/0x19c) > [] (exynos_drm_bind) from [] > (try_to_bring_up_master+0x1e4/0x2c4) > [] (try_to_bring_up_master) from [] > (component_master_add_with_match+0xd4/0x108) > [] (component_master_add_with_match) from [] > (exynos_drm_platform_probe+0xe4/0x110) > [] (exynos_drm_platform_probe) from [] > (platform_drv_probe+0x6c/0xa4) > [] (platform_drv_probe) from [] > (really_probe+0x200/0x4fc) > [] (really_probe) from [] > (driver_probe_device+0x78/0x1fc) > [] (driver_probe_device) from [] > (device_driver_attach+0x58/0x60) > [] (device_driver_attach) from [] > (__driver_attach+0xdc/0x174) > [] (__driver_attach) from [] > (bus_for_each_dev+0x68/0xb4) > [] (bus_for_each_dev) from [] > (bus_add_driver+0x158/0x214) > [] (bus_add_driver) from [] > (driver_register+0x78/0x110) > [] (driver_register) from [] > (exynos_drm_init+0xe4/0x118) > [] (exynos_drm_init) from [] > (do_one_initcall+0x8c/0x42c) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x190/0x1dc) > [] (kernel_init_freeable) from [] > (kernel_init+0x8/0x118) > [] (kernel_init) from [] (ret_from_fork+0x14/0x20) > Exception stack(0xef0dffb0 to 0xef0dfff8) > ... > ---[ end trace ee27f313f9ed9da1 ]--- > > # arm-linux-gnueabi-addr2line -e vmlinux c0628c08 > drivers/gpu/drm/drm_bridge.c:184 (discriminator 1) > > I will try to debug it a bit more today. > >>> The above crash has been caused by lack of in_bridge initialization to > >>> NULL in exynos_dsi_bind() in this patch. However, fixing it reveals > >>> another issue: > >>> > >>> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping operations > >>> exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) > >>> OF: graph: no port node found in /soc/dsi@11c8 > >>> 8<--- cut here --- > >>> Unable to handle kernel NULL pointer dereference at virtual address > >>> 0280 > >>> pgd = (ptrval) > >>> [0280] *pgd= > >>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM > >>> Modules linked in: > >>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted > >>> 5.9.0-rc4-next-20200911-00010-g417dc70d70ec-dirty #1613 > >>> Hardware name: Samsung Exynos (Flattened Device Tree) > >>> PC is at __mutex_lock+0x54/0xb18 > >>> LR is at lock_is_held_type+0x80/0x138 > >>> pc : [] lr : [] psr: 6013 > >>> sp : ef0dfd30 ip : 33937b74 fp : c13193c8 > >>> r10: c1208eec r9 : r8 : ee45f808 > >>> r7 : c19561a4 r6 : r5 : r4 : 024c > >>> r3 : r2 : 00204140 r1 : c124f13c r0 : > >>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
Re: [PATCH 3/5] drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler
On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 31/01/21 20:50, Rob Clark ha scritto:
> > > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > > wrote:
> > >>
> > >> The VCO rate was being miscalculated due to a big overlook during
> > >> the process of porting this driver from downstream to upstream:
> > >> here we are really recalculating the rate of the VCO by reading
> > >> the appropriate registers and returning a real frequency, while
> > >> downstream the driver was doing something entirely different.
> > >>
> > >> In our case here, the recalculated rate was wrong, as it was then
> > >> given back to the set_rate function, which was erroneously doing
> > >> a division on the fractional value, based on the prescaler being
> > >> either enabled or disabled: this was actually producing a bug for
> > >> which the final VCO rate was being doubled, causing very obvious
> > >> issues when trying to drive a DSI panel because the actual divider
> > >> value was multiplied by two!
> > >>
> > >> To make things work properly, remove the multiplication of the
> > >> reference clock by two from function dsi_pll_calc_dec_frac and
> > >> account for the prescaler enablement in the vco_recalc_rate (if
> > >> the prescaler is enabled, then the hardware will divide the rate
> > >> by two).
> > >>
> > >> This will make the vco_recalc_rate function to pass the right
> > >> frequency to the (clock framework) set_rate function when called,
> > >> which will - in turn - program the right values in both the
> > >> DECIMAL_DIV_START_1 and the FRAC_DIV_START_{LOW/MID/HIGH}_1
> > >> registers, finally making the PLL to output the right clock.
> > >>
> > >> Also, while at it, remove the prescaler TODO by also adding the
> > >> possibility of disabling the prescaler on the PLL (it is in the
> > >> PLL_ANALOG_CONTROLS_ONE register).
> > >> Of course, both prescaler-ON and OFF cases were tested.
> > >
> > > This somehow breaks things on sc7180 (display gets stuck at first
> > > frame of splash screen). (This is a setup w/ an ti-sn65dsi86 dsi->eDP
> > > bridge)
> > >
> >
> > First frame of the splash means that something is "a bit" wrong...
> > ...like the DSI clock is a little off.
> >
> > I don't have such hardware, otherwise I would've tried... but what you
> > describe is a bit strange.
> > Is there any other older qcom platform using this chip? Any other
> > non-qcom platform? Is the driver for the SN65DSI86 surely fine?
> > Anyway, as you know, I would never propose untested patches nor
> > partially working ones for any reason: I'm sorry that this happened.
>
> I don't think there is anything publicly avail w/ sc7180 (yet.. but very soon)
>
> The ti-sn65dsi86 bridge is used on a bunch of 845/850 devices (like
> the snapdragon windows laptops).. and I think also the older 835
> laptops.. ofc that doesn't mean that there isn't some bug, but I'd
> guess maybe more likely that there is some small difference in DSI vs
> older devices, or some cmd vs video mode difference.
>
> Anyways, seems like the screen did eventually recover so that gives me
> a bit of confidence to bisect this series, which I'll do a bit later
> today.
fwiw, this series minus this patch, and everything looks ok.. let me
take a closer look at what changes with this patch
BR,
-R
> > In any case, just to be perfectly transparent, while being here waiting
> > for review, this patch series got tested on more smartphones, even ones
> > that I don't personally own, with different displays.
> >
> > For your reference, here's a list (all MSM8998..):
> > - OnePlus 5 (1920x1080)
> > - F(x)Tec Pro 1 (2160x1080)
> > - Sony Xperia XZ1 Compact (1280x720)
> > - Sony Xperia XZ1 (1920x1080)
> > - Sony Xperia XZ Premium (3840x2160)
> >
>
> Yeah, no worries, I wasn't trying to imply that the patch was untested.
>
> Out of curiosity, are any of those video mode panels?
>
> >
> > > Also, something (I assume DSI related) that I was testing on
> > > msm-next-staging seems to have effected the colors on the panel (ie.
> > > they are more muted).. which seems to persist across reboots (ie. when
> >
> > So much "fun". This makes me think something about the PCC block doing
> > the wrong thing (getting misconfigured).
> >
> > > switching back to a good kernel), and interestingly if I reboot from a
> > > good kernel I see part of the login prompt (or whatever was previously
> > > on-screen) in the firmware ui screen !?! (so maybe somehow triggered
> > > the display to think it is in PSR mode??)
> > >
> >
> > From a fast read, the SN65DSI86 is on I2C.. giving it a wrong dsi clock
> > cannot produce (logically, at least) this, so I say that it is very
> > unlikely for this to be a consequence of the 10nm pll fixes...
> >
>
> Note that the bridge can also be programmed via dsi cmd mode packets,
> which I believe is the case on the 835 laptops (or at least o
RE: [PATCH rdma-core v7 4/6] pyverbs: Add dma-buf based MR support
> -Original Message- > From: Jason Gunthorpe > Sent: Monday, February 01, 2021 7:29 AM > To: Daniel Vetter > Cc: Leon Romanovsky ; Gal Pressman ; > Xiong, Jianxin ; Yishai Hadas > ; linux-rdma ; Edward Srouji > ; dri-devel de...@lists.freedesktop.org>; Christian Koenig ; > Doug Ledford ; Vetter, Daniel > > Subject: Re: [PATCH rdma-core v7 4/6] pyverbs: Add dma-buf based MR support > > On Mon, Feb 01, 2021 at 03:10:00PM +0100, Daniel Vetter wrote: > > On Mon, Feb 1, 2021 at 7:16 AM Leon Romanovsky wrote: > > > > > > On Sun, Jan 31, 2021 at 05:31:16PM +0200, Gal Pressman wrote: > > > > On 25/01/2021 21:57, Jianxin Xiong wrote: > > > > > Define a new sub-class of 'MR' that uses dma-buf object for the > > > > > memory region. Define a new class 'DmaBuf' as a wrapper for > > > > > dma-buf allocation mechanism implemented in C. > > > > > > > > > > Update the cmake function for cython modules to allow building > > > > > modules with mixed cython and c source files. > > > > > > > > > > Signed-off-by: Jianxin Xiong > > > > > buildlib/pyverbs_functions.cmake | 78 +++ > > > > > pyverbs/CMakeLists.txt | 11 +- > > > > > pyverbs/dmabuf.pxd | 15 +++ > > > > > pyverbs/dmabuf.pyx | 73 ++ > > > > > pyverbs/dmabuf_alloc.c | 278 > > > > > +++ > > > > > pyverbs/dmabuf_alloc.h | 19 +++ > > > > > pyverbs/libibverbs.pxd | 2 + > > > > > pyverbs/mr.pxd | 6 + > > > > > pyverbs/mr.pyx | 105 ++- > > > > > 9 files changed, 557 insertions(+), 30 deletions(-) create > > > > > mode 100644 pyverbs/dmabuf.pxd create mode 100644 > > > > > pyverbs/dmabuf.pyx create mode 100644 pyverbs/dmabuf_alloc.c > > > > > create mode 100644 pyverbs/dmabuf_alloc.h > > > > > > <...> > > > > > > > > index 000..05eae75 > > > > > +++ b/pyverbs/dmabuf_alloc.c > > > > > @@ -0,0 +1,278 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB > > > > > +/* > > > > > + * Copyright 2020 Intel Corporation. All rights reserved. See > > > > > +COPYING file */ > > > > > + > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > > > > I assume these should come from the kernel headers package, right? > > > > > > This is gross, all kernel headers should be placed in > > > kernel-headers/* and "update" script needs to be extended to take drm/* > > > files too :(. > > > > drm kernel headers are in the libdrm package. You need that anyway for > > doing the ioctls (if you don't hand-roll the restarting yourself). > > > > Also our userspace has gone over to just outright copying the driver > > headers. Not the generic headers, but for the rendering side of gpus, > > which is the topic here, there's really not much generic stuff. > > > > > Jianxin, are you fixing it? > > > > So fix is either to depend upon libdrm for building, or have copies of > > the headers included in the package for the i915/amdgpu/radeon headers > > (drm/drm.h probably not so good idea). > > We should have a cmake test to not build the drm parts if it can't be built, > and pyverbs should skip the tests. > Yes, I will add a test for that. Also, on SLES, the headers could be under /usr/include/libdrm instead of /usr/include/drm. The make test should check that and use proper path. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d/v3d_sched: fix scheduler callbacks return status
Ah, thank you Christian. :-)
This did change a few times--sorry I missed it, not sure how it happened. :-)
Regards,
Luben
On 2021-02-01 4:11 a.m., Christian König wrote:
> Looks like this was not correctly adjusted.
>
> Signed-off-by: Christian König
> Fixes: a6a1f036c74e ("drm/scheduler: Job timeout handler returns status (v3)")
> ---
> drivers/gpu/drm/v3d/v3d_sched.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index ef2338a294ca..ceb33f8e4379 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -259,7 +259,7 @@ v3d_cache_clean_job_run(struct drm_sched_job *sched_job)
> return NULL;
> }
>
> -static enum drm_gpu_sched_status
> +static enum drm_gpu_sched_stat
> v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job
> *sched_job)
> {
> enum v3d_queue q;
> @@ -294,7 +294,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct
> drm_sched_job *sched_job)
> * could fail if the GPU got in an infinite loop in the CL, but that
> * is pretty unlikely outside of an i-g-t testcase.
> */
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
> u32 *timedout_ctca, u32 *timedout_ctra)
> {
> @@ -312,7 +312,7 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum
> v3d_queue q,
> return v3d_gpu_reset_for_timeout(v3d, sched_job);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_bin_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_bin_job *job = to_bin_job(sched_job);
> @@ -321,7 +321,7 @@ v3d_bin_job_timedout(struct drm_sched_job *sched_job)
> &job->timedout_ctca, &job->timedout_ctra);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_render_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_render_job *job = to_render_job(sched_job);
> @@ -330,7 +330,7 @@ v3d_render_job_timedout(struct drm_sched_job *sched_job)
> &job->timedout_ctca, &job->timedout_ctra);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_generic_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_job *job = to_v3d_job(sched_job);
> @@ -338,7 +338,7 @@ v3d_generic_job_timedout(struct drm_sched_job *sched_job)
> return v3d_gpu_reset_for_timeout(job->v3d, sched_job);
> }
>
> -static enum drm_task_status
> +static enum drm_gpu_sched_stat
> v3d_csd_job_timedout(struct drm_sched_job *sched_job)
> {
> struct v3d_csd_job *job = to_csd_job(sched_job);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH rdma-core v7 5/6] tests: Add tests for dma-buf based memory regions
> -Original Message-
> From: John Hubbard
> Sent: Sunday, January 31, 2021 12:45 AM
> To: Xiong, Jianxin ; linux-r...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
> Cc: Doug Ledford ; Jason Gunthorpe ; Leon
> Romanovsky ; Sumit Semwal
> ; Christian Koenig ;
> Vetter, Daniel ; Edward Srouji
> ; Yishai Hadas
> Subject: Re: [PATCH rdma-core v7 5/6] tests: Add tests for dma-buf based
> memory regions
>
> On 1/25/21 11:57 AM, Jianxin Xiong wrote:
> > Define a set of unit tests similar to regular MR tests and a set of
> > tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
> > function to generate access flags for dma-buf based MRs because the
> > set of supported flags is smaller.
> >
> > Signed-off-by: Jianxin Xiong
>
> Hi Jianxin,
>
> It's awesome to see a GPU to IB test suite here!
>
> > ---
> > tests/args_parser.py | 4 +
> > tests/test_mr.py | 266
> > ++-
> > tests/utils.py | 26 +
> > 3 files changed, 295 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/args_parser.py b/tests/args_parser.py index
> > 446535a..5bc53b0 100644
> > --- a/tests/args_parser.py
> > +++ b/tests/args_parser.py
> > @@ -19,6 +19,10 @@ class ArgsParser(object):
> > parser.add_argument('--port',
> > help='Use port of RDMA device',
> > type=int,
> > default=1)
> > +parser.add_argument('--gpu', nargs='?', type=int, const=0,
> > default=0,
> > +help='GPU unit to allocate dmabuf from')
> > +parser.add_argument('--gtt', action='store_true', default=False,
> > +help='Allocate dmabuf from GTT instead of
> > + VRAM')
>
> Just to be kind to non-GPU people, how about:
>
> s/GTT/GTT (Graphics Translation Table)/
>
>
<...>
> > +def check_dmabuf_support(unit=0):
> > +"""
> > +Check if dma-buf allocation is supported by the system.
> > +Skip the test on failure.
> > +"""
> > +device_num = 128 + unit
> > +try:
> > +DmaBuf(1, unit=unit)
>
> unit?? This is a GPU, never anything else! Let's s/unit/gpu/ throughout, yes?
>
Thanks for the feedback. Will integrate the suggestions in upcoming patch.
Jianxin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler
On Mon, Feb 1, 2021 at 9:05 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
> >
> > On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> > wrote:
> > >
> > > Il 31/01/21 20:50, Rob Clark ha scritto:
> > > > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > > > wrote:
> > > >>
> > > >> The VCO rate was being miscalculated due to a big overlook during
> > > >> the process of porting this driver from downstream to upstream:
> > > >> here we are really recalculating the rate of the VCO by reading
> > > >> the appropriate registers and returning a real frequency, while
> > > >> downstream the driver was doing something entirely different.
> > > >>
> > > >> In our case here, the recalculated rate was wrong, as it was then
> > > >> given back to the set_rate function, which was erroneously doing
> > > >> a division on the fractional value, based on the prescaler being
> > > >> either enabled or disabled: this was actually producing a bug for
> > > >> which the final VCO rate was being doubled, causing very obvious
> > > >> issues when trying to drive a DSI panel because the actual divider
> > > >> value was multiplied by two!
> > > >>
> > > >> To make things work properly, remove the multiplication of the
> > > >> reference clock by two from function dsi_pll_calc_dec_frac and
> > > >> account for the prescaler enablement in the vco_recalc_rate (if
> > > >> the prescaler is enabled, then the hardware will divide the rate
> > > >> by two).
> > > >>
> > > >> This will make the vco_recalc_rate function to pass the right
> > > >> frequency to the (clock framework) set_rate function when called,
> > > >> which will - in turn - program the right values in both the
> > > >> DECIMAL_DIV_START_1 and the FRAC_DIV_START_{LOW/MID/HIGH}_1
> > > >> registers, finally making the PLL to output the right clock.
> > > >>
> > > >> Also, while at it, remove the prescaler TODO by also adding the
> > > >> possibility of disabling the prescaler on the PLL (it is in the
> > > >> PLL_ANALOG_CONTROLS_ONE register).
> > > >> Of course, both prescaler-ON and OFF cases were tested.
> > > >
> > > > This somehow breaks things on sc7180 (display gets stuck at first
> > > > frame of splash screen). (This is a setup w/ an ti-sn65dsi86 dsi->eDP
> > > > bridge)
> > > >
> > >
> > > First frame of the splash means that something is "a bit" wrong...
> > > ...like the DSI clock is a little off.
> > >
> > > I don't have such hardware, otherwise I would've tried... but what you
> > > describe is a bit strange.
> > > Is there any other older qcom platform using this chip? Any other
> > > non-qcom platform? Is the driver for the SN65DSI86 surely fine?
> > > Anyway, as you know, I would never propose untested patches nor
> > > partially working ones for any reason: I'm sorry that this happened.
> >
> > I don't think there is anything publicly avail w/ sc7180 (yet.. but very
> > soon)
> >
> > The ti-sn65dsi86 bridge is used on a bunch of 845/850 devices (like
> > the snapdragon windows laptops).. and I think also the older 835
> > laptops.. ofc that doesn't mean that there isn't some bug, but I'd
> > guess maybe more likely that there is some small difference in DSI vs
> > older devices, or some cmd vs video mode difference.
> >
> > Anyways, seems like the screen did eventually recover so that gives me
> > a bit of confidence to bisect this series, which I'll do a bit later
> > today.
>
> fwiw, this series minus this patch, and everything looks ok.. let me
> take a closer look at what changes with this patch
Btw, it looks like upstream, config->disable_prescaler is always
false.. I don't suppose you have anything WIP that changes this?
BR,
-R
>
> > > In any case, just to be perfectly transparent, while being here waiting
> > > for review, this patch series got tested on more smartphones, even ones
> > > that I don't personally own, with different displays.
> > >
> > > For your reference, here's a list (all MSM8998..):
> > > - OnePlus 5 (1920x1080)
> > > - F(x)Tec Pro 1 (2160x1080)
> > > - Sony Xperia XZ1 Compact (1280x720)
> > > - Sony Xperia XZ1 (1920x1080)
> > > - Sony Xperia XZ Premium (3840x2160)
> > >
> >
> > Yeah, no worries, I wasn't trying to imply that the patch was untested.
> >
> > Out of curiosity, are any of those video mode panels?
> >
> > >
> > > > Also, something (I assume DSI related) that I was testing on
> > > > msm-next-staging seems to have effected the colors on the panel (ie.
> > > > they are more muted).. which seems to persist across reboots (ie. when
> > >
> > > So much "fun". This makes me think something about the PCC block doing
> > > the wrong thing (getting misconfigured).
> > >
> > > > switching back to a good kernel), and interestingly if I reboot from a
> > > > good kernel I see part of the login prompt (or whatever was previously
> > > > on-screen) in the firmware ui screen !?! (so maybe somehow triggered
> > > > the display to think it is
Re: [PATCH 3/5] drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler
On Mon, Feb 1, 2021 at 9:18 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 9:05 AM Rob Clark wrote:
> >
> > On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> > > wrote:
> > > >
> > > > Il 31/01/21 20:50, Rob Clark ha scritto:
> > > > > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > > > > wrote:
> > > > >>
> > > > >> The VCO rate was being miscalculated due to a big overlook during
> > > > >> the process of porting this driver from downstream to upstream:
> > > > >> here we are really recalculating the rate of the VCO by reading
> > > > >> the appropriate registers and returning a real frequency, while
> > > > >> downstream the driver was doing something entirely different.
> > > > >>
> > > > >> In our case here, the recalculated rate was wrong, as it was then
> > > > >> given back to the set_rate function, which was erroneously doing
> > > > >> a division on the fractional value, based on the prescaler being
> > > > >> either enabled or disabled: this was actually producing a bug for
> > > > >> which the final VCO rate was being doubled, causing very obvious
> > > > >> issues when trying to drive a DSI panel because the actual divider
> > > > >> value was multiplied by two!
> > > > >>
> > > > >> To make things work properly, remove the multiplication of the
> > > > >> reference clock by two from function dsi_pll_calc_dec_frac and
> > > > >> account for the prescaler enablement in the vco_recalc_rate (if
> > > > >> the prescaler is enabled, then the hardware will divide the rate
> > > > >> by two).
> > > > >>
> > > > >> This will make the vco_recalc_rate function to pass the right
> > > > >> frequency to the (clock framework) set_rate function when called,
> > > > >> which will - in turn - program the right values in both the
> > > > >> DECIMAL_DIV_START_1 and the FRAC_DIV_START_{LOW/MID/HIGH}_1
> > > > >> registers, finally making the PLL to output the right clock.
> > > > >>
> > > > >> Also, while at it, remove the prescaler TODO by also adding the
> > > > >> possibility of disabling the prescaler on the PLL (it is in the
> > > > >> PLL_ANALOG_CONTROLS_ONE register).
> > > > >> Of course, both prescaler-ON and OFF cases were tested.
> > > > >
> > > > > This somehow breaks things on sc7180 (display gets stuck at first
> > > > > frame of splash screen). (This is a setup w/ an ti-sn65dsi86 dsi->eDP
> > > > > bridge)
> > > > >
> > > >
> > > > First frame of the splash means that something is "a bit" wrong...
> > > > ...like the DSI clock is a little off.
> > > >
> > > > I don't have such hardware, otherwise I would've tried... but what you
> > > > describe is a bit strange.
> > > > Is there any other older qcom platform using this chip? Any other
> > > > non-qcom platform? Is the driver for the SN65DSI86 surely fine?
> > > > Anyway, as you know, I would never propose untested patches nor
> > > > partially working ones for any reason: I'm sorry that this happened.
> > >
> > > I don't think there is anything publicly avail w/ sc7180 (yet.. but very
> > > soon)
> > >
> > > The ti-sn65dsi86 bridge is used on a bunch of 845/850 devices (like
> > > the snapdragon windows laptops).. and I think also the older 835
> > > laptops.. ofc that doesn't mean that there isn't some bug, but I'd
> > > guess maybe more likely that there is some small difference in DSI vs
> > > older devices, or some cmd vs video mode difference.
> > >
> > > Anyways, seems like the screen did eventually recover so that gives me
> > > a bit of confidence to bisect this series, which I'll do a bit later
> > > today.
> >
> > fwiw, this series minus this patch, and everything looks ok.. let me
> > take a closer look at what changes with this patch
>
> Btw, it looks like upstream, config->disable_prescaler is always
> false.. I don't suppose you have anything WIP that changes this?
fwiw, this is the clk_summary diff with and without this patch:
--
270,282c270,282
< dsi0_pll_out_div_clk 110
887039941 0 0 5 Y
Re: [PATCH v12] staging: fbtft: add tearing signal detect
On Sat, Jan 30, 2021 at 8:39 AM carlis wrote: > On Fri, 29 Jan 2021 16:26:12 +0200 > Andy Shevchenko wrote: > > On Fri, Jan 29, 2021 at 3:56 PM carlis wrote: > > > On Fri, 29 Jan 2021 12:23:08 +0200 > > > Andy Shevchenko wrote: ... > > > Hi, I apologize for what I said in the previous two emails. I missed > > > one email you sent before, and now I probably understand what you > > > meant. Here is a version I modified according to your suggestion: I have realized that you are mocking stuff in the generic fbtft structure for all drivers while only a single one is going to use that. Consider moving everything to the driver in question. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > > > Add a new page protection flag IOMMU_LLC which can be used > > > > > by non-coherent masters to set cacheable memory attributes > > > > > for an outer level of cache called as last-level cache or > > > > > system cache. Initial user of this page protection flag is > > > > > the adreno gpu and then can later be used by other clients > > > > > such as video where this can be used for per-buffer based > > > > > mapping. > > > > > > > > > > Signed-off-by: Sai Prakash Ranjan > > > > > --- > > > > > drivers/iommu/io-pgtable-arm.c | 3 +++ > > > > > include/linux/iommu.h | 6 ++ > > > > > 2 files changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/iommu/io-pgtable-arm.c > > > > > b/drivers/iommu/io-pgtable-arm.c > > > > > index 7439ee7fdcdb..ebe653ef601b 100644 > > > > > --- a/drivers/iommu/io-pgtable-arm.c > > > > > +++ b/drivers/iommu/io-pgtable-arm.c > > > > > @@ -415,6 +415,9 @@ static arm_lpae_iopte > > > > > arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, > > > > > else if (prot & IOMMU_CACHE) > > > > > pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE > > > > > << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > > > + else if (prot & IOMMU_LLC) > > > > > + pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE > > > > > + << ARM_LPAE_PTE_ATTRINDX_SHIFT); > > > > > } > > > > > > > > > > if (prot & IOMMU_CACHE) > > > > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > > > > index ffaa389ea128..1f82057df531 100644 > > > > > --- a/include/linux/iommu.h > > > > > +++ b/include/linux/iommu.h > > > > > @@ -31,6 +31,12 @@ > > > > > * if the IOMMU page table format is equivalent. > > > > > */ > > > > > #define IOMMU_PRIV (1 << 5) > > > > > +/* > > > > > + * Non-coherent masters can use this page protection flag to set > > > > > cacheable > > > > > + * memory attributes for only a transparent outer level of cache, > > > > > also known as > > > > > + * the last-level or system cache. > > > > > + */ > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > On reflection, I'm a bit worried about exposing this because I think it > > > > will > > > > introduce a mismatched virtual alias with the CPU (we don't even have a > > > > MAIR > > > > set up for this memory type). Now, we also have that issue for the PTW, > > > > but > > > > since we always use cache maintenance (i.e. the streaming API) for > > > > publishing the page-tables to a non-coheren walker, it works out. > > > > However, > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > > > allocation, then they're potentially in for a nasty surprise due to the > > > > mismatched outer-cacheability attributes. > > > > > > > > > > Can't we add the syscached memory type similar to what is done on android? > > > > Maybe. How does the GPU driver map these things on the CPU side? > > Currently we use writecombine mappings for everything, although there > are some cases that we'd like to use cached (but have not merged > patches that would give userspace a way to flush/invalidate) > > BR, > -R LLC/system cache doesn't have a relationship with the CPU cache. Its just a little accelerator that sits on the connection from the GPU to DDR and caches accesses. The hint that Sai is suggesting is used to mark the buffers as 'no-write-allocate' to prevent GPU write operations from being cached in the LLC which a) isn't interesting and b) takes up cache space for read operations. Its easiest to think of the LLC as a bonus accelerator that has no cost for us to use outside of the unfortunate per buffer hint. We do have to worry about the CPU cache w.r.t I/O coherency (which is a different hint) and in that case we have all of concerns that Will identified. Jordan -- 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: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal wrote: > > On Thu, 28 Jan 2021 at 17:23, Christian König > wrote: > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > Hi Hridya, > > > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH wrote: > > >> On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > > >>> This patch allows statistics to be enabled for each DMA-BUF in > > >>> sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > >>> > > >>> The following stats will be exposed by the interface: > > >>> > > >>> /sys/kernel/dmabuf/buffers//exporter_name > > >>> /sys/kernel/dmabuf/buffers//size > > >>> /sys/kernel/dmabuf/buffers//attachments//device > > >>> /sys/kernel/dmabuf/buffers//attachments//map_counter > > >>> > > >>> The inode_number is unique for each DMA-BUF and was added earlier [1] > > >>> in order to allow userspace to track DMA-BUF usage across different > > >>> processes. > > >>> > > >>> Currently, this information is exposed in > > >>> /sys/kernel/debug/dma_buf/bufinfo. > > >>> However, since debugfs is considered unsafe to be mounted in production, > > >>> it is being duplicated in sysfs. > > >>> > > >>> This information will be used to derive DMA-BUF > > >>> per-exporter stats and per-device usage stats for Android Bug reports. > > >>> The corresponding userspace changes can be found at [2]. > > >>> Telemetry tools will also capture this information(along with other > > >>> memory metrics) periodically as well as on important events like a > > >>> foreground app kill (which might have been triggered by Low Memory > > >>> Killer). It will also contribute to provide a snapshot of the system > > >>> memory usage on other events such as OOM kills and Application Not > > >>> Responding events. > > >>> > > >>> A shell script that can be run on a classic Linux environment to read > > >>> out the DMA-BUF statistics can be found at [3](suggested by John > > >>> Stultz). > > >>> > > >>> The patch contains the following improvements over the previous version: > > >>> 1) Each attachment is represented by its own directory to allow creating > > >>> a symlink to the importing device and to also provide room for future > > >>> expansion. > > >>> 2) The number of distinct mappings of each attachment is exposed in a > > >>> separate file. > > >>> 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > >>> inorder to make the interface expandable in future. > > >>> > > >>> All of the improvements above are based on suggestions/feedback from > > >>> Daniel Vetter and Christian König. > > >>> > > >>> [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > >>> [2]: > > >>> https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > > >>> [3]: > > >>> https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > >>> > > >>> Signed-off-by: Hridya Valsaraju > > >>> Reported-by: kernel test robot > > > Thanks for the patch! > > > > > > Christian: If you're satisfied with the explanation around not > > > directly embedding kobjects into the dma_buf and dma_buf_attachment > > > structs, then with Greg's r-b from sysfs PoV, I think we can merge it. > > > Please let me know if you feel otherwise! > > > > From the technical side it looks clean to me, feel free to add my > > acked-by while pushing. > > > > But I would at least try to convince Daniel on the design. At least some > > of his concerns seems to be valid and keep in mind that we need to > > support this interface forever. > > Naturally. > > Since he didn't comment over Hridya's last clarification about the > tracepoints to track total GPU memory allocations being orthogonal to > this series, I assumed he agreed with it. The tracepoint being orthogonal didn't really look convincing to me, since I do expect we'll need that at a much more generic level, at allocators. Whether that's dma-buf heaps or in drm or wherever. And we probably also need that to somehow align with cgroups accounting. But I guess for this it should be easy to extend however we see fit, so retrofitting allocator sources and anything else we want/need for the overall gpu memory account shouldn't be a problem. Also, it's first, so the proof for showing it all works together is more on the tracepoints :-) > Daniel, do you still have objections around adding this patch in? Needs docs (especially the uapi I think would be useful to document), igt tests, that kind of stuff still I think? It's meant to be generic uapi across drivers, generally we're a pile stricter for that (and yes dma-buf heaps I think didn't do all that, so maybe there's an argument for doing this a bit more sloppy or at least "the testsuite is somewhere else"). But I think it would be good to have this all done. -Daniel > > > > > Regards, > > Christian. > > Best, > Sumit. > > > > > > > >>> --- > > >>> Changes in v3: > > >>> Fix a warning reported by the kernel test robot. > > >>> > > >>> Changes in v2: > > >>> -Mo
Re: [PATCH v2 13/15] dt-binding: display: bcm2711-hdmi: Add CEC and hotplug interrupts
On Mon, Jan 11, 2021 at 8:27 AM Maxime Ripard wrote: > > The CEC and hotplug interrupts were missing when that binding was > introduced, let's add them in now that we've figured out how it works. > > Signed-off-by: Maxime Ripard > --- > .../bindings/display/brcm,bcm2711-hdmi.yaml | 20 ++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > index 7ce06f9f9f8e..6e8ac910bdd8 100644 > --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > @@ -53,6 +53,24 @@ properties: >- const: audio >- const: cec > > + interrupts: > +items: > + - description: CEC TX interrupt > + - description: CEC RX interrupt > + - description: CEC stuck at low interrupt > + - description: Wake-up interrupt > + - description: Hotplug connected interrupt > + - description: Hotplug removed interrupt > + > + interrupt-names: > +items: > + - const: cec-tx > + - const: cec-rx > + - const: cec-low > + - const: wakeup > + - const: hpd-connected > + - const: hpd-removed > + >ddc: > allOf: >- $ref: /schemas/types.yaml#/definitions/phandle > @@ -90,7 +108,7 @@ required: >- resets >- ddc > > -additionalProperties: false > +unevaluatedProperties: false /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml: 'additionalProperties' is a required property And you missed the DT list, so no checks ran. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 09/15] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
On Fri, Dec 18, 2020 at 04:07:17PM +0530, Ankit Nautiyal wrote:
> This patch adds functions to start FRL training for an HDMI2.1 sink,
> connected via a PCON as a DP branch device.
> This patch also adds a new structure for storing frl training related
> data, when FRL training is completed.
>
> v2: As suggested by Uma Shankar:
> -renamed couple of variables for better clarity
> -tweaked the macros used for correct semantics for true/false
> -fixed other styling issues.
>
> v3: Completed the TODO for condition for going to FRL mode.
> Modified the condition to determine the required FRL b/w
> based only on the Pcon and Sink's max FRL values.
> Moved the frl structure initialization to intel_dp_init_connector().
>
> v4: Fixed typo in initialization of frl structure.
>
> v5: Always use FRL if its possible, instead of enabling only for
> higher modes as done in v3.
>
> Signed-off-by: Ankit Nautiyal
> Reviewed-by: Uma Shankar (v2)
> ---
> .../drm/i915/display/intel_display_types.h| 7 +
> drivers/gpu/drm/i915/display/intel_dp.c | 151 ++
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +
> 3 files changed, 160 insertions(+)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0596d6c24e73..43027a6d5e5e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3891,6 +3891,8 @@ static void intel_disable_dp(struct intel_atomic_state
> *state,
> intel_edp_backlight_off(old_conn_state);
> intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
> intel_edp_panel_off(intel_dp);
> + intel_dp->frl.is_trained = false;
> + intel_dp->frl.trained_rate_gbps = 0;
This stuff looks rather misplaced (or missing from elsewhere). This code
doesn't even get executed on modern platforms.
> +static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
> +{
> +#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
> +#define PCON_CONCURRENT_MODE (1 > 0)
> +#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
> +#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
All of that looks like nonsense. What is it supposed to do?
> +#define TIMEOUT_FRL_READY_MS 500
> +#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
> +
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
> + u8 max_frl_bw_mask = 0, frl_trained_mask;
> + bool is_active;
> +
> + ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
> + if (ret < 0)
> + return ret;
> +
> + max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
> + drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
> +
> + max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
> + drm_dbg(&i915->drm, "Sink max rate from EDID = %d Gbps\n",
> max_edid_frl_bw);
> +
> + max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
> +
> + if (max_frl_bw <= 0)
> + return -EINVAL;
> +
> + ret = drm_dp_pcon_frl_prepare(&intel_dp->aux, false);
> + if (ret < 0)
> + return ret;
> + /* Wait for PCON to be FRL Ready */
> + wait_for(is_active = drm_dp_pcon_is_frl_ready(&intel_dp->aux) == true,
> TIMEOUT_FRL_READY_MS);
> +
> + if (!is_active)
> + return -ETIMEDOUT;
> +
> + max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
> + ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
> PCON_SEQUENTIAL_MODE);
> + if (ret < 0)
> + return ret;
> + ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
> PCON_NORMAL_TRAIN_MODE);
> + if (ret < 0)
> + return ret;
> + ret = drm_dp_pcon_frl_enable(&intel_dp->aux);
> + if (ret < 0)
> + return ret;
> + /*
> + * Wait for FRL to be completed
> + * Check if the HDMI Link is up and active.
> + */
> + wait_for(is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux) ==
> true, TIMEOUT_HDMI_LINK_ACTIVE_MS);
> +
> + if (!is_active)
> + return -ETIMEDOUT;
> +
> + /* Verify HDMI Link configuration shows FRL Mode */
> + if (DP_PCON_HDMI_MODE_FRL != drm_dp_pcon_hdmi_link_mode(&intel_dp->aux,
> &frl_trained_mask)) {
> + drm_dbg(&i915->drm, "HDMI couldn't be trained in FRL Mode\n");
> + return -EINVAL;
> + }
> + drm_dbg(&i915->drm, "MAX_FRL_MASK = %u, FRL_TRAINED_MASK = %u\n",
> max_frl_bw_mask, frl_trained_mask);
> +
> + intel_dp->frl.trained_rate_gbps =
> intel_dp_pcon_get_frl_mask(frl_trained_mask);
> + intel_dp->frl.is_trained = true;
> + drm_dbg(&i915->drm, "FRL trained with : %d Gbps\n",
> intel_dp->frl.trained_rate_gbps);
> +
> + return 0;
> +}
> +
> +static bool intel_dp_is_hdmi_2_1_sink(struct intel_dp *intel_dp)
> +{
> + if (drm_dp_is_branch(intel_dp->dpcd) &&
> + intel_dp->has_hdmi_sink &&
> + intel_dp_hdmi_sink_max_frl(intel_dp) > 0)
> +
Re: [PATCH 08/29] dma-buf: Avoid comma separated statements
This is entirely unrelated to this thread, but I noticed when going through dri-
devel that this email is somehow dated two days in the future from now.
On Wed, 2021-02-03 at 14:26 +0100, Christian König wrote:
> Am 30.01.21 um 19:47 schrieb Joe Perches:
> > On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
> > > Use semicolons and braces.
> > Ping?
> >
> > > Signed-off-by: Joe Perches
>
> Reviewed-by: Christian König
>
> Do you have commit rights to drm-misc-next?
>
> > > ---
> > > drivers/dma-buf/st-dma-fence.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
> > > fence.c
> > > index e593064341c8..c8a12d7ad71a 100644
> > > --- a/drivers/dma-buf/st-dma-fence.c
> > > +++ b/drivers/dma-buf/st-dma-fence.c
> > > @@ -471,8 +471,11 @@ static int thread_signal_callback(void *arg)
> > > dma_fence_signal(f1);
> > >
> > >
> > > smp_store_mb(cb.seen, false);
> > > - if (!f2 || dma_fence_add_callback(f2, &cb.cb,
> > > simple_callback))
> > > - miss++, cb.seen = true;
> > > + if (!f2 ||
> > > + dma_fence_add_callback(f2, &cb.cb, simple_callback)) {
> > > + miss++;
> > > + cb.seen = true;
> > > + }
> > >
> > >
> > > if (!t->before)
> > > dma_fence_signal(f1);
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] dp/dp_mst: Add support for sink event notify messages
On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> Sink event notify messages are used for MST CEC IRQs. Add parsing
> support for sink event notify messages in preparation for handling MST
> CEC IRQs.
>
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
> include/drm/drm_dp_mst_helper.h | 14 ++
> 2 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 17dbed0a9800..15b6cc39a754 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1027,6 +1027,30 @@ static bool
> drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
> return false;
> }
>
> +static bool drm_dp_sideband_parse_sink_event_notify(
> + struct drm_dp_sideband_msg_rx *raw,
> + struct drm_dp_sideband_msg_req_body *msg)
> +{
> + int idx = 1;
> +
> + msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
> + idx++;
> + if (idx > raw->curlen)
> + goto fail_len;
> +
> + memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
> + idx += 16;
> + if (idx > raw->curlen)
> + goto fail_len;
> +
> + msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx +
> 1]);
> + idx++;
> + return true;
> +fail_len:
> + DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx, raw-
> >curlen);
Is it possible for us to use drm_dbg_kms() here?
Also-there is an MST selftest you should update for this
> + return false;
> +}
> +
> static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_req_body
> *msg)
> {
> @@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct
> drm_dp_sideband_msg_rx *raw,
> return drm_dp_sideband_parse_connection_status_notify(raw,
> msg);
> case DP_RESOURCE_STATUS_NOTIFY:
> return drm_dp_sideband_parse_resource_status_notify(raw, msg);
> + case DP_SINK_EVENT_NOTIFY:
> + return drm_dp_sideband_parse_sink_event_notify(raw, msg);
> default:
> DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> @@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr
> *mgr,
> guid = msg->u.conn_stat.guid;
> else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> guid = msg->u.resource_stat.guid;
> + else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
> + guid = msg->u.sink_event.guid;
>
> if (guid)
> mstb = drm_dp_get_mst_branch_device_by_guid(mgr,
> guid);
> @@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
> drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
>
> if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
> - up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
> + up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
> + up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
> DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
> up_req->msg.req_type);
> kfree(up_req);
> @@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
> DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
> res_stat->port_number,
> res_stat->available_pbn);
> + } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
> + const struct drm_dp_sink_event_notify *sink_event =
> + &up_req->msg.u.sink_event;
> +
> + DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
> + sink_event->port_number, sink_event->event_id);
> }
>
> up_req->hdr = mgr->up_req_recv.initial_hdr;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 6ae5860d8644..c7c79e0ced18 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify {
> u16 available_pbn;
> };
>
> +#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR BIT(0)
> +#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR BIT(1)
> +#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUN BIT(2)
> +#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW BIT(3)
> +#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR BIT(4)
> +#define DP_SINK_EVENT_CEC_IRQ_EVENT
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> For adapters behind an MST hub use the correct AUX channel.
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org: rebased, removing redundant changes]
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 15b6cc39a754..0d753201adbd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> drm_dp_mst_topology_mgr *mgr,
> drm_dp_mst_topology_put_port(port);
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
> +
> static struct drm_dp_mst_port *
> drm_dp_mst_add_port(struct drm_device *dev,
> struct drm_dp_mst_topology_mgr *mgr,
> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> port->port_num = port_number;
> port->mgr = mgr;
> port->aux.name = "DPMST";
> + mutex_init(&port->aux.hw_mutex);
> + mutex_init(&port->aux.cec.lock);
You're missing a matching mutex_destroy() for both of these
With that fixed:
Reviewed-by: Lyude Paul
> port->aux.dev = dev->dev;
> port->aux.is_remote = true;
>
> + port->aux.transfer = drm_dp_mst_aux_transfer;
> +
> /* initialize the MST downstream port's AUX crc work queue */
> drm_dp_remote_aux_init(&port->aux);
>
> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> return 0;
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> +{
> + struct drm_dp_mst_port *port =
> + container_of(aux, struct drm_dp_mst_port, aux);
> + int ret;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
> + break;
> +
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
> + break;
> +
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
> if (dp_link_bw == 0 || dp_link_count == 0)
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm_dp_mst_topology: export two functions
On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> These are required for the CEC MST support.
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
> include/drm/drm_dp_mst_helper.h | 4
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 0d753201adbd..c783a2a1c114 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
> static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> char *buf);
>
> -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> -
> static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> int id,
> struct drm_dp_payload *payload);
> @@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct
> drm_dp_mst_port *port)
> * drm_dp_mst_topology_try_get_port()
> * drm_dp_mst_topology_get_port()
> */
> -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
> +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
Mhh-can you think of some way around this? I really don't think it's a good
idea for us to be exposing topology references to things as-is, the thing is
they're really meant to be used for critical sections in code where it'd become
very painful to deal with an mst port disappearing from under us. Outside of MST
helpers, everyone else should be dealing with the expectation that these things
can disappear as a result of hotplugs at any moment.
Note that we do expose malloc refs, but that's intentional as holding a malloc
ref to something doesn't cause it to stay around even when it's unplugged - it
just stops it from being unallocated.
> {
> topology_ref_history_lock(port->mgr);
>
> @@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct
> drm_dp_mst_branch *mstb,
> return NULL;
> }
>
> -static struct drm_dp_mst_port *
> +struct drm_dp_mst_port *
> drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port)
> {
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index c7c79e0ced18..d036222e0d64 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port);
>
> +struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
> +(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
> +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> +
> struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
> drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
>
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/dp_mst: Don't report ports connected if nothing is attached to them
For the whole series:
Reviewed-by: Lyude Paul
On Mon, 2021-02-01 at 14:01 +0200, Imre Deak wrote:
> Reporting a port as connected if nothing is attached to them leads to
> any i2c transactions on this port trying to use an uninitialized i2c
> adapter, fix this.
>
> Let's account for this case even if branch devices have no good reason
> to report a port as unplugged with their peer device type set to 'none'.
>
> Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/2987
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1963
> Cc: Wayne Lin
> Cc: Lyude Paul
> Cc: # v5.5+
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e82b596d646c..deb7995f42fa 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4224,6 +4224,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
>
> switch (port->pdt) {
> case DP_PEER_DEVICE_NONE:
> + break;
> case DP_PEER_DEVICE_MST_BRANCHING:
> if (!port->mcs)
> ret = connector_status_connected;
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> For adapters behind an MST hub use the correct AUX channel.
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org: rebased, removing redundant changes]
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 15b6cc39a754..0d753201adbd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> drm_dp_mst_topology_mgr *mgr,
> drm_dp_mst_topology_put_port(port);
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
> +
> static struct drm_dp_mst_port *
> drm_dp_mst_add_port(struct drm_device *dev,
> struct drm_dp_mst_topology_mgr *mgr,
> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> port->port_num = port_number;
> port->mgr = mgr;
> port->aux.name = "DPMST";
> + mutex_init(&port->aux.hw_mutex);
> + mutex_init(&port->aux.cec.lock);
> port->aux.dev = dev->dev;
> port->aux.is_remote = true;
>
> + port->aux.transfer = drm_dp_mst_aux_transfer;
> +
This was supposed to be handled via higher levels checking for
is_remote==true.
> /* initialize the MST downstream port's AUX crc work queue */
> drm_dp_remote_aux_init(&port->aux);
>
> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> return 0;
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> +{
> + struct drm_dp_mst_port *port =
> + container_of(aux, struct drm_dp_mst_port, aux);
> + int ret;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
That doesn't make sense to me. I2c writes and DPCD writes
are definitely not the same thing.
aux->transfer is a very low level thing. I don't think it's the
correct level of abstraction for sideband.
> + break;
> +
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
> + break;
> +
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
> if (dp_link_bw == 0 || dp_link_count == 0)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
should we do GSoC 2021?
Hi everyone, There are discussions regarding whether or not we want to participate in GSoC this year. Org applications are open now until Feb 19. Last year at the GSoC Mentor Summit (Oct 2020) it was announced that changes were coming to GSoC 2021: - the amount of time a student is expected to spend on a project is halved - stipends are halved - overall duration is shortened to 10 weeks - lowered eligibility requirements As a result, project expectations are supposed to be reduced as well. Whereas previously a student was expected to work 350 hours and had to be enrolled in an accredited university programme, now projects are expected to take a student 175 hours and accredited colleges and coding camps are acceptable. What this means right now is that our list of ideas ( https://www.x.org/wiki/SummerOfCodeIdeas/) needs to be checked to see if it's still suitable. Are the project ideas still valid? Are they something a student could do in 175 hours? Some people feel that 175 hours might not be enough time to contribute a significant coding effort against an fd.o project. At this point my gut feeling is to hold off on the application. If I can't find anyone to help go through the ideas list or who are willing to mentor under these new changes then we'll need to consider our options. Thoughts? Thanks so much for reading, best regards, Trevor ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/9] cgroup support for GPU devices
On 1/28/2021 7:00 PM, Xingyou Chen wrote: > On 2021/1/27 上午5:46, Brian Welty wrote: > >> We'd like to revisit the proposal of a GPU cgroup controller for managing >> GPU devices but with just a basic set of controls. This series is based on >> the prior patch series from Kenny Ho [1]. We take Kenny's base patches >> which implement the basic framework for the controller, but we propose an >> alternate set of control files. Here we've taken a subset of the controls >> proposed in earlier discussion on ML here [2]. >> >> This series proposes a set of device memory controls (gpu.memory.current, >> gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage >> (gpu.sched.runtime). GPU time sharing controls are left as future work. >> These are implemented within the GPU controller along with integration/usage >> of the device memory controls by the i915 device driver. >> >> As an accelerator or GPU device is similar in many respects to a CPU with >> (or without) attached system memory, the basic principle here is try to >> copy the semantics of existing controls from other controllers when possible >> and where these controls serve the same underlying purpose. >> For example, the memory.max and memory.current controls are based on >> same controls from MEMCG controller. > > It seems not to be DRM specific, or even GPU specific. Would we have an > universal > control group for any accelerator, GPGPU device etc, that hold sharable > resources > like device memory, compute utility, bandwidth, with extra control file to > select > between devices(or vendors)? > > e.g. /cgname.device that stores PCI BDF， or enum(intel, amdgpu, nvidia, ...), > defaults to none, means not enabled. > Hi, thanks for the feedback. Yes, I tend to agree. I've asked about this in earlier work; my suggestion is to name the controller something like 'XPU' to be clear that these controls could apply to more than GPU. But at least for now, based on Tejun's reply [1], the feedback is to try and keep this controller as small and focused as possible on just GPU. At least until we get some consensus on set of controls for GPU. but for this we need more active input from community.. -Brian [1] https://lists.freedesktop.org/archives/dri-devel/2019-November/243167.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: Use delayed timer as default in devfreq profile
Hi Lukasz, Thanks for the explanation. So the deferred timer option makes a mistake that when GPU goes from idle to busy for only one poll periodic, in this case 50ms, right? But delayed timer will wakeup CPU every 50ms even when system is idle, will this cause more power consumption for the case like phone suspend? Regards, Qiang On Mon, Feb 1, 2021 at 5:53 PM Lukasz Luba wrote: > > Hi Qiang, > > On 1/30/21 1:51 PM, Qiang Yu wrote: > > Thanks for the patch. But I can't observe any difference on glmark2 > > with or without this patch. > > Maybe you can provide other test which can benefit from it. > > This is a design problem and has impact on the whole system. > There is a few issues. When the device is not checked and there are > long delays between last check and current, the history is broken. > It confuses the devfreq governor and thermal governor (Intelligent Power > Allocation (IPA)). Thermal governor works on stale stats data and makes > stupid decisions, because there is no new stats (device not checked). > Similar applies to devfreq simple_ondemand governor, where it 'tires' to > work on a lng period even 3sec and make prediction for the next > frequency based on it (which is broken). > > How it should be done: constant reliable check is needed, then: > - period is guaranteed and has fixed size, e.g 50ms or 100ms. > - device status is quite recent so thermal devfreq cooling provides >'fresh' data into thermal governor > > This would prevent odd behavior and solve the broken cases. > > > > > Considering it will wake up CPU more frequently, and user may choose > > to change this by sysfs, > > I'd like to not apply it. > > The deferred timer for GPU is wrong option, for UFS or eMMC makes more > sense. It's also not recommended for NoC busses. I've discovered that > some time ago and proposed to have option to switch into delayed timer. > Trust me, it wasn't obvious to find out that this missing check has > those impacts. So the other engineers or users might not know that some > problems they faces (especially when the device load is changing) is due > to this delayed vs deffered timer and they will change it in the sysfs. > > Regards, > Lukasz > > > > > Regards, > > Qiang > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds
OK, I see. Patch is also: Reviewed-by: Qiang Yu Regards, Qiang On Mon, Feb 1, 2021 at 5:59 PM Lukasz Luba wrote: > > > > On 1/30/21 1:57 PM, Qiang Yu wrote: > > This patch gets minor improvement on glmark2 (160->162). > > It has bigger impact when the load is changing and the frequency > is stuck to min w/o this patch. > > > > > Seems there's no way for user to change this value, do we? > > Or there's work pending to expose it to sysfs? > > True there is no user sysfs. I've proposed a patch to export these via > sysfs. Chanwoo is going to work on it. When it will land mainline, it's > probably a few months. So for now, the fix makes sense. > > Regards, > Lukasz > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
[AMD Public Use]
> -Original Message-
> From: Imre Deak
> Sent: Monday, February 1, 2021 8:02 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Lyude Paul
> Subject: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
>
> Caching EDIDs for physical ports prevents updating the EDID if a port gets
> reconnected via a Connection Status Notification message,
> fix this.
>
> Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
> Cc: Wayne Lin
> Cc: Lyude Paul
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index deb7995f42fa..309afe61afdd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2302,7 +2302,8 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
> *mstb,
> }
>
> if (port->pdt != DP_PEER_DEVICE_NONE &&
> -drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
> +drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
> +port->port_num >= DP_MST_LOGICAL_PORT_0) {
Hi Imre Deak,
Thanks for the patch!
Just curious that you mean we don't want to fetch the EDID of the sst monitor
like below case?
Src->MST device ->SST monitor
I thought we still need to get the EDID even the monitor is connected to the
physical output port of mst device.
Maybe what we should fix here is why the EDID is not get updated once
reconnected via CSN message?
Thanks!
> port->cached_edid = drm_get_edid(port->connector,
> &port->aux.ddc);
> drm_connector_set_tile_property(port->connector);
> --
> 2.25.1
Regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/aspeed: Look up syscon by phandle
On Tue, 2 Feb 2021 at 04:39, Jeremy Kerr wrote:
>
> Hi Joel,
>
> Sounds like a good idea! One comment though:
>
> > @@ -111,10 +112,13 @@ static int aspeed_gfx_load(struct drm_device *drm)
> > if (IS_ERR(priv->base))
> > return PTR_ERR(priv->base);
> >
> > - priv->scu =
> > syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu");
> > + priv->scu = syscon_regmap_lookup_by_phandle(np, "syscon");
> > if (IS_ERR(priv->scu)) {
> > - dev_err(&pdev->dev, "failed to find SCU regmap\n");
> > - return PTR_ERR(priv->scu);
> > + priv->scu =
> > syscon_regmap_lookup_by_compatible("aspeed,aspeed-scu");
>
> Is this (more generic) compatible value guaranteed to exist alongside
> aspeed,ast2500-scu? The scu binding only specifies the model-specific
> ones:
>
> Documentation/devicetree/bindings/mfd/aspeed-scu.txt:
>
> Required properties:
> - compatible: One of:
> "aspeed,ast2400-scu", "syscon", "simple-mfd"
> "aspeed,ast2500-scu", "syscon", "simple-mfd"
>
> - the only mention of the new compatible value that I can find is this
> thread. Maybe we should retain the existing one to keep the fallback
> case working?
Yes, it was a mistake to change ast2500-scu to aspeed-scu. The only
reason to keep the lookup_by_compatible was to decouple this patch
from the device tree changes.
I will send a v2 with syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu").
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/aspeed: Use dt matching for default register values
On Tue, 2 Feb 2021 at 04:46, Jeremy Kerr wrote: > > Hi Joel, > > > There are minor differences in the values for the threshold value and > > the scan line size between families of ASPEED SoC. Additionally the > > SCU register for the output control differs between families. > > > > This adds device tree matching to parameterise these values, allowing > > us to add support for the AST2400 now, and in the future the AST2600. > > Looks good to me. Two super minor things: > > > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c > > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c > > @@ -60,7 +60,8 @@ static void aspeed_gfx_enable_controller(struct > > aspeed_gfx *priv) > > u32 ctrl2 = readl(priv->base + CRT_CTRL2); > > > > /* SCU2C: set DAC source for display output to Graphics CRT (GFX) */ > > - regmap_update_bits(priv->scu, 0x2c, BIT(16), BIT(16)); > > + regmap_update_bits(priv->scu, priv->dac_reg, BIT(16), BIT(16)); > > The comment references SCU2C; but you've implied that this will > change... > > > @@ -228,7 +258,7 @@ static ssize_t dac_mux_store(struct device *dev, > > struct device_attribute *attr, > > if (val > 3) > > return -EINVAL; > > > > - rc = regmap_update_bits(priv->scu, ASPEED_SCU_MISC_CTRL, 0x3, > > val << 16); > > + rc = regmap_update_bits(priv->scu, priv->dac_reg, 0x3, val << > > 16); > > if (rc < 0) > > return 0; > > > > @@ -241,7 +271,7 @@ static ssize_t dac_mux_show(struct device *dev, > > struct device_attribute *attr, c > > u32 reg; > > int rc; > > > > - rc = regmap_read(priv->scu, ASPEED_SCU_MISC_CTRL, ®); > > + rc = regmap_read(priv->scu, priv->dac_reg, ®); > > if (rc) > > return rc; > > You've removed the only uses of ASPEED_SCU_MISC_CTRL here, maybe drop > the #define too? Good idea. I'll implement both of your suggestions. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/8] drm/mediatek: add component POSTMASK
Hi, Hsin-Yi:
It looks like that postmask driver could be placed in mtk_drm_ddp_comp.c
and this patch would much smaller.
Regards,
CK
On Mon, 2021-02-01 at 18:37 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> This patch add component POSTMASK.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/Makefile| 1 +
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
> drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 149 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 71 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 7 files changed, 204 insertions(+), 31 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index b64674b944860..13a0eafabf9c0 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -3,6 +3,7 @@
> mediatek-drm-y := mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> + mtk_disp_postmask.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> mtk_drm_ddp_comp.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index cdb0383f99061..06d4d4e1c0d05 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -37,6 +37,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
> drm_crtc_state *state);
> void mtk_gamma_start(struct device *dev);
> void mtk_gamma_stop(struct device *dev);
>
> +int mtk_postmask_clk_enable(struct device *dev);
> +void mtk_postmask_clk_disable(struct device *dev);
> +void mtk_postmask_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_postmask_start(struct device *dev);
> +void mtk_postmask_stop(struct device *dev);
> +
> void mtk_ovl_bgclr_in_on(struct device *dev);
> void mtk_ovl_bgclr_in_off(struct device *dev);
> void mtk_ovl_bypass_shadow(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> new file mode 100644
> index 0..5a109fee6b238
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_POSTMASK_EN 0x
> +#define POSTMASK_EN BIT(0)
> +#define DISP_POSTMASK_CFG0x0020
> +#define POSTMASK_RELAY_MODE BIT(0)
> +#define DISP_POSTMASK_SIZE 0x0030
> +
> +/**
> + * struct mtk_disp_postmask - DISP_postmask driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_postmask {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> +};
> +
> +int mtk_postmask_clk_enable(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(postmask->clk);
> +}
> +
> +void mtk_postmask_clk_disable(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(postmask->clk);
> +}
> +
> +void mtk_postmask_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, &postmask->cmdq_reg,
> postmask->regs,
> + DISP_POSTMASK_SIZE);
> + mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, &postmask->cmdq_reg,
> + postmask->regs, DISP_POSTMASK_CFG);
> +}
> +
> +void mtk_postmask_start(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + writel(POSTMASK_EN, postmask->regs + DISP_POSTMASK_EN);
> +}
> +
> +void mtk_postmask_stop(struct device *dev)
> +{
> + struct mtk_disp_postmask *postmask = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, postmask->regs + DISP_POSTMASK_EN);
> +}
> +
> +static int mtk_disp_postmask_bind(struct device *dev, struct device *master,
> void *data)
> +{
> + return 0;
> +}
> +
> +static void mtk_disp_postmask_unbind(struct d
Re: [PATCH v5 4/8] drm/mediatek: separate ccorr module
Hi, Hsin-Yi:
On Mon, 2021-02-01 at 18:37 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> ccorr ctm matrix bits will be different in mt8192
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 216
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 95 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 236 insertions(+), 96 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 13a0eafabf9c0..f119bef6d6e66 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -mediatek-drm-y := mtk_disp_color.o \
> +mediatek-drm-y := mtk_disp_ccorr.o \
> + mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> mtk_disp_postmask.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> new file mode 100644
> index 0..6ee2431e6b843
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_CCORR_EN0x
> +#define CCORR_EN BIT(0)
> +#define DISP_CCORR_CFG 0x0020
> +#define CCORR_RELAY_MODE BIT(0)
> +#define CCORR_ENGINE_EN BIT(1)
> +#define CCORR_GAMMA_OFF BIT(2)
> +#define CCORR_WGAMUT_SRC_CLIPBIT(3)
> +#define DISP_CCORR_SIZE 0x0030
> +#define DISP_CCORR_COEF_00x0080
> +#define DISP_CCORR_COEF_10x0084
> +#define DISP_CCORR_COEF_20x0088
> +#define DISP_CCORR_COEF_30x008C
> +#define DISP_CCORR_COEF_40x0090
> +
> +struct mtk_disp_ccorr_data {
> + u32 reserved;
> +};
> +
> +/**
> + * struct mtk_disp_ccorr - DISP_CCORR driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_ccorr {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> + const struct mtk_disp_ccorr_data*data;
> +};
> +
> +int mtk_ccorr_clk_enable(struct device *dev)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(ccorr->clk);
> +}
> +
> +void mtk_ccorr_clk_disable(struct device *dev)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(ccorr->clk);
> +}
> +
> +void mtk_ccorr_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, h << 16 | w, &ccorr->cmdq_reg, ccorr->regs,
> + DISP_CCORR_SIZE);
> + mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, &ccorr->cmdq_reg, ccorr->regs,
> + DISP_CCORR_CFG);
> +}
> +
> +void mtk_ccorr_start(struct device *dev)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + writel(CCORR_EN, ccorr->regs + DISP_CCORR_EN);
> +}
> +
> +void mtk_ccorr_stop(struct device *dev)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, ccorr->regs + DISP_CCORR_EN);
> +}
> +
> +/* Converts a DRM S31.32 value to the HW S1.10 format. */
> +static u16 mtk_ctm_s31_32_to_s1_10(u64 in)
> +{
> + u16 r;
> +
> + /* Sign bit. */
> + r = in & BIT_ULL(63) ? BIT(11) : 0;
> +
> + if ((in & GENMASK_ULL(62, 33)) > 0) {
> + /* identity value 0x1 -> 0x400, */
> + /* if bigger this, set it to max 0x7ff. */
> + r |= GENMASK(10, 0);
> + } else {
> + /* take the 11 most important bits. */
> + r |= (in >> 22) & GENMASK(10, 0);
> + }
> +
> + return r;
> +}
> +
> +void mtk_ccorr_ctm_set(struct device *dev, struct drm_crtc_state *state)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> + struct drm_property_blob *blob = state-
Re: [PATCH v5 5/8] drm/mediatek: Fix ccorr size config
Hi, Hsin-Yi:
On Mon, 2021-02-01 at 18:37 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Fix setting to follow hardware datasheet. The original error setting
> affects mt8192 display.
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> index 6ee2431e6b843..6c86673a835c3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -65,7 +65,7 @@ void mtk_ccorr_config(struct device *dev, unsigned int w,
> {
> struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
>
> - mtk_ddp_write(cmdq_pkt, h << 16 | w, &ccorr->cmdq_reg, ccorr->regs,
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, &ccorr->cmdq_reg, ccorr->regs,
> DISP_CCORR_SIZE);
> mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, &ccorr->cmdq_reg, ccorr->regs,
> DISP_CCORR_CFG);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm: aspeed: Support more chip families
The out of tree vendor driver was recently updated to support the ast2400 and ast2600. These patches begin to add that support to the mainline driver. With these two cleanups it should be easier to support different families of BMC system on chip with this driver. I will merge them through drm-misc once they have been reviewed. v2 fixes review from Jeremy. Thanks! Joel Stanley (2): drm/aspeed: Look up syscon by phandle drm/aspeed: Use dt matching for default register values drivers/gpu/drm/aspeed/aspeed_gfx.h | 8 +-- drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 11 ++-- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 67 ++-- 3 files changed, 62 insertions(+), 24 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/aspeed: Look up syscon by phandle
This scales better to multiple families of SoC. The lookup by compatible
can be removed in a future change.
The fallback path is for the ast2500 platform only. Other platforms will
be added with the new style, so they won't need fallback paths.
Signed-off-by: Joel Stanley
---
v2: Fix fallback path to still find ast2500-scu. Thanks jk for the
review
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 457ec04950f7..54a6bda03c0e 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -103,6 +103,7 @@ static int aspeed_gfx_load(struct drm_device *drm)
{
struct platform_device *pdev = to_platform_device(drm->dev);
struct aspeed_gfx *priv = to_aspeed_gfx(drm);
+ struct device_node *np = pdev->dev.of_node;
struct resource *res;
int ret;
@@ -111,10 +112,13 @@ static int aspeed_gfx_load(struct drm_device *drm)
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
- priv->scu = syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu");
+ priv->scu = syscon_regmap_lookup_by_phandle(np, "syscon");
if (IS_ERR(priv->scu)) {
- dev_err(&pdev->dev, "failed to find SCU regmap\n");
- return PTR_ERR(priv->scu);
+ priv->scu =
syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu");
+ if (IS_ERR(priv->scu)) {
+ dev_err(&pdev->dev, "failed to find SCU regmap\n");
+ return PTR_ERR(priv->scu);
+ }
}
ret = of_reserved_mem_device_init(drm->dev);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/aspeed: Use dt matching for default register values
There are minor differences in the values for the threshold value and
the scan line size between families of ASPEED SoC. Additionally the SCU
registers for the output control and scratch registers differ between
families.
This adds device tree matching to parameterise these values, allowing us
to add support for the AST2400 now, and in the future the AST2600.
Reviewed-by: Jeremy Kerr
Signed-off-by: Joel Stanley
---
v2:
- Add jk's review
- Clean up comments and unused define
- Add VGA password register
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 8 ++--
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 11 ++---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 57 ++--
3 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx.h
b/drivers/gpu/drm/aspeed/aspeed_gfx.h
index f1e7e56abc02..96501152bafa 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx.h
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx.h
@@ -11,6 +11,11 @@ struct aspeed_gfx {
struct reset_control*rst;
struct regmap *scu;
+ u32 dac_reg;
+ u32 vga_scratch_reg;
+ u32 throd_val;
+ u32 scan_line_max;
+
struct drm_simple_display_pipe pipe;
struct drm_connectorconnector;
};
@@ -100,6 +105,3 @@ int aspeed_gfx_create_output(struct drm_device *drm);
/* CRT_THROD */
#define CRT_THROD_LOW(x) (x)
#define CRT_THROD_HIGH(x) ((x) << 8)
-
-/* Default Threshold Seting */
-#define G5_CRT_THROD_VAL (CRT_THROD_LOW(0x24) | CRT_THROD_HIGH(0x3C))
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index e54686c31a90..20c2197b270f 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -59,8 +59,8 @@ static void aspeed_gfx_enable_controller(struct aspeed_gfx
*priv)
u32 ctrl1 = readl(priv->base + CRT_CTRL1);
u32 ctrl2 = readl(priv->base + CRT_CTRL2);
- /* SCU2C: set DAC source for display output to Graphics CRT (GFX) */
- regmap_update_bits(priv->scu, 0x2c, BIT(16), BIT(16));
+ /* Set DAC source for display output to Graphics CRT (GFX) */
+ regmap_update_bits(priv->scu, priv->dac_reg, BIT(16), BIT(16));
writel(ctrl1 | CRT_CTRL_EN, priv->base + CRT_CTRL1);
writel(ctrl2 | CRT_CTRL_DAC_EN, priv->base + CRT_CTRL2);
@@ -74,7 +74,7 @@ static void aspeed_gfx_disable_controller(struct aspeed_gfx
*priv)
writel(ctrl1 & ~CRT_CTRL_EN, priv->base + CRT_CTRL1);
writel(ctrl2 & ~CRT_CTRL_DAC_EN, priv->base + CRT_CTRL2);
- regmap_update_bits(priv->scu, 0x2c, BIT(16), 0);
+ regmap_update_bits(priv->scu, priv->dac_reg, BIT(16), 0);
}
static void aspeed_gfx_crtc_mode_set_nofb(struct aspeed_gfx *priv)
@@ -127,7 +127,8 @@ static void aspeed_gfx_crtc_mode_set_nofb(struct aspeed_gfx
*priv)
* Terminal Count: memory size of one scan line
*/
d_offset = m->hdisplay * bpp / 8;
- t_count = (m->hdisplay * bpp + 127) / 128;
+ t_count = DIV_ROUND_UP(m->hdisplay * bpp, priv->scan_line_max);
+
writel(CRT_DISP_OFFSET(d_offset) | CRT_TERM_COUNT(t_count),
priv->base + CRT_OFFSET);
@@ -135,7 +136,7 @@ static void aspeed_gfx_crtc_mode_set_nofb(struct aspeed_gfx
*priv)
* Threshold: FIFO thresholds of refill and stop (16 byte chunks
* per line, rounded up)
*/
- writel(G5_CRT_THROD_VAL, priv->base + CRT_THROD);
+ writel(priv->throd_val, priv->base + CRT_THROD);
}
static void aspeed_gfx_pipe_enable(struct drm_simple_display_pipe *pipe,
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 54a6bda03c0e..debf6c6e1958 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +58,34 @@
* which is available under NDA from ASPEED.
*/
+struct aspeed_gfx_config {
+ u32 dac_reg;/* DAC register in SCU */
+ u32 vga_scratch_reg;/* VGA scratch register in SCU */
+ u32 throd_val; /* Default Threshold Seting */
+ u32 scan_line_max; /* Max memory size of one scan line */
+};
+
+static const struct aspeed_gfx_config ast2400_config = {
+ .dac_reg = 0x2c,
+ .vga_scratch_reg = 0x50,
+ .throd_val = CRT_THROD_LOW(0x1e) | CRT_THROD_HIGH(0x12),
+ .scan_line_max = 64,
+};
+
+static const struct aspeed_gfx_config ast2500_config = {
+ .dac_reg = 0x2c,
+ .vga_scratch_reg = 0x50,
+ .throd_val = CRT_THROD_LOW(0x24) | CRT_THROD_HIGH(0x3c),
+ .scan_line_max = 128,
+};
+
+static const struct of_device_id aspeed_gfx_match[] = {
+ { .compatible = "aspeed,a
Re: [PATCH v5 6/8] drm/mediatek: add matrix_bits private data for ccorr
Hi, Hsin-Yi:
On Mon, 2021-02-01 at 18:37 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Add matrix_bits and coeffs_precision to ccorr private data:
> - matrix bits of mt8183 is 10
> - matrix bits of mt8192 is 11
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 34 ---
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> index 6c86673a835c3..fb86f3a8b3a18 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -29,8 +29,10 @@
> #define DISP_CCORR_COEF_30x008C
> #define DISP_CCORR_COEF_40x0090
>
> +#define CCORR_MATRIX_BITS10
> +
> struct mtk_disp_ccorr_data {
> - u32 reserved;
> + u32 matrix_bits;
> };
>
> /**
> @@ -85,21 +87,22 @@ void mtk_ccorr_stop(struct device *dev)
> writel_relaxed(0x0, ccorr->regs + DISP_CCORR_EN);
> }
>
> -/* Converts a DRM S31.32 value to the HW S1.10 format. */
> -static u16 mtk_ctm_s31_32_to_s1_10(u64 in)
> +/* Converts a DRM S31.32 value to the HW S1.n format. */
> +static u16 mtk_ctm_s31_32_to_s1_n(u64 in, u32 n)
> {
> u16 r;
>
> /* Sign bit. */
> - r = in & BIT_ULL(63) ? BIT(11) : 0;
> + r = in & BIT_ULL(63) ? BIT(n + 1) : 0;
>
> if ((in & GENMASK_ULL(62, 33)) > 0) {
> - /* identity value 0x1 -> 0x400, */
> + /* identity value 0x1 -> 0x400(mt8183), */
> + /* identity value 0x1 -> 0x800(mt8192), */
> /* if bigger this, set it to max 0x7ff. */
> - r |= GENMASK(10, 0);
> + r |= GENMASK(n, 0);
> } else {
> - /* take the 11 most important bits. */
> - r |= (in >> 22) & GENMASK(10, 0);
> + /* take the n+1 most important bits. */
> + r |= (in >> (32 - n)) & GENMASK(n, 0);
> }
>
> return r;
> @@ -114,6 +117,7 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
> drm_crtc_state *state)
> uint16_t coeffs[9] = { 0 };
> int i;
> struct cmdq_pkt *cmdq_pkt = NULL;
> + u32 matrix_bits;
>
> if (!blob)
> return;
> @@ -121,8 +125,13 @@ void mtk_ccorr_ctm_set(struct device *dev, struct
> drm_crtc_state *state)
> ctm = (struct drm_color_ctm *)blob->data;
> input = ctm->matrix;
>
> + if (ccorr->data)
ccorr->data is always true, isn't it?
> + matrix_bits = ccorr->data->matrix_bits;
> + else
> + matrix_bits = CCORR_MATRIX_BITS;
> +
> for (i = 0; i < ARRAY_SIZE(coeffs); i++)
> - coeffs[i] = mtk_ctm_s31_32_to_s1_10(input[i]);
> + coeffs[i] = mtk_ctm_s31_32_to_s1_n(input[i], matrix_bits);
>
> mtk_ddp_write(cmdq_pkt, coeffs[0] << 16 | coeffs[1],
> &ccorr->cmdq_reg, ccorr->regs, DISP_CCORR_COEF_0);
> @@ -199,8 +208,13 @@ static int mtk_disp_ccorr_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
> + .matrix_bits = CCORR_MATRIX_BITS,
Drop CCORR_MATRIX_BITS and use 10 here.
> +};
> +
> static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
> - { .compatible = "mediatek,mt8183-disp-ccorr"},
> + { .compatible = "mediatek,mt8183-disp-ccorr",
> + .data = &mt8183_ccorr_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 09/15] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
Hi Ville,
Please find my responses inline.
On 2/2/2021 2:08 AM, Ville Syrjälä wrote:
On Fri, Dec 18, 2020 at 04:07:17PM +0530, Ankit Nautiyal wrote:
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().
v4: Fixed typo in initialization of frl structure.
v5: Always use FRL if its possible, instead of enabling only for
higher modes as done in v3.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 151 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 160 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0596d6c24e73..43027a6d5e5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3891,6 +3891,8 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
This stuff looks rather misplaced (or missing from elsewhere). This code
doesn't even get executed on modern platforms.
I think these two lines should have been added to
intel_ddi_post_disable_dp() for TGL+
My intention was to reset these before disabling DP. In hindsight, since
we are initializing (resetting) these in dp_init_connector, this doesnt
seem to be required.
I will send a patch to remove these two lines from here.
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
All of that looks like nonsense. What is it supposed to do?
When asking an HDMI2.1 PCON to initiate FRL training there are 2 options:
Sequential/Concurrent mode: Sequential mode attempts the FRL training
after DP Link training is completed. Concurrent mode tries to do the FRL
training, during DP link training.
Normal train Mode/ Extended mode: Normal train mode, PCON FW trains FRL
from Max to min BW, set by source in BW Mask. It aborts on first
successful training. In Extended mode, PCON FW trains for all BW set by
source in BW mask.
For Concurrent and Extended mode we need to set some extra bits in PCON
FRL config DPCDs
The intention was to go with sequential and Normal training mode, so no
need to set above bits.
Do you think, some documentation will make this clear?
Thanks & Regards,
Ankit
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+ u8 max_frl_bw_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+ drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+ max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+ drm_dbg(&i915->drm, "Sink max rate from EDID = %d Gbps\n",
max_edid_frl_bw);
+
+ max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+ if (max_frl_bw <= 0)
+ return -EINVAL;
+
+ ret = drm_dp_pcon_frl_prepare(&intel_dp->aux, false);
+ if (ret < 0)
+ return ret;
+ /* Wait for PCON to be FRL Ready */
+ wait_for(is_active = drm_dp_pcon_is_frl_ready(&intel_dp->aux) == true,
TIMEOUT_FRL_READY_MS);
+
+ if (!is_active)
+ return -ETIMEDOUT;
+
+ max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
+ ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
PCON_SEQUENTIAL_MODE);
+ if (ret < 0)
+ return ret;
+ ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
PCON_NORMAL_TRAIN_MODE);
+ if (ret < 0)
+ return ret;
+ ret = drm_dp_pcon_frl_enable(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+ /*
+* Wait for FRL to be completed
+* Check if the HDMI Link is up and active.
+
Re: [PATCH v7 09/15] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
On Tue, Feb 02, 2021 at 12:09:47PM +0530, Nautiyal, Ankit K wrote:
> Hi Ville,
>
> Please find my responses inline.
>
> On 2/2/2021 2:08 AM, Ville Syrjälä wrote:
> > On Fri, Dec 18, 2020 at 04:07:17PM +0530, Ankit Nautiyal wrote:
> >> This patch adds functions to start FRL training for an HDMI2.1 sink,
> >> connected via a PCON as a DP branch device.
> >> This patch also adds a new structure for storing frl training related
> >> data, when FRL training is completed.
> >>
> >> v2: As suggested by Uma Shankar:
> >> -renamed couple of variables for better clarity
> >> -tweaked the macros used for correct semantics for true/false
> >> -fixed other styling issues.
> >>
> >> v3: Completed the TODO for condition for going to FRL mode.
> >> Modified the condition to determine the required FRL b/w
> >> based only on the Pcon and Sink's max FRL values.
> >> Moved the frl structure initialization to intel_dp_init_connector().
> >>
> >> v4: Fixed typo in initialization of frl structure.
> >>
> >> v5: Always use FRL if its possible, instead of enabling only for
> >> higher modes as done in v3.
> >>
> >> Signed-off-by: Ankit Nautiyal
> >> Reviewed-by: Uma Shankar (v2)
> >> ---
> >> .../drm/i915/display/intel_display_types.h| 7 +
> >> drivers/gpu/drm/i915/display/intel_dp.c | 151 ++
> >> drivers/gpu/drm/i915/display/intel_dp.h | 2 +
> >> 3 files changed, 160 insertions(+)
> >
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 0596d6c24e73..43027a6d5e5e 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -3891,6 +3891,8 @@ static void intel_disable_dp(struct
> >> intel_atomic_state *state,
> >>intel_edp_backlight_off(old_conn_state);
> >>intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
> >>intel_edp_panel_off(intel_dp);
> >> + intel_dp->frl.is_trained = false;
> >> + intel_dp->frl.trained_rate_gbps = 0;
> > This stuff looks rather misplaced (or missing from elsewhere). This code
> > doesn't even get executed on modern platforms.
>
> I think these two lines should have been added to
> intel_ddi_post_disable_dp() for TGL+
>
> My intention was to reset these before disabling DP. In hindsight, since
> we are initializing (resetting) these in dp_init_connector, this doesnt
> seem to be required.
>
> I will send a patch to remove these two lines from here.
>
>
> >
> >
> >> +static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
> >> +{
> >> +#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
> >> +#define PCON_CONCURRENT_MODE (1 > 0)
> >> +#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
> >> +#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
> > All of that looks like nonsense. What is it supposed to do?
>
> When asking an HDMI2.1 PCON to initiate FRL training there are 2 options:
>
> Sequential/Concurrent mode: Sequential mode attempts the FRL training
> after DP Link training is completed. Concurrent mode tries to do the FRL
> training, during DP link training.
>
> Normal train Mode/ Extended mode: Normal train mode, PCON FW trains FRL
> from Max to min BW, set by source in BW Mask. It aborts on first
> successful training. In Extended mode, PCON FW trains for all BW set by
> source in BW mask.
>
> For Concurrent and Extended mode we need to set some extra bits in PCON
> FRL config DPCDs
>
> The intention was to go with sequential and Normal training mode, so no
> need to set above bits.
>
> Do you think, some documentation will make this clear?
I'm asking why does the code do
#define PCON_EXTENDED_TRAIN_MODE true
#define PCON_CONCURRENT_MODE true
#define PCON_SEQUENTIAL_MODE false
#define PCON_NORMAL_TRAIN_MODE false
but in a very convoluted way?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] printk: use CONFIG_CONSOLE_LOGLEVEL_* directly
CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of
CONFIG_CONSOLE_LOGLEVEL_DEFAULT.
When you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from Kconfig, almost
all objects are rebuilt because CONFIG_CONSOLE_LOGLEVEL_DEFAULT is
used in , which is included from most of source files.
In fact, there are only 4 users of CONSOLE_LOGLEVEL_DEFAULT:
arch/x86/platform/uv/uv_nmi.c
drivers/firmware/efi/libstub/efi-stub-helper.c
drivers/tty/sysrq.c
kernel/printk/printk.c
So, when you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT and rebuild the
kernel, it is enough to recompile those 4 files.
Remove the CONSOLE_LOGLEVEL_DEFAULT definition from ,
and use CONFIG_CONSOLE_LOGLEVEL_DEFAULT directly.
With this, the build system will rebuild the minimal number of objects.
Steps to confirm it:
[1] Do the full build
[2] Change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from 'make menuconfig' etc.
[3] Rebuild
$ make
SYNCinclude/config/auto.conf
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC kernel/printk/printk.o
AR kernel/printk/built-in.a
AR kernel/built-in.a
CC drivers/tty/sysrq.o
AR drivers/tty/built-in.a
CC drivers/firmware/efi/libstub/efi-stub-helper.o
STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
AR drivers/firmware/efi/libstub/lib.a
AR drivers/built-in.a
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
AR init/built-in.a
LD vmlinux.o
...
For the same reason, do likewise for CONSOLE_LOGLEVEL_QUIET and
MESSAGE_LOGLEVEL_DEFAULT.
Signed-off-by: Masahiro Yamada
---
arch/x86/platform/uv/uv_nmi.c | 2 +-
drivers/firmware/efi/libstub/efi-stub-helper.c | 6 +++---
drivers/tty/sysrq.c| 4 ++--
drivers/video/fbdev/core/fbcon.c | 2 +-
drivers/video/fbdev/efifb.c| 2 +-
include/linux/printk.h | 10 --
init/main.c| 2 +-
kernel/printk/printk.c | 6 +++---
8 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index eafc530c8767..4751299c7416 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -100,7 +100,7 @@ static cpumask_var_t uv_nmi_cpu_mask;
* Default is all stack dumps go to the console and buffer.
* Lower level to send to log buffer only.
*/
-static int uv_nmi_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
+static int uv_nmi_loglevel = CONFIG_CONSOLE_LOGLEVEL_DEFAULT;
module_param_named(dump_loglevel, uv_nmi_loglevel, int, 0644);
/*
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aa8da0a49829..3e8d8f706589 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include /* For CONSOLE_LOGLEVEL_* */
+#include /* For CONSOLE_LOGLEVEL_DEBUG */
#include
#include
@@ -21,7 +21,7 @@
bool efi_nochunk;
bool efi_nokaslr = !IS_ENABLED(CONFIG_RANDOMIZE_BASE);
bool efi_noinitrd;
-int efi_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
+int efi_loglevel = CONFIG_CONSOLE_LOGLEVEL_DEFAULT;
bool efi_novamap;
static bool efi_nosoftreserve;
@@ -213,7 +213,7 @@ efi_status_t efi_parse_options(char const *cmdline)
if (!strcmp(param, "nokaslr")) {
efi_nokaslr = true;
} else if (!strcmp(param, "quiet")) {
- efi_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ efi_loglevel = CONFIG_CONSOLE_LOGLEVEL_QUIET;
} else if (!strcmp(param, "noinitrd")) {
efi_noinitrd = true;
} else if (!strcmp(param, "efi") && val) {
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 959f9e121cc6..e0ae7793155e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -103,7 +103,7 @@ static void sysrq_handle_loglevel(int key)
int i;
i = key - '0';
- console_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
+ console_loglevel = CONFIG_CONSOLE_LOGLEVEL_DEFAULT;
pr_info("Loglevel set to %d\n", i);
console_loglevel = i;
}
@@ -584,7 +584,7 @@ void __handle_sysrq(int key, bool check_mask)
* routing in the consumers of /proc/kmsg.
*/
orig_log_level = console_loglevel;
- console_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
+ console_loglevel = CONFIG_CONSOLE_LOGLEVEL_DEFAULT;
op_p = __sysrq_get_key_op(key);
if (op_p) {
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bf61598bf1c3..75b97268663f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers
[PATCH v4 1/3] dma-buf: heaps: Add deferred-free-helper library code
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.
As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
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
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
to a spinlock as Reported-by: kernel test robot
* Cleanup API to use a reason enum for clarity and add some documentation
comments as suggested by Suren Baghdasaryan.
v3:
* Minor tweaks so it can be built as a module
* A few small fixups suggested by Daniel Mentz
v4:
* Tweak from Daniel Mentz to make sure the shrinker
count/freed values are tracked in pages not bytes
---
drivers/dma-buf/heaps/Kconfig| 3 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/deferred-free-helper.c | 138 +++
drivers/dma-buf/heaps/deferred-free-helper.h | 55
4 files changed, 197 insertions(+)
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..f7aef8bc7119 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+ tristate
+
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..0ba02de9dc1c
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_size_pages;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+void deferred_free(struct deferred_freelist_item *item,
+ void (*free)(struct deferred_freelist_item*,
+ enum df_reason),
+ size_t size)
+{
+ unsigned long flags;
+
+ INIT_LIST_HEAD(&item->list);
+ item->size = size;
+ item->free = free;
+
+ spin_lock_irqsave(&free_list_lock, flags);
+ list_add(&item->list, &free_list);
+ list_size_pages += size >> PAGE_SHIFT;
+ spin_unlock_irqrestore(&free_list_lock, flags);
+ wake_up(&freelist_waitqueue);
+}
+EXPORT_SYMBOL_GPL(deferred_free);
+
+static size_t free_one_item(enum df_reason reason)
+{
+ unsigned long flags;
+ size_t size = 0;
+ struct deferred_freelist_item *item;
+
+ spin_lock_irqsave(&free_list_lock, flags);
+ if (list_empty(&free_list)) {
+ spin_unlock_irqrestore(&free_list_lock, flags);
+ return 0;
+ }
+ item = list_first_entry(&free_list, struct deferred_freelist_item,
list);
+ list_del(&item->list);
+ size = item->size;
+ list_size_pages -= size >> PAGE_SHIFT;
+ spin_unlock_irqrestore(&free_list_lock, flags);
+
+ item->free(item, reason);
+ return size >> PAGE_SHIFT;
+}
+
+static unsigned long get_freelist_size_pages(void)
+{
+ unsigned long size;
+ unsigned long flags;
+
+ spin_lock_irqsave(&free_list_lock, flags);
+ size = list_size_pages;
+ spin_unlock_irqrestore(&free_list_lock, flags);
+ return size;
+}
+
+static unsigned long freelist_shrink_count(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ return get_freelist_size_pages();
+}
+
+static unsigned long freelist_shrink_scan(struct shrinker *shrinker,
+
[PATCH v4 2/3] dma-buf: system_heap: Add pagepool support to system heap
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: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
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
---
v2:
* Fix build issue caused by selecting PAGE_POOL w/o NET
as Reported-by: kernel test robot
v3:
* Simplify the page zeroing logic a bit by using kmap_atomic
instead of vmap as suggested by Daniel Mentz
---
drivers/dma-buf/heaps/Kconfig | 2 ++
drivers/dma-buf/heaps/system_heap.c | 52 ++---
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index f7aef8bc7119..45c7d277448b 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,6 +4,8 @@ config DMABUF_HEAPS_DEFERRED_FREE
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+ select NET
+ 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 17e0e9a68baf..2addb6d832e0 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
static struct dma_heap *sys_heap;
@@ -53,6 +54,7 @@ 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)
{
@@ -281,18 +283,43 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
struct dma_buf_map *map)
dma_buf_map_clear(map);
}
+static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
+{
+ struct sg_table *sgt = &buffer->sg_table;
+ struct sg_page_iter piter;
+ struct page *p;
+ void *vaddr;
+ int ret = 0;
+
+ for_each_sgtable_page(sgt, &piter, 0) {
+ p = sg_page_iter_page(&piter);
+ vaddr = kmap_atomic(p);
+ memset(vaddr, 0, PAGE_SIZE);
+ kunmap_atomic(vaddr);
+ }
+
+ return ret;
+}
+
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;
+
+ /* Zero the buffer pages before adding back to the pool */
+ system_heap_zero_buffer(buffer);
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);
@@ -322,8 +349,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;
@@ -428,6 +454,24 @@ 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];
+ 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;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] dma-buf: system_heap: Add deferred freeing to the system heap
Utilize the deferred free helper library in the system heap.
This provides a nice performance bump and puts the
system heap performance on par with ION.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
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
---
v2:
* Rework deferred-free api to use reason enum as suggested by
Suren Baghdasaryan
---
drivers/dma-buf/heaps/Kconfig | 1 +
drivers/dma-buf/heaps/system_heap.c | 32 ++---
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 45c7d277448b..2276420ae905 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -6,6 +6,7 @@ config DMABUF_HEAPS_SYSTEM
depends on DMABUF_HEAPS
select NET
select PAGE_POOL
+ select DMABUF_HEAPS_DEFERRED_FREE
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 2addb6d832e0..fe122b5eff10 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,8 @@
#include
#include
+#include "deferred-free-helper.h"
+
static struct dma_heap *sys_heap;
struct system_heap_buffer {
@@ -32,6 +34,7 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+ struct deferred_freelist_item deferred_free;
};
struct dma_heap_attachment {
@@ -301,30 +304,45 @@ static int system_heap_zero_buffer(struct
system_heap_buffer *buffer)
return ret;
}
-static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+static void system_heap_buf_free(struct deferred_freelist_item *item,
+enum df_reason reason)
{
- struct system_heap_buffer *buffer = dmabuf->priv;
+ struct system_heap_buffer *buffer;
struct sg_table *table;
struct scatterlist *sg;
int i, j;
+ buffer = container_of(item, struct system_heap_buffer, deferred_free);
/* Zero the buffer pages before adding back to the pool */
- system_heap_zero_buffer(buffer);
+ if (reason == DF_NORMAL)
+ if (system_heap_zero_buffer(buffer))
+ reason = DF_UNDER_PRESSURE; // On failure, just free
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- for (j = 0; j < NUM_ORDERS; j++) {
- if (compound_order(page) == orders[j])
- break;
+ if (reason == DF_UNDER_PRESSURE) {
+ __free_pages(page, compound_order(page));
+ } else {
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
- page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
}
+static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+
+ deferred_free(&buffer->deferred_free, system_heap_buf_free,
buffer->len);
+}
+
static const struct dma_buf_ops system_heap_buf_ops = {
.attach = system_heap_attach,
.detach = system_heap_detach,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
