[PATCH 1/3] drm/komeda: Add drm_lut_to_fgamma_coeffs()
This function is used to convert drm 3dlut to komeda HW required 1d curve
coeffs values.
Signed-off-by: james qian wang (Arm Technology China)
---
.../arm/display/komeda/komeda_color_mgmt.c| 52 +++
.../arm/display/komeda/komeda_color_mgmt.h| 9 +++-
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
index 9d14a92dbb17..c180ce70c26c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
@@ -65,3 +65,55 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding,
u32 color_range)
return coeffs;
}
+
+struct gamma_curve_sector {
+ u32 boundary_start;
+ u32 num_of_segments;
+ u32 segment_width;
+};
+
+struct gamma_curve_segment {
+ u32 start;
+ u32 end;
+};
+
+static struct gamma_curve_sector sector_tbl[] = {
+ { 0,4, 4 },
+ { 16, 4, 4 },
+ { 32, 4, 8 },
+ { 64, 4, 16 },
+ { 128, 4, 32 },
+ { 256, 4, 64 },
+ { 512, 16, 32 },
+ { 1024, 24, 128 },
+};
+
+static void
+drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
+ struct gamma_curve_sector *sector_tbl, u32 num_sectors)
+{
+ struct drm_color_lut *lut;
+ u32 i, j, in, num = 0;
+
+ if (!lut_blob)
+ return;
+
+ lut = lut_blob->data;
+
+ for (i = 0; i < num_sectors; i++) {
+ for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
+ in = sector_tbl[i].boundary_start +
+j * sector_tbl[i].segment_width;
+
+ coeffs[num++] = drm_color_lut_extract(lut[in].red,
+ KOMEDA_COLOR_PRECISION);
+ }
+ }
+
+ coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
+}
+
+void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs)
+{
+ drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
index a2df218f58e7..08ab69281648 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
@@ -11,7 +11,14 @@
#include
#define KOMEDA_N_YUV2RGB_COEFFS12
+#define KOMEDA_N_RGB2YUV_COEFFS12
+#define KOMEDA_COLOR_PRECISION 12
+#define KOMEDA_N_GAMMA_COEFFS 65
+#define KOMEDA_COLOR_LUT_SIZE BIT(KOMEDA_COLOR_PRECISION)
+#define KOMEDA_N_CTM_COEFFS9
+
+void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs);
const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
-#endif
+#endif /*_KOMEDA_COLOR_MGMT_H_*/
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/komeda: Add drm_ctm_to_coeffs()
This function is used to convert drm_color_ctm S31.32 sign-magnitude
value to komeda required Q2.12 2's complement
Signed-off-by: james qian wang (Arm Technology China)
---
.../arm/display/komeda/komeda_color_mgmt.c| 27 +++
.../arm/display/komeda/komeda_color_mgmt.h| 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
index c180ce70c26c..c92c82eebddb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
@@ -117,3 +117,30 @@ void drm_lut_to_fgamma_coeffs(struct drm_property_blob
*lut_blob, u32 *coeffs)
{
drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
}
+
+/* Convert from S31.32 sign-magnitude to HW Q2.12 2's complement */
+static s32 drm_ctm_s31_32_to_q2_12(u64 input)
+{
+ u64 mag = (input & ~BIT_ULL(63)) >> 20;
+ bool negative = !!(input & BIT_ULL(63));
+ u32 val;
+
+ /* the range of signed 2s complement is [-2^n, 2^n - 1] */
+ val = clamp_val(mag, 0, negative ? BIT(14) : BIT(14) - 1);
+
+ return negative ? 0 - val : val;
+}
+
+void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
+{
+ struct drm_color_ctm *ctm;
+ u32 i;
+
+ if (!ctm_blob)
+ return;
+
+ ctm = ctm_blob->data;
+
+ for (i = 0; i < KOMEDA_N_CTM_COEFFS; i++)
+ coeffs[i] = drm_ctm_s31_32_to_q2_12(ctm->matrix[i]);
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
index 08ab69281648..2f4668466112 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
@@ -18,6 +18,7 @@
#define KOMEDA_N_CTM_COEFFS9
void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs);
+void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs);
const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/komeda: Adds gamma and color-transform support for DOU-IPS
From: "Lowry Li (Arm Technology China)"
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 24 +++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
.../display/komeda/komeda_pipeline_state.c| 6 +
4 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index c3d29c0b051b..e7e5a8e4430e 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
static void d71_improc_update(struct komeda_component *c,
struct komeda_component_state *state)
{
+ struct drm_crtc_state *crtc_st = state->crtc->state;
struct komeda_improc_state *st = to_improc_st(state);
+ struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
u32 __iomem *reg = c->reg;
u32 index;
+ u32 mask = 0, ctrl = 0;
for_each_changed_input(state, index)
malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
to_d71_input_id(state, index));
malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+
+ if (crtc_st->color_mgmt_changed) {
+ mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
+
+ if (crtc_st->gamma_lut) {
+ malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
+ KOMEDA_N_GAMMA_COEFFS,
+ st->fgamma_coeffs);
+ ctrl |= IPS_CTRL_FT; /* enable gamma */
+ }
+
+ if (crtc_st->ctm) {
+ malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
+ KOMEDA_N_CTM_COEFFS,
+ st->ctm_coeffs);
+ ctrl |= IPS_CTRL_RGB; /* enable gamut */
+ }
+ }
+
+ if (mask)
+ malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
}
static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 9ca5dbfd0723..33f7362dcc6e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -588,6 +588,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
crtc->port = kcrtc->master->of_output_port;
+ drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
+
return err;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 8401cc0cdfe7..21a50e8ce0b7 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -11,6 +11,7 @@
#include
#include
#include "malidp_utils.h"
+#include "komeda_color_mgmt.h"
#define KOMEDA_MAX_PIPELINES 2
#define KOMEDA_PIPELINE_MAX_LAYERS 4
@@ -324,6 +325,8 @@ struct komeda_improc {
struct komeda_improc_state {
struct komeda_component_state base;
u16 hsize, vsize;
+ u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
+ u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
};
/* display timing controller */
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 0ba9c6aa3708..4a40b37eb1a6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
st->hsize = dflow->in_w;
st->vsize = dflow->in_h;
+ if (kcrtc_st->base.color_mgmt_changed) {
+ drm_lut_to_fgamma_coeffs(kcrtc_st->base.gamma_lut,
+st->fgamma_coeffs);
+ drm_ctm_to_coeffs(kcrtc_st->base.ctm, st->ctm_coeffs);
+ }
+
komeda_component_add_input(>base, >input, 0);
komeda_component_set_output(>input, >base, 0);
--
2.20.1
[PATCH 0/3] drm/komeda: Enable CRTC color-mgmt
This series enable CRTC color-mgmt for komeda driver, for current komeda HW which only supports color conversion and forward gamma for CRTC. This series actually are regrouped from: - drm/komeda: Enable layer/plane color-mgmt: https://patchwork.freedesktop.org/series/60893/ - drm/komeda: Enable CRTC color-mgmt https://patchwork.freedesktop.org/series/61370/ For removing the dependence on: - https://patchwork.freedesktop.org/series/30876/ Lowry Li (Arm Technology China) (1): drm/komeda: Adds gamma and color-transform support for DOU-IPS james qian wang (Arm Technology China) (2): drm/komeda: Add drm_lut_to_fgamma_coeffs() drm/komeda: Add drm_ctm_to_coeffs() .../arm/display/komeda/d71/d71_component.c| 24 ++ .../arm/display/komeda/komeda_color_mgmt.c| 79 +++ .../arm/display/komeda/komeda_color_mgmt.h| 10 ++- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 + .../drm/arm/display/komeda/komeda_pipeline.h | 3 + .../display/komeda/komeda_pipeline_state.c| 6 ++ 6 files changed, 123 insertions(+), 1 deletion(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: sii902x: Variable status in sii902x_connector_detect() could be uninitialized if regmap_read() fails
In function sii902x_connector_detect(), variable "status" could be
initialized if regmap_read() fails. However, "status" is used to
decide the return value, which is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/drm/bridge/sii902x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 38f75ac580df..afce64f51ff2 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -246,7 +246,7 @@ static enum drm_connector_status
sii902x_connector_detect(struct drm_connector *connector, bool force)
{
struct sii902x *sii902x = connector_to_sii902x(connector);
- unsigned int status;
+ unsigned int status = 0;
mutex_lock(>mutex);
--
2.17.1
[PATCH] Staging: fbtft: fix memory leak in fbtft_framebuffer_alloc
In fbtft_framebuffer_alloc the error handling path should take care of
releasing frame buffer after it is allocated via framebuffer_alloc, too.
Therefore, in two failure cases the goto destination is changed to
address this issue.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Navid Emamdoost
---
drivers/staging/fbtft/fbtft-core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index cf5700a2ea66..a0a67aa517f0 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -714,7 +714,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct
fbtft_display *display,
if (par->gamma.curves && gamma) {
if (fbtft_gamma_parse_str(par, par->gamma.curves, gamma,
strlen(gamma)))
- goto alloc_fail;
+ goto release_framebuf;
}
/* Transmit buffer */
@@ -731,7 +731,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct
fbtft_display *display,
if (txbuflen > 0) {
txbuf = devm_kzalloc(par->info->device, txbuflen, GFP_KERNEL);
if (!txbuf)
- goto alloc_fail;
+ goto release_framebuf;
par->txbuf.buf = txbuf;
par->txbuf.len = txbuflen;
}
@@ -753,6 +753,9 @@ struct fb_info *fbtft_framebuffer_alloc(struct
fbtft_display *display,
return info;
+release_framebuf:
+ framebuffer_release(info);
+
alloc_fail:
vfree(vmem);
--
2.17.1
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #61 from jamespharve...@gmail.com --- It might look like I'm just ranting. That's not the reason I posted my comment. I'm trying to give feedback to AMD about how bad so many customer experiences are right now, and have been for quite some time, and how there should be easy and affordable (for AMD) ways to make it better. -- 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 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #60 from jamespharve...@gmail.com --- (In reply to Sergey Kondakov from comment #59) > > And how about instead of knowingly pushing untested code with known fatal > errors you stop taking QA notes from FGLRX in the first place and do your > own full testing ? You do realize that I, as all others, paid for that card > to your employer, right ? And people don't buy your top cards, > RX[4-5][7-8]0, VEGAs and so on, to use them as expensive bare output > controllers. This. If this were just a free project with volunteers giving their time, many of us who occasionally throw a tantrum towards AMD wouldn't be. But, some of us are throwing money at AMD to try to have a stable system again, and keep getting regressions introduced that are either fixed very slowly, or not at all. I'm here, because I was running an R9 390, and kernel 4.19 introduced a regression that causes a complete boot failure. Others confirmed the same. See https://bugs.freedesktop.org/show_bug.cgi?id=108781 (As I explain way below, this is still unfixed in 5.3.) On that bug, I'm asked by an amd.com developer to bisect. I run into hundreds, or even a thousand, commits that don't even compile, and only a later commit fixes that issue. Fun, thanks for pushing those, guys. I finally achieve a bisected commit, where 0d9988910989 causes a boot hang and the one previous to it doesn't. Upon being told this shouldn't have to do with the bug I've posted, I do discover that this bug causes a black screen boot hang, but it's a different bug! I then go on to document that I've found between 3 and 5 crashing commits in the new 4.19 commits. So, how am I supposed to bisect this garbage, when a lot doesn't even compile, and there are multiple bugs popping in and out of existence causing the same symptom? Boot crashes with black screen, and I'm supposed to know to mark that commit as good because it's a different bug causing the same issue? I ask the AMD devs to tell me exactly which card they use in testing (if any, at all) so I can just buy that and be done with this. No response. So, I pay AMD more money and buy a RX 580, which is mostly a downgrade from the R9 390. Get frequent crashes from that as well. So, I just decide to buy a Vega 64. I don't need the extra power, I just want to run a stable machine. Since AMD devs aren't saying what card I could use that they do, in a hope that they might fix crashes before they push them, I figure the latest and greatest might be getting more attention. All goes well until this regression is introduced. I go back to try my R9 390, and guess what? The same bug introduced in kernel 4.19 is still there in 5.3! AMD's just ignored it, and hasn't bothered to try to reproduce it themselves and try to untangle the mess of spaghetti. Since running a custom kernel with the patchset, I haven't had this crash, but come on guys! Couldn't AMD have a bank of 50 computers running different cards, constantly running the latest unpushed code and going through different stress tests? Hey, Jim, monitor #14 and #36 keep crashing, let's look into it. -- 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 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #59 from Sergey Kondakov (virtuous...@gmail.com) --- (In reply to Andrey Grodzovsky from comment #57) > Sergey, instead of throwing tantrums why can't you just do what you are > asked ? You present an extremely convoluted set of driver config params and > demand from us resolving the bug with those parameters in place. This > introduces unneeded complication of the failure scenario which in turn > introduces a lot of unknowns. Alex asks you to simplify the settings so less > unknows are in the system so it's easier for us to try and figure out what > goes wrong while we inspect the code. > So please, bring the parameters back to default as this is the most well > tested configuration and gives a baseline and also please provide addr2line > for 0010:amdgpu_dm_atomic_commit_tail+0x2ee so we can get a better idea > where in code the NULL ptr happened. And how about instead of knowingly pushing untested code with known fatal errors you stop taking QA notes from FGLRX in the first place and do your own full testing ? You do realize that I, as all others, paid for that card to your employer, right ? And people don't buy your top cards, RX[4-5][7-8]0, VEGAs and so on, to use them as expensive bare output controllers. DO NOT SHOOT THE MESSENGER. What you ignore from me, others will get one way or another, most of which would be incapable to even report it and just resort to cursing you and sell the hardware, going on Nvidia & Intel combo forever instead. Do you have any idea how many times in my life I've heard "at least it's without hassle" spiel about all (yes, all) AMD stuff from "normal people" ? I don't demand from you resolving this personally for me and whatever I might configure. But I do demand you not pushing untested code, hide it under parameters that limit all cards to bare minimum and then use it as an excuse to continue not to test it. And then silently expect me to work as your QA as if I trained on how to debug kernel-level code and telepathically know what might be on your minds. What else, should I be expected to whip out chip programmer and write custom asm-code for your mystery chips by myself ? I don't have a laboratory or a dedicated debug station. _Regarding this notion of "testing on defaults"_. Maybe I was not clear on that: that #3 dereference happened just once after about a full day of uptime. The machine sometime was running for more than a week straight without issues. So, defaulting will not show any difference on my end unless I run both configs no less than 2 weeks of pure uptime each without shutting down the machine. And it still be useless guesswork which will not produce any more pointers on what exactly goes wrong, at best it just will repeat or not. However, you as a developers of that code and a trained experts, can use that little data there is to recheck exact offending code about no one else have a clue about. You also can fully reproduce my configuration (including exact packages of my kernel with debug-info) and work with full data of your own, since you not willing to test all your codepaths regularly as a rule. I will try to figure out what the hell this "addr2line" is but it will probably include installing gigabytes of debug-symbols on SSD that has no space for them, so… it will take a while. But the way, what happened with my answer about #2 ? You know, the `list *(amdgpu_vm_update_directories+0xe7)` part, which was real time-consuming pain to get, with: 0x2e127 is in amdgpu_vm_update_directories (../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1191). where line #1191 is: struct amdgpu_bo *bo = parent->base.bo, *pbo; Have you even seen it ? Was it the right thing ? Any thoughts on the cause for this one ? Should I do the same for the #3 ? Will it also go into a void of silence ? (In reply to Damian Nowak from comment #58) > I encounter this error once a week on average on my Radeon 7 (Vega 20). > Great on see you guys actively working on it. When 5.3.2 releases to Arch, > I'll keep using it for a week or two and report back whether I encounter an > issue again or not. Thanks! > > @Sergey You could revert to defaults just for the duration of > testing/debugging. It'll sure make things easier for developers, and you can > still go back to your settings once the issue is fixed. Great settings > nonetheless, do these kernel parameters really improve the power performance > of RX 580, or did you need to do something in addition too? By the way, I > used RX 580 on default Arch Linux settings (so most likely kernel defaults) > for a year and it was fine so you probably don't have to worry about frying > it. Now I'm using Radeon 7, while RX 580 is still alive in a different > Windows-based computer. Ok, I can. But what's next ? How exactly does that would give any more data ? What exactly should I do after booting the machine ? Power ? No, the custom hacked GPU BIOS does. Although, after fiddling
Re: X11 + console switch - how does it actually work ?
> Hello folks, > > > could anybody please give me some more insight, how switching > from X to console (ctrl+alt+f*) actually works ? > > Who catches the keypress event and initiates the VT switch ? > The Xserver ? Could this be done in the kernel (eg. when Xserver > is hanging) ? The X server is in full control of it all. No the kernel can't do it, SAK might work (secure-attention key) using sysrq but it probably will just end up with a more confused system. Dave. > > > --mtx > > -- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ion_system_heap: support X86 archtecture
On 9/29/19 3:28 AM, jun.zh...@intel.com wrote:
From: zhang jun
we see tons of warning like:
[ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back
[ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
write-combining for [mem 0x1e7a58000-0x1e7a58fff], got write-back
[ 45.848875] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a48000-0x1e7a4], got write-back
[ 45.849403] x86/PAT: .vorbis.decoder:4088 map pfn RAM range
req write-combining for [mem 0x1e7a7-0x1e7a70fff], got write-back
check the kernel Documentation/x86/pat.txt, it says:
A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
vm_insert_pfn
Drivers wanting to export some pages to userspace do it by using
mmap interface and a combination of
1) pgprot_noncached()
2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()
With PAT support, a new API pgprot_writecombine is being added.
So, drivers can continue to use the above sequence, with either
pgprot_noncached() or pgprot_writecombine() in step 1, followed by step 2.
In addition, step 2 internally tracks the region as UC or WC in
memtype list in order to ensure no conflicting mapping.
Note that this set of APIs only works with IO (non RAM) regions.
If driver ants to export a RAM region, it has to do set_memory_uc() or
set_memory_wc() as step 0 above and also track the usage of those pages
and use set_memory_wb() before the page is freed to free pool.
the fix follow the pat document, do set_memory_wc() as step 0 and
use the set_memory_wb() before the page is freed.
All this work needs to be done on the new dma-buf heap rework and I
don't think it makes sense to put it on the staging version
https://lore.kernel.org/lkml/20190906184712.91980-1-john.stu...@linaro.org/
(I also continue to question the value of uncached buffers, especially on
x86)
Signed-off-by: he, bo
Signed-off-by: zhang jun
Signed-off-by: Bai, Jie A
---
drivers/staging/android/ion/ion_system_heap.c | 28 ++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b83a1d16bd89..d298b8194820 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "ion.h"
@@ -134,6 +135,13 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
sg = table->sgl;
list_for_each_entry_safe(page, tmp_page, , lru) {
sg_set_page(sg, page, page_size(page), 0);
+
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wc((unsigned long)page_address(sg_page(sg)),
+ PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
+#endif
+
sg = sg_next(sg);
list_del(>lru);
}
@@ -162,8 +170,15 @@ static void ion_system_heap_free(struct ion_buffer *buffer)
if (!(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
ion_heap_buffer_zero(buffer);
- for_each_sg(table->sgl, sg, table->nents, i)
+ for_each_sg(table->sgl, sg, table->nents, i) {
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wb((unsigned long)page_address(sg_page(sg)),
+ PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
+#endif
+
free_buffer_page(sys_heap, buffer, sg_page(sg));
+ }
sg_free_table(table);
kfree(table);
}
@@ -316,6 +331,12 @@ static int ion_system_contig_heap_allocate(struct ion_heap
*heap,
buffer->sg_table = table;
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wc((unsigned long)page_address(page),
+ PAGE_ALIGN(len) >> PAGE_SHIFT);
+#endif
+
return 0;
free_table:
@@ -334,6 +355,11 @@ static void ion_system_contig_heap_free(struct ion_buffer
*buffer)
unsigned long pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
unsigned long i;
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wb((unsigned long)page_address(page), pages);
+#endif
+
for (i = 0; i < pages; i++)
__free_page(page + i);
sg_free_table(table);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4] drm: two planes with the same zpos have undefined ordering
Hi, > On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote: > > Currently the property docs don't specify whether it's okay for two planes > > to > > have the same zpos value and what user-space should expect in this case. > > > > The rule mentionned in the past was to disambiguate with object IDs. However > > some drivers break this rule (that's why the ordering is documented as > > unspecified in case the zpos property is missing). Additionally it doesn't > > really make sense for a driver to user identical zpos values if it knows > > their > > relative position: the driver can just pick different values instead. > > > > So two solutions would make sense: either disallow completely identical zpos > > values for two different planes, either make the ordering unspecified. To > > allow > > drivers that don't know the relative ordering between two planes to still > > expose the zpos property, choose the latter solution. > > Some Arm's usage cases about two planes with same zpos. > > - "Smart layer" > which can accepts 4 different fbs with different src/display rect, > but this smart layer has one restriction: > > 4 display rects must have no overlaps in V direction > (A optimization for android window like Toolbar/Navigation bar) > > So when map this Smart-layer to drm world, it might be 4 different > drm-planes, but with same zorder to indicate that these 4 planes are > smart-laye planes. > > - "VR-Layer" > One VR-layer comprises two different viewports which can be configured > with totoally different fbs, src/display rect. > we use two differernt drm-planes to drive on HW "VR-Layer", and these > two drm-planes must be configured with same zpos. Thanks a lot for your feedback James, that's exactly what I was looking for. Both of these use-cases make sense to me. I think user-space should be prepared to handle identical immutable zpos values. Pekka and Daniel, thoughts? In any case, this doesn't change the patch itself. Probably something worth mentionning in the commit message. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: fix multiple memory leaks
> v2: moved the released into goto error handlings A better version comment should be moved below the triple dashes. Will the tag “Fixes” be added? > @@ -393,6 +395,16 @@ static int acp_hw_init(void *handle) > val &= ~ACP_SOFT_RESET__SoftResetAud_MASK; > cgs_write_register(adev->acp.cgs_device, mmACP_SOFT_RESET, val); > return 0; > + > +out4: > + kfree(i2s_pdata); > +out3: > + kfree(adev->acp.acp_res); > +out2: > + kfree(adev->acp.acp_cell); > +out1: > + kfree(adev->acp.acp_genpd); > + return ret; > } > > /** I suggest to reconsider the label selection according to the Linux coding style. Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
Hi Alex,
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, September 24, 2019 6:07 PM
> To: Jason Wang
> Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; m...@redhat.com; tiwei@intel.com;
> virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; christophe.de.dinec...@gmail.com;
> kevin.t...@intel.com
> Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
>
> On Tue, 24 Sep 2019 21:53:30 +0800
> Jason Wang wrote:
>
> > This patch implements basic support for mdev driver that supports
> > virtio transport for kernel virtio driver.
> >
> > Signed-off-by: Jason Wang
> > ---
> > include/linux/mdev.h| 2 +
> > include/linux/virtio_mdev.h | 145
> >
> > 2 files changed, 147 insertions(+)
> > create mode 100644 include/linux/virtio_mdev.h
> >
> > diff --git a/include/linux/mdev.h b/include/linux/mdev.h index
> > 3414307311f1..73ac27b3b868 100644
> > --- a/include/linux/mdev.h
> > +++ b/include/linux/mdev.h
> > @@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device
> > *dev);
> >
> > enum {
> > MDEV_ID_VFIO = 1,
> > + MDEV_ID_VIRTIO = 2,
> > + MDEV_ID_VHOST = 3,
>
> MDEV_ID_VHOST isn't used yet here. Also, given the strong interdependence
> between the class_id and the ops structure, we might wand to define them in
> the same place. Thanks,
>
When mlx5_core creates mdevs (parent->ops->create() and it wants to bind to
mlx5 mdev driver (which does mdev_register_driver()),
mlx5 core driver will publish MDEV_ID_MLX5_NET defined in central place as
include/linux/mdev.h without any ops structure.
Because such ops are not relevant. It uses usual, standard ops probe() remove()
on the mdev (similar to a regular PCI device).
So for VHOST case ops may be closely related to ID, but not for other type of
ID.
Just want to make sure, that scope of ID covers this case.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/amdgpu: remove set but not used variable 'pipe'
Fixes gcc '-Wunused-but-set-variable' warning:
rivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c: In function
‘amdgpu_gfx_graphics_queue_acquire’:
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:234:16: warning:
variable ‘pipe’ set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Reported-by: Hulk Robot
Signed-off-by: yu kuai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index f9bef31..c1035a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -231,12 +231,10 @@ void amdgpu_gfx_compute_queue_acquire(struct
amdgpu_device *adev)
void amdgpu_gfx_graphics_queue_acquire(struct amdgpu_device *adev)
{
- int i, queue, pipe, me;
+ int i, queue, me;
for (i = 0; i < AMDGPU_MAX_GFX_QUEUES; ++i) {
queue = i % adev->gfx.me.num_queue_per_pipe;
- pipe = (i / adev->gfx.me.num_queue_per_pipe)
- % adev->gfx.me.num_pipe_per_me;
me = (i / adev->gfx.me.num_queue_per_pipe)
/ adev->gfx.me.num_pipe_per_me;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: amd: amdgpu: Remove call to memset after dma_alloc_coherent
dma_alloc_coherent has already zeroed the memory. So memset is not needed. Signed-off-by: Saurav Girepunje --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c index 6d8f05511aba..111a301ce878 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c @@ -66,7 +66,6 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih, if (ih->ring == NULL) return -ENOMEM; - memset((void *)ih->ring, 0, ih->ring_size + 8); ih->gpu_addr = dma_addr; ih->wptr_addr = dma_addr + ih->ring_size; ih->wptr_cpu = >ring[ih->ring_size / 4]; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
X11 + console switch - how does it actually work ?
Hello folks, could anybody please give me some more insight, how switching from X to console (ctrl+alt+f*) actually works ? Who catches the keypress event and initiates the VT switch ? The Xserver ? Could this be done in the kernel (eg. when Xserver is hanging) ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ 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 #151 from line...@xcpp.org --- Created attachment 145583 --> https://bugs.freedesktop.org/attachment.cgi?id=145583=edit 5.3.1 patched, xorg crash And here is a dmesg of just an X session crashing -- 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 line...@xcpp.org changed: What|Removed |Added Attachment #145581|0 |1 is obsolete|| --- Comment #150 from line...@xcpp.org --- Created attachment 145582 --> https://bugs.freedesktop.org/attachment.cgi?id=145582=edit 5.3.1 patched, wayland crash Sorry, the file got messed up, here is the wayland crash -- 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 line...@xcpp.org changed: What|Removed |Added CC||line...@xcpp.org --- Comment #149 from line...@xcpp.org --- Created attachment 145581 --> https://bugs.freedesktop.org/attachment.cgi?id=145581=edit 5.3.1 plus Alex's patches, kde wayland crash, then kde xorg crash This issue is not fixed for me with Alex's patches. I use only a single monitor via DP. Running a patched 5.3.1 kernel. Attached is a dmesg log: First a wayland KDE session crashes, I kill all user processes and restart sddm and start a KDE Xorg session, which later also crashes. -- 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 111747] [CI][DRMTIP] igt@ - incomplete - Jenkins gives up
https://bugs.freedesktop.org/show_bug.cgi?id=111747
--- Comment #13 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- TGL: igt@* -incomplete - Abort requested by .* terminating children -}
{+ TGL: igt@* -incomplete - Abort requested by .* terminating children +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_380/fi-tgl-u2/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html
--
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 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 Damian Nowak (s...@nowaker.net) changed: What|Removed |Added CC||s...@nowaker.net --- Comment #58 from Damian Nowak (s...@nowaker.net) --- I encounter this error once a week on average on my Radeon 7 (Vega 20). Great on see you guys actively working on it. When 5.3.2 releases to Arch, I'll keep using it for a week or two and report back whether I encounter an issue again or not. Thanks! @Sergey You could revert to defaults just for the duration of testing/debugging. It'll sure make things easier for developers, and you can still go back to your settings once the issue is fixed. Great settings nonetheless, do these kernel parameters really improve the power performance of RX 580, or did you need to do something in addition too? By the way, I used RX 580 on default Arch Linux settings (so most likely kernel defaults) for a year and it was fine so you probably don't have to worry about frying it. Now I'm using Radeon 7, while RX 580 is still alive in a different Windows-based computer. -- 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 111747] [CI][DRMTIP] igt@ - incomplete - Jenkins gives up
https://bugs.freedesktop.org/show_bug.cgi?id=111747
--- Comment #12 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- TGL: igt@* -incomplete - Abort requested by .* terminating children -}
{+ TGL: igt@* -incomplete - Abort requested by .* terminating children +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-tglb4/igt@kms_rotation_...@primary-x-tiled-reflect-x-180.html
--
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: imx6: hdmi black screen issue after resume
>
> On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal wrote:
> >
> > Dear Philipp,
> >
> > I have a iMX6dl custom board with custom Linux Kernel 4.8.
> > I have both LCD and HDMI connected to the board.
> > And we are using weston/wayland as the display interface.
> > In normal boot, both LCD and HDMI display is working fine.
> >
> > But, currently, for one of the requirement, I am trying to explore and
> > support hibernation image booting on it.
> > Currently, we are able to resume the system without display.
> > Also, if we make the entire imx-drm as modules, and then install the
> > modules after resume, even LCD is also coming up.
> > But HDMI display is black out.
> >
> > After, resume, when I try to launch the weston, I noticed the following
> > errors:
> > enabling vblank on crtc 0, ret: 0
> > drm_vblank_get: CALLED: vblank->refcount: 1
> > [ cut here ]
> > WARNING: at drivers/gpu/drm/drm_atomic_helper.c:1121
> > drm_atomic_helper_wait_for_vblanks+0x228/0x24c [drm_kms_helper]()
> > [CRTC:24] vblank wait timed out
> > .
> > [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
> > [CRTC:24:crtc-0] flip_done timed out
> >
> >
> > [00:06:42.600] Warning: computed repaint delay is insane: -5069 msec
> > [00:06:42.665] unexpectedly large timestamp jump (from 397522 to 402648)
> >
> >
> > And, when I try to reboot the system, the system does not reboot.
> > And I get the following error:
> > /wayland # reboot
> >
> > [17:55:01.180] destroy output while page flip pending
> > ...
> > imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> >
> >
> > -
> > If you have any clue about this issue, please let me know.
> >
> > Any help will be really appreciated!
> >
> >
> > Thank You!
> >
> > Regards,
> > Pintu
Hi All,
I need some help, on the above issue.
Finally, I could boil down the issue to be vblank refcount issue.
After system resume, vblank ref count is getting screwed up, because
of which vblank_enable is not happening.
As per below code path: drivers/gpu/drm/drm_vblank.c:
drm_vblank_get()
{
[...]
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, >refcount) == 1) {
ret = drm_vblank_enable(dev, pipe);
} else {
if (!vblank->enabled) {
atomic_dec(>refcount);
ret = -EINVAL;
}
}
[...]
First time, everything seems fine.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 0, vblank-enabled: 0
..
drm_vblank_enable: calling - enable_vblank
enabling vblank on crtc 0, ret: 0
...
But, after resume, somewhere during HDMI initialization, the refcount
is getting incremented.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 1, vblank-enabled: 1
Thus, due to the above logic, drm_vblank_enable() will not be called,
if previous refcount is not 0.
What I further noticed is that, after resume, during hdmi_setup the
refcount is automatically getting updated.
drm_update_vblank_count - storing vblank count: diff: 1
This does not happen in normal case.
Now, I am not sure, why the vblank counter is getting incremented
during hdmi setup.
Is it like, hdmi setup is taking slightly longer time for
initialization, after resume??
Because of which the vblank timestamp counter is getting disturbed.
If anybody observed this issue, or aware about the fixes, please let me know.
It will be of great help.
Meanwhile, I am further continue to debug this more..
Regards,
Pintu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
kernel warning related to i915 code
Dear all, (please Cc) linux 5.3.1 Debian/sid Lenovo X260 [2.472152] i915 :00:02.0: vgaarb: deactivate vga console [2.473035] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.473037] [drm] Driver supports precise vblank timestamp query. [2.473431] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.474796] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27) [2.497068] [drm] Initialized i915 1.6.0 20190619 for :00:02.0 on minor 0 [2.499469] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [2.500011] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 [2.697843] fbcon: i915drmfb (fb0) is primary device [2.711468] Console: switching to colour frame buffer device 240x67 [2.732932] i915 :00:02.0: fb0: i915drmfb frame buffer device I am seeing kernel warnings in flushqueue: [ 6180.832664] workqueue: PF_MEMALLOC task 117(kswapd0) is flushing !WQ_MEM_RECLAIM events:gen6_pm_rps_work [i915] [ 6180.832670] WARNING: CPU: 2 PID: 117 at check_flush_dependency+0xa0/0x130 [ 6180.832671] Modules linked in: hid_generic(E) usbhid(E) hid(E) xt_MASQUERADE(E) nf_conntrack_netlink(E) xfrm_user(E) xfrm_algo( E) xt_addrtype(E) xt_conntrack(E) br_netfilter(E) pci_stub(E) vboxpci(OE) vboxnetadp(OE) l2tp_ppp(E) l2tp_netlink(E) vboxnetflt(OE ) l2tp_core(E) ip6_udp_tunnel(E) udp_tunnel(E) pppox(E) ppp_generic(E) vboxdrv(OE) slhc(E) ccm(E) rfcomm(E) xt_CHECKSUM(E) ipt_REJ ECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) nft_counter(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf _defrag_ipv4(E) nf_tables(E) nfnetlink(E) tun(E) cmac(E) cpufreq_userspace(E) cpufreq_powersave(E) bnep(E) cpufreq_conservative(E) uinput(E) binfmt_misc(E) nls_ascii(E) nls_cp437(E) btusb(E) btrtl(E) btbcm(E) uvcvideo(E) btintel(E) intel_rapl_msr(E) snd_hda_co dec_hdmi(E) videobuf2_vmalloc(E) intel_rapl_common(E) videobuf2_memops(E) videobuf2_v4l2(E) fuse(E) bluetooth(E) videobuf2_common( E) iwlmvm(E) snd_hda_codec_realtek(E) ecdh_generic(E) videodev(E) ecc(E) snd_hda_codec_generic(E) [ 6180.832696] mac80211(E) mei_hdcp(E) x86_pkg_temp_thermal(E) libarc4(E) snd_hda_intel(E) intel_powerclamp(E) coretemp(E) iwlwif i(E) snd_hda_codec(E) snd_hwdep(E) kvm_intel(E) snd_hda_core(E) efi_pstore(E) kvm(E) cfg80211(E) irqbypass(E) snd_pcm(E) thinkpad_ acpi(E) intel_pch_thermal(E) iTCO_wdt(E) joydev(E) mei_me(E) snd_timer(E) nvram(E) efivars(E) ledtrig_audio(E) iTCO_vendor_support (E) serio_raw(E) sg(E) snd(E) tpm_crb(E) mei(E) evdev(E) pcspkr(E) soundcore(E) rfkill(E) tpm_tis(E) ac(E) tpm_tis_core(E) battery (E) tpm(E) rng_core(E) button(E) sunrpc(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) dm_crypt(E) dm_mod(E) raid10(E) raid456 (E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) async_tx(E) raid1(E) raid0(E) multipath(E) linear(E) md_mod(E) s d_mod(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) i915(E) ahci(E) i2c_algo_bit(E) libahci(E) drm _kms_helper(E) aesni_intel(E) rtsx_pci_sdmmc(E) syscopyarea(E) xhci_pci(E) libata(E) mmc_core(E) [ 6180.832721] sysfillrect(E) aes_x86_64(E) sysimgblt(E) crypto_simd(E) fb_sys_fops(E) xhci_hcd(E) cryptd(E) glue_helper(E) psmou se(E) i2c_i801(E) scsi_mod(E) drm(E) usbcore(E) thermal(E) video(E) [ 6180.832730] CPU: 2 PID: 117 Comm: kswapd0 Tainted: G OE 5.3.1+ #16 [ 6180.832731] Hardware name: LENOVO 20F5CTO1WW/20F5CTO1WW, BIOS R02ET71W (1.44 ) 05/08/2019 [ 6180.832733] RIP: 0010:check_flush_dependency+0xa0/0x130 [ 6180.832735] Code: 8d 8a 60 06 00 00 49 89 e8 48 c7 c7 f0 a0 87 97 48 8d 8b b0 00 00 00 4c 89 ca 48 89 04 24 c6 05 62 2b 28 01 0 1 e8 0e 16 fe ff <0f> 0b 48 8b 04 24 eb 10 4c 89 e7 e8 30 64 00 00 41 f6 44 24 25 08 [ 6180.832736] RSP: 0018:aa41801e78e8 EFLAGS: 00010082 [ 6180.832738] RAX: RBX: 9e48d0414c00 RCX: [ 6180.832739] RDX: 0063 RSI: 980515e3 RDI: 980519e3 [ 6180.832740] RBP: c05ae640 R08: 059f1655da91 R09: 0063 [ 6180.832741] R10: 98051960 R11: 980515cb R12: 9e48cf87e080 [ 6180.832742] R13: 9e48d222c400 R14: 0001 R15: 9e48c97ede80 [ 6180.832743] FS: () GS:9e48d230() knlGS: [ 6180.832744] CS: 0010 DS: ES: CR0: 80050033 [ 6180.832745] CR2: 7fc7a50c2000 CR3: 000118c0a005 CR4: 003606e0 [ 6180.832746] Call Trace: [ 6180.832750] __flush_work+0x92/0x1b0 [ 6180.832753] ? enqueue_hrtimer+0x36/0x90 [ 6180.832755] ? hrtimer_start_range_ns+0x18b/0x2c0 [ 6180.832757] __cancel_work_timer+0x100/0x190 [ 6180.832760] ? _cond_resched+0x15/0x30 [ 6180.832762] ? synchronize_irq+0x3a/0xa0 [ 6180.832764] ? _raw_spin_lock_irqsave+0x25/0x30 [ 6180.832783] ? fwtable_write32+0x4f/0x210 [i915] [ 6180.832799]
Re: [PATCH] ion_system_heap: support X86 archtecture
On Sun, Sep 29, 2019 at 03:28:41PM +0800, jun.zh...@intel.com wrote:
> From: zhang jun
>
> we see tons of warning like:
> [ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back
> [ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
> write-combining for [mem 0x1e7a58000-0x1e7a58fff], got write-back
> [ 45.848875] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a48000-0x1e7a4], got write-back
> [ 45.849403] x86/PAT: .vorbis.decoder:4088 map pfn RAM range
> req write-combining for [mem 0x1e7a7-0x1e7a70fff], got write-back
>
> check the kernel Documentation/x86/pat.txt, it says:
> A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
> vm_insert_pfn
> Drivers wanting to export some pages to userspace do it by using
> mmap interface and a combination of
> 1) pgprot_noncached()
> 2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()
> With PAT support, a new API pgprot_writecombine is being added.
> So, drivers can continue to use the above sequence, with either
> pgprot_noncached() or pgprot_writecombine() in step 1, followed by step 2.
>
> In addition, step 2 internally tracks the region as UC or WC in
> memtype list in order to ensure no conflicting mapping.
>
> Note that this set of APIs only works with IO (non RAM) regions.
> If driver ants to export a RAM region, it has to do set_memory_uc() or
> set_memory_wc() as step 0 above and also track the usage of those pages
> and use set_memory_wb() before the page is freed to free pool.
>
> the fix follow the pat document, do set_memory_wc() as step 0 and
> use the set_memory_wb() before the page is freed.
>
> Signed-off-by: he, bo
> Signed-off-by: zhang jun
> Signed-off-by: Bai, Jie A
> ---
> drivers/staging/android/ion/ion_system_heap.c | 28 ++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion_system_heap.c
> b/drivers/staging/android/ion/ion_system_heap.c
> index b83a1d16bd89..d298b8194820 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ion.h"
>
> @@ -134,6 +135,13 @@ static int ion_system_heap_allocate(struct ion_heap
> *heap,
> sg = table->sgl;
> list_for_each_entry_safe(page, tmp_page, , lru) {
> sg_set_page(sg, page, page_size(page), 0);
> +
> +#ifdef CONFIG_X86
> + if (!(buffer->flags & ION_FLAG_CACHED))
> + set_memory_wc((unsigned long)page_address(sg_page(sg)),
> + PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
> +#endif
There is no way to do this without these #ifdefs? That feels odd, why
can't you just always test for this?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ion_system_heap: support X86 archtecture
From: zhang jun
we see tons of warning like:
[ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back
[ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
write-combining for [mem 0x1e7a58000-0x1e7a58fff], got write-back
[ 45.848875] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a48000-0x1e7a4], got write-back
[ 45.849403] x86/PAT: .vorbis.decoder:4088 map pfn RAM range
req write-combining for [mem 0x1e7a7-0x1e7a70fff], got write-back
check the kernel Documentation/x86/pat.txt, it says:
A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
vm_insert_pfn
Drivers wanting to export some pages to userspace do it by using
mmap interface and a combination of
1) pgprot_noncached()
2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()
With PAT support, a new API pgprot_writecombine is being added.
So, drivers can continue to use the above sequence, with either
pgprot_noncached() or pgprot_writecombine() in step 1, followed by step 2.
In addition, step 2 internally tracks the region as UC or WC in
memtype list in order to ensure no conflicting mapping.
Note that this set of APIs only works with IO (non RAM) regions.
If driver ants to export a RAM region, it has to do set_memory_uc() or
set_memory_wc() as step 0 above and also track the usage of those pages
and use set_memory_wb() before the page is freed to free pool.
the fix follow the pat document, do set_memory_wc() as step 0 and
use the set_memory_wb() before the page is freed.
Signed-off-by: he, bo
Signed-off-by: zhang jun
Signed-off-by: Bai, Jie A
---
drivers/staging/android/ion/ion_system_heap.c | 28 ++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b83a1d16bd89..d298b8194820 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "ion.h"
@@ -134,6 +135,13 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
sg = table->sgl;
list_for_each_entry_safe(page, tmp_page, , lru) {
sg_set_page(sg, page, page_size(page), 0);
+
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wc((unsigned long)page_address(sg_page(sg)),
+ PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
+#endif
+
sg = sg_next(sg);
list_del(>lru);
}
@@ -162,8 +170,15 @@ static void ion_system_heap_free(struct ion_buffer *buffer)
if (!(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
ion_heap_buffer_zero(buffer);
- for_each_sg(table->sgl, sg, table->nents, i)
+ for_each_sg(table->sgl, sg, table->nents, i) {
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wb((unsigned long)page_address(sg_page(sg)),
+ PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
+#endif
+
free_buffer_page(sys_heap, buffer, sg_page(sg));
+ }
sg_free_table(table);
kfree(table);
}
@@ -316,6 +331,12 @@ static int ion_system_contig_heap_allocate(struct ion_heap
*heap,
buffer->sg_table = table;
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wc((unsigned long)page_address(page),
+ PAGE_ALIGN(len) >> PAGE_SHIFT);
+#endif
+
return 0;
free_table:
@@ -334,6 +355,11 @@ static void ion_system_contig_heap_free(struct ion_buffer
*buffer)
unsigned long pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
unsigned long i;
+#ifdef CONFIG_X86
+ if (!(buffer->flags & ION_FLAG_CACHED))
+ set_memory_wb((unsigned long)page_address(page), pages);
+#endif
+
for (i = 0; i < pages; i++)
__free_page(page + i);
sg_free_table(table);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/11] drm/amdgpu: job is secure iff CS is secure (v5)
Mark a job as secure, if and only if the command
submission flag has the secure flag set.
v2: fix the null job pointer while in vmid 0
submission.
v3: Context --> Command submission.
v4: filling cs parser with cs->in.flags
v5: move the job secure flag setting out of amdgpu_cs_submit()
Signed-off-by: Huang Rui
Co-developed-by: Luben Tuikov
Signed-off-by: Luben Tuikov
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 49b767b..c18a153 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -231,6 +231,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
if (ret)
goto free_all_kdata;
+ p->job->secure = cs->in.flags & AMDGPU_CS_FLAGS_SECURE;
+
if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
ret = -ECANCELED;
goto free_all_kdata;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 9a6dbf3..6e0f97a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -213,7 +213,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned
num_ibs,
if (job && ring->funcs->emit_cntxcntl) {
status |= job->preamble_status;
status |= job->preemption_status;
- amdgpu_ring_emit_cntxcntl(ring, status, false);
+ amdgpu_ring_emit_cntxcntl(ring, status, job->secure);
}
for (i = 0; i < num_ibs; ++i) {
@@ -232,7 +232,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned
num_ibs,
}
if (ring->funcs->emit_tmz)
- amdgpu_ring_emit_tmz(ring, false, false);
+ amdgpu_ring_emit_tmz(ring, false, job ? job->secure : false);
#ifdef CONFIG_X86_64
if (!(adev->flags & AMD_IS_APU))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
index dc7ee93..aa0e375 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
@@ -63,6 +63,8 @@ struct amdgpu_job {
uint64_tuf_addr;
uint64_tuf_sequence;
+ /* the job is due to a secure command submission */
+ boolsecure;
};
int amdgpu_job_alloc(struct amdgpu_device *adev, unsigned num_ibs,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111729] RX480 : random NULL pointer dereference on resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111729 --- Comment #2 from p...@phi-gamma.net --- I can confirm this bug. Same phenomenology here with 5.2.11, two screens, and a 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon RX 550/550X] (rev c7) Sep 29 08:26:39 phlegethon kernel: PM: suspend exit Sep 29 08:26:40 phlegethon kernel: [drm] schedsdma0 is not ready, skipping Sep 29 08:26:58 phlegethon kernel: [drm] schedsdma1 is not ready, skipping Sep 29 08:26:58 phlegethon kernel: BUG: kernel NULL pointer dereference, address: 0008 Sep 29 08:26:58 phlegethon kernel: #PF: supervisor read access in kernel mode Sep 29 08:26:58 phlegethon kernel: #PF: error_code(0x) - not-present page Sep 29 08:26:59 phlegethon kernel: PGD 6032ef067 P4D 6032ef067 PUD 603c09067 PMD 0 Sep 29 08:26:59 phlegethon kernel: Oops: [#1] SMP NOPTI Sep 29 08:26:59 phlegethon kernel: CPU: 0 PID: 1429 Comm: X Tainted: GW 5.2.11 #1-NixOS Sep 29 08:26:59 phlegethon kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 6.0/GA-78LMT-USB3 6.0, BIOS F2 11/25/2014 Sep 29 08:26:59 phlegethon kernel: RIP: 0010:amdgpu_vm_sdma_commit+0x46/0x140 [amdgpu] Sep 29 08:26:59 phlegethon kernel: Code: 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 48 8b 47 08 48 8b aa a8 01 00 00 4c 8b a8 80 00 00 00 48 8b 80 c8 00 00 00 <4c> 8b 70 08 8b 45 08 85 c0 4d 8d 7e 88 0f 84 c2 00 00 00 49 8b 46 Sep 29 08:26:59 phlegethon kernel: RSP: 0018:99bb838ffad8 EFLAGS: 00010246 Sep 29 08:26:59 phlegethon kernel: RAX: RBX: 99bb838ffb20 RCX: 00103c00 Sep 29 08:26:59 phlegethon kernel: RDX: 89abd64a4000 RSI: 99bb838ffba8 RDI: 99bb838ffb20 Sep 29 08:26:59 phlegethon kernel: RBP: 89abd64a4210 R08: 99bb838ffa6c R09: 99bb838ffa70 Sep 29 08:26:59 phlegethon kernel: R10: 00103804 R11: 0021 R12: 99bb838ffba8 Sep 29 08:26:59 phlegethon kernel: R13: 89ac48fc6000 R14: 00103803 R15: Sep 29 08:26:59 phlegethon kernel: FS: 7fd089d18e40() GS:89ac67a0() knlGS: Sep 29 08:26:59 phlegethon kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 29 08:26:59 phlegethon kernel: CR2: 0008 CR3: 000603afa000 CR4: 06f0 Sep 29 08:26:59 phlegethon kernel: Call Trace: Sep 29 08:26:59 phlegethon kernel: amdgpu_vm_bo_update_mapping+0xcd/0xe0 [amdgpu] Sep 29 08:26:59 phlegethon kernel: amdgpu_vm_clear_freed+0xbe/0x190 [amdgpu] Sep 29 08:26:59 phlegethon kernel: amdgpu_gem_va_ioctl+0x488/0x4f0 [amdgpu] Sep 29 08:26:59 phlegethon kernel: ? amdgpu_gem_metadata_ioctl+0x1b0/0x1b0 [amdgpu] Sep 29 08:26:59 phlegethon kernel: ? drm_ioctl_kernel+0xac/0xf0 [drm] Sep 29 08:26:59 phlegethon kernel: drm_ioctl_kernel+0xac/0xf0 [drm] Sep 29 08:26:59 phlegethon kernel: ? sock_write_iter+0x8f/0xf0 Sep 29 08:26:59 phlegethon kernel: drm_ioctl+0x2e6/0x3a0 [drm] Sep 29 08:26:59 phlegethon kernel: ? amdgpu_gem_metadata_ioctl+0x1b0/0x1b0 [amdgpu] Sep 29 08:26:59 phlegethon kernel: ? do_iter_write+0xe2/0x190 Sep 29 08:26:59 phlegethon kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Sep 29 08:26:59 phlegethon kernel: do_vfs_ioctl+0xa4/0x630 Sep 29 08:26:59 phlegethon kernel: ksys_ioctl+0x70/0x80 Sep 29 08:26:59 phlegethon kernel: __x64_sys_ioctl+0x16/0x20 Sep 29 08:26:59 phlegethon kernel: do_syscall_64+0x4e/0x130 Sep 29 08:26:59 phlegethon kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 29 08:26:59 phlegethon kernel: RIP: 0033:0x7fd08a3c4b57 Sep 29 08:26:59 phlegethon kernel: Code: 00 00 00 48 8b 05 29 53 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f9 52 0c 00 f7 d8 64 89 01 48 Sep 29 08:26:59 phlegethon kernel: RSP: 002b:7fff6a6738b8 EFLAGS: 0246 ORIG_RAX: 0010 Sep 29 08:26:59 phlegethon kernel: RAX: ffda RBX: RCX: 7fd08a3c4b57 Sep 29 08:26:59 phlegethon kernel: RDX: 7fff6a673900 RSI: c0286448 RDI: 0012 Sep 29 08:26:59 phlegethon kernel: RBP: 7fff6a673900 R08: 00010340 R09: 000e Sep 29 08:26:59 phlegethon kernel: R10: 0026 R11: 0246 R12: c0286448 Sep 29 08:26:59 phlegethon kernel: R13: 0012 R14: 0002 R15: 043d74a0 Sep 29 08:26:59 phlegethon kernel: Modules linked in: fuse bridge stp llc cfg80211 msr rfkill 8021q ext4 crc16 mbcache jbd2 amdgpu wmi_bmof ppdev gpu_sched edac_core ttm drm_kms_helper snd_hda_codec_realtek k10temp snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi drm snd_hda_intel joydev r8169 ata_generic snd_hda_codec sp5100_tco uas agpgart watchdog i2c_algo_bit pata_acpi evdev fb_sys_fops syscopyarea i2c_piix4 mousedev sysfillrect realtek sysimgblt mac_hid snd_hda_core backlight libphy i2c_core parport_pc snd_hwdep parport wmi button pcc_cpufreq acpi_cpufreq
Re: [v2] drm/komeda: Workaround for broken FLIP_COMPLETE timestamps
On Mon, Sep 23, 2019 at 10:10:26AM +, Mihail Atanassov wrote: > When initially turning a crtc on, drm_reset_vblank_timestamp will > set the vblank timestamp to 0 for any driver that doesn't provide > a ->get_vblank_timestamp() hook. > > Unfortunately, the FLIP_COMPLETE event depends on that timestamp, > and the only way to regenerate a valid one is to have vblank > interrupts enabled and have a valid in-ISR call to > drm_crtc_handle_vblank. > > Additionally, if the user doesn't request vblanks but _does_ request > FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the > same stamp as the last vblank one. > > Work around the issue by always enabling vblanks when the CRTC is on. > Reducing the amount of time that PL0 has to be unmasked would be nice to > fix at a later time. > > Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]: > - moved drm_crtc_vblank_put call to the ->atomic_disable() hook > > Cc: Daniel Vetter > Cc: Liviu Dudau > Signed-off-by: Mihail Atanassov > --- > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > index 34bc73ca18bc..d06679afb228 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > @@ -489,6 +489,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc, > pm_runtime_get_sync(crtc->dev->dev); > komeda_crtc_prepare(to_kcrtc(crtc)); > drm_crtc_vblank_on(crtc); > + WARN_ON(drm_crtc_vblank_get(crtc)); > komeda_crtc_do_flush(crtc, old); > } > > @@ -581,6 +582,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc, > komeda_crtc_flush_and_wait_for_flip_done(kcrtc, disable_done); > } > > + drm_crtc_vblank_put(crtc); > drm_crtc_vblank_off(crtc); > komeda_crtc_unprepare(kcrtc); > pm_runtime_put(crtc->dev->dev); Looks good to me. Reviewed-by: James Qian Wang (Arm Technology China) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4] drm: two planes with the same zpos have undefined ordering
On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote:
> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
>
> The rule mentionned in the past was to disambiguate with object IDs. However
> some drivers break this rule (that's why the ordering is documented as
> unspecified in case the zpos property is missing). Additionally it doesn't
> really make sense for a driver to user identical zpos values if it knows their
> relative position: the driver can just pick different values instead.
>
> So two solutions would make sense: either disallow completely identical zpos
> values for two different planes, either make the ordering unspecified. To
> allow
> drivers that don't know the relative ordering between two planes to still
> expose the zpos property, choose the latter solution.
Some Arm's usage cases about two planes with same zpos.
- "Smart layer"
which can accepts 4 different fbs with different src/display rect,
but this smart layer has one restriction:
4 display rects must have no overlaps in V direction
(A optimization for android window like Toolbar/Navigation bar)
So when map this Smart-layer to drm world, it might be 4 different
drm-planes, but with same zorder to indicate that these 4 planes are
smart-laye planes.
- "VR-Layer"
One VR-layer comprises two different viewports which can be configured
with totoally different fbs, src/display rect.
we use two differernt drm-planes to drive on HW "VR-Layer", and these
two drm-planes must be configured with same zpos.
Thanks
James
> While at it, remove the assumption that zpos is only for overlay planes.
>
> Additionally, update the drm_plane_state.zpos docs to clarify that zpos
> disambiguation via plane object IDs is a recommendation for drivers, not
> something user-space can rely on.
>
> v2: clarify drm_plane_state.zpos docs (Daniel)
>
> v3: zpos is for all planes (Marius, Daniel)
>
> v4: completely reword the drm_plane_state.zpos docs to make it clear the
> recommendation to use plane IDs is for drivers in case user-space uses
> duplicate zpos values (Pekka)
>
> Signed-off-by: Simon Ser
> Cc: Pekka Paalanen
> Cc: Marius Vlad
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_blend.c | 8
> include/drm/drm_plane.h | 9 +
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> --
> 2.23.0
>
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d02709dd2d4a..121481f6aa71 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -132,10 +132,10 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined. The positive
> * Z axis points towards the user, i.e. planes with lower Z position values
> - * are underneath planes with higher Z position values. Note that the Z
> - * position value can also be immutable, to inform userspace about the
> - * hard-coded stacking of overlay planes, see
> - * drm_plane_create_zpos_immutable_property().
> + * are underneath planes with higher Z position values. Two planes with the
> + * same Z position value have undefined ordering. Note that the Z position
> + * value can also be immutable, to inform userspace about the hard-coded
> + * stacking of planes, see drm_plane_create_zpos_immutable_property().
> *
> * pixel blend mode:
> * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index cd5903ad33f7..328773690851 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -140,10 +140,11 @@ struct drm_plane_state {
>* @zpos:
>* Priority of the given plane on crtc (optional).
>*
> - * Note that multiple active planes on the same crtc can have an
> - * identical zpos value. The rule to solving the conflict is to compare
> - * the plane object IDs; the plane with a higher ID must be stacked on
> - * top of a plane with a lower ID.
> + * User-space may set mutable zpos properties so that multiple active
> + * planes on the same CRTC have identical zpos values. This is a
> + * user-space bug, but drivers can solve the conflict by comparing the
> + * plane object IDs; the plane with a higher ID is stacked on top of a
> + * plane with a lower ID.
>*
>* See drm_plane_create_zpos_property() and
>* drm_plane_create_zpos_immutable_property() for more details.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm/gem: refine drm_gem_objects_lookup
On Fri, Sep 27, 2019 at 9:57 PM Steven Price wrote:
>
> On 27/09/2019 14:46, Qiang Yu wrote:
> > drm_gem_objects_lookup does not use user space bo handles
> > directly and left the user to kernel copy work to a new
> > interface drm_gem_objects_lookup_user.
> >
> > This is for driver like lima which does not pass gem bo
> > handles continously in an array in ioctl argument.
>
> Nit: It would be good to mention in the commit message that this adds
> drm_gem_objects_lookup_user() as it helps grepping commits. Also if
> you're rewriting it - it would be good to point out that you are
> _changing_ the behvaviour of drm_gem_objects_lookpu() to not use user
> space handles.
>
OK, I can improve the comments of two patches in v3.
Thanks,
Qiang
> >
> > v2:
> > 1. add drm_gem_objects_lookup_user
> > 2. remove none-zero check as all caller will check before
> >calling this function
> >
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Steven Price
> > Cc: Alyssa Rosenzweig
> > Suggested-by: Rob Herring
> > Signed-off-by: Qiang Yu
>
> Reviewed-by: Steven Price
>
> > ---
> > drivers/gpu/drm/drm_gem.c | 57 +++--
> > drivers/gpu/drm/panfrost/panfrost_drv.c | 6 +--
> > include/drm/drm_gem.h | 4 +-
> > 3 files changed, 49 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 6854f5867d51..a5e88c3e6d25 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -679,11 +679,11 @@ static int objects_lookup(struct drm_file *filp, u32
> > *handle, int count,
> > /**
> > * drm_gem_objects_lookup - look up GEM objects from an array of handles
> > * @filp: DRM file private date
> > - * @bo_handles: user pointer to array of userspace handle
> > + * @bo_handles: array of GEM object handles
> > * @count: size of handle array
> > * @objs_out: returned pointer to array of drm_gem_object pointers
> > *
> > - * Takes an array of userspace handles and returns a newly allocated array
> > of
> > + * Takes an array of GEM object handles and returns a newly allocated
> > array of
> > * GEM objects.
> > *
> > * For a single handle lookup, use drm_gem_object_lookup().
> > @@ -695,26 +695,56 @@ static int objects_lookup(struct drm_file *filp, u32
> > *handle, int count,
> > * failure. 0 is returned on success.
> > *
> > */
> > -int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
> > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
> > int count, struct drm_gem_object ***objs_out)
> > {
> > int ret;
> > - u32 *handles;
> > struct drm_gem_object **objs;
> >
> > - if (!count)
> > - return 0;
> > -
> > objs = kvmalloc_array(count, sizeof(struct drm_gem_object *),
> >GFP_KERNEL | __GFP_ZERO);
> > if (!objs)
> > return -ENOMEM;
> >
> > + ret = objects_lookup(filp, bo_handles, count, objs);
> > + if (ret)
> > + kvfree(objs);
> > + else
> > + *objs_out = objs;
> > +
> > + return ret;
> > +
> > +}
> > +EXPORT_SYMBOL(drm_gem_objects_lookup);
> > +
> > +/**
> > + * drm_gem_objects_lookup_user - look up GEM objects from an array of
> > handles
> > + * @filp: DRM file private date
> > + * @bo_handles: user pointer to array of userspace handle
> > + * @count: size of handle array
> > + * @objs_out: returned pointer to array of drm_gem_object pointers
> > + *
> > + * Takes an array of userspace handles and returns a newly allocated array
> > of
> > + * GEM objects.
> > + *
> > + * For a single handle lookup, use drm_gem_object_lookup().
> > + *
> > + * Returns:
> > + *
> > + * @objs filled in with GEM object pointers. Returned GEM objects need to
> > be
> > + * released with drm_gem_object_put(). -ENOENT is returned on a lookup
> > + * failure. 0 is returned on success.
> > + *
> > + */
> > +int drm_gem_objects_lookup_user(struct drm_file *filp, void __user
> > *bo_handles,
> > + int count, struct drm_gem_object ***objs_out)
> > +{
> > + int ret;
> > + u32 *handles;
> > +
> > handles = kvmalloc_array(count, sizeof(u32), GFP_KERNEL);
> > - if (!handles) {
> > - ret = -ENOMEM;
> > - goto out;
> > - }
> > + if (!handles)
> > + return -ENOMEM;
> >
> > if (copy_from_user(handles, bo_handles, count * sizeof(u32))) {
> > ret = -EFAULT;
> > @@ -722,15 +752,14 @@ int drm_gem_objects_lookup(struct drm_file *filp,
> > void __user *bo_handles,
> > goto out;
> > }
> >
> > - ret = objects_lookup(filp, handles, count, objs);
> > - *objs_out = objs;
> > + ret = drm_gem_objects_lookup(filp, handles, count, objs_out);
> >
> > out:
> > kvfree(handles);
> > return ret;
> >
> > }
> > -EXPORT_SYMBOL(drm_gem_objects_lookup);
> >
