Re: [PATCH v2 03/10] input: keyboard: gpio_keys: convert platform driver to use dev_groups
On Wed, Jul 31, 2019 at 02:43:42PM +0200, Greg Kroah-Hartman wrote:
> Platform drivers now have the option to have the platform core create
> and remove any needed sysfs attribute files. So take advantage of that
> and do not register "by hand" a bunch of sysfs files.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
Applied, thank you.
> ---
> drivers/input/keyboard/gpio_keys.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c
> b/drivers/input/keyboard/gpio_keys.c
> index 03f4d152f6b7..1373dc5b0765 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -351,10 +351,7 @@ static struct attribute *gpio_keys_attrs[] = {
> &dev_attr_disabled_switches.attr,
> NULL,
> };
> -
> -static const struct attribute_group gpio_keys_attr_group = {
> - .attrs = gpio_keys_attrs,
> -};
> +ATTRIBUTE_GROUPS(gpio_keys);
>
> static void gpio_keys_gpio_report_event(struct gpio_button_data *bdata)
> {
> @@ -851,13 +848,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
>
> fwnode_handle_put(child);
>
> - error = devm_device_add_group(dev, &gpio_keys_attr_group);
> - if (error) {
> - dev_err(dev, "Unable to export keys/switches, error: %d\n",
> - error);
> - return error;
> - }
> -
> error = input_register_device(input);
> if (error) {
> dev_err(dev, "Unable to register input device, error: %d\n",
> @@ -1026,6 +1016,7 @@ static struct platform_driver gpio_keys_device_driver =
> {
> .name = "gpio-keys",
> .pm = &gpio_keys_pm_ops,
> .of_match_table = gpio_keys_of_match,
> + .dev_groups = gpio_keys_groups,
> }
> };
>
> --
> 2.22.0
>
--
Dmitry
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #79 from ReddestDream --- >I tried something like that before but a huge portion of the commits in that >range won't build kernels that can boot (at least on my system). It's interesting that you found d1a3e239a6016f2bb42a91696056e223982e8538 to improve the issue: https://github.com/torvalds/linux/commit/d1a3e239a6016f2bb42a91696056e223982e8538#diff-0bc07842bc28283d64ffa6dd2ed716de >From Tom B.'s and my review of the code, it seems very likely that somehow a failure to set a hard minimum properly is at the heart of the issue. >This brings me to the second thing: When looking through the commits, I >noticed that there were multiple commits that claim to prevent or reduce >crashing in high-resolution situations (one references 5k displays, another >references 3+ 4k displays). Yeah. I have 2 4K displays as well. But I don't think it should really be straining the card. These commits are probably overzealous for Radeon VII. Rather it could be that at least part of the issue, especially the excessive power draw at idle, is just due to these commits artificially setting minimums very high. In fact, that could be why it's stable at all with just one monitor, since the code to set the minimums up is only being triggered when there are more monitors connected. I'd suspect a boottime configuration issue too, but others have reported instability even when the monitors are hotplugged later on. So, it seems like maybe the monitor detect might at least partially be okay, but the follow-through with raising the clock minimums is broken. I suspect the issue is in the code calculating the minimum to set, so the driver gets stuck trying to send incomplete/incorrect values to the card. https://bbs.archlinux.org/viewtopic.php?id=247733 It does make me wonder if it's worth testing like 2 simple 1080p 60 Hz displays. Maybe that wouldn't trigger this issue. Not that that would really be of use to me. But it might help distinguish between just monitor detect generally being broken and "high monitor load" being broken . . . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH for-5.3] drm/omap: ensure we have a valid dma_mask
On 09/08/2019 13.00, Tomi Valkeinen wrote:
> Here's my version.
>
> From c258309e36fc86076db155aead03a3900b96c3d4 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen
> Date: Fri, 9 Aug 2019 09:54:49 +0300
> Subject: [PATCH] drm/omap: ensure we have a valid dma_mask
>
> The omapdrm driver uses dma_set_coherent_mask(), but that's not enough
> anymore when LPAE is enabled.
>
> From Christoph Hellwig :
>
> The traditional arm DMA code ignores, but the generic dma-direct/swiotlb
> has stricter checks and thus fails mappings without a DMA mask. As we
> use swiotlb for arm with LPAE now, omapdrm needs to catch up and
> actually set a DMA mask.
>
> Change the dma_set_coherent_mask() call to
> dma_coerce_mask_and_coherent() so that the dev->dma_mask is also set.
Reviewed-by: Peter Ujfalusi
> Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
> Reported-by: "H. Nikolaus Schaller"
> Signed-off-by: Tomi Valkeinen
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 288c59dae56a..1bad0a2cc5c6 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -669,7 +669,7 @@ static int pdev_probe(struct platform_device *pdev)
> if (omapdss_is_initialized() == false)
> return -EPROBE_DEFER;
>
> - ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (ret) {
> dev_err(&pdev->dev, "Failed to set the DMA mask\n");
> return ret;
>
>
>
>
- Péter
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
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #78 from Chris Hodapp --- > I don't see anywhere else to go but bisection from 5.0.13 to 5.1. That should > at least find something . . . I tried something like that before but a huge portion of the commits in that range won't build kernels that can boot (at least on my system). I ended up resorting to trying reverting individual vega20-affecting commits out of 5.1. See my results far above in the thread (though someone else willing to spend more time doing a deeper analysis of the code could probably take my approach much further). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #13 from Haxk20 (haxk...@gmail.com) --- (In reply to Michel Dänzer from comment #12) > (In reply to vr00m from comment #11) > > ICYMI, I was able to solve the tearing problem with raven ridge using > > iommu=soft boot param. > > Tearing isn't related to the IOMMU. Scatter/gather scanout support for Raven > Ridge is landing now, maybe you're running a development snapshot kernel > which has it already? Could you please point us to the patch series that implements scatter/gather scanout support for Raven Ridge ? I havent found it in rc4 nor in drm-next-5.4 Thank you. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #103 from reject5...@naver.com --- I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0x option enabled. Patch didn't work for me. My GPU is RX570. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #77 from ReddestDream --- >I guess, you are good for a bisection if you have a "working" kernel. This is, based on everything here, I'm not convinced that 5.0.13 has 0 issues. Only that it seems to have fewer issues. But yeah. I don't see anywhere else to go but bisection from 5.0.13 to 5.1. That should at least find something . . . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #76 from Sylvain BERTRAND --- > Unfortunately, it does look like going through and slowing disabling features > and/or bisecting might be the only way to find how this issue got started. At > least if we could narrow it down, we might be in better shape. :/ I guess, you are good for a bisection if you have a "working" kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #83 from J. Andrew Lanz-O'Brien --- Can confirm that this bug is still present as of August 11, 2019 on kernel 5.2.8 with mesa 19.1.4. Borderlands 2 hard locked my system about 5 times tonight. Manually setting the power profile didn't help either, ie these two commands: echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level echo 7 > /sys/class/drm/card0/device/pp_dpm_sclk -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111372] Dual-monitor desktop environment crash with certain monitor positions
https://bugs.freedesktop.org/show_bug.cgi?id=111372 Bug ID: 111372 Summary: Dual-monitor desktop environment crash with certain monitor positions Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: theodoretts...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 145032 --> https://bugs.freedesktop.org/attachment.cgi?id=145032&action=edit Monitor placement crash/working cutoff There's an issue with certain desktop environments crashing on startup when the monitors of a multi-display system are in certain positions. In my case, I have two monitors, and my desktop environment crashes with the error cinnamon: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. when my secondary monitor is positioned to the left of the primary monitor. An example placement can be seen in the attached image. This is roughly the cutoff; moving the secondary monitor, the Philips, any farther left and restarting the DE will result in a crash. Keeping it further right and restarting the DE results in no issues. The secondary monitor can be either above or below the primary monitor with the same results. This error also occurs if the secondary monitor is too far left when the DE starts on system startup. Switching which monitor is the primary and secondary results in the same issue, with a crash if the new secondary is too far left. I'm using Linux Mint 19.2, Cinnamon 4.2.3, and kernel version 5.0.0-23-generic, though I've tried several different kernel versions. I'm using an RX480. The issue has been confirmed by others at https://github.com/linuxmint/cinnamon/issues/8754 and a very similar and likely linked issue at https://bugs.launchpad.net/ubuntu/+source/cinnamon/+bug/1837087 . glxinfo output can be found at https://pastebin.com/RGnAR320 and I'm happy to provide any other information needed, though I may need some pointers on something like recompiling Mesa in debug mode and getting a trace stack. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Fix potential integer overflow in komeda_crtc_update_clock_ratio
Add suffix ULL to constant 1000 in order to avoid a potential integer
overflow and give the compiler complete information about the proper
arithmetic to use. Notice that this constant is being used in a context
that expects an expression of type u64, but it's currently evaluated
using 32-bit arithmetic.
Addresses-Coverity-ID: 1485796 ("Unintentional integer overflow")
Fixes: ed22c6d9304d ("drm/komeda: Use drm_display_mode "crtc_" prefixed
hardware timings")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index fa9a4593bb37..624d257da20f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -27,7 +27,7 @@ static void komeda_crtc_update_clock_ratio(struct
komeda_crtc_state *kcrtc_st)
return;
}
- pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
+ pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000ULL;
aclk = komeda_crtc_get_aclk(kcrtc_st);
kcrtc_st->clock_ratio = div64_u64(aclk << 32, pxlclk);
--
2.22.0
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #75 from ReddestDream --- >Here's some additional investigation. >[SetUclkToHightestDpmLevel] Set hard min uclk failed! Appears as one of the >first errors in dmesg. This is from vega20_hwmgr.c:3354 and triggered by: I agree that [SetUclkToHightestDpmLevel] is probably the key to all this as it always seems to be the first thing that fails after dysregulation occurs. The "Failed to send message 0x28, response 0x0" errors show that the driver is sending wrong or at least wrongly timed commands to the GPU that eventually cascade into complete failure. >Again, it didn't help. I will note that this code is identical in 5.0.13 I have also been unable to find changed code since 5.0 that could be directly connected to display detect/init/enumeration issues on Radeon VII/Vega 20. This is why I've come to suspect the error is triggered indirectly in a way that will probably not be obvious and by code that was likely flawed from the beginning of Radeon VII/Vega 20 support. This is also why I was hopeful that 5.3-rc2 would fix this issue since it has commits that do seem to affect display detection on AMD GPUs. Alas, it did not. :( >If the GPU did not crash with dpm disabled as a whole, the proper way to proceed would be to start from there and step by step add dpm features and see when it starts crashing. It's not a small task since dpm code paths may be scattered all over the code. Unfortunately, it does look like going through and slowing disabling features and/or bisecting might be the only way to find how this issue got started. At least if we could narrow it down, we might be in better shape. :/ I must admit I don't have much experience with graphics drivers and when I tell other people about this issue, they immediately want to blame X or Mesa until I explain that I can get these errors w/o starting any graphics at all. lol. In any case, I really appreciate your testing Tom B. And any advice you might have on debugging, Sylvain BERTRAND, is greatly appreciated. :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #74 from Sylvain BERTRAND --- Forcing the memory clock and voltage is not enough: the dc[en]x memory requests should be given also the highest priority in the arbiter block. I don't recall how it interacts with the dc[en]x watermarks, but they should be "disabled" or "maxed out". Basically, whatever the 3D/compute/(vcn|vce/uvd) load, the dc[en]x will always come first (due to the realtime nature of display data transmission to monitors). Oh and of course, the smu/smc should not manage the dc[en]x. Very probably, there are some smc/smu commands to do that. If the GPU did not crash with dpm disabled as a whole, the proper way to proceed would be to start from there and step by step add dpm features and see when it starts crashing. It's not a small task since dpm code paths may be scattered all over the code. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Best practice for embedded code samles? [Was: drm/drv: Use // for comments in example code]
On Thu, Aug 08, 2019 at 06:36:28PM +0200, Jonathan Neuschäfer wrote:
> This improves Sphinx output in two ways:
>
> - It avoids an unmatched single-quote ('), about which Sphinx complained:
>
> /.../Documentation/gpu/drm-internals.rst:298:
> WARNING: Could not lex literal_block as "c". Highlighting skipped.
>
> An alternative approach would be to replace "can't" with a word that
> doesn't have a single-quote.
>
> - It lets Sphinx format the comments in italics and grey, making the
> code slightly easier to read.
>
> Signed-off-by: Jonathan Neuschäfer
The result looks much better now - thanks.
I wonder if there is a better way to embed a code sample
than reverting to // style comments.
As the kernel do not like // comments we should try to avoid them in
examples.
Mauro/Jon?
Sam
> ---
> drivers/gpu/drm/drm_drv.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9d00947ca447..769feeff 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -328,11 +328,9 @@ void drm_minor_release(struct drm_minor *minor)
> * struct drm_device *drm;
> * int ret;
> *
> - * [
> - * devm_kzalloc() can't be used here because the drm_device
> - * lifetime can exceed the device lifetime if driver unbind
> - * happens when userspace still has open file descriptors.
> - * ]
> + * // devm_kzalloc() can't be used here because the drm_device '
> + * // lifetime can exceed the device lifetime if driver unbind
> + * // happens when userspace still has open file descriptors.
> * priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> * if (!priv)
> * return -ENOMEM;
> @@ -355,7 +353,7 @@ void drm_minor_release(struct drm_minor *minor)
> * if (IS_ERR(priv->pclk))
> * return PTR_ERR(priv->pclk);
> *
> - * [ Further setup, display pipeline etc ]
> + * // Further setup, display pipeline etc
> *
> * platform_set_drvdata(pdev, drm);
> *
> @@ -370,7 +368,7 @@ void drm_minor_release(struct drm_minor *minor)
> * return 0;
> * }
> *
> - * [ This function is called before the devm_ resources are released ]
> + * // This function is called before the devm_ resources are released
> * static int driver_remove(struct platform_device *pdev)
> * {
> * struct drm_device *drm = platform_get_drvdata(pdev);
> @@ -381,7 +379,7 @@ void drm_minor_release(struct drm_minor *minor)
> * return 0;
> * }
> *
> - * [ This function is called on kernel restart and shutdown ]
> + * // This function is called on kernel restart and shutdown
> * static void driver_shutdown(struct platform_device *pdev)
> * {
> * drm_atomic_helper_shutdown(platform_get_drvdata(pdev));
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] Add drivers for auo, kd101n80-45na and boe, tv101wum-nl6 panels
Hi Jitao. > .../display/panel/auo,kd101n80-45na.txt | 34 + > .../display/panel/boe,tv101wum-nl6.txt| 34 + panel bindings are in the process of being migrated to the new meta-schema format. Therefore new bindings should preferably also follow the new format. Can you please look into this. In upstream and drm-misc-next there is already some examples. Note: It is not a hard rule that new bindings shall be in the new meta-schema format (.yaml extension), but as this is best practice now it is preferred. Same goes for display bindings btw. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[CI] dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any.
v4: Same applies to installing the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..d3fbd950be94 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -13,6 +13,8 @@
#include
#include
+#define PENDING_ERROR 1
+
static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
{
return "dma_fence_array";
@@ -23,10 +25,29 @@ static const char *dma_fence_array_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
+static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
+ int error)
+{
+ /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*/
+ if (error)
+ cmpxchg(&array->base.error, PENDING_ERROR, error);
+}
+
+static void dma_fence_array_clear_pending_error(struct dma_fence_array *array)
+{
+ /* Clear the error flag if not actually set. */
+ cmpxchg(&array->base.error, PENDING_ERROR, 0);
+}
+
static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ dma_fence_array_clear_pending_error(array);
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -38,6 +59,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
+ dma_fence_array_set_pending_error(array, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,9 +86,14 @@ static bool dma_fence_array_enable_signaling(struct
dma_fence *fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
dma_fence_array_cb_func)) {
+ int error = array->fences[i]->error;
+
+ dma_fence_array_set_pending_error(array, error);
dma_fence_put(&array->base);
- if (atomic_dec_and_test(&array->num_pending))
+ if (atomic_dec_and_test(&array->num_pending)) {
+ dma_fence_array_clear_pending_error(array);
return false;
+ }
}
}
@@ -142,6 +170,8 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->base.error = PENDING_ERROR;
+
return array;
}
EXPORT_SYMBOL(dma_fence_array_create);
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[CI] dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any.
v4: Same applies to installing the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..d3fbd950be94 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -13,6 +13,8 @@
#include
#include
+#define PENDING_ERROR 1
+
static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
{
return "dma_fence_array";
@@ -23,10 +25,29 @@ static const char *dma_fence_array_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
+static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
+ int error)
+{
+ /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*/
+ if (error)
+ cmpxchg(&array->base.error, PENDING_ERROR, error);
+}
+
+static void dma_fence_array_clear_pending_error(struct dma_fence_array *array)
+{
+ /* Clear the error flag if not actually set. */
+ cmpxchg(&array->base.error, PENDING_ERROR, 0);
+}
+
static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ dma_fence_array_clear_pending_error(array);
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -38,6 +59,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
+ dma_fence_array_set_pending_error(array, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,9 +86,14 @@ static bool dma_fence_array_enable_signaling(struct
dma_fence *fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
dma_fence_array_cb_func)) {
+ int error = array->fences[i]->error;
+
+ dma_fence_array_set_pending_error(array, error);
dma_fence_put(&array->base);
- if (atomic_dec_and_test(&array->num_pending))
+ if (atomic_dec_and_test(&array->num_pending)) {
+ dma_fence_array_clear_pending_error(array);
return false;
+ }
}
}
@@ -142,6 +170,8 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->base.error = PENDING_ERROR;
+
return array;
}
EXPORT_SYMBOL(dma_fence_array_create);
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] dma-fence: Propagate errors to dma-fence-array container
Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc3 next-20190809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-fence-Propagate-errors-to-dma-fence-array-container/20190812-022143 reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) >> include/linux/dma-fence-array.h:49: warning: Function parameter or member >> 'pending_error' not described in 'dma_fence_array' include/linux/w1.h:272: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' lib/genalloc.c:1: warning: 'gen_pool_add_virt' not found lib/genalloc.c:1: warning: 'gen_pool_alloc' not found lib/genalloc.c:1: warning: 'gen_pool_free' not found lib/genalloc.c:1: warning: 'gen_pool_alloc_algo' not found include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' drivers/gpu/drm/mcde/mcde_drv.c:1: warning: 'ST-Ericsson MCDE DRM Driver' not found include/net/mac80211.h:2006: warning: Function parameter or member 'txpwr' not described in 'ieee80211_sta' mm/util.c:1: warning: 'get_user_pages_fast' not found mm/slab.c:4215: warning: Function parameter or member 'objp' not described in '__ksize' include/linux/skbuff.h:893: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'encapsulation' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'csum_valid' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__pkt_vlan_present_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'vlan_present' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'csum_level' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 're
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #73 from Tom B --- Created attachment 145026 --> https://bugs.freedesktop.org/attachment.cgi?id=145026&action=edit diff of vega20_hwmgr.c from 5.0.13 to 5.2.7 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #72 from Tom B ---
> The nasty displayport mst thingy? I would always set this to false.
I don't believe mst is being used here, it's two monitors both with separate
cables.
Here's some additional investigation.
[SetUclkToHightestDpmLevel] Set hard min uclk failed! Appears as one of the
first errors in dmesg. This is from vega20_hwmgr.c:3354 and triggered by:
PP_ASSERT_WITH_CODE(!(ret =
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinByFreq,
(PPCLK_UCLK << 16 ) |
dpm_table->dpm_state.hard_min_level)),
"[SetUclkToHightestDpmLevel] Set hard min uclk
failed!",
return ret);
hard_min_level is adjusted if disable_mclk_switching is set on line 3497.
disable_mclk_switching = ((1 < hwmgr->display_config->num_display) &&
!hwmgr->display_config->multi_monitor_in_sync) ||
vblank_too_short;
/* Hardmin is dependent on displayconfig */
if (disable_mclk_switching) {
dpm_table->dpm_state.hard_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
for (i = 0; i < data->mclk_latency_table.count - 1; i++) {
if (data->mclk_latency_table.entries[i].latency <=
latency) {
if (dpm_table->dpm_levels[i].value >=
(hwmgr->display_config->min_mem_set_clock / 100)) {
dpm_table->dpm_state.hard_min_level =
dpm_table->dpm_levels[i].value;
break;
}
}
}
}
Interestingly, this also checks for the presence of multiple displays so we at
least have a connection between the code, error message and cause of the bug
(multiple displays). As a very crude test, I tried forcing it on and compiling
with
disable_mclk_switching = true;
No difference, so I also tried:
disable_mclk_switching = false;
Again, it didn't help. I will note that this code is identical in 5.0.13 so my
test was really only checking for an incorrect value being set elsewhere in
hwmgr->display_config->multi_monitor_in_sync or
hwmgr->display_config->num_display. In 5.0.13 I do get mclk boosting, It idles
at 351mhz and boosts to 1001mhz so I don't think that forcing the memory to max
clock all the time is the correct solution.
I also diff'd vega20_hwmgr.c from 5.0.13 and 5.2.7 (I'll attach it). Here's a
few things I noticed:
in vega20_init_smc_table, this line has been added in this commit
https://github.com/torvalds/linux/commit/f5e79735cab448981e245a41ee6cbebf0e334f61
:
+ data->vbios_boot_state.fclock = boot_up_values.ulFClk;
I don't know what fclock is, but this was never set in 5.0.13.
in vega20_setup_default_dpm_tables:
@@ -710,8 +729,10 @@ static int vega20_setup_default_dpm_tables(struct pp_hwmgr
*hwmgr)
PP_ASSERT_WITH_CODE(!ret,
"[SetupDefaultDpmTable] failed to get fclk dpm
levels!",
return ret);
- } else
- dpm_table->count = 0;
+ } else {
+ dpm_table->count = 1;
+ dpm_table->dpm_levels[0].value = data->vbios_boot_state.fclock
/ 100;
+ }
in 5.0.13, dpm_table->count is set to 0, in 5.2.7 it's set and a dpm_level
added based on fclock. fclock appears throughout as a new addition. I don't
think this is the cause, but the addition of fclock may be worth exploring.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/tegra: Turn off and reset hardware across suspend-resume
The drivers core bumps runtime PM refcount during of entering into
suspend to workaround some problem where parent device may become turned
off before its children. In order to disable and reset CRTCs/HDMI/etc
hardware, the runtime PM needs to be "forced" into suspend mode.
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2: The SYSTEM_SLEEP_PM_OPS are now set for all of the relevant drivers and
not only for the DC because turned out that they all should enforce the
suspending.
drivers/gpu/drm/tegra/dc.c| 2 ++
drivers/gpu/drm/tegra/dpaux.c | 2 ++
drivers/gpu/drm/tegra/dsi.c | 2 ++
drivers/gpu/drm/tegra/hdmi.c | 2 ++
drivers/gpu/drm/tegra/hub.c | 2 ++
drivers/gpu/drm/tegra/sor.c | 2 ++
drivers/gpu/drm/tegra/vic.c | 2 ++
7 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 4a75d149e368..6c8f5222d558 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2572,6 +2572,8 @@ static int tegra_dc_resume(struct device *dev)
static const struct dev_pm_ops tegra_dc_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_dc_suspend, tegra_dc_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver tegra_dc_driver = {
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 2d94da225e51..22f80f69ffb8 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -638,6 +638,8 @@ static int tegra_dpaux_resume(struct device *dev)
static const struct dev_pm_ops tegra_dpaux_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_dpaux_suspend, tegra_dpaux_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct of_device_id tegra_dpaux_of_match[] = {
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 2fbfefe9cb42..fd0f8cec8c7e 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -1665,6 +1665,8 @@ static int tegra_dsi_resume(struct device *dev)
static const struct dev_pm_ops tegra_dsi_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_dsi_suspend, tegra_dsi_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct of_device_id tegra_dsi_of_match[] = {
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 334c4d7d238b..ef66defac767 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1739,6 +1739,8 @@ static int tegra_hdmi_resume(struct device *dev)
static const struct dev_pm_ops tegra_hdmi_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_hdmi_suspend, tegra_hdmi_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver tegra_hdmi_driver = {
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 92f202ec0577..3d33d0360169 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -931,6 +931,8 @@ static int __maybe_unused tegra_display_hub_resume(struct
device *dev)
static const struct dev_pm_ops tegra_display_hub_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_display_hub_suspend,
tegra_display_hub_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct tegra_display_hub_soc tegra186_display_hub = {
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 4ffe3794e6d3..b743193bf0b1 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3572,6 +3572,8 @@ static int tegra_sor_resume(struct device *dev)
static const struct dev_pm_ops tegra_sor_pm_ops = {
SET_RUNTIME_PM_OPS(tegra_sor_suspend, tegra_sor_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver tegra_sor_driver = {
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 958548ef69e7..880304a65c5c 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -476,6 +476,8 @@ static int vic_remove(struct platform_device *pdev)
static const struct dev_pm_ops vic_pm_ops = {
SET_RUNTIME_PM_OPS(vic_runtime_suspend, vic_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
struct platform_driver tegra_vic_driver = {
--
2.22.0
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Noralf. > >>> + /* register value */ > >>> + buffer[4] = 0x72; > >>> + buffer[5] = val >> 8; > >>> + buffer[6] = val; > >>> + value_xfer.tx_buf = buffer + 4; > >>> + spi_message_add_tail(&value_xfer, &msg); > >>> + > >>> + return spi_sync(lcd->spi, &msg); > >>> +} > >> > >> Just a note to Sam: > >> This is the same spi protocol that the ili9325 controller on the hy28b > >> panel uses. > >> > >> I remembered that I have experimented with a regmap implementation: > >> https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191 > > > > regmap seems a too limited interface to use when trying to generalize > > this. > > We should rather go for a ili-lib or something that can be used in all > > the present and future ili based drivers. > > Obviously it depends on how similar the ili based chips are. > > > > I did a quick look and this driver did not match the ili9325 datasheet > > as different bits was are in register 0x1. > > So it smeels like another, similar. ili varaint. > > > > So for this driver we would just use the hardcoded varaint already > > present. Then we may re-visit ili-lib idea later if we see too much > > similar code. > > This is as I see it for now... > > > > Yeah, no point in changing this driver until there are more similar > controllers. Just wanted to point out that the hy28b panel you ordered > uses the same protocol. Ohh, that was your point. Thanks! The display is still in the mail somewhere from China.. Right now I do not have time to hack on it so not a big deal. For the fun of it I ordred a few other displays. One was ssd1306 based, and do not recall the rest. Sam > > A web search helped my memory, these 3 supported by staging/fbtft use a > startbyte: ili9320, ili9325 and hx8347d. The ili chips are almost > identical. The search revealed many more including: > st7793, st7781r, S6E63D6, +many ilitek. > > Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/9] DRM panel drivers for omapdrm
Hi Laurent. On Sun, Aug 11, 2019 at 02:10:39AM +0300, Laurent Pinchart wrote: > Hello everybody, > > These 9 patches have initially been posted as part of the larger "[PATCH > 00/60] drm/omap: Replace custom display drivers with drm_bridge and > drm_panel" series, hence the v2 in the subject prefix. > > I'm posting this second version separately per Sam's request as the rest > of the original series is expected to take more time to process through > review. Thanks, make good sense (to me) that we process these now while waiting for the dust to settel on the other more invasive patches. > > There's nothing very special here. The first three patches add DT vendor > prefixes and DT bindings. Since v1 patch 3/9 has been converted from > text to YAML, and as I'm not very familiar with YAML DT bindings, I'm > eagerly waiting for reviews. > > The last six patches add new panel drivers. The code originates from the > corresponding omapdrm-specific panel drivers, which explains why only > one new DT binding is needed as most of them are already present. > > Please see individual patches for changelogs. Sam, I believe I've taken > all your comments into account, I hope none fell through the cracks. I have been through the patches - all looked good. One generel comment about drm_panel_remove(). The DT for the NEC NL8048HL11 needs to be reviewed, and then we can land all patches in one go. Unless someone else put some review effort in and find something. Sam > > The patches are based on top of drm-misc-next and can be found at > > git://linuxtv.org/pinchartl/media.git omapdrm/panels > > Laurent Pinchart (9): > dt-bindings: Add vendor prefix for LG Display > dt-bindings: Add legacy 'toppoly' vendor prefix > dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel > drm/panel: Add driver for the LG Philips LB035Q02 panel > drm/panel: Add driver for the NEC NL8048HL11 panel > drm/panel: Add driver for the Sharp LS037V7DW01 panel > drm/panel: Add driver for the Sony ACX565AKM panel > drm/panel: Add driver for the Toppoly TD028TTEC1 panel > drm/panel: Add driver for the Toppoly TD043MTEA1 panel > > .../display/panel/nec,nl8048hl11.yaml | 49 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 5 + > drivers/gpu/drm/panel/Kconfig | 46 ++ > drivers/gpu/drm/panel/Makefile| 6 + > drivers/gpu/drm/panel/panel-lg-lb035q02.c | 237 ++ > drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 247 +++ > .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 226 ++ > drivers/gpu/drm/panel/panel-sony-acx565akm.c | 693 ++ > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 381 ++ > drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 508 + > 10 files changed, 2398 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml > create mode 100644 drivers/gpu/drm/panel/panel-lg-lb035q02.c > create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c > create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c > create mode 100644 drivers/gpu/drm/panel/panel-sony-acx565akm.c > create mode 100644 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c > create mode 100644 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c > > -- > Regards, > > Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Den 11.08.2019 18.49, skrev Sam Ravnborg:
> Hi Noralf.
>
>>> +static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
>>> +{
>>> + struct spi_message msg;
>>> + struct spi_transfer index_xfer = {
>>> + .len= 3,
>>> + .cs_change = 1,
>>> + };
>>> + struct spi_transfer value_xfer = {
>>> + .len= 3,
>>> + };
>>> + u8 buffer[16];
>>> +
>>> + spi_message_init(&msg);
>>> +
>>> + /* register index */
>>> + buffer[0] = 0x70;
>>> + buffer[1] = 0x00;
>>> + buffer[2] = reg & 0x7f;
>>> + index_xfer.tx_buf = buffer;
>>> + spi_message_add_tail(&index_xfer, &msg);
>>> +
>>> + /* register value */
>>> + buffer[4] = 0x72;
>>> + buffer[5] = val >> 8;
>>> + buffer[6] = val;
>>> + value_xfer.tx_buf = buffer + 4;
>>> + spi_message_add_tail(&value_xfer, &msg);
>>> +
>>> + return spi_sync(lcd->spi, &msg);
>>> +}
>>
>> Just a note to Sam:
>> This is the same spi protocol that the ili9325 controller on the hy28b
>> panel uses.
>>
>> I remembered that I have experimented with a regmap implementation:
>> https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191
>
> regmap seems a too limited interface to use when trying to generalize
> this.
> We should rather go for a ili-lib or something that can be used in all
> the present and future ili based drivers.
> Obviously it depends on how similar the ili based chips are.
>
> I did a quick look and this driver did not match the ili9325 datasheet
> as different bits was are in register 0x1.
> So it smeels like another, similar. ili varaint.
>
> So for this driver we would just use the hardcoded varaint already
> present. Then we may re-visit ili-lib idea later if we see too much
> similar code.
> This is as I see it for now...
>
Yeah, no point in changing this driver until there are more similar
controllers. Just wanted to point out that the hy28b panel you ordered
uses the same protocol.
A web search helped my memory, these 3 supported by staging/fbtft use a
startbyte: ili9320, ili9325 and hx8347d. The ili chips are almost
identical. The search revealed many more including:
st7793, st7781r, S6E63D6, +many ilitek.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm/panel: Add driver for the NEC NL8048HL11 panel
Hi Laurent.
On Sun, Aug 11, 2019 at 02:10:44AM +0300, Laurent Pinchart wrote:
> This panel is used on the Zoom2/3/3630 SDP boards.
>
> The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Mention boards using the panel in Kconfig
> - Renamed nl8048_device to nl8048_panel
> - Comments updates
> - Store width_mm and height_mm in drm_display_mode
> - Use drm_panel_disable() in .remove() handler
> ---
> drivers/gpu/drm/panel/Kconfig| 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 247 +++
> 3 files changed, 256 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 87cdc330672b..d28133c6aa0a 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -119,6 +119,14 @@ config DRM_PANEL_LG_LG4573
> Say Y here if you want to enable support for LG4573 RGB panel.
> To compile this driver as a module, choose M here.
>
> +config DRM_PANEL_NEC_NL8048HL11
> + tristate "NEC NL8048HL11 RGB panel"
> + depends on GPIOLIB && OF && SPI
> + help
> + Say Y here if you want to enable support for the NEC NL8048HL11 RGB
> + panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
> + as a module, choose M here.
> +
> config DRM_PANEL_NOVATEK_NT39016
> tristate "Novatek NT39016 RGB/SPI panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 9bc6f3c5bf96..8052f9a7ad60 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
> panel-jdi-lt070me05000.o
> obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
> obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> +obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
> obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
> obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> diff --git a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> new file mode 100644
> index ..7c1b77a0b024
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> @@ -0,0 +1,247 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NEC NL8048HL11 Panel Driver
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated
> + *
> + * Based on the omapdrm-specific panel-nec-nl8048hl11 driver
> + *
> + * Copyright (C) 2010 Texas Instruments Incorporated
> + * Author: Erik Gilling
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct nl8048_panel {
> + struct drm_panel panel;
> +
> + struct spi_device *spi;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +#define to_nl8048_device(p) container_of(p, struct nl8048_panel, panel)
> +
> +static int nl8048_write(struct nl8048_panel *lcd, unsigned char addr,
> + unsigned char value)
> +{
> + u8 data[4] = { value, 0x01, addr, 0x00 };
> + int ret;
> +
> + ret = spi_write(lcd->spi, data, sizeof(data));
> + if (ret)
> + dev_err(&lcd->spi->dev, "SPI write to %u failed: %d\n",
> + addr, ret);
> +
> + return ret;
> +}
> +
> +static int nl8048_init(struct nl8048_panel *lcd)
> +{
> + static const struct {
> + unsigned char addr;
> + unsigned char data;
> + } nl8048_init_seq[] = {
> + { 3, 0x01 }, { 0, 0x00 }, { 1, 0x01 }, { 4, 0x00 },
> + { 5, 0x14 }, { 6, 0x24 }, { 16, 0xd7 }, { 17, 0x00 },
> + { 18, 0x00 }, { 19, 0x55 }, { 20, 0x01 }, { 21, 0x70 },
> + { 22, 0x1e }, { 23, 0x25 }, { 24, 0x25 }, { 25, 0x02 },
> + { 26, 0x02 }, { 27, 0xa0 }, { 32, 0x2f }, { 33, 0x0f },
> + { 34, 0x0f }, { 35, 0x0f }, { 36, 0x0f }, { 37, 0x0f },
> + { 38, 0x0f }, { 39, 0x00 }, { 40, 0x02 }, { 41, 0x02 },
> + { 42, 0x02 }, { 43, 0x0f }, { 44, 0x0f }, { 45, 0x0f },
> + { 46, 0x0f }, { 47, 0x0f }, { 48, 0x0f }, { 49, 0x0f },
> + { 50, 0x00 }, { 51, 0x02 }, { 52, 0x02 }, { 53, 0x02 },
> + { 80, 0x0c }, { 83, 0x42 }, { 84, 0x42 }, { 85, 0x41 },
> + { 86, 0x14 }, { 89, 0x88 }, { 90, 0x01 }, { 91, 0x00 },
> + { 92, 0x02 }, { 93, 0x0c }, { 94, 0x1c }, { 95, 0x27 },
> + { 98, 0x49 }, { 99, 0x27 }, { 102, 0x76 }, { 103, 0x27 },
> + { 112, 0x01 }, { 113,
Re: [PATCH 4/4] drm/panel/ili9341: Support DPI panels
Hi Noralf.
On Thu, Aug 01, 2019 at 03:52:49PM +0200, Noralf Trønnes wrote:
> Add support for panels that use the DPI interface.
> ILI9341 has onboard RAM so the assumption made here is that all such
> panels support pixel upload over DBI.
>
> The presence/absense of the Device Tree 'port' node decides which
> interface is used for pixel transfer.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 56
> 1 file changed, 45 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index f6082fa2a389..7cbfd739c7fd 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -53,11 +54,13 @@
> struct ili9341_config {
> const struct drm_panel_funcs *funcs;
> const struct drm_display_mode *mode;
> + bool no_dpi;
> };
>
> struct ili9341 {
> struct mipi_dbi_dev dbidev; /* This must be the first entry */
> struct drm_panel panel;
> + bool use_dpi;
> struct regulator *regulator;
> struct backlight_device *backlight;
> const struct ili9341_config *conf;
> @@ -174,6 +177,7 @@ static const struct drm_display_mode yx240qv29_mode = {
> static const struct ili9341_config yx240qv29_data = {
> .funcs = &yx240qv29_funcs,
> .mode = &yx240qv29_mode,
> + .no_dpi = true,
> };
>
> static int mi0283qt_prepare(struct drm_panel *panel)
> @@ -291,6 +295,7 @@ static const struct drm_display_mode mi0283qt_mode = {
> static const struct ili9341_config mi0283qt_data = {
> .funcs = &mi0283qt_drm_funcs,
> .mode = &mi0283qt_mode,
> + .no_dpi = true,
> };
>
> /* Legacy, DRM driver name is ABI */
> @@ -303,6 +308,7 @@ static int ili9341_probe(struct spi_device *spi)
> const struct spi_device_id *spi_id;
> struct device *dev = &spi->dev;
> struct drm_driver *driver;
> + struct device_node *port;
> struct mipi_dbi *dbi;
> struct gpio_desc *dc;
> struct ili9341 *ili;
> @@ -357,21 +363,44 @@ static int ili9341_probe(struct spi_device *spi)
> ili->panel.dev = dev;
> ili->panel.funcs = ili->conf->funcs;
>
> - if (ili->conf == &mi0283qt_data)
> - driver = &mi0283qt_drm_driver;
> - else
> - driver = &ili9341_drm_driver;
>
> - return drm_mipi_dbi_panel_register(&ili->panel, &ili->dbidev, driver,
> -ili->conf->mode, rotation);
> + port = of_get_child_by_name(dev->of_node, "port");
> + if (port) {
> + of_node_put(port);
> + ili->use_dpi = true;
> + }
> +
> + if (ili->conf->no_dpi)
> + ili->use_dpi = false;
> +
> + if (ili->use_dpi) {
> + ret = drm_panel_add(&ili->panel);
> + } else {
> + if (ili->conf == &mi0283qt_data)
> + driver = &mi0283qt_drm_driver;
> + else
> + driver = &ili9341_drm_driver;
> +
> + ret = drm_mipi_dbi_panel_register(&ili->panel, &ili->dbidev,
> driver,
> + ili->conf->mode, rotation);
> + }
> +
> + return ret;
> }
>
> static int ili9341_remove(struct spi_device *spi)
> {
> struct ili9341 *ili = spi_get_drvdata(spi);
>
> - drm_dev_unplug(&ili->dbidev.drm);
> - drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + if (ili->use_dpi) {
> + drm_panel_remove(&ili->panel);
> + drm_panel_disable(&ili->panel);
> + drm_panel_unprepare(&ili->panel);
> + kfree(ili);
At first I thought - order is wrong.
But drm_panel_remove() prevents display drivers from using the driver.
And this will not invalidate the other calls.
Maybe add a short comment?
Sam
> + } else {
> + drm_dev_unplug(&ili->dbidev.drm);
> + drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + }
>
> return 0;
> }
> @@ -380,21 +409,26 @@ static void ili9341_shutdown(struct spi_device *spi)
> {
> struct ili9341 *ili = spi_get_drvdata(spi);
>
> - drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> + drm_atomic_helper_shutdown(&ili->dbidev.drm);
> }
>
> static int __maybe_unused ili9341_pm_suspend(struct device *dev)
> {
> struct ili9341 *ili = dev_get_drvdata(dev);
>
> - return drm_mode_config_helper_suspend(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> + return drm_mode_config_helper_suspend(&ili->dbidev.drm);
> +
> + return 0;
> }
>
> static int __maybe_unused ili9341_pm_resume(struct device *dev)
> {
> struct ili9341 *ili = dev_get_drvdata(dev);
>
> - drm_mode_config_helper_resume(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> +
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #71 from Sylvain BERTRAND --- On Sun, Aug 11, 2019 at 01:15:48AM +, bugzilla-dae...@freedesktop.org wrote: > I think the clock dysregulation and excessive voltage/wattage are symptoms of Is there a way to configure the smu block to keep the memory clock to its max with the appropriate power/voltage? If the smu block do configure some of the vram arbiter block priority, could we tell it to keep the dc[en]x to max priority and ignore display vram watermarks? (due to the realtime requirement of monitor data transmission, I still don't understand the existence of watermarks in the first place, I would need data which proves me wrong). On my AMD TAHITI XT, the memory clock seems to be locked to the max (only 1 full hd 144Hz monitor). I recall dce6 has fancy inner-blocks configuration: I simplified it in my custom driver (something about availability of display clocks and memory bandwidth. Maybe the smu while clock/power managing breaks due this dc[en]x "fancy" inner-blocks configuration. Additionnally, never heard of 2 displays which would be driven by a common display block and being in sync. Is the sync dependant on the monitors and not the display block?? What I am missing ? The nasty displayport mst thingy? I would always set this to false. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/9] dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel
Hi Laurent.
My meta-schemas foo is very limited, but I noticed a few things.
Hopefully Rob finds time soon to review.
Sam
On Sun, Aug 11, 2019 at 02:10:42AM +0300, Laurent Pinchart wrote:
> The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB
> parallel data interface and an SPI control interface.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Convert to YAML
> ---
> .../display/panel/nec,nl8048hl11.yaml | 49 +++
> 1 file changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> new file mode 100644
> index ..cc3d40975828
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NEC NL8048HL11 4.1" WVGA TFT LCD panel
> +
> +description:
> + The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB parallel
> + data interface and an SPI control interface.
> +
> +maintainers:
> + - Laurent Pinchart
> +
> +allOf:
> + - $ref: panel-common.yaml#
I *think* we are missing a reference to spi-controller.yaml here.
> +
> +properties:
> + compatible:
> +const: nec,nl8048hl11
> +
> + label: true
> + reset-gpios: true
> + port: true
> +
> +required:
> + - compatible
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +lcd_panel: panel {
> + compatible = "nec,nl8048hl11";
> + spi-max-frequency = <1000>;
Not sure, but should there be a reg property here for spi too?
> +
> + reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>;
> +
> + port {
> +lcd_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> +};
> + };
> +};
> +
> +...
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Noralf.
> > +static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
> > +{
> > + struct spi_message msg;
> > + struct spi_transfer index_xfer = {
> > + .len= 3,
> > + .cs_change = 1,
> > + };
> > + struct spi_transfer value_xfer = {
> > + .len= 3,
> > + };
> > + u8 buffer[16];
> > +
> > + spi_message_init(&msg);
> > +
> > + /* register index */
> > + buffer[0] = 0x70;
> > + buffer[1] = 0x00;
> > + buffer[2] = reg & 0x7f;
> > + index_xfer.tx_buf = buffer;
> > + spi_message_add_tail(&index_xfer, &msg);
> > +
> > + /* register value */
> > + buffer[4] = 0x72;
> > + buffer[5] = val >> 8;
> > + buffer[6] = val;
> > + value_xfer.tx_buf = buffer + 4;
> > + spi_message_add_tail(&value_xfer, &msg);
> > +
> > + return spi_sync(lcd->spi, &msg);
> > +}
>
> Just a note to Sam:
> This is the same spi protocol that the ili9325 controller on the hy28b
> panel uses.
>
> I remembered that I have experimented with a regmap implementation:
> https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191
regmap seems a too limited interface to use when trying to generalize
this.
We should rather go for a ili-lib or something that can be used in all
the present and future ili based drivers.
Obviously it depends on how similar the ili based chips are.
I did a quick look and this driver did not match the ili9325 datasheet
as different bits was are in register 0x1.
So it smeels like another, similar. ili varaint.
So for this driver we would just use the hardcoded varaint already
present. Then we may re-visit ili-lib idea later if we see too much
similar code.
This is as I see it for now...
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: gm12u320: Do not take a mutex from a wait_event condition
Hi Hans. On Sun, Aug 11, 2019 at 04:37:24PM +0200, Hans de Goede wrote: > I made the condition of the wait_event_timeout call in > gm12u320_fb_update_work a helper which takes a mutex to make sure > that any writes to fb_update.run or fb_update.fb from other CPU cores > are seen before the check is done. > > This is not necessary as the wait_event helpers contain the necessary > barriers for this themselves. > > More over it is harmfull since by the time the check is done the task > is no longer in the TASK_RUNNING state and calling mutex_lock while not > in task-running is not allowed, leading to this warning when the kernel > is build with some extra locking checks enabled: > > [11947.450011] do not call blocking ops when !TASK_RUNNING; state=2 set at >[] prepare_to_wait_event+0x61/0x190 > > This commit fixes this by dropping the helper and simply directly > checking the condition (without unnecessary locking) in the > wait_event_timeout call. > > Signed-off-by: Hans de Goede Both patches are: Acked-by: Sam Ravnborg Code looks sane and matches your explanations. But with limited clue on locking or USB this is not a proper review. Sam > --- > drivers/gpu/drm/tiny/gm12u320.c | 14 ++ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c > index 4c47aa4de09b..4d66765b1125 100644 > --- a/drivers/gpu/drm/tiny/gm12u320.c > +++ b/drivers/gpu/drm/tiny/gm12u320.c > @@ -342,17 +342,6 @@ static void gm12u320_copy_fb_to_blocks(struct > gm12u320_device *gm12u320) > mutex_unlock(&gm12u320->fb_update.lock); > } > > -static int gm12u320_fb_update_ready(struct gm12u320_device *gm12u320) > -{ > - int ret; > - > - mutex_lock(&gm12u320->fb_update.lock); > - ret = !gm12u320->fb_update.run || gm12u320->fb_update.fb != NULL; > - mutex_unlock(&gm12u320->fb_update.lock); > - > - return ret; > -} > - > static void gm12u320_fb_update_work(struct work_struct *work) > { > struct gm12u320_device *gm12u320 = > @@ -426,7 +415,8 @@ static void gm12u320_fb_update_work(struct work_struct > *work) >* switches back to showing its logo. >*/ > wait_event_timeout(gm12u320->fb_update.waitq, > -gm12u320_fb_update_ready(gm12u320), > +!gm12u320->fb_update.run || > + gm12u320->fb_update.fb != NULL, > IDLE_TIMEOUT); > } > return; > -- > 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/panel/ili9341: Support DPI panels
Hi Noralf.
On Thu, Aug 01, 2019 at 03:52:49PM +0200, Noralf Trønnes wrote:
> Add support for panels that use the DPI interface.
> ILI9341 has onboard RAM so the assumption made here is that all such
> panels support pixel upload over DBI.
>
> The presence/absense of the Device Tree 'port' node decides which
> interface is used for pixel transfer.
Have you consiered if the compatible could be used to determine the use
of a panel?
Then it is more explicit how the HW is described in DT.
Sam
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 56
> 1 file changed, 45 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index f6082fa2a389..7cbfd739c7fd 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -53,11 +54,13 @@
> struct ili9341_config {
> const struct drm_panel_funcs *funcs;
> const struct drm_display_mode *mode;
> + bool no_dpi;
> };
>
> struct ili9341 {
> struct mipi_dbi_dev dbidev; /* This must be the first entry */
> struct drm_panel panel;
> + bool use_dpi;
> struct regulator *regulator;
> struct backlight_device *backlight;
> const struct ili9341_config *conf;
> @@ -174,6 +177,7 @@ static const struct drm_display_mode yx240qv29_mode = {
> static const struct ili9341_config yx240qv29_data = {
> .funcs = &yx240qv29_funcs,
> .mode = &yx240qv29_mode,
> + .no_dpi = true,
> };
>
> static int mi0283qt_prepare(struct drm_panel *panel)
> @@ -291,6 +295,7 @@ static const struct drm_display_mode mi0283qt_mode = {
> static const struct ili9341_config mi0283qt_data = {
> .funcs = &mi0283qt_drm_funcs,
> .mode = &mi0283qt_mode,
> + .no_dpi = true,
> };
>
> /* Legacy, DRM driver name is ABI */
> @@ -303,6 +308,7 @@ static int ili9341_probe(struct spi_device *spi)
> const struct spi_device_id *spi_id;
> struct device *dev = &spi->dev;
> struct drm_driver *driver;
> + struct device_node *port;
> struct mipi_dbi *dbi;
> struct gpio_desc *dc;
> struct ili9341 *ili;
> @@ -357,21 +363,44 @@ static int ili9341_probe(struct spi_device *spi)
> ili->panel.dev = dev;
> ili->panel.funcs = ili->conf->funcs;
>
> - if (ili->conf == &mi0283qt_data)
> - driver = &mi0283qt_drm_driver;
> - else
> - driver = &ili9341_drm_driver;
>
> - return drm_mipi_dbi_panel_register(&ili->panel, &ili->dbidev, driver,
> -ili->conf->mode, rotation);
> + port = of_get_child_by_name(dev->of_node, "port");
> + if (port) {
> + of_node_put(port);
> + ili->use_dpi = true;
> + }
> +
> + if (ili->conf->no_dpi)
> + ili->use_dpi = false;
> +
> + if (ili->use_dpi) {
> + ret = drm_panel_add(&ili->panel);
> + } else {
> + if (ili->conf == &mi0283qt_data)
> + driver = &mi0283qt_drm_driver;
> + else
> + driver = &ili9341_drm_driver;
> +
> + ret = drm_mipi_dbi_panel_register(&ili->panel, &ili->dbidev,
> driver,
> + ili->conf->mode, rotation);
> + }
> +
> + return ret;
> }
>
> static int ili9341_remove(struct spi_device *spi)
> {
> struct ili9341 *ili = spi_get_drvdata(spi);
>
> - drm_dev_unplug(&ili->dbidev.drm);
> - drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + if (ili->use_dpi) {
> + drm_panel_remove(&ili->panel);
> + drm_panel_disable(&ili->panel);
> + drm_panel_unprepare(&ili->panel);
> + kfree(ili);
> + } else {
> + drm_dev_unplug(&ili->dbidev.drm);
> + drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + }
>
> return 0;
> }
> @@ -380,21 +409,26 @@ static void ili9341_shutdown(struct spi_device *spi)
> {
> struct ili9341 *ili = spi_get_drvdata(spi);
>
> - drm_atomic_helper_shutdown(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> + drm_atomic_helper_shutdown(&ili->dbidev.drm);
> }
>
> static int __maybe_unused ili9341_pm_suspend(struct device *dev)
> {
> struct ili9341 *ili = dev_get_drvdata(dev);
>
> - return drm_mode_config_helper_suspend(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> + return drm_mode_config_helper_suspend(&ili->dbidev.drm);
> +
> + return 0;
> }
>
> static int __maybe_unused ili9341_pm_resume(struct device *dev)
> {
> struct ili9341 *ili = dev_get_drvdata(dev);
>
> - drm_mode_config_helper_resume(&ili->dbidev.drm);
> + if (!ili->use_dpi)
> + drm_mode_config_helper_resume(&ili
Re: [PATCH v5] dma-fence: Propagate errors to dma-fence-array container
Am 11.08.19 um 18:25 schrieb Chris Wilson:
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
> v3: Be careful not to flag an error if we race against signal-on-any.
> v4: Same applies to installing the signal cb.
> v5: Use cmpxchg to only set the error once before using a nifty idea by
> Christian to avoid changing the status after emitting the signal.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: Christian König
Reviewed-by: Christian König
> ---
> drivers/dma-buf/dma-fence-array.c | 32 ++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c
> b/drivers/dma-buf/dma-fence-array.c
> index 12c6f64c0bc2..d3fbd950be94 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#define PENDING_ERROR 1
> +
> static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
> {
> return "dma_fence_array";
> @@ -23,10 +25,29 @@ static const char
> *dma_fence_array_get_timeline_name(struct dma_fence *fence)
> return "unbound";
> }
>
> +static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
> + int error)
> +{
> + /*
> + * Propagate the first error reported by any of our fences, but only
> + * before we ourselves are signaled.
> + */
> + if (error)
> + cmpxchg(&array->base.error, PENDING_ERROR, error);
> +}
> +
> +static void dma_fence_array_clear_pending_error(struct dma_fence_array
> *array)
> +{
> + /* Clear the error flag if not actually set. */
> + cmpxchg(&array->base.error, PENDING_ERROR, 0);
> +}
> +
> static void irq_dma_fence_array_work(struct irq_work *wrk)
> {
> struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
>
> + dma_fence_array_clear_pending_error(array);
> +
> dma_fence_signal(&array->base);
> dma_fence_put(&array->base);
> }
> @@ -38,6 +59,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
> container_of(cb, struct dma_fence_array_cb, cb);
> struct dma_fence_array *array = array_cb->array;
>
> + dma_fence_array_set_pending_error(array, f->error);
> +
> if (atomic_dec_and_test(&array->num_pending))
> irq_work_queue(&array->work);
> else
> @@ -63,9 +86,14 @@ static bool dma_fence_array_enable_signaling(struct
> dma_fence *fence)
> dma_fence_get(&array->base);
> if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
> dma_fence_array_cb_func)) {
> + int error = array->fences[i]->error;
> +
> + dma_fence_array_set_pending_error(array, error);
> dma_fence_put(&array->base);
> - if (atomic_dec_and_test(&array->num_pending))
> + if (atomic_dec_and_test(&array->num_pending)) {
> + dma_fence_array_clear_pending_error(array);
> return false;
> + }
> }
> }
>
> @@ -142,6 +170,8 @@ struct dma_fence_array *dma_fence_array_create(int
> num_fences,
> atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
> array->fences = fences;
>
> + array->base.error = PENDING_ERROR;
> +
> return array;
> }
> EXPORT_SYMBOL(dma_fence_array_create);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any.
v4: Same applies to installing the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..d3fbd950be94 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -13,6 +13,8 @@
#include
#include
+#define PENDING_ERROR 1
+
static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
{
return "dma_fence_array";
@@ -23,10 +25,29 @@ static const char *dma_fence_array_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
+static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
+ int error)
+{
+ /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*/
+ if (error)
+ cmpxchg(&array->base.error, PENDING_ERROR, error);
+}
+
+static void dma_fence_array_clear_pending_error(struct dma_fence_array *array)
+{
+ /* Clear the error flag if not actually set. */
+ cmpxchg(&array->base.error, PENDING_ERROR, 0);
+}
+
static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ dma_fence_array_clear_pending_error(array);
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -38,6 +59,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
+ dma_fence_array_set_pending_error(array, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,9 +86,14 @@ static bool dma_fence_array_enable_signaling(struct
dma_fence *fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
dma_fence_array_cb_func)) {
+ int error = array->fences[i]->error;
+
+ dma_fence_array_set_pending_error(array, error);
dma_fence_put(&array->base);
- if (atomic_dec_and_test(&array->num_pending))
+ if (atomic_dec_and_test(&array->num_pending)) {
+ dma_fence_array_clear_pending_error(array);
return false;
+ }
}
}
@@ -142,6 +170,8 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->base.error = PENDING_ERROR;
+
return array;
}
EXPORT_SYMBOL(dma_fence_array_create);
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
Am 11.08.19 um 11:15 schrieb Chris Wilson:
> Now that dma_fence_signal always takes the spinlock to flush the
> cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> avoid code repetition.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
> Cc: Christian König
Reviewed-by: Christian König
> ---
> drivers/dma-buf/dma-fence.c | 32
> 1 file changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index ab4a456bba04..367b71084d34 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -122,26 +122,18 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
>*/
> int dma_fence_signal_locked(struct dma_fence *fence)
> {
> - int ret = 0;
> -
> - lockdep_assert_held(fence->lock);
> -
> if (WARN_ON(!fence))
> return -EINVAL;
>
> - if (!__dma_fence_signal(fence)) {
> - ret = -EINVAL;
> + lockdep_assert_held(fence->lock);
>
> - /*
> - * we might have raced with the unlocked dma_fence_signal,
> - * still run through all callbacks
> - */
> - } else {
> - __dma_fence_signal__timestamp(fence, ktime_get());
> - }
> + if (!__dma_fence_signal(fence))
> + return -EINVAL;
>
> + __dma_fence_signal__timestamp(fence, ktime_get());
> __dma_fence_signal__notify(fence);
> - return ret;
> +
> + return 0;
> }
> EXPORT_SYMBOL(dma_fence_signal_locked);
>
> @@ -161,19 +153,19 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
> int dma_fence_signal(struct dma_fence *fence)
> {
> unsigned long flags;
> + int ret;
>
> if (!fence)
> return -EINVAL;
>
> - if (!__dma_fence_signal(fence))
> - return -EINVAL;
> -
> - __dma_fence_signal__timestamp(fence, ktime_get());
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> + return 0;
>
> spin_lock_irqsave(fence->lock, flags);
> - __dma_fence_signal__notify(fence);
> + ret = dma_fence_signal_locked(fence);
> spin_unlock_irqrestore(fence->lock, flags);
> - return 0;
> +
> + return ret;
> }
> EXPORT_SYMBOL(dma_fence_signal);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] dma-fence: Propagate errors to dma-fence-array container
How about this instead:
Setting array->base.error = 1 during initialization.
Then cmpxchg(array->base.error, 1, error) whenever a fence in the array
signals.
And then finally cmpxchg(array->base.error, 1, 0) when the array itself
signals.
Christian.
Am 11.08.19 um 14:21 schrieb Chris Wilson:
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
> v3: Be careful not to flag an error if we race against signal-on-any.
> v4: Same applies to installing the signal cb.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: Christian König
> ---
> drivers/dma-buf/dma-fence-array.c | 37 ++-
> include/linux/dma-fence-array.h | 2 ++
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c
> b/drivers/dma-buf/dma-fence-array.c
> index 12c6f64c0bc2..4d574dff0ba9 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -23,10 +23,37 @@ static const char
> *dma_fence_array_get_timeline_name(struct dma_fence *fence)
> return "unbound";
> }
>
> +static void dma_fence_array_set_error(struct dma_fence_array *array)
> +{
> + int error = READ_ONCE(array->pending_error);
> +
> + if (!array->base.error && error)
> + dma_fence_set_error(&array->base, error);
> +}
> +
> +static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
> + int error)
> +{
> + /*
> + * Propagate the first error reported by any of our fences, but only
> + * before we ourselves are signaled.
> + *
> + * Note that this may race with multiple fences completing
> + * simultaneously in error, but only one error will be kept, not
> + * necessarily the first. So long as we propagate an error if any
> + * fences were in error before we are signaled we should be telling
> + * an acceptable truth.
> + */
> + if (error && !array->pending_error)
> + WRITE_ONCE(array->pending_error, error);
> +}
> +
> static void irq_dma_fence_array_work(struct irq_work *wrk)
> {
> struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
>
> + dma_fence_array_set_error(array);
> +
> dma_fence_signal(&array->base);
> dma_fence_put(&array->base);
> }
> @@ -38,6 +65,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
> container_of(cb, struct dma_fence_array_cb, cb);
> struct dma_fence_array *array = array_cb->array;
>
> + dma_fence_array_set_pending_error(array, f->error);
> +
> if (atomic_dec_and_test(&array->num_pending))
> irq_work_queue(&array->work);
> else
> @@ -63,9 +92,14 @@ static bool dma_fence_array_enable_signaling(struct
> dma_fence *fence)
> dma_fence_get(&array->base);
> if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
> dma_fence_array_cb_func)) {
> + int error = array->fences[i]->error;
> +
> + dma_fence_array_set_pending_error(array, error);
> dma_fence_put(&array->base);
> - if (atomic_dec_and_test(&array->num_pending))
> + if (atomic_dec_and_test(&array->num_pending)) {
> + dma_fence_array_set_error(array);
> return false;
> + }
> }
> }
>
> @@ -141,6 +175,7 @@ struct dma_fence_array *dma_fence_array_create(int
> num_fences,
> array->num_fences = num_fences;
> atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
> array->fences = fences;
> + array->pending_error = 0;
>
> return array;
> }
> diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
> index 303dd712220f..faaf70c524ae 100644
> --- a/include/linux/dma-fence-array.h
> +++ b/include/linux/dma-fence-array.h
> @@ -42,6 +42,8 @@ struct dma_fence_array {
> atomic_t num_pending;
> struct dma_fence **fences;
>
> + int pending_error;
> +
> struct irq_work work;
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #70 from Tom B ---
> Based on all the data you (Tom B) and others have provided as well as my own
> tests, my current suspicion is that there is a bug in the display mode/type
> detection and enumeration, leading to the driver losing state consistency and
> eventually contact entirely with the hardware.
I looked through the commits and the code trying to find anything that dealt
with multiple displays as that seems to be the trigger but couldn't find
anything that looked promising.
It's probably worth noting what I tried/found even though I was unsuccessful as
it may help someone. I'm fairly sure that the problem must be this file:
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
There is a variable called NumOfDisplays and related code. Maybe someone who
understands driver development can point me in the right direction:
Line 2049 seems promising.
smu_send_smc_msg_with_param(smu, SMU_MSG_NumOfDisplays, 0);
ret = vega20_set_uclk_to_highest_dpm_level(smu,
&dpm_table->mem_table);
if (ret)
pr_err("Failed to set uclk to highest dpm level");
Although that error message is not displayed in dmesg, this function deals with
multiple displays and the power levels. Unfortunatelely I cannot find
documenation for the driver code. What does smu_send_smc_msg_with_param do?
Because here the last argument is 0. In the next function,
vega20_display_config_changed the final argument is the number of displays:
smu_send_smc_msg_with_param(smu,
SMU_MSG_NumOfDisplays,
smu->display_config->num_display);
The next point of interest is line 2091. I don't think it's the cause of the
bug but:
disable_mclk_switching = ((1 < smu->display_config->num_display) &&
!smu->display_config->multi_monitor_in_sync)
|| vblank_too_short;
disable_mclk_switching is set if the number of displays is more than 1 and
"multi_monitor_in_sync" (whatever that is, possibly mirrored displays?) or
"vblank_too_short". I don't believe this is a problem because the code has
existed since January, presumably for the February release, but perhaps the
contents of the different variables has chagned so this code runs differently.
I only mention this because it's the only point in the code I found where it
does something different if more than one display is connected.
My questions for the driver devs:
1. Why is smu_send_smc_msg_with_param called with zero in the function
vega20_pre_display_config_changed but the number of displays in the next
function?
2. Is num_displays an index (so 0 is actually the first display and we're
assuming 1 display in index 0) or is it actually 0, no displays?
3. Is there any way to see which code appears in which kernel version? The tags
are definitely incorrect, the first commit for that file:
https://github.com/torvalds/linux/commit/74e07f9d3b77034cd1546617afce1d014a68d1ca#diff-2575675126169f3c0c971db736852af9
says 5.2 but was done in December last year so I can't imagine this file isn't
used.
However, as a customer this is very frustrating. I bought the VII instead of an
nvidia card because AMD were supporting open source drivers.
As it stands:
- The AMDGPU driver worked for 4 months after the VII's release and now we've
had nearly the same amount of time where it hasn't worked with the latest
kernel.
- The AMDGPU-Pro driver only supports Ubuntu, I've never managed to get it to
run successfully on Arch and the latest version only supports The RX5700 cards
anyway.
I emailed AMD technical support about this bug over a month ago and never got a
reply.
The VII appears to be completely unsupported other than the initial driver
release when the card came out. I'll be going back to nvidia next time and
although I had intended to keep the VII for several years it looks like that
won't be possible as I can't run an old kernel forever.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/tiny/ili9341: Move driver to drm/panel
Hi Noralf.
Most feedback on this driver was covered in comment to 1/4.
Only a few things caught my eye.
On Thu, Aug 01, 2019 at 03:52:47PM +0200, Noralf Trønnes wrote:
> Move the driver to drm/panel and take advantage of the new panel support
> in drm_mipi_dbi. Change the file name to match the naming standard in
> drm/panel. The DRM driver name is kept since it is ABI.
>
> Add missing MAINTAINERS entry.
>
> Cc: David Lechner
> Signed-off-by: Noralf Trønnes
> ---
> MAINTAINERS | 7 +
> drivers/gpu/drm/panel/Kconfig | 12 ++
> drivers/gpu/drm/panel/Makefile| 1 +
> .../panel-ilitek-ili9341.c} | 174 ++
> drivers/gpu/drm/tiny/Kconfig | 13 --
> drivers/gpu/drm/tiny/Makefile | 1 -
> 6 files changed, 113 insertions(+), 95 deletions(-)
> rename drivers/gpu/drm/{tiny/ili9341.c => panel/panel-ilitek-ili9341.c} (66%)
>
> +
> +struct ili9341 {
> + struct mipi_dbi_dev dbidev; /* This must be the first entry */
Can we avoid the need for this to be the first entry?
> -static struct drm_driver ili9341_driver = {
> - .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .fops = &ili9341_fops,
> - .release= mipi_dbi_release,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .debugfs_init = mipi_dbi_debugfs_init,
> - .name = "ili9341",
> - .desc = "Ilitek ILI9341",
> - .date = "20180514",
> - .major = 1,
> - .minor = 0,
> +DEFINE_DRM_MIPI_DBI_PANEL_DRIVER(ili9341, "Ilitek ILI9341", "20180514");
Update the date. This is a major change so let it be refelcted in the
date.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: gm12u320: Add -ENODEV to list of errors to ignore
Add -ENODEV to the list of usb-transfer errors which we ignore to
avoid logging Frame update errors when the device gets unplugged.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 4d66765b1125..08a52a67ec9e 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -422,7 +422,7 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
return;
err:
/* Do not log errors caused by module unload or device unplug */
- if (ret != -ECONNRESET && ret != -ESHUTDOWN)
+ if (ret != -ENODEV && ret != -ECONNRESET && ret != -ESHUTDOWN)
GM12U320_ERR("Frame update error: %d\n", ret);
}
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: gm12u320: Do not take a mutex from a wait_event condition
I made the condition of the wait_event_timeout call in gm12u320_fb_update_work a helper which takes a mutex to make sure that any writes to fb_update.run or fb_update.fb from other CPU cores are seen before the check is done. This is not necessary as the wait_event helpers contain the necessary barriers for this themselves. More over it is harmfull since by the time the check is done the task is no longer in the TASK_RUNNING state and calling mutex_lock while not in task-running is not allowed, leading to this warning when the kernel is build with some extra locking checks enabled: [11947.450011] do not call blocking ops when !TASK_RUNNING; state=2 set at [] prepare_to_wait_event+0x61/0x190 This commit fixes this by dropping the helper and simply directly checking the condition (without unnecessary locking) in the wait_event_timeout call. Signed-off-by: Hans de Goede --- drivers/gpu/drm/tiny/gm12u320.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c index 4c47aa4de09b..4d66765b1125 100644 --- a/drivers/gpu/drm/tiny/gm12u320.c +++ b/drivers/gpu/drm/tiny/gm12u320.c @@ -342,17 +342,6 @@ static void gm12u320_copy_fb_to_blocks(struct gm12u320_device *gm12u320) mutex_unlock(&gm12u320->fb_update.lock); } -static int gm12u320_fb_update_ready(struct gm12u320_device *gm12u320) -{ - int ret; - - mutex_lock(&gm12u320->fb_update.lock); - ret = !gm12u320->fb_update.run || gm12u320->fb_update.fb != NULL; - mutex_unlock(&gm12u320->fb_update.lock); - - return ret; -} - static void gm12u320_fb_update_work(struct work_struct *work) { struct gm12u320_device *gm12u320 = @@ -426,7 +415,8 @@ static void gm12u320_fb_update_work(struct work_struct *work) * switches back to showing its logo. */ wait_event_timeout(gm12u320->fb_update.waitq, - gm12u320_fb_update_ready(gm12u320), + !gm12u320->fb_update.run || + gm12u320->fb_update.fb != NULL, IDLE_TIMEOUT); } return; -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/mipi-dbi: Support command mode panel drivers
Hi Noralf.
I really like how this allows us to have a single file for all
the uses of a driver IC.
And this patch-set is much easier to grasp than the first RFC.
General things:
- The current design have a tight connection between the display
controller and the panel. Will this hurt in the long run?
In other words, should we try to add a panel_bridge in-between?
For now I think this would just make something simple more
complicated.
So this note was to say - no I think we should not use panel_bridge.
- drm_panel has proper support for modes.
This is today duplicated in mipi_dbi.
Could we make it so that when a panel is used then the panel
has the mode info - as we then use the panel more in the way we do
in other cases?
As it is now the mode is specified in mipi_dbi_dev_init()
The drm_connector would then, if a panel is used, ask the panel for
the mode.
I did not really think to the end of this, but it seems wrong that
we introduce drm_panel and then keep modes in mipi_dbi.
- For backlight support please move this to drm_panel.
I have patches that makes it simple to use backlight with drm_panel,
and this will then benefit from it.
The drm_panel backlight supports requires that a backlight
phandle is specified in the DT node of the panel.
Some more specific comments in the following.
Sam
On Thu, Aug 01, 2019 at 03:52:46PM +0200, Noralf Trønnes wrote:
> This adds a function that registers a DRM driver for use with MIPI DBI
> panels in command mode. That is, framebuffer upload over DBI.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 92 ++
> include/drm/drm_mipi_dbi.h | 34 +
> 2 files changed, 126 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 1961f713aaab..797a20e3a017 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -17,11 +17,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -597,6 +599,96 @@ void mipi_dbi_release(struct drm_device *drm)
> }
> EXPORT_SYMBOL(mipi_dbi_release);
>
> +static void drm_mipi_dbi_panel_pipe_enable(struct drm_simple_display_pipe
> *pipe,
> +struct drm_crtc_state *crtc_state,
> +struct drm_plane_state *plane_state)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
> + struct drm_panel *panel = dbidev->panel;
> + int ret, idx;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, &idx))
> + return;
> +
> + DRM_DEBUG_KMS("\n");
Still usefull?
> +
> + ret = drm_panel_prepare(panel);
> + if (ret)
> + goto out_exit;
> +
> + mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
> +
> + drm_panel_enable(panel);
> +out_exit:
nit - blank line above label?
> + drm_dev_exit(idx);
> +}
> +
> +static void drm_mipi_dbi_panel_pipe_disable(struct drm_simple_display_pipe
> *pipe)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
> + struct drm_panel *panel = dbidev->panel;
> +
> + if (!dbidev->enabled)
> + return;
> +
> + DRM_DEBUG_KMS("\n");
Still usefull?
> +
> + dbidev->enabled = false;
> + drm_panel_disable(panel);
> + drm_panel_unprepare(panel);
> +}
> +
> +static const struct drm_simple_display_pipe_funcs drm_mipi_dbi_pipe_funcs = {
> + .enable = drm_mipi_dbi_panel_pipe_enable,
> + .disable = drm_mipi_dbi_panel_pipe_disable,
> + .update = mipi_dbi_pipe_update,
> + .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
> +};
> +
> +/**
> + * drm_mipi_dbi_panel_register - Register a MIPI DBI DRM driver
> + * @panel: DRM Panel
> + * @dbidev: MIPI DBI device structure to initialize
> + * @mode: Display mode
> + *
> + * This function registeres a DRM driver with @panel attached.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int drm_mipi_dbi_panel_register(struct drm_panel *panel, struct mipi_dbi_dev
> *dbidev,
> + struct drm_driver *driver, const struct
> drm_display_mode *mode,
> + u32 rotation)
Can we make this use enum drm_panel_orientation - so we can use
of_drm_get_panel_orientation() in the callers?
of_drm_get_panel_orientation() is not merged yet, but we could do so if
this patch-set needs it.
I know that this would require mipi_dbi_dev_init() and all users to be
updated. But it is a simpler interface so worth it.
> +{
> + struct device *dev = panel->dev;
> + struct drm_device *drm;
> + int ret;
> +
> + dbidev->panel = panel;
> +
> + drm = &dbidev->drm;
> + ret = devm_drm_dev_init(dev, drm, driver);
> + if (ret) {
> + kfree(dbidev);
> + retu
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Laurent,
Den 11.08.2019 15.35, skrev Laurent Pinchart:
> Hi Noralf,
>
> On Sun, Aug 11, 2019 at 03:19:13PM +0200, Noralf Trønnes wrote:
>> Sam,
>>
>> Den 11.08.2019 01.10, skrev Laurent Pinchart:
>>> This panel is used on the Gumstix Overo Palo35.
>>>
>>> The code is based on the omapdrm-specific panel-lgphilips-lb035q02
>>> driver.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> Reviewed-by: Sam Ravnborg
>>> ---
>>
>>
>>
>>> diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
>>> b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
>>
>>
>>
>>> +static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
>>> +{
>>> + struct spi_message msg;
>>> + struct spi_transfer index_xfer = {
>>> + .len= 3,
>>> + .cs_change = 1,
>>> + };
>>> + struct spi_transfer value_xfer = {
>>> + .len= 3,
>>> + };
>>> + u8 buffer[16];
>>> +
>>> + spi_message_init(&msg);
>>> +
>>> + /* register index */
>>> + buffer[0] = 0x70;
>>> + buffer[1] = 0x00;
>>> + buffer[2] = reg & 0x7f;
>>> + index_xfer.tx_buf = buffer;
>>> + spi_message_add_tail(&index_xfer, &msg);
>>> +
>>> + /* register value */
>>> + buffer[4] = 0x72;
>>> + buffer[5] = val >> 8;
>>> + buffer[6] = val;
>>> + value_xfer.tx_buf = buffer + 4;
>>> + spi_message_add_tail(&value_xfer, &msg);
>>> +
>>> + return spi_sync(lcd->spi, &msg);
>>> +}
>>
>> Just a note to Sam:
>> This is the same spi protocol that the ili9325 controller on the hy28b
>> panel uses.
>>
>> I remembered that I have experimented with a regmap implementation:
>> https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191
>
> That's useful information, thanks. The controller seems different
> though, the limited information available in
> https://www.beyondinfinite.com/lcd/Library/LG-Philips/LB035Q02.pdf
> doesn't match the registers from
> https://github.com/notro/tinydrm/blob/master/fb_ili9325.c.
>
I've seen several controllers that use this protocol, and one that had a
different start byte configuration. The details unfortunately is lost in
time, it's been a while since I worked on these controllers.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: gm12u320: Some minor cleanups
Hi, On 8/1/19 4:59 PM, Sam Ravnborg wrote: Hi Hans. On Tue, Jul 30, 2019 at 03:38:56PM +0200, Hans de Goede wrote: 3 small cleanups: 1) Drop unused DRIVER_PATCHLEVEL 2) We do not set mode_config.preferred_depth, so instead of passing the unset mode_config.preferred_depth to drm_fbdev_generic_setup simply pass 0 3) Use __maybe_unused instead of #ifdef CONFIG_PM around the suspend / resume functions Cc: Sam Ravnborg Suggested-by: Sam Ravnborg If you add: Suggested-by: Noralf Trønnes And adjust to the new location. Then this is: Reviewed-by: Sam Ravnborg Thank you for the review. I will push this to drm-misc-next, with the suggested changes, tomorrow (when I'm back behind my workstation which has all the necessary kernel trees). Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Noralf,
On Sun, Aug 11, 2019 at 03:19:13PM +0200, Noralf Trønnes wrote:
> Sam,
>
> Den 11.08.2019 01.10, skrev Laurent Pinchart:
> > This panel is used on the Gumstix Overo Palo35.
> >
> > The code is based on the omapdrm-specific panel-lgphilips-lb035q02
> > driver.
> >
> > Signed-off-by: Laurent Pinchart
> > Reviewed-by: Sam Ravnborg
> > ---
>
>
>
> > diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
> > b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
>
>
>
> > +static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
> > +{
> > + struct spi_message msg;
> > + struct spi_transfer index_xfer = {
> > + .len= 3,
> > + .cs_change = 1,
> > + };
> > + struct spi_transfer value_xfer = {
> > + .len= 3,
> > + };
> > + u8 buffer[16];
> > +
> > + spi_message_init(&msg);
> > +
> > + /* register index */
> > + buffer[0] = 0x70;
> > + buffer[1] = 0x00;
> > + buffer[2] = reg & 0x7f;
> > + index_xfer.tx_buf = buffer;
> > + spi_message_add_tail(&index_xfer, &msg);
> > +
> > + /* register value */
> > + buffer[4] = 0x72;
> > + buffer[5] = val >> 8;
> > + buffer[6] = val;
> > + value_xfer.tx_buf = buffer + 4;
> > + spi_message_add_tail(&value_xfer, &msg);
> > +
> > + return spi_sync(lcd->spi, &msg);
> > +}
>
> Just a note to Sam:
> This is the same spi protocol that the ili9325 controller on the hy28b
> panel uses.
>
> I remembered that I have experimented with a regmap implementation:
> https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191
That's useful information, thanks. The controller seems different
though, the limited information available in
https://www.beyondinfinite.com/lcd/Library/LG-Philips/LB035Q02.pdf
doesn't match the registers from
https://github.com/notro/tinydrm/blob/master/fb_ili9325.c.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
Sam,
Den 11.08.2019 01.10, skrev Laurent Pinchart:
> This panel is used on the Gumstix Overo Palo35.
>
> The code is based on the omapdrm-specific panel-lgphilips-lb035q02
> driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sam Ravnborg
> ---
> diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
> b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
> +static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
> +{
> + struct spi_message msg;
> + struct spi_transfer index_xfer = {
> + .len= 3,
> + .cs_change = 1,
> + };
> + struct spi_transfer value_xfer = {
> + .len= 3,
> + };
> + u8 buffer[16];
> +
> + spi_message_init(&msg);
> +
> + /* register index */
> + buffer[0] = 0x70;
> + buffer[1] = 0x00;
> + buffer[2] = reg & 0x7f;
> + index_xfer.tx_buf = buffer;
> + spi_message_add_tail(&index_xfer, &msg);
> +
> + /* register value */
> + buffer[4] = 0x72;
> + buffer[5] = val >> 8;
> + buffer[6] = val;
> + value_xfer.tx_buf = buffer + 4;
> + spi_message_add_tail(&value_xfer, &msg);
> +
> + return spi_sync(lcd->spi, &msg);
> +}
Just a note to Sam:
This is the same spi protocol that the ili9325 controller on the hy28b
panel uses.
I remembered that I have experimented with a regmap implementation:
https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c#L191
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any.
v4: Same applies to installing the signal cb.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 37 ++-
include/linux/dma-fence-array.h | 2 ++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..4d574dff0ba9 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -23,10 +23,37 @@ static const char *dma_fence_array_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
+static void dma_fence_array_set_error(struct dma_fence_array *array)
+{
+ int error = READ_ONCE(array->pending_error);
+
+ if (!array->base.error && error)
+ dma_fence_set_error(&array->base, error);
+}
+
+static void dma_fence_array_set_pending_error(struct dma_fence_array *array,
+ int error)
+{
+ /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*
+* Note that this may race with multiple fences completing
+* simultaneously in error, but only one error will be kept, not
+* necessarily the first. So long as we propagate an error if any
+* fences were in error before we are signaled we should be telling
+* an acceptable truth.
+*/
+ if (error && !array->pending_error)
+ WRITE_ONCE(array->pending_error, error);
+}
+
static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ dma_fence_array_set_error(array);
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -38,6 +65,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
+ dma_fence_array_set_pending_error(array, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,9 +92,14 @@ static bool dma_fence_array_enable_signaling(struct
dma_fence *fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
dma_fence_array_cb_func)) {
+ int error = array->fences[i]->error;
+
+ dma_fence_array_set_pending_error(array, error);
dma_fence_put(&array->base);
- if (atomic_dec_and_test(&array->num_pending))
+ if (atomic_dec_and_test(&array->num_pending)) {
+ dma_fence_array_set_error(array);
return false;
+ }
}
}
@@ -141,6 +175,7 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
array->num_fences = num_fences;
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->pending_error = 0;
return array;
}
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..faaf70c524ae 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -42,6 +42,8 @@ struct dma_fence_array {
atomic_t num_pending;
struct dma_fence **fences;
+ int pending_error;
+
struct irq_work work;
};
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 25 +
include/linux/dma-fence-array.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 12c6f64c0bc2..e806c5fe9ec9 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -23,10 +23,19 @@ static const char *dma_fence_array_get_timeline_name(struct
dma_fence *fence)
return "unbound";
}
+static void dma_fence_array_set_error_once(struct dma_fence_array *array,
+ int error)
+{
+ if (!array->base.error && error)
+ dma_fence_set_error(&array->base, error);
+}
+
static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ dma_fence_array_set_error_once(array, READ_ONCE(array->pending_error));
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -38,6 +47,19 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
container_of(cb, struct dma_fence_array_cb, cb);
struct dma_fence_array *array = array_cb->array;
+ /*
+* Propagate the first error reported by any of our fences, but only
+* before we ourselves are signaled.
+*
+* Note that this may race with multiple fences completing
+* simultaneously in error, but only one error will be kept, not
+* necessarily the first. So long as we propagate an error if any
+* fences were in error before we are signaled we should be telling
+* an acceptable truth.
+*/
+ if (f->error && !array->pending_error)
+ WRITE_ONCE(array->pending_error, f->error);
+
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
else
@@ -63,6 +85,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence
*fence)
dma_fence_get(&array->base);
if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
dma_fence_array_cb_func)) {
+ dma_fence_array_set_error_once(array,
+ array->fences[i]->error);
dma_fence_put(&array->base);
if (atomic_dec_and_test(&array->num_pending))
return false;
@@ -141,6 +165,7 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
array->num_fences = num_fences;
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->pending_error = 0;
return array;
}
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..faaf70c524ae 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -42,6 +42,8 @@ struct dma_fence_array {
atomic_t num_pending;
struct dma_fence **fences;
+ int pending_error;
+
struct irq_work work;
};
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dma-fence: Propagate errors to dma-fence-array container
Quoting Koenig, Christian (2019-08-11 09:58:31)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> > + /*
> > + * Propagate the first error reported by any of our fences, but only
> > + * before we ourselves are signaled.
> > + */
> > + if (atomic_read(&array->num_pending) > 0)
> > + fence_set_error_once(&array->base, f->error);
>
> That is racy even if you check the atomic because num_pending can be
> initialized to 1 for signal any arrays as well.
We both agree that we don't care about the potential write tearing if
two errors occur simultaneous, either error will do for our error?
So it's just the matter of not marking the array as being in error if we
have already signaled.
> I suggest to rather test in dma_fence_array_set_error_once if we got an
> error and if yes grab the sequence lock and test if we are already
> signaled or not.
How about embracing the race with something like,
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index d90675bb4fcc..c71c57d25e48 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -33,6 +33,8 @@ static void irq_dma_fence_array_work(struct irq_work *wrk)
{
struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+ fence_set_error_once(&array->base, READ_ONCE(array->pending_error));
+
dma_fence_signal(&array->base);
dma_fence_put(&array->base);
}
@@ -48,8 +50,8 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
* Propagate the first error reported by any of our fences, but only
* before we ourselves are signaled.
*/
- if (atomic_read(&array->num_pending) > 0)
- fence_set_error_once(&array->base, f->error);
+ if (f->error && !array->pending_error)
+ WRITE_ONCE(array->pending_error, f->error);
if (atomic_dec_and_test(&array->num_pending))
irq_work_queue(&array->work);
@@ -156,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
array->num_fences = num_fences;
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
+ array->pending_error = 0;
return array;
}
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..faaf70c524ae 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -42,6 +42,8 @@ struct dma_fence_array {
atomic_t num_pending;
struct dma_fence **fences;
+ int pending_error;
+
struct irq_work work;
};
That ensures there is no race between signaling and raising the error,
but accepts that multiple fences may try and raise an error. There is
still the potential for the signal-on-any to be flagged as an error by
the second fence, but I claim that race is immaterial as the second
fence could have been the signaler.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 7/7] drm: mediatek: adjust dsi and mipi_tx probe sequence
mtk_mipi_tx is the phy of mtk_dsi.
mtk_dsi get the phy(mtk_mipi_tx) in probe().
So, mtk_mipi_tx init should be ahead of mtk_dsi. Or mtk_dsi will
defer to wait mtk_mipi_tx probe done.
Signed-off-by: Jitao Shi
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 95fdbd0fbcac..a762fd9111ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -630,8 +630,8 @@ static struct platform_driver * const mtk_drm_drivers[] = {
&mtk_disp_rdma_driver,
&mtk_dpi_driver,
&mtk_drm_platform_driver,
- &mtk_dsi_driver,
&mtk_mipi_tx_driver,
+ &mtk_dsi_driver,
};
static int __init mtk_drm_init(void)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/7] drm/mediatek: move mipi_dsi_host_register to probe
DSI panel driver need attach function which is inculde in
mipi_dsi_host_ops.
If mipi_dsi_host_register is not in probe, dsi panel will
probe more delay.
So move the mipi_dsi_host_register to probe from bind.
Signed-off-by: Jitao Shi
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 53 +-
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b91c4616644a..52b49daeed9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -520,7 +520,7 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi,
u8 irq_flag, u32 t)
static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
- struct device *dev = dsi->dev;
+ struct device *dev = dsi->host.dev;
int ret;
u64 pixel_clock, total_bits;
u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
@@ -1047,12 +1047,6 @@ static int mtk_dsi_bind(struct device *dev, struct
device *master, void *data)
return ret;
}
- ret = mipi_dsi_host_register(&dsi->host);
- if (ret < 0) {
- dev_err(dev, "failed to register DSI host: %d\n", ret);
- goto err_ddp_comp_unregister;
- }
-
ret = mtk_dsi_create_conn_enc(drm, dsi);
if (ret) {
DRM_ERROR("Encoder create failed with %d\n", ret);
@@ -1062,8 +1056,6 @@ static int mtk_dsi_bind(struct device *dev, struct device
*master, void *data)
return 0;
err_unregister:
- mipi_dsi_host_unregister(&dsi->host);
-err_ddp_comp_unregister:
mtk_ddp_comp_unregister(drm, &dsi->ddp_comp);
return ret;
}
@@ -1075,7 +1067,6 @@ static void mtk_dsi_unbind(struct device *dev, struct
device *master,
struct mtk_dsi *dsi = dev_get_drvdata(dev);
mtk_dsi_destroy_conn_enc(dsi);
- mipi_dsi_host_unregister(&dsi->host);
mtk_ddp_comp_unregister(drm, &dsi->ddp_comp);
}
@@ -1099,31 +1090,36 @@ static int mtk_dsi_probe(struct platform_device *pdev)
dsi->host.ops = &mtk_dsi_ops;
dsi->host.dev = dev;
+ ret = mipi_dsi_host_register(&dsi->host);
+ if (ret < 0) {
+ dev_err(dev, "failed to register DSI host: %d\n", ret);
+ return ret;
+ }
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
&dsi->panel, &dsi->bridge);
if (ret)
- return ret;
+ goto err_unregister_host;
dsi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dsi->engine_clk)) {
ret = PTR_ERR(dsi->engine_clk);
dev_err(dev, "Failed to get engine clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->digital_clk = devm_clk_get(dev, "digital");
if (IS_ERR(dsi->digital_clk)) {
ret = PTR_ERR(dsi->digital_clk);
dev_err(dev, "Failed to get digital clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->hs_clk = devm_clk_get(dev, "hs");
if (IS_ERR(dsi->hs_clk)) {
ret = PTR_ERR(dsi->hs_clk);
dev_err(dev, "Failed to get hs clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1131,33 +1127,35 @@ static int mtk_dsi_probe(struct platform_device *pdev)
if (IS_ERR(dsi->regs)) {
ret = PTR_ERR(dsi->regs);
dev_err(dev, "Failed to ioremap memory: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->phy = devm_phy_get(dev, "dphy");
if (IS_ERR(dsi->phy)) {
ret = PTR_ERR(dsi->phy);
dev_err(dev, "Failed to get MIPI-DPHY: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DSI);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
- return comp_id;
+ ret = comp_id;
+ goto err_unregister_host;
}
ret = mtk_ddp_comp_init(dev, dev->of_node, &dsi->ddp_comp, comp_id,
&mtk_dsi_funcs);
if (ret) {
dev_err(dev, "Failed to initialize component: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
irq_num = platform_get_irq(pdev, 0);
if (irq_num < 0) {
- dev_err(&pdev->dev, "failed to request dsi irq resource\n");
- return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "failed to get dsi irq_num: %d\n", irq_num);
+ ret = irq_num;
+ goto err_unregis
[PATCH v6 6/7] drm/mediatek: change the dsi phytiming calculate method
Change the method of frame rate calc which can get more accurate
frame rate.
data rate = pixel_clock * bit_per_pixel / lanes
Adjust hfp_wc to adapt the additional phy_data
if MIPI_DSI_MODE_VIDEO_BURST
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
else
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
Note:
//(2: 1 for sync, 1 for phy idle)
data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
bpp: bit per pixel
Signed-off-by: Jitao Shi
Tested-by: Ryan Case
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 118 -
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b3676426aeb5..4d98ea08635a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -136,12 +136,6 @@
#define DATA_0 (0xff << 16)
#define DATA_1 (0xff << 24)
-#define T_LPX 5
-#define T_HS_PREP 6
-#define T_HS_TRAIL 8
-#define T_HS_EXIT 7
-#define T_HS_ZERO 10
-
#define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
#define MTK_DSI_HOST_IS_READ(type) \
@@ -150,6 +144,25 @@
(type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
(type == MIPI_DSI_DCS_READ))
+struct mtk_phy_timing {
+ u32 lpx;
+ u32 da_hs_prepare;
+ u32 da_hs_zero;
+ u32 da_hs_trail;
+
+ u32 ta_go;
+ u32 ta_sure;
+ u32 ta_get;
+ u32 da_hs_exit;
+
+ u32 clk_hs_zero;
+ u32 clk_hs_trail;
+
+ u32 clk_hs_prepare;
+ u32 clk_hs_post;
+ u32 clk_hs_exit;
+};
+
struct phy;
struct mtk_dsi_driver_data {
@@ -180,6 +193,7 @@ struct mtk_dsi {
enum mipi_dsi_pixel_format format;
unsigned int lanes;
struct videomode vm;
+ struct mtk_phy_timing phy_timing;
int refcount;
bool enabled;
u32 irq_data;
@@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
+
+ ui = DIV_ROUND_UP(10, dsi->data_rate);
+ cycle_time = div_u64(80ULL, dsi->data_rate);
+
+ timing->lpx = NS_TO_CYCLE(60, cycle_time);
+ timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
+ timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
+ timing->da_hs_trail = NS_TO_CYCLE(90 + 4 * ui, cycle_time);
- ui = 1000 / dsi->data_rate + 0x01;
- cycle_time = 8000 / dsi->data_rate + 0x01;
+ timing->ta_go = 4 * timing->lpx;
+ timing->ta_sure = 3 * timing->lpx / 2;
+ timing->ta_get = 5 * timing->lpx;
+ timing->da_hs_exit = 2 * timing->lpx;
- timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
- timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
- T_HS_EXIT << 24;
- timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
- NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
+ timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
+ timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
+
+ timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
+ timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
+ timing->clk_hs_exit = 2 * timing->lpx;
+
+ timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
+ timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
+ timcon1 = timing->ta_go | timing->ta_sure << 8 |
+ timing->ta_get << 16 | timing->da_hs_exit << 24;
+ timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
+ timing->clk_hs_trail << 24;
+ timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
+ timing->clk_hs_exit << 16;
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -410,7 +443,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
- u32 dsi_tmp_buf_bpp;
+ u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
struct videomode *vm = &dsi->vm;
@@ -437,7 +471,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
dsi_tmp_buf_bpp - 10);
- horizontal_frontporch_byte = (vm->hfront_porch * dsi_tmp_buf_bpp - 12);
+ data_phy_cycles = timing->lpx + timing->da_hs_prepare +
+ timing->da_hs_zero + timing->da_hs_exit + 2;
+
+ if (dsi->mode_
[PATCH v6 4/7] drm/mediatek: add frame size control
Our new DSI chip has frame size control.
So add the driver data to control for different chips.
Signed-off-by: Jitao Shi
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 314bfb1c827b..68794edecf96 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -70,6 +70,7 @@
#define DSI_VBP_NL 0x24
#define DSI_VFP_NL 0x28
#define DSI_VACT_NL0x2C
+#define DSI_SIZE_CON 0x38
#define DSI_HSA_WC 0x50
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
@@ -154,6 +155,7 @@ struct phy;
struct mtk_dsi_driver_data {
const u32 reg_cmdq_off;
bool has_shadow_ctl;
+ bool has_size_ctl;
};
struct mtk_dsi {
@@ -422,6 +424,10 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
writel(vm->vfront_porch, dsi->regs + DSI_VFP_NL);
writel(vm->vactive, dsi->regs + DSI_VACT_NL);
+ if (dsi->driver_data->has_size_ctl)
+ writel(vm->vactive << 16 | vm->hactive,
+ dsi->regs + DSI_SIZE_CON);
+
horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different with mt2701
Config the different CMDQ reg address in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 52b49daeed9f..ac8e80e379f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,7 +123,6 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
-#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET2
@@ -148,6 +147,10 @@
struct phy;
+struct mtk_dsi_driver_data {
+ const u32 reg_cmdq_off;
+};
+
struct mtk_dsi {
struct mtk_ddp_comp ddp_comp;
struct device *dev;
@@ -174,6 +177,7 @@ struct mtk_dsi {
bool enabled;
u32 irq_data;
wait_queue_head_t irq_wait_queue;
+ const struct mtk_dsi_driver_data *driver_data;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -936,6 +940,7 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct
mipi_dsi_msg *msg)
const char *tx_buf = msg->tx_buf;
u8 config, cmdq_size, cmdq_off, type = msg->type;
u32 reg_val, cmdq_mask, i;
+ u32 reg_cmdq_off = dsi->driver_data->reg_cmdq_off;
if (MTK_DSI_HOST_IS_READ(type))
config = BTA;
@@ -955,9 +960,11 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct
mipi_dsi_msg *msg)
}
for (i = 0; i < msg->tx_len; i++)
- writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+ mtk_dsi_mask(dsi, (reg_cmdq_off + cmdq_off + i) & (~0x3U),
+(0xffUL << (((i + cmdq_off) & 3U) * 8U)),
+tx_buf[i] << (((i + cmdq_off) & 3U) * 8U));
- mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, reg_cmdq_off, cmdq_mask, reg_val);
mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
}
@@ -1101,6 +1108,8 @@ static int mtk_dsi_probe(struct platform_device *pdev)
if (ret)
goto err_unregister_host;
+ dsi->driver_data = of_device_get_match_data(dev);
+
dsi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dsi->engine_clk)) {
ret = PTR_ERR(dsi->engine_clk);
@@ -1194,9 +1203,19 @@ static int mtk_dsi_remove(struct platform_device *pdev)
return 0;
}
+static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+};
+
+static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
+ .reg_cmdq_off = 0x180,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
- { .compatible = "mediatek,mt2701-dsi" },
- { .compatible = "mediatek,mt8173-dsi" },
+ { .compatible = "mediatek,mt2701-dsi",
+ .data = &mt2701_dsi_driver_data },
+ { .compatible = "mediatek,mt8173-dsi",
+ .data = &mt8173_dsi_driver_data },
{ },
};
--
2.21.0
[PATCH v6 3/7] drm/mediatek: add dsi reg commit disable control
New DSI IP has shadow register and working reg. The register
values are writen to shadow register. And then trigger with
commit reg, the register values will be moved working register.
This fucntion is defualt on. But this driver doesn't use this
function. So add the disable control.
Signed-off-by: Jitao Shi
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ac8e80e379f7..314bfb1c827b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,6 +123,10 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
+#define DSI_SHADOW_DEBUG 0x190U
+#define FORCE_COMMIT BIT(0)
+#define BYPASS_SHADOW BIT(1)
+
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET2
@@ -149,6 +153,7 @@ struct phy;
struct mtk_dsi_driver_data {
const u32 reg_cmdq_off;
+ bool has_shadow_ctl;
};
struct mtk_dsi {
@@ -586,6 +591,11 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
+
+ if (dsi->driver_data->has_shadow_ctl)
+ writel(FORCE_COMMIT | BYPASS_SHADOW,
+ dsi->regs + DSI_SHADOW_DEBUG);
+
mtk_dsi_reset_engine(dsi);
mtk_dsi_phy_timconfig(dsi);
--
2.21.0
[PATCH v6 5/7] drm/mediatek: add mt8183 dsi driver support
Add mt8183 dsi driver data. Enable size control and
reg commit control.
Signed-off-by: Jitao Shi
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 68794edecf96..b3676426aeb5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1227,11 +1227,19 @@ static const struct mtk_dsi_driver_data
mt2701_dsi_driver_data = {
.reg_cmdq_off = 0x180,
};
+static const struct mtk_dsi_driver_data mt8183_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+ .has_shadow_ctl = true,
+ .has_size_ctl = true,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
{ .compatible = "mediatek,mt2701-dsi",
.data = &mt2701_dsi_driver_data },
{ .compatible = "mediatek,mt8173-dsi",
.data = &mt8173_dsi_driver_data },
+ { .compatible = "mediatek,mt8183-dsi",
+ .data = &mt8183_dsi_driver_data },
{ },
};
--
2.21.0
[PATCH v6 0/7] Support dsi for mt8183
Change since v5: - fine tune dphy timing. Change since v4: - move mipi_dsi_host_unregiter() to .remove() - fine tune add frame size control coding style - change the data type of data_rate as u32, and add DIV_ROUND_UP_ULL - use div_u64 when 80ULL / dsi->data_rate. Changes since v3 - add one more 'tab' for bitwise define. - add Tested-by: Ryan Case and Reviewed-by: CK Hu . - remove compare da_hs_zero to da_hs_prepare. Changes since v2: - change the video timing calc method - fine the dsi and mipitx init sequence - fine tune commit msg Changes since v1: - separate frame size and reg commit control independent patches. - fix some return values in probe - remove DSI_CMDW0 in "CMDQ reg address of mt8173 is different with mt2701" Jitao Shi (7): drm/mediatek: move mipi_dsi_host_register to probe drm/mediatek: fixes CMDQ reg address of mt8173 is different with mt2701 drm/mediatek: add dsi reg commit disable control drm/mediatek: add frame size control drm/mediatek: add mt8183 dsi driver support drm/mediatek: change the dsi phytiming calculate method drm: mediatek: adjust dsi and mipi_tx probe sequence drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 224 ++--- 2 files changed, 161 insertions(+), 65 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #82 from Mauro Gaspari --- (In reply to Pierre-Eric Pelloux-Prayer from comment #81) > Can anyone provide a apitrace/renderdoc capture that can reliably reproduce > the crash/freeze? Hello, Sadly my freezes are hard to reproduce. Sometimes I can play for a day with no freeze, sometimes it freezes in 10 minutes, one hour, and so on. I had another freeze today: OS: openSUSE Tumbleweed x86_64 Kernel: 5.2.5-1-default Resolution: 3440x1440 DE: Xfce WM: Xfwm4 CPU: AMD Ryzen 7 2700X (16) @ 3.700GHz GPU: AMD ATI Radeon VII Memory: 3791MiB / 64387MiB OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.3 Game: EVE Online: Wine+DXVK. (Crossover 18.5.0) vsync off frame limiter off Problem description: Afer rougly 1 hour of gameplay, desktop Frozen for a few seconds but managed to recover. Game did not recover and I killed the process. DMESG: [20612.721860] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=12880412, emitted seq=12880414 [20612.721921] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process exefile.exe pid 1980 thread exefile.ex:cs0 pid 2057 [20612.721925] amdgpu :0a:00.0: GPU reset begin! [20613.526448] amdgpu :0a:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) [20613.526502] [drm:gfx_v9_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed [20613.547524] amdgpu :0a:00.0: GPU mode1 reset [20614.055810] [drm] psp mode1 reset succeed [20614.128815] amdgpu :0a:00.0: GPU reset succeeded, trying to resume [20614.128943] [drm] PCIE GART of 512M enabled (table at 0x00800030). [20614.129304] [drm] PSP is resuming... [20614.192202] [drm] reserve 0x40 from 0x8000c0 for PSP TMR SIZE [20614.649220] [drm] UVD and UVD ENC initialized successfully. [20614.748872] [drm] VCE initialized successfully. [20615.271942] [drm] Fence fallback timer expired on ring gfx [20615.783826] [drm] Fence fallback timer expired on ring comp_1.0.0 [20616.616023] [drm] Fence fallback timer expired on ring uvd_1 [20617.127844] [drm] Fence fallback timer expired on ring uvd_enc_1.0 [20617.639836] [drm] Fence fallback timer expired on ring uvd_enc_1.1 [20617.739606] [drm] recover vram bo from shadow start [20617.742231] [drm] recover vram bo from shadow done [20617.742233] [drm] Skip scheduling IBs! [20617.742234] [drm] Skip scheduling IBs! [20617.742259] amdgpu :0a:00.0: GPU reset(2) succeeded! [20617.742289] [drm] Skip scheduling IBs! [20617.742309] [drm] Skip scheduling IBs! [20617.742314] [drm] Skip scheduling IBs! [20617.742316] [drm] Skip scheduling IBs! [20617.742318] [drm] Skip scheduling IBs! [20617.742320] [drm] Skip scheduling IBs! [20617.743840] [drm] Skip scheduling IBs! [20617.744006] [drm] Skip scheduling IBs! [20617.744180] [drm] Skip scheduling IBs! [20617.744450] [drm] Skip scheduling IBs! System Logs: 2019-08-11T17:13:10.377029+08:00 MGDT-ROG kernel: [20612.721860] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=12880412, emitted seq=12880414 2019-08-11T17:13:10.377046+08:00 MGDT-ROG kernel: [20612.721921] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process exefile.exe pid 1980 thread exefile.ex:cs0 pid 2057 2019-08-11T17:13:10.377047+08:00 MGDT-ROG kernel: [20612.721925] amdgpu :0a:00.0: GPU reset begin! 2019-08-11T17:13:11.182763+08:00 MGDT-ROG kernel: [20613.526448] amdgpu :0a:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) 2019-08-11T17:13:11.182776+08:00 MGDT-ROG kernel: [20613.526502] [drm:gfx_v9_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed 2019-08-11T17:13:11.202766+08:00 MGDT-ROG kernel: [20613.547524] amdgpu :0a:00.0: GPU mode1 reset 2019-08-11T17:13:11.714757+08:00 MGDT-ROG kernel: [20614.055810] [drm] psp mode1 reset succeed 2019-08-11T17:13:11.786740+08:00 MGDT-ROG kernel: [20614.128815] amdgpu :0a:00.0: GPU reset succeeded, trying to resume 2019-08-11T17:13:11.786749+08:00 MGDT-ROG kernel: [20614.128943] [drm] PCIE GART of 512M enabled (table at 0x00800030). 2019-08-11T17:13:11.786751+08:00 MGDT-ROG kernel: [20614.129304] [drm] PSP is resuming... 2019-08-11T17:13:11.850739+08:00 MGDT-ROG kernel: [20614.192202] [drm] reserve 0x40 from 0x8000c0 for PSP TMR SIZE 2019-08-11T17:13:12.306756+08:00 MGDT-ROG kernel: [20614.649220] [drm] UVD and UVD ENC initialized successfully. 2019-08-11T17:13:12.406756+08:00 MGDT-ROG kernel: [20614.748872] [drm] VCE initialized successfully. 2019-08-11T17:13:12.926899+08:00 MGDT-ROG kernel: [20615.271942] [drm] Fence fallback timer expired on ring gfx 2019-08-11T17:13:13.438783+08:00 MGDT-ROG kernel: [20615.783826] [drm] Fence fallback timer expired on ring comp_1.0.0 2019-08-11T17:13:14.274773+08:00 MGDT-ROG kernel: [20616.616023] [drm] Fence fallback timer expired on ring uvd_1 2019-08-11T17:13:14.671435+08:00 MGDT-ROG tracker-store[4801]: OK 2019-08-11T17:13:14.672970+08
Re: [PATCH] dma-buf: rename reservation_object to dma_resv
Quoting Christian König (2019-08-11 09:56:01) > Be more consistent with the naming of the other DMA-buf objects. From the tip of my fingers, \o/ > Signed-off-by: Christian König Letting the compiler do the real work (for the bits I spot checked it was the expected mechanical translation), and overwhelmingly agreeing with the motivation, Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
Now that dma_fence_signal always takes the spinlock to flush the
cb_list, simply take the spinlock and call dma_fence_signal_locked() to
avoid code repetition.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index ab4a456bba04..367b71084d34 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -122,26 +122,18 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
*/
int dma_fence_signal_locked(struct dma_fence *fence)
{
- int ret = 0;
-
- lockdep_assert_held(fence->lock);
-
if (WARN_ON(!fence))
return -EINVAL;
- if (!__dma_fence_signal(fence)) {
- ret = -EINVAL;
+ lockdep_assert_held(fence->lock);
- /*
-* we might have raced with the unlocked dma_fence_signal,
-* still run through all callbacks
-*/
- } else {
- __dma_fence_signal__timestamp(fence, ktime_get());
- }
+ if (!__dma_fence_signal(fence))
+ return -EINVAL;
+ __dma_fence_signal__timestamp(fence, ktime_get());
__dma_fence_signal__notify(fence);
- return ret;
+
+ return 0;
}
EXPORT_SYMBOL(dma_fence_signal_locked);
@@ -161,19 +153,19 @@ EXPORT_SYMBOL(dma_fence_signal_locked);
int dma_fence_signal(struct dma_fence *fence)
{
unsigned long flags;
+ int ret;
if (!fence)
return -EINVAL;
- if (!__dma_fence_signal(fence))
- return -EINVAL;
-
- __dma_fence_signal__timestamp(fence, ktime_get());
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return 0;
spin_lock_irqsave(fence->lock, flags);
- __dma_fence_signal__notify(fence);
+ ret = dma_fence_signal_locked(fence);
spin_unlock_irqrestore(fence->lock, flags);
- return 0;
+
+ return ret;
}
EXPORT_SYMBOL(dma_fence_signal);
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings
Add documentation for boe tv101wum-n16 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/boe,tv101wum-nl6.txt| 34 +++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
new file mode 100644
index ..bd44af636390
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
@@ -0,0 +1,34 @@
+Boe Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,tv101wum-nl6"
+- reg: the virtual channel number of a DSI peripheral
+- enable-gpios: a GPIO spec for the enable pin
+- pp1800-supply: core voltage supply
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
+- backlight: phandle of the backlight device attached to the panel
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+&dsi {
+ ...
+ panel@0 {
+ compatible = "boe,tv101wum-nl6";
+ reg = <0>;
+ enable-gpios = <&pio 45 0>;
+ avdd-supply = <&ppvarn_lcd>;
+ avee-supply = <&ppvarp_lcd>;
+ pp1800-supply = <&pp1800_lcd>;
+ backlight = <&backlight_lcd0>;
+ status = "okay";
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/4] Add drivers for auo, kd101n80-45na and boe, tv101wum-nl6 panels
Changes since v3: - remove check enable_gpio. - fine tune the auo,kd101n80-45na panel's power on timing. Changes since v2: - correct the panel size - remove blank line in Kconfig - move auo,kd101n80-45na panel driver in this series. Changes since v1: - update typo nl6 -> n16. - update new panel config and makefile are added in alphabetically order. - add the panel mode and panel info in driver data. - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver Jitao Shi (4): dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel dt-bindings: display: panel: add auo kd101n80-45na panel bindings drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel .../display/panel/auo,kd101n80-45na.txt | 34 + .../display/panel/boe,tv101wum-nl6.txt| 34 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 761 ++ 5 files changed, 839 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH wn 2/4] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 709 ++
3 files changed, 719 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d9d931aa6e26..afcadb3585fb 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,15 @@ config DRM_PANEL_ARM_VERSATILE
reference designs. The panel is detected using special registers
in the Versatile family syscon registers.
+config DRM_PANEL_BOE_TV101WUM_NL6
+ tristate "BOE TV101WUM 1200x1920 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index fb0cb3aaa9e6..bd26b6ac039e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..c0e27f0b2713
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,709 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+};
+
+struct boe_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+
+ const struct drm_display_mode *mode;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x05),
+ _INIT_DCS_CMD(0xB1, 0xE5),
+ _INIT_DCS_CMD(0xB3, 0x52),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB3, 0x88),
+ _INIT_DCS_CMD(0xB0, 0x04),
+ _INIT_DCS_CMD(0xB8, 0x00),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB6, 0x03),
+ _INIT_DCS_CMD(0xBA, 0x8B),
+ _INIT_DCS_CMD(0xBF, 0x1A),
+ _INIT_DCS_CMD(0xC0, 0x0F),
+ _INIT_DCS_CMD(0xC2, 0x0C),
+ _INIT_DCS_CMD(0xC3, 0x02),
+ _INIT_DCS_CMD(0xC4, 0x0C),
+ _INIT_DCS_CMD(0xC5, 0x02),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xE0, 0x26),
+ _INIT_DCS_CMD(0xE1, 0x26),
+ _INIT_DCS_CMD(0xDC, 0x00),
+ _INIT_DCS_CMD(0xDD, 0x00),
+ _INIT_DCS_CMD(0xCC, 0x26),
+ _INIT_DCS_CMD(0xCD, 0x26),
+ _INIT_DCS_CMD(0xC8, 0x00),
+ _INIT_DCS_CMD(0xC9, 0x00),
+ _INIT_DCS_CMD(0xD2, 0x03),
+ _INIT_DCS_CMD(0xD3, 0x03),
+ _INIT_DCS_CMD(0xE6, 0x04),
+ _INIT_DCS_CMD(0xE7, 0x04),
+ _INIT_DCS_CMD(0xC4, 0x09),
+ _INIT_DCS_CMD(0xC5, 0x09),
+ _INIT_DCS_CMD(0xD8, 0x0A),
+ _INIT_DCS_CMD(0xD9, 0x0A),
+ _INIT_DCS_CMD(0xC2, 0x0B),
+ _INIT_DCS_CMD(0xC3, 0x0B),
+ _INIT_DCS_CMD(0xD6, 0x0C),
+ _INIT_DCS_CMD(0xD7, 0x0C),
[PATCH wn 3/4] dt-bindings: display: panel: add auo kd101n80-45na panel bindings
Add documentation for auo kd101n80-45na panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/auo,kd101n80-45na.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
new file mode 100644
index ..994c2a13f942
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
@@ -0,0 +1,34 @@
+AUO Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,kd101n80-45na"
+- reg: the virtual channel number of a DSI peripheral
+- enable-gpios: a GPIO spec for the enable pin
+- pp1800-supply: core voltage supply
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
+- backlight: phandle of the backlight device attached to the panel
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+&dsi {
+ ...
+ panel@0 {
+ compatible = "auo,kd101n80-45na";
+ reg = <0>;
+ enable-gpios = <&pio 45 0>;
+ avdd-supply = <&ppvarn_lcd>;
+ avee-supply = <&ppvarp_lcd>;
+ pp1800-supply = <&pp1800_lcd>;
+ backlight = <&backlight_lcd0>;
+ status = "okay";
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH wn 4/4] drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/Kconfig | 6 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 76 ---
2 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index afcadb3585fb..0e887c978796 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -19,13 +19,13 @@ config DRM_PANEL_ARM_VERSATILE
in the Versatile family syscon registers.
config DRM_PANEL_BOE_TV101WUM_NL6
- tristate "BOE TV101WUM 1200x1920 panel"
+ tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index c0e27f0b2713..aef4f8034c5b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -35,6 +35,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+ bool discharge_on_disable;
};
struct boe_panel {
@@ -372,6 +373,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0x11),
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0x29),
+ _INIT_DELAY_CMD(120),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -449,20 +459,30 @@ static int boe_panel_unprepare(struct drm_panel *panel)
if (!boe->prepared)
return 0;
- ret = boe_panel_off(boe);
- if (ret < 0) {
- dev_err(panel->dev, "failed to set panel off: %d\n", ret);
- return ret;
+ if (boe->desc->discharge_on_disable) {
+ msleep(150);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ } else {
+ ret = boe_panel_off(boe);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to set panel off: %d\n",
+ ret);
+ return ret;
+ }
+ msleep(150);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(500, 1000);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
}
- msleep(150);
- gpiod_set_value(boe->enable_gpio, 0);
- usleep_range(500, 1000);
- regulator_disable(boe->avee);
- regulator_disable(boe->avdd);
- usleep_range(5000, 7000);
- regulator_disable(boe->pp1800);
-
boe->prepared = false;
return 0;
@@ -564,6 +584,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+ .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_default_mode = {
+ .clock = 157000,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 + 80 + 24,
+ .htotal = 1200 + 80 + 24 + 36,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 16,
+ .vsync_end = 1920 + 16 + 4,
+ .vtotal = 1920 + 16 + 4 + 16,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_kd101n80_45na_desc = {
+ .modes = &auo_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_init_cmd,
+ .discharge_on_disable = true,
};
static int boe_panel_get_modes(struct drm_panel *panel)
@@ -689,6 +738,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-nl
Re: [PATCH 4/4] dma-fence: Always execute signal callbacks
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Allow for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signaling mechanism around every fence.
> (The cost of interrupts is too darn high, to revive an old meme.)
> This means that we may have a cb_list even if the signaling bit is not
> enabled, so always notify the callbacks.
>
> The cost is that dma_fence_signal() must always acquire the spinlock to
> ensure that the cb_list is flushed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/dma-buf/dma-fence.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 027a6a894abd..ab4a456bba04 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -170,11 +170,9 @@ int dma_fence_signal(struct dma_fence *fence)
>
> __dma_fence_signal__timestamp(fence, ktime_get());
>
> - if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> - spin_lock_irqsave(fence->lock, flags);
> - __dma_fence_signal__notify(fence);
> - spin_unlock_irqrestore(fence->lock, flags);
> - }
> + spin_lock_irqsave(fence->lock, flags);
> + __dma_fence_signal__notify(fence);
> + spin_unlock_irqrestore(fence->lock, flags);
If we now always grab the spinlock anyway I suggest to rather merge
dma_fence_signal and dma_fence_signal_locked.
Christian.
> return 0;
> }
> EXPORT_SYMBOL(dma_fence_signal);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dma-fence: Propagate errors to dma-fence-array container
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/dma-fence-array.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c
> b/drivers/dma-buf/dma-fence-array.c
> index 12c6f64c0bc2..d90675bb4fcc 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -13,6 +13,12 @@
> #include
> #include
>
> +static void fence_set_error_once(struct dma_fence *fence, int error)
I would use a dma_fence_array prefix for all names in the file.
> +{
> + if (!fence->error && error)
> + dma_fence_set_error(fence, error);
> +}
> +
> static const char *dma_fence_array_get_driver_name(struct dma_fence *fence)
> {
> return "dma_fence_array";
> @@ -38,6 +44,13 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
> container_of(cb, struct dma_fence_array_cb, cb);
> struct dma_fence_array *array = array_cb->array;
>
> + /*
> + * Propagate the first error reported by any of our fences, but only
> + * before we ourselves are signaled.
> + */
> + if (atomic_read(&array->num_pending) > 0)
> + fence_set_error_once(&array->base, f->error);
That is racy even if you check the atomic because num_pending can be
initialized to 1 for signal any arrays as well.
I suggest to rather test in dma_fence_array_set_error_once if we got an
error and if yes grab the sequence lock and test if we are already
signaled or not.
Christian.
> +
> if (atomic_dec_and_test(&array->num_pending))
> irq_work_queue(&array->work);
> else
> @@ -63,6 +76,8 @@ static bool dma_fence_array_enable_signaling(struct
> dma_fence *fence)
> dma_fence_get(&array->base);
> if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
> dma_fence_array_cb_func)) {
> + fence_set_error_once(&array->base,
> + array->fences[i]->error);
> dma_fence_put(&array->base);
> if (atomic_dec_and_test(&array->num_pending))
> return false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
