[PATCH 3/3] drm: Add a client-cap to set scheduling mode
From: Rob Clark
Add DRM_CLIENT_CAP_SCHED_MODE so that userspace can control the
scheduling mode for nonblocking atomic commits. Userspace such as
android, which treats the display pipeline as realtime (SCHED_FIFO)
should set DRM_CLIENT_CAP_SCHED_FIFO to prevent userspace components
of the display pipeline (like surfaceflinger) from preempting atomic
commit_work.
This cap may only be set by the drm master, after setting the
DRM_CLIENT_CAP_ATOMIC cap. The scheduling mode is returned to default
(SCHED_NORMAL) after master is dropped.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_auth.c | 4
drivers/gpu/drm/drm_crtc.c | 26 ++
drivers/gpu/drm/drm_ioctl.c | 13 +
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm.h | 13 +
5 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index f2d46b7ac6f9..217f422389f9 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -335,6 +336,9 @@ void drm_master_release(struct drm_file *file_priv)
drm_lease_revoke(master);
}
+ if (drm_core_check_feature(dev, DRIVER_ATOMIC) && file_priv->is_master)
+ drm_crtc_set_sched_mode(dev, DRM_CLIENT_CAP_SCHED_NORMAL);
+
/* drop the master reference held by the file priv */
if (file_priv->master)
drm_master_put(_priv->master);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4f7c0bfce0a3..02f2be0b1700 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -93,6 +93,32 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device *dev,
int idx)
}
EXPORT_SYMBOL(drm_crtc_from_index);
+/**
+ * drm_crtc_set_sched_mode:
+ * @dev: DRM device
+ * @mode: one of DRM_CLIENT_CAP_SCHED_x
+ *
+ * Set the scheduling mode for per-CRTC kthread workers. This controls
+ * whether nonblocking atomic commits will run with SCHED_NORMAL or
+ * SCHED_FIFO (rt) priority.
+ */
+void drm_crtc_set_sched_mode(struct drm_device *dev, int mode)
+{
+ struct drm_crtc *crtc;
+
+ drm_for_each_crtc(crtc, dev) {
+ switch (mode) {
+ case DRM_CLIENT_CAP_SCHED_NORMAL:
+ /* zero is default nice value for kthreads: */
+ sched_set_normal(crtc->worker->task, 0);
+ break;
+ case DRM_CLIENT_CAP_SCHED_FIFO:
+ sched_set_fifo(crtc->worker->task);
+ break;
+ }
+ }
+}
+
int drm_crtc_force_disable(struct drm_crtc *crtc)
{
struct drm_mode_set set = {
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 789ee65ac1f5..44920621571c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -362,6 +362,19 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
return -EINVAL;
file_priv->writeback_connectors = req->value;
break;
+ case DRM_CLIENT_CAP_SCHED_MODE:
+ if (!file_priv->is_master)
+ return -EPERM;
+ if (!file_priv->atomic)
+ return -EOPNOTSUPP;
+ switch (req->value) {
+ case DRM_CLIENT_CAP_SCHED_NORMAL:
+ case DRM_CLIENT_CAP_SCHED_FIFO:
+ drm_crtc_set_sched_mode(dev, req->value);
+ return 0;
+ default:
+ return -EINVAL;
+ }
default:
return -EINVAL;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8964a3732bca..6dd4d01b7191 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1245,6 +1245,8 @@ static inline uint32_t drm_crtc_mask(const struct
drm_crtc *crtc)
int drm_mode_set_config_internal(struct drm_mode_set *set);
struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx);
+void drm_crtc_set_sched_mode(struct drm_device *dev, int mode);
+
/**
* drm_crtc_find - look up a CRTC object from its ID
* @dev: DRM device
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a93330..989e007ef608 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -698,6 +698,19 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
+/**
+ * DRM_CLIENT_CAP_SCHED_MODE
+ *
+ * Allow userspace to control the scheduling parameters for nonblocking
+ * commit. The default is SCHED_NORMAL/CFS. Userspace using SCHED_FIFO
+ * in the rendering/display pipeline should use DRM_CLIENT_CAP_SCHED_FIFO
+ * to prevent userspace portions of the display pipeline from preempting
+ * nonblocking commit_work.
+ */
+#define DRM_CLIENT_CAP_SCHED_MODE 6
+# define DRM_CLIENT_CAP_SCHED_NORMAL 0
+#
[PATCH 0/3] drm: commit_work scheduling
From: Rob Clark
The android userspace treats the display pipeline as a realtime problem.
And arguably, if your goal is to not miss frame deadlines (ie. vblank),
it is. (See https://lwn.net/Articles/809545/ for the best explaination
that I found.)
But this presents a problem with using workqueues for non-blocking
atomic commit_work(), because the SCHED_FIFO userspace thread(s) can
preempt the worker. Which is not really the outcome you want.. once
the required fences are scheduled, you want to push the atomic commit
down to hw ASAP.
But the decision of whether commit_work should be RT or not really
depends on what userspace is doing. For a pure CFS userspace display
pipeline, commit_work() should remain SCHED_NORMAL.
To handle this, convert non-blocking commit_work() to use per-CRTC
kthread workers, instead of system_unbound_wq. Per-CRTC workers are
used to avoid serializing commits when userspace is using a per-CRTC
update loop.
A client-cap is introduced so that userspace can opt-in to SCHED_FIFO
priority commit work.
A potential issue is that since 616d91b68cd ("sched: Remove
sched_setscheduler*() EXPORTs") we have limited RT priority levels,
meaning that commit_work() ends up running at the same priority level
as vblank-work. This shouldn't be a big problem *yet*, due to limited
use of vblank-work at this point. And if it could be arranged that
vblank-work is scheduled before signaling out-fences and/or sending
pageflip events, it could probably work ok to use a single priority
level for both commit-work and vblank-work.
Rob Clark (3):
drm/crtc: Introduce per-crtc kworker
drm/atomic: Use kthread worker for nonblocking commits
drm: Add a client-cap to set scheduling mode
drivers/gpu/drm/drm_atomic_helper.c | 13 ++
drivers/gpu/drm/drm_auth.c | 4
drivers/gpu/drm/drm_crtc.c | 37 +
drivers/gpu/drm/drm_ioctl.c | 13 ++
include/drm/drm_atomic.h| 31
include/drm/drm_crtc.h | 10
include/uapi/drm/drm.h | 13 ++
7 files changed, 117 insertions(+), 4 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/atomic: Use kthread worker for nonblocking commits
From: Rob Clark
This will allow us to more easily switch scheduling rules based on what
userspace wants.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 13
include/drm/drm_atomic.h| 31 +
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9e1ad493e689..75eeec5e7b10 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1659,11 +1659,11 @@ static void commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_state_put(old_state);
}
-static void commit_work(struct work_struct *work)
+static void commit_work(struct kthread_work *work)
{
struct drm_atomic_state *state = container_of(work,
struct drm_atomic_state,
- commit_work);
+ commit_kwork);
commit_tail(state);
}
@@ -1797,6 +1797,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
struct drm_atomic_state *state,
bool nonblock)
{
+ struct kthread_worker *worker = NULL;
int ret;
if (state->async_update) {
@@ -1814,7 +1815,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
- INIT_WORK(>commit_work, commit_work);
+ kthread_init_work(>commit_kwork, commit_work);
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
@@ -1857,8 +1858,12 @@ int drm_atomic_helper_commit(struct drm_device *dev,
*/
drm_atomic_state_get(state);
+
if (nonblock)
- queue_work(system_unbound_wq, >commit_work);
+ worker = drm_atomic_pick_worker(state);
+
+ if (worker)
+ kthread_queue_work(worker, >commit_kwork);
else
commit_tail(state);
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d07c851d255b..8d0ee19953df 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -373,8 +373,18 @@ struct drm_atomic_state {
*
* Work item which can be used by the driver or helpers to execute the
* commit without blocking.
+*
+* This is deprecated, use commit_kwork.
*/
struct work_struct commit_work;
+
+ /**
+* @commit_kwork:
+*
+* Work item which can be used by the driver or helpers to execute the
+* commit without blocking.
+*/
+ struct kthread_work commit_kwork;
};
void __drm_crtc_commit_free(struct kref *kref);
@@ -954,6 +964,27 @@ void drm_state_dump(struct drm_device *dev, struct
drm_printer *p);
(new_obj_state) = (__state)->private_objs[__i].new_state,
1); \
(__i)++)
+/**
+ * drm_atomic_pick_worker - helper to get kworker to use for nonblocking commit
+ * @state: the _atomic_state for the commit
+ *
+ * Pick an appropriate worker for a given atomic update. The first CRTC
+ * invovled in the atomic update is used to pick the worker, to prevent
+ * serializing multiple pageflips / atomic-updates on indenpendent CRTCs.
+ */
+static inline struct kthread_worker *
+drm_atomic_pick_worker(const struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ unsigned i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+ return crtc->worker;
+
+ return NULL;
+}
+
/**
* drm_atomic_crtc_needs_modeset - compute combined modeset need
* @state: _crtc_state for the CRTC
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/crtc: Introduce per-crtc kworker
From: Rob Clark
This will be used for non-block atomic commits.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 11 +++
include/drm/drm_crtc.h | 8
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index aecdd7ea26dc..4f7c0bfce0a3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -326,6 +326,14 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
config->prop_out_fence_ptr, 0);
drm_object_attach_property(>base,
config->prop_vrr_enabled, 0);
+
+ crtc->worker = kthread_create_worker(0, "%s-worker",
crtc->name);
+ if (IS_ERR(crtc->worker)) {
+ drm_mode_object_unregister(dev, >base);
+ ret = PTR_ERR(crtc->worker);
+ crtc->worker = NULL;
+ return ret;
+ }
}
return 0;
@@ -366,6 +374,9 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
kfree(crtc->name);
+ if (crtc->worker)
+ kthread_destroy_worker(crtc->worker);
+
memset(crtc, 0, sizeof(*crtc));
}
EXPORT_SYMBOL(drm_crtc_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 59b51a09cae6..8964a3732bca 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1172,6 +1173,13 @@ struct drm_crtc {
* Initialized via drm_self_refresh_helper_init().
*/
struct drm_self_refresh_data *self_refresh_data;
+
+ /**
+* worker:
+*
+* Per-CRTC worker for nonblock atomic commits.
+*/
+ struct kthread_worker *worker;
};
/**
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote: > > My concern with that is people might use kmap() and then pass the address > to a different task. So we need to audit the current users of kmap() > and convert any that do that into using vmap() instead. Ahh. Yes, I guess they might do that. It sounds strange, but not entirely crazy - I could imagine some "PIO thread" that does IO to a page that has been set up by somebody else using kmap(). Or similar. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF
On Fri, Sep 18, 2020 at 09:57:37AM -0400, Alex Deucher wrote: On Fri, Sep 18, 2020 at 3:17 AM Quan, Evan wrote: [AMD Official Use Only - Internal Distribution Only] Hi @Sasha Levin @Deucher, Alexander, The following changes need to be applied also. Otherwise, you may see unexpected shutdown on stress gpu loading on Vega10. drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting drm/amd/pm: correct the thermal alert temperature limit settings drm/amd/pm: correct Vega20 swctf limit setting drm/amd/pm: correct Vega12 swctf limit setting drm/amd/pm: correct Vega10 swctf limit setting I would suggest we just drop this patch for kernels prior to 5.8 (where it was introduced). Will do, thanks. -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote: > > this provides a preemptible variant of kmap_atomic & related > interfaces. This is achieved by: Ack. This looks really nice, even apart from the new capability. The only thing I really reacted to is that the name doesn't make sense to me: "kmap_temporary()" seems a bit odd. Particularly for an interface that really is basically meant as a better replacement of "kmap_atomic()" (but is perhaps also a better replacement for "kmap()"). I think I understand how the name came about: I think the "temporary" is there as a distinction from the "longterm" regular kmap(). So I think it makes some sense from an internal implementation angle, but I don't think it makes a lot of sense from an interface name. I don't know what might be a better name, but if we want to emphasize that it's thread-private and a one-off, maybe "local" would be a better naming, and make it distinct from the "global" nature of the old kmap() interface? However, another solution might be to just use this new preemptible "local" kmap(), and remove the old global one entirely. Yes, the old global one caches the page table mapping and that sounds really efficient and nice. But it's actually horribly horribly bad, because it means that we need to use locking for them. Your new "temporary" implementation seems to be fundamentally better locking-wise, and only need preemption disabling as locking (and is equally fast for the non-highmem case). So I wonder if the single-page TLB flush isn't a better model, and whether it wouldn't be a lot simpler to just get rid of the old complex kmap() entirely, and replace it with this? I agree we can't replace the kmap_atomic() version, because maybe people depend on the preemption disabling it also implied. But what about replacing the non-atomic kmap()? Maybe I've missed something. Is it because the new interface still does "pagefault_disable()" perhaps? But does it even need the pagefault_disable() at all? Yes, the *atomic* one obviously needed it. But why does this new one need to disable page faults? [ I'm just reading the patches, I didn't try to apply them and look at the end result, so I might have missed something ] The only other worry I would have is just test coverage of this change. I suspect very few developers use HIGHMEM. And I know the various test robots don't tend to test 32-bit either. But apart from that question about naming (and perhaps replacing kmap() entirely), I very much like it. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/omap: dsi: simplify the return expression of dsi_init_pll_data
Simplify the return expression.
Signed-off-by: Liu Shixin
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index eeccf40bae41..cac0d1993dab 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5015,7 +5015,6 @@ static int dsi_init_pll_data(struct dss_device *dss,
struct dsi_data *dsi)
{
struct dss_pll *pll = >pll;
struct clk *clk;
- int r;
clk = devm_clk_get(dsi->dev, "sys_clk");
if (IS_ERR(clk)) {
@@ -5030,11 +5029,7 @@ static int dsi_init_pll_data(struct dss_device *dss,
struct dsi_data *dsi)
pll->hw = dsi->data->pll_hw;
pll->ops = _pll_ops;
- r = dss_pll_register(dss, pll);
- if (r)
- return r;
-
- return 0;
+ return dss_pll_register(dss, pll);
}
/*
-
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/lima: simplify the return expression of lima_devfreq_target
Simplify the return expression.
Signed-off-by: Liu Shixin
---
drivers/gpu/drm/lima/lima_devfreq.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index bbe02817721b..5914442936ed 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -35,18 +35,13 @@ static int lima_devfreq_target(struct device *dev, unsigned
long *freq,
u32 flags)
{
struct dev_pm_opp *opp;
- int err;
opp = devfreq_recommended_opp(dev, freq, flags);
if (IS_ERR(opp))
return PTR_ERR(opp);
dev_pm_opp_put(opp);
- err = dev_pm_opp_set_rate(dev, *freq);
- if (err)
- return err;
-
- return 0;
+ return dev_pm_opp_set_rate(dev, *freq);
}
static void lima_devfreq_reset(struct lima_devfreq *devfreq)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 357/442] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3043:6: warning: no previous prototype for function 'dc_is_plane_eligible_for_idle_optimizaitons'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 4589b6459d145ea133422b91be2f55a40fe74463 commit: cf3da8ea14f50741d6ddd3bee410459703036c4c [357/442] drm/amd/display: Update idle optimization handling config: x86_64-randconfig-a002-20200919 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project ed79827aea444e6995fb3d36abc2bfd36331773c) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git checkout cf3da8ea14f50741d6ddd3bee410459703036c4c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:777:6: warning: no previous prototype for function 'apply_ctx_interdependent_lock' [-Wmissing-prototypes] void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context, struct dc_stream_state *stream, bool lock) ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:777:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context, struct dc_stream_state *stream, bool lock) ^ static >> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3043:6: warning: no >> previous prototype for function >> 'dc_is_plane_eligible_for_idle_optimizaitons' [-Wmissing-prototypes] bool dc_is_plane_eligible_for_idle_optimizaitons(struct dc *dc, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3043:1: note: declare 'static' if the function is not intended to be used outside of this translation unit bool dc_is_plane_eligible_for_idle_optimizaitons(struct dc *dc, ^ static 2 warnings generated. git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git git fetch --no-tags radeon-alex amd-staging-drm-next git checkout cf3da8ea14f50741d6ddd3bee410459703036c4c vim +/dc_is_plane_eligible_for_idle_optimizaitons +3043 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c 3042 > 3043 bool dc_is_plane_eligible_for_idle_optimizaitons(struct dc *dc, --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/selftests: align more to real device lifetimes
To avoid having to create all the device and driver scaffolding we
just manually create and destroy a devres_group.
v2: Rebased
v3: use devres_open/release_group so we can use devm without real
hacks in the driver core or having to create an entire fake bus for
testing drivers. Might want to extract this into helpers eventually,
maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
v4:
- Fix IS_ERR handling (Matt)
- Delete surplus put_device() in mock_device_release (intel-gfx-ci)
v5:
- do not switch to device_add - it breaks runtime pm in the tests and
with the devres_group_add/release no longer needed for automatic
cleanup (CI). Update commit message to match.
- print correct error in pr_err (Matt)
v6: Remove now unused err variable (CI).
v7: More warning fixes ...
Cc: Matthew Auld
Reviewed-by: Maarten Lankhorst (v3)
Cc: Maarten Lankhorst
Reviewed-by: Matthew Auld (v4)
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 39 +--
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index ac600d395c8f..b6c42fd872ad 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -79,8 +79,6 @@ static void mock_device_release(struct drm_device *dev)
out:
i915_params_free(>params);
- put_device(>drm.pdev->dev);
- i915->drm.pdev = NULL;
}
static struct drm_driver mock_driver = {
@@ -123,17 +121,10 @@ struct drm_i915_private *mock_gem_device(void)
#endif
struct drm_i915_private *i915;
struct pci_dev *pdev;
- int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
return NULL;
- i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
- if (!i915) {
- kfree(pdev);
- return NULL;
- }
-
device_initialize(>dev);
pdev->class = PCI_BASE_CLASS_DISPLAY << 16;
pdev->dev.release = release_dev;
@@ -144,8 +135,23 @@ struct drm_i915_private *mock_gem_device(void)
/* HACK to disable iommu for the fake device; force identity mapping */
pdev->dev.iommu = _iommu;
#endif
+ if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
+ put_device(>dev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(>dev, _driver,
+ struct drm_i915_private, drm);
+ if (IS_ERR(i915)) {
+ pr_err("Failed to allocate mock GEM device: err=%ld\n",
PTR_ERR(i915));
+ devres_release_group(>dev, NULL);
+ put_device(>dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(>dev, _domain);
pm_runtime_enable(>dev);
@@ -153,16 +159,6 @@ struct drm_i915_private *mock_gem_device(void)
if (pm_runtime_enabled(>dev))
WARN_ON(pm_runtime_get_sync(>dev));
- err = drm_dev_init(>drm, _driver, >dev);
- if (err) {
- pr_err("Failed to initialise mock GEM device: err=%d\n", err);
- put_device(>dev);
- kfree(i915);
-
- return NULL;
- }
- i915->drm.pdev = pdev;
- drmm_add_final_kfree(>drm, i915);
i915_params_copy(>params, _modparams);
@@ -229,5 +225,8 @@ struct drm_i915_private *mock_gem_device(void)
void mock_destroy_device(struct drm_i915_private *i915)
{
- drm_dev_put(>drm);
+ struct device *dev = i915->drm.dev;
+
+ devres_release_group(dev, NULL);
+ put_device(dev);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/selftests: align more to real device lifetimes
To avoid having to create all the device and driver scaffolding we
just manually create and destroy a devres_group.
v2: Rebased
v3: use devres_open/release_group so we can use devm without real
hacks in the driver core or having to create an entire fake bus for
testing drivers. Might want to extract this into helpers eventually,
maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
v4:
- Fix IS_ERR handling (Matt)
- Delete surplus put_device() in mock_device_release (intel-gfx-ci)
v5:
- do not switch to device_add - it breaks runtime pm in the tests and
with the devres_group_add/release no longer needed for automatic
cleanup (CI). Update commit message to match.
- print correct error in pr_err (Matt)
v6: Remove now unused err variable (CI).
Cc: Matthew Auld
Reviewed-by: Maarten Lankhorst (v3)
Cc: Maarten Lankhorst
Reviewed-by: Matthew Auld (v4)
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 39 +--
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index ac600d395c8f..b7db3ec346ba 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -79,8 +79,6 @@ static void mock_device_release(struct drm_device *dev)
out:
i915_params_free(>params);
- put_device(>drm.pdev->dev);
- i915->drm.pdev = NULL;
}
static struct drm_driver mock_driver = {
@@ -123,17 +121,10 @@ struct drm_i915_private *mock_gem_device(void)
#endif
struct drm_i915_private *i915;
struct pci_dev *pdev;
- int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
return NULL;
- i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
- if (!i915) {
- kfree(pdev);
- return NULL;
- }
-
device_initialize(>dev);
pdev->class = PCI_BASE_CLASS_DISPLAY << 16;
pdev->dev.release = release_dev;
@@ -144,8 +135,23 @@ struct drm_i915_private *mock_gem_device(void)
/* HACK to disable iommu for the fake device; force identity mapping */
pdev->dev.iommu = _iommu;
#endif
+ if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
+ put_device(>dev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(>dev, _driver,
+ struct drm_i915_private, drm);
+ if (IS_ERR(i915)) {
+ pr_err("Failed to allocate mock GEM device: err=%d\n",
PTR_ERR(i915));
+ devres_release_group(>dev, NULL);
+ put_device(>dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(>dev, _domain);
pm_runtime_enable(>dev);
@@ -153,16 +159,6 @@ struct drm_i915_private *mock_gem_device(void)
if (pm_runtime_enabled(>dev))
WARN_ON(pm_runtime_get_sync(>dev));
- err = drm_dev_init(>drm, _driver, >dev);
- if (err) {
- pr_err("Failed to initialise mock GEM device: err=%d\n", err);
- put_device(>dev);
- kfree(i915);
-
- return NULL;
- }
- i915->drm.pdev = pdev;
- drmm_add_final_kfree(>drm, i915);
i915_params_copy(>params, _modparams);
@@ -229,5 +225,8 @@ struct drm_i915_private *mock_gem_device(void)
void mock_destroy_device(struct drm_i915_private *i915)
{
- drm_dev_put(>drm);
+ struct device *dev = i915->drm.dev;
+
+ devres_release_group(dev, NULL);
+ put_device(dev);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/lima: simplify the return expression of lima_devfreq_target
Looks good for me, patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Sat, Sep 19, 2020 at 5:47 PM Liu Shixin wrote:
>
> Simplify the return expression.
>
> Signed-off-by: Liu Shixin
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/lima/lima_devfreq.c
> index bbe02817721b..5914442936ed 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -35,18 +35,13 @@ static int lima_devfreq_target(struct device *dev,
> unsigned long *freq,
>u32 flags)
> {
> struct dev_pm_opp *opp;
> - int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp))
> return PTR_ERR(opp);
> dev_pm_opp_put(opp);
>
> - err = dev_pm_opp_set_rate(dev, *freq);
> - if (err)
> - return err;
> -
> - return 0;
> + return dev_pm_opp_set_rate(dev, *freq);
> }
>
> static void lima_devfreq_reset(struct lima_devfreq *devfreq)
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote: > > On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote: > > > > First of all, sorry for the horribly big Cc list! > > > > Following up to the discussion in: > > > > https://lore.kernel.org/r/20200914204209.256266...@linutronix.de > > > > this provides a preemptible variant of kmap_atomic & related > > interfaces. This is achieved by: > > > > - Consolidating all kmap atomic implementations in generic code > > > > - Switching from per CPU storage of the kmap index to a per task storage > > > > - Adding a pteval array to the per task storage which contains the ptevals > >of the currently active temporary kmaps > > > > - Adding context switch code which checks whether the outgoing or the > >incoming task has active temporary kmaps. If so, the outgoing task's > >kmaps are removed and the incoming task's kmaps are restored. > > > > - Adding new interfaces k[un]map_temporary*() which are not disabling > >preemption and can be called from any context (except NMI). > > > >Contrary to kmap() which provides preemptible and "persistant" mappings, > >these interfaces are meant to replace the temporary mappings provided by > >kmap_atomic*() today. > > > > This allows to get rid of conditional mapping choices and allows to have > > preemptible short term mappings on 64bit which are today enforced to be > > non-preemptible due to the highmem constraints. It clearly puts overhead on > > the highmem users, but highmem is slow anyway. > > > > This is not a wholesale conversion which makes kmap_atomic magically > > preemptible because there might be usage sites which rely on the implicit > > preempt disable. So this needs to be done on a case by case basis and the > > call sites converted to kmap_temporary. > > > > Note, that this is only lightly tested on X86 and completely untested on > > all other architectures. > > > > The lot is also available from > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem > > I think it should be the case, but I want to double check: Will > copy_*_user be allowed within a kmap_temporary section? This would > allow us to ditch an absolute pile of slowpaths. (coffee just kicked in) copy_*_user is ofc allowed, but if you hit a page fault you get a short read/write. This looks like it would remove the need to handle these in a slowpath, since page faults can now be served in this new kmap_temporary sections. But this sounds too good to be true, so I'm wondering what I'm missing. -Daniel > > > > > Thanks, > > > > tglx > > --- > > a/arch/arm/mm/highmem.c | 121 - > > a/arch/microblaze/mm/highmem.c| 78 - > > a/arch/nds32/mm/highmem.c | 48 > > a/arch/powerpc/mm/highmem.c | 67 --- > > a/arch/sparc/mm/highmem.c | 115 > > arch/arc/Kconfig |1 > > arch/arc/include/asm/highmem.h|8 + > > arch/arc/mm/highmem.c | 44 --- > > arch/arm/Kconfig |1 > > arch/arm/include/asm/highmem.h| 30 +++-- > > arch/arm/mm/Makefile |1 > > arch/csky/Kconfig |1 > > arch/csky/include/asm/highmem.h |4 > > arch/csky/mm/highmem.c| 75 - > > arch/microblaze/Kconfig |1 > > arch/microblaze/include/asm/highmem.h |6 - > > arch/microblaze/mm/Makefile |1 > > arch/microblaze/mm/init.c |6 - > > arch/mips/Kconfig |1 > > arch/mips/include/asm/highmem.h |4 > > arch/mips/mm/highmem.c| 77 - > > arch/mips/mm/init.c |3 > > arch/nds32/Kconfig.cpu|1 > > arch/nds32/include/asm/highmem.h | 21 ++- > > arch/nds32/mm/Makefile|1 > > arch/powerpc/Kconfig |1 > > arch/powerpc/include/asm/highmem.h|6 - > > arch/powerpc/mm/Makefile |1 > > arch/powerpc/mm/mem.c |7 - > > arch/sparc/Kconfig|1 > > arch/sparc/include/asm/highmem.h |7 - > > arch/sparc/mm/Makefile|3 > > arch/sparc/mm/srmmu.c |2 > > arch/x86/include/asm/fixmap.h |1 > > arch/x86/include/asm/highmem.h| 12 +- > > arch/x86/include/asm/iomap.h | 29 +++-- > > arch/x86/mm/highmem_32.c | 59 -- > > arch/x86/mm/init_32.c | 15 -- > > arch/x86/mm/iomap_32.c| 57 -- > > arch/xtensa/Kconfig |1 > > arch/xtensa/include/asm/highmem.h |9 + > > arch/xtensa/mm/highmem.c | 44 --- > > b/arch/x86/Kconfig|3 > > include/linux/highmem.h | 141
Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote: > > First of all, sorry for the horribly big Cc list! > > Following up to the discussion in: > > https://lore.kernel.org/r/20200914204209.256266...@linutronix.de > > this provides a preemptible variant of kmap_atomic & related > interfaces. This is achieved by: > > - Consolidating all kmap atomic implementations in generic code > > - Switching from per CPU storage of the kmap index to a per task storage > > - Adding a pteval array to the per task storage which contains the ptevals >of the currently active temporary kmaps > > - Adding context switch code which checks whether the outgoing or the >incoming task has active temporary kmaps. If so, the outgoing task's >kmaps are removed and the incoming task's kmaps are restored. > > - Adding new interfaces k[un]map_temporary*() which are not disabling >preemption and can be called from any context (except NMI). > >Contrary to kmap() which provides preemptible and "persistant" mappings, >these interfaces are meant to replace the temporary mappings provided by >kmap_atomic*() today. > > This allows to get rid of conditional mapping choices and allows to have > preemptible short term mappings on 64bit which are today enforced to be > non-preemptible due to the highmem constraints. It clearly puts overhead on > the highmem users, but highmem is slow anyway. > > This is not a wholesale conversion which makes kmap_atomic magically > preemptible because there might be usage sites which rely on the implicit > preempt disable. So this needs to be done on a case by case basis and the > call sites converted to kmap_temporary. > > Note, that this is only lightly tested on X86 and completely untested on > all other architectures. > > The lot is also available from > >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem I think it should be the case, but I want to double check: Will copy_*_user be allowed within a kmap_temporary section? This would allow us to ditch an absolute pile of slowpaths. -Daniel > > Thanks, > > tglx > --- > a/arch/arm/mm/highmem.c | 121 - > a/arch/microblaze/mm/highmem.c| 78 - > a/arch/nds32/mm/highmem.c | 48 > a/arch/powerpc/mm/highmem.c | 67 --- > a/arch/sparc/mm/highmem.c | 115 > arch/arc/Kconfig |1 > arch/arc/include/asm/highmem.h|8 + > arch/arc/mm/highmem.c | 44 --- > arch/arm/Kconfig |1 > arch/arm/include/asm/highmem.h| 30 +++-- > arch/arm/mm/Makefile |1 > arch/csky/Kconfig |1 > arch/csky/include/asm/highmem.h |4 > arch/csky/mm/highmem.c| 75 - > arch/microblaze/Kconfig |1 > arch/microblaze/include/asm/highmem.h |6 - > arch/microblaze/mm/Makefile |1 > arch/microblaze/mm/init.c |6 - > arch/mips/Kconfig |1 > arch/mips/include/asm/highmem.h |4 > arch/mips/mm/highmem.c| 77 - > arch/mips/mm/init.c |3 > arch/nds32/Kconfig.cpu|1 > arch/nds32/include/asm/highmem.h | 21 ++- > arch/nds32/mm/Makefile|1 > arch/powerpc/Kconfig |1 > arch/powerpc/include/asm/highmem.h|6 - > arch/powerpc/mm/Makefile |1 > arch/powerpc/mm/mem.c |7 - > arch/sparc/Kconfig|1 > arch/sparc/include/asm/highmem.h |7 - > arch/sparc/mm/Makefile|3 > arch/sparc/mm/srmmu.c |2 > arch/x86/include/asm/fixmap.h |1 > arch/x86/include/asm/highmem.h| 12 +- > arch/x86/include/asm/iomap.h | 29 +++-- > arch/x86/mm/highmem_32.c | 59 -- > arch/x86/mm/init_32.c | 15 -- > arch/x86/mm/iomap_32.c| 57 -- > arch/xtensa/Kconfig |1 > arch/xtensa/include/asm/highmem.h |9 + > arch/xtensa/mm/highmem.c | 44 --- > b/arch/x86/Kconfig|3 > include/linux/highmem.h | 141 +++- > include/linux/io-mapping.h|2 > include/linux/sched.h |9 + > kernel/sched/core.c | 10 + > mm/Kconfig|3 > mm/highmem.c | 192 > -- > 49 files changed, 422 insertions(+), 909 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCH v11 1/3] dt-bindings: drm/bridge: Document Cadence MHDP8546 bridge bindings
From: Yuti Amonkar
Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
---
.../display/bridge/cdns,mhdp8546.yaml | 169 ++
1 file changed, 169 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
new file mode 100644
index ..74d675fc6e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence MHDP8546 bridge
+
+maintainers:
+ - Swapnil Jakhade
+ - Yuti Amonkar
+
+properties:
+ compatible:
+enum:
+ - cdns,mhdp8546
+ - ti,j721e-mhdp8546
+
+ reg:
+minItems: 1
+maxItems: 2
+items:
+ - description:
+ Register block of mhdptx apb registers up to PHY mapped area
(AUX_CONFIG_P).
+ The AUX and PMA registers are not part of this range, they are
instead
+ included in the associated PHY.
+ - description:
+ Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
SoCs.
+
+ reg-names:
+minItems: 1
+maxItems: 2
+items:
+ - const: mhdptx
+ - const: j721e-intg
+
+ clocks:
+maxItems: 1
+description:
+ DP bridge clock, used by the IP to know how to translate a number of
+ clock cycles into a time (which is used to comply with DP standard
timings
+ and delays).
+
+ phys:
+maxItems: 1
+description:
+ phandle to the DisplayPort PHY.
+
+ phy-names:
+items:
+ - const: dpphy
+
+ power-domains:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ ports:
+type: object
+description:
+ Ports as described in Documentation/devicetree/bindings/graph.txt.
+
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ port@0:
+type: object
+description:
+ First input port representing the DP bridge input.
+
+ port@1:
+type: object
+description:
+ Second input port representing the DP bridge input.
+
+ port@2:
+type: object
+description:
+ Third input port representing the DP bridge input.
+
+ port@3:
+type: object
+description:
+ Fourth input port representing the DP bridge input.
+
+ port@4:
+type: object
+description:
+ Output port representing the DP bridge output.
+
+required:
+ - port@0
+ - port@4
+ - '#address-cells'
+ - '#size-cells'
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,j721e-mhdp8546
+then:
+ properties:
+reg:
+ minItems: 2
+reg-names:
+ minItems: 2
+else:
+ properties:
+reg:
+ maxItems: 1
+reg-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - reg-names
+ - phys
+ - phy-names
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mhdp: dp-bridge@f0fb00 {
+compatible = "cdns,mhdp8546";
+reg = <0xf0 0xfb00 0x0 0x100>;
+reg-names = "mhdptx";
+clocks = <_clock>;
+phys = <_phy>;
+phy-names = "dpphy";
+interrupts = ;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dp_bridge_input: endpoint {
+remote-endpoint = <_dpi_output>;
+};
+};
+
+port@4 {
+reg = <4>;
+dp_bridge_output: endpoint {
+remote-endpoint = <_dp_connector_input>;
+};
+};
+};
+};
+};
+...
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: update kernel-doc line comments
Update kernel-doc line comments to fix warnings reported by make W=1. drivers/gpu/drm/drm_dp_helper.c:1036: warning: Function parameter or member 'dpcd' not described in 'drm_dp_subconnector_type' drivers/gpu/drm/drm_dp_helper.c:1036: warning: Function parameter or member 'port_cap' not described in 'drm_dp_subconnector_type' drivers/gpu/drm/drm_dp_helper.c:1089: warning: Function parameter or member 'connector' not described in 'drm_dp_set_subconnector_property' drivers/gpu/drm/drm_dp_helper.c:1089: warning: Function parameter or member 'status' not described in 'drm_dp_set_subconnector_property' drivers/gpu/drm/drm_dp_helper.c:1089: warning: Function parameter or member 'dpcd' not described in 'drm_dp_set_subconnector_property' drivers/gpu/drm/drm_dp_helper.c:1089: warning: Function parameter or member 'port_cap' not described in 'drm_dp_set_subconnector_property' Signed-off-by: Tian Tao --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 90807a6..a12485f 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1026,7 +1026,7 @@ void drm_dp_downstream_debug(struct seq_file *m, } EXPORT_SYMBOL(drm_dp_downstream_debug); -/** +/* * drm_dp_subconnector_type() - get DP branch device type * */ @@ -1077,7 +1077,7 @@ drm_dp_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], } EXPORT_SYMBOL(drm_dp_subconnector_type); -/** +/* * drm_mode_set_dp_subconnector_property - set subconnector for DP connector * * Called by a driver on every detect event. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
On Fri, Sep 18, 2020 at 11:45:34AM +0300, Dan Carpenter wrote:
> Hi Xin,
>
> url:
> https://github.com/0day-ci/linux/commits/Xin-Ji/Add-initial-support-for-slimport-anx7625/20200917-163238
> base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 5925fa68fe8244651b3f78a88c4af99190a88f0d
> config: mips-randconfig-m031-20200917 (attached as .config)
> compiler: mips-linux-gcc (GCC) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
Hi Dan, OK, I'll fix it right now.
Thanks,
Xin
>
> smatch warnings:
> drivers/gpu/drm/bridge/analogix/anx7625.c:1289 anx7625_get_edid() warn:
> possible memory leak of 'edid'
>
> #
> https://github.com/0day-ci/linux/commit/667ee517c70d2bedafe5bfa0dc5f13fc60d5133d
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review
> Xin-Ji/Add-initial-support-for-slimport-anx7625/20200917-163238
> git checkout 667ee517c70d2bedafe5bfa0dc5f13fc60d5133d
> vim +/edid +1289 drivers/gpu/drm/bridge/analogix/anx7625.c
>
> 667ee517c70d2be Xin Ji 2020-09-17 1264 static struct edid
> *anx7625_get_edid(struct anx7625_data *ctx)
> 667ee517c70d2be Xin Ji 2020-09-17 1265 {
> 667ee517c70d2be Xin Ji 2020-09-17 1266 struct device *dev =
> >client->dev;
> 667ee517c70d2be Xin Ji 2020-09-17 1267 struct s_edid_data *p_edid =
> >slimport_edid_p;
> 667ee517c70d2be Xin Ji 2020-09-17 1268 int edid_num;
> 667ee517c70d2be Xin Ji 2020-09-17 1269 u8 *edid;
> 667ee517c70d2be Xin Ji 2020-09-17 1270
> 667ee517c70d2be Xin Ji 2020-09-17 1271 edid = kmalloc(FOUR_BLOCK_SIZE,
> GFP_KERNEL);
> 667ee517c70d2be Xin Ji 2020-09-17 1272 if (!edid) {
> 667ee517c70d2be Xin Ji 2020-09-17 1273 DRM_DEV_ERROR(dev,
> "Fail to allocate buffer\n");
> 667ee517c70d2be Xin Ji 2020-09-17 1274 return NULL;
> 667ee517c70d2be Xin Ji 2020-09-17 1275 }
> 667ee517c70d2be Xin Ji 2020-09-17 1276
> 667ee517c70d2be Xin Ji 2020-09-17 1277 if
> (ctx->slimport_edid_p.edid_block_num > 0) {
> 667ee517c70d2be Xin Ji 2020-09-17 1278 memcpy(edid,
> ctx->slimport_edid_p.edid_raw_data,
> 667ee517c70d2be Xin Ji 2020-09-17 1279 FOUR_BLOCK_SIZE);
> 667ee517c70d2be Xin Ji 2020-09-17 1280 return (struct edid
> *)edid;
> 667ee517c70d2be Xin Ji 2020-09-17 1281 }
> 667ee517c70d2be Xin Ji 2020-09-17 1282
> 667ee517c70d2be Xin Ji 2020-09-17 1283
> anx7625_low_power_mode_check(ctx, 1);
> 667ee517c70d2be Xin Ji 2020-09-17 1284 edid_num = sp_tx_edid_read(ctx,
> p_edid->edid_raw_data);
> 667ee517c70d2be Xin Ji 2020-09-17 1285
> anx7625_low_power_mode_check(ctx, 0);
> 667ee517c70d2be Xin Ji 2020-09-17 1286
> 667ee517c70d2be Xin Ji 2020-09-17 1287 if (edid_num < 1) {
> 667ee517c70d2be Xin Ji 2020-09-17 1288 DRM_DEV_ERROR(dev,
> "Fail to read EDID: %d\n", edid_num);
> 667ee517c70d2be Xin Ji 2020-09-17 @1289 return NULL;
>
> kfree(edid); before returning.
>
> 667ee517c70d2be Xin Ji 2020-09-17 1290 }
> 667ee517c70d2be Xin Ji 2020-09-17 1291
> 667ee517c70d2be Xin Ji 2020-09-17 1292 p_edid->edid_block_num =
> edid_num;
> 667ee517c70d2be Xin Ji 2020-09-17 1293
> 667ee517c70d2be Xin Ji 2020-09-17 1294 memcpy(edid,
> ctx->slimport_edid_p.edid_raw_data, FOUR_BLOCK_SIZE);
> 667ee517c70d2be Xin Ji 2020-09-17 1295 return (struct edid *)edid;
> 667ee517c70d2be Xin Ji 2020-09-17 1296 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
and embedded Display Port (eDP) standards. It integrates uCPU running the
embedded Firmware (FW) interfaced over APB interface.
Basically, it takes a DPI stream as input and outputs it encoded in DP
format. Currently, it supports only SST mode.
Co-developed-by: Tomi Valkeinen
Signed-off-by: Tomi Valkeinen
Co-developed-by: Jyri Sarha
Signed-off-by: Jyri Sarha
Signed-off-by: Quentin Schulz
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig|2 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/cadence/Kconfig| 11 +
drivers/gpu/drm/bridge/cadence/Makefile |3 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 2522 +
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 399 +++
6 files changed, 2938 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63..ef91646441b1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -241,6 +241,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
+source "drivers/gpu/drm/bridge/cadence/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1..2b3aff104e46 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -25,4 +25,5 @@ obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
obj-y += analogix/
+obj-y += cadence/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
new file mode 100644
index ..f49d77eb7814
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_CDNS_MHDP8546
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+ It takes a DPI stream as input and outputs it encoded
+ in DP format.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
new file mode 100644
index ..676739cdf5e6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
+cdns-mhdp8546-y := cdns-mhdp8546-core.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
new file mode 100644
index ..7b1bd5d10923
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -0,0 +1,2522 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence MHDP8546 DP bridge driver.
+ *
+ * Copyright (C) 2020 Cadence Design Systems, Inc.
+ *
+ * Authors: Quentin Schulz
+ * Swapnil Jakhade
+ * Yuti Amonkar
+ * Tomi Valkeinen
+ * Jyri Sarha
+ *
+ * TODO:
+ * - Implement optimized mailbox communication using mailbox interrupts
+ * - Add support for power management
+ * - Add support for features like audio, MST and fast link training
+ * - Implement request_fw_cancel to handle HW_STATE
+ * - Fix asynchronous loading of firmware implementation
+ * - Add DRM helper function for cdns_mhdp_lower_link_rate
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "cdns-mhdp8546-core.h"
+
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
+{
+ int ret, empty;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(mhdp->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret =
[PATCH v17 0/2] Add initial support for slimport anx7625
Hi all, The following series add support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the v17 version, any mistakes, please let me know, I will fix it in the next series. Change history: v17: Fix comments from Dan - Fix possible memory leak of 'edid' v16: Fix compile error - Fix compiling error of incompitible interface of ".mode_valid()" v15: Fix comments from Sam and Hsin-Yi Wang - Remove connector - Allocate memory for edid at ".get_edid()" v14: Fix comments from Sam and Nicolas - Check flags at drm_bridge_attach - Use panel_bridge instead of drm_panel - Fix not correct return value v13: Fix comments from Launrent Pinchart and Rob Herring - Picked up Rob's Reviewed-By - Add .detect and .get_edid interface in bridge funcs. v12: Fix comments from Hsin-Yi Wang - Rebase the code on kernel 5.7, fix DRM interface not match issue. v11: Fix comments from Rob Herring - Update commit message. - Remove unused label. v10: Fix comments from Rob Herring, Daniel. - Fix dt_binding_check warning. - Update description. v9: Fix comments from Sam, Nicolas, Daniel - Remove extcon interface. - Remove DPI support. - Fix dt_binding_check complains. - Code clean up and update description. v8: Fix comments from Nicolas. - Fix several coding format. - Update description. v7: - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP .../bindings/display/bridge/analogix,anx7625.yaml | 95 + drivers/gpu/drm/bridge/analogix/Kconfig|9 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 1850 drivers/gpu/drm/bridge/analogix/anx7625.h | 390 + 5 files changed, 2345 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO
The HVS FIFOs are currently assigned each time we have an atomic_check
for all the enabled CRTCs.
However, if we are running multiple outputs in parallel and we happen to
disable the first (by index) CRTC, we end up changing the assigned FIFO
of the second CRTC without disabling and reenabling the pixelvalve which
ends up in a stall and eventually a VBLANK timeout.
In order to fix this, we can create a special value for our assigned
channel to mark it as disabled, and if our CRTC already had an assigned
channel in its previous state, we keep on using it.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 ++---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_kms.c | 21 +++--
3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a393f93390a2..be754120faa8 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -852,11 +852,18 @@ void vc4_crtc_destroy_state(struct drm_crtc *crtc,
void vc4_crtc_reset(struct drm_crtc *crtc)
{
+ struct vc4_crtc_state *vc4_crtc_state;
+
if (crtc->state)
vc4_crtc_destroy_state(crtc, crtc->state);
- crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
- if (crtc->state)
- __drm_atomic_helper_crtc_reset(crtc, crtc->state);
+
+ vc4_crtc_state = kzalloc(sizeof(*vc4_crtc_state), GFP_KERNEL);
+ if (!vc4_crtc_state)
+ return;
+
+ vc4_crtc_state->assigned_channel = VC4_HVS_CHANNEL_DISABLED;
+ crtc->state = _crtc_state->base;
+ __drm_atomic_helper_crtc_reset(crtc, crtc->state);
}
static const struct drm_crtc_funcs vc4_crtc_funcs = {
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 8c8d96b6289f..2b13f2126f13 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -531,6 +531,7 @@ struct vc4_crtc_state {
unsigned int bottom;
} margins;
};
+#define VC4_HVS_CHANNEL_DISABLED ((unsigned int) -1)
static inline struct vc4_crtc_state *
to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 01fa60844695..f452dad50c22 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -616,7 +616,7 @@ static int
vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
{
unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
- struct drm_crtc_state *crtc_state;
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc *crtc;
int i, ret;
@@ -629,6 +629,7 @@ vc4_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
* modified.
*/
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+ struct drm_crtc_state *crtc_state;
if (!crtc->state->enable)
continue;
@@ -637,15 +638,23 @@ vc4_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return PTR_ERR(crtc_state);
}
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- struct vc4_crtc_state *vc4_crtc_state =
- to_vc4_crtc_state(crtc_state);
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ struct vc4_crtc_state *new_vc4_crtc_state =
+ to_vc4_crtc_state(new_crtc_state);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
unsigned int matching_channels;
- if (!crtc_state->enable)
+ if (old_crtc_state->enable && !new_crtc_state->enable)
+ new_vc4_crtc_state->assigned_channel =
VC4_HVS_CHANNEL_DISABLED;
+
+ if (!new_crtc_state->enable)
continue;
+ if (new_vc4_crtc_state->assigned_channel !=
VC4_HVS_CHANNEL_DISABLED) {
+ unassigned_channels &=
~BIT(new_vc4_crtc_state->assigned_channel);
+ continue;
+ }
+
/*
* The problem we have to solve here is that we have
* up to 7 encoders, connected to up to 6 CRTCs.
@@ -674,7 +683,7 @@ vc4_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
if (matching_channels) {
unsigned int channel = ffs(matching_channels) - 1;
- vc4_crtc_state->assigned_channel = channel;
+ new_vc4_crtc_state->assigned_channel = channel;
unassigned_channels &= ~BIT(channel);
} else {
return -EINVAL;
--
2.26.2
[PATCH -next v2] drm/msm/dpu: Convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
---
v2: based on linux-next(20200917), and can be applied to
mainline cleanly now.
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 15 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 29 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 17 ++--
4 files changed, 8 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index f1bc6a1af..84ea09d96 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -288,19 +288,6 @@ static void dpu_disable_all_irqs(struct dpu_kms *dpu_kms)
}
#ifdef CONFIG_DEBUG_FS
-#define DEFINE_DPU_DEBUGFS_SEQ_FOPS(__prefix) \
-static int __prefix ## _open(struct inode *inode, struct file *file) \
-{ \
- return single_open(file, __prefix ## _show, inode->i_private); \
-} \
-static const struct file_operations __prefix ## _fops = { \
- .owner = THIS_MODULE, \
- .open = __prefix ## _open, \
- .release = single_release, \
- .read = seq_read, \
- .llseek = seq_lseek,\
-}
-
static int dpu_debugfs_core_irq_show(struct seq_file *s, void *v)
{
struct dpu_irq *irq_obj = s->private;
@@ -328,7 +315,7 @@ static int dpu_debugfs_core_irq_show(struct seq_file *s,
void *v)
return 0;
}
-DEFINE_DPU_DEBUGFS_SEQ_FOPS(dpu_debugfs_core_irq);
+DEFINE_SHOW_ATTRIBUTE(dpu_debugfs_core_irq);
void dpu_debugfs_core_irq_init(struct dpu_kms *dpu_kms,
struct dentry *parent)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 6169148b3..f56414a06 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1177,23 +1177,7 @@ static int _dpu_debugfs_status_show(struct seq_file *s,
void *data)
return 0;
}
-static int _dpu_debugfs_status_open(struct inode *inode, struct file *file)
-{
- return single_open(file, _dpu_debugfs_status_show, inode->i_private);
-}
-
-#define DEFINE_DPU_DEBUGFS_SEQ_FOPS(__prefix) \
-static int __prefix ## _open(struct inode *inode, struct file *file) \
-{ \
- return single_open(file, __prefix ## _show, inode->i_private); \
-} \
-static const struct file_operations __prefix ## _fops = { \
- .owner = THIS_MODULE, \
- .open = __prefix ## _open, \
- .release = single_release, \
- .read = seq_read, \
- .llseek = seq_lseek,\
-}
+DEFINE_SHOW_ATTRIBUTE(_dpu_debugfs_status);
static int dpu_crtc_debugfs_state_show(struct seq_file *s, void *v)
{
@@ -1210,25 +1194,18 @@ static int dpu_crtc_debugfs_state_show(struct seq_file
*s, void *v)
return 0;
}
-DEFINE_DPU_DEBUGFS_SEQ_FOPS(dpu_crtc_debugfs_state);
+DEFINE_SHOW_ATTRIBUTE(dpu_crtc_debugfs_state);
static int _dpu_crtc_init_debugfs(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
- static const struct file_operations debugfs_status_fops = {
- .open = _dpu_debugfs_status_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- };
-
dpu_crtc->debugfs_root = debugfs_create_dir(dpu_crtc->name,
crtc->dev->primary->debugfs_root);
debugfs_create_file("status", 0400,
dpu_crtc->debugfs_root,
- dpu_crtc, _status_fops);
+ dpu_crtc, &_dpu_debugfs_status_fops);
debugfs_create_file("state", 0600,
dpu_crtc->debugfs_root,
_crtc->base,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index bd6def436..da192e275 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1880,24 +1880,13 @@ static int _dpu_encoder_status_show(struct seq_file *s,
void *data)
return 0;
}
-static int _dpu_encoder_debugfs_status_open(struct inode
[PATCH v11 0/3] drm: Add support for Cadence MHDP8546 DPI/DP bridge and J721E wrapper.
This patch series adds new DRM bridge driver for Cadence MHDP8546 DPI/DP bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High Definition Link, High-Definition Multimedia Interface, Display Port). Cadence Display Port complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards. The MHDP bridge driver currently implements Single Stream Transport (SST) mode. It also adds Texas Instruments j721e SoC specific wrapper and adds the device tree bindings in YAML format. Some of the features that will be added later on include (but are not limited to): - Power Management (PM) support: We will implement the PM functions in next stage once there will be a stable driver in upstream - Audio and MST support The patch series has three patches in the below sequence: 1. 0001-dt-bindings-drm-bridge-Document-Cadence-MHDP8546.patch Documents the bindings in yaml format. 2. 0002-drm-bridge-Add-support-for-Cadence-MHDP8546-DPI-.patch This patch adds new DRM bridge driver for Cadence MHDP Display Port. The patch implements support for single stream transport mode. 3. 0003-drm-bridge-cdns-mhdp8546-Add-TI-J721E-wrapper.patch Adds Texas Instruments (TI) j721e wrapper for MHDP. The wrapper configures MHDP clocks and muxes as required by SoC. This patch series is dependent on PHY patch series [1] to add new PHY attribute max_link_rate and to set attributes in Cadence Torrent PHY driver. Please pull tag phy-attrs-5.10 for phy tree. [1] https://lkml.org/lkml/2020/9/11/54 Version History: v11: In 1/3 - Add phy-names, power-domains and interrupts properties. In 2/3 - No change In 3/3 - No change v10: In 1/3 - No change In 2/3 - Simplify TU, VS calculations with fixed TU size of 64. - Shift TU, VS calculations to atomic_enable() and remove cdns_mhdp_validate_mode_params() function. - Add bandwidth check in atomic_enable() before enabling mode. - Read PHY attributes manually without using API. - Fix other minor comments and issues for v9 patches. - Add Reviewed-by: Laurent Pinchart In 3/3 - No change v9: In 1/3 - Rename bindings file to cdns,mhdp8546.yaml. - Minor changes replacing mhdp with mhdp8546 to include IP part number. - Add 4 input ports and one output port supporting MST for DP bridge. In 2/3 - Add driver files in cadence folder under drm/bridge. - Rename driver files to include part number mhdp8546. - Remove link training calls from atomic_check. - Support DRM_BRIDGE_OP_HPD with hpd_enable, hpd_disable callbacks. - Remove unnecessary fw states. - Fix other review comments for v8 patches. In 3/3 - Add input_bus_flags specific for J721E in drm_bridge_timings. - Fix other review comments for v8 patches. v8: In 1/3 - Fix error reported by dt_binding_check - Fix indent in the example - Fix other comments given for v7 patches. In 2/3: - Implement bridge connector operations .get_edid() and .detect(). - Make connector creation optional based on DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. - Fix other comments given for v7 patches. In 3/3 - Fix comments given for v7 patches. v7: In 1/3 - No change In 2/3 - Switch to atomic versions of bridge operations - Implement atomic_check() handler to perform all validation checks - Add struct cdns_mhdp_bridge_state with subclassed bridge state - Use PHY API[1] to get PHY attributes instead of reading from PHY DT node - Updated HPD handling and link configuration in IRQ handler - Add "link_mutex" protecting the access to all the link parameters - Add support to check and print FW version information - Add separate function to initialize host parameters to simplify probe - Use waitqueue instead of manual loop in cdns_mhdp_remove - Add forward declarations and header files in cdns-mhdp-core.h file - Use bool instead of single bit values in struct cdns_mhdp_device - Fix for other minor comments given for v6 patches In 3/3 - Use of_device_is_compatible() to set compatible string specific values - Move mhdp_ti_j721e_ops structure to cdns-mhdp-j721e.c - Remove duplicate Copyright message - Remove CONFIG_DRM_CDNS_MHDP_J721E check - Add Reviewed-by: Laurent Pinchart v6: - Added minor fixes in YAML file. - Added Reviewed-by: Laurent Pinchart to the YAML patch. - Removed all the FIXME comments which are invalid in drm driver. - Reduced the mailbox timeout from 5s to 2s. - Added Reviewed-by: Tomi Valkeinen to the 003-drm-mhdp-add-j721e-wrapper patch. - Added Signed-off all the module authors. - Fixed the compiler error Reported-by: kbuild test robot . v5: - Added Signed-off-by: Jyri Sarha tag to the code patches. v4: - Added SPDX dual license tag to YAML bindings. - Corrected indentation of the child node properties. - Removed the maxItems in the conditional statement. - Add Reviewed-by: Rob Herring tag to the Document Cadence MHDP bridge bindings patch. - Renamed the DRM driver executable name from mhdp8546 to cdns-mhdp in Makefile. - Renamed the DRM driver and header file from cdns-mhdp to cdns-mhdp-core. v3: - Added if /
RE: [PATCH v10 1/3] dt-bindings: drm/bridge: Document Cadence MHDP8546 bridge bindings
Hi Tomi, > -Original Message- > From: Tomi Valkeinen > Sent: Wednesday, September 16, 2020 5:48 PM > To: Swapnil Kashinath Jakhade ; airl...@linux.ie; > dan...@ffwll.ch; laurent.pinch...@ideasonboard.com; robh...@kernel.org; > a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se; > jernej.skra...@siol.net; dri-devel@lists.freedesktop.org; > devicet...@vger.kernel.org; linux-ker...@vger.kernel.org > Cc: Milind Parab ; Yuti Suresh Amonkar > ; jsa...@ti.com; nsek...@ti.com; > prane...@ti.com; nikhil...@ti.com > Subject: Re: [PATCH v10 1/3] dt-bindings: drm/bridge: Document Cadence > MHDP8546 bridge bindings > > EXTERNAL MAIL > > > Hi Swapnil, Yuti, > > On 14/09/2020 15:48, Swapnil Jakhade wrote: > > From: Yuti Amonkar > > > > Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in > > yaml format. > > > > Signed-off-by: Yuti Amonkar > > Signed-off-by: Swapnil Jakhade > > Reviewed-by: Rob Herring > > Reviewed-by: Laurent Pinchart > > --- > > .../display/bridge/cdns,mhdp8546.yaml | 154 ++ > > 1 file changed, 154 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > I was testing this on J7 EVM, and looking at the dts files and DT bindings. To > get rid of the warnings from dtbs_check, I made the following changes. > > I think the interrupt one is clear. The driver needs the interrupt, but it was > not defined in the yaml file. > > For phy-names, we had that in the out-of-tree dts file, so I added it here. > The > driver just looks for the PHY via index, but I guess we should require it. > > The power-domain is not needed by the driver, but if I'm not mistaken, has > to be defined here. > > > diff --git > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > index a21a4bfe15cf..c5f5781c1ed6 100644 > --- > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > +++ > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yam > +++ l > @@ -46,6 +46,16 @@ properties: > description: >phandle to the DisplayPort PHY. > > + phy-names: > +items: > + - const: dpphy > + > + power-domains: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + >ports: > type: object > description: > @@ -114,6 +124,8 @@ required: >- reg >- reg-names >- phys > + - phy-names > + - interrupts >- ports > Okay. We will update the bindings as per above suggestions. Thanks for your inputs. Thanks & regards, Swapnil > additionalProperties: false > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
Apologies once again, some of my emails were bouncing for some addresses yesterday. Hopefully it was a temporary condition; I'll continue trying to dig into it on my end if it happens again for this email. Since there's evidence that some models want lsb and some (well, at least one) want msb, my understanding is that we'll need a quirk one way or the other (please correct if I'm mistaken). I unfortunately don't have the ability to test anything other than the Pixelbook, so if we decide the msb is the "right" way, then I will have to rely on others to test (and find the OUI of) other models which require lsb. I am happy to make any changes requested, but I do not at all have enough background here to make the decision on whether the msb functionality deserves the quirk or if the lsb one does. How can I help you all come to an agreement here? * It seems like Ville feels strongly about the msb being the correct interpretation of the spec. * It's unclear to me on which side of the fence Lyude falls, I couldn't pick up a strong opinion in her clarifying question. * Puthikorn seems to be on the side of lsb being correct, but maybe was swayed by Ville's argument. If no one feels that Ville's argument is not strong in some way, and we go with that, I will get to work on the requested changes. I am concerned, though, about changing the default functionality without testing it widely to find the set of laptops which require the lsb quirk. I'd appreciate any advice people might have about making this change safely. Thank you for your time, Kevin On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä wrote: > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote: > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote: > > > The Lyude fde7266fb2f6 change is actually based on Chromium change > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung > > > Galaxy Chromebook. So currently we have 2 examples that use LSB > > > interpretation and 1 that use MSB. > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit > > is cleared to 0, only the 8 MSB of the brightness control value can be > > controlled. > > (See Note below.) > > Assigned bits are allocated to the MSB of the enabled register > > combination." > > > > I think that's pretty clear the assigned bits are supposed to be > > msb aligned. > > I guess there's some email issues happening, but just to clarify: > > When the spec says MSB in caps here it clearly means > "most significant-bit(s)" since otherwise "8 MSB" would not make > any sense in the context of a 2 byte value. > > Granted the spec is crap here since "Table 1-1: Acronyms and > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s). > > Also I can't imagine anyone would allocate the bits starting > from the lsb when the whole thing is clearly supposed to be a > 16bit big endian integer. So with >8 assigned bits you'd end > up with crazy stuff like this: > > [ 7 ... 0 ][7 ... 0] > [ 8 MSB ][][N LSB] > > so you couldn't even treat the value as a regular big endian > thing. Instead, if you squint a bit, it now looks like a funky > little endian value. So we're deep into some mixed endian land > where nothing makes sense anymore. > > Anyways I think the code should simply do this to match the spec: > u16 value = brightness << (16 - num_assigned_bits); > val[0] = value >> 8; > val[1] = value & 0xff; > > > > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski > > > wrote: > > > > > > > > Apologies for being too vague. To be as precise I can be, here is the > > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer > > > > your other question, the code I tested against is indeed including the > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit > > > > message): our current top-of-tree for our 5.4 branch includes the > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change > > > > is exactly the change which breaks my Pixelbook model: prior to the > > > > change, the max_brightness was hard-coded to 0x and the math > > > > worked out that it didn't matter that the hardware cared about the MSB > > > > despite the driver code caring about the LSB. > > > > > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I > > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we > > > > need a quirk at least for some laptop. Reading through the copy of the > > > > datasheet I have, it wasn't clear to me which was the correct > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current > > > > kernel code (caring about LSB) being the correct interpretation. I > > > > believe we have other chromebooks which do rely on LSB functionality, > > > > so unless we can find
[PATCH -next] gpu: gma500: Remove set but not used variable
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/mmu.c: In function psb_mmu_insert_pfn_sequence:
drivers/gpu/drm/gma500/mmu.c:660:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function get_clock:
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable ‘tmp’ set
but not used [-Wunused-but-set-variable]
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function get_data:
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable ‘tmp’ set
but not used [-Wunused-but-set-variable]
these variable is never used, so remove it or check it's return value.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/gma500/mmu.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
index 505044c9a673..6ce842d05a44 100644
--- a/drivers/gpu/drm/gma500/mmu.c
+++ b/drivers/gpu/drm/gma500/mmu.c
@@ -690,7 +690,7 @@ int psb_mmu_insert_pfn_sequence(struct psb_mmu_pd *pd,
uint32_t start_pfn,
if (pd->hw_context != -1)
psb_mmu_flush(pd->driver);
- return 0;
+ return ret;
}
int psb_mmu_insert_pages(struct psb_mmu_pd *pd, struct page **pages,
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
index baaf8212e01d..4d660868d76f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
@@ -66,12 +66,12 @@
static int get_clock(void *data)
{
struct psb_intel_i2c_chan *chan = data;
- u32 val, tmp;
+ u32 val;
val = LPC_READ_REG(chan, RGIO);
val |= GPIO_CLOCK;
LPC_WRITE_REG(chan, RGIO, val);
- tmp = LPC_READ_REG(chan, RGLVL);
+ LPC_READ_REG(chan, RGLVL);
val = (LPC_READ_REG(chan, RGLVL) & GPIO_CLOCK) ? 1 : 0;
return val;
@@ -80,12 +80,12 @@ static int get_clock(void *data)
static int get_data(void *data)
{
struct psb_intel_i2c_chan *chan = data;
- u32 val, tmp;
+ u32 val;
val = LPC_READ_REG(chan, RGIO);
val |= GPIO_DATA;
LPC_WRITE_REG(chan, RGIO, val);
- tmp = LPC_READ_REG(chan, RGLVL);
+ LPC_READ_REG(chan, RGLVL);
val = (LPC_READ_REG(chan, RGLVL) & GPIO_DATA) ? 1 : 0;
return val;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 3/3] drm: bridge: cdns-mhdp8546: Add TI J721E wrapper
Add J721E wrapper for mhdp, which sets up the clock and data muxes.
Signed-off-by: Jyri Sarha
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/cadence/Kconfig| 13
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 10 +++
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 1 +
.../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 78 +++
.../drm/bridge/cadence/cdns-mhdp8546-j721e.h | 19 +
6 files changed, 122 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index f49d77eb7814..511d67b16d14 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -9,3 +9,16 @@ config DRM_CDNS_MHDP8546
bridge and is meant to be directly embedded in a SoC.
It takes a DPI stream as input and outputs it encoded
in DP format.
+
+if DRM_CDNS_MHDP8546
+
+config DRM_CDNS_MHDP8546_J721E
+ depends on ARCH_K3_J721E_SOC || COMPILE_TEST
+ bool "J721E Cadence DPI/DP wrapper support"
+ default y
+ help
+ Support J721E Cadence DPI/DP wrapper. This is a wrapper
+ which adds support for J721E related platform ops. It
+ initializes the J721E Display Port and sets up the
+ clock and data muxes.
+endif
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 676739cdf5e6..8f647991b374 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o
+cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 7b1bd5d10923..621ebdbff8a3 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -50,6 +50,8 @@
#include "cdns-mhdp8546-core.h"
+#include "cdns-mhdp8546-j721e.h"
+
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
int ret, empty;
@@ -2496,6 +2498,14 @@ static int cdns_mhdp_remove(struct platform_device *pdev)
static const struct of_device_id mhdp_ids[] = {
{ .compatible = "cdns,mhdp8546", },
+#ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
+ { .compatible = "ti,j721e-mhdp8546",
+ .data = &(const struct cdns_mhdp_platform_info) {
+ .timings = _ti_j721e_bridge_timings,
+ .ops = _ti_j721e_ops,
+ },
+ },
+#endif
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mhdp_ids);
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
index c0fff78d15be..5897a85e3159 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
@@ -341,6 +341,7 @@ struct cdns_mhdp_platform_info {
struct cdns_mhdp_device {
void __iomem *regs;
+ void __iomem *j721e_regs;
struct device *dev;
struct clk *clk;
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
new file mode 100644
index ..dfe1b59514f7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI j721e Cadence MHDP8546 DP wrapper
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Jyri Sarha
+ */
+
+#include
+#include
+
+#include "cdns-mhdp8546-j721e.h"
+
+#defineREVISION0x00
+#defineDPTX_IPCFG 0x04
+#defineECC_MEM_CFG 0x08
+#defineDPTX_DSC_CFG0x0c
+#defineDPTX_SRC_CFG0x10
+#defineDPTX_VIF_SECURE_MODE_CFG0x14
+#defineDPTX_VIF_CONN_STATUS0x18
+#definePHY_CLK_STATUS 0x1c
+
+#define DPTX_SRC_AIF_ENBIT(16)
+#define DPTX_SRC_VIF_3_IN30B BIT(11)
+#define DPTX_SRC_VIF_2_IN30B BIT(10)
+#define DPTX_SRC_VIF_1_IN30B BIT(9)
+#define DPTX_SRC_VIF_0_IN30B BIT(8)
+#define DPTX_SRC_VIF_3_SEL_DPI5BIT(7)
+#define DPTX_SRC_VIF_3_SEL_DPI30
+#define DPTX_SRC_VIF_2_SEL_DPI4BIT(6)
+#define DPTX_SRC_VIF_2_SEL_DPI20
+#define DPTX_SRC_VIF_1_SEL_DPI3BIT(5)
+#define DPTX_SRC_VIF_1_SEL_DPI1
[PATCH] drm: rcar-du: Fix LVDS dual link mode kernel crash
Kernel crash is observed when dual lvds link mode is activated
along with HDMI. For this use case DU0 drives dual lvds output
and DU1 drives hdmi output, but dot clock for DU1 is generated
from lvds1.
[ 585.890230] Unable to handle kernel paging request at virtual address
ff18
[ 585.898534] Mem abort info:
[ 586.065713] x1 : 0839b680 x0 : ff20
[ 586.071038] Call trace:
[ 586.073490] rcar_lvds_clk_enable+0x14/0xd0
[ 586.077682] rcar_du_crtc_atomic_enable+0xe4/0xe8
[ 586.082403] drm_atomic_helper_commit_modeset_enables+0x1f0/0x240
[ 586.088508] rcar_du_atomic_commit_tail+0xac/0xd8
[ 586.093224] commit_tail+0x9c/0x168
[ 586.096720] drm_atomic_helper_commit+0x180/0x198
[ 586.101435] drm_atomic_commit+0x48/0x58
[ 586.105370] drm_client_modeset_commit_atomic+0x250/0x2b0
[ 586.110780] drm_client_modeset_commit_locked+0x54/0x1e8
[ 586.116102] drm_client_modeset_commit+0x2c/0x50
[ 586.120733] __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0x120
[ 586.127013] drm_fb_helper_set_par+0x38/0x70
[ 586.131291] drm_fb_helper_hotplug_event.part.22+0xc4/0xd8
[ 586.136789] drm_fbdev_client_hotplug+0xcc/0x1d8
[ 586.141415] drm_client_dev_hotplug+0x7c/0xc0
[ 586.145781] drm_kms_helper_hotplug_event+0x30/0x40
[ 586.150670] tda998x_detect_work+0x14/0x28
[ 586.154781] process_one_work+0x2a8/0x730
Fixes: a6cc417d3eee ("drm: rcar-du: Turn LVDS clock output on/off for DPAD0
output on D3/E3")
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 --
drivers/gpu/drm/rcar-du/rcar_lvds.c| 6 ++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index fe86a3e67757..2440df786b02 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -729,11 +729,16 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
struct rcar_du_encoder *encoder =
rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
+ struct rcar_du_encoder *enc_dual_link =
+ rcdu->encoders[RCAR_DU_OUTPUT_LVDS0];
const struct drm_display_mode *mode =
>state->adjusted_mode;
struct drm_bridge *bridge;
- bridge = drm_bridge_chain_get_first_bridge(>base);
+ bridge =
drm_bridge_chain_get_first_bridge(_dual_link->base);
+ if (!rcar_lvds_dual_link(bridge))
+ bridge =
drm_bridge_chain_get_first_bridge(>base);
+
rcar_lvds_clk_enable(bridge, mode->clock * 1000);
}
@@ -761,13 +766,18 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
*crtc,
rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
struct rcar_du_encoder *encoder =
rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
+ struct rcar_du_encoder *enc_dual_link =
+ rcdu->encoders[RCAR_DU_OUTPUT_LVDS0];
struct drm_bridge *bridge;
/*
* Disable the LVDS clock output, see
* rcar_du_crtc_atomic_enable().
*/
- bridge = drm_bridge_chain_get_first_bridge(>base);
+ bridge =
drm_bridge_chain_get_first_bridge(_dual_link->base);
+ if (!rcar_lvds_dual_link(bridge))
+ bridge =
drm_bridge_chain_get_first_bridge(>base);
+
rcar_lvds_clk_disable(bridge);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index ab0d49618cf9..588f2a16b8a5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -373,6 +373,9 @@ int rcar_lvds_clk_enable(struct drm_bridge *bridge,
unsigned long freq)
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
int ret;
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
+ lvds = bridge_to_rcar_lvds(lvds->companion);
+
if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
return -ENODEV;
@@ -392,6 +395,9 @@ void rcar_lvds_clk_disable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
+ lvds = bridge_to_rcar_lvds(lvds->companion);
+
if (WARN_ON(!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)))
return;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active
The HVS has three FIFOs that can be assigned to a number of PixelValves
through a mux.
However, changing that FIFO requires that we disable and then enable the
pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not
just the active ones.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index af3ee3dcdab6..01fa60844695 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -643,7 +643,7 @@ vc4_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
unsigned int matching_channels;
- if (!crtc_state->active)
+ if (!crtc_state->enable)
continue;
/*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel, Dave, Here's this week drm-misc-next PR Maxime drm-misc-next-2020-09-18: drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: - virtio: Merged a PR for patches that will affect drm/virtio Core Changes: - atomic: Split out drm_atomic_helper_calc_timestamping_constants of drm_atomic_helper_update_legacy_modeset_state - ttm: More rework Driver Changes: - tree-wide: conversions to devm_drm_dev_alloc, - ast: simplifications of the atomic modesetting code - panfrost: multiple fixes - vc4: multiple fixes The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14: Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-09-18 for you to fetch changes up to 4856e5aa0ef1d4c62f6f30bf273a778735507837: drm/ttm: drop evicted from ttm_bo. (2020-09-18 06:23:38 +1000) drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: - virtio: Merged a PR for patches that will affect drm/virtio Core Changes: - atomic: Split out drm_atomic_helper_calc_timestamping_constants of drm_atomic_helper_update_legacy_modeset_state - ttm: More rework Driver Changes: - tree-wide: conversions to devm_drm_dev_alloc, - ast: simplifications of the atomic modesetting code - panfrost: multiple fixes - vc4: multiple fixes Alex Dewar (2): video: fbdev: sstfb: replace spurious snprintf() with sprintf() drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy Angelo Ribeiro (1): drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs Antonio Borneo (3): drm/bridge/synopsys: dsi: allow LP commands in video mode drm/bridge/synopsys: dsi: allow sending longer LP commands drm/bridge/synopsys: dsi: add support for non-continuous HS clock Bernard Zhao (1): gpu/drm: cleanup coding style a bit Bilal Wasim (1): docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option. Christian König (14): drm/ttm: make sure that we always zero init mem.bus v2 drm/nouveau: move io_reserve_lru handling into the driver v5 drm/ttm: remove io_reserve_lru handling v3 drm/qxl: don't touch mem.bus.offset drm/ttm: merge offset and base in ttm_bus_placement drm/vram-helper: stop using TTM placement flags drm/nouveau: stop using TTM placement flags drm/vmwgfx: stop setting multiple domain flags drm/ttm: nuke memory type flags drm/ttm: remove default caching drm/nouveau: explicitly specify caching to use drm/ttm: remove available_caching drm/ttm: some cleanups drm/ttm: remove superflous extern attribute from funcs Colin Ian King (2): video: fbdev: vga16fb: fix setting of pixclock because a pass-by-value error omapfb: fix spelling mistake "propert" -> "property" Dan Carpenter (2): drm/vc4: hdmi: Fix off by ones in vc4_hdmi_read/write() drm/vc4: hdmi: Fix NULL vs IS_ERR() checks in vc5_hdmi_init_resources() Daniel Vetter (8): drm/managed: Cleanup of unused functions and polishing docs drm/armada: Use devm_drm_dev_alloc drm/armada: Don't use drm_device->dev_private drm/aspeed: Use managed drmm_mode_config_cleanup drm/vgem: Use devm_drm_dev_alloc drm/vkms: Use devm_drm_dev_alloc drm/xlnx: Use devm_drm_dev_alloc dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv Dave Airlie (30): drm/ttm: remove bdev from ttm_tt drm/ttm: introduce ttm_bo_move_null drm/ttm: add optional bind/unbind via driver. drm/qxl: move bind/unbind/destroy to the driver function table. drm/ttm/agp: export bind/unbind/destroy for drivers to use. drm/radeon/ttm: move to driver binding/destroy functions. (v2) drm/nouveau/ttm: use driver bind/unbind/destroy functions. drm/vmwgfx: move to driver binding functions drm/amdgpu/ttm: move to driver backend binding funcs drm/gem_vram/ttm: move to driver backend destroy function. drm/ttm/agp: drop back end bindings from agp drm/ttm: get rid of agp specific populate/unpopulate paths. drm/ttm/agp: remove bdev from agp helpers drm/ttm: drop the tt backend function paths. drm/ttm/tt: add wrappers to set tt state. drm/ttm: wrap tt destroy. (v2) drm/ttm: tt destroy move null check to outer function. drm/ttm: split populate out from binding. drm/ttm: move ttm binding/unbinding out of ttm_tt paths. drm/ttm: split bound/populated flags. drm/ttm: move populated state into page flags drm/ttm: protect against reentrant bind in the drivers drm/ttm: flip tt destroy ordering. drm/ttm: move unbind into the tt destroy. drm/ttm/drivers: call the bind function directly. drm/ttm:
[PATCH] drm/ttm: update kernel-doc line comments
Update kernel-doc line comments to fix warnings reported by make W=1. drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or member 'glob' not described in 'ttm_shrink' drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or member 'from_wq' not described in 'ttm_shrink' drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or member 'extra' not described in 'ttm_shrink' drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or member 'ctx' not described in 'ttm_shrink' Signed-off-by: Tian Tao --- drivers/gpu/drm/ttm/ttm_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c index acd63b7..0b51773 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -259,7 +259,7 @@ static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob, return false; } -/** +/* * At this point we only support a single shrink callback. * Extend this if needed, perhaps using a linked list of callbacks. * Note that this function is reentrant: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
Signed-off-by: Xin Ji
Reported-by: kernel test robot
Reported-by: Dan Carpenter
---
drivers/gpu/drm/bridge/analogix/Kconfig |9 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 1850 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 390 ++
4 files changed, 2250 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e1fa7d8..024ea2a 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+ tristate "Analogix Anx7625 MIPI to DP interface support"
+ depends on DRM
+ depends on OF
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter
+ designed for portable devices. It converts MIPI/DPI to
+ DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 97669b3..44da392 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..65cc059
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1850 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = >dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = >dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = >dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_write(struct anx7625_data *ctx,
+struct i2c_client *client,
+u8 reg_addr, u8 reg_val)
+{
+ int ret;
+ struct device *dev = >dev;
+
+
[PATCH v17 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
anx7625: MIPI to DP transmitter DT schema
Signed-off-by: Xin Ji
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..60585a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description:
+ Video port for MIPI DSI input.
+
+ port@1:
+type: object
+description:
+ Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dmabuf: fix NULL pointer dereference in dma_buf_release()
NULL pointer dereference is observed while exporting the dmabuf but
failed to allocate the 'struct file' which results into the dropping of
the allocated dentry corresponding to this file in the dmabuf fs, which
is ending up in dma_buf_release() and accessing the uninitialzed
dentry->d_fsdata.
Call stack on 5.4 is below:
dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
__dentry_kill+0x294/0x31c fs/dcache.c:584
dentry_kill fs/dcache.c:673 [inline]
dput+0x250/0x380 fs/dcache.c:859
path_put+0x24/0x40 fs/namei.c:485
alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235
dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585
Fix this by checking for the valid pointer in the dentry->d_fsdata.
Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
Cc: [5.7+]
Signed-off-by: Charan Teja Reddy
---
drivers/dma-buf/dma-buf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82..844967f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -59,6 +59,8 @@ static void dma_buf_release(struct dentry *dentry)
struct dma_buf *dmabuf;
dmabuf = dentry->d_fsdata;
+ if (unlikely(!dmabuf))
+ return;
BUG_ON(dmabuf->vmapping_counter);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
I'll defer to Ville & Lyude. I dug up more on the bug report and found that both Thinkpad and Galaxy Chromebook use the same Samsung OLED. So my 2 vs 1 argument is actually not valid. On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski wrote: > > Apologies once again, some of my emails were bouncing for some > addresses yesterday. Hopefully it was a temporary condition; I'll > continue trying to dig into it on my end if it happens again for this > email. > > Since there's evidence that some models want lsb and some (well, at > least one) want msb, my understanding is that we'll need a quirk one > way or the other (please correct if I'm mistaken). I unfortunately > don't have the ability to test anything other than the Pixelbook, so > if we decide the msb is the "right" way, then I will have to rely on > others to test (and find the OUI of) other models which require lsb. > > I am happy to make any changes requested, but I do not at all have > enough background here to make the decision on whether the msb > functionality deserves the quirk or if the lsb one does. How can I > help you all come to an agreement here? > > * It seems like Ville feels strongly about the msb being the correct > interpretation of the spec. > * It's unclear to me on which side of the fence Lyude falls, I > couldn't pick up a strong opinion in her clarifying question. > * Puthikorn seems to be on the side of lsb being correct, but maybe > was swayed by Ville's argument. > > If no one feels that Ville's argument is not strong in some way, and > we go with that, I will get to work on the requested changes. I am > concerned, though, about changing the default functionality without > testing it widely to find the set of laptops which require the lsb > quirk. I'd appreciate any advice people might have about making this > change safely. > > Thank you for your time, > Kevin > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä > wrote: > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote: > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote: > > > > The Lyude fde7266fb2f6 change is actually based on Chromium change > > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB > > > > interpretation and 1 that use MSB. > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit > > > is cleared to 0, only the 8 MSB of the brightness control value can be > > > controlled. > > > (See Note below.) > > > Assigned bits are allocated to the MSB of the enabled register > > > combination." > > > > > > I think that's pretty clear the assigned bits are supposed to be > > > msb aligned. > > > > I guess there's some email issues happening, but just to clarify: > > > > When the spec says MSB in caps here it clearly means > > "most significant-bit(s)" since otherwise "8 MSB" would not make > > any sense in the context of a 2 byte value. > > > > Granted the spec is crap here since "Table 1-1: Acronyms and > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s). > > > > Also I can't imagine anyone would allocate the bits starting > > from the lsb when the whole thing is clearly supposed to be a > > 16bit big endian integer. So with >8 assigned bits you'd end > > up with crazy stuff like this: > > > > [ 7 ... 0 ][7 ... 0] > > [ 8 MSB ][][N LSB] > > > > so you couldn't even treat the value as a regular big endian > > thing. Instead, if you squint a bit, it now looks like a funky > > little endian value. So we're deep into some mixed endian land > > where nothing makes sense anymore. > > > > Anyways I think the code should simply do this to match the spec: > > u16 value = brightness << (16 - num_assigned_bits); > > val[0] = value >> 8; > > val[1] = value & 0xff; > > > > > > > > > > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski > > > > wrote: > > > > > > > > > > Apologies for being too vague. To be as precise I can be, here is the > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer > > > > > your other question, the code I tested against is indeed including the > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit > > > > > message): our current top-of-tree for our 5.4 branch includes the > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change > > > > > is exactly the change which breaks my Pixelbook model: prior to the > > > > > change, the max_brightness was hard-coded to 0x and the math > > > > > worked out that it didn't matter that the hardware cared about the MSB > > > > > despite the driver code caring about the LSB. > > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I > > > > > dug up) and breaks another
Re: [PATCH] drm: fsl-dcu: enable PIXCLK on LS1021A
On Fri, 2020-08-21 at 15:41 +0200, Stefan Agner wrote:
> Hi Matthias,
>
> On 2020-08-20 12:58, Matthias Schiffer wrote:
> > The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A,
> > or the access will hang.
>
> Hm, this seems a rather ad-hoc access to SCFG from the DCU. We do
> support a pixel clock in the device tree bindings of fsl-dcu, so ideally
> we should enable the pixel clock through the clock framework.
>
> On the other hand, I guess that would mean adding a clock driver to flip
> a single bit, which seems a bit excessive too.
>
> I'd like a second opinion on that. Adding clk framework maintainers.
>
> --
> Stefan
How do we proceed with this patch?
Kind regards,
Matthias
>
> >
> > Signed-off-by: Matthias Schiffer
> > ---
> > drivers/gpu/drm/fsl-dcu/Kconfig | 1 +
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 3 +++
> > 3 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
> > b/drivers/gpu/drm/fsl-dcu/Kconfig
> > index d7dd8ba90e3a..9e5a35e7c00c 100644
> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> > @@ -8,6 +8,7 @@ config DRM_FSL_DCU
> > select DRM_PANEL
> > select REGMAP_MMIO
> > select VIDEOMODE_HELPERS
> > + select MFD_SYSCON if SOC_LS1021A
> > help
> > Choose this option if you have an Freescale DCU chipset.
> > If M is selected the module will be called fsl-dcu-drm.
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > index abbc1ddbf27f..8a7556655581 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > @@ -51,6 +51,23 @@ static const struct regmap_config fsl_dcu_regmap_config
> > = {
> > .volatile_reg = fsl_dcu_drm_is_volatile_reg,
> > };
> >
> > +static int fsl_dcu_scfg_config_ls1021a(struct device_node *np)
> > +{
> > + struct regmap *scfg;
> > +
> > + scfg = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
> > + if (IS_ERR(scfg))
> > + return PTR_ERR(scfg);
> > +
> > + /*
> > +* For simplicity, enable the PIXCLK unconditionally. It might
> > +* be possible to disable the clock in PM or on unload as a future
> > +* improvement.
> > +*/
> > + return regmap_update_bits(scfg, SCFG_PIXCLKCR, SCFG_PIXCLKCR_PXCEN,
> > + SCFG_PIXCLKCR_PXCEN);
> > +}
> > +
> > static void fsl_dcu_irq_uninstall(struct drm_device *dev)
> > {
> > struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > @@ -70,6 +87,14 @@ static int fsl_dcu_load(struct drm_device *dev,
> > unsigned long flags)
> > return ret;
> > }
> >
> > + if (of_device_is_compatible(fsl_dev->np, "fsl,ls1021a-dcu")) {
> > + ret = fsl_dcu_scfg_config_ls1021a(fsl_dev->np);
> > + if (ret < 0) {
> > + dev_err(dev->dev, "failed to enable pixclk\n");
> > + goto done;
> > + }
> > + }
> > +
> > ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
> > if (ret < 0) {
> > dev_err(dev->dev, "failed to initialize vblank\n");
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > index e2049a0e8a92..566396013c04 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > @@ -160,6 +160,9 @@
> > #define FSL_DCU_ARGB 12
> > #define FSL_DCU_YUV422 14
> >
> > +#define SCFG_PIXCLKCR 0x28
> > +#define SCFG_PIXCLKCR_PXCENBIT(31)
> > +
> > #define VF610_LAYER_REG_NUM9
> > #define LS1021A_LAYER_REG_NUM 10
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: fix initialization sequence
Am Freitag, 18. September 2020, 13:46:53 CEST schrieb Yannick Fertre:
> The current driver calls drm_bridge_add(), to add the dsi bridge
> to the global bridge list, in dw_mipi_dsi_host_attach().
> Thus, it relies on the probing of panel or bridge sub-nodes to
> trigger the execution of dsi host attach() that will, in turn,
> call dw_mipi_dsi_host_attach().
> This causes an incomplete driver initialization if the panel or
> the next bridge is not present as sub-node, e.g. because it is an
> i2c device, thus sub-node of the respective i2c controller.
Actually the drm_of_find_panel_or_bridge() works on of-graph nodes,
so having an remote-port pointing to the i2c/spi/whatever driver
should just work - and no need for the driver to be a subnode itself.
And while my memory is fuzzy, I think I remember Andrzej requesting
only registering the bridge once we know something is connected,
aka when it calls dsi_attach.
Heiko
>
> Move the relevant code from host attach() to probe(), and the
> corresponding code from detach() to remove().
>
> Signed-off-by: Antonio Borneo
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 73 ---
> 1 file changed, 48 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 6b268f9445b3..aa74abddc79f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -314,9 +314,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
> *host,
> {
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> - struct drm_bridge *bridge;
> - struct drm_panel *panel;
> - int ret;
> + int ret = -ENODEV;
>
> if (device->lanes > dsi->plat_data->max_data_lanes) {
> dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
> @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
> *host,
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
>
> - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> - , );
> - if (ret)
> - return ret;
> -
> - if (panel) {
> - bridge = drm_panel_bridge_add_typed(panel,
> - DRM_MODE_CONNECTOR_DSI);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> - }
> -
> - dsi->panel_bridge = bridge;
> -
> - drm_bridge_add(>bridge);
> -
> if (pdata->host_ops && pdata->host_ops->attach) {
> ret = pdata->host_ops->attach(pdata->priv_data, device);
> if (ret < 0)
> @@ -367,10 +349,6 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
> *host,
> return ret;
> }
>
> - drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
> -
> - drm_bridge_remove(>bridge);
> -
> return 0;
> }
>
> @@ -1105,6 +1083,9 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> struct device *dev = >dev;
> struct reset_control *apb_rst;
> struct dw_mipi_dsi *dsi;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> + int i, nb_endpoints;
> int ret;
>
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> @@ -1172,8 +1153,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> ret = mipi_dsi_host_register(>dsi_host);
> if (ret) {
> dev_err(dev, "Failed to register MIPI host: %d\n", ret);
> - dw_mipi_dsi_debugfs_remove(dsi);
> - return ERR_PTR(ret);
> + goto err_pmr_enable;
> }
>
> dsi->bridge.driver_private = dsi;
> @@ -1182,11 +1162,54 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
>
> + /* Get number of endpoints */
> + nb_endpoints = of_graph_get_endpoint_count(pdev->dev.of_node);
> + if (!nb_endpoints) {
> + ret = -ENODEV;
> + goto err_host_reg;
> + }
> +
> + for (i = 1; i < nb_endpoints; i++) {
> + ret = drm_of_find_panel_or_bridge(pdev->dev.of_node, i, 0,
> + , );
> + if (!ret)
> + break;
> + else if (ret == -EPROBE_DEFER)
> + goto err_host_reg;
> + }
> +
> + /* check if an error is returned >> no panel or bridge detected */
> + if (ret)
> + goto err_host_reg;
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add_typed(panel,
> DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto err_host_reg;
> + }
> + }
> +
> + dsi->panel_bridge = bridge;
> +
> +
[PATCH -next] gpu: nouveau: Remove set but not used variable
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_mstm_cleanup:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1303:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_mstm_prepare:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1327:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_svm.c: In function nouveau_pfns_map:
drivers/gpu/drm/nouveau/nouveau_svm.c:818:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
these variable is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 +++--
drivers/gpu/drm/nouveau/nouveau_svm.c | 3 +--
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1ed242070001..7cb5618e4592 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1306,12 +1306,10 @@ nv50_mstm_cleanup(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
- ret = drm_dp_check_act_status(>mgr);
-
- ret = drm_dp_update_payload_part2(>mgr);
+ drm_dp_check_act_status(>mgr);
+ drm_dp_update_payload_part2(>mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
@@ -1330,10 +1328,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
- ret = drm_dp_update_payload_part1(>mgr);
+ drm_dp_update_payload_part1(>mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 2df1c0460559..01583e9954a2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -815,7 +815,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
unsigned long addr, u64 *pfns, unsigned long npages)
{
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
- int ret;
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
@@ -823,7 +822,7 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
mutex_lock(>mutex);
svmm->vmm->vmm.object.client->super = true;
- ret = nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
+ nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
npages * sizeof(args->p.phys[0]), NULL);
svmm->vmm->vmm.object.client->super = false;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(_list_lock);
list_add(>list, _list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] dma-heap: Add a system-uncached heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)
Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
-
https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
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 on sh reported-by: kernel test robot
* Rework to use for_each_sgtable_sg(), dma_map_sgtable(), and
for_each_sg_page() along with numerous other cleanups suggested
by Robin Murphy
v3:
* Clarified commit message to address questions from last submission
---
drivers/dma-buf/heaps/Kconfig| 10 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_uncached_heap.c | 371 +++
3 files changed, 382 insertions(+)
create mode 100644 drivers/dma-buf/heaps/system_uncached_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..420b0ed0a512 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -5,6 +5,16 @@ config DMABUF_HEAPS_SYSTEM
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.
+config DMABUF_HEAPS_SYSTEM_UNCACHED
+ bool "DMA-BUF Uncached System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the uncached system dmabuf heap. This
+ heap is backed by pages from the buddy allocator, but pages are setup
+ for write combining. This avoids cache management overhead, and can
+ be faster if pages are mostly untouched by the cpu. If in doubt,
+ say Y.
+
config DMABUF_HEAPS_CMA
bool "DMA-BUF CMA Heap"
depends on DMABUF_HEAPS && DMA_CMA
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..085685ec478f 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM_UNCACHED) += system_uncached_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/system_uncached_heap.c
b/drivers/dma-buf/heaps/system_uncached_heap.c
new file mode 100644
index ..3b8e699bcae7
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_uncached_heap.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Uncached System DMA-Heap exporter
+ *
+ * Copyright (C) 2020 Linaro Ltd.
+ *
+ * Based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct uncached_heap {
+ struct dma_heap *heap;
+};
+
+struct uncached_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static struct sg_table
