[PATCH -next] drm: bridge: fix wrong pointer passed to PTR_ERR()
PTR_ERR should access the value just tested by IS_ERR, otherwise
the wrong error code will be returned.
Reported-by: Hulk Robot
Signed-off-by: Qiheng Lin
---
drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index d8a60691fd32..6980c9801d0d 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -943,7 +943,7 @@ static int it66121_probe(struct i2c_client *client,
ctx->regmap = devm_regmap_init_i2c(client, &it66121_regmap_config);
if (IS_ERR(ctx->regmap)) {
ite66121_power_off(ctx);
- return PTR_ERR(ctx);
+ return PTR_ERR(ctx->regmap);
}
regmap_read(ctx->regmap, IT66121_VENDOR_ID0_REG, &vendor_ids[0]);
Re: [PATCH] drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE
Am 14.05.21 um 08:40 schrieb Huacai Chen: From: Yi Li When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB entries which need to update in amdgpu_map_buffer() should be multiplied by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE). Signed-off-by: Yi Li Signed-off-by: Huacai Chen Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 3bef0432cac2..a376a993e474 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -225,7 +225,7 @@ static int amdgpu_ttm_map_buffer(struct ttm_buffer_object *bo, *addr += mm_cur->start & ~PAGE_MASK; num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8); - num_bytes = num_pages * 8; + num_bytes = num_pages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE; r = amdgpu_job_alloc_with_ib(adev, num_dw * 4 + num_bytes, AMDGPU_IB_POOL_DELAYED, &job);
Re: [PATCH 0/7] Per client engine busyness
[AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. From: Alex Deucher Sent: Thursday, May 13, 2021 10:58 PM To: Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian Cc: Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter Subject: Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show > >> not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz;0% RC6; 5.30 Watts; 933 irqs/s > >> > >>IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >>ENGINE BUSY MI_SEMA > >> MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% > >>0% > >> Blitter/00.00% | | 0% > >>0% > >> Video/00.00% | | 0% > >>0% > >>VideoEnhance/00.00% | | 0% > >>0% > >> > >>PIDNAME Render/3D BlitterVideo > >> VideoEnhance > >> 2733 neverball |██▌ |||||| > >>| > >> 2047Xorg |███▊|||||| > >>| > >> 2737glxgears |█▍ |||||| > >>| > >> 2128 xfwm4 ||||||| > >>| > >> 2047Xorg ||||||| > >>| > >> > >> > >> Internally we track time spent on engines for each struct intel_context, > >> both > >> for current and past contexts belonging to each open DRM file. > >> > >> This can serve as a building block for several features from the wanted > >> list: > >> smarter scheduler decisions, getrusage(2)-like per-GEM-context > >> functionality > >> wanted by some customers, setrlimit(2) like controls, cgroups controller, > >> dynamic SSEU tuning, ... > >> > >> To enable userspace access to the tracked data, we expose time spent on > >> GPU per > >> client and per engine class in sysfs with a hierarchy like the below: > >> > >> # cd /sys/class/drm/card0/clients/ > >> # tree > >> . > >> ├── 7 > >> │ ├── busy > >> │ │ ├── 0 > >> │ │ ├── 1 > >> │ │ ├── 2 > >> │ │ └── 3 > >> │ ├── name > >> │ └── pid > >> ├── 8 > >> │ ├── busy > >> │ │ ├── 0 > >> │ │ ├── 1 > >> │ │ ├── 2 > >> │ │ └── 3 > >> │ ├── name > >> │ └── pid > >> └── 9 > >> ├── busy > >> │ ├── 0 > >> │ ├── 1 > >> │ ├── 2 > >> │ └── 3 > >> ├── name > >> └── pid > >> > >> Files in 'busy' directories are numbered using the engine class ABI values > >> and > >> they contain accumulated nanoseconds each client spent on engines of a > >> respective class. > > > > We did something similar in amdgpu using the gpu scheduler. We then > > expose the data via fdinfo. See > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D1774baa64f9395fa884ea9ed494bcb043f3b83f5&data=04%7C01%7CDavid.Nieto%40amd.com%7C5e3c05578ef14be3692508d9169d55bf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637565687273144615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mt1EIL%2Fc9pHCXR%2FYSd%2BTr1e64XHoeYcdQ2cYufJ%2FcYQ%3D&reserved=0 > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D874442541133f78c78b6880b8cc495bab5c61704&data=04%7C01%7CDavid.Nieto%40amd.com%7C5e3c05578ef14be3692508d9169d55bf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637565687273144615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
[PATCH v2] video/logo: protect against divide by zero when reading image
In video/logo/pnmtologo.c, the function read_image can read from the
image file an integer 0 and pass it to function get_number255, leading
to a divide by zero problem.
Signed-off-by: Yiyuan GUO
---
drivers/video/logo/pnmtologo.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/video/logo/pnmtologo.c b/drivers/video/logo/pnmtologo.c
index 4718d7895..d9e8d1d5b 100644
--- a/drivers/video/logo/pnmtologo.c
+++ b/drivers/video/logo/pnmtologo.c
@@ -116,6 +116,16 @@ static unsigned int get_number(FILE *fp)
return val;
}
+static unsigned int get_maxval(FILE *fp)
+{
+unsigned int maxval = get_number(fp);
+
+if (!maxval)
+ die("%s: invalid maxval zero\n", filename);
+
+return maxval;
+}
+
static unsigned int get_number255(FILE *fp, unsigned int maxval)
{
unsigned int val = get_number(fp);
@@ -182,7 +192,7 @@ static void read_image(void)
case '2':
/* Plain PGM */
- maxval = get_number(fp);
+ maxval = get_maxval(fp);
for (i = 0; i < logo_height; i++)
for (j = 0; j < logo_width; j++)
logo_data[i][j].red = logo_data[i][j].green =
@@ -191,7 +201,7 @@ static void read_image(void)
case '3':
/* Plain PPM */
- maxval = get_number(fp);
+ maxval = get_maxval(fp);
for (i = 0; i < logo_height; i++)
for (j = 0; j < logo_width; j++) {
logo_data[i][j].red = get_number255(fp, maxval);
--
2.25.1
[PATCH] agp: check if ndevs is zero before enabling node
In function agp_3_5_enable from drivers/char/agp/isoch.c, the
variable ndevs may remain zero if all AGP devices have type of
"Bridge" or "Unclassified device". Passing ndevs==0 to function
agp_3_5_isochronous_node_enable or agp_3_5_nonisochronous_node_enable
will lead to divide by zero problems.
Signed-off-by: Yiyuan GUO
---
drivers/char/agp/isoch.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/char/agp/isoch.c b/drivers/char/agp/isoch.c
index 7ecf20a6d..4c21bb057 100644
--- a/drivers/char/agp/isoch.c
+++ b/drivers/char/agp/isoch.c
@@ -433,6 +433,11 @@ int agp_3_5_enable(struct agp_bridge_data *bridge)
}
}
+ if (!ndevs) {
+ ret = -ENODEV;
+ goto free_and_exit;
+ }
+
/*
* Call functions to divide target resources amongst the AGP 3.0
* masters. This process is dramatically different depending on
--
2.25.1
Re: KASAN: use-after-free Read in drm_gem_object_release
Tse
Re: Re: [PATCH] agp: check if ndevs is zero before enabling node
From: Yiyuan GUO I guess it may only happen in theory, but maybe there is no harm in adding a simple check? Thanks.
[PATCH] drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE
From: Yi Li When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB entries which need to update in amdgpu_map_buffer() should be multiplied by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE). Signed-off-by: Yi Li Signed-off-by: Huacai Chen --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 3bef0432cac2..a376a993e474 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -225,7 +225,7 @@ static int amdgpu_ttm_map_buffer(struct ttm_buffer_object *bo, *addr += mm_cur->start & ~PAGE_MASK; num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8); - num_bytes = num_pages * 8; + num_bytes = num_pages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE; r = amdgpu_job_alloc_with_ib(adev, num_dw * 4 + num_bytes, AMDGPU_IB_POOL_DELAYED, &job); -- 2.27.0
Re: [PATCH 1/2] drm: Fix dirtyfb stalls
On Wed, 12 May 2021 07:57:26 -0700 Rob Clark wrote: > On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote: > > > > On Tue, 11 May 2021 18:44:17 +0200 > > Daniel Vetter wrote: > > > > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote: > > > > On Mon, May 10, 2021 at 10:44 AM Daniel Vetter wrote: > > > > > > > > > > > > > > On Mon, May 10, 2021 at 6:51 PM Rob Clark > > > > > wrote: > > > > > > > > > > > > On Mon, May 10, 2021 at 9:14 AM Daniel Vetter > > > > > > wrote: > > > > > > > > > > > > > > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote: > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > drm_atomic_helper_dirtyfb() will end up stalling for vblank on > > > > > > > > "video > > > > > > > > mode" type displays, which is pointless and unnecessary. Add an > > > > > > > > optional helper vfunc to determine if a plane is attached to a > > > > > > > > CRTC > > > > > > > > that actually needs dirtyfb, and skip over them. > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark ... > > > > > > But we could re-work drm_framebuffer_funcs::dirty to operate on a > > > > > > per-crtc basis and hoist the loop and check if dirtyfb is needed out > > > > > > of drm_atomic_helper_dirtyfb() > > > > > > > > > > That's still using information that userspace doesn't have, which is a > > > > > bit irky. We might as well go with your thing here then. > > > > > > > > arguably, this is something we should expose to userspace.. for DSI > > > > command-mode panels, you probably want to make a different decision > > > > with regard to how many buffers in your flip-chain.. > > > > > > > > Possibly we should add/remove the fb_damage_clips property depending > > > > on the display type (ie. video/pull vs cmd/push mode)? > > > > > > I'm not sure whether atomic actually needs this exposed: > > > - clients will do full flips for every frame anyway, I've not heard of > > > anyone seriously doing frontbuffer rendering. > > > > That may or may not be changing, depending on whether the DRM drivers > > will actually support tearing flips. There has been a huge amount of > > debate for needing tearing for Wayland [1], and while I haven't really > > joined that discussion, using front-buffer rendering (blits) to work > > around the driver inability to flip-tear might be something some people > > will want. > > jfwiw, there is a lot of hw that just can't do tearing pageflips.. I > think this probably includes most arm hw. What is done instead is to > skip the pageflip and render directly to the front-buffer. > > EGL_KHR_mutable_render_buffer is a thing you might be interested in.. > it is wired up for android on i965 and there is a WIP MR[1] for > mesa/st (gallium): > > Possibly it could be useful to add support for platform_wayland? > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10685 Thanks Rob, that's interesting. I would like to say that EGL Wayland platform cannot and has no reason to support frontbuffer rendering in Wayland clients, because the compositor may be reading the current client frontbuffer at any time, including *not reading it again* until another update is posted via Wayland. So if a Wayland client is doing frontbuffer rendering, then I would expect it to be very likely that the window might almost never show a "good" picture, meaning that it is literally just the half-rendered frame after the current one with continuously updating clients. That is because a Wayland client doing frontbuffer rendering is completely unrelated to the Wayland compositor putting the client buffer on scanout. Frontbuffer rendering used by a Wayland compositor would be used for fallback tearing updates, where the rendering is roughly just a blit from a client buffer. By definition, it means blit instead of scanout from client buffers, so the performance/power hit is going to be... let's say observable. If a Wayland client did frontbuffer rendering, and then it used a shadow buffer of its own to minimise the level of garbage on screen by doing only blits into the frontbuffer, that would again be a blit. And then the compositor might be doing another blit because it doesn't know the client is doing frontbuffer rendering which would theoretically allow the compositor to scan out the client buffer. There emerges the need for a Wayland extension for clients to be telling the compositor explicitly that they are going to be doing frontbuffer rendering now, it is ok to put the client buffer on scanout even if you want to do tearing updates on hardware that cannot tear-flip. However, knowing that a client buffer is good for scanout is not sufficient for scanout in a compositor, so it might still not be scanned out. If the compositor is instead render-compositing, you have the first problem of "likely never a good picture". I'm sure there can be specialised use cases (e.g. a game console Wayland compositor) where scanout can be guaranteed, but generally
Re: [PATCH 0/7] Per client engine busyness
Well in my opinion exposing it through fdinfo turned out to be a really clean approach. It describes exactly the per file descriptor information we need. Making that device driver independent is potentially useful as well. Regards, Christian. Am 14.05.21 um 09:22 schrieb Nieto, David M: [AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. *From:* Alex Deucher *Sent:* Thursday, May 13, 2021 10:58 PM *To:* Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian *Cc:* Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter *Subject:* Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz; 0% RC6; 5.30 Watts; 933 irqs/s > >> > >> IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >> ENGINE BUSY MI_SEMA MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% 0% > >> Blitter/0 0.00% | | 0% 0% > >> Video/0 0.00% | | 0% 0% > >> VideoEnhance/0 0.00% | | 0% 0% > >> > >> PID NAME Render/3D Blitter Video VideoEnhance > >> 2733 neverball |██▌ || || || | > >> 2047 Xorg |███▊ || || || | > >> 2737 glxgears |█▍ || || || | > >> 2128 xfwm4 | || || || | > >> 2047 Xorg | || || || | > >> > >> > >> Internally we track time spent on engines for each struct intel_context, both > >> for current and past contexts belonging to each open DRM file. > >> > >> This can serve as a building block for several features from the wanted list: > >> smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality > >> wanted by some customers, setrlimit(2) like controls, cgroups controller, > >> dynamic SSEU tuning, ... > >> > >> To enable userspace access to the tracked data, we expose time spent on GPU per > >> client and per engine class in sysfs with a hierarchy like the below: > >> > >> # cd /sys/class/drm/card0/clients/ > >> # tree > >> . > >> ├── 7 > >> │ ├── busy > >> │ │ ├── 0 > >> │ │ ├── 1 > >> │ │ ├── 2 > >> │ │ └── 3 > >> │ ├── name > >> │ └── pid > >> ├── 8 > >> │ ├── busy > >> │ │ ├── 0 > >> │ │ ├── 1 > >> │ │ ├── 2 > >> │ │ └── 3 > >> │ ├── name > >> │ └── pid > >> └── 9 > >> ├── busy > >> │ ├── 0 > >> │ ├── 1 > >> │ ├── 2 > >> │ └── 3 > >> ├── name > >> └── pid > >> > >> Files in 'busy' directories are numbered using the engine class ABI values and > >> they contain accumulated nanoseconds each client spent on engines of a > >> respective class. > > > > We did something similar in amdgpu using the gpu scheduler. We then > > expose the data via fdinfo. See > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D1774baa64f9395fa884ea9ed494bcb043f3b83f5&data=04%7C01%7CDavid.Nieto%40amd.com%7C5e3c05578ef14be3692508d9169d55bf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637565687273144615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mt1EIL%2Fc9pHCXR%2FYSd%2BTr1e64XHoeYcdQ2cYufJ%2FcYQ%3D&reserved=0
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
Em Wed, 12 May 2021 18:07:04 +0100
David Woodhouse escreveu:
> On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > Such conversion tools - plus some text editor like LibreOffice or similar
> > - have
> > a set of rules that turns some typed ASCII characters into UTF-8
> > alternatives,
> > for instance converting commas into curly commas and adding non-breakable
> > spaces. All of those are meant to produce better results when the text is
> > displayed in HTML or PDF formats.
>
> And don't we render our documentation into HTML or PDF formats?
Yes.
> Are
> some of those non-breaking spaces not actually *useful* for their
> intended purpose?
No.
The thing is: non-breaking space can cause a lot of problems.
We even had to disable Sphinx usage of non-breaking space for
PDF outputs, as this was causing bad LaTeX/PDF outputs.
See, commit: 3b4c963243b1 ("docs: conf.py: adjust the LaTeX document output")
The afore mentioned patch disables Sphinx default behavior of
using NON-BREAKABLE SPACE on literal blocks and strings, using this
special setting: "parsedliteralwraps=true".
When NON-BREAKABLE SPACE were used on PDF outputs, several parts of
the media uAPI docs were violating the document margins by far,
causing texts to be truncated.
So, please **don't add NON-BREAKABLE SPACE**, unless you test
(and keep testing it from time to time) if outputs on all
formats are properly supporting it on different Sphinx versions.
-
Also, most of those came from conversion tools, together with other
eccentricities, like the usage of U+FEFF (BOM) character at the
start of some documents. The remaining ones seem to came from
cut-and-paste.
For instance, bibliographic references (there are a couple of
those on media) sometimes have NON-BREAKABLE SPACE. I'm pretty
sure that those came from cut-and-pasting the document titles
from their names at the original PDF documents or web pages that
are referenced.
> > While it is perfectly fine to use UTF-8 characters in Linux, and specially
> > at
> > the documentation, it is better to stick to the ASCII subset on such
> > particular case, due to a couple of reasons:
> >
> > 1. it makes life easier for tools like grep;
>
> Barely, as noted, because of things like line feeds.
You can use grep with "-z" to seek for multi-line strings(*), Like:
$ grep -Pzl 'grace period started,\s*then' $(find Documentation/ -type
f)
Documentation/RCU/Design/Data-Structures/Data-Structures.rst
(*) Unfortunately, while "git grep" also has a "-z" flag, it
seems that this is (currently?) broken with regards of handling multilines:
$ git grep -Pzl 'grace period started,\s*then'
$
> > 2. they easier to edit with the some commonly used text/source
> >code editors.
>
> That is nonsense. Any but the most broken and/or anachronistic
> environments and editors will be just fine.
Not really.
I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely
on the US-intl keyboard settings, that allow me to type as "'a" for á.
However, there's no shortcut for non-Latin UTF-codes, as far as I know.
So, if would need to type a curly comma on the text editors I normally
use for development (vim, nano, kate), I would need to cut-and-paste
it from somewhere[1].
[1] If I have a table with UTF-8 codes handy, I could type the UTF-8
number manually... However, it seems that this is currently broken
at least on Fedora 33 (with Mate Desktop and US intl keyboard with
dead keys).
Here, U is not working. No idea why. I haven't
test it for *years*, as I din't see any reason why I would
need to type UTF-8 characters by numbers until we started
this thread.
In practice, on the very rare cases where I needed to write
non-Latin utf-8 chars (maybe once in a year or so, Like when I
would need to use a Greek letter or some weird symbol), there changes
are high that I wouldn't remember its UTF-8 code.
So, If I need to spend time to seek for an specific symbol, after
finding it, I just cut-and-paste it.
But even in the best case scenario where I know the UTF-8 and
U works, if I wanted to use, for instance, a curly
comma, the keystroke sequence would be:
U201csome stringU201d
That's a lot harder than typing and has a higher chances of
mistakenly add a wrong symbol than just typing:
"some string"
Knowing that both will produce *exactly* the same output, why
should I bother doing it the hard way?
-
Now, I'm not arguing that you can't use whatever UTF-8 symbol you
want on your docs. I'm just saying that, now that the conversion
is over and a lot of documents ended getting some UTF-8 characters
by accident, it is time for a cleanup.
Thanks,
Mauro
[PATCH -next] drm/vmwgfx: Fix return value check in vmw_setup_pci_resources()
In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR().
The IS_ERR() test in the return value check should be replaced with NULL test.
After that, the error code -ENOMEM should be returned.
Reported-by: Hulk Robot
Signed-off-by: Qiheng Lin
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 5cf3a5bf539f..6f5ea00973e0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -719,10 +719,10 @@ static int vmw_setup_pci_resources(struct vmw_private
*dev,
dev->rmmio = devm_ioremap(dev->drm.dev,
rmmio_start,
rmmio_size);
- if (IS_ERR(dev->rmmio)) {
+ if (!dev->rmmio) {
DRM_ERROR("Failed mapping registers mmio memory.\n");
pci_release_regions(pdev);
- return PTR_ERR(dev->rmmio);
+ return -ENOMEM;
}
} else if (pci_id == VMWGFX_PCI_ID_SVGA2) {
dev->io_start = pci_resource_start(pdev, 0);
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice or
> > > similar - have
> > > a set of rules that turns some typed ASCII characters into UTF-8
> > > alternatives,
> > > for instance converting commas into curly commas and adding non-breakable
> > > spaces. All of those are meant to produce better results when the text is
> > > displayed in HTML or PDF formats.
> >
> > And don't we render our documentation into HTML or PDF formats?
>
> Yes.
>
> > Are
> > some of those non-breaking spaces not actually *useful* for their
> > intended purpose?
>
> No.
>
> The thing is: non-breaking space can cause a lot of problems.
>
> We even had to disable Sphinx usage of non-breaking space for
> PDF outputs, as this was causing bad LaTeX/PDF outputs.
>
> See, commit: 3b4c963243b1 ("docs: conf.py: adjust the LaTeX document output")
>
> The afore mentioned patch disables Sphinx default behavior of
> using NON-BREAKABLE SPACE on literal blocks and strings, using this
> special setting: "parsedliteralwraps=true".
>
> When NON-BREAKABLE SPACE were used on PDF outputs, several parts of
> the media uAPI docs were violating the document margins by far,
> causing texts to be truncated.
>
> So, please **don't add NON-BREAKABLE SPACE**, unless you test
> (and keep testing it from time to time) if outputs on all
> formats are properly supporting it on different Sphinx versions.
And there you have a specific change with a specific fix. Nothing to do
with whether NON-BREAKABLE SPACE is ∉ ASCII, and *certainly* nothing to
do with the fact that, like *every* character in every kernel file
except the *binary* files, it's representable in UTF-8.
By all means fix the specific characters which are typographically
wrong or which, like NON-BREAKABLE SPACE, cause problems for rendering
the documentation.
> Also, most of those came from conversion tools, together with other
> eccentricities, like the usage of U+FEFF (BOM) character at the
> start of some documents. The remaining ones seem to came from
> cut-and-paste.
... or which are just entirely redundant and gratuitous, like a BOM in
an environment where all files are UTF-8 and never 16-bit encodings
anyway.
> > > While it is perfectly fine to use UTF-8 characters in Linux, and
> > > specially at
> > > the documentation, it is better to stick to the ASCII subset on such
> > > particular case, due to a couple of reasons:
> > >
> > > 1. it makes life easier for tools like grep;
> >
> > Barely, as noted, because of things like line feeds.
>
> You can use grep with "-z" to seek for multi-line strings(*), Like:
>
> $ grep -Pzl 'grace period started,\s*then' $(find Documentation/ -type
> f)
> Documentation/RCU/Design/Data-Structures/Data-Structures.rst
Yeah, right. That works if you don't just use the text that you'll have
seen in the HTML/PDF "grace period started, then", and if you instead
craft a *regex* for it, replacing the spaces with '\s*'. Or is that
[[:space:]]* if you don't want to use the experimental Perl regex
feature?
$ grep -zlr 'grace[[:space:]]\+period[[:space:]]\+started,[[:space:]]\+then'
Documentation/RCU
Documentation/RCU/Design/Data-Structures/Data-Structures.rst
And without '-l' it'll obviously just give you the whole file. No '-A5
-B5' to see the surroundings... it's hardly a useful thing, is it?
> (*) Unfortunately, while "git grep" also has a "-z" flag, it
> seems that this is (currently?) broken with regards of handling
> multilines:
>
> $ git grep -Pzl 'grace period started,\s*then'
> $
Even better. So no, multiline grep isn't really a commonly usable
feature at all.
This is why we prefer to put user-visible strings on one line in C
source code, even if it takes the lines over 80 characters — to allow
for grep to find them.
> > > 2. they easier to edit with the some commonly used text/source
> > >code editors.
> >
> > That is nonsense. Any but the most broken and/or anachronistic
> > environments and editors will be just fine.
>
> Not really.
>
> I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely
> on the US-intl keyboard settings, that allow me to type as "'a" for á.
> However, there's no shortcut for non-Latin UTF-codes, as far as I know.
>
> So, if would need to type a curly comma on the text editors I normally
> use for development (vim, nano, kate), I would need to cut-and-paste
> it from somewhere[1].
That's entirely irrelevant. You don't need to be able to *type* every
character that you see in front of you, as long as your editor will
render it correctly and perhaps let you cut/paste it as you're editing
the document if you're moving things around.
> [1] If I have a table with UTF-8 codes handy, I could type the UTF-8
> number manua
Re: [PATCH v3] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops
On Wed, May 12, 2021 at 2:19 AM Ville Syrjälä
wrote:
>
> On Mon, Apr 26, 2021 at 11:24:10PM +0800, Kai-Heng Feng wrote:
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected display as a new one, losing display settings.
> >
> > The expected behavior is to let discrete GFX drives all external
> > displays.
> >
> > The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
> > The method is inside the another _DSM, so add the _DSM and call it
> > accordingly.
> >
> > I also tested some MUX-less and iGPU only laptops with that _DSM, no
> > regression was found.
> >
> > v3:
> > - Remove BXT from names.
> > - Change the parameter type.
> > - Fold the function into intel_modeset_init_hw().
> >
> > v2:
> > - Forward declare struct pci_dev.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
> > References:
> > https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/
> > Signed-off-by: Kai-Heng Feng
> > ---
> > drivers/gpu/drm/i915/display/intel_acpi.c| 18 ++
> > drivers/gpu/drm/i915/display/intel_acpi.h| 3 +++
> > drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> > 3 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index 833d0c1be4f1..d008d3976261 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -13,12 +13,17 @@
> > #include "intel_display_types.h"
> >
> > #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
> > +#define INTEL_DSM_FN_PLATFORM_MUX_ENABLE 0 /* No args */
>
> This block of defines is for the other DSM. We don't want to
> mix these up. We also want to name it according to the spec,
> so something like GET_BIOS_DATA_FUNCS_SUPPORTED. Similarly
> for the intel_dsm_enable_mux() wrapper function. + it needs
> a comment to document that some BIOSes abuse it to do MUX
> initialization and whatnot.
Will do.
>
> We should perhaps rename all the old DSM stuff to
> something a bit less generic as well...
I can rename them as well. But what's the naming scheme you prefer?
>
> > #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
> >
> > static const guid_t intel_dsm_guid =
> > GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
> > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> >
> > +static const guid_t intel_dsm_guid2 =
> > + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
> > +
> > static char *intel_dsm_port_name(u8 id)
> > {
> > switch (id) {
> > @@ -176,6 +181,19 @@ void intel_unregister_dsm_handler(void)
> > {
> > }
> >
> > +void intel_dsm_enable_mux(struct drm_i915_private *i915)
> > +{
> > + struct pci_dev *pdev = i915->drm.pdev;
> > + acpi_handle dhandle;
> > +
> > + dhandle = ACPI_HANDLE(&pdev->dev);
> > + if (!dhandle)
> > + return;
> > +
> > + acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> > + INTEL_DSM_FN_PLATFORM_MUX_ENABLE, NULL);
> > +}
> > +
> > /*
> > * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All
> > Devices
> > * Attached to the Display Adapter).
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
> > b/drivers/gpu/drm/i915/display/intel_acpi.h
> > index e8b068661d22..def013cf6308 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> > @@ -11,11 +11,14 @@ struct drm_i915_private;
> > #ifdef CONFIG_ACPI
> > void intel_register_dsm_handler(void);
> > void intel_unregister_dsm_handler(void);
> > +void intel_dsm_enable_mux(struct drm_i915_private *i915);
> > void intel_acpi_device_id_update(struct drm_i915_private *i915);
> > #else
> > static inline void intel_register_dsm_handler(void) { return; }
> > static inline void intel_unregister_dsm_handler(void) { return; }
> > static inline
> > +void intel_dsm_enable_mux(struct drm_i915_private *i915) { return; }
> > +static inline
> > void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> > #endif /* CONFIG_ACPI */
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a10e26380ef3..d79dae370b20 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -11472,6 +11472,8 @@ void intel_modeset_init_hw(struct drm_i915_private
> > *i915)
> > {
> > struct intel_cdclk_state *cdclk_state;
> >
> > + intel_dsm_enable_mux(i915);
> > +
>
> This should probably be somewhere around where we do all the other
> semi ACPI related init (OpRegion/etc.).
Hmm, but Jani prefers to put it inside intel_modeset_*() helpers. But
I
Re: [PATCH] drm/loongson: Add GPIO and I2C driver for loongson drm.
Hi, Chenyang,
Please make this patch and the other one in a series.
Huacai
On Fri, May 14, 2021 at 9:50 AM lichenyang wrote:
>
> Implement use GPIO and I2C driver to detect connector
> and fetch EDID via DDC.
>
> Signed-off-by: lichenyang
> ---
> drivers/gpu/drm/loongson/Makefile | 3 +-
> drivers/gpu/drm/loongson/loongson_connector.c | 70 -
> drivers/gpu/drm/loongson/loongson_drv.c | 16 +-
> drivers/gpu/drm/loongson/loongson_drv.h | 10 +
> drivers/gpu/drm/loongson/loongson_i2c.c | 280 ++
> drivers/gpu/drm/loongson/loongson_i2c.h | 38 +++
> 6 files changed, 410 insertions(+), 7 deletions(-)
> create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_i2c.h
>
> diff --git a/drivers/gpu/drm/loongson/Makefile
> b/drivers/gpu/drm/loongson/Makefile
> index 22d063953b78..773b806e99a2 100644
> --- a/drivers/gpu/drm/loongson/Makefile
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -10,5 +10,6 @@ loongson-y := loongson_drv.o \
> loongson_plane.o \
> loongson_device.o \
> loongson_connector.o \
> - loongson_encoder.o
> + loongson_encoder.o \
> + loongson_i2c.o
> obj-$(CONFIG_DRM_LOONGSON) += loongson.o
> diff --git a/drivers/gpu/drm/loongson/loongson_connector.c
> b/drivers/gpu/drm/loongson/loongson_connector.c
> index 6b1f0ffa33bd..2096a6ddc366 100644
> --- a/drivers/gpu/drm/loongson/loongson_connector.c
> +++ b/drivers/gpu/drm/loongson/loongson_connector.c
> @@ -4,12 +4,65 @@
>
> static int loongson_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct loongson_connector *lconnector;
> + struct i2c_adapter *adapter;
> + struct edid *edid = NULL;
> + u32 ret;
> +
> + lconnector = to_loongson_connector(connector);
> + adapter = lconnector->i2c->adapter;
>
> - count = drm_add_modes_noedid(connector, 1920, 1080);
> - drm_set_preferred_mode(connector, 1024, 768);
> + if (adapter != NULL)
> + edid = drm_get_edid(connector, adapter);
> + else
> + DRM_DEBUG_KMS("get loongson connector adapter err\n");
>
> - return count;
> + if (edid) {
> + drm_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + } else {
> + DRM_ERROR("Failed to read EDID\n");
> + ret = drm_add_modes_noedid(connector, 1024, 768);
> + }
> +
> + return ret;
> +}
> +
> +static bool is_connected(struct loongson_connector *ls_connector)
> +{
> + unsigned char start = 0x0;
> + struct i2c_adapter *adapter;
> + struct i2c_msg msgs = {
> + .addr = DDC_ADDR,
> + .flags = 0,
> + .len = 1,
> + .buf = &start,
> + };
> +
> + if (!ls_connector->i2c)
> + return false;
> +
> + adapter = ls_connector->i2c->adapter;
> + if (i2c_transfer(adapter, &msgs, 1) != 1) {
> + DRM_DEBUG_KMS("display-%d not connect\n", ls_connector->id);
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static enum drm_connector_status
> +loongson_detect(struct drm_connector *connector, bool force)
> +{
> + struct loongson_connector *lconnector;
> + enum drm_connector_status ret = connector_status_disconnected;
> +
> + lconnector = to_loongson_connector(connector);
> +
> + if (is_connected(lconnector))
> + ret = connector_status_connected;
> +
> + return ret;
> }
>
> static const struct drm_connector_helper_funcs loongson_connector_helper = {
> @@ -17,6 +70,7 @@ static const struct drm_connector_helper_funcs
> loongson_connector_helper = {
> };
>
> static const struct drm_connector_funcs loongson_connector_funcs = {
> + .detect = loongson_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = drm_connector_cleanup,
> .reset = drm_atomic_helper_connector_reset,
> @@ -37,11 +91,17 @@ int loongson_connector_init(struct loongson_device *ldev,
> int index)
>
> lconnector->ldev = ldev;
> lconnector->id = index;
> + lconnector->i2c_id = index + DC_I2C_BASE;
> +
> + lconnector->i2c = loongson_i2c_bus_match(ldev, lconnector->i2c_id);
> + if (!lconnector->i2c)
> + DRM_INFO("connector-%d match i2c-%d err\n", index,
> + lconnector->i2c_id);
>
> ldev->mode_info[index].connector = lconnector;
> connector = &lconnector->base;
> drm_connector_init(ldev->dev, connector, &loongson_connector_funcs,
> - DRM_MODE_CONNECTOR_Unknown);
> + DRM_MODE_CONNECTOR_Unknown);
> drm_connector_helper_add(connector, &loongson_connector_helper);
>
> return 0;
> diff --git a/drivers/gpu/drm/loongson/loongson_drv.c
> b/drivers/gpu/drm/loongson/loongson_drv.c
> index e405199a3df6..252be9e25aff 100644
> --- a/drivers/gpu/drm/loongson/loongson_drv.c
> +++ b/drivers/gpu/drm/loongson/loongson_drv.c
> @@ -11,9 +11,10 @@
>
> /* Interface history:
> * 0.1 - original.
> + * 0.2 - add i2c and connector detect.
> */
> #define DRIVER_MAJOR 0
> -#define DRIVER_MINOR 1
> +#define DRIVER_MINOR 2
>
> static const struct drm_mode_config_funcs loongson_mode_funcs = {
> .fb_create = drm_gem_fb_create,
> @@ -31,6 +32,7 @@ static int loongson_device_init(struct drm_device *dev,
> uint32_t
[PATCH] drm: Only select I2C_ALGOBIT for drivers that actually need it
While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even tough only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-König --- drivers/gpu/drm/Kconfig | 5 - drivers/gpu/drm/ast/Kconfig | 2 ++ drivers/gpu/drm/gma500/Kconfig | 2 ++ drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++ drivers/gpu/drm/i915/Kconfig| 2 ++ drivers/gpu/drm/mgag200/Kconfig | 2 ++ drivers/gpu/drm/nouveau/Kconfig | 2 ++ 7 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3c16bd1afd87..351ea617c498 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,7 +12,6 @@ menuconfig DRM select HDMI select FB_CMDLINE select I2C - select I2C_ALGOBIT select DMA_SHARED_BUFFER select SYNC_FILE # gallium uses SYS_kcmp for os_same_file_description() to de-duplicate @@ -233,6 +232,8 @@ config DRM_RADEON select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -254,6 +255,8 @@ config DRM_AMDGPU select DRM_SCHED select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig index fbcf2f45cef5..bcc25decd485 100644 --- a/drivers/gpu/drm/ast/Kconfig +++ b/drivers/gpu/drm/ast/Kconfig @@ -6,6 +6,8 @@ config DRM_AST select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Say yes for experimental AST GPU driver. Do not enable this driver without having a working -modesetting, diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..e26c3a24955d 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,6 +3,8 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig index 43943e980203..ac8c42dc79f6 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -6,6 +6,8 @@ config DRM_HISI_HIBMC select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Choose this option if you have a Hisilicon Hibmc soc chipset. If M is selected the module will be called hibmc-drm. diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 69f57ca9c68d..b3bb6f7cfbbc 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -13,6 +13,8 @@ config DRM_I915 select DRM_PANEL select DRM_MIPI_DSI select RELAY + select I2C + select I2C_ALGOBIT select IRQ_WORK # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig index eec59658a938..b28c5e4828f4 100644 --- a/drivers/gpu/drm/mgag200/Kconfig +++ b/drivers/gpu/drm/mgag200/Kconfig @@ -4,6 +4,8 @@ config DRM_MGAG200 depends on DRM && PCI && MMU select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT help This is a KMS driver for Matrox G200 chips. It supports the original MGA G200 desktop chips and the server variants. It requires 0.3.0 diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 9436310d0854..8823f0b24c73 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -7,6 +7,8 @@ config DRM_NOUVEAU select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT select X86_PLATFORM_DEVICES if ACPI && X86 base-commit: 315d99318179b9cd5077ccc9f7f26a164c9fa998 -- 2.30.2
Re: [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature
On Wed, May 12, 2021 at 09:18:37PM +, Kasireddy, Vivek wrote: > Hi Gerd, > > > > However, as part of this feature (explicit flush), I'd like to make the > > > Guest wait until > > > the current resource (as specified by resource_flush or set_scanout) is > > > flushed or > > > synchronized. But for a different feature I am thinking of (explicit > > > sync), I'd like to > > > make the Guest wait for the previous buffer/resource submitted (available > > > via > > > old_state->fb). > > > > For page-flipping I guess? i.e. you want submit a new framebuffer, then > > wait until the host doesn't need the previous one? That is likewise > > linked to a command, although it is set_scanout this time. > [Kasireddy, Vivek] Mainly for page-flipping but I'd also like to have fbcon, > Xorg that > do frontbuffer rendering/updates to work seamlessly as well. > > > > > So, right now qemu simply queues the request and completes the command > > when a guest sends a resource_flush our set_scanout command. You want > > be notified when the host is actually done processing the request. > [Kasireddy, Vivek] Correct, that is exactly what I want -- make the Guest wait > until it gets notified that the Host is completely done processing/using the > fb. > However, there can be two resources the guest can be made to wait on: wait for > the new/current fb that is being submitted to be processed (explicit flush) That would be wait on resource_flush case, right? > or wait for the previous fb that was submitted earlier (in the > previous repaint cycle) to be processed (explicit sync). That would be the wait on set_scanout case, right? And it would effectively wait on the previous fb not being needed by the host any more (because the page-flip to the new fb completed) so the guest can re-use the previous fb to render the next frame, right? (also when doing front-buffer rendering with xorg/fbcon and then doing a virtual console switch the guest could wait for the console switch being completed). > IIUC, Explicit sync only makes sense if 1) the Host windowing system also > supports > that feature/protocol (currently only upstream Weston does but I'd like to > add it to > Mutter if no one else does) or if there is a way to figure out (dma-buf sync > file?) if > the Host has completely processed the fb and 2) if Qemu UI is not doing a > blit and > instead submitting the guest fb/dmabuf directly to the Host windowing system. > As you are aware, 2) can possibly be done with dbus/pipewire Qemu UI backends > (I'll explore this soon) but not with GTK or SDL. Well, I think we need to clearly define the wait flag semantics. Should resource_flush with wait flag wait until the host is done reading the resource (blit done)? Or should it wait until the host screen has been updated (gtk draw callback completed)? Everything else will be a host/guest implementation detail then, and of course this needs some integration with the UI on the host side and different UIs might have to do different things. On the guest side integrating this with fences will give us enough flexibility on how we want handle the waits. Simplest would be to just block. We could implement virtual vblanks, which would probably make most userspace work fine without explicit virtio-gpu support. If needed we could even give userspace access to the fence so it can choose how to wait. take care, Gerd
[PATCH 0/4] Fix the i2c/clk bug of stm32 mcu platform
From: Dillon Min
This seriese fix three i2c/clk bug for stm32 f4/f7
- kernel runing in sdram, i2c driver get data timeout
- ltdc clk turn off after kernel console active
- kernel hang in set ltdc clock rate
clk bug found on stm32f429/f469-disco board
Hi Patrice:
below is the guide to verify the patch:
setup test env with following files(link at below 'files link'):
[1] u-boot-dtb.bin
[2] rootfs zip file (used in kernel initramfs)
[3] u-boot's mkimage to create itb file
[4] kernel config file
[5] my itb with-or-without i2c patch
This patch based on kernel commit:
88b06399c9c766c283e070b022b5ceafa4f63f19
Note:
panel-ilitek-ili9341.c is the driver which was submitted last year, but not
get accepted. it's used to setup touch screen calibration, then test i2c.
create itb file(please correct path of 'data'):
./mkimage -f stm32.its stm32.itb
HW setup:
console:
PA9, PA10
usart0
serial@40011000
115200 8n1
-- flash u-boot.bin to stm32f429-disco on PC
$ sudo openocd -f board/stm32f429discovery.cfg -c \
'{PATH-TO-YOUR-UBOOT}/u-boot-dtb.bin 0x0800 exit reset'
-- setup kernel load bootargs at u-boot
U-Boot > setenv bootargs 'console=tty0 console=ttySTM0,115200
root=/dev/ram rdinit=/linuxrc loglevel=8 fbcon=rotate:2'
U-Boot > loady;bootm
(download stm32.dtb or your kernel with itb format, or download zImage, dtb)
-- setup ts_calibrate running env on stm32f429-disco
/ # export TSLIB_CONFFILE=/etc/ts.conf
/ # export TSLIB_TSDEVICE=/dev/input/event0
/ # export TSLIB_CONSOLEDEVICE=none
/ # export TSLIB_FBDEVICE=/dev/fb0
-- clear screen
/ # ./fb
-- run ts_calibrate
/ # ts_calibrate
(you can calibrate touchscreen now, and get below errors)
[ 113.942087] stmpe-i2c0-0041: failed to read regs 0x52: -110
[ 114.063598] stmpe-i2c 0-0041: failed to read reg 0x4b: -16
[ 114.185629] stmpe-i2c 0-0041: failed to read reg 0x40: -16
[ 114.307257] stmpe-i2c 0-0041: failed to write reg 0xb: -16
...
with i2c patch applied, you will find below logs:
RAW-> 3164 908 183 118.110884
TS_READ_RAW> x = 3164, y =908, pressure = 183
RAW-> 3166 922 126 118.138946
TS_READ_RAW> x = 3166, y = 922, pressure = 126
files link:
https://drive.google.com/drive/folders/1qNbjChcB6UGtKzne2F5x9_WG_sZFyo3o?usp=sharing
Dillon Min (4):
drm/panel: Add ilitek ili9341 panel driver
i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate
clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after
kernel startup
drivers/clk/clk-stm32f4.c| 10 +-
drivers/gpu/drm/panel/Kconfig| 12 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1285 ++
drivers/i2c/busses/i2c-stm32f4.c | 12 +-
5 files changed, 1310 insertions(+), 10 deletions(-)
create mode 100755 drivers/gpu/drm/panel/panel-ilitek-ili9341.c
--
2.7.4
[PATCH 1/4] drm/panel: Add ilitek ili9341 panel driver
From: Dillon Min This driver combine tiny/ili9341.c mipi_dbi_interface driver with mipi_dpi_interface driver, can support ili9341 with serial mode or parallel rgb interface mode by register configuration. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.min...@gmail.com/ Signed-off-by: Dillon Min --- drivers/gpu/drm/panel/Kconfig| 12 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1285 ++ 3 files changed, 1298 insertions(+) create mode 100755 drivers/gpu/drm/panel/panel-ilitek-ili9341.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 4894913936e9..e4babba17864 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -123,6 +123,18 @@ config DRM_PANEL_ILITEK_IL9322 Say Y here if you want to enable support for Ilitek IL9322 QVGA (320x240) RGB, YUV and ITU-T BT.656 panels. +config DRM_PANEL_ILITEK_ILI9341 + tristate "Ilitek ILI9341 240x320 QVGA panels" + depends on OF && SPI + depends on DRM_KMS_HELPER + depends on DRM_KMS_CMA_HELPER + depends on BACKLIGHT_CLASS_DEVICE + select DRM_MIPI_DBI + help + Say Y here if you want to enable support for Ilitek IL9341 + QVGA (240x320) RGB panels. support serial & parallel rgb + interface. + config DRM_PANEL_ILITEK_ILI9881C tristate "Ilitek ILI9881C-based panels" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index cae4d976c069..0ecde184665d 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c new file mode 100644 index ..f84983cbb250 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c @@ -0,0 +1,1285 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Ilitek ILI9341 TFT LCD drm_panel driver. + * + * This panel can be configured to support: + * - 16-bit parallel RGB interface + * - 18-bit parallel RGB interface + * - 4-line serial spi interface + * + * Copyright (C) 2020 Dillon Min + * Derived from drivers/drm/gpu/panel/panel-ilitek-ili9322.c + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define ILI9341_RGB_INTERFACE 0xb0 /* RGB Interface Signal Control */ +#define ILI9341_FRC0xb1 /* Frame Rate Control register */ +#define ILI9341_DFC0xb6 /* Display Function Control register */ +#define ILI9341_POWER1 0xc0 /* Power Control 1 register */ +#define ILI9341_POWER2 0xc1 /* Power Control 2 register */ +#define ILI9341_VCOM1 0xc5 /* VCOM Control 1 register */ +#define ILI9341_VCOM2 0xc7 /* VCOM Control 2 register */ +#define ILI9341_POWERA 0xcb /* Power control A register */ +#define ILI9341_POWERB 0xcf /* Power control B register */ +#define ILI9341_PGAMMA 0xe0 /* Positive Gamma Correction register */ +#define ILI9341_NGAMMA 0xe1 /* Negative Gamma Correction register */ +#define ILI9341_DTCA 0xe8 /* Driver timing control A */ +#define ILI9341_DTCB 0xea /* Driver timing control B */ +#define ILI9341_POWER_SEQ 0xed /* Power on sequence register */ +#define ILI9341_3GAMMA_EN 0xf2 /* 3 Gamma enable register */ +#define ILI9341_INTERFACE 0xf6 /* Interface control register */ +#define ILI9341_PRC0xf7 /* Pump ratio control register */ +#define ILI9341_ETMOD 0xb7 /* Entry mode set */ + +#define ILI9341_MADCTL_BGR BIT(3) +#define ILI9341_MADCTL_MV BIT(5) +#define ILI9341_MADCTL_MX BIT(6) +#define ILI9341_MADCTL_MY BIT(7) + + +#define ILI9341_POWER_B_LEN3 +#define ILI9341_POWER_SEQ_LEN 4 +#define ILI9341_DTCA_LEN 3 +#define ILI9341_DTCB_LEN 2 +#define ILI9341_POWER_A_LEN5 +#define ILI9341_DFC_1_LEN 2 +#define ILI9341_FRC_LEN2 +#define ILI9341_VCOM_1_LEN 2 +#define ILI9341_DFC_2_LEN 4 +#define ILI9341_COLUMN_ADDR_LEN4 +#define ILI9341_PAGE_ADDR_LEN 4 +#define ILI9341_INTERFACE_LEN
[PATCH 2/4] i2c: stm32f4: Fix stmpe811 get xyz data timeout issue
From: Dillon Min
As stm32f429's internal flash is 2Mbytes and compiled kernel
image bigger than 2Mbytes, so we have to load kernel image
to sdram on stm32f429-disco board which has 8Mbytes sdram space.
based on above context, as you knows kernel running on external
sdram is more slower than internal flash. besides, we need read 4
bytes to get touch screen xyz(x, y, pressure) coordinate data in
stmpe811 interrupt.
so, in stm32f4_i2c_handle_rx_done, as i2c read slower than running
in xip mode, have to adjust 'STOP/START bit set position' from last
two bytes to last one bytes. else, will get i2c timeout in reading
touch screen coordinate.
to not bring in side effect, introduce IIC_LAST_BYTE_POS to support xip
kernel or zImage.
Fixes: 62817fc8d282 ("i2c: stm32f4: add driver")
Link:
https://lore.kernel.org/lkml/1591709203-12106-5-git-send-email-dillon.min...@gmail.com/
Signed-off-by: Dillon Min
---
drivers/i2c/busses/i2c-stm32f4.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index 4933fc8ce3fd..2e41231b9037 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -93,6 +93,12 @@
#define STM32F4_I2C_MAX_FREQ 46U
#define HZ_TO_MHZ 100
+#if !defined(CONFIG_MMU) && !defined(CONFIG_XIP_KERNEL)
+#define IIC_LAST_BYTE_POS 1
+#else
+#define IIC_LAST_BYTE_POS 2
+#endif
+
/**
* struct stm32f4_i2c_msg - client specific data
* @addr: 8-bit slave addr, including r/w bit
@@ -439,7 +445,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
int i;
switch (msg->count) {
- case 2:
+ case IIC_LAST_BYTE_POS:
/*
* In order to correctly send the Stop or Repeated Start
* condition on the I2C bus, the STOP/START bit has to be set
@@ -454,7 +460,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
else
stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
- for (i = 2; i > 0; i--)
+ for (i = IIC_LAST_BYTE_POS; i > 0; i--)
stm32f4_i2c_read_msg(i2c_dev);
reg = i2c_dev->base + STM32F4_I2C_CR2;
@@ -463,7 +469,7 @@ static void stm32f4_i2c_handle_rx_done(struct
stm32f4_i2c_dev *i2c_dev)
complete(&i2c_dev->complete);
break;
- case 3:
+ case (IIC_LAST_BYTE_POS+1):
/*
* In order to correctly generate the NACK pulse after the last
* received data byte, we have to enable NACK before reading N-2
--
2.7.4
[PATCH 3/4] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate
From: Dillon Min
This is due to misuse ‘PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
'PLL_SAI' is 2, 'PLL_VCO_SAI' is 7(defined in
include/dt-bindings/clock/stm32fx-clock.h).
'post_div' point to 'post_div_data[]', 'post_div->pll_num'
is PLL_I2S or PLL_SAI.
'clks[PLL_VCO_SAI]' has valid 'struct clk_hw* ' return
from stm32f4_rcc_register_pll() but, at line 1777 of
driver/clk/clk-stm32f4.c, use the 'clks[post_div->pll_num]',
equal to 'clks[PLL_SAI]', this is invalid array member at that time.
Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs")
Signed-off-by: Dillon Min
Acked-by: Stephen Boyd
Link:
https://lore.kernel.org/linux-arm-kernel/1590564453-24499-6-git-send-email-dillon.min...@gmail.com/
---
drivers/clk/clk-stm32f4.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 18117ce5ff85..42ca2dd86aea 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -557,13 +557,13 @@ static const struct clk_div_table post_divr_table[] = {
#define MAX_POST_DIV 3
static const struct stm32f4_pll_post_div_data post_div_data[MAX_POST_DIV] = {
- { CLK_I2SQ_PDIV, PLL_I2S, "plli2s-q-div", "plli2s-q",
+ { CLK_I2SQ_PDIV, PLL_VCO_I2S, "plli2s-q-div", "plli2s-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 0, 5, 0, NULL},
- { CLK_SAIQ_PDIV, PLL_SAI, "pllsai-q-div", "pllsai-q",
+ { CLK_SAIQ_PDIV, PLL_VCO_SAI, "pllsai-q-div", "pllsai-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 8, 5, 0, NULL },
- { NO_IDX, PLL_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
+ { NO_IDX, PLL_VCO_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
STM32F4_RCC_DCKCFGR, 16, 2, 0, post_divr_table },
};
--
2.7.4
[PATCH 4/4] clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup
From: Dillon Min
stm32's clk driver register two ltdc gate clk to clk core by
clk_hw_register_gate() and clk_hw_register_composite()
first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
both of them point to the same offset of stm32's RCC register. after
kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]'
is no one to use. but, actually 'stm32f429_aux_clk[]' is in use.
Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
Signed-off-by: Dillon Min
Acked-by: Stephen Boyd
Link:
https://lore.kernel.org/linux-arm-kernel/1590564453-24499-7-git-send-email-dillon.min...@gmail.com/
---
drivers/clk/clk-stm32f4.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 42ca2dd86aea..f4156a8a6041 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -129,7 +129,6 @@ static const struct stm32f4_gate_data stm32f429_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
@@ -211,7 +210,6 @@ static const struct stm32f4_gate_data stm32f469_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f746_gates[] __initconst = {
@@ -286,7 +284,6 @@ static const struct stm32f4_gate_data stm32f746_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 23, "sai2", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
static const struct stm32f4_gate_data stm32f769_gates[] __initconst = {
@@ -364,7 +361,6 @@ static const struct stm32f4_gate_data stm32f769_gates[]
__initconst = {
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 23, "sai2", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 30, "mdio", "apb2_div" },
};
--
2.7.4
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On 06/05/2021 20:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following RFC [1]. At a very high level the GuC is a piece of firmware which sits between the i915 and the GPU. It offloads some of the scheduling of contexts from the i915 and programs the GPU to submit contexts. The i915 communicates with the GuC and the GuC communicates with the GPU. GuC submission will be disabled by default on all current upstream platforms behind a module parameter - enable_guc. A value of 3 will enable submission and HuC loading via the GuC. GuC submission should work on all gen11+ platforms assuming the GuC firmware is present. Some thoughts mostly relating to future platforms where GuC will be the only option, and to some extent platforms where it will be possible to turn it on for one reason or another. Debuggability - in the context of having an upstream way/tool for capturing and viewing GuC logs usable for attaching to bug reports. Currently i915 logs, can provide traces via tracepoints and trace printk, and GPU error capture state, which provides often sufficient trail of evidence to debug issues. We need to make sure GuC does is not a black box in this respect. By this I mean it does not hide a large portion of the execution flows from upstream observability. This could mean a tool in IGT to access/capture GuC logs and update bug filing instructions. Leading from here is probably the need for the GuC firmware team to cross the internal-upstream boundary and deal with such bug reports on upstream trackers. Upstream GuC is unlikely to work if we don't have such plan and commitment. Also leading from here is the need for GPU error capture to be on par from day one which is I believe still not there in the firmware. Another, although unrelated, missing feature on my wish list is firmware support for wiring up accurate engine busyness stats to i915 PMU. I believe this is also being worked on but I don't know when is the expected delivery. If we are tracking a TODO list of items somewhere I think these ones should be definitely considered. Regards, Tvrtko
Re: [PATCH v6 2/5] drm/dp: Allow an early call to register DDC i2c bus
On Fri, 07 May 2021, Lyude Paul wrote:
> On Fri, 2021-05-07 at 17:00 -0500, Bjorn Andersson wrote:
>> On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
>>
>> > Adding ville from Intel to also get their take on this.
>> >
>> > In general we've been trying to move DRM to a design where we don't expose
>> > any
>> > devices until everything is ready. That's pretty much the main reason that
>> > we
>> > register things during bridge attach time. Note though that even before
>> > the
>> > DDC bus is registered it should still be usable, just things like
>> > get_device()
>> > won't work.
>> >
>> > This isn't the first time we've run into a problem like the one you're
>> > trying
>> > to solve though, Tegra currently has a similar issue. Something we
>> > discussed
>> > as a possible long-term solution for this was splitting i2c_add_adapter()
>> > into
>> > a minimal initialization function and a registration function. Linux's
>> > device
>> > core already allows for this (device_initialize() and device_add(), which
>> > are
>> > called together when device_register() is called). Would this be a
>> > solution
>> > that might work for you (and even better, would you possibly be willing to
>> > write the patches? :)
>> >
>>
>> It's not enough that the adapter is half-baked, because the bridge's
>> initialization depends on that the panel device is done probing, and the
>> panel driver will only complete its probe if it can find it's resources.
>>
>> So we need a mechanism to fully create the resources exposed by the
>> bridge chip (i2c bus, gpio chip and (soon) a pwm chip), then allow the
>> panel to probe and after that initialize the bridge.
>>
>> We did discuss possible ways to register these resources and then
>> "sleep for a while" before resolving the panel, but what we came up with
>> was definitely suboptimal - and ugly.
>
> Sigh, I'm really starting to wonder if we should reconsider the rules on
> exposing ddc adapters early...
>
> Danvet, Jani, and/or airlied: can I get your take on this?
Granted, I did not study this in detail, but it sounds like we'd need to
be able to add and use an i2c adapter in kernel, before deciding to
register it with the userspace. But that does not seem to be as trivial
as making it possible to call the now-static i2c_register_adapter()
separately.
BR,
Jani.
>
>>
>> Regards,
>> Bjorn
>>
>> > On Mon, 2021-05-03 at 14:58 -0700, Douglas Anderson wrote:
>> > > It can be helpful to fully register the AUX channel as an i2c bus even
>> > > before the bridge is created. Let's optionally allow bridges to do
>> > > that.
>> > >
>> > > Specifically the case we're running into:
>> > > - The panel driver wants to get its DDC bus at probe time.
>> > > - The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the DDC
>> > > bus, wants to get the panel at probe time.
>> > >
>> > > The next patches ("drm/bridge: ti-sn65dsi86: Promote the AUX channel
>> > > to its own sub-dev") solves the chicken-and-egg problem by breaking
>> > > the ti-sn65dsi86 driver into sub-devices, but in order for it to
>> > > actually work we need the i2c bus to get registered at probe time and
>> > > not in bridge attach time.
>> > >
>> > > Cc: Lyude Paul
>> > > Cc: Thierry Reding
>> > > Signed-off-by: Douglas Anderson
>> > > ---
>> > >
>> > > Changes in v6:
>> > > - ("drm/dp: Allow an early call to register DDC i2c bus") new for v6.
>> > >
>> > > drivers/gpu/drm/drm_dp_helper.c | 67 +++--
>> > > include/drm/drm_dp_helper.h | 2 +
>> > > 2 files changed, 57 insertions(+), 12 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> > > b/drivers/gpu/drm/drm_dp_helper.c
>> > > index cb56d74e9d38..830294f0b341 100644
>> > > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > > @@ -1757,6 +1757,49 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
>> > > }
>> > > EXPORT_SYMBOL(drm_dp_aux_init);
>> > >
>> > > +/**
>> > > + * drm_dp_aux_register_ddc() - register the DDC parts of the aux
>> > > channel
>> > > + * @aux: DisplayPort AUX channel
>> > > + *
>> > > + * This can be called after drm_dp_aux_init() to fully register the ddc
>> > > bus
>> > > + * as an i2c adapter with the rest of Linux.
>> > > + *
>> > > + * If you don't explicitly call this function it will be done
>> > > implicitly as
>> > > + * part of drm_dp_aux_register().
>> > > + *
>> > > + * Returns 0 on success or a negative error code on failure.
>> > > + */
>> > > +int drm_dp_aux_register_ddc(struct drm_dp_aux *aux)
>> > > +{
>> > > + WARN_ON_ONCE(!aux->dev);
>> > > +
>> > > + aux->ddc.class = I2C_CLASS_DDC;
>> > > + aux->ddc.owner = THIS_MODULE;
>> > > + aux->ddc.dev.parent = aux->dev;
>> > > +
>> > > + strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux-
>> > > >dev),
>> > > + sizeof(aux->ddc.name));
>> > > +
>> > > + return i2c_add_adapter(&aux->ddc);
>> > > +}
>> > > +EXPORT_SYMBOL(
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
> On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote: >> I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely >> on the US-intl keyboard settings, that allow me to type as "'a" for á. >> However, there's no shortcut for non-Latin UTF-codes, as far as I know. >> >> So, if would need to type a curly comma on the text editors I normally >> use for development (vim, nano, kate), I would need to cut-and-paste >> it from somewhere For anyone who doesn't know about it: X has this wonderful thing called the Compose key[1]. For instance, type ⎄--- to get —, or ⎄<" for “. Much more mnemonic than Unicode codepoints; and you can extend it with user-defined sequences in your ~/.XCompose file. (I assume Wayland supports all this too, but don't know the details.) On 14/05/2021 10:06, David Woodhouse wrote: > Again, if you want to make specific fixes like removing non-breaking > spaces and byte order marks, with specific reasons, then those make > sense. But it's got very little to do with UTF-8 and how easy it is to > type them. And the excuse you've put in the commit comment for your > patches is utterly bogus. +1 -ed [1] https://en.wikipedia.org/wiki/Compose_key
Re: [PATCH v1 1/1] video: ssd1307fb: Drop OF dependency
On Fri, Apr 16, 2021 at 05:42:04PM +0300, Andy Shevchenko wrote: > +Cc: Greg. > > Greg, can you pick up this one? > > The subsystem seems orphaned and I see your name in the git history for the > recent submissions against that driver. Now applied, thanks. greg k-h
Re: linux-next: manual merge of the drm-intel tree with the drm tree
Hi
Am 14.05.21 um 03:53 schrieb Stephen Rothwell:
Hi all,
On Fri, 30 Apr 2021 08:23:21 +1000 Stephen Rothwell
wrote:
On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
wrote:
On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_sprite.c
between commit:
92f1d09ca4ed ("drm: Switch to %p4cc format modifier")
from the drm tree and commit:
46d12f911821 ("drm/i915: migrate skl planes code new file (v5)")
from the drm-intel tree.
I fixed it up (I used the latter version of the file and applied the
following patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted
for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Wed, 17 Mar 2021 14:05:42 +1100
Subject: [PATCH] merge fix for "drm: Switch to %p4cc format modifier"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 1f335cb09149..45ceff436bf7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1120,7 +1120,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
- struct drm_format_name_buf format_name;
if (!fb)
return 0;
@@ -1168,9 +1167,8 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_XVYU12_16161616:
case DRM_FORMAT_XVYU16161616:
drm_dbg_kms(&dev_priv->drm,
- "Unsupported pixel format %s for 90/270!\n",
- drm_get_format_name(fb->format->format,
- &format_name));
+ "Unsupported pixel format %p4cc for
90/270!\n",
+ &fb->format->format);
return -EINVAL;
default:
break;
--
2.30.0
The above fix up patch now needs to be applied to the drm tree.
I am still applying the above patch, but it applies to Linus' tree now.
I am going to stop applying this. You guys can apply it if you want to
some time.
Sorry, this got lost several times. I've applied your patch to
drm-misc-next now. Thanks a lot.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver
Maxime Ripard 于2021年4月30日周五 下午5:22写道： > > On Sun, Apr 25, 2021 at 08:36:05PM +0800, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display > > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > > > v2: > > - Use drm_xxx to replace all DRM_XXX. > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > v3: > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > > > v4: > > - Use drmm_helpers to allocate crtc and planes. > > - Move rotation enum definitions to crtc layer reg bitfields. > > - Move allocate crtc and planes to bind function. > > > > v5: > > - Fix the checkpatch warnings. > > - Use mode_set_nofb instead of mode_valid callback. > > - Follow the OF-Graph bindings, use of_graph_get_port_by_id > > instead of of_parse_phandle. > > - Use zpos to represent the layer position. > > - Rebase to last drm misc branch. > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > --- > > drivers/gpu/drm/sprd/Kconfig| 1 + > > drivers/gpu/drm/sprd/Makefile | 3 +- > > drivers/gpu/drm/sprd/sprd_dpu.c | 939 > > drivers/gpu/drm/sprd/sprd_dpu.h | 109 > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 6 files changed, 1054 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > index 726c3e76d..37762c333 100644 > > --- a/drivers/gpu/drm/sprd/Kconfig > > +++ b/drivers/gpu/drm/sprd/Kconfig > > @@ -5,6 +5,7 @@ config DRM_SPRD > > select DRM_GEM_CMA_HELPER > > select DRM_KMS_CMA_HELPER > > select DRM_KMS_HELPER > > + select VIDEOMODE_HELPERS > > help > > Choose this option if you have a Unisoc chipset. > > If M is selected the module will be called sprd_drm. > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > > index 9850f00b8..ab12b95e6 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -1,3 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-y := sprd_drm.o > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > > b/drivers/gpu/drm/sprd/sprd_dpu.c > > new file mode 100644 > > index 0..e74c3dbb3 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > @@ -0,0 +1,939 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_drm.h" > > +#include "sprd_dpu.h" > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1F8 > > + > > +/* MMU control registers */ > > +#define REG_MMU_EN 0x800 > > +#define REG_MMU_VPN_RANGE0x80C > > +#define REG_MMU_VAOR_ADDR_RD 0x818 > > +#define REG_MMU_VAOR_ADDR_WR 0x81C > > +#define REG_MMU_INV_ADDR_RD 0x820 > > +#define REG_MMU_INV_ADDR_WR 0x824 > > +#define REG_MMU_PPN1 0x83C > > +#define REG_MMU_RANGE1 0x840 > > +#define REG_MMU_PPN2 0x844 > > +#define REG_MMU_RANGE2 0x848 > > + > > +/* Global control bits */ > > +#define BIT_DPU_RUN BIT(0) > > +#define BIT_DPU_STOP BIT(1) > > +#define BIT_DPU_REG_UPDATE BIT(2) > > +#define BIT_DPU_IF_EDPI BIT(0) > > + > > +/* Layer control bits */ > > +#define BIT_DPU_LAY_EN BIT(0) > > +#define BIT_DPU_LAY_LAYER_ALPHA (0x01 << 2) > > +#define BIT_DPU_LAY_COMBO_ALPHA
Re: [PATCH v2] drm/i915/gem: Pin the L-shape quirked object as unshrinkable
On Thu, May 13, 2021 at 01:07:56PM +0100, Matthew Auld wrote:
> From: Chris Wilson
>
> When instantiating a tiled object on an L-shaped memory machine, we mark
> the object as unshrinkable to prevent the shrinker from trying to swap
> out the pages. We have to do this as we do not know the swizzling on the
> individual pages, and so the data will be scrambled across swap out/in.
>
> Not only do we need to move the object off the shrinker list, we need to
> mark the object with shrink_pin so that the counter is consistent across
> calls to madvise.
>
> v2: in the madvise ioctl we need to check if the object is currently
> shrinkable/purgeable, not if the object type supports shrinking
>
> Fixes: 0175969e489a ("drm/i915/gem: Use shrinkable status for unknown swizzle
> quirks")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3293
> Reported-by: Ville Syrjälä
> Signed-off-by: Chris Wilson
> Signed-off-by: Matthew Auld
This one seems to fare better than v1.
Tested-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 11 +--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index aed8a37ccdc9..7361971c177d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -63,6 +63,8 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> i915->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
> GEM_BUG_ON(i915_gem_object_has_tiling_quirk(obj));
> i915_gem_object_set_tiling_quirk(obj);
> + GEM_BUG_ON(!list_empty(&obj->mm.link));
> + atomic_inc(&obj->mm.shrink_pin);
> shrinkable = false;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d0018c5f88bd..cffd7f4f87dc 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1009,12 +1009,11 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
> obj->mm.madv = args->madv;
>
> if (i915_gem_object_has_pages(obj)) {
> - struct list_head *list;
> + unsigned long flags;
>
> - if (i915_gem_object_is_shrinkable(obj)) {
> - unsigned long flags;
> -
> - spin_lock_irqsave(&i915->mm.obj_lock, flags);
> + spin_lock_irqsave(&i915->mm.obj_lock, flags);
> + if (!list_empty(&obj->mm.link)) {
> + struct list_head *list;
>
> if (obj->mm.madv != I915_MADV_WILLNEED)
> list = &i915->mm.purge_list;
> @@ -1022,8 +1021,8 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
> list = &i915->mm.shrink_list;
> list_move_tail(&obj->mm.link, list);
>
> - spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
> }
> + spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
> }
>
> /* if the object is no longer attached, discard its backing storage */
> --
> 2.26.3
--
Ville Syrjälä
Intel
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 09:04, Christian König wrote: Well in my opinion exposing it through fdinfo turned out to be a really clean approach. It describes exactly the per file descriptor information we need. Yeah fdinfo certainly is mostly simple and neat. I say mostly because main problem I see with it is discoverability. Alex commented in another sub-thread - "If you know the process, you can look it up in procfs." - so that's fine for introspection but a bit challenging for a top(1) like tool. David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Top level hierarchy is under /sys/class/drm/card0/clients/ and each opened drm fd gets a directory in there. Process data I expose there are the name and pid, but these are for convenience, not as a primary information. But yes, I agree this part of the approach is definitely questionable. (As a side note, I am not sure if I could put a symlink to proc in there. I think sysfs and symlinks did not really work.) Another data point is that this "client root" we think would be useful for adding other stuff in the future. For instance per client debug log stream is occasionally talked about. Making that device driver independent is potentially useful as well. Alternative to my sysfs approach, the idea of exposing this in proc was floated by Chris in this series https://patchwork.freedesktop.org/series/86692/. That would be generic enough so any GPU vendor can slot in, and common enough that GPU agnostic tools should be able to use it. Modulo some discussion around naming the "channels" (GPU engines) or not. It wouldn't be able to support things like the before mentioned per client debug log stream but I guess that's not the most important thing. Most important would be allowing GPU usage to be wired to top(1) like tools which is probably even overdue given the modern computing landscape. Would you guys be interested to give a more detailed look over both proposals and see if any would interest you? Regards, Tvrtko Regards, Christian. Am 14.05.21 um 09:22 schrieb Nieto, David M: [AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. *From:* Alex Deucher *Sent:* Thursday, May 13, 2021 10:58 PM *To:* Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian *Cc:* Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter *Subject:* Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz; 0% RC6; 5.30 Watts; 933 irqs/s > >> > >> IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >> ENGINE BUSY MI_SEMA MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% 0% > >> Blitter/0 0.00% | | 0% 0% > >> Video/0 0.00% | | 0% 0% > >> VideoEnhance/0 0.00% | | 0% 0% > >> > >> PID NAME Render/3D Blitter Video VideoEnhance > >> 2733 neverball |██▌ || || || | > >> 2047 Xorg |███▊ || || || | > >> 2737 glxgears |█▍ || || || | > >> 2128 xfwm4 | || || || | > >> 2047 Xorg | || || || | > >> > >> > >> Internally we track time spent on engines for each struct intel_context, both > >> for current and past contexts belonging to each open DRM file. > >> > >> This can serve as a building block for several features from the wanted list: > >> smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality >
Re: [PATCH 0/7] Per client engine busyness
David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. So even with sysfs aid for discovery you are back to just going over all files again. Regards, Christian. Am 14.05.21 um 15:42 schrieb Tvrtko Ursulin: On 14/05/2021 09:04, Christian König wrote: Well in my opinion exposing it through fdinfo turned out to be a really clean approach. It describes exactly the per file descriptor information we need. Yeah fdinfo certainly is mostly simple and neat. I say mostly because main problem I see with it is discoverability. Alex commented in another sub-thread - "If you know the process, you can look it up in procfs." - so that's fine for introspection but a bit challenging for a top(1) like tool. David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Top level hierarchy is under /sys/class/drm/card0/clients/ and each opened drm fd gets a directory in there. Process data I expose there are the name and pid, but these are for convenience, not as a primary information. But yes, I agree this part of the approach is definitely questionable. (As a side note, I am not sure if I could put a symlink to proc in there. I think sysfs and symlinks did not really work.) Another data point is that this "client root" we think would be useful for adding other stuff in the future. For instance per client debug log stream is occasionally talked about. Making that device driver independent is potentially useful as well. Alternative to my sysfs approach, the idea of exposing this in proc was floated by Chris in this series https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F86692%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C69e215ff2b434ba36ecc08d916de1754%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637565965394961215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JsARknf2q%2FwtGfgLM6ZUOSkaivV%2B6yakpqYh%2B6yQlEc%3D&reserved=0. That would be generic enough so any GPU vendor can slot in, and common enough that GPU agnostic tools should be able to use it. Modulo some discussion around naming the "channels" (GPU engines) or not. It wouldn't be able to support things like the before mentioned per client debug log stream but I guess that's not the most important thing. Most important would be allowing GPU usage to be wired to top(1) like tools which is probably even overdue given the modern computing landscape. Would you guys be interested to give a more detailed look over both proposals and see if any would interest you? Regards, Tvrtko Regards, Christian. Am 14.05.21 um 09:22 schrieb Nieto, David M: [AMD Official Use Only - Internal Distribution Only] We had entertained the idea of exposing the processes as sysfs nodes as you proposed, but we had concerns about exposing process info in there, especially since /proc already exists for that purpose. I think if you were to follow that approach, we could have tools like top that support exposing GPU engine usage. *From:* Alex Deucher *Sent:* Thursday, May 13, 2021 10:58 PM *To:* Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian *Cc:* Intel Graphics Development ; Maling list - DRI developers ; Daniel Vetter *Subject:* Re: [PATCH 0/7] Per client engine busyness + David, Christian On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin wrote: > > > Hi, > > On 13/05/2021 16:48, Alex Deucher wrote: > > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin > > wrote: > >> > >> From: Tvrtko Ursulin > >> > >> Resurrect of the previosuly merged per client engine busyness patches. In a > >> nutshell it enables intel_gpu_top to be more top(1) like useful and show not > >> only physical GPU engine usage but per process view as well. > >> > >> Example screen capture: > >> > >> intel-gpu-top - 906/ 955 MHz; 0% RC6; 5.30 Watts; 933 irqs/s > >> > >> IMC reads: 4414 MiB/s > >> IMC writes: 3805 MiB/s > >> > >> ENGINE BUSY MI_SEMA MI_WAIT > >> Render/3D/0 93.46% |▋ | 0% 0
[PATCH] drm/tegra: fix 32-bit DMA address calculation
From: Arnd Bergmann
gcc points out an invalid bit shift operation on 32-bit architectures
with 64-bit dma_addr_t:
drivers/gpu/drm/tegra/hub.c: In function 'tegra_shared_plane_atomic_update':
include/vdso/bits.h:7:40: error: left shift count >= width of type
[-Werror=shift-count-overflow]
7 | #define BIT(nr) (UL(1) << (nr))
|^~
drivers/gpu/drm/tegra/hub.c:513:25: note: in expansion of macro 'BIT'
513 | base |= BIT(39);
| ^~~
Use the correct BIT_ULL() macro to always generate a 64-bit mask.
Fixes: 7b6f846785f4 ("drm/tegra: Support sector layout on Tegra194")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/tegra/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 79bff8b48271..bfae8a02f55b 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -510,7 +510,7 @@ static void tegra_shared_plane_atomic_update(struct
drm_plane *plane,
* dGPU sector layout.
*/
if (tegra_plane_state->tiling.sector_layout ==
TEGRA_BO_SECTOR_LAYOUT_GPU)
- base |= BIT(39);
+ base |= BIT_ULL(39);
#endif
tegra_plane_writel(p, tegra_plane_state->format, DC_WIN_COLOR_DEPTH);
--
2.29.2
[bug report] drm: remove usage of drm_pci_alloc/free
Hello Joseph Kogut,
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
from Apr 22, 2021, leads to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '&dev->struct_mutex'.
Locked on : 988
Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
drivers/gpu/drm/drm_bufs.c
965 temp_pagelist = kmalloc_array(dma->page_count + (count <<
page_order),
966sizeof(*dma->pagelist),
967GFP_KERNEL);
968 if (!temp_pagelist) {
969 kfree(entry->buflist);
970 kfree(entry->seglist);
971 mutex_unlock(&dev->struct_mutex);
972 atomic_dec(&dev->buf_alloc);
973 return -ENOMEM;
There is a bunch of clean up happenning on the existing returns.
974 }
975 memcpy(temp_pagelist,
976 dma->pagelist, dma->page_count * sizeof(*dma->pagelist));
977 DRM_DEBUG("pagelist: %d entries\n",
978dma->page_count + (count << page_order));
979
980 entry->buf_size = size;
981 entry->page_order = page_order;
982 byte_count = 0;
983 page_count = 0;
984
985 while (entry->buf_count < count) {
986 dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
987 if (!dmah)
988 return -ENOMEM;
This new return has no clean up. We a mutex_unlock(&dev->struct_mutex).
989
990 dmah->size = total;
991 dmah->vaddr = dma_alloc_coherent(dev->dev,
992 dmah->size,
993 &dmah->busaddr,
994 GFP_KERNEL);
995 if (!dmah->vaddr) {
996 kfree(dmah);
997
998 /* Set count correctly so we free the proper
amount. */
999 entry->buf_count = count;
1000 entry->seg_count = count;
1001 drm_cleanup_buf_error(dev, entry);
1002 kfree(temp_pagelist);
1003 mutex_unlock(&dev->struct_mutex);
1004 atomic_dec(&dev->buf_alloc);
1005 return -ENOMEM;
1006 }
1007 entry->seglist[entry->seg_count++] = dmah;
1008 for (i = 0; i < (1 << page_order); i++) {
1009 DRM_DEBUG("page %d @ 0x%08lx\n",
regards,
dan carpenter
Re: [PATCH v15 2/4] dt-bindings: msm: dsi: add yaml schemas for DSI bindings
On Wed, May 5, 2021 at 11:11 PM wrote: > > On 2021-04-08 20:33, Rob Herring wrote: > > On Mon, Apr 05, 2021 at 04:36:08PM +0530, Krishna Manikandan wrote: > >> Add YAML schema for the device tree bindings for DSI > >> + data-lanes: > >> +$ref: "/schemas/media/video-interfaces.yaml#" > > > > Not how this reference works. Look at other examples. > > > >> +description: | > >> + This describes how the physical DSI data lanes are > >> mapped > >> + to the logical lanes on the given platform. The > >> value contained in > >> + index n describes what physical lane is mapped to > >> the logical lane n > >> + (DATAn, where n lies between 0 and 3). The clock > >> lane position is fixed > >> + and can't be changed. Hence, they aren't a part of > >> the DT bindings. > >> + > >> +items: > >> + - const: 0 > >> + - const: 1 > >> + - const: 2 > >> + - const: 3 > > > > If this is the only possible value, why does it need to be in DT? > Hi Rob, > These are the possible values: > -<0 1 2 3> > -<1 2 3 0> > -<2 3 0 1> > -<3 0 1 2> > -<0 3 2 1> > -<1 0 3 2> > -<2 1 0 3> > -<3 2 1 0> > > Shall I follow the below mentioned approach for defining these values ? > oneOf: >- items: > - const: 0 > - const: 1 > - const: 2 > - const: 3 >- items: > - const: 1 > - const: 2 > - const: 3 > - const: 0 >- items: > - const: 2 > - const: 3 > - const: 0 > - const: 1 >- items: > - const: 3 > - const: 0 > - const: 1 > - const: 2 >- items: > - const: 0 > - const: 3 > - const: 2 > - const: 1 >- items: > - const: 1 > - const: 0 > - const: 3 > - const: 2 >- items: > - const: 2 > - const: 1 > - const: 0 > - const: 3 >- items: > - const: 3 > - const: 2 > - const: 1 > - const: 0 That's too verbose. maxItems: 4 minItems: 4 (or is less supported?) items: enum: [ 0, 1, 2, 3 ]
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
Em Fri, 14 May 2021 12:08:36 +0100
Edward Cree escreveu:
> For anyone who doesn't know about it: X has this wonderful thing called
> the Compose key[1]. For instance, type ⎄--- to get —, or ⎄<" for “.
> Much more mnemonic than Unicode codepoints; and you can extend it with
> user-defined sequences in your ~/.XCompose file.
Good tip. I haven't use composite for years, as US-intl with dead keys is
enough for 99.999% of my needs.
Btw, at least on Fedora with Mate, Composite is disabled by default. It has
to be enabled first using the same tool that allows changing the Keyboard
layout[1].
Yet, typing an EN DASH for example, would be "--.", with is 4
keystrokes instead of just two ('--'). It means twice the effort ;-)
[1] KDE, GNome, Mate, ... have different ways to enable it and to
select what key would be considered :
https://dry.sailingissues.com/us-international-keyboard-layout.html
https://help.ubuntu.com/community/ComposeKey
Thanks,
Mauro
Re: [PATCH][next] drm/vmwgfx: Fix memory leak of object fifo on error return
On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case where fifo->static_buffer fails to be allocated the
> error return path neglects to kfree the fifo object. Fix this by
> adding in the missing kfree.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> index 027d7d504e78..e5fa210f589e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
> @@ -107,8 +107,10 @@ struct vmw_fifo_state *vmw_fifo_create(struct
> vmw_private *dev_priv)
> fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
This needs an:
if (!fifo)
return -ENOMEM;
> fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
> fifo->static_buffer = vmalloc(fifo->static_buffer_size);
> - if (unlikely(fifo->static_buffer == NULL))
> + if (unlikely(fifo->static_buffer == NULL)) {
> + kfree(fifo);
> return ERR_PTR(-ENOMEM);
> + }
regards,
dan carpenter
Re: [PATCH][next] drm/vmwgfx: Fix memory leak of object fifo on error return
On 14/05/2021 15:30, Dan Carpenter wrote:
> On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> In the case where fifo->static_buffer fails to be allocated the
>> error return path neglects to kfree the fifo object. Fix this by
>> adding in the missing kfree.
>>
>> Addresses-Coverity: ("Resource leak")
>> Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> index 027d7d504e78..e5fa210f589e 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
>> @@ -107,8 +107,10 @@ struct vmw_fifo_state *vmw_fifo_create(struct
>> vmw_private *dev_priv)
>> fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
>
> This needs an:
>
> if (!fifo)
> return -ENOMEM;
Doh, I completely missed that. I'll send a V2. Thanks Dan.
>
>> fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
>> fifo->static_buffer = vmalloc(fifo->static_buffer_size);
>> -if (unlikely(fifo->static_buffer == NULL))
>> +if (unlikely(fifo->static_buffer == NULL)) {
>> +kfree(fifo);
>> return ERR_PTR(-ENOMEM);
>> +}
>
> regards,
> dan carpenter
>
Re: [PATCH 1/2] drm: Fix dirtyfb stalls
On Fri, May 14, 2021 at 12:54 AM Pekka Paalanen wrote: > > On Wed, 12 May 2021 07:57:26 -0700 > Rob Clark wrote: > > > On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote: > > > > > > On Tue, 11 May 2021 18:44:17 +0200 > > > Daniel Vetter wrote: > > > > > > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote: > > > > > On Mon, May 10, 2021 at 10:44 AM Daniel Vetter > > > > > wrote: > > > > > > > > > > > > On Mon, May 10, 2021 at 6:51 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > On Mon, May 10, 2021 at 9:14 AM Daniel Vetter > > > > > > > wrote: > > > > > > > > > > > > > > > > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote: > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > > > drm_atomic_helper_dirtyfb() will end up stalling for vblank > > > > > > > > > on "video > > > > > > > > > mode" type displays, which is pointless and unnecessary. Add > > > > > > > > > an > > > > > > > > > optional helper vfunc to determine if a plane is attached to > > > > > > > > > a CRTC > > > > > > > > > that actually needs dirtyfb, and skip over them. > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > ... > > > > > > > > But we could re-work drm_framebuffer_funcs::dirty to operate on a > > > > > > > per-crtc basis and hoist the loop and check if dirtyfb is needed > > > > > > > out > > > > > > > of drm_atomic_helper_dirtyfb() > > > > > > > > > > > > That's still using information that userspace doesn't have, which > > > > > > is a > > > > > > bit irky. We might as well go with your thing here then. > > > > > > > > > > arguably, this is something we should expose to userspace.. for DSI > > > > > command-mode panels, you probably want to make a different decision > > > > > with regard to how many buffers in your flip-chain.. > > > > > > > > > > Possibly we should add/remove the fb_damage_clips property depending > > > > > on the display type (ie. video/pull vs cmd/push mode)? > > > > > > > > I'm not sure whether atomic actually needs this exposed: > > > > - clients will do full flips for every frame anyway, I've not heard of > > > > anyone seriously doing frontbuffer rendering. > > > > > > That may or may not be changing, depending on whether the DRM drivers > > > will actually support tearing flips. There has been a huge amount of > > > debate for needing tearing for Wayland [1], and while I haven't really > > > joined that discussion, using front-buffer rendering (blits) to work > > > around the driver inability to flip-tear might be something some people > > > will want. > > > > jfwiw, there is a lot of hw that just can't do tearing pageflips.. I > > think this probably includes most arm hw. What is done instead is to > > skip the pageflip and render directly to the front-buffer. > > > > EGL_KHR_mutable_render_buffer is a thing you might be interested in.. > > it is wired up for android on i965 and there is a WIP MR[1] for > > mesa/st (gallium): > > > > Possibly it could be useful to add support for platform_wayland? > > > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10685 > > Thanks Rob, that's interesting. > > I would like to say that EGL Wayland platform cannot and has no reason > to support frontbuffer rendering in Wayland clients, because the > compositor may be reading the current client frontbuffer at any time, > including *not reading it again* until another update is posted via > Wayland. So if a Wayland client is doing frontbuffer rendering, then I > would expect it to be very likely that the window might almost never > show a "good" picture, meaning that it is literally just the > half-rendered frame after the current one with continuously updating > clients. > > That is because a Wayland client doing frontbuffer rendering is > completely unrelated to the Wayland compositor putting the client > buffer on scanout. > > Frontbuffer rendering used by a Wayland compositor would be used for > fallback tearing updates, where the rendering is roughly just a blit > from a client buffer. By definition, it means blit instead of scanout > from client buffers, so the performance/power hit is going to be... > let's say observable. > > If a Wayland client did frontbuffer rendering, and then it used a > shadow buffer of its own to minimise the level of garbage on screen by > doing only blits into the frontbuffer, that would again be a blit. And > then the compositor might be doing another blit because it doesn't know > the client is doing frontbuffer rendering which would theoretically > allow the compositor to scan out the client buffer. > > There emerges the need for a Wayland extension for clients to be > telling the compositor explicitly that they are going to be doing > frontbuffer rendering now, it is ok to put the client buffer on scanout > even if you want to do tearing updates on hardware that cannot > tear-flip. > > However, knowing that a client buffer is good for scanout is not > sufficient for scanout in a compositor, s
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
to avoid freeing uniniitalized rings.
Call amdgpu_ih_ring_fini unconditionally.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 5 +
drivers/gpu/drm/amd/amdgpu/cik_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
18 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 18598eda18f6..a0bff4713672 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3256,7 +3256,6 @@ static const struct attribute *amdgpu_dev_attributes[] = {
NULL
};
-
/**
* amdgpu_device_init - initialize the driver
*
@@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
-
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
amdgpu_device_ip_fini_early(adev);
+
+ amdgpu_gart_dummy_page_fini(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index c5a9a4fb10d2..6460cf723f0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct amdgpu_device
*adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
@@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
return 0;
}
-
-/**
- * amdgpu_gart_fini - tear down the driver info for managing the gart
- *
- * @adev: amdgpu_device pointer
- *
- * Tear down the gart driver info and free the dummy page (all asics).
- */
-void amdgpu_gart_fini(struct amdgpu_device *adev)
-{
- amdgpu_gart_dummy_page_fini(adev);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index a25fe97b0196..030b9d4c736a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct amdgpu_device *adev);
int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
int amdgpu_gart_init(struct amdgpu_device *adev);
-void amdgpu_gart_fini(struct amdgpu_device *adev);
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
int pages);
int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index faaa6aa2faaf..433469ace6f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, struct
amdgpu_ih_ring *ih,
*/
void amdgpu_ih_ring_fini(struct amdgpu_device *adev, struct amdgpu_ih_ring
*ih)
{
+
+ if (!ih->ring)
+ return;
+
if (ih->use_bus_addr) {
- if (!ih->ring)
- return;
/* add 8 bytes for the rptr/wptr shadows and
* add them to the end of the ring allocation.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 233b64dab94b..32ce0e679dc7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -361,6 +361,11 @@ void amdgpu_irq_fini_hw(s
Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 1ffb36bd0b19..fa03702ecbfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -525,8 +526,7 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
*/
void amdgpu_fence_driver_fini_hw(struct amdgpu_device *adev)
{
- unsigned i, j;
- int r;
+ int i, r;
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -535,11 +535,15 @@ void amdgpu_fence_driver_fini_hw(struct amdgpu_device
*adev)
continue;
if (!ring->no_scheduler)
drm_sched_fini(&ring->sched);
- r = amdgpu_fence_wait_empty(ring);
- if (r) {
- /* no need to trigger GPU reset as we are unloading */
+ /* You can't wait for HW to signal if it's gone */
+ if (!drm_dev_is_unplugged(&adev->ddev))
+ r = amdgpu_fence_wait_empty(ring);
+ else
+ r = -ENODEV;
+ /* no need to trigger GPU reset as we are unloading */
+ if (r)
amdgpu_fence_driver_force_completion(ring);
- }
+
if (ring->fence_drv.irq_src)
amdgpu_irq_put(adev, ring->fence_drv.irq_src,
ring->fence_drv.irq_type);
Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f7cca25c0fa0..73cbc3c7453f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3666,6 +3666,25 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
+static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
+{
+ /* Clear all CPU mappings pointing to this device */
+ unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
+
+ /* Unmap all mapped bars - Doorbell, registers and VRAM */
+ amdgpu_device_doorbell_fini(adev);
+
+ iounmap(adev->rmmio);
+ adev->rmmio = NULL;
+ if (adev->mman.aper_base_kaddr)
+ iounmap(adev->mman.aper_base_kaddr);
+ adev->mman.aper_base_kaddr = NULL;
+
+ /* Memory manager related */
+ arch_phys_wc_del(adev->gmc.vram_mtrr);
+ arch_io_free_memtype_wc(adev->gmc.aper_base, adev->gmc.aper_size);
+}
+
/**
* amdgpu_device_fini - tear down the driver
*
@@ -3712,6 +3731,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_device_ip_fini_early(adev);
amdgpu_gart_dummy_page_fini(adev);
+
+ amdgpu_device_unmap_mmio(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
@@ -3739,9 +3760,6 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
}
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
vga_client_register(adev->pdev, NULL, NULL, NULL);
- iounmap(adev->rmmio);
- adev->rmmio = NULL;
- amdgpu_device_doorbell_fini(adev);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 0adffcace326..882fb49f3c41 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -533,6 +533,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
return -ENOMEM;
drm_gem_private_object_init(adev_to_drm(adev), &bo->tbo.base, size);
INIT_LIST_HEAD(&bo->shadow_list);
+
bo->vm_bo = NULL;
bo->preferred_domains = bp->preferred_domain ? bp->preferred_domain :
bp->domain;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0d54e70278ca..58ad2fecc9e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1841,10 +1841,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
amdgpu_bo_free_kernel(&adev->mman.discovery_memory, NULL, NULL);
amdgpu_ttm_fw_reserve_vram_fini(adev);
- if (adev->mman.aper_base_kaddr)
- iounmap(adev->mman.aper_base_kaddr);
- adev->mman.aper_base_kaddr = NULL;
-
amdgpu_vram_mgr_fini(adev);
amdgpu_gtt_mgr_fini(adev);
ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_GDS);
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. So even with sysfs aid for discovery you are back to just going over all files again. For what use case? To enable GPU usage in top we can do much better than iterate over all open files in the system. We can start with a process if going with the /proc proposal, or with the opened DRM file directly with the sysfs proposal. Both are significantly fewer than total number of open files across all processes. Regards, Tvrtko
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
On 13/05/2021 16:55, Ezequiel Garcia wrote: > Hi Neil, > > On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: >> >> Hi, >> >> On 21/04/2021 07:28, Nicolas Boichat wrote: >>> Hi! >>> >>> This is just a rebase of the v11, untested (but it seems like >>> Neil Armstrong recently tested it), with small changes in >>> binding and dts. v11 cover follows: >>> >>> Follow-up on the v5 [1], things have gotten significantly >>> better in the last year, thanks to the efforts on Bifrost >>> support by the Collabora team (and probably others I'm not >>> aware of). >>> >>> I've been testing this series on a MT8183/kukui device, with a >>> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with >>> mesa 20.3.2 (lots of artifacts though). >>> >>> devfreq is currently not supported, as we'll need: >>> - Clock core support for switching the GPU core clock (see 2/4). >>> - Platform-specific handling of the 2-regulator (see 3/4). >>> >>> Since the latter is easy to detect, patch 3/4 just disables >>> devfreq if the more than one regulator is specified in the >>> compatible matching table. >>> >>> [1] >>> https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ >>> [2] https://crrev.com/c/2608070 >>> >>> Changes in v13: >>> - devfreq: Fix conflict resolution mistake when rebasing, didn't >>>even compile. Oops. >>> >>> Changes in v12: >>> - binding: Fix min/maxItems logic (Rob Herring) >>> - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). >>> >>> Changes in v11: >>> - binding: power-domain-names not power-domainS-names >>> - mt8183*.dts: remove incorrect supply-names >>> >>> Changes in v10: >>> - Fix the binding to make sure sram-supply property can be provided. >>> >>> Changes in v9: >>> - Explain why devfreq needs to be disabled for GPUs with >1 >>>regulators. >>> >>> Changes in v8: >>> - Use DRM_DEV_INFO instead of ERROR >>> >>> Changes in v7: >>> - Fix GPU ID in commit message >>> - Fix GPU ID in commit message >>> >>> Changes in v6: >>> - Rebased, actually tested with recent mesa driver. >>> - Add gpu regulators to kukui dtsi as well. >>> - Power domains are now attached to spm, not scpsys >>> - Drop R-B. >>> - devfreq: New change >>> - Context conflicts, reflow the code. >>> - Use ARRAY_SIZE for power domains too. >>> >>> Changes in v5: >>> - Rename "2d" power domain to "core2" >>> - Rename "2d" power domain to "core2" (keep R-B again). >>> - Change power domain name from 2d to core2. >>> >>> Changes in v4: >>> - Add power-domain-names description >>>(kept Alyssa's reviewed-by as the change is minor) >>> - Add power-domain-names to describe the 3 domains. >>>(kept Alyssa's reviewed-by as the change is minor) >>> - Add power domain names. >>> >>> Changes in v3: >>> - Match mt8183-mali instead of bifrost, as we require special >>>handling for the 2 regulators and 3 power domains. >>> >>> Changes in v2: >>> - Use sram instead of mali_sram as SRAM supply name. >>> - Rename mali@ to gpu@. >>> >>> Nicolas Boichat (4): >>> dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 >>> arm64: dts: mt8183: Add node for the Mali GPU >>> drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 >>> drm/panfrost: Add mt8183-mali compatible string >>> >>> .../bindings/gpu/arm,mali-bifrost.yaml| 30 - >>> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + >>> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + >>> .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + >>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ >>> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ >>> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ >>> 7 files changed, 168 insertions(+), 1 deletion(-) >>> >> >> Seems this version is ready to be applied if we get a review on the DT ? >> >> Mathias ? could you have a look ? >> > > Given Rob has Acked the DT bindings, I think it's OK to apply patches > 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. > > My two unsolicited cents :-) Yeah sure, is there a panfrost maintainer in the room ? I can apply them if you ack me. Neil > > Ezequiel >
[PATCH][V2][next] drm/vmwgfx: Fix memory allocation check and a leak of object fifo
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Kudos to Dan Carpenter for spotting the missing kzalloc failure
check.
Addresses-Coverity: ("Resource leak")
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Colin Ian King
---
V2: Add missing allocation failure check
Update $SUBJECT to reflect this extra change
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
index 027d7d504e78..d9acd2f3f673 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
@@ -105,10 +105,14 @@ struct vmw_fifo_state *vmw_fifo_create(struct vmw_private
*dev_priv)
return NULL;
fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
+ if (!fifo)
+ return ERR_PTR(-ENOMEM);
fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
fifo->static_buffer = vmalloc(fifo->static_buffer_size);
- if (unlikely(fifo->static_buffer == NULL))
+ if (unlikely(fifo->static_buffer == NULL)) {
+ kfree(fifo);
return ERR_PTR(-ENOMEM);
+ }
fifo->dynamic_buffer = NULL;
fifo->reserved_size = 0;
--
2.30.2
Re: [PATCH 0/7] Per client engine busyness
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. Regards, Christian. So even with sysfs aid for discovery you are back to just going over all files again. For what use case? To enable GPU usage in top we can do much better than iterate over all open files in the system. We can start with a process if going with the /proc proposal, or with the opened DRM file directly with the sysfs proposal. Both are significantly fewer than total number of open files across all processes. Regards, Tvrtko
Re: [PATCH 0/7] Per client engine busyness
On 14/05/2021 15:56, Christian König wrote: Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. Yes we have special code in i915 for this. Part of this series we are discussing here. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. I asked you about the use case you have in mind which you did not answer. Otherwise I don't understand when do you need to walk all files. What information you want to get? For the use case of knowing which DRM file is using how much GPU time on engine X we do not need to walk all open files either with my sysfs approach or the proc approach from Chris. (In the former case we optionally aggregate by PID at presentation time, and in the latter case aggregation is implicit.) Regards, Tvrtko
Re: [PATCH 0/7] Per client engine busyness
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin: On 14/05/2021 15:56, Christian König wrote: Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: On 14/05/2021 14:53, Christian König wrote: David also said that you considered sysfs but were wary of exposing process info in there. To clarify, my patch is not exposing sysfs entry per process, but one per open drm fd. Yes, we discussed this as well, but then rejected the approach. To have useful information related to the open drm fd you need to related that to process(es) which have that file descriptor open. Just tracking who opened it first like DRM does is pretty useless on modern systems. We do update the pid/name for fds passed over unix sockets. Well I just double checked and that is not correct. Could be that i915 has some special code for that, but on my laptop I only see the X server under the "clients" debugfs file. Yes we have special code in i915 for this. Part of this series we are discussing here. Ah, yeah you should mention that. Could we please separate that into common code instead? Cause I really see that as a bug in the current handling independent of the discussion here. As far as I know all IOCTLs go though some common place in DRM anyway. But an "lsof /dev/dri/renderD128" for example does exactly what top does as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. Completely agree. The key point is you either need to have all references to an open fd, or at least track whoever last used that fd. At least the last time I looked even the fs layer didn't know which fd is open by which process. So there wasn't really any alternative to the lsof approach. I asked you about the use case you have in mind which you did not answer. Otherwise I don't understand when do you need to walk all files. What information you want to get? Per fd debugging information, e.g. instead of the top use case you know which process you want to look at. For the use case of knowing which DRM file is using how much GPU time on engine X we do not need to walk all open files either with my sysfs approach or the proc approach from Chris. (In the former case we optionally aggregate by PID at presentation time, and in the latter case aggregation is implicit.) I'm unsure if we should go with the sysfs, proc or some completely different approach. In general it would be nice to have a way to find all the fd references for an open inode. Regards, Christian. Regards, Tvrtko
Re: [bug report] drm: remove usage of drm_pci_alloc/free
Hi Dan,
On Fri, May 14, 2021 at 6:54 AM Dan Carpenter wrote:
>
> Hello Joseph Kogut,
>
> The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
> from Apr 22, 2021, leads to the following static checker warning:
>
> drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
> warn: inconsistent returns '&dev->struct_mutex'.
> Locked on : 988
> Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
>
> drivers/gpu/drm/drm_bufs.c
>965 temp_pagelist = kmalloc_array(dma->page_count + (count <<
> page_order),
>966sizeof(*dma->pagelist),
>967GFP_KERNEL);
>968 if (!temp_pagelist) {
>969 kfree(entry->buflist);
>970 kfree(entry->seglist);
>971 mutex_unlock(&dev->struct_mutex);
>972 atomic_dec(&dev->buf_alloc);
>973 return -ENOMEM;
>
> There is a bunch of clean up happenning on the existing returns.
>
>974 }
>975 memcpy(temp_pagelist,
>976 dma->pagelist, dma->page_count *
> sizeof(*dma->pagelist));
>977 DRM_DEBUG("pagelist: %d entries\n",
>978dma->page_count + (count << page_order));
>979
>980 entry->buf_size = size;
>981 entry->page_order = page_order;
>982 byte_count = 0;
>983 page_count = 0;
>984
>985 while (entry->buf_count < count) {
>986 dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
>987 if (!dmah)
>988 return -ENOMEM;
>
> This new return has no clean up. We a mutex_unlock(&dev->struct_mutex).
>
>989
>990 dmah->size = total;
>991 dmah->vaddr = dma_alloc_coherent(dev->dev,
>992 dmah->size,
>993 &dmah->busaddr,
>994 GFP_KERNEL);
>995 if (!dmah->vaddr) {
>996 kfree(dmah);
>997
>998 /* Set count correctly so we free the proper
> amount. */
>999 entry->buf_count = count;
> 1000 entry->seg_count = count;
> 1001 drm_cleanup_buf_error(dev, entry);
> 1002 kfree(temp_pagelist);
> 1003 mutex_unlock(&dev->struct_mutex);
> 1004 atomic_dec(&dev->buf_alloc);
> 1005 return -ENOMEM;
> 1006 }
> 1007 entry->seglist[entry->seg_count++] = dmah;
> 1008 for (i = 0; i < (1 << page_order); i++) {
> 1009 DRM_DEBUG("page %d @ 0x%08lx\n",
>
> regards,
> dan carpenter
Thanks for the report, I'll follow up with a patch to fix this.
Best,
Joseph
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
On 14/05/2021 15:48, Neil Armstrong wrote: > On 13/05/2021 16:55, Ezequiel Garcia wrote: >> Hi Neil, >> >> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: >>> >>> Hi, >>> >>> On 21/04/2021 07:28, Nicolas Boichat wrote: Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v13: - devfreq: Fix conflict resolution mistake when rebasing, didn't even compile. Oops. Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 30 - arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 7 files changed, 168 insertions(+), 1 deletion(-) >>> >>> Seems this version is ready to be applied if we get a review on the DT ? >>> >>> Mathias ? could you have a look ? >>> >> >> Given Rob has Acked the DT bindings, I think it's OK to apply patches >> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. >> >> My two unsolicited cents :-) You make a convincing point - and if everyone is happy for the DT changes to be handled separately I don't see a reason for the other patches to be held up. > Yeah sure, is there a panfrost maintainer in the room ? I can apply them if > you ack me. I seem to be applying most Panfrost changes these days, so I'll save you the effort and push 1,3,4 to drm-misc-next. Thanks, Steve
[PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
syzbot is reporting that a local user with the framebuffer console can
crash the kernel [1], for ioctl(VT_RESIZE) allows a TTY to set arbitrary
rows/columns values regardless of amount of memory reserved for
the graphical screen.
--
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
const int fd = open("/dev/char/4:1", O_RDWR);
struct vt_sizes vt = { 0x4100, 2 };
ioctl(fd, KDSETMODE, KD_GRAPHICS);
ioctl(fd, VT_RESIZE, &vt);
ioctl(fd, KDSETMODE, KD_TEXT);
return 0;
}
--
Currently it is impossible to control upper limit of rows/columns values
based on amount of memory reserved for the graphical screen, for
resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
already KD_GRAPHICS. I don't know the reason, and this condition predates
the git history. Even if it turns out to be safe to always call this
callback, we will need to involve another callback via "struct fb_ops" for
checking the upper limits from fbcon_resize(). As a result, we will need
to modify
drivers/tty/vt/vt.c
drivers/video/fbdev/core/fbcon.c
drivers/video/fbdev/vga16fb.c
include/linux/fb.h
files only for checking rows/columns values passed to ioctl(VT_RESIZE)
request.
Therefore, instead of introducing such a complicated callback chain, avoid
this problem by simply checking whether the address to read or write is in
[VGA_FB_PHYS, VGA_FB_PHYS + VGA_FB_PHYS_LEN) range.
[1] https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/vga16fb.c | 54 +++
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index e2757ff1c23d..13732a3b1d69 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -98,6 +98,18 @@ static const struct fb_fix_screeninfo vga16fb_fix = {
.accel = FB_ACCEL_NONE
};
+/*
+ * Verify that the address to read or write is in [VGA_FB_PHYS, VGA_FB_PHYS +
VGA_FB_PHYS_LEN)
+ * range, for ioctl(VT_RESIZE) allows a TTY to set arbitrary rows/columns
values which will crash
+ * the kernel due to out of bounds access when trying to redraw the screen.
+ */
+static inline bool is_valid_iomem(const struct fb_info *info, const char
__iomem *where)
+{
+ return info->screen_base <= where && where < info->screen_base +
VGA_FB_PHYS_LEN;
+}
+
+#define IS_SAFE(where) is_valid_iomem(info, (where))
+
/* The VGA's weird architecture often requires that we read a byte and
write a byte to the same location. It doesn't matter *what* byte
we write, however. This is because all the action goes on behind
@@ -851,7 +863,7 @@ static void vga_8planes_fillrect(struct fb_info *info,
const struct fb_fillrect
int x;
/* we can do memset... */
-for (x = width; x > 0; --x) {
+ for (x = width; x > 0 && IS_SAFE(where); --x) {
writeb(rect->color, where);
where++;
}
@@ -864,7 +876,7 @@ static void vga_8planes_fillrect(struct fb_info *info,
const struct fb_fillrect
oldop = setop(0x18);
oldsr = setsr(0xf);
setmask(0x0F);
-for (y = 0; y < rect->height; y++) {
+ for (y = 0; y < rect->height && IS_SAFE(where) && IS_SAFE(where
+ 1); y++) {
rmw(where);
rmw(where+1);
where += info->fix.line_length;
@@ -919,7 +931,7 @@ static void vga16fb_fillrect(struct fb_info *info, const
struct fb_fillrect *rec
setmask(0xff);
while (height--) {
- for (x = 0; x < width; x++) {
+ for (x = 0; x < width && IS_SAFE(dst);
x++) {
writeb(0, dst);
dst++;
}
@@ -935,7 +947,7 @@ static void vga16fb_fillrect(struct fb_info *info, const
struct fb_fillrect *rec
setmask(0xff);
while (height--) {
- for (x = 0; x < width; x++) {
+ for (x = 0; x < width && IS_SAFE(dst);
x++) {
rmw(dst);
dst++;
}
@@ -975,7 +987,7 @@ static void vga_8planes_copyarea(struct fb_info *info,
const struct fb_copyarea
dest = info->screen_base + dx + area->dy *
info->fix.line_length;
src = info->screen_base + sx +
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
refactoring to me.
Regards,
Felix
Am 2021-05-14 um 10:41 a.m. schrieb Andrey Grodzovsky:
> Ping
>
> Andrey
>
> On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
>> Handle all DMA IOMMU gropup related dependencies before the
>> group is removed.
>>
>> v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
>> v6: Drop the BO unamp list
>> v7:
>> Drop amdgpu_gart_fini
>> In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
>> to avoid freeing uniniitalized rings.
>> Call amdgpu_ih_ring_fini unconditionally.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
>> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 +
>> drivers/gpu/drm/amd/amdgpu/cik_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
>> drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
>> drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
>> 18 files changed, 13 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 18598eda18f6..a0bff4713672 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3256,7 +3256,6 @@ static const struct attribute
>> *amdgpu_dev_attributes[] = {
>> NULL
>> };
>> -
>> /**
>> * amdgpu_device_init - initialize the driver
>> *
>> @@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct
>> amdgpu_device *adev)
>> amdgpu_ucode_sysfs_fini(adev);
>> sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
>> -
>> amdgpu_fbdev_fini(adev);
>> amdgpu_irq_fini_hw(adev);
>> amdgpu_device_ip_fini_early(adev);
>> +
>> + amdgpu_gart_dummy_page_fini(adev);
>> }
>> void amdgpu_device_fini_sw(struct amdgpu_device *adev)
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> index c5a9a4fb10d2..6460cf723f0a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> @@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
>> amdgpu_device *adev)
>> *
>> * Frees the dummy page used by the driver (all asics).
>> */
>> -static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
>> +void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
>> {
>> if (!adev->dummy_page_addr)
>> return;
>> @@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
>> return 0;
>> }
>> -
>> -/**
>> - * amdgpu_gart_fini - tear down the driver info for managing the gart
>> - *
>> - * @adev: amdgpu_device pointer
>> - *
>> - * Tear down the gart driver info and free the dummy page (all asics).
>> - */
>> -void amdgpu_gart_fini(struct amdgpu_device *adev)
>> -{
>> - amdgpu_gart_dummy_page_fini(adev);
>> -}
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> index a25fe97b0196..030b9d4c736a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
>> @@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct
>> amdgpu_device *adev);
>> int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
>> void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
>> int amdgpu_gart_init(struct amdgpu_device *adev);
>> -void amdgpu_gart_fini(struct amdgpu_device *adev);
>> +void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
>> int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>> int pages);
>> int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> index faaa6aa2faaf..433469ace6f4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
>> @@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device
>> *adev, struct amdgpu_ih_ring *ih,
>> */
>> void amdgpu_ih_
Re: [PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Makes sense - will update.
Andrey
On 2021-05-14 12:25 p.m., Felix Kuehling wrote:
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
refactoring to me.
Regards,
Felix
Am 2021-05-14 um 10:41 a.m. schrieb Andrey Grodzovsky:
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
to avoid freeing uniniitalized rings.
Call amdgpu_ih_ring_fini unconditionally.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 +
drivers/gpu/drm/amd/amdgpu/cik_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
18 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 18598eda18f6..a0bff4713672 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3256,7 +3256,6 @@ static const struct attribute
*amdgpu_dev_attributes[] = {
NULL
};
-
/**
* amdgpu_device_init - initialize the driver
*
@@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct
amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
-
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
amdgpu_device_ip_fini_early(adev);
+
+ amdgpu_gart_dummy_page_fini(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index c5a9a4fb10d2..6460cf723f0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
amdgpu_device *adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
@@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
return 0;
}
-
-/**
- * amdgpu_gart_fini - tear down the driver info for managing the gart
- *
- * @adev: amdgpu_device pointer
- *
- * Tear down the gart driver info and free the dummy page (all asics).
- */
-void amdgpu_gart_fini(struct amdgpu_device *adev)
-{
- amdgpu_gart_dummy_page_fini(adev);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index a25fe97b0196..030b9d4c736a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct
amdgpu_device *adev);
int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
int amdgpu_gart_init(struct amdgpu_device *adev);
-void amdgpu_gart_fini(struct amdgpu_device *adev);
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
int pages);
int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index faaa6aa2faaf..433469ace6f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device
*adev, struct amdgpu_ih_ring *ih,
*/
void amdgpu_ih_ring_fini(struct amdgpu_device *adev, struct
amdgpu_ih_ring *ih)
{
+
+ if (!ih->ring)
+ return;
+
if (ih->use_bus_addr) {
- if (!ih->ring)
- return;
/*
Re: [RFC PATCH 00/97] Basic GuC submission support in the i915
Pulling a few threads together... On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote: > > I agree with Martin on this. Given that using GuC currently involves > making your open-source graphics stack rely on a closed-source > cryptographically-protected blob in order to submit commands to the GPU, > and given that it is /still/ possible to use the GPU without it, I'd > expect some strong material justification for making the switch (like, > it improves performance of test-case X and Y by Z%, or, we're truly > sorry but we cannot program your GPU anymore with a purely open-source > software stack). Any argument based on the apparent direction of the > wind doesn't sound like a material engineering reason to me, and runs > the risk of being self-fulfilling if it leads us to do the worse thing > for our users just because we have the vague feeling that it is the > general trend, even though we may have had the means to obtain a better > compromise for them. I think it's important to distinguish between landing code to support GuC submission and requiring it in order to use the GPU. We've got the execlist back-end and it's not going anywhere, at least not for older hardware, and it will likely keep working as long as execlists remain in the hardware. What's being proposed here is a new back-end which, yes, depends on firmware and can be used for more features. I'm well aware of the slippery slope argument that's implicitly being used here even if no one is actually saying it: If we land GuC support in i915 in any form then Intel HW engineers will say "See, Linux supports GuC now; we can rip out execlists" and we'll end up in the dystopia of closed-source firmware. If upstream continues to push back on GuC in any form then they'll be forced to keep execlists. I'll freely admit that there is probably some truth to this. However, I really doubt that it's going to work long-term. If the HW architects are determined enough to rip it out, they will. If GuC is really inevitable, then it's in our best interests to land at least beta support earlier. There are a lot of questions that people have brought up around back-ports, dealing with stable kernels, stability concerns, etc. The best way to sort those out is to land the code and start dealing with the issues. We can't front-load solving every possible issue or the code will never land. But maybe that's people's actual objective? On Wed, May 12, 2021 at 1:26 AM Martin Peres wrote: > > On 11/05/2021 19:39, Matthew Brost wrote: > > On Tue, May 11, 2021 at 08:26:59AM -0700, Bloomfield, Jon wrote: > >>> On 10/05/2021 19:33, Daniel Vetter wrote: > On Mon, May 10, 2021 at 3:55 PM Martin Peres > >>> wrote: > >>> > >>> However, if the GuC is actually helping i915, then why not open source > >>> it and drop all the issues related to its stability? Wouldn't it be the > >>> perfect solution, as it would allow dropping execlist support for newer > >>> HW, and it would eliminate the concerns about maintenance of stable > >>> releases of Linux? I would like to see that happen. I know there was some chatter about it for a while and then the discussions got killed. I'm not sure what happened, to be honest. However, I don't think we can make any guarantees or assumptions there, I'm afraid. :-( > >> That the major version of the FW is high is not due to bugs - Bugs don't > >> trigger major version bumps anyway. > > Of course, where did I say they would? I think the concern here is that old kernels will require old major GuC versions because interfaces won't be backwards-compatible and then those kernels won't get bug fixes. That's a legitimate concern. Given the Linux usage model, I think it's fair to require either backwards-compatibility with GuC interfaces and validation of that backwards-compatibility or stable releases with bug fixes for a good long while. I honestly can't say whether or not we've really scoped that. Jon? > >> We have been using GuC as the sole mechanism for submission on Windows > >> since Gen8, and it has proven very reliable. This is in large part because > >> it is simple, and designed from day 1 as a cohesive solution alongside the > >> hardware. There are going to be differences in the usage patterns that i915 and Windows will hit when it comes to the subtle details of how we bang on the GuC rings. Those will likely lead to bugs on Linux that don't show up on Windows so "it works on Windows" doesn't mean we're headed for a bug-free future. It means we have an existence proof that firmware-based submission can be very reliable. However, I don't think anyone on this thread is really questioning that. > Exactly, the GuC was designed with Windows' GPU model... which is not > directly applicable to Linux. Also, Windows does not care as much about > submission latency, whereas most Linux users still depend on glamor for > 2D acceleration which is pretty much the biggest stress test for command > submission latency.
Re: [bug report] drm: remove usage of drm_pci_alloc/free
On Fri, May 14, 2021 at 8:13 AM Joseph Kogut wrote: > > Hi Dan, > > On Fri, May 14, 2021 at 6:54 AM Dan Carpenter > wrote: > > > > Hello Joseph Kogut, > > > > The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free" > > from Apr 22, 2021, leads to the following static checker warning: > > > > drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci() > > warn: inconsistent returns '&dev->struct_mutex'. > > Locked on : 988 > > Unlocked on: 938,944,951,959,973,1005,1042,1060,1090 > > Do you mind if I copy this portion of the bug report in the commit message?
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware which sits between > > the i915 and the GPU. It offloads some of the scheduling of contexts > > from the i915 and programs the GPU to submit contexts. The i915 > > communicates with the GuC and the GuC communicates with the GPU. > > > > GuC submission will be disabled by default on all current upstream > > platforms behind a module parameter - enable_guc. A value of 3 will > > enable submission and HuC loading via the GuC. GuC submission should > > work on all gen11+ platforms assuming the GuC firmware is present. > > Some thoughts mostly relating to future platforms where GuC will be the > only option, and to some extent platforms where it will be possible to > turn it on for one reason or another. > > Debuggability - in the context of having an upstream way/tool for > capturing and viewing GuC logs usable for attaching to bug reports. > > Currently i915 logs, can provide traces via tracepoints and trace > printk, and GPU error capture state, which provides often sufficient > trail of evidence to debug issues. > > We need to make sure GuC does is not a black box in this respect. By > this I mean it does not hide a large portion of the execution flows from > upstream observability. I agree here. If GuC suddenly makes submission issues massively harder to debug then that's a regression vs. execlists. I don't know what the solution there is but I think the concern is valid. > This could mean a tool in IGT to access/capture GuC logs and update bug > filing instructions. > > Leading from here is probably the need for the GuC firmware team to > cross the internal-upstream boundary and deal with such bug reports on > upstream trackers. Upstream GuC is unlikely to work if we don't have > such plan and commitment. I mostly agree here as well. I'm not sure it'll actually happen but I'd like anyone who writes code which impacts Linux to be active in upstream bug trackers. > Also leading from here is the need for GPU error capture to be on par > from day one which is I believe still not there in the firmware. This one has me genuinely concerned. I've heard rumors that we don't have competent error captures with GuC yet. From the Mesa PoV, this is a non-starter. We can't be asked to develop graphics drivers with no error capture. The good news is that, based on my understanding, it shouldn't be terrible to support. We just need the GuC to grab all the registers for us and shove them in a buffer somewhere before it resets the GPU and all that data is lost. I would hope the Windows people have already done that and we just need to hook it up. If not, there may be some GuC engineering required here. > Another, although unrelated, missing feature on my wish list is firmware > support for wiring up accurate engine busyness stats to i915 PMU. I > believe this is also being worked on but I don't know when is the > expected delivery. > > If we are tracking a TODO list of items somewhere I think these ones > should be definitely considered. Yup, let's get it all in the ToDo and not flip GuC on by default in the wild until it's all checked off. --Jason
Re: thinkpad x1 carbon display flickering after update to 5.12. good on 5.11.x (i915)
Hello. On Fri, May 14, 2021 at 10:24:26AM +0200, Thomas Stein wrote: > After upgrading to linux 5.12 the display on my X1 Carbon Gen 2 starts to > flicker. Well actually it seems to turn off and on again and again. Here a > link to a video a person posted who has the same issue as me obviousely. > https://linuxove.com/thinkpad-x1-carbon-gen-3-display-flickering-on-linux-kernel-5-12/ > > This happens without having Xorg running too. So it can't be related to > Xorg. The kernel boots and after a few seconds, the kernel messages scoll > through, the flickering starts. Nothing special in dmesg. > > dmesg: > > himbeere@rather ~ $ dmesg | grep i915 > [0.713595] i915 :00:02.0: vgaarb: deactivate vga console > [0.720280] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [0.741494] i915 :00:02.0: [drm] Panel advertises DPCD backlight > support, but VBT disagrees. If your backlight controls don't work try > booting with i915.enable_dpcd_backlight=1. If your machine needs this, > please file a _new_ bug report on drm/i915, see > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for > details. > [1.864837] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on > minor 0 > [1.875907] fbcon: i915drmfb (fb0) is primary device > [3.158255] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device > himbeere@rather ~ $ > > Downgrading to 5.11 solves the issue for me. Any ideas? Does [1] fix your issue? [1] https://cgit.freedesktop.org/drm-tip/patch/?id=acca7762eb71bc05a8f28d29320d193150051f79 -- Oleksandr Natalenko (post-factum)
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 12:11:56PM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware which sits between > > the i915 and the GPU. It offloads some of the scheduling of contexts > > from the i915 and programs the GPU to submit contexts. The i915 > > communicates with the GuC and the GuC communicates with the GPU. > > > > GuC submission will be disabled by default on all current upstream > > platforms behind a module parameter - enable_guc. A value of 3 will > > enable submission and HuC loading via the GuC. GuC submission should > > work on all gen11+ platforms assuming the GuC firmware is present. > > Some thoughts mostly relating to future platforms where GuC will be the only > option, and to some extent platforms where it will be possible to turn it on > for one reason or another. > > Debuggability - in the context of having an upstream way/tool for capturing > and viewing GuC logs usable for attaching to bug reports. > Agree. We have discussed this internally as an upstream requirement for quite sometime. > Currently i915 logs, can provide traces via tracepoints and trace printk, > and GPU error capture state, which provides often sufficient trail of > evidence to debug issues. > If we do this right, we should have something the same with GuC submission. > We need to make sure GuC does is not a black box in this respect. By this I > mean it does not hide a large portion of the execution flows from upstream > observability. > > This could mean a tool in IGT to access/capture GuC logs and update bug > filing instructions. > We have a few internal tools decode the GuC logs. One of these tools will be open sourced and on a public repo. We just need to decide which tool and make sure that tool works across all the distros. > Leading from here is probably the need for the GuC firmware team to cross > the internal-upstream boundary and deal with such bug reports on upstream > trackers. Upstream GuC is unlikely to work if we don't have such plan and > commitment. > I think we can land this code first as it is going be disabled by default. Certainly once we turn it on by default we need to have everything in place that you mention in this email. > Also leading from here is the need for GPU error capture to be on par from > day one which is I believe still not there in the firmware. > We are missing a register dump from the GuC on reset. No other way to say this than this has been huge miss by the i915 / GuC teams. This is something we absolutely need and it hasn't gotten done. I'll push on this and hopefully we can land this feature soon. > Another, although unrelated, missing feature on my wish list is firmware > support for wiring up accurate engine busyness stats to i915 PMU. I believe > this is also being worked on but I don't know when is the expected delivery. > This is landing this week I believe. Next upstream post should include an updated GuC firmware + code in the i915 that hooks into the PMU stats. Matt > If we are tracking a TODO list of items somewhere I think these ones should > be definitely considered. > > Regards, > > Tvrtko
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Fri, May 14, 2021 at 11:36:37AM -0500, Jason Ekstrand wrote: > On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin > wrote: > > > > On 06/05/2021 20:13, Matthew Brost wrote: > > > Basic GuC submission support. This is the first bullet point in the > > > upstreaming plan covered in the following RFC [1]. > > > > > > At a very high level the GuC is a piece of firmware which sits between > > > the i915 and the GPU. It offloads some of the scheduling of contexts > > > from the i915 and programs the GPU to submit contexts. The i915 > > > communicates with the GuC and the GuC communicates with the GPU. > > > > > > GuC submission will be disabled by default on all current upstream > > > platforms behind a module parameter - enable_guc. A value of 3 will > > > enable submission and HuC loading via the GuC. GuC submission should > > > work on all gen11+ platforms assuming the GuC firmware is present. > > > > Some thoughts mostly relating to future platforms where GuC will be the > > only option, and to some extent platforms where it will be possible to > > turn it on for one reason or another. > > > > Debuggability - in the context of having an upstream way/tool for > > capturing and viewing GuC logs usable for attaching to bug reports. > > > > Currently i915 logs, can provide traces via tracepoints and trace > > printk, and GPU error capture state, which provides often sufficient > > trail of evidence to debug issues. > > > > We need to make sure GuC does is not a black box in this respect. By > > this I mean it does not hide a large portion of the execution flows from > > upstream observability. > > I agree here. If GuC suddenly makes submission issues massively > harder to debug then that's a regression vs. execlists. I don't know > what the solution there is but I think the concern is valid. > Replied to Tvrtko with detailed answers. The TL;DR is agree with basically everything he said and we have plans address it all and everything must be addressed before the GuC can be turned on by default. Matt > > This could mean a tool in IGT to access/capture GuC logs and update bug > > filing instructions. > > > > Leading from here is probably the need for the GuC firmware team to > > cross the internal-upstream boundary and deal with such bug reports on > > upstream trackers. Upstream GuC is unlikely to work if we don't have > > such plan and commitment. > > I mostly agree here as well. I'm not sure it'll actually happen but > I'd like anyone who writes code which impacts Linux to be active in > upstream bug trackers. > > > Also leading from here is the need for GPU error capture to be on par > > from day one which is I believe still not there in the firmware. > > This one has me genuinely concerned. I've heard rumors that we don't > have competent error captures with GuC yet. From the Mesa PoV, this > is a non-starter. We can't be asked to develop graphics drivers with > no error capture. > > The good news is that, based on my understanding, it shouldn't be > terrible to support. We just need the GuC to grab all the registers > for us and shove them in a buffer somewhere before it resets the GPU > and all that data is lost. I would hope the Windows people have > already done that and we just need to hook it up. If not, there may > be some GuC engineering required here. > > > Another, although unrelated, missing feature on my wish list is firmware > > support for wiring up accurate engine busyness stats to i915 PMU. I > > believe this is also being worked on but I don't know when is the > > expected delivery. > > > > If we are tracking a TODO list of items somewhere I think these ones > > should be definitely considered. > > Yup, let's get it all in the ToDo and not flip GuC on by default in > the wild until it's all checked off. > > --Jason
Re: [PATCH] drm/ingenic: Fix pixclock rate for 24-bit serial panels
Am 13.05.21 um 14:29 schrieb Paul Cercueil:
Hi,
Almost two months later,
Le mar., mars 23 2021 at 14:40:08 +, Paul Cercueil
a écrit :
When using a 24-bit panel on a 8-bit serial bus, the pixel clock
requested by the panel has to be multiplied by 3, since the subpixels
are shifted sequentially.
The code (in ingenic_drm_encoder_atomic_check) already computed
crtc_state->adjusted_mode->crtc_clock accordingly, but clk_set_rate()
used crtc_state->adjusted_mode->clock instead.
Fixes: 28ab7d35b6e0 ("drm/ingenic: Properly compute timings when using
a 3x8-bit panel")
Cc: sta...@vger.kernel.org # v5.10
Signed-off-by: Paul Cercueil
Can I get an ACK for my patch?
Acked-by: Thomas Zimmermann
Thanks!
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index d60e1eefc9d1..cba68bf52ec5 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -342,7 +342,7 @@ static void ingenic_drm_crtc_atomic_flush(struct
drm_crtc *crtc,
if (priv->update_clk_rate) {
mutex_lock(&priv->clk_mutex);
clk_set_rate(priv->pix_clk,
- crtc_state->adjusted_mode.clock * 1000);
+ crtc_state->adjusted_mode.crtc_clock * 1000);
priv->update_clk_rate
= false;
mutex_unlock(&priv->clk_mutex);
}
--
2.30.2
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 9:20 AM Tetsuo Handa wrote: > > Currently it is impossible to control upper limit of rows/columns values > based on amount of memory reserved for the graphical screen, for > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not > already KD_GRAPHICS Honestly, the saner approach would seem to be to simply error out if vc_mode is KD_GRAPHICS. Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable, and is clearly currently very buggy. So why not just say "that clearly already doesn't work, so make it explicitly not permitted"? Linus
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 10:29 AM Linus Torvalds
wrote:
>
> So why not just say "that clearly already doesn't work, so make it
> explicitly not permitted"?
IOW, something like this would seem fairly simple and straightforward:
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 01645e87b3d5..f24e627b7402 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1171,8 +1171,13 @@ static inline int resize_screen(struct
vc_data *vc, int width, int height,
/* Resizes the resolution of the display adapater */
int err = 0;
- if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_resize)
+ if (vc->vc_sw->con_resize) {
+ // If we have a resize function but are in KD_GRAPHICS mode,
+ // we can't actually do a resize and need to error out.
+ if (vc->vc_mode == KD_GRAPHICS)
+ return -EINVAL;
err = vc->vc_sw->con_resize(vc, width, height, user);
+ }
return err;
}
not tested, but it looks ObviouslyCorrect(tm), and since we know the
old case didn't work right, it seems very safe to do.
Linus
Re: [git pull] drm fixes for 5.13-rc2
On Thu, May 13, 2021 at 7:34 PM Dave Airlie wrote: > > Just realised I got the tag header wrong, these are the rc2 fixes. Heh. The tag message also says: > vc4: > - drop an used function which just makes me think you may have started drinking early ;) I fixed it up. Skål! Linus
Re: [git pull] drm fixes for 5.13-rc2
The pull request you sent on Fri, 14 May 2021 12:34:38 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b5304a4f9ad88a712c26c63691a99c0b9b1b5dc6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 02/27] drm/i915: Stop storing the ring size in the ring pointer
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > Previously, we were storing the ring size in the ring pointer before it
> > was actually allocated. We would then guard setting the ring size on
> > checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
> > only saves us a few bytes on something that already burns at least 4K.
> > Instead, this patch adds a new ring_size field and makes everything use
> > that.
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
> > drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
> > drivers/gpu/drm/i915/gt/intel_context.h | 5 -
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +-
> > drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++-
> > 9 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index e52b85b8f923d..2ba4c7e4011b4 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -211,8 +211,7 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> > GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
> > RCU_INIT_POINTER(ce->gem_context, ctx);
> >
> > - if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
> > - ce->ring = __intel_context_ring_size(SZ_16K);
> > + ce->ring_size = SZ_16K;
> >
> > if (rcu_access_pointer(ctx->vm)) {
> > struct i915_address_space *vm;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 17cf2640b082b..342fa7daa08b5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -372,7 +372,8 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > ce->engine = engine;
> > ce->ops = engine->cops;
> > ce->sseu = engine->sseu;
> > - ce->ring = __intel_context_ring_size(SZ_4K);
> > + ce->ring = NULL;
> > + ce->ring_size = SZ_4K;
> >
> > ewma_runtime_init(&ce->runtime.avg);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index f83a73a2b39fc..b10cbe8fee992 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -175,11 +175,6 @@ int intel_context_prepare_remote_request(struct
> > intel_context *ce,
> >
> > struct i915_request *intel_context_create_request(struct intel_context
> > *ce);
> >
> > -static inline struct intel_ring *__intel_context_ring_size(u64 sz)
> > -{
> > - return u64_to_ptr(struct intel_ring, sz);
> > -}
> > -
> > static inline bool intel_context_is_barrier(const struct intel_context *ce)
> > {
> > return test_bit(CONTEXT_BARRIER_BIT, &ce->flags);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index ed8c447a7346b..90026c1771055 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -82,6 +82,7 @@ struct intel_context {
> > spinlock_t signal_lock; /* protects signals, the list of requests */
> >
> > struct i915_vma *state;
> > + u32 ring_size;
> > struct intel_ring *ring;
> > struct intel_timeline *timeline;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index e86897cde9846..63193c80fb117 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -845,7 +845,7 @@ int lrc_alloc(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > if (IS_ERR(vma))
> > return PTR_ERR(vma);
> >
> > - ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
> > + ring = intel_engine_create_ring(engine, ce->ring_size);
> > if (IS_ERR(ring)) {
> > err = PTR_ERR(ring);
> > goto err_vma;
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > index 1081cd36a2bd3..01d9896dd4844 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> > @@ -2793,7 +2793,7 @@ static int __live_preempt_ring(struct intel_engine_cs
> > *engine,
> > goto err_ce;
> > }
> >
> > - tmp->ring = __intel_context_ring_size(ring_sz);
> > + tmp->ring_size = ring_sz;
> >
> > err = intel_context_pin
Re: [Intel-gfx] [PATCH 06/27] drm/i915: Drop the CONTEXT_CLONE API
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
> > real userspace. It's used by a few IGT tests and that's it. Since it
> > doesn't add any real value (most of the stuff you can CLONE you can copy
> > in other ways), drop it.
> >
> > There is one thing that this API allows you to clone which you cannot
> > clone via getparam/setparam: timelines. However, timelines are an
> > implementation detail of i915 and not really something that needs to be
> > exposed to userspace. Also, sharing timelines between contexts isn't
> > obviously useful and supporting it has the potential to complicate i915
> > internally. It also doesn't add any functionality that the client can't
> > get in other ways. If a client really wants a shared timeline, they can
> > use a syncobj and set it as an in and out fence on every submit.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Tvrtko Ursulin
>
> This aint gitlab MR, so please include a per-patch (and also per-revision)
> changelog summary here. With that added:
I don't think this patch has changed. I'll scroll through to make sure, though.
> Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
> > .../drm/i915/gt/intel_execlists_submission.c | 28 ---
> > .../drm/i915/gt/intel_execlists_submission.h | 3 -
> > include/uapi/drm/i915_drm.h | 16 +-
> > 4 files changed, 6 insertions(+), 240 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index d6f342e605254..308a63f778faf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1958,207 +1958,14 @@ static int create_setparam(struct
> > i915_user_extension __user *ext, void *data)
> > return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
> > }
> >
> > -static int clone_engines(struct i915_gem_context *dst,
> > - struct i915_gem_context *src)
> > +static int invalid_ext(struct i915_user_extension __user *ext, void *data)
> > {
> > - struct i915_gem_engines *clone, *e;
> > - bool user_engines;
> > - unsigned long n;
> > -
> > - e = __context_engines_await(src, &user_engines);
> > - if (!e)
> > - return -ENOENT;
> > -
> > - clone = alloc_engines(e->num_engines);
> > - if (!clone)
> > - goto err_unlock;
> > -
> > - for (n = 0; n < e->num_engines; n++) {
> > - struct intel_engine_cs *engine;
> > -
> > - if (!e->engines[n]) {
> > - clone->engines[n] = NULL;
> > - continue;
> > - }
> > - engine = e->engines[n]->engine;
> > -
> > - /*
> > - * Virtual engines are singletons; they can only exist
> > - * inside a single context, because they embed their
> > - * HW context... As each virtual context implies a single
> > - * timeline (each engine can only dequeue a single request
> > - * at any time), it would be surprising for two contexts
> > - * to use the same engine. So let's create a copy of
> > - * the virtual engine instead.
> > - */
> > - if (intel_engine_is_virtual(engine))
> > - clone->engines[n] =
> > - intel_execlists_clone_virtual(engine);
> > - else
> > - clone->engines[n] = intel_context_create(engine);
> > - if (IS_ERR_OR_NULL(clone->engines[n])) {
> > - __free_engines(clone, n);
> > - goto err_unlock;
> > - }
> > -
> > - intel_context_set_gem(clone->engines[n], dst);
> > - }
> > - clone->num_engines = n;
> > - i915_sw_fence_complete(&e->fence);
> > -
> > - /* Serialised by constructor */
> > - engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone,
> > 1));
> > - if (user_engines)
> > - i915_gem_context_set_user_engines(dst);
> > - else
> > - i915_gem_context_clear_user_engines(dst);
> > - return 0;
> > -
> > -err_unlock:
> > - i915_sw_fence_complete(&e->fence);
> > - return -ENOMEM;
> > -}
> > -
> > -static int clone_flags(struct i915_gem_context *dst,
> > -struct i915_gem_context *src)
> > -{
> > - dst->user_flags = src->user_flags;
> > - return 0;
> > -}
> > -
> > -static int clone_schedattr(struct i915_gem_context *dst,
> > -struct i915_gem_context *src)
> > -{
> > - dst->sched = src->sched;
> > - return 0
[PATCH v6 0/9] drm: Extract DPCD backlight helpers from i915, add support in nouveau
This series: * Cleans up i915's DPCD backlight code a little bit * Extracts i915's DPCD backlight code into a set of shared DRM helpers * Starts using those helpers in nouveau to add support to nouveau for DPCD backlight control v2 series-wide changes: * Rebase v3 series-wide changes: * Split up the changes to intel's backlight code into separate patches v4 series-wide changes: * Don't forget to actually include the patch that starts using these helpers in nouveau v5 series-wide changes: * Rebase * Use new drm_dbg_*() logging helpers v6 series-wide changes: * Add a bunch of R-bs that got dropped by accident Lyude Paul (9): drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight drm/i915/dpcd_bl: Move VESA backlight enabling code closer together drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT drm/i915/dpcd_bl: Print return codes for VESA backlight failures drm/dp: Extract i915's eDP backlight code into DRM helpers drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau drivers/gpu/drm/drm_dp_helper.c | 347 ++ .../drm/i915/display/intel_display_types.h| 2 +- .../drm/i915/display/intel_dp_aux_backlight.c | 329 ++--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 - drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +- drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 + include/drm/drm_dp_helper.h | 48 +++ 8 files changed, 622 insertions(+), 308 deletions(-) -- 2.31.1
[PATCH v6 2/9] drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 41 +--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 68bfe50ada59..1dbe38282ebe 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -107,7 +107,7 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector
*connector)
u8 tcon_cap[4];
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap,
sizeof(tcon_cap));
- if (ret < 0)
+ if (ret != sizeof(tcon_cap))
return false;
if (!(tcon_cap[1] & INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP))
@@ -137,7 +137,7 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
u8 tmp;
u8 buf[2] = { 0 };
- if (drm_dp_dpcd_readb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
&tmp) < 0) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
&tmp) != 1) {
drm_err(&i915->drm, "Failed to read current backlight mode from
DPCD\n");
return 0;
}
@@ -153,7 +153,8 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
return panel->backlight.max;
}
- if (drm_dp_dpcd_read(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, sizeof(buf)) < 0) {
+ if (drm_dp_dpcd_read(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB, buf,
+sizeof(buf)) != sizeof(buf)) {
drm_err(&i915->drm, "Failed to read brightness from DPCD\n");
return 0;
}
@@ -172,7 +173,8 @@ intel_dp_aux_hdr_set_aux_backlight(const struct
drm_connector_state *conn_state,
buf[0] = level & 0xFF;
buf[1] = (level & 0xFF00) >> 8;
- if (drm_dp_dpcd_write(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, 4) < 0)
+ if (drm_dp_dpcd_write(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf,
+ sizeof(buf)) != sizeof(buf))
drm_err(dev, "Failed to write brightness level to DPCD\n");
}
@@ -203,7 +205,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
u8 old_ctrl, ctrl;
ret = drm_dp_dpcd_readb(&intel_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, &old_ctrl);
- if (ret < 0) {
+ if (ret != 1) {
drm_err(&i915->drm, "Failed to read current backlight control
mode: %d\n", ret);
return;
}
@@ -221,7 +223,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
if (ctrl != old_ctrl)
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) < 0)
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) != 1)
drm_err(&i915->drm, "Failed to configure DPCD
brightness controls\n");
}
@@ -277,8 +279,7 @@ static void set_vesa_backlight_enable(struct intel_dp
*intel_dp, bool enable)
if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
return;
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- ®_val) < 0) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) != 1) {
drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_DISPLAY_CONTROL_REGISTER);
return;
@@ -332,8 +333,8 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
-&read_val, sizeof(read_val)) < 0) {
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
&read_val,
+sizeof(read_val)) != sizeof(read_val)) {
drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
@@ -365,8 +366,8 @@ intel_dp_aux_vesa_set_backlight(
[PATCH v6 1/9] drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_dp_aux_backlight.c | 65 ++-
2 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9c0adfc60c6f..7054a37363fb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -311,6 +311,7 @@ struct intel_panel {
union {
struct {
u8 pwmgen_bit_count;
+ u8 pwm_freq_pre_divider;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 8e9ac9ba1d38..68bfe50ada59 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -373,50 +373,6 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
-{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- const u8 pn = connector->panel.backlight.edp.vesa.pwmgen_bit_count;
- int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
- freq = dev_priv->vbt.backlight.pwm_freq_hz;
- if (!freq) {
- drm_dbg_kms(&dev_priv->drm,
- "Use panel default backlight frequency\n");
- return false;
- }
-
- fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
-
- /* Ensure frequency is within 25% of desired value */
- fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
- fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
- if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
- drm_dbg_kms(&dev_priv->drm, "Actual frequency out of range\n");
- return false;
- }
-
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
- drm_dbg_kms(&dev_priv->drm,
- "Failed to write aux backlight freq\n");
- return false;
- }
- return true;
-}
-
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
@@ -459,9 +415,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
break;
}
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
- if (intel_dp_aux_vesa_set_pwm_freq(connector))
+ if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET,
+
panel->backlight.edp.vesa.pwm_freq_pre_divider) == 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+ else
+ drm_dbg_kms(&i915->drm, "Failed to write aux backlight
frequency\n");
+ }
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
@@ -482,6 +442,14 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
false);
}
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (D
[PATCH v6 3/9] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1dbe38282ebe..1ab82933afb5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_panel *panel = &connector->panel;
- u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
+ u8 dpcd_buf, new_dpcd_buf;
u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
if (drm_dp_dpcd_readb(&intel_dp->aux,
@@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
new_dpcd_buf = dpcd_buf;
- edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- switch (edp_backlight_mode) {
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
@@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
pwmgen_bit_count) != 1)
drm_dbg_kms(&i915->drm,
"Failed to write aux pwmgen bit count\n");
-
- break;
-
- /* Do nothing when it is already DPCD mode */
- case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
- default:
- break;
}
if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
--
2.31.1
[PATCH v6 7/9] drm/i915/dpcd_bl: Print return codes for VESA backlight failures
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 101 +-
1 file changed, 52 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index bf8e4ed56847..95f2df631052 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -274,14 +274,12 @@ static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct
intel_connector *connec
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 mode_reg;
- if (drm_dp_dpcd_readb(&intel_dp->aux,
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
- &mode_reg) != 1) {
- drm_dbg_kms(&i915->drm,
- "Failed to read the DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+ ret = drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &mode_reg);
+ if (ret != 1) {
+ drm_dbg_kms(&i915->drm, "Failed to read backlight mode: %d\n",
ret);
return false;
}
@@ -297,6 +295,7 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 read_val[2] = { 0x0 };
u16 level = 0;
@@ -307,10 +306,10 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
&read_val,
-sizeof(read_val)) != sizeof(read_val)) {
- drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
+ ret = drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
&read_val,
+ sizeof(read_val));
+ if (ret != sizeof(read_val)) {
+ drm_dbg_kms(&i915->drm, "Failed to read brightness level:
%d\n", ret);
return 0;
}
@@ -333,6 +332,7 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 vals[2] = { 0x0 };
/* Write the MSB and/or LSB */
@@ -343,10 +343,10 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
vals[0] = level;
}
- if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
- sizeof(vals)) != sizeof(vals)) {
- drm_dbg_kms(&i915->drm,
- "Failed to write aux backlight level\n");
+ ret = drm_dp_dpcd_write(&intel_dp->aux,
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, vals,
+ sizeof(vals));
+ if (ret != sizeof(vals)) {
+ drm_dbg_kms(&i915->drm, "Failed to write aux backlight level:
%d\n", ret);
return;
}
}
@@ -355,26 +355,28 @@ static void set_vesa_backlight_enable(struct
intel_connector *connector, bool en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) != 1) {
- drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
+ ret = drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_DISPLAY_CONTROL_REGISTER, ®_val);
+ if (ret != 1) {
+ drm_dbg_kms(&i915->drm, "Failed to read eDP display control
register: %d\n", ret);
return;
}
+
if (enable)
reg_val |= DP_EDP_BACKLIGHT_ENABLE;
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
- if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
-
[PATCH v6 8/9] drm/dp: Extract i915's eDP backlight code into DRM helpers
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.
The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.
Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):
* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
v3:
* Split out changes to i915's backlight code to separate patches to make it
easier to review
v4:
* Style/spelling changes from Thomas Zimmermann
v5:
* Start using new drm_dbg_*() functions
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 347 ++
.../drm/i915/display/intel_display_types.h| 5 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 285 ++
include/drm/drm_dp_helper.h | 48 +++
4 files changed, 427 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 55b53df6ce34..24bbc710c825 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3115,3 +3115,350 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux
*aux, u8 color_spc)
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the
panel's backlight must
+ * already have been enabled by the driver by calling
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+ u16 level)
+{
+ int ret;
+ u8 buf[2] = { 0 };
+
+ if (bl->lsb_reg_used) {
+ buf[0] = (level & 0xff00) >> 8;
+ buf[1] = (level & 0x00ff);
+ } else {
+ buf[0] = level;
+ }
+
+ ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
sizeof(buf));
+ if (ret != sizeof(buf)) {
+ drm_err(aux->drm_dev,
+ "%s: Failed to write aux backlight level: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+bool enable)
+{
+ int ret;
+ u8 buf;
+
+ /* The panel uses something other then DPCD for enabling its backlight
*/
+ if (!bl->aux_enable)
+ return 0;
+
+ ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
+ if (ret != 1) {
+ drm_err(aux->drm_dev, "%s: Failed to read eDP display control
register: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+ if (enable)
+ buf |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+ if (ret != 1) {
+ drm_err(aux->drm_dev, "%s: Failed to write eDP display control
register: %d\n",
+ aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over
DPCD, while additionally
+ * restoring any important backlight state such as the g
[PATCH v6 4/9] drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every driver from having to check everything against the eDP DPCD using DP
macros, which makes the code slightly easier to read (especially since the
names of some of the eDP capabilities don't exactly match up with what we
actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT
for instance).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_types.h| 2 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 29 ---
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7054a37363fb..d4a57bce71b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -312,6 +312,8 @@ struct intel_panel {
struct {
u8 pwmgen_bit_count;
u8 pwm_freq_pre_divider;
+ bool lsb_reg_used;
+ bool aux_enable;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1ab82933afb5..1d31c33f4867 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,13 +270,14 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
- if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) != 1) {
@@ -339,9 +340,11 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
- level = read_val[0];
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
+
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used)
level = (read_val[0] << 8 | read_val[1]);
+ else
+ level = read_val[0];
return level;
}
@@ -359,13 +362,14 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
- vals[0] = level;
-
/* Write the MSB and/or LSB */
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
+ } else {
+ vals[0] = level;
}
+
if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
sizeof(vals)) != sizeof(vals)) {
drm_dbg_kms(&i915->drm,
@@ -419,14 +423,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
intel_dp_aux_vesa_set_backlight(conn_state, level);
- set_vesa_backlight_enable(intel_dp, true);
+ set_vesa_backlight_enable(connector, true);
}
static void intel_dp_aux_vesa_disable_backlight(const struct
drm_connector_state *old_conn_state,
u32 level)
{
-
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
- false);
+
set_vesa_backlight_enable(to_intel_connector(old_conn_state->connector), false);
}
/*
@@ -524,8 +527,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector *connector,
enum pipe pipe)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_panel *panel = &connector->panel;
+ if (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)
+ panel->b
[PATCH v6 9/9] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.
Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 28
drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
4 files changed, 186 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c46d0374b6e6..80ad2d6b7e4b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1648,15 +1649,30 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
}
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and
uses a
+ * fixed time delay from the vbios…
+ */
static void
nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
*state)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(state, nv_encoder);
+ struct nouveau_backlight *backlight = nv_connector->backlight;
struct drm_dp_aux *aux = &nv_connector->aux;
+ int ret;
u8 pwr;
+ if (backlight && backlight->uses_dpcd) {
+ ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
+ if (ret < 0)
+ NV_ERROR(drm, "Failed to disable backlight on
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id,
nv_connector->base.name, ret);
+ }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
@@ -1695,6 +1711,9 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = &drm->vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1769,6 +1788,14 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
nv50_audio_enable(encoder, nv_crtc, nv_connector, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ backlight = nv_connector->backlight;
+ if (backlight && backlight->uses_dpcd)
+ drm_edp_backlight_enable(&nv_connector->aux,
&backlight->edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2294,6 +2321,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 72f35a2babcb..1cbd71abc80a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -42,11 +42,6 @@
static struct ida bl_ida;
#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
-struct nouveau_backlight {
- struct backlight_device *dev;
- int id;
-};
-
[PATCH v6 5/9] drm/i915/dpcd_bl: Move VESA backlight enabling code closer together
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 1d31c33f4867..781c7cd98d75 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,33 +270,6 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
-{
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 reg_val = 0;
-
- /* Early return when display use other mechanism to enable backlight. */
- if (!connector->panel.backlight.edp.vesa.aux_enable)
- return;
-
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) != 1) {
- drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
- return;
- }
- if (enable)
- reg_val |= DP_EDP_BACKLIGHT_ENABLE;
- else
- reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
-
- if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- reg_val) != 1) {
- drm_dbg_kms(&i915->drm, "Failed to %s aux backlight\n",
- enabledisable(enable));
- }
-}
-
static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector
*connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -378,6 +351,33 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 reg_val = 0;
+
+ /* Early return when display use other mechanism to enable backlight. */
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
+ return;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) != 1) {
+ drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
+ DP_EDP_DISPLAY_CONTROL_REGISTER);
+ return;
+ }
+ if (enable)
+ reg_val |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
+
+ if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ reg_val) != 1) {
+ drm_dbg_kms(&i915->drm, "Failed to %s aux backlight\n",
+ enabledisable(enable));
+ }
+}
+
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
--
2.31.1
[PATCH v6 6/9] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 781c7cd98d75..bf8e4ed56847 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -449,11 +449,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
u8 pn, pn_min, pn_max;
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, &pn) ==
1) {
- pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
- max_backlight = (1 << pn) - 1;
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, &pn) !=
1) {
+ drm_dbg_kms(&i915->drm, "Failed to read pwmgen bit count
cap\n");
+ return 0;
}
+ pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ max_backlight = (1 << pn) - 1;
+
/* Find desired value of (F x P)
* Note that, if F x P is out of supported range, the maximum value or
* minimum value will applied automatically. So no need to check that.
--
2.31.1
Re: [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
> > more magic than that. If FENCE_SUBMIT is used to submit something to a
> > balanced engine, we would wait to assign engines until the primary
> > request was ready to start and then attempt to assign it to a different
> > engine than the primary. There is an IGT test which exercises this by
> > submitting a primary batch to a specific VCS and then using FENCE_SUBMIT
> > to submit a secondary which can run on any VCS and have i915 figure out
> > which VCS to run it on such that they can run in parallel.
> >
> > However, this functionality has never been used in the real world. The
> > media driver (the only user of FENCE_SUBMIT) always picks exactly two
> > physical engines to bond and never asks us to pick which to use.
>
> Maybe reference the specific igt you're break (and removing in the igt
> series to match this) here. Just for the record and all that.
Done.
> -Daniel
>
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h| 7 ---
> > .../drm/i915/gt/intel_execlists_submission.c| 17 -
> > 3 files changed, 1 insertion(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index d640bba6ad9ab..efb2fa3522a42 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -3474,7 +3474,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > if (args->flags & I915_EXEC_FENCE_SUBMIT)
> > err = i915_request_await_execution(eb.request,
> > in_fence,
> > -
> > eb.engine->bond_execute);
> > +NULL);
> > else
> > err = i915_request_await_dma_fence(eb.request,
> > in_fence);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 883bafc449024..68cfe5080325c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -446,13 +446,6 @@ struct intel_engine_cs {
> >*/
> > void(*submit_request)(struct i915_request *rq);
> >
> > - /*
> > - * Called on signaling of a SUBMIT_FENCE, passing along the signaling
> > - * request down to the bonded pairs.
> > - */
> > - void(*bond_execute)(struct i915_request *rq,
> > - struct dma_fence *signal);
> > -
> > /*
> >* Call when the priority on a request has changed and it and its
> >* dependencies may need rescheduling. Note the request itself may
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 14378b28169b7..635d6d2494d26 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3547,22 +3547,6 @@ static void virtual_submit_request(struct
> > i915_request *rq)
> > spin_unlock_irqrestore(&ve->base.active.lock, flags);
> > }
> >
> > -static void
> > -virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> > -{
> > - intel_engine_mask_t allowed, exec;
> > -
> > - allowed = ~to_request(signal)->engine->mask;
> > -
> > - /* Restrict the bonded request to run on only the available engines */
> > - exec = READ_ONCE(rq->execution_mask);
> > - while (!try_cmpxchg(&rq->execution_mask, &exec, exec & allowed))
> > - ;
> > -
> > - /* Prevent the master from being re-run on the bonded engines */
> > - to_request(signal)->execution_mask &= ~allowed;
> > -}
> > -
> > struct intel_context *
> > intel_execlists_create_virtual(struct intel_engine_cs **siblings,
> > unsigned int count)
> > @@ -3616,7 +3600,6 @@ intel_execlists_create_virtual(struct intel_engine_cs
> > **siblings,
> >
> > ve->base.schedule = i915_schedule;
> > ve->base.submit_request = virtual_submit_request;
> > - ve->base.bond_execute = virtual_bond_execute;
> >
> > INIT_LIST_HEAD(virtual_queue(ve));
> > ve->base.execlists.queue_priority_hint = INT_MIN;
> > --
> > 2.31.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo
Re: [Intel-gfx] [PATCH 17/27] drm/i915/gem: Rework error handling in default_engines
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
>
> I guess subsequent patches apply the same for the set_engines command and
> __free_engines disappears? Otherwise feels a bit silly.
Working towards that.
> Anyway looks correct.
>
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 10bd1b6dd1774..ce729e640bbf7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -420,7 +420,7 @@ static struct i915_gem_engines *default_engines(struct
> > i915_gem_context *ctx)
> > {
> > const struct intel_gt *gt = &ctx->i915->gt;
> > struct intel_engine_cs *engine;
> > - struct i915_gem_engines *e;
> > + struct i915_gem_engines *e, *err;
> > enum intel_engine_id id;
> >
> > e = alloc_engines(I915_NUM_ENGINES);
> > @@ -438,18 +438,21 @@ static struct i915_gem_engines
> > *default_engines(struct i915_gem_context *ctx)
> >
> > ce = intel_context_create(engine);
> > if (IS_ERR(ce)) {
> > - __free_engines(e, e->num_engines + 1);
> > - return ERR_CAST(ce);
> > + err = ERR_CAST(ce);
> > + goto free_engines;
> > }
> >
> > intel_context_set_gem(ce, ctx);
> >
> > e->engines[engine->legacy_idx] = ce;
> > - e->num_engines = max(e->num_engines, engine->legacy_idx);
> > + e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
> > }
> > - e->num_engines++;
> >
> > return e;
> > +
> > +free_engines:
> > + free_engines(e);
> > + return err;
> > }
> >
> > void i915_gem_context_release(struct kref *ref)
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 10:37 AM Linus Torvalds
wrote:
>
> IOW, something like this would seem fairly simple and straightforward:
Proper patch in case syzbot can test this..
Linus
From b33ca195cecea478768de353b3ae976c07a65615 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Fri, 14 May 2021 11:06:12 -0700
Subject: [PATCH] vt: don't allow text-mode resizing when in KD_GRAPHICS mode
The VT layer itself just keeps track of the underlying text contents
just fine, but if the underlying hardware driver has a con_resize()
function, we can't just ignore it when in KD_GRAPHICS mode.
So just refuse to do a text mode resize if we're not in text mode.
Reported-by: Tetsuo Handa
Reported-by: syzbot
Signed-off-by: Linus Torvalds
---
drivers/tty/vt/vt.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 01645e87b3d5..f24e627b7402 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1171,8 +1171,13 @@ static inline int resize_screen(struct vc_data *vc, int width, int height,
/* Resizes the resolution of the display adapater */
int err = 0;
- if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_resize)
+ if (vc->vc_sw->con_resize) {
+ // If we have a resize function but are in KD_GRAPHICS mode,
+ // we can't actually do a resize and need to error out.
+ if (vc->vc_mode == KD_GRAPHICS)
+ return -EINVAL;
err = vc->vc_sw->con_resize(vc, width, height, user);
+ }
return err;
}
--
2.31.1.365.ga2a05a39c5
Re: [PATCH][V2][next] drm/vmwgfx: Fix memory allocation check and a leak of object fifo
On 5/14/21 10:49 AM, Colin King wrote:
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Kudos to Dan Carpenter for spotting the missing kzalloc failure
check.
Addresses-Coverity: ("Resource leak")
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Colin Ian King
---
V2: Add missing allocation failure check
Update $SUBJECT to reflect this extra change
Looks good. Thanks. I'll push it through drm-misc-next.
z
Re: [PATCH -next] drm/vmwgfx: Fix return value check in vmw_setup_pci_resources()
On 5/14/21 4:28 AM, Qiheng Lin wrote: In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. After that, the error code -ENOMEM should be returned. Reported-by: Hulk Robot Signed-off-by: Qiheng Lin Looks good. Thank you. I'll push it with some other fixes via drm-misc-next. z
Re: [PATCH 19/27] drm/i915/gem: Use the proto-context to handle create parameters
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
> > be deleting a lot of setparam logic on the primary context shortly so it
> > will hopefully balance out.
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 546 +-
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
> > 2 files changed, 587 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 6dd50d669c5b9..aa4edfbf7ed48 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -193,8 +193,15 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> >
> > static void proto_context_close(struct i915_gem_proto_context *pc)
> > {
> > + int i;
> > +
> > if (pc->vm)
> > i915_vm_put(pc->vm);
> > + if (pc->user_engines) {
> > + for (i = 0; i < pc->num_user_engines; i++)
> > + kfree(pc->user_engines[i].siblings);
> > + kfree(pc->user_engines);
>
> free_engines(&pc->user_engines);
>
> Maybe even stuff that if check into free_engines. Except I realized this
> is proto engines here now :-(
>
> > + }
> > kfree(pc);
> > }
> >
> > @@ -248,6 +255,9 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > if (!pc)
> > return ERR_PTR(-ENOMEM);
> >
> > + pc->num_user_engines = -1;
> > + pc->user_engines = NULL;
> > +
> > if (HAS_FULL_PPGTT(i915)) {
> > struct i915_ppgtt *ppgtt;
> >
> > @@ -282,6 +292,439 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > return err;
> > }
> >
> > +static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> > + struct i915_gem_proto_context *pc,
> > + const struct drm_i915_gem_context_param *args)
> > +{
> > + struct i915_address_space *vm;
> > +
> > + if (args->size)
> > + return -EINVAL;
> > +
> > + if (!pc->vm)
> > + return -ENODEV;
> > +
> > + if (upper_32_bits(args->value))
> > + return -ENOENT;
> > +
> > + rcu_read_lock();
> > + vm = xa_load(&fpriv->vm_xa, args->value);
> > + if (vm && !kref_get_unless_zero(&vm->ref))
> > + vm = NULL;
> > + rcu_read_unlock();
>
> vm lookup helpers would be nice I guess, but perhaps something that
> vm_bind patches should do.
I can add those. I just don't know where to put it. We don't have an
i915_gem_vm.h. Suggestions?
>
> > + if (!vm)
> > + return -ENOENT;
> > +
> > + i915_vm_put(pc->vm);
>
> Ah I guess I've found why you went with "pc->vm is always set". *shrug*
>
> > + pc->vm = vm;
> > +
> > + return 0;
> > +}
> > +
> > +struct set_proto_ctx_engines {
> > + struct drm_i915_private *i915;
> > + unsigned num_engines;
> > + struct i915_gem_proto_engine *engines;
> > +};
> > +
> > +static int
> > +set_proto_ctx_engines_balance(struct i915_user_extension __user *base,
> > + void *data)
> > +{
> > + struct i915_context_engines_load_balance __user *ext =
> > + container_of_user(base, typeof(*ext), base);
> > + const struct set_proto_ctx_engines *set = data;
> > + struct drm_i915_private *i915 = set->i915;
> > + struct intel_engine_cs **siblings;
> > + u16 num_siblings, idx;
> > + unsigned int n;
> > + int err;
> > +
> > + if (!HAS_EXECLISTS(i915))
> > + return -ENODEV;
> > +
> > + if (intel_uc_uses_guc_submission(&i915->gt.uc))
> > + return -ENODEV; /* not implement yet */
> > +
> > + if (get_user(idx, &ext->engine_index))
> > + return -EFAULT;
> > +
> > + if (idx >= set->num_engines) {
> > + drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
> > + idx, set->num_engines);
> > + return -EINVAL;
> > + }
> > +
> > + idx = array_index_nospec(idx, set->num_engines);
> > + if (set->engines[idx].type != I915_GEM_ENGINE_TYPE_INVALID) {
> > + drm_dbg(&i915->drm,
> > + "Invalid placement[%d], already occupied\n", idx);
> > + return -EEXIST;
> > + }
> > +
> > + if (get_user(num_siblings, &ext->num_siblings))
> > + return -EFAULT;
> > +
> > + err = check_user_mbz(&ext->flags);
> > + if (err)
> > + return err;
> > +
> > + err = check_user_mbz(&ext->mbz64);
> > + if (err)
> > + return err;
> > +
> > + if (num_siblings == 0)
> > + return 0;
>
> You deleted the on-stack
Re: [pull] drm/msm: drm-msm-fixes-2021-05-09 for v5.13-rc2
On Sun, May 9, 2021 at 4:21 PM Rob Clark wrote: > > Hi Dave & Daniel, > > First round of fixes for v5.13 > > The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621: > > drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09 > 12:02:35 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git this should have been: https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-05-09 BR, -R > > for you to fetch changes up to f2f46b878777e0d3f885c7ddad48f477b4dea247: > > drm/msm/dp: initialize audio_comp when audio starts (2021-05-06 > 16:26:57 -0700) > > > Dmitry Baryshkov (2): > drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access > drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code > > Jonathan Marek (2): > drm/msm: fix LLC not being enabled for mmu500 targets > drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support > > Kuogee Hsieh (2): > drm/msm/dp: check sink_count before update is_connected status > drm/msm/dp: initialize audio_comp when audio starts > > Rob Clark (1): > drm/msm: Do not unpin/evict exported dma-buf's > > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 + > drivers/gpu/drm/msm/dp/dp_audio.c | 1 + > drivers/gpu/drm/msm/dp/dp_display.c | 26 > - > drivers/gpu/drm/msm/dp/dp_display.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/msm/msm_gem.c | 16 ++- > drivers/gpu/drm/msm/msm_gem.h | 4 ++-- > 9 files changed, 47 insertions(+), 18 deletions(-)
[resend][pull] drm/msm: drm-msm-fixes-2021-05-09 for v5.13-rc2
Hi Dave & Daniel, First round of fixes for v5.13 The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621: drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09 12:02:35 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-05-09 for you to fetch changes up to f2f46b878777e0d3f885c7ddad48f477b4dea247: drm/msm/dp: initialize audio_comp when audio starts (2021-05-06 16:26:57 -0700) Dmitry Baryshkov (2): drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code Jonathan Marek (2): drm/msm: fix LLC not being enabled for mmu500 targets drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support Kuogee Hsieh (2): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts Rob Clark (1): drm/msm: Do not unpin/evict exported dma-buf's drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 + drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 26 - drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 16 ++- drivers/gpu/drm/msm/msm_gem.h | 4 ++-- 9 files changed, 47 insertions(+), 18 deletions(-)
[PATCH v3 0/3] Add option to mmap GEM buffers cached
oRework of my previous patchset which added support for GEM buffers backed by non-coherent memory to the ingenic-drm driver. Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. For the record, a previous patchset was accepted for 5.10 then had to be reverted, as it conflicted with some changes made to the DMA API. The first two patches add support for cached GEM buffers in the DRM core, the third patch adds support for this functionality in the ingenic-drm driver for the JZ4770 SoC. Cheers, -Paul Paul Cercueil (3): drm: Add support for GEM buffers backed by non-coherent memory drm: Add and export function drm_gem_cma_sync_data drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_gem_cma_helper.c | 96 ++- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 56 - drivers/gpu/drm/ingenic/ingenic-ipu.c | 18 - include/drm/drm_gem_cma_helper.h | 12 ++- 4 files changed, 171 insertions(+), 11 deletions(-) -- 2.30.2
[PATCH v3 1/3] drm: Add support for GEM buffers backed by non-coherent memory
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on some Ingenic SoCs, where even simple blits (e.g. memcpy)
are about three times faster using this method.
Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which
can be set by the drivers when they create the dumb buffer.
Since this really only applies to software rendering, disable this flag
as soon as the CMA objects are exported via PRIME.
v3: New patch. Now uses a simple 'map_noncoherent' flag to control how
the objects are mapped, and use the new dma_mmap_pages function.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 41 +---
include/drm/drm_gem_cma_helper.h | 7 -
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..81a31bcf7d68 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -115,8 +115,15 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
if (IS_ERR(cma_obj))
return cma_obj;
- cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
- GFP_KERNEL | __GFP_NOWARN);
+ if (cma_obj->map_noncoherent) {
+ cma_obj->vaddr = dma_alloc_noncoherent(drm->dev, size,
+ &cma_obj->paddr,
+ DMA_TO_DEVICE,
+ GFP_KERNEL |
__GFP_NOWARN);
+ } else {
+ cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
+ GFP_KERNEL | __GFP_NOWARN);
+ }
if (!cma_obj->vaddr) {
drm_dbg(drm, "failed to allocate buffer with size %zu\n",
size);
@@ -499,8 +506,13 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
cma_obj = to_drm_gem_cma_obj(obj);
- ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ if (!cma_obj->map_noncoherent)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
+ ret = dma_mmap_pages(cma_obj->base.dev->dev,
+vma, vma->vm_end - vma->vm_start,
+virt_to_page(cma_obj->vaddr));
if (ret)
drm_gem_vm_close(vma);
@@ -556,3 +568,24 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
return obj;
}
EXPORT_SYMBOL(drm_gem_cma_prime_import_sg_table_vmap);
+
+/**
+ * drm_gem_cma_prime_mmap - PRIME mmap function for CMA GEM drivers
+ * @obj: GEM object
+ * @vma: Virtual address range
+ *
+ * Carbon copy of drm_gem_prime_mmap, but the 'map_noncoherent' flag is
+ * disabled to ensure that the exported buffers have the expected cache
+ * coherency.
+ */
+int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
+{
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+ /* Use standard cache settings for PRIME-exported GEM buffers */
+ cma_obj->map_noncoherent = false;
+
+ return drm_gem_prime_mmap(obj, vma);
+}
+EXPORT_SYMBOL(drm_gem_cma_prime_mmap);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 0a9711caa3e8..b597e00fd5f6 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -16,6 +16,7 @@ struct drm_mode_create_dumb;
* more than one entry but they are guaranteed to have contiguous
* DMA addresses.
* @vaddr: kernel virtual address of the backing memory
+ * @map_noncoherent: if true, the GEM object is backed by non-coherent memory
*/
struct drm_gem_cma_object {
struct drm_gem_object base;
@@ -24,6 +25,8 @@ struct drm_gem_cma_object {
/* For objects with DMA memory allocated by GEM CMA */
void *vaddr;
+
+ bool map_noncoherent;
};
#define to_drm_gem_cma_obj(gem_obj) \
@@ -119,7 +122,7 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma);
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, \
- .gem_prime_mmap = drm_gem_prime_mmap
+ .gem_prime_mmap = drm_gem_cma_prime_mmap
/**
* DRM_GEM_CMA_DRIVER_OPS - CMA GEM driver operations
@@ -181,5 +184,7 @@ struct drm_gem_object
[PATCH v3 2/3] drm: Add and export function drm_gem_cma_sync_data
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coherent memory.
- Use a drm_device pointer instead of device pointer in prototype
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 55
include/drm/drm_gem_cma_helper.h | 5 +++
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 81a31bcf7d68..9dbe766c3177 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -17,9 +17,14 @@
#include
#include
+#include
#include
#include
+#include
+#include
+#include
#include
+#include
#include
/**
@@ -589,3 +594,53 @@ int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
return drm_gem_prime_mmap(obj, vma);
}
EXPORT_SYMBOL(drm_gem_cma_prime_mmap);
+
+/**
+ * drm_gem_cma_sync_data - Sync GEM object to non-coherent backing memory
+ * @drm: DRM device
+ * @old_state: Old plane state
+ * @state: New plane state
+ *
+ * This function can be used by drivers that use damage clips and have
+ * CMA GEM objects backed by non-coherent memory. Calling this function
+ * in a plane's .atomic_update ensures that all the data in the backing
+ * memory have been written to RAM.
+ */
+void drm_gem_cma_sync_data(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state)
+{
+ const struct drm_format_info *finfo = state->fb->format;
+ struct drm_atomic_helper_damage_iter iter;
+ const struct drm_gem_cma_object *cma_obj;
+ unsigned int offset, i;
+ struct drm_rect clip;
+ dma_addr_t daddr;
+
+ for (i = 0; i < finfo->num_planes; i++) {
+ cma_obj = drm_fb_cma_get_gem_obj(state->fb, i);
+
+ if (cma_obj->map_noncoherent)
+ break;
+ }
+
+ /* No non-coherent buffers - no need to sync anything. */
+ if (i == finfo->num_planes)
+ return;
+
+ drm_atomic_helper_damage_iter_init(&iter, old_state, state);
+
+ drm_atomic_for_each_plane_damage(&iter, &clip) {
+ for (i = 0; i < finfo->num_planes; i++) {
+ daddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
+
+ /* Ignore x1/x2 values, invalidate complete lines */
+ offset = clip.y1 * state->fb->pitches[i];
+
+ dma_sync_single_for_device(drm->dev, daddr + offset,
+ (clip.y2 - clip.y1) *
state->fb->pitches[i],
+ DMA_TO_DEVICE);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(drm_gem_cma_sync_data);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index b597e00fd5f6..4ccc8c69e594 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -7,6 +7,7 @@
#include
struct drm_mode_create_dumb;
+struct drm_plane_state;
/**
* struct drm_gem_cma_object - GEM object backed by CMA memory allocations
@@ -187,4 +188,8 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*drm,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
+void drm_gem_cma_sync_data(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state);
+
#endif /* __DRM_GEM_CMA_HELPER_H__ */
--
2.30.2
[PATCH v3 3/3] drm/ingenic: Add option to alloc cached GEM buffers
With the module parameter ingenic-drm.cached_gem_buffers, it is possible
to specify that we want GEM buffers backed by non-coherent memory.
This dramatically speeds up software rendering on Ingenic SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
Enable it on SoCs where it is actually faster than write-combine.
v3: The option is now selected per-SoC instead of being a module
parameter.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 56 ++-
drivers/gpu/drm/ingenic/ingenic-ipu.c | 18 ++--
2 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 09225b770bb8..5f64e8583eec 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +59,7 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool map_noncoherent;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -410,6 +413,8 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
crtc_state->mode_changed = true;
+ drm_atomic_helper_check_plane_damage(state, new_plane_state);
+
return 0;
}
@@ -544,8 +549,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
struct drm_atomic_state *state)
{
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
- struct drm_plane_state *newstate = drm_atomic_get_new_plane_state(state,
-
plane);
+ struct drm_plane_state *newstate =
drm_atomic_get_new_plane_state(state, plane);
+ struct drm_plane_state *oldstate =
drm_atomic_get_old_plane_state(state, plane);
struct drm_crtc_state *crtc_state;
struct ingenic_dma_hwdesc *hwdesc;
unsigned int width, height, cpp, offset;
@@ -553,6 +558,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
u32 fourcc;
if (newstate && newstate->fb) {
+ drm_gem_cma_sync_data(&priv->drm, oldstate, newstate);
+
crtc_state = newstate->crtc->state;
addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
@@ -742,6 +749,43 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
*crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
}
+static int ingenic_drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags,
+unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(fb->dev);
+
+ if (!priv->soc_info->map_noncoherent)
+ return 0;
+
+ return drm_atomic_helper_dirtyfb(fb, file_priv, flags,
+color, clips, num_clips);
+}
+
+static const struct drm_framebuffer_funcs ingenic_drm_gem_fb_funcs = {
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = ingenic_drm_atomic_helper_dirtyfb,
+};
+
+static struct drm_gem_object *
+ingenic_drm_gem_create_object(struct drm_device *drm, size_t size)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(drm);
+ struct drm_gem_cma_object *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ obj->map_noncoherent = priv->soc_info->map_noncoherent;
+
+ return &obj->base;
+}
+
DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
static const struct drm_driver ingenic_drm_driver_data = {
@@ -754,6 +798,7 @@ static const struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
.fops = &ingenic_drm_fops,
+ .gem_create_object = ingenic_drm_gem_create_object,
DRM_GEM_CMA_DRIVER_OPS,
.irq_handler= ingenic_drm_irq_handler,
@@ -961,6 +1006,8 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
return ret;
}
+ drm_plane_enable_fb_damage_clips(&priv->f1);
+
drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs);
ret = d
Re: [Intel-gfx] [RFC PATCH 4/5] drm/i915: Introduce 'set parallel submit' extension
On Wed, May 12, 2021 at 10:34:59AM +0200, Daniel Vetter wrote:
> On Tue, May 11, 2021 at 11:44:28AM -0700, Matthew Brost wrote:
> > On Tue, May 11, 2021 at 05:11:44PM +0200, Daniel Vetter wrote:
> > > On Thu, May 06, 2021 at 10:30:48AM -0700, Matthew Brost wrote:
> > > > i915_drm.h updates for 'set parallel submit' extension.
> > > >
> > > > Cc: Tvrtko Ursulin
> > > > Cc: Tony Ye
> > > > CC: Carl Zhang
> > > > Cc: Daniel Vetter
> > > > Cc: Jason Ekstrand
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > include/uapi/drm/i915_drm.h | 126
> > > > 1 file changed, 126 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 26d2e135aa31..0175b12b33b8 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1712,6 +1712,7 @@ struct drm_i915_gem_context_param {
> > > > * Extensions:
> > > > * i915_context_engines_load_balance
> > > > (I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE)
> > > > * i915_context_engines_bond (I915_CONTEXT_ENGINES_EXT_BOND)
> > > > + * i915_context_engines_parallel_submit
> > > > (I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT)
> > >
> > > Hm just relalized, but I don't think this hyperlinsk correctly, and I'm
> > > also not sure this formats very well as a nice list. Using item lists
> > > should look pretty nice like we're doing for the various kms properties,
> > > e.g.
> > >
> > > FOO:
> > > Explain what FOO does
> > >
> > > BAR:
> > > Explain what BAR does. struct bar also automatically generates a link
> > >
> > > Please check with make htmldocs and polish this a bit (might need a small
> > > prep patch).
> > >
> >
> > I agree the doc should look nice. To get there I might need to chat with
> > you on
> > IRC as I'm new to this.
> >
> > > > */
> > > > #define I915_CONTEXT_PARAM_ENGINES 0xa
> > > >
> > > > @@ -1894,9 +1895,134 @@ struct i915_context_param_engines {
> > > > __u64 extensions; /* linked chain of extension blocks, 0
> > > > terminates */
> > > > #define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see
> > > > i915_context_engines_load_balance */
> > > > #define I915_CONTEXT_ENGINES_EXT_BOND 1 /* see
> > > > i915_context_engines_bond */
> > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > > i915_context_engines_parallel_submit */
> > > > struct i915_engine_class_instance engines[0];
> > > > } __attribute__((packed));
> > > >
> > > > +/*
> > > > + * i915_context_engines_parallel_submit:
> > > > + *
> > > > + * Setup a gem context to allow multiple BBs to be submitted in a
> > > > single execbuf
> > > > + * IOCTL. Those BBs will then be scheduled to run on the GPU in
> > > > parallel.
> > > > + *
> > > > + * All hardware contexts in the engine set are configured for parallel
> > > > + * submission (i.e. once this gem context is configured for parallel
> > > > submission,
> > > > + * all the hardware contexts, regardless if a BB is available on each
> > > > individual
> > > > + * context, will be submitted to the GPU in parallel). A user can
> > > > submit BBs to
> > > > + * subset of the hardware contexts, in a single execbuf IOCTL, but it
> > > > is not
> > > > + * recommended as it may reserve physical engines with nothing to run
> > > > on them.
> > > > + * Highly recommended to configure the gem context with N hardware
> > > > contexts then
> > > > + * always submit N BBs in a single IOCTL.
> > > > + *
> > > > + * Their are two currently defined ways to control the placement of the
> > > > + * hardware contexts on physical engines: default behavior (no flags)
> > > > and
> > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the
> > > > in the
> > > > + * future as new hardware / use cases arise. Details of how to use this
> > > > + * interface below above the flags.
> > > > + *
> > > > + * Returns -EINVAL if hardware context placement configuration invalid
> > > > or if the
> > > > + * placement configuration isn't supported on the platform / submission
> > > > + * interface.
> > > > + * Returns -ENODEV if extension isn't supported on the platform /
> > > > submission
> > > > + * inteface.
> > > > + */
> > > > +struct i915_context_engines_parallel_submit {
> > > > + struct i915_user_extension base;
> > >
> > > Ok this is good, since it makes sure we can't possible use this in
> > > CTX_SETPARAM.
> > >
> >
> > Yep, this is at context creation time. Technically you still can call this
> > over
> > and over on the same gem context but Jason is taking that ability away I
> > believe. I've also told the media team to setup the context once and don't
> > touch
> > it again.
>
> Only if you base your context param on drm_i915_gem_context_param, which
> can be used both at create time with
> drm_i915_gem_context_create_ext_setparam and with the CTX_SETPARAM ioctl.
> But you don't, so this issue is fixed at the uapi
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Currently it is impossible to control upper limit of rows/columns values
> > based on amount of memory reserved for the graphical screen, for
> > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> > already KD_GRAPHICS
>
> Honestly, the saner approach would seem to be to simply error out if
> vc_mode is KD_GRAPHICS.
>
> Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable,
> and is clearly currently very buggy.
I haven't looked into it any further beyond tracking down (again, using
the LMO tree) the originating change as the other fix took precedence. It
came with:
commit 094e0a9cdbdf1e11a28dd756a6cbd750b6303d10
Author: Ralf Baechle
Date: Sun Jun 1 12:07:37 2003 +
Merge with Linux 2.5.51
along with framebuffer console support:
+inline int resize_screen(int currcons, int width, int height)
+{
+ /* Resizes the resolution of the display adapater */
+ int err = 0;
+
+ if (vcmode != KD_GRAPHICS && sw->con_resize)
+ err = sw->con_resize(vc_cons[currcons].d, width, height);
+ return err;
+}
+
A handler for fbcon was added shortly afterwards with:
commit bab384bdbe279efd7acc2146ef13b0b0395b2a42
Author: Ralf Baechle
Date: Tue Jun 3 17:04:10 2003 +
Merge with Linux 2.5.59.
however vgacon didn't have a handler for it until commit 28254d439b8c
("[PATCH] vga text console and stty cols/rows") two years later only.
Overall I think it does make sense to resize the text console at any
time, even if the visible console (VT) chosen is in the graphics mode, as
my understanding (and experience at least with vgacon) is that resizing
the console applies globally across all the VTs. So the intent of the
original change appears valid to me, and the choice not to reprogram the
visible console and only store the settings for a future use if it's in
the graphics mode correct.
Which means any bug triggered here needs to be fixed elsewhere rather
than by making the request fail.
NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
kind enough to know how to fiddle with its clockchip. It works just fine.
Maciej
Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit()
On Fri, May 14, 2021 at 1:25 PM Maciej W. Rozycki wrote: > > Overall I think it does make sense to resize the text console at any > time, even if the visible console (VT) chosen is in the graphics mode, It might make sense, but only if we call the function to update the low-level data. Not calling it, and then starting to randomly use the (wrong) geometry, and just limiting it so that it's all within the buffer - THAT does not make sense. So I think your patch is fundamentally wrong. It basically says "let's use random stale incorrect data, but just make sure that the end result is still within the allocated buffer". My patch is at least conceptually sane. An alternative would be to just remove the "vcmode != KD_GRAPHICS" check entirely, and always call con_resize() to update the low-level data, but honestly, that seems very likelty to break something very fundamentally, since it's not how any of fbcon has ever been tested, Another alternative would be to just delay the resize to when vcmode is put back to text mode again. That sounds somewhat reasonable to me, but it's a pretty big thing. But no, your patch to just "knowingly use entirely wrong values, then add a limit check because we know the values are possibly garbage and not consistent with reality" is simply not acceptable. Linus
[PATCH 1/1] drm: drm_legacy_addbufs_pci(): fix return without cleanup
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free" leads
to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '&dev->struct_mutex'.
Locked on : 988
Unlocked on: 938,944,951,959,973,1005,1042,1060,1090
Fix the return without cleanup by removing the early return and taking
the original return path on allocation failure, including the intended
unlocks.
Signed-off-by: Joseph Kogut
---
drivers/gpu/drm/drm_bufs.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 94bc1f6049c9..ea3ca81be9dd 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -984,17 +984,18 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
while (entry->buf_count < count) {
dmah = kmalloc(sizeof(drm_dma_handle_t), GFP_KERNEL);
- if (!dmah)
- return -ENOMEM;
-
- dmah->size = total;
- dmah->vaddr = dma_alloc_coherent(dev->dev,
-dmah->size,
-&dmah->busaddr,
-GFP_KERNEL);
- if (!dmah->vaddr) {
- kfree(dmah);
-
+ if (dmah) {
+ dmah->size = total;
+ dmah->vaddr = dma_alloc_coherent(dev->dev,
+dmah->size,
+&dmah->busaddr,
+GFP_KERNEL);
+ if (!dmah->vaddr) {
+ kfree(dmah);
+ dmah = NULL;
+ }
+ }
+ if (!dmah) {
/* Set count correctly so we free the proper amount. */
entry->buf_count = count;
entry->seg_count = count;
--
2.31.1
Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
On 2021-04-30 6:39 a.m., Shashank Sharma wrote: > Hello Pekka, > > On 30/04/21 15:13, Pekka Paalanen wrote: >> On Wed, 28 Apr 2021 13:24:27 +0530 >> Shashank Sharma wrote: >> >>> Assuming these details, A compositor will look for DRM color properties >>> like these: >>> >>> 1. Degamma plane property : To make buffers linear for Gamut mapping >>> >>> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020 >>> colorspace >>> >>> 3. Color space conversion plane property: To convert from YCBCR->RGB >>> >>> 4. Tone mapping plane property: To tone map SDR buffer S2H and HDR buffer >>> H2H >>> >>> 5. Gamma plane/CRTC property: to re-apply the output ST2084 curve >>> >>> >> ... >> >>> * >>> * >>> * >>> * ┌─┐ ┌─┐ >>> ┌─┐ ┌┐ >>> * HDR 600 Nits│ │HDR 600 Nits │ │HDR600 >>> │ │HDR500 │ │ HDR500 >>> * ► │ Degamma ├►│ Color space >>> ├──►│ Tone mapping ├──►│ Gamma │ >>> * BT2020 │ OETF ST2084 │ BT2020 │ conversion │BT2020 >>> │ H2H │BT2020 │ ST2084 │ BT2020 >>> * YCBCR420 │ │ YCBCR420 │ YCBCR->RGB │RGB88 >>> │ 600->500 │RGB888 │ │ RGB888 >>> * Non Linear └─┘ Linear └─┘Linear >>> └─┘Linear └┘ ST2084 >>> */ >> Hi Shashank, >> >> I think you might have degamma and color model conversion reversed, or >> is that a new thing in the HDR specs? >> >> Usually the YCbCr/RGB conversion matrix applies to non-linear values >> AFAIU. > Ah, that was due to the Gamut mapping block. You are right, color format > conversion can happen on non-linear data (doesn't mean it can't happen on > linear), but in the sequential block above, there was gamut mapping (color > space conversion), which needs to be done on Linear space, and I was a bit > too lazy to create separate blocks, so I just re[placed the block titles :D. >> There is also confusion with OETF vs. EOTF. I got that initially wrong >> too. OETF is not just a name for inverse-EOTF but it is used in a >> different context. Though here it seems to be just a typo. >> OETF is inherent to a camera when it converts light into >> electrical signals. EOTF is inherent to a monitor when it converts >> electrical signals to light. Depending on what the electrical signals >> have been defined to be in each step of a broadcasting chain, you might >> need OETF or EOTF or their inverse or a different OETF or EOTF or their >> inverse. > > Yes, that was a typo. The intention was to call it inverse curve for HDR > encoded buffers. It's almost 4 years (and 2 companies) since I last did HDR, > so I am a bit rusty on the topic ;) . > > - Shashank > Thanks, Ville and Shashank. This is indeed helpful. I apologize for the late response but I needed to take some time to do more reading and internalize some of the HDR and CM concepts. I will send out a v2 of my patchset but realize that it is only a small step toward the right KMS interface for HDR and CM. Harry >> >> As we are talking about displays and likely assuming display-referred >> content (not scene-referred content), we probably have no use for OETF, >> but we could have several different EOTFs. >> >> >> Thanks, >> pq
[git pull] drm fixes for 5.13-rc2 (part two)
Hey, Looks like I wasn't the only one not fully switched on this week, the msm pull has a missing tag so I missed it, and i915 team were a bit late. In my defence I did have a day with the roof of my home office removed, so was sitting at my kids desk. Dave. drm-fixes-2021-05-15: drm fixes for 5.13-rc2 (part two) msm: - dsi regression fix - dma-buf pinning fix - displayport fixes - llc fix i915: - Fix active callback alignment annotations and subsequent crashes - Retract link training strategy to slow and wide, again - Avoid division by zero on gen2 - Use correct width reads for C0DRB3/C1DRB3 registers - Fix double free in pdp allocation failure path - Fix HDMI 2.1 PCON downstream caps check The following changes since commit 08f0cfbf739a5086995f0779bbcb607163128a9a: Merge tag 'amd-drm-fixes-5.13-2021-05-13' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-05-14 09:20:04 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-15 for you to fetch changes up to 5dce58de4be8a4c9f2af3beed3ee9813933a0583: Merge tag 'drm-msm-fixes-2021-05-09' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2021-05-15 06:52:15 +1000) drm fixes for 5.13-rc2 (part two) msm: - dsi regression fix - dma-buf pinning fix - displayport fixes - llc fix i915: - Fix active callback alignment annotations and subsequent crashes - Retract link training strategy to slow and wide, again - Avoid division by zero on gen2 - Use correct width reads for C0DRB3/C1DRB3 registers - Fix double free in pdp allocation failure path - Fix HDMI 2.1 PCON downstream caps check Ankit Nautiyal (1): drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON Dave Airlie (2): Merge tag 'drm-intel-fixes-2021-05-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-msm-fixes-2021-05-09' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Dmitry Baryshkov (2): drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code Jonathan Marek (2): drm/msm: fix LLC not being enabled for mmu500 targets drm/msm: fix minor version to indicate MSM_PARAM_SUSPENDS support Kai-Heng Feng (1): drm/i915/dp: Use slow and wide link training for everything Kuogee Hsieh (2): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts Lv Yunlong (1): drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp Rob Clark (1): drm/msm: Do not unpin/evict exported dma-buf's Stéphane Marchesin (1): drm/i915: Fix crash in auto_retire Tvrtko Ursulin (1): drm/i915/overlay: Fix active retire callback alignment Ville Syrjälä (2): drm/i915: Avoid div-by-zero on gen2 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again drivers/gpu/drm/i915/display/intel_dp.c | 61 +++-- drivers/gpu/drm/i915/display/intel_overlay.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 1 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c| 4 +- drivers/gpu/drm/i915/i915_active.c | 3 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 ++-- drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 26 +++ drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 ++ drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 16 ++- drivers/gpu/drm/msm/msm_gem.h | 4 +- 15 files changed, 59 insertions(+), 79 deletions(-)
Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings
On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
> On 2021-04-26 20:56, Harry Wentland wrote:
>> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
>>> On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_color_mgmt.c | 4
include/drm/drm_color_mgmt.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c
b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..a183ebae2941 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -469,6 +469,10 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+ [DRM_COLOR_RGB_BT601] = "ITU-R BT.601 RGB",
+ [DRM_COLOR_RGB_BT709] = "ITU-R BT.709 RGB",
+ [DRM_COLOR_RGB_BT2020] = "ITU-R BT.2020 RGB",
+ [DRM_COLOR_P3] = "DCI-P3",
>>>
>>> These are a totally different thing than the YCbCr stuff.
>>> The YCbCr stuff just specifies the YCbCr<->RGB converison matrix,
>>> whereas these are I guess supposed to specify the primaries/whitepoint?
>>> But without specifying what we're converting *to* these mean absolutely
>>> nothing. Ie. I don't think they belong in this property.
>>>
>>
>> If this is the intention I don't see it documented.
>>
>> I might have overlooked something but do we have a way to explicitly
>> specify today what *to* format the YCbCr color encodings convert into?
>> Would that be a combination of the output color encoding specified via
>> colorspace_property and the color space encoded in the primaries and
>> whitepoint of the hdr_output_metadata?
>>
>> Fundamentally I don't see how the use of this property differs,
>> whether you translate from YCbCr or from RGB. In either case you're
>> converting from the defined input color space and pixel format to an
>> output color space and pixel format.
>>
>>> The previous proposals around this topic have suggested a new
>>> property to specify a conversion matrix either explicitly, or
>>> via a separate enum (which would specify both the src and dst
>>> colorspaces). I've always argued the enum approach is needed
>>> anyway since not all hardware has a programmable matrix for
>>> this. But a fully programmable matrix could be nice for tone
>>> mapping purposes/etc, so we may want to make sure both are
>>> possible.
>>>
>>> As for the transfer func, the proposals so far have mostly just
>>> been to expose a programmable degamma/gamma LUTs for each plane.
>>> But considering how poor the current gamma uapi is we've thrown
>>> around some ideas how to allow the kernel to properly expose the
>>> hw capabilities. This is one of those ideas:
>>> https://lists.freedesktop.org/archives/dri-devel/2019-April/212886.html I
>>> think that basic idea could be also be extended to allow fixed
>>> curves in case the hw doesn't have a fully programmable LUT. But
>>> dunno if that's relevant for your hw.
>>>
>>
>> The problem with exposing gamma, whether per-plane or per-crtc, is
>> that it is hard to define an API that works for all the HW out there.
>> The capabilities for different HW differ a lot, not just between
>> vendors but also between generations of a vendor's HW.
>
> Introducing another API if hardware is sufficiently different doesn't
> seem like the worst idea. At least it sounds a lot more tractable than
> teaching the kernel about all the different use cases, opinions and
> nuances that arise from color management.
>
> In the end generic user space must always be able to fall back to
> software so the worst case is that it won't be able to offload an
> operation if it doesn't know about a new API.
>
>> Another reason I'm proposing to define the color space (and gamma) of
>> a plane is to make this explicit. Up until the color space and gamma
>> of a plane or framebuffer are not well defined, which leads to drivers
>> assuming the color space and gamma of a buffer (for blending and other
>> purposes) and might lead to sub-optimal outcomes.
>
> Blending only is "correct" with linear light so that property of the
> color space is important. However, why does the kernel have to be
> involved here? As long as user space knows that for correct blending the
> data must represent linear light and knows when in the pipeline blending
> happens it can make sure that the data at that point in the pipeline
> contains linear light.
>
The only reason the kernel needs to be involved is to take full advantage
of the available HW without requiring KMS clients to be aware of
the difference in display HW.
Harry
> What other p
Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > On Mon, 26 Apr 2021 13:38:49 -0400 > Harry Wentland wrote: > >> ## Introduction >> >> We are looking to enable HDR support for a couple of single-plane and >> multi-plane scenarios. To do this effectively we recommend new >> interfaces to drm_plane. Below I'll give a bit of background on HDR >> and why we propose these interfaces. >> >> >> ## Defining a pixel's luminance >> >> Currently the luminance space of pixels in a framebuffer/plane >> presented to the display is not well defined. It's usually assumed to >> be in a 2.2 or 2.4 gamma space and has no mapping to an absolute >> luminance value but is interpreted in relative terms. >> >> Luminance can be measured and described in absolute terms as candela >> per meter squared, or cd/m2, or nits. Even though a pixel value can >> be mapped to luminance in a linear fashion to do so without losing a >> lot of detail requires 16-bpc color depth. The reason for this is >> that human perception can distinguish roughly between a 0.5-1% >> luminance delta. A linear representation is suboptimal, wasting >> precision in the highlights and losing precision in the shadows. >> >> A gamma curve is a decent approximation to a human's perception of >> luminance, but the PQ (perceptual quantizer) function [1] improves on >> it. It also defines the luminance values in absolute terms, with the >> highest value being 10,000 nits and the lowest 0.0005 nits. >> >> Using a content that's defined in PQ space we can approximate the >> real world in a much better way. >> >> Here are some examples of real-life objects and their approximate >> luminance values: >> >> | Object| Luminance in nits | >> | - | - | >> | Sun | 1.6 million | >> | Fluorescent light | 10,000| >> | Highlights| 1,000 - sunlight | >> | White Objects | 250 - 1,000 | >> | Typical objects | 1 - 250 | >> | Shadows | 0.01 - 1 | >> | Ultra Blacks | 0 - 0.0005| >> >> >> ## Describing the luminance space >> >> **We propose a new drm_plane property to describe the Eletro-Optical >> Transfer Function (EOTF) with which its framebuffer was composed.** >> Examples of EOTF are: >> >> | EOTF | Description >>| >> | - >> |:- | >> | Gamma 2.2 | a simple 2.2 gamma >>| >> | sRGB | 2.4 gamma with small initial linear section >>| >> | PQ 2084 | SMPTE ST 2084; used for HDR video and allows for up to 10,000 >> nit support | >> | Linear| Linear relationship between pixel value and luminance value >>| >> > > The definitions agree with what I have learnt so far. However, with > these EOTF definitions, only PQ defines absolute luminance values > while the others do not. So this is not enough information to blend > planes together if they do not all use the same EOTF with the same > dynamic range. More below. > Good point. > >> >> ## Mastering Luminances >> >> Now we are able to use the PQ 2084 EOTF to define the luminance of >> pixels in absolute terms. Unfortunately we're again presented with >> physical limitations of the display technologies on the market today. >> Here are a few examples of luminance ranges of displays. >> >> | Display | Luminance range in nits | >> | | --- | >> | Typical PC display | 0.3 - 200 | >> | Excellent LCD HDTV | 0.3 - 400 | >> | HDR LCD w/ local dimming | 0.05 - 1,500| >> >> Since no display can currently show the full 0.0005 to 10,000 nits >> luminance range the display will need to tonemap the HDR content, i.e >> to fit the content within a display's capabilities. To assist with >> tonemapping HDR content is usually accompanied with a metadata that >> describes (among other things) the minimum and maximum mastering >> luminance, i.e. the maximum and minimum luminance of the display that >> was used to master the HDR content. >> >> The HDR metadata is currently defined on the drm_connector via the >> hdr_output_metadata blob property. >> >> It might be useful to define per-plane hdr metadata, as different >> planes might have been mastered differently. > > I don't think this would directly help with the dynamic range blending > problem. You still need to establish the mapping between the optical > values from two different EOTFs and dynamic ranges. Or can you know > which optical values match the mastering display maximum and minimum > luminances for not-PQ? > My understanding of this is probably best illustrated by this example: Assume HDR was mastered on a display with a maximum white level of 500 nits and played back on a display that s
[RFC PATCH v2 0/6] A drm_plane API to support HDR planes
We are looking to enable HDR support for a couple of single-plane and multi-plane scenarios. To do this effectively we recommend new interfaces to drm_plane. The first patch gives a bit of background on HDR and why we propose these interfaces. v2: * Moved RFC from cover letter to kernel doc (Daniel Vetter) * Created new color space property instead of abusing color_encoding property (Ville) * Elaborated on need for named transfer functions * Expanded on reason for SDR luminance definition * Dropped 'color' from transfer function naming * Added output_transfer_function on crtc Bhawanpreet Lakha (3): drm/color: Add transfer functions for HDR/SDR on drm_plane drm/color: Add sdr boost property drm/color: Add color space plane property Harry Wentland (3): drm/doc: Color Management and HDR10 RFC drm/color: Add output transfer function to crtc drm/amd/display: reformat YCbCr-RGB conversion matrix Documentation/gpu/rfc/hdr-wide-gamut.rst | 416 ++ Documentation/gpu/rfc/index.rst | 4 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +- drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 7 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 6 +- drivers/gpu/drm/arm/malidp_crtc.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 6 +- drivers/gpu/drm/armada/armada_crtc.c | 5 +- drivers/gpu/drm/armada/armada_overlay.c | 6 +- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 7 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 + drivers/gpu/drm/drm_color_mgmt.c | 177 +++- drivers/gpu/drm/i915/display/intel_color.c| 11 +- drivers/gpu/drm/i915/display/intel_color.h| 2 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- .../drm/i915/display/skl_universal_plane.c| 6 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c| 6 +- drivers/gpu/drm/nouveau/dispnv50/head.c | 13 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +- drivers/gpu/drm/omapdrm/omap_plane.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 7 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +- drivers/gpu/drm/stm/ltdc.c| 8 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 10 +- drivers/gpu/drm/tidss/tidss_crtc.c| 9 +- drivers/gpu/drm/tidss/tidss_plane.c | 10 +- drivers/gpu/drm/vc4/vc4_crtc.c| 16 +- include/drm/drm_color_mgmt.h | 49 ++- include/drm/drm_crtc.h| 20 + include/drm/drm_plane.h | 47 +- 35 files changed, 905 insertions(+), 60 deletions(-) create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst -- 2.31.1
[RFC PATCH v2 1/6] drm/doc: Color Management and HDR10 RFC
Use the new DRM RFC doc section to capture the RFC previously only described in the cover letter at https://patchwork.freedesktop.org/series/89506/ Update the RFC based on feedback received: * don't use color_encoding property to define color space * expand on reason for SDR luminance definition * define input/output transfer functions for luminance space transforms, rather than defining the luminance space of an input directly Signed-off-by: Harry Wentland --- Documentation/gpu/rfc/hdr-wide-gamut.rst | 416 +++ Documentation/gpu/rfc/index.rst | 4 + 2 files changed, 420 insertions(+) create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst diff --git a/Documentation/gpu/rfc/hdr-wide-gamut.rst b/Documentation/gpu/rfc/hdr-wide-gamut.rst new file mode 100644 index ..132898668eac --- /dev/null +++ b/Documentation/gpu/rfc/hdr-wide-gamut.rst @@ -0,0 +1,416 @@ +== +HDR & Wide Color Gamut Support +== + +.. role:: wy-text-strike + +ToDo + + +* :wy-text-strike:`Reformat as RST kerneldoc` - done +* :wy-text-strike:`Don't use color_encoding for color_space definitions` - done +* :wy-text-strike:`Update SDR luminance description and reasoning` - done +* :wy-text-strike:`Clarify 3D LUT required for some color space transformations` - done +* :wy-text-strike:`Highlight need for named color space and EOTF definitions` - done +* :wy-text-strike:`Define transfer function API` - done +* :wy-text-strike:`Draft upstream plan` - done +* Reference to wayland and/or Chrome plans +* Sketch view of HW pipeline for couple of HW implementations + + +Upstream Plan += + +* Reach consensus on DRM/KMS API +* Implement support in amdgpu +* Implement IGT tests +* Add API support to Weston, ChromiumOS, or other canonical open-source project interested in HDR +* Merge user-space +* Merge kernel patches + + +Introduction + + +We are looking to enable HDR support for a couple of single-plane and +multi-plane scenarios. To do this effectively we recommend new interfaces +to drm_plane. Below I'll give a bit of background on HDR and why we +propose these interfaces. + + +Overview and background +=== + +Defining a pixel's luminance + + +The luminance space of pixels in a framebuffer/plane presented to the +display is not well defined in the DRM/KMS APIs. It is usually assumed to +be in a 2.2 or 2.4 gamma space and has no mapping to an absolute luminance +value; it is interpreted in relative terms. + +Luminance can be measured and described in absolute terms as candela +per meter squared, or cd/m2, or nits. Even though a pixel value can be +mapped to luminance in a linear fashion to do so without losing a lot of +detail requires 16-bpc color depth. The reason for this is that human +perception can distinguish roughly between a 0.5-1% luminance delta. A +linear representation is suboptimal, wasting precision in the highlights +and losing precision in the shadows. + +A gamma curve is a decent approximation to a human's perception of +luminance, but the PQ (perceptual quantizer) function [1] improves on +it. It also defines the luminance values in absolute terms, with the +highest value being 10,000 nits and the lowest 0.0005 nits. + +Using a content that's defined in PQ space we can approximate the real +world in a much better way. + +Here are some examples of real-life objects and their approximate +luminance values: + +.. flat-table:: + :header-rows: 1 + + * - Object + - Luminance in nits + + * - Fluorescent light + - 10,000 + + * - Highlights + - 1,000 - sunlight + + * - White Objects + - 250 - 1,000 + + * - Typical Objects + - 1 - 250 + + * - Shadows + - 0.01 - 1 + + * - Ultra Blacks + - 0 - 0.0005 + +Transfer functions +-- + +Traditionally we used the terms gamma and de-gamma to describe the +encoding of a pixel's luminance value and the operation to transfer from +a linear luminance space to the non-linear space used to encode the +pixels. Since some newer encodings don't use a gamma curve I suggest +we refer to non-linear encodings using the terms EOTF, and OETF[2], or +simply as transfer function in general. + +The EOTF (Electro-Optical Transfer Function) describes how to transfer +from an electrical signal to an optical signal. This was traditionally +done by the de-gamma function. + +The OETF (Opto Electronic Transfer Function) describes how to transfer +from an optical signal to an electronic signal. This was traditionally +done by the gamma function. + +More generally we can name the transfer function describing the transform +between scanout and blending space as the **input transfer function**, and +the transfer function describing the transform from blending space to the +output space as **output transfer function**. + + +Mastering Luminances +---
[RFC PATCH v2 4/6] drm/color: Add sdr boost property
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to this problem is to boost the SDR plane so that its
not too dim.
This patch introduces a "sdr_white_level" property, this property can be
used by the userspace to boost the SDR content luminance. The boost
value is an explicit luminance value in nits. This allows the userspace
to set the maximum white level for the SDR plane.
v2:
- fix type in description
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_color_mgmt.c | 17 +
include/drm/drm_color_mgmt.h | 6 ++
include/drm/drm_plane.h | 15 ++-
4 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 42f8fd577d36..863d6ee3bd3d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -597,6 +597,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->color_range = val;
} else if (property == plane->transfer_function_property) {
state->transfer_function = val;
+ } else if (property == plane->sdr_white_level_property) {
+ state->sdr_white_level = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -665,6 +667,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_range;
} else if (property == plane->transfer_function_property) {
*val = state->transfer_function;
+ } else if (property == plane->sdr_white_level_property) {
+ *val = state->sdr_white_level;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 196544951ab7..44842ba0454d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -556,6 +556,23 @@ const char *drm_get_color_range_name(enum drm_color_range
range)
return color_range_name[range];
}
+int drm_plane_create_sdr_white_level_property(struct drm_plane *plane){
+
+ struct drm_property *prop;
+
+ prop = drm_property_create_range(plane->dev, 0, "SDR_WHITE_LEVEL", 0,
UINT_MAX);
+
+ if (!prop)
+ return -ENOMEM;
+
+ plane->sdr_white_level_property = prop;
+ drm_object_attach_property(&plane->base, prop,
DRM_DEFAULT_SDR_WHITE_LEVEL);
+
+ if (plane->state)
+ plane->state->sdr_white_level = DRM_DEFAULT_SDR_WHITE_LEVEL;
+
+ return 0;
+}
/**
* drm_get_transfer_function - return a string for transfer function
* @tf: transfer function to compute name of
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 408561acdb3d..2a356a9601df 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -26,6 +26,12 @@
#include
#include
+/**
+ * Default SDR white level in nits. Although there is no standard SDR nit
level, 200
+ * is chosen as the default since that is the generally accepted value.
+ */
+#define DRM_DEFAULT_SDR_WHITE_LEVEL 200
+
struct drm_crtc;
struct drm_plane;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index cff56994513f..93ee308a46af 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -187,6 +187,11 @@ struct drm_plane_state {
* format for a proper HDR color/luminance output.
*/
enum drm_transfer_function transfer_function;
+ /**
+* @sdr_white_level:
+* SDR white level boost for HDR+SDR multi plane usecases. max white
level in nits
+*/
+ unsigned int sdr_white_level;
/**
* @fb_damage_clips:
*
@@ -757,7 +762,15 @@ struct drm_plane {
* See drm_plane_create_color_properties().
*/
struct drm_property *transfer_function_property;
-
+ /**
+* @sdr_white_level:
+*
+* Optional sdr_white_level. When HDR and SDR are combined in multi
plane
+* overlay cases, the sdr plane will be very dim. This property allows
+* the driver to boost the sdr plane's white level. The value should be
+* max white level in nits.
+*/
+ struct drm_property *sdr_white_level_property;
/**
* @scaling_filter_property: property to apply a particular filter while
* scaling.
--
2.31.1
[RFC PATCH v2 3/6] drm/color: Add output transfer function to crtc
We currently have 1D LUTs to define output transfer function but using a
1D LUT is not always the best way to define a transfer function for HW
that has ROMs for certain transfer functions, or for HW that has complex
PWL definition for accurate LUT definitions.
For this reason we're introducing named transfer functions. The original
LUT behavior is preserved with the default "1D LUT" transfer function.
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++-
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_crtc.c | 7 ++-
drivers/gpu/drm/armada/armada_crtc.c | 5 +-
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 7 ++-
drivers/gpu/drm/drm_color_mgmt.c | 54 ---
drivers/gpu/drm/i915/display/intel_color.c| 11 ++--
drivers/gpu/drm/i915/display/intel_color.h| 2 +-
drivers/gpu/drm/i915/display/intel_crtc.c | 4 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 +++-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +++-
drivers/gpu/drm/nouveau/dispnv50/head.c | 13 +++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +++-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 7 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +-
drivers/gpu/drm/stm/ltdc.c| 8 ++-
drivers/gpu/drm/tidss/tidss_crtc.c| 9 +++-
drivers/gpu/drm/vc4/vc4_crtc.c| 16 +-
include/drm/drm_color_mgmt.h | 37 +++--
include/drm/drm_crtc.h| 20 +++
21 files changed, 208 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 041576945a0d..59d277c31864 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7139,8 +7139,15 @@ static int amdgpu_dm_crtc_init(struct
amdgpu_display_manager *dm,
acrtc->otg_inst = -1;
dm->adev->mode_info.crtcs[crtc_index] = acrtc;
- drm_crtc_enable_color_mgmt(&acrtc->base, MAX_COLOR_LUT_ENTRIES,
- true, MAX_COLOR_LUT_ENTRIES);
+
+ res = drm_crtc_enable_color_mgmt(&acrtc->base, MAX_COLOR_LUT_ENTRIES,
+true, MAX_COLOR_LUT_ENTRIES,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (res) {
+ drm_crtc_cleanup(&acrtc->base);
+ goto fail;
+ }
+
drm_mode_crtc_set_gamma_size(&acrtc->base,
MAX_COLOR_LEGACY_LUT_ENTRIES);
return 0;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..f364d37232b5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -626,7 +626,12 @@ 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);
+ err = drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (err) {
+ drm_crtc_cleanup(crtc);
+ return err;
+ }
return err;
}
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..7af87002c375 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -552,7 +552,12 @@ int malidp_crtc_init(struct drm_device *drm)
drm_crtc_helper_add(&malidp->crtc, &malidp_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&malidp->crtc, MALIDP_GAMMA_LUT_SIZE);
/* No inverse-gamma: it is per-plane. */
- drm_crtc_enable_color_mgmt(&malidp->crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE);
+ ret = drm_crtc_enable_color_mgmt(&malidp->crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (ret) {
+ drm_crtc_cleanup(&malidp->crtc);
+ return ret;
+ }
malidp_se_set_enh_coeffs(malidp->dev);
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index b7bb90ae787f..d44a1d4fa475 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -992,7 +992,10 @@ static int armada_drm_crtc_create(struct drm_device *drm,
struct device *dev,
if (ret)
return ret;
- drm_crtc_enable_color_mgmt(&dcrtc->crtc, 0, false, 256);
+ ret = drm_crtc_enable_color_mgmt(&dcrtc->crtc, 0, false, ,
+BIT(DRM_TF_1D_LUT), DRM_TF_1D_LUT);
+ if (ret)
+ return ret;
return armada_overlay_
[RFC PATCH v2 6/6] drm/amd/display: reformat YCbCr-RGB conversion matrix
Show the CSC matrixes in a 4x3 format.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index ddbe4bb52724..e91dd899ba65 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -49,22 +49,30 @@ struct dpp_input_csc_matrix {
static const struct dpp_input_csc_matrix __maybe_unused dpp_input_csc_matrix[]
= {
{COLOR_SPACE_SRGB,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+ {0x2000, 0, 0, 0,
+ 0, 0x2000, 0, 0,
+ 0, 0, 0x2000, 0} },
{COLOR_SPACE_SRGB_LIMITED,
- {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+ {0x2000, 0, 0, 0,
+ 0, 0x2000, 0, 0,
+ 0, 0, 0x2000, 0} },
{COLOR_SPACE_YCBCR601,
- {0x2cdd, 0x2000, 0, 0xe991, 0xe926, 0x2000, 0xf4fd, 0x10ef,
- 0, 0x2000, 0x38b4, 0xe3a6} },
+ {0x2cdd, 0x2000, 0, 0xe991,
+0xe926, 0x2000, 0xf4fd, 0x10ef,
+ 0, 0x2000, 0x38b4, 0xe3a6} },
{COLOR_SPACE_YCBCR601_LIMITED,
- {0x3353, 0x2568, 0, 0xe400, 0xe5dc, 0x2568, 0xf367, 0x1108,
- 0, 0x2568, 0x40de, 0xdd3a} },
+ {0x3353, 0x2568, 0, 0xe400,
+0xe5dc, 0x2568, 0xf367, 0x1108,
+ 0, 0x2568, 0x40de, 0xdd3a} },
{COLOR_SPACE_YCBCR709,
- {0x3265, 0x2000, 0, 0xe6ce, 0xf105, 0x2000, 0xfa01, 0xa7d, 0,
- 0x2000, 0x3b61, 0xe24f} },
+ {0x3265, 0x2000, 0, 0xe6ce,
+0xf105, 0x2000, 0xfa01, 0xa7d,
+ 0, 0x2000, 0x3b61, 0xe24f} },
{COLOR_SPACE_YCBCR709_LIMITED,
- {0x39a6, 0x2568, 0, 0xe0d6, 0xeedd, 0x2568, 0xf925, 0x9a8, 0,
- 0x2568, 0x43ee, 0xdbb2} }
+ {0x39a6, 0x2568, 0, 0xe0d6,
+0xeedd, 0x2568, 0xf925, 0x9a8,
+ 0, 0x2568, 0x43ee, 0xdbb2} }
};
struct dpp_grph_csc_adjustment {
--
2.31.1
