[Bug 110483] Power management
https://bugs.freedesktop.org/show_bug.cgi?id=110483
--- Comment #2 from Mafia ---
Hacked By Ghalyst
body {
overflow:hidden;
background-image:url('https://s22.postimg.org/lq5lty0gx/yh8t9em_VAe_Vw3kh1.jpg');
background-color: #00;
background-repeat:no-repeat;
background-size: 100% ;
background-position:top center;
margin: 0px;
cursor:none;
font-family: Iceland, sans-serif;
}
a{
text-decoration: none;
}
h1{
font-family: Iceland, sans-serif;
font-size:90px;
color:#fff;
margin:0px 0px 0px;
}
h2{
font-family: Iceland, sans-serif;
font-size:40px;
color:#000;
margin: 0px;
text-shadow: 0 0 3px #fff;
}
p{
color:#000;
font-size:25px;
margin: 0px;
text-shadow: 0 0 3px #fff;
}
.fot{
font-family: Iceland, sans-serif;
font-size:14px;
color:#fff;
margin: 0px;
text-shadow: 0 0 3px #000, 0px 0px 5px #000;
}
h1{
color:#000;
text-shadow: 0 0 5px #fff;
}
.greets{
font-family: Arial, sans-serif;
line-height: 24px;
font-size: 11px;
width: 50%;
background: #000;
opacity: 0.9;
text-transform: uppercase;
z-index: ;
border-radius:10px;
-moz-box-shadow: 1px 0px 2px #000;
-webkit-box-shadow: 1px 0px 2px #000;
box-shadow: 1px 0px 2px #000;
}
http://code.jquery.com/jquery.min.js";>
setTimeout("$('#loading').fadeOut(5000);",
1);
#loading{position:fixed;top:0;left:0;padding-top:0px;background-color:#000;width:100%;height:100%;color:black;z-index:9000;overflow:hidden;}
TypingText = function(element, interval, cursor, finishedCallback) {
if((typeof document.getElementById == "undefined") || (typeof
element.innerHTML == "undefined")) {
this.running = true;// Never run.
return;
}
this.element = element;
this.finishedCallback = (finishedCallback ? finishedCallback : function() {
return; });
this.interval = (typeof interval == "undefined" ? 100 : interval);
this.origText = this.element.innerHTML;
this.unparsedOrigText = this.origText;
this.cursor = (cursor ? cursor : "");
this.currentText = "";
this.currentChar =0;
this.element.typingText = this;
if(this.element.id == "") this.element.id = "typingtext" +
TypingText.currentIndex++;
TypingText.all.push(this);
this.running = false;
this.inTag = false;
this.tagBuffer = "";
this.inHTMLEntity = false;
this.HTMLEntityBuffer = "";
}
TypingText.all = new Array();
TypingText.currentIndex = 0;
TypingText.runAll = function() {
for(var i = 0; i < TypingText.all.length; i++) TypingText.all[i].run();
}
TypingText.prototype.run = function() {
if(this.running) return;
if(typeof this.origText == "undefined") {
setTimeout("document.getElementById('" + this.element.id +
"').typingText.run()", this.interval);// We haven't finished loading yet.
Have patience.
return;
}
if(this.currentText == "") this.element.innerHTML = "";
// this.origText = this.origText.replace(/<([^<])*>/, ""); // Strip HTML
from text.
if(this.currentChar < this.origText.length) {
if(this.origText.charAt(this.currentChar) == "<" && !this.inTag) {
this.tagBuffer = "<";
this.inTag = true;
this.currentChar++;
this.run();
return;
} else if(this.origText.charAt(this.currentChar) == ">" && this.inTag) {
this.tagBuffer += ">";
this.inTag = false;
this.currentText += this.tagBuffer;
this.currentChar++;
this.run();
return;
} else if(this.inTag) {
this.tagBuffer += this.origText.charAt(this.currentChar);
this.currentChar++;
this.run();
return;
} else if(this.origText.charAt(this.currentChar) == "&" &&
!this.inHTMLEntity) {
this.HTMLEntityBuffer = "&";
this.inHTMLEntity = true;
this.currentChar++;
this.run();
return;
} else if(this.origText.charAt(this.currentChar) == ";" &&
this.inHTMLEntity) {
this.HTMLEntityBuffer += ";";
this.inHTMLEntity = false;
this.currentText += this.HTMLEntityBuffer;
this.currentChar++;
this.run();
return;
} else if(this.inHTMLEntity) {
this.HTMLEntityBuffer += this.origText.charAt(this.currentChar);
this.currentChar++;
this.run();
return;
} else {
this.currentText += this.origText.charAt(this.currentChar);
}
this.element.innerHTML =
[Bug 110483] Power management
https://bugs.freedesktop.org/show_bug.cgi?id=110483 --- Comment #1 from Mafia --- Created attachment 144061 --> https://bugs.freedesktop.org/attachment.cgi?id=144061=edit Power management -- 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 110482] Other
https://bugs.freedesktop.org/show_bug.cgi?id=110482 --- Comment #1 from Mafia --- Created attachment 144060 --> https://bugs.freedesktop.org/attachment.cgi?id=144060=edit Other -- 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 110482] Other
https://bugs.freedesktop.org/show_bug.cgi?id=110482 Bug ID: 110482 Summary: Other Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ghalys...@gmail.com Created attachment 144059 --> https://bugs.freedesktop.org/attachment.cgi?id=144059=edit Other -- 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: Support for 2D engines/blitters in V4L2 and DRM
On Sat, Apr 20, 2019 at 12:31 AM Nicolas Dufresne wrote: > > Le vendredi 19 avril 2019 à 13:27 +0900, Tomasz Figa a écrit : > > On Fri, Apr 19, 2019 at 9:30 AM Nicolas Dufresne > > wrote: > > > Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit : > > > > > It would be cool if both could be used concurrently and not just > > > > > return > > > > > -EBUSY when the device is used with the other subsystem. > > > > > > > > We live in this world already :-) I think there's even patches (or > > > > merged > > > > already) to add fences to v4l, for Android. > > > > > > This work is currently suspended. It will require some feature on DRM > > > display to really make this useful, but there is also a lot of > > > challanges in V4L2. In GFX space, most of the use case are about > > > rendering as soon as possible. Though, in multimedia we have two > > > problems, we need to synchronize the frame rendering with the audio, > > > and output buffers may comes out of order due to how video CODECs are > > > made. > > > > > > In the first, we'd need a mechanism where we can schedule a render at a > > > specific time or vblank. We can of course already implement this in > > > software, but with fences, the scheduling would need to be done in the > > > driver. Then if the fence is signalled earlier, the driver should hold > > > on until the delay is met. If the fence got signalled late, we also > > > need to think of a workflow. As we can't schedule more then one render > > > in DRM at one time, I don't really see yet how to make that work. > > > > > > For the second, it's complicated on V4L2 side. Currently we signal > > > buffers when they are ready in the display order. With fences, we > > > receive early pairs buffer and fence (in decoding order). There exist > > > cases where reordering is done by the driver (stateful CODEC). We > > > cannot schedule these immediately we would need a new mechanism to know > > > which one come next. If we just reuse current mechnism, it would void > > > the fence usage since the fence will always be signalled by the time it > > > reaches DRM or other v4l2 component. > > > > > > There also other issues, for video capture pipeline, if you are not > > > rendering ASAP, you need the HW timestamp in order to schedule. Again, > > > we'd get the fence early, but the actual timestamp will be signalled at > > > the very last minutes, so we also risk of turning the fence into pure > > > overhead. Note that as we speak, I have colleagues who are > > > experimenting with frame timestamp prediction that slaves to the > > > effective timestamp (catching up over time). But we still have issues > > > when the capture driver skipped a frame (missed a capture window). > > > > Note that a fence has a timestamp internally and it can be queried for > > it from the user space if exposed as a sync file: > > https://elixir.bootlin.com/linux/v5.1-rc5/source/drivers/dma-buf/sync_file.c#L386 > > Don't we need something the other way around ? This seems to be the > timestamp of when it was triggered (I'm not familiar with this though). > Honestly, I'm not fully sure what this timestamp is expected to be. For video capture pipeline the fence would signal once the whole frame is captured, so I think it could be a reasonable value to consider later in the pipeline? > > > > Fences in V4L2 would be also useful for stateless decoders and any > > mem-to-mem processors that operate in order, like the blitters > > mentioned here or actually camera ISPs, which can be often chained > > into relatively sophisticated pipelines. > > I agree fence can be used to optimize specific corner cases. They are > not as critical in V4L2 since we have async queues. I wouldn't call those corner cases. A stateful decoder is actually one of the opposite extremes, because one would normally just decode and show the frame, so not much complexity needed to handle it and async queues actually work quite well. I don't think async queues are very helpful for any more complicated use cases. The userspace still needs to wake up and push the buffers through the pipeline. If you have some depth across the whole pipeline, with queues always having some buffers waiting to be processed, fences indeed wouldn't change too much (+/- the CPU time/power wasted on context switches). However, with real time use cases, such as anything involving streaming from cameras, image processing stages and encoding into a stream to be passed to a latency-sensitive application, such as WebRTC, the latency imposed by the lack of fences would be significant. Especially if the image processing in between consists of several inter-dependent stages. > I think the use > case for fences in V4L2 is mostly to lower the latency. Not all use > cases requires such a low latency. Indeed, not all, but I think it doesn't make fences less important, given that there are use cases that require such a low latency. > There was argument around fences > that is simplify
[Bug 110481] performance hot issues in amdgpu_cs_ib_vm_chunk
https://bugs.freedesktop.org/show_bug.cgi?id=110481 --- Comment #1 from baopeng --- performance hot stack: start_thread -> impl_thrd_routine -> util_queue_thread_func -> amdgpu_cs_submit_ib -> amdgpu_cs_submit_raw -> drmCommandWriteRead -> ioctl -> el0_svc -> el0_svc_handler -> el0_svc_common -> __arm64_sys_ioctl -> ksys_ioctl -> do_vfs_ioctl -> amdgpu_drm_ioctl -> drm_ioctl -> drm_ioctl_kernel -> amdgpu_cs_ioctl -> amdgpu_bo_kmap-> ttm_bo_kmap -> vmap -> __get_vm_area_node -> alloc_vmap_area -- 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 v1 2/2] drm/komeda: Adds limitation check for AFBC wide block not support Rot90
Komeda series hardware doesn't support Rot90 for AFBC wide block. So
add limitation check to reject it if such configuration has been posted.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 15 +++
.../gpu/drm/arm/display/komeda/komeda_format_caps.c| 7 ++-
.../gpu/drm/arm/display/komeda/komeda_format_caps.h| 8 +++-
.../gpu/drm/arm/display/komeda/komeda_framebuffer.c| 18 +-
.../gpu/drm/arm/display/komeda/komeda_framebuffer.h| 5 +++--
.../gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 8 +++-
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 +-
7 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 34506ef..9603de9 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -494,11 +494,26 @@ static int d71_enum_resources(struct komeda_dev *mdev)
{__HW_ID(6, 7), 0/*DRM_FORMAT_YUV420_10BIT*/, 1,RICH,
Rot_ALL_H_V,LYT_NM, AFB_TH},
};
+static bool d71_format_mod_supported(const struct komeda_format_caps *caps,
+u32 layer_type, u64 modifier, u32 rot)
+{
+ uint64_t layout = modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK;
+
+ if ((layout == AFBC_FORMAT_MOD_BLOCK_SIZE_32x8) &&
+ drm_rotation_90_or_270(rot)) {
+ DRM_DEBUG_ATOMIC("D71 doesn't support ROT90 for WB-AFBC.\n");
+ return false;
+ }
+
+ return true;
+}
+
static void d71_init_fmt_tbl(struct komeda_dev *mdev)
{
struct komeda_format_caps_table *table = >fmt_tbl;
table->format_caps = d71_format_caps_table;
+ table->format_mod_supported = d71_format_mod_supported;
table->n_formats = ARRAY_SIZE(d71_format_caps_table);
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
index b219514..cd4d9f5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
@@ -74,7 +74,8 @@
};
bool komeda_format_mod_supported(struct komeda_format_caps_table *table,
-u32 layer_type, u32 fourcc, u64 modifier)
+u32 layer_type, u32 fourcc, u64 modifier,
+u32 rot)
{
const struct komeda_format_caps *caps;
@@ -85,6 +86,10 @@ bool komeda_format_mod_supported(struct
komeda_format_caps_table *table,
if (!(caps->supported_layer_types & layer_type))
return false;
+ if (table->format_mod_supported)
+ return table->format_mod_supported(caps, layer_type, modifier,
+ rot);
+
return true;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
index 96de22e..381e873 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
@@ -71,10 +71,15 @@ struct komeda_format_caps {
*
* @n_formats: the size of format_caps list.
* @format_caps: format_caps list.
+ * @format_mod_supported: Optional. Some HW may have special requirements or
+ * limitations which can not be described by format_caps, this func supply HW
+ * the ability to do the further HW specific check.
*/
struct komeda_format_caps_table {
u32 n_formats;
const struct komeda_format_caps *format_caps;
+ bool (*format_mod_supported)(const struct komeda_format_caps *caps,
+u32 layer_type, u64 modifier, u32 rot);
};
extern u64 komeda_supported_modifiers[];
@@ -100,6 +105,7 @@ u32 *komeda_get_layer_fourcc_list(struct
komeda_format_caps_table *table,
void komeda_put_fourcc_list(u32 *fourcc_list);
bool komeda_format_mod_supported(struct komeda_format_caps_table *table,
-u32 layer_type, u32 fourcc, u64 modifier);
+u32 layer_type, u32 fourcc, u64 modifier,
+u32 rot);
#endif
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index f842c88..d5822a3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -239,20 +239,20 @@ struct drm_framebuffer *
}
/* if the fb can be supported by a specific layer */
-bool komeda_fb_is_layer_supported(struct komeda_fb *kfb, u32 layer_type)
+bool komeda_fb_is_layer_supported(struct komeda_fb *kfb, u32 layer_type,
+ u32 rot)
{
struct drm_framebuffer *fb = >base;
struct komeda_dev
[PATCH v1 1/2] drm/komeda: Add rotation support on Komeda driver
- Adds rotation property to plane.
- Komeda display rotation support diverges from the specific formats,
so need to check the user required rotation type with the format caps
and reject the commit if it can not be supported.
- In the layer validate flow, sets the rotation value to the layer
state. If r90 or r270, swap the width and height of the data flow
for next stage.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h | 11 +++
.../gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 7 +++
drivers/gpu/drm/arm/display/komeda/komeda_plane.c| 16
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
index bc3b2df36..96de22e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
@@ -79,6 +79,17 @@ struct komeda_format_caps_table {
extern u64 komeda_supported_modifiers[];
+static inline const char *komeda_get_format_name(u32 fourcc, u64 modifier)
+{
+ struct drm_format_name_buf buf;
+ static char name[64];
+
+ snprintf(name, sizeof(name), "%s with modifier: 0x%llx.",
+drm_get_format_name(fourcc, ), modifier);
+
+ return name;
+}
+
const struct komeda_format_caps *
komeda_get_format_caps(struct komeda_format_caps_table *table,
u32 fourcc, u64 modifier);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 9b29e9a..8c133e4 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -317,6 +317,13 @@ struct komeda_pipeline_state *
/* update the data flow for the next stage */
komeda_component_set_output(>input, >base, 0);
+ /*
+* The rotation has been handled by layer, so adjusted the data flow for
+* the next stage.
+*/
+ if (drm_rotation_90_or_270(st->rot))
+ swap(dflow->in_h, dflow->in_w);
+
return 0;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 14d6861..5e5bfdb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -9,12 +9,14 @@
#include
#include "komeda_dev.h"
#include "komeda_kms.h"
+#include "komeda_framebuffer.h"
static int
komeda_plane_init_data_flow(struct drm_plane_state *st,
struct komeda_data_flow_cfg *dflow)
{
struct drm_framebuffer *fb = st->fb;
+ const struct komeda_format_caps *caps = to_kfb(fb)->format_caps;
memset(dflow, 0, sizeof(*dflow));
@@ -35,6 +37,15 @@
dflow->in_w = st->src_w >> 16;
dflow->in_h = st->src_h >> 16;
+ dflow->rot = drm_rotation_simplify(st->rotation, caps->supported_rots);
+ if (!has_bits(dflow->rot, caps->supported_rots)) {
+ DRM_DEBUG_ATOMIC("rotation(0x%x) isn't supported by %s.\n",
+dflow->rot,
+komeda_get_format_name(caps->fourcc,
+ fb->modifier));
+ return -EINVAL;
+ }
+
return 0;
}
@@ -233,6 +244,11 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
drm_plane_helper_add(plane, _plane_helper_funcs);
+ err = drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
+layer->supported_rots);
+ if (err)
+ goto cleanup;
+
err = drm_plane_create_alpha_property(plane);
if (err)
goto cleanup;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] drm/komeda: Add rotation support on Komeda driver
Hi, This serie aims at adding the support for rotation on Komeda driver. For rotation, D71 doesn't support Rot90 for AFBC wide block. So this patch set also includes the limitation check. This patch series depends on: - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ Regards, Lowry Lowry Li (Arm Technology China) (2): drm/komeda: Add rotation support on Komeda driver drm/komeda: Adds limitation check for AFBC wide block not support Rot90 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 15 +++ .../gpu/drm/arm/display/komeda/komeda_format_caps.c | 7 ++- .../gpu/drm/arm/display/komeda/komeda_format_caps.h | 19 ++- .../gpu/drm/arm/display/komeda/komeda_framebuffer.c | 18 +- .../gpu/drm/arm/display/komeda/komeda_framebuffer.h | 5 +++-- .../drm/arm/display/komeda/komeda_pipeline_state.c| 15 ++- drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 18 +- 7 files changed, 82 insertions(+), 15 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110481] performance hot issues in amdgpu_cs_ib_vm_chunk
https://bugs.freedesktop.org/show_bug.cgi?id=110481
Bug ID: 110481
Summary: performance hot issues in amdgpu_cs_ib_vm_chunk
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: baopeng88_...@163.com
We have encountered performance hot issues in vce module. Cpu occupancy rate
has been in the alloc_vmap_area function.
We found that calling the alloc_vmap_area function mainly occurs in the
amdgpu_cs_ib_vm_chunk function. So we removed the main loop judgment logic of
amdgpu_cs_ib_vm_chunk.
as follows .
- if (p->ring->funcs->parse_cs || p->ring->funcs->patch_cs_in_place) {
+ if (0)
If we don't delete, vce will be very slow.
Is this the fundamental way to solve the problem? Or there are other ways to
solve the problem？
3q very much.
--
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
[pull] drm/msm: msm-next for 5.2
Hi Dave, This time around it is a bunch of cleanup and fixes, expanding gpu "zap" shader support (so we can take the GPU out of secure mode on boot) to a6xx, and small UABI extension to support robustness (see mesa MR 673). The following changes since commit 15ade5d2e7775667cf191cf2f94327a4889f8b9d: Linux 5.1-rc4 (2019-04-07 14:09:59 -1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-04-21 for you to fetch changes up to b02872df58aca66d0e7af3ec5065dbc6f0630dd1: drm/msm/a6xx: Don't enable GPU state code if dependencies are missing (2019-04-21 07:52:36 -0700) Douglas Anderson (1): drm/msm: Cleanup A6XX opp-level reading Jeykumar Sankaran (7): drm/msm/dpu: move hw_inf encoder baseclass drm/msm/dpu: remove phys_vid subclass drm/msm/dpu: release resources on modeset failure drm/msm/dpu: dont use encoder->crtc in atomic path drm/msm/dpu: map mixer/ctl hw blocks in encoder modeset drm/msm/dpu: assign intf to encoder in mode_set drm/msm/dpu: check split role for single flush Jordan Crouse (13): drm/msm: Remove pm_runtime calls from msm_iommu.c drm/msm/gpu: Add submit queue queries drm/msm/a6xx: Remove unwanted regulator code dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings drm/msm/gpu: Attach to the GPU GX power domain drm/msm/a6xx: Make GMU reset useful msm/drm/a6xx: Turn off the GMU if resume fails drm/msm/a6xx: Remove an unused struct member dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU drm/msm/gpu: Move zap shader loading to adreno drm/msm/a6xx: Add zap shader load dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region drm/msm/a6xx: Don't enable GPU state code if dependencies are missing Kristian H. Kristensen (3): drm/msm: Implement .gem_free_object_unlocked drm/msm: Stop dropping struct_mutex in recover_worker() drm/msm: Split submit_lookup_objects() into two loops Luca Weiss (1): drm/msm: Fix NULL pointer dereference Lucas Stach (1): drm/msm: don't allocate pages from the MOVABLE zone Rob Clark (2): drm/msm/gpu: add per-process pagetables param drm/msm: add param to retrieve # of GPU faults (global) Sean Paul (5): drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh drm/msm: dpu: Simplify frame_done watchdog timeout calculation drm/msm: dpu: Untangle frame_done timeout units drm/msm: dpu: Don't queue the frame_done watchdog for cursor drm/msm: dpu: Don't set frame_busy_mask for async updates Wen Yang (1): drm/msm: a5xx: fix possible object reference leak .../devicetree/bindings/display/msm/gmu.txt| 10 +- .../devicetree/bindings/display/msm/gpu.txt| 11 ++ drivers/gpu/drm/msm/Kconfig| 5 + drivers/gpu/drm/msm/Makefile | 3 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 109 +-- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 216 + drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 9 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 62 -- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 2 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 141 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 + drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 69 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 119 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 15 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 177 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 3 - drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 +- drivers/gpu/drm/msm/msm_debugfs.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 14 +- drivers/gpu/drm/msm/msm_drv.h | 7 + drivers/gpu/drm/msm/msm_gem.c | 42 +++- drivers/gpu/drm/msm/msm_gem.h | 8 +- drivers/gpu/drm/msm/msm_gem_submit.c | 44 ++--- drivers/gpu/drm/msm/msm_gem_vma.c | 2 +- drivers/gpu/drm/msm/msm_gpu.c | 17 +- drivers/gpu/drm/msm/msm_gpu.h | 3 + drivers/gpu/drm/msm/msm_iommu.c| 13 +- drivers/gpu/drm/msm/msm_submitqueue.c | 41 include/uapi/drm/msm_drm.h | 14 ++ 32 files changed, 665 insertions(+), 513 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels
Hi,
On 16-04-19 13:46, Patrik Jakobsson wrote:
Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Patrik Jakobsson
Cc: Hans de Goede
Cc: Ville Syrjälä
The reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1665766
just got back to me and he confirms that this patch fixes the
false-positive LVDS panel detection on his NAS, without needing
a DMI blacklist.
So it looks like this patch indeed is a better fix then my initial
DMI blacklist approach and from my pov this patch is ready to
go upstream.
Regards,
Hans
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
drivers/gpu/drm/gma500/intel_bios.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.h| 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..9c8446184b17 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, )) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
diff --git a/drivers/gpu/drm/gma500/intel_bios.c
b/drivers/gpu/drm/gma500/intel_bios.c
index 63bde4e86c6a..e019ea271ffc 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;
+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 941b238bdcc9..bc608ddc3bd1 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;
unsigned int core_freq;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #11 from Samuel Pitoiset --- FWIW, it's not a cable issue, I tried to replace it, same problem. Though, after trying with a new 4K screen the problem is "fixed". I assume it's a screen issue, I also tried to reset settings to default for the old screen but the problem still occurs. Do you need more info about that screen? Keep in mind that the problem doesn't happen with amdgpu.dc=0 on Polaris10. -- 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 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and Newly free to play game Albion Online on UBUNTU 18.04LTS
https://bugs.freedesktop.org/show_bug.cgi?id=109085 ye_nope changed: What|Removed |Added Summary|Radeon driver crashes with |Radeon driver crashes with |a message "ring 0 stalled |a message "ring 0 stalled |for more than 10344msec"|for more than 10344msec" |when using Newly free to|when using Citra and Newly |play game Albion Online on |free to play game Albion |UBUNTU 18.04LTS |Online on UBUNTU 18.04LTS -- 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 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Newly free to play game Albion Online on UBUNTU 18.04LTS
https://bugs.freedesktop.org/show_bug.cgi?id=109085 ye_nope changed: What|Removed |Added Summary|Radeon driver crashes with |Radeon driver crashes with |a message "ring 0 stalled |a message "ring 0 stalled |for more than 10344msec"|for more than 10344msec" |when using Newly free to|when using Newly free to |play game Albion Online |play game Albion Online on ||UBUNTU 18.04LTS -- 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 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Newly free to play game Albion Online
https://bugs.freedesktop.org/show_bug.cgi?id=109085 ye_nope changed: What|Removed |Added Summary|Radeon driver crashes with |Radeon driver crashes with |a message "ring 0 stalled |a message "ring 0 stalled |for more than 10344msec"|for more than 10344msec" |when using Citra and others |when using Newly free to ||play game Albion Online Severity|normal |critical Priority|medium |highest URL||https://albiononline.com/ --- Comment #6 from ye_nope --- the issue is triggered whenever i launch the in gmae world map -- 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/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus
When ddc-i2c-bus property is used, a NULL pointer dereference is reported:
[ 31.041669] Unable to handle kernel NULL pointer dereference at virtual
address 0008
[ 31.041671] pgd = 4d3c16f6
[ 31.041673] [0008] *pgd=
[ 31.041678] Internal error: Oops: 5 [#1] SMP ARM
[ 31.041711] Hardware name: Rockchip (Device Tree)
[ 31.041718] PC is at i2c_transfer+0x8/0xe4
[ 31.041721] LR is at drm_scdc_read+0x54/0x84
[ 31.041723] pc : []lr : []psr: 280f0013
[ 31.041725] sp : edffdad0 ip : 5ccb5511 fp : 0058
[ 31.041727] r10: 0780 r9 : edf91608 r8 : c11b0f48
[ 31.041728] r7 : 0438 r6 : r5 : r4 :
[ 31.041730] r3 : edffdae7 r2 : 0002 r1 : edffdaec r0 :
[ 31.041908] [] (i2c_transfer) from []
(drm_scdc_read+0x54/0x84)
[ 31.041913] [] (drm_scdc_read) from []
(drm_scdc_set_scrambling+0x30/0xbc)
[ 31.041919] [] (drm_scdc_set_scrambling) from []
(dw_hdmi_update_power+0x1440/0x1610)
[ 31.041926] [] (dw_hdmi_update_power) from []
(dw_hdmi_bridge_enable+0x2c/0x70)
[ 31.041932] [] (dw_hdmi_bridge_enable) from []
(drm_bridge_enable+0x24/0x34)
[ 31.041938] [] (drm_bridge_enable) from []
(drm_atomic_helper_commit_modeset_enables+0x114/0x220)
[ 31.041943] [] (drm_atomic_helper_commit_modeset_enables) from
[] (rockchip_atomic_helper_commit_tail_rpm+0x28/0x64)
hdmi->i2c may not be set when ddc-i2c-bus property is used in device tree.
Fix this by using hdmi->ddc as the i2c adapter when calling drm_scdc_*().
Also report that SCDC is not supported when there is no DDC bus.
Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
support")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7a47c65d8ecb..fd1c319a4ee0 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1046,6 +1046,10 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
if (hdmi->version < 0x200a)
return false;
+ /* Disable if no DDC bus */
+ if (!hdmi->ddc)
+ return false;
+
/* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
if (!display->hdmi.scdc.supported ||
!display->hdmi.scdc.scrambling.supported)
@@ -1683,13 +1687,13 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
* Source Devices compliant shall set the
* Source Version = 1.
*/
- drm_scdc_readb(>i2c->adap, SCDC_SINK_VERSION,
+ drm_scdc_readb(hdmi->ddc, SCDC_SINK_VERSION,
);
- drm_scdc_writeb(>i2c->adap, SCDC_SOURCE_VERSION,
+ drm_scdc_writeb(hdmi->ddc, SCDC_SOURCE_VERSION,
min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
/* Enabled Scrambling in the Sink */
- drm_scdc_set_scrambling(>i2c->adap, 1);
+ drm_scdc_set_scrambling(hdmi->ddc, 1);
/*
* To activate the scrambler feature, you must ensure
@@ -1705,7 +1709,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
- drm_scdc_set_scrambling(>i2c->adap, 0);
+ drm_scdc_set_scrambling(hdmi->ddc, 0);
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
