Re: [PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
Hi Andrew Am Di., 4. Apr. 2023 um 17:02 Uhr schrieb Christian Gmeiner : > > > > Hi Andrew > > > > > >> > > >> > > >> Okay, will split for v2. > > >> > > >> > > > > > > Was there a follow-up v2 of this patchset? AFAICT this series did not > > > make it into the mainline kernel. > > > Do you have any plans to work on it? If not I would like to help out > > > as we have a use case where we want to > > > use a dma-buf sram exporter. > > > > > > > > > > Sure, I've been keeping it alive in our evil vendor tree, but if > > there is interest upstream now I'll post a v2 and CC you. > > That would be great! > Did you find time to prepare a v2? If not, can you point me to the evil vendor tree? -- thanks -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
Re: [PATCH 01/27] dt-bindings: pwm: Add compatible for MediaTek MT6795
Hello, On Wed, Apr 12, 2023 at 01:27:13PM +0200, AngeloGioacchino Del Regno wrote: > Add a compatible string for MediaTek Helio X10 MT6795's display PWM > block: this is the same as MT8173. > > Signed-off-by: AngeloGioacchino Del Regno > Acked-by: Uwe Kleine-König I assume this patch will go in together with the other patches in this series via an ARM tree? (I.e. not via pwm.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On Fri, 14 Apr 2023 at 06:24, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/14 04:01, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 13.04.23 um 20:56 schrieb Daniel Vetter:
> >> [...]
> >>> This should switch the existing code over to using drm_framebuffer instead
> >>> of fbdev:
> >>>
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index ef4eb8b12766..99ca69dd432f 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -647,22 +647,26 @@ static void drm_fb_helper_damage(struct
> >>> drm_fb_helper *helper, u32 x, u32 y,
> >>>static void drm_fb_helper_memory_range_to_clip(struct fb_info *info,
> >>> off_t off, size_t len,
> >>>struct drm_rect *clip)
> >>>{
> >>> + struct drm_fb_helper *helper = info->par;
> >>> +
> >>> off_t end = off + len;
> >>> u32 x1 = 0;
> >>> u32 y1 = off / info->fix.line_length;
> >>> - u32 x2 = info->var.xres;
> >>> - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
> >>> + u32 x2 = helper->fb->height;
> >>> + unsigned stride = helper->fb->pitches[0];
> >>> + u32 y2 = DIV_ROUND_UP(end, stride);
> >>> + int bpp = drm_format_info_bpp(helper->fb->format, 0);
> >> Please DONT do that. The code here is fbdev code and shouldn't bother about
> >> DRM data structures. Actually, it shouldn't be here: a number of fbdev
> >> drivers with deferred I/O contain similar code and the fbdev module should
> >> provide us with a helper. (I think I even had some patches somewhere.)
> > Well my thinking is that it's a drm driver,
>
> Yes, I actually agree with this, and the code looks quite good. And I
> really want to adopt it.
>
> Because here is DRM, we should emulate the fbdev in the DRM's way.
>
> The DRM is really the big brother on the behind of emulated fbdev,
>
> who provide the real displayable backing memory and scant out engine to
> display such a buffer.
>
>
> But currently, the fact is, drm_fb_helper.c still initializes lots of
> data structure come from fbdev world.
>
> For example, the drm_fb_helper_fill_fix() and drm_fb_helper_fill_var()
> in drm_fb_helper_fill_info() function.
>
> This saying implicitly that the fbdev-generic is a glue layer which copy
> damage frame buffer data
>
> from the front end(fbdev layer) to its drm backend. It's not a 100%
> replacement its fbdev front end,
>
> rather, it relay on it.
>
>
> > so if we have issue with limit
> > checks blowing up it makes more sense to check them against drm limits.
> > Plus a lot more people understand those than fbdev. They should all match
> > anyway, or if they dont, we have a bug.
>
> Yes, this is really what I'm worry about.
>
> I see that members of struct fb_var_screeninfo can be changed by
> user-space. For example, xoffset and yoffset.
>
> There is no change about 'info->var.xres' and 'info->var.yres' from the
> userspace,
>
> therefore, they should all match in practice.
>
>
> User-space can choose a use a smaller dispaly area than 'var.xres x
> var.yres',
>
> but that is implemented with 'var.xoffset' and 'var.xoffset'.
>
> But consider that the name 'var', which may stand for 'variation' or
> 'vary'. This is terrifying.
>
> I imagine, with a shadow buffer, the front end can do any modeset on the
> runtime freely,
>
> including change the format of frame buffer on the runtime. Just do not
> out-of-bound.
>
> The middle do the conversion on the fly.
>
>
> We might also create double shadow buffer size to allow the front end to
> pan?
Yeah so the front should be able to pan. And the front-end can
actually make xres/yres smalle than drm_fb->height/width, so we _have_
to use the fb side of things. Otherwise it's a bug I just realized.
The xres_virtual/yres_virtual should always match drm_fb sizes (but
we've had bugs in the past for that, only recently fixed all in
linux-next), because that's supposed to be the max size. And since we
never reallocate the fbdev emulation fb (at least with the current
code) this should never change.
But fundamentally you're bringing up a very good point, we've had
piles of bugs in the past with not properly validating the fbdev side
information in info->var, and a bunch of resulting bugs. So validating
against the drm side of things should be a bit more robust.
It's kinda the same we do for legacy kms ioctls: We translate that to
atomic kms as fast as possible, and then do the entire subsequent
validation with atomic kms data structures.
-Daniel
> > The thing is, if you change this
> > further to just pass the drm_framebuffer, then this 100% becomes a drm
> > function, which could be used by anything in drm really.
>
> I agree with you.
>
> If I use fb_width/fb_height directly and bypassing 'info->var.xres" and
> "info->var.yres",
>
> the code style diverged then. As far as I am understanding, the clip
> happen on
RE: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
[Public]
Hi Jeff,
Thanks. I might need more information to understand why we can't retrieve
the drm atomic state. Also , "Failed to create MST payload for port" indicates
error while configuring DPCD payload ID table. Could you help to provide log
with KMS + ATOMIC + DP debug on please? Thanks in advance!
Regards,
Wayne
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, April 13, 2023 8:59 PM
> To: Jani Nikula ; Lin, Wayne
>
> Cc: Jeff Layton ; David Airlie ;
> Daniel Vetter ; Deucher, Alexander
> ; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully
> handle NULL state pointer
>
> + Wayne
>
> On Thu, Apr 13, 2023 at 8:31 AM Jani Nikula
> wrote:
> >
> > On Thu, 13 Apr 2023, Jeff Layton wrote:
> > > I've been experiencing some intermittent crashes down in the display
> > > driver code. The symptoms are ususally a line like this in dmesg:
> > >
> > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > 6d3a3885: -5
> > >
> > > ...followed by an Oops due to a NULL pointer dereference.
> > >
> > > The real bug is probably in the caller of this function, which is
> > > passing it a NULL state pointer, but this patch at least keeps my
> > > machine from oopsing when this occurs.
> >
> > My fear is that papering over this makes the root cause harder to find.
> >
> > Cc: Harry, Alex
> >
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > Signed-off-by: Jeff Layton
> > > ---
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 38dab76ae69e..87ad406c50f9 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >
> > > /* Skip failed payloads */
> > > if (payload->vc_start_slot == -1) {
> > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> > > + drm_dbg_kms(state ? state->dev : NULL,
> > > + "Part 1 of payload creation for %s failed,
> > > + skipping part 2\n",
> > > payload->port->connector->name);
> > > return -EIO;
> > > }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
Hi,
On 2023/4/14 04:01, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.04.23 um 20:56 schrieb Daniel Vetter:
[...]
This should switch the existing code over to using drm_framebuffer instead
of fbdev:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ef4eb8b12766..99ca69dd432f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -647,22 +647,26 @@ static void drm_fb_helper_damage(struct drm_fb_helper
*helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t
off, size_t len,
struct drm_rect *clip)
{
+ struct drm_fb_helper *helper = info->par;
+
off_t end = off + len;
u32 x1 = 0;
u32 y1 = off / info->fix.line_length;
- u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 x2 = helper->fb->height;
+ unsigned stride = helper->fb->pitches[0];
+ u32 y2 = DIV_ROUND_UP(end, stride);
+ int bpp = drm_format_info_bpp(helper->fb->format, 0);
Please DONT do that. The code here is fbdev code and shouldn't bother about
DRM data structures. Actually, it shouldn't be here: a number of fbdev
drivers with deferred I/O contain similar code and the fbdev module should
provide us with a helper. (I think I even had some patches somewhere.)
Well my thinking is that it's a drm driver,
Yes, I actually agree with this, and the code looks quite good. And I
really want to adopt it.
Because here is DRM, we should emulate the fbdev in the DRM's way.
The DRM is really the big brother on the behind of emulated fbdev,
who provide the real displayable backing memory and scant out engine to
display such a buffer.
But currently, the fact is, drm_fb_helper.c still initializes lots of
data structure come from fbdev world.
For example, the drm_fb_helper_fill_fix() and drm_fb_helper_fill_var()
in drm_fb_helper_fill_info() function.
This saying implicitly that the fbdev-generic is a glue layer which copy
damage frame buffer data
from the front end(fbdev layer) to its drm backend. It's not a 100%
replacement its fbdev front end,
rather, it relay on it.
so if we have issue with limit
checks blowing up it makes more sense to check them against drm limits.
Plus a lot more people understand those than fbdev. They should all match
anyway, or if they dont, we have a bug.
Yes, this is really what I'm worry about.
I see that members of struct fb_var_screeninfo can be changed by
user-space. For example, xoffset and yoffset.
There is no change about 'info->var.xres' and 'info->var.yres' from the
userspace,
therefore, they should all match in practice.
User-space can choose a use a smaller dispaly area than 'var.xres x
var.yres',
but that is implemented with 'var.xoffset' and 'var.xoffset'.
But consider that the name 'var', which may stand for 'variation' or
'vary'. This is terrifying.
I imagine, with a shadow buffer, the front end can do any modeset on the
runtime freely,
including change the format of frame buffer on the runtime. Just do not
out-of-bound.
The middle do the conversion on the fly.
We might also create double shadow buffer size to allow the front end to
pan?
The thing is, if you change this
further to just pass the drm_framebuffer, then this 100% becomes a drm
function, which could be used by anything in drm really.
I agree with you.
If I use fb_width/fb_height directly and bypassing 'info->var.xres" and
"info->var.yres",
the code style diverged then. As far as I am understanding, the clip
happen on the front end,
the actual damage update happen at back end.
Using the data structure come with the front end is more reasonable for
current implement.
But also *shrug*.
I can convert this single function to 100% drm with another patch.
But, maybe there also have other functions are not 100% drm
I would like do something to help achieve this in the future,
let me help to fix this bug first?
-Daniel
[Bug 217278] ast 0000:03:00.0: PM: **** DPM device timeout **** during S4 resuming
https://bugzilla.kernel.org/show_bug.cgi?id=217278 --- Comment #9 from wendy.w...@intel.com --- Thanks Thorsten for your information, I sent email and got response. Jammy Huang gave me the patch and ast driver rpm package, we confirmed that it can unblock the kernel panic during S4 entry. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217278] ast 0000:03:00.0: PM: **** DPM device timeout **** during S4 resuming
https://bugzilla.kernel.org/show_bug.cgi?id=217278 --- Comment #8 from wendy.w...@intel.com --- Created attachment 304133 --> https://bugzilla.kernel.org/attachment.cgi?id=304133&action=edit 0001-drm-ast-Fix-long-timeout-which-could-lead-to-panic.patch_v6.3-rc5 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm/ast: Fix long time waiting on s3/s4 resume
Hi Jammy,
kernel test robot noticed the following build errors:
[auto build test ERROR on e62252bc55b6d4eddc6c2bdbf95a448180d6a08d]
url:
https://github.com/intel-lab-lkp/linux/commits/Jammy-Huang/drm-ast-Fix-long-time-waiting-on-s3-s4-resume/20230414-091312
base: e62252bc55b6d4eddc6c2bdbf95a448180d6a08d
patch link:
https://lore.kernel.org/r/20230414011147.3858-1-jammy_huang%40aspeedtech.com
patch subject: [PATCH] drm/ast: Fix long time waiting on s3/s4 resume
config: ia64-allyesconfig
(https://download.01.org/0day-ci/archive/20230414/202304141155.hsgy2cn0-...@intel.com/config)
compiler: ia64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/120de3fe25a450d9918de8bc73a4fe079bc71d9c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jammy-Huang/drm-ast-Fix-long-time-waiting-on-s3-s4-resume/20230414-091312
git checkout 120de3fe25a450d9918de8bc73a4fe079bc71d9c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=ia64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304141155.hsgy2cn0-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ast/ast_dp.c:122:6: error: conflicting types for
>> 'ast_dp_launch'; have 'void(struct drm_device *, u8)' {aka 'void(struct
>> drm_device *, unsigned char)'}
122 | void ast_dp_launch(struct drm_device *dev, u8 bPower)
| ^
In file included from drivers/gpu/drm/ast/ast_dp.c:8:
drivers/gpu/drm/ast/ast_drv.h:501:6: note: previous declaration of
'ast_dp_launch' with type 'void(struct drm_device *)'
501 | void ast_dp_launch(struct drm_device *dev);
| ^
vim +122 drivers/gpu/drm/ast/ast_dp.c
594e9c04b5864b KuoHsiang Chou2022-04-28 118
594e9c04b5864b KuoHsiang Chou2022-04-28 119 /*
594e9c04b5864b KuoHsiang Chou2022-04-28 120 * Launch Aspeed DP
594e9c04b5864b KuoHsiang Chou2022-04-28 121 */
594e9c04b5864b KuoHsiang Chou2022-04-28 @122 void ast_dp_launch(struct
drm_device *dev, u8 bPower)
594e9c04b5864b KuoHsiang Chou2022-04-28 123 {
120de3fe25a450 Jammy Huang 2023-04-14 124u32 i = 0;
594e9c04b5864b KuoHsiang Chou2022-04-28 125u8 bDPExecute = 1;
594e9c04b5864b KuoHsiang Chou2022-04-28 126struct ast_private *ast
= to_ast_private(dev);
594e9c04b5864b KuoHsiang Chou2022-04-28 127
594e9c04b5864b KuoHsiang Chou2022-04-28 128// Wait one second then
timeout.
594e9c04b5864b KuoHsiang Chou2022-04-28 129while
(ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1, COPROCESSOR_LAUNCH) !=
594e9c04b5864b KuoHsiang Chou2022-04-28 130
COPROCESSOR_LAUNCH) {
594e9c04b5864b KuoHsiang Chou2022-04-28 131i++;
594e9c04b5864b KuoHsiang Chou2022-04-28 132// wait 100 ms
594e9c04b5864b KuoHsiang Chou2022-04-28 133msleep(100);
594e9c04b5864b KuoHsiang Chou2022-04-28 134
594e9c04b5864b KuoHsiang Chou2022-04-28 135if (i >= 10) {
594e9c04b5864b KuoHsiang Chou2022-04-28 136// DP
would not be ready.
594e9c04b5864b KuoHsiang Chou2022-04-28 137
bDPExecute = 0;
594e9c04b5864b KuoHsiang Chou2022-04-28 138break;
594e9c04b5864b KuoHsiang Chou2022-04-28 139}
594e9c04b5864b KuoHsiang Chou2022-04-28 140}
594e9c04b5864b KuoHsiang Chou2022-04-28 141
120de3fe25a450 Jammy Huang 2023-04-14 142if (!bDPExecute)
120de3fe25a450 Jammy Huang 2023-04-14 143drm_err(dev,
"Wait DPMCU executing timeout\n");
594e9c04b5864b KuoHsiang Chou2022-04-28 144
594e9c04b5864b KuoHsiang Chou2022-04-28 145
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
594e9c04b5864b KuoHsiang Chou2022-04-28 146
(u8) ~ASTDP_HOST_EDID_READ_DONE_MASK,
594e9c04b5864b KuoHsiang Chou2022-04-28 147
ASTDP_HOST_EDID_READ_DONE);
7f35680ada234c Thomas Zimmermann 2022-06-07 148 }
594e9c04b5864b KuoHsiang Chou2022-04-28 149
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[PATCH] drm/ast: Fix long time waiting on s3/s4 resume
In resume, DP's launch function, ast_dp_launch, could wait at most 30
seconds before timeout to check if DP is enabled.
To avoid this problem, we only check if DP enable or not at driver probe.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217278
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_dp.c | 53 ++
drivers/gpu/drm/ast/ast_drv.h | 2 +-
drivers/gpu/drm/ast/ast_main.c | 11 +--
drivers/gpu/drm/ast/ast_post.c | 3 +-
4 files changed, 28 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
index 56483860306b..3a4218102631 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -121,51 +121,30 @@ int ast_astdp_read_edid(struct drm_device *dev, u8
*ediddata)
*/
void ast_dp_launch(struct drm_device *dev, u8 bPower)
{
- u32 i = 0, j = 0, WaitCount = 1;
- u8 bDPTX = 0;
+ u32 i = 0;
u8 bDPExecute = 1;
-
struct ast_private *ast = to_ast_private(dev);
- // S3 come back, need more time to wait BMC ready.
- if (bPower)
- WaitCount = 300;
-
-
- // Wait total count by different condition.
- for (j = 0; j < WaitCount; j++) {
- bDPTX = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
TX_TYPE_MASK);
-
- if (bDPTX)
- break;
+ // Wait one second then timeout.
+ while (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
COPROCESSOR_LAUNCH) !=
+ COPROCESSOR_LAUNCH) {
+ i++;
+ // wait 100 ms
msleep(100);
- }
- // 0xE : ASTDP with DPMCU FW handling
- if (bDPTX == ASTDP_DPMCU_TX) {
- // Wait one second then timeout.
- i = 0;
-
- while (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
COPROCESSOR_LAUNCH) !=
- COPROCESSOR_LAUNCH) {
- i++;
- // wait 100 ms
- msleep(100);
-
- if (i >= 10) {
- // DP would not be ready.
- bDPExecute = 0;
- break;
- }
+ if (i >= 10) {
+ // DP would not be ready.
+ bDPExecute = 0;
+ break;
}
+ }
- if (bDPExecute)
- ast->tx_chip_types |= BIT(AST_TX_ASTDP);
+ if (!bDPExecute)
+ drm_err(dev, "Wait DPMCU executing timeout\n");
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
- (u8)
~ASTDP_HOST_EDID_READ_DONE_MASK,
-
ASTDP_HOST_EDID_READ_DONE);
- }
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
+ (u8) ~ASTDP_HOST_EDID_READ_DONE_MASK,
+ ASTDP_HOST_EDID_READ_DONE);
}
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index d51b81fea9c8..15e86394be4f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -498,7 +498,7 @@ struct ast_i2c_chan *ast_i2c_create(struct drm_device *dev);
/* aspeed DP */
int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata);
-void ast_dp_launch(struct drm_device *dev, u8 bPower);
+void ast_dp_launch(struct drm_device *dev);
void ast_dp_power_on_off(struct drm_device *dev, bool no);
void ast_dp_set_on_off(struct drm_device *dev, bool no);
void ast_dp_set_mode(struct drm_crtc *crtc, struct ast_vbios_mode_info
*vbios_mode);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f83ce77127cb..8ecddf20113f 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -254,8 +254,13 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
case 0x0c:
ast->tx_chip_types = AST_TX_DP501_BIT;
}
- } else if (ast->chip == AST2600)
- ast_dp_launch(&ast->base, 0);
+ } else if (ast->chip == AST2600) {
+ if (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
TX_TYPE_MASK) ==
+ ASTDP_DPMCU_TX) {
+ ast->tx_chip_types = AST_TX_ASTDP_BIT;
+ ast_dp_launch(&ast->base);
+ }
+ }
/* Print stuff for diagnostic purposes */
if (ast->tx_chip_types & AST_TX_NONE_BIT)
@@ -264,6 +269,8 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
drm_info(dev, "Using Sil164 TMDS transmitter\n");
if (ast->tx_chip_types & AST_TX_DP501_BIT)
drm_info(dev, "Using DP501 DisplayPort transmitter\n");
+ if (ast->tx_chip_types & AST_TX_ASTDP_BIT)
+ drm
Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
Quoting Pin-yen Lin (2023-04-13 02:50:44) > Hi Stephen, > > On Wed, Apr 12, 2023 at 10:38 AM Stephen Boyd wrote: > > > > Quoting Pin-yen Lin (2023-03-31 02:11:39) > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > index b42553ac505c..604c7391d74f 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > +++ > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > @@ -12,7 +12,8 @@ maintainers: > > > > > > description: | > > >The ANX7625 is an ultra-low power 4K Mobile HD Transmitter > > > - designed for portable devices. > > > + designed for portable devices. Product brief is available at > > > + > > > https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf > > > > > > properties: > > >compatible: > > > @@ -112,9 +113,40 @@ properties: > > >data-lanes: true > > > > > >port@1: > > > -$ref: /schemas/graph.yaml#/properties/port > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > description: > > > - Video port for panel or connector. > > > + Video port for panel or connector. Each endpoint connects to a > > > video > > > + output downstream, and the "data-lanes" property is used to > > > describe > > > + the pin connections. 0, 1, 2, 3 in "data-lanes" maps to SSRX1, > > > SSTX1, > > > + SSRX2, SSTX2, respectively. > > > + > > > +patternProperties: > > > + "^endpoint@[01]$": > > > +$ref: /schemas/media/video-interfaces.yaml# > > > +properties: > > > + reg: true > > > + > > > + remote-endpoint: true > > > + > > > + data-lanes: > > > +oneOf: > > > + - items: > > > + - enum: [0, 1, 2, 3] > > > + > > > + - items: > > > + - const: 0 > > > + - const: 1 > > > + > > > + - items: > > > + - const: 2 > > > + - const: 3 > > > + > > > + mode-switch: > > > > Is it possible to not have this property? Can we have the driver for > > this anx device look at the remote-endpoint and if it sees that it is > > not a drm_bridge or panel on the other end, or a DP connector, that it > > should register a typec mode switch (or two depending on the number of > > endpoints in port@1)? Is there any case where that doesn't hold true? > > > > I see these possible scenarios: > > > > 1. DPI to DP bridge steering DP to one of two usb-c-connectors > > > > In this case, endpoint@0 is connected to one usb-c-connector and > > endpoint@1 is connected to another usb-c-connector. The input endpoint > > is only connected to DPI. The USB endpoint is not present (although I > > don't see this described in the binding either, so we would need a > > port@2, entirely optional to describe USB3 input). The driver will > > register two mode switches. > > > > 2. DPI to DP bridge with USB3 to one usb-c-connector > > > > In this case, endpoint@1 doesn't exist. The SSTX1/2 and SSRX1/2 pins are > > all connected to a usb-c-connector node. The input ports (0 and 2) are > > connected to both DPI and USB. The device acts as both a mode-switch and > > an orientation-switch. It registers both switches. I wonder if there is > > any benefit to describing SBU connections or CC connections? Maybe we > > don't register the orientation-switch if the SBU or CC connection isn't > > described? > > > > 3. DPI to DP bridge connected to eDP panel > > > > In this case, endpoint@1 doesn't exist. The USB endpoint is not present > > (port@2). Depending on how the crosspoint should be configured, we'll > > need to use data-lanes in the port@1 endpoint to describe which SSTRX > > pair to use (1 or 2). Or we'll have to use the endpoint's reg property > > to describe which pair to drive DP on. Presumably the default > > configuration is SSRX2/SSTX2 providing 2 lanes of DP to an eDP panel. > > The endpoint@0 in port@1 will be connected to a drm_panel, and the > > driver will be able to detect this properly by checking for the > > existence of an aux-bus node or the return value of > > of_dp_aux_populate_bus(). > > Can we assume that the eDP panel always stays behind an `aux-bus` > node? Can't the panel be connected to the bridge directly in the > graph? Though this might not matter if we only register mode switches > when there are usb-c-connectors connected. The panel is connected to the bridge in the graph. I think we should assume the eDP panel is on an aux-bus. Maybe another scenario is a design that has a DP to HDMI bridge wired down on the device? In which case the output port would be connected to the HDMI bridge. > > > > 4. DPI to DP bridge connected to DP connector > > > > This
Re: [PULL] drm-fixes for 6.3-rc7
The pull request you sent on Thu, 13 Apr 2023 21:51:38 +0200: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-04-13 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f1be7b6c165f0d451c3ea2062f506bf5f130bd5e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v3 00/65] clk: Make determine_rate mandatory for muxes
Quoting Maxime Ripard (2023-04-04 03:10:50)
> Hi,
>
> This is a follow-up to a previous series that was printing a warning
> when a mux has a set_parent implementation but is missing
> determine_rate().
>
> The rationale is that set_parent() is very likely to be useful when
> changing the rate, but it's determine_rate() that takes the parenting
> decision. If we're missing it, then the current parent is always going
> to be used, and thus set_parent() will not be used. The only exception
> being a direct call to clk_set_parent(), but those are fairly rare
> compared to clk_set_rate().
>
> Stephen then asked to promote the warning to an error, and to fix up all
> the muxes that are in that situation first. So here it is :)
>
Thanks for resending.
I was thinking that we apply this patch first and then set
determine_rate clk_ops without setting the clk flag. The function name
is up for debate.
---8<---
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 27c30a533759..057dd3ca8920 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -594,45 +594,57 @@ clk_core_forward_rate_req(struct clk_core *core,
req->max_rate = old_req->max_rate;
}
-int clk_mux_determine_rate_flags(struct clk_hw *hw,
-struct clk_rate_request *req,
-unsigned long flags)
+static int
+clk_core_determine_rate_noreparent(struct clk_core *core,
+ struct clk_rate_request *req)
{
- struct clk_core *core = hw->core, *parent, *best_parent = NULL;
- int i, num_parents, ret;
+ struct clk_core *parent;
+ int ret;
unsigned long best = 0;
- /* if NO_REPARENT flag set, pass through to current parent */
- if (core->flags & CLK_SET_RATE_NO_REPARENT) {
- parent = core->parent;
- if (core->flags & CLK_SET_RATE_PARENT) {
- struct clk_rate_request parent_req;
-
- if (!parent) {
- req->rate = 0;
- return 0;
- }
+ parent = core->parent;
+ if (core->flags & CLK_SET_RATE_PARENT) {
+ struct clk_rate_request parent_req;
- clk_core_forward_rate_req(core, req, parent,
&parent_req, req->rate);
+ if (!parent) {
+ req->rate = 0;
+ return 0;
+ }
- trace_clk_rate_request_start(&parent_req);
+ clk_core_forward_rate_req(core, req, parent, &parent_req,
req->rate);
- ret = clk_core_round_rate_nolock(parent, &parent_req);
- if (ret)
- return ret;
+ trace_clk_rate_request_start(&parent_req);
- trace_clk_rate_request_done(&parent_req);
+ ret = clk_core_round_rate_nolock(parent, &parent_req);
+ if (ret)
+ return ret;
- best = parent_req.rate;
- } else if (parent) {
- best = clk_core_get_rate_nolock(parent);
- } else {
- best = clk_core_get_rate_nolock(core);
- }
+ trace_clk_rate_request_done(&parent_req);
- goto out;
+ best = parent_req.rate;
+ } else if (parent) {
+ best = clk_core_get_rate_nolock(parent);
+ } else {
+ best = clk_core_get_rate_nolock(core);
}
+ req->rate = best;
+
+ return 0;
+}
+
+int clk_mux_determine_rate_flags(struct clk_hw *hw,
+struct clk_rate_request *req,
+unsigned long flags)
+{
+ struct clk_core *core = hw->core, *parent, *best_parent = NULL;
+ int i, num_parents, ret;
+ unsigned long best = 0;
+
+ /* if NO_REPARENT flag set, pass through to current parent */
+ if (core->flags & CLK_SET_RATE_NO_REPARENT)
+ return clk_core_determine_rate_noreparent(core, req);
+
/* find the parent that can provide the fastest rate <= rate */
num_parents = core->num_parents;
for (i = 0; i < num_parents; i++) {
@@ -670,9 +682,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
if (!best_parent)
return -EINVAL;
-out:
- if (best_parent)
- req->best_parent_hw = best_parent->hw;
+ req->best_parent_hw = best_parent->hw;
req->best_parent_rate = best;
req->rate = best;
@@ -772,6 +782,24 @@ int __clk_mux_determine_rate_closest(struct clk_hw *hw,
}
EXPORT_SYMBOL_GPL(__clk_mux_determine_rate_closest);
+/**
+ * clk_hw_determine_rate_noreparent - clk_ops::determine_rate implementation
for a clk that doesn't reparent
+ * @hw: clk to determine rate on
+ * @req: rate request
+ *
+ * Helper for finding best parent rate to
Re: [PATCH 2/2] drm/nouveau: constify pointers to hwmon_channel_info
Reviewed-by: Lyude Paul
On Fri, 2023-04-07 at 17:00 +0200, Krzysztof Kozlowski wrote:
> Statically allocated array of pointed to hwmon_channel_info can be made
> const for safety.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> This depends on hwmon core patch:
> https://lore.kernel.org/all/20230406203103.3011503-2-krzysztof.kozlow...@linaro.org/
>
> Therefore I propose this should also go via hwmon tree.
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: linux-hw...@vger.kernel.org
> ---
> drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index e844be49e11e..db30a4c2cd4d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -211,7 +211,7 @@ static const struct attribute_group
> temp1_auto_point_sensor_group = {
>
> #define N_ATTR_GROUPS 3
>
> -static const struct hwmon_channel_info *nouveau_info[] = {
> +static const struct hwmon_channel_info * const nouveau_info[] = {
> HWMON_CHANNEL_INFO(chip,
> HWMON_C_UPDATE_INTERVAL),
> HWMON_CHANNEL_INFO(temp,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
RE: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation
> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO > creation > > On 2023-04-05 13:26:43, Jordan Justen wrote: >> On 2023-04-05 00:45:24, Lionel Landwerlin wrote: >>> On 04/04/2023 19:04, Yang, Fei wrote: > Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set > cache at BO creation > > Just like the protected content uAPI, there is no way for > userspace to tell this feature is available other than trying using it. > > Given the issues with protected content, is it not thing we could want to > add? Sorry I'm not aware of the issues with protected content, could you elaborate? There was a long discussion on teams uAPI channel, could you comment there if any concerns? >>> >>> We wanted to have a getparam to detect protected support and were >>> told to detect it by trying to create a context with it. >>> >> >> An extensions system where the detection mechanism is "just try it", >> and assume it's not supported if it fails. ?? >> > > I guess no one wants to discuss the issues with this so-called detection > mechanism for i915 extensions. (Just try it and if it fails, it must not be supported.) > > I wonder how many ioctls we will be making a couple years down the road > just to see what the kernel supports. > > Maybe we'll get more fun 8 second timeouts to deal with. Maybe these probing > ioctls failing or succeeding will alter the kmd's state in some unexpected > way. For this SET_PAT extension, I can assure you there is no 8 second wait :) This is definitely a non-blocking call. > It'll also be fun to debug cases where the driver is not starting up with the > noise of a bunch of probing ioctls flying by. > > I thought about suggesting at least something like > I915_PARAM_CMD_PARSER_VERSION, > but I don't know if that could have prevented this 8 second timeout for > creating > a protected content context. Maybe it's better than nothing though. > > Of course, there was also the vague idea I threw out below for getting a list > of > supported extentions. The detection mechanism itself is an uAPI change, I don't think it's a good idea to combine that with this SET_PAT extension patch. I suggest we start a discussion in the "i915 uAPI changes" teams channel just like how we sorted out a solution for this setting cache policy issue. Would that work? https://teams.microsoft.com/l/channel/19%3af1767bda6734476ba0a9c7d147b928d1%40thread.skype/i915%2520uAPI%2520changes?groupId=379f3ae1-d138-4205-bb65-d4c7d38cb481&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d -Fei > -Jordan > >> >> This seem likely to get more and more problematic as a detection >> mechanism as more extensions are added. >> >> > >> > Now it appears trying to create a protected context can block for >> > several seconds. >> > >> > Since we have to report capabilities to the user even before it >> > creates protected contexts, any app is at risk of blocking. >> > >> >> This failure path is not causing any re-thinking about using this as >> the extension detection mechanism? >> >> Doesn't the ioctl# + input-struct-size + u64-extension# identify the >> extension such that the kernel could indicate if it is supported or >> not. (Or, perhaps return an array of the supported extensions so the >> umd doesn't have to potentially make many ioctls for each extension of >> interest.) >> >> -Jordan
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 TheRinger (tyrell.rutle...@icloud.com) changed: What|Removed |Added CC||tyrell.rutle...@icloud.com --- Comment #78 from TheRinger (tyrell.rutle...@icloud.com) --- After this happened to me on Debian I started digging to find the source as it came with a payload which ultimately flashed my bios after flashing my wireless card’s firmware. I found two files that were modified from the original installation which may have been injected as the source hash is different. Researching further I’ve found some interesting comments about how this is done by manipulating Systemd after resuming from hibernation, and pulling memory back from the swap that was modified. The rabbit hole goes further as it then returns from sleeping after modifying the library’s that control fonts and their storage. You browse Google and your search’s contain websites with web fonts. In These fonts there is strange emojis and and symbols which at first seem like poorly designed icons and graphic s but actually contain raw code that is downloaded to your cache. At some point there is another part that goes in and assembles these code blocks to copy your .home/user/.ssh files because of weak user land file and directory attributes. Anyway this goes into on as you can imagine how this only continues to work. When this happens or after you restart because the computer doesn’t return from sleep. You end up with modifications to your bios, graphics, hard drive, firmware and anything else that it can possibly find to stay present. Your gparted code will contain code blocks that that swap out code from the end of your hard drive to the start. You will need to start from scratch by clearing cmos then uploading new firmware and zeroing out hard drives. It’s a huge headache. It may only get so far and so you may never end up downloading the cached fonts or some other step it needs and will think it’s just a glitch. Check your known hosts folder in your ssh directory also compare hashes to original source code . I switched to Slackware despite enjoying the simplicity of package management years ago as its appeal to me was it didn’t contain Systemd, recently I decided to try a mainline distro again only to discover this gem. The library files among others but notable only because the were in the original initramfs were libfribidi.o and libgraphite2.so -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
>
> On 13/04/2023 14:27, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 12/04/2023 20:18, Daniel Vetter wrote:
> > > > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> > > > > On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > > > > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > > > > > > From: Rob Clark
> > > > > > > > >
> > > > > > > > > Add support to dump GEM stats to fdinfo.
> > > > > > > > >
> > > > > > > > > v2: Fix typos, change size units to match docs, use div_u64
> > > > > > > > > v3: Do it in core
> > > > > > > > >
> > > > > > > > > Signed-off-by: Rob Clark
> > > > > > > > > Reviewed-by: Emil Velikov
> > > > > > > > > ---
> > > > > > > > > Documentation/gpu/drm-usage-stats.rst | 21
> > > > > > > > > drivers/gpu/drm/drm_file.c| 76
> > > > > > > > > +++
> > > > > > > > > include/drm/drm_file.h| 1 +
> > > > > > > > > include/drm/drm_gem.h | 19 +++
> > > > > > > > > 4 files changed, 117 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > index b46327356e80..b5e7802532ed 100644
> > > > > > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > @@ -105,6 +105,27 @@ object belong to this client, in the
> > > > > > > > > respective memory region.
> > > > > > > > > Default unit shall be bytes with optional unit specifiers
> > > > > > > > > of 'KiB' or 'MiB'
> > > > > > > > > indicating kibi- or mebi-bytes.
> > > > > > > > >
> > > > > > > > > +- drm-shared-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are shared with another file
> > > > > > > > > (ie. have more
> > > > > > > > > +than a single handle).
> > > > > > > > > +
> > > > > > > > > +- drm-private-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are not shared with another
> > > > > > > > > file.
> > > > > > > > > +
> > > > > > > > > +- drm-resident-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are resident in system memory.
> > > > > > > >
> > > > > > > > I think this naming maybe does not work best with the existing
> > > > > > > > drm-memory- keys.
> > > > > > >
> > > > > > > Actually, it was very deliberate not to conflict with the existing
> > > > > > > drm-memory- keys ;-)
> > > > > > >
> > > > > > > I wouldn't have preferred drm-memory-{active,resident,...} but it
> > > > > > > could be mis-parsed by existing userspace so my hands were a bit
> > > > > > > tied.
> > > > > > >
> > > > > > > > How about introduce the concept of a memory region from the
> > > > > > > > start and
> > > > > > > > use naming similar like we do for engines?
> > > > > > > >
> > > > > > > > drm-memory-$CATEGORY-$REGION: ...
> > > > > > > >
> > > > > > > > Then we document a bunch of categories and their semantics, for
> > > > > > > > instance:
> > > > > > > >
> > > > > > > > 'size' - All reachable objects
> > > > > > > > 'shared' - Subset of 'size' with handle_count > 1
> > > > > > > > 'resident' - Objects with backing store
> > > > > > > > 'active' - Objects in use, subset of resident
> > > > > > > > 'purgeable' - Or inactive? Subset of resident.
> > > > > > > >
> > > > > > > > We keep the same semantics as with process memory accounting
> > > > > > > > (if I got
> > > > > > > > it right) which could be desirable for a simplified mental
> > > > > > > > model.
> > > > > > > >
> > > > > > > > (AMD needs to remind me of their 'drm-memory-...' keys
> > > > > > > > semantics. If we
> > > > > > > > correctly captured this in the first round it should be
> > > > > > > > equivalent to
> > > > > > > > 'resident' above. In any case we can document no category is
> > > > > > > > equal to
> > > > > > > > which category, and at most one of the two must be output.)
> > > > > > > >
> > > > > > > > Region names we at most partially standardize. Like we could say
> > > > > > > > 'system' is to be used where backing store is system RAM and
> > > > > > > > others are
> > > > > > > > driver defined.
> > > > > > > >
> > > > > > > > Then discrete GPUs could emit N sets of key-values, one for
> > > > > > > > each memory
> > > > > > > > region they support.
> > > > > > > >
> > > > > > > > I think this all also works for objects which can be migrated
> > > > > > > > between
> > > > > > > > memory regions. 'Size' accounts them against all regions while
> > > > > > > > for
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.04.23 um 20:56 schrieb Daniel Vetter:
> [...]
> >
> > This should switch the existing code over to using drm_framebuffer instead
> > of fbdev:
> >
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index ef4eb8b12766..99ca69dd432f 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -647,22 +647,26 @@ static void drm_fb_helper_damage(struct drm_fb_helper
> > *helper, u32 x, u32 y,
> > static void drm_fb_helper_memory_range_to_clip(struct fb_info *info,
> > off_t off, size_t len,
> >struct drm_rect *clip)
> > {
> > + struct drm_fb_helper *helper = info->par;
> > +
> > off_t end = off + len;
> > u32 x1 = 0;
> > u32 y1 = off / info->fix.line_length;
> > - u32 x2 = info->var.xres;
> > - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
> > + u32 x2 = helper->fb->height;
> > + unsigned stride = helper->fb->pitches[0];
> > + u32 y2 = DIV_ROUND_UP(end, stride);
> > + int bpp = drm_format_info_bpp(helper->fb->format, 0);
>
> Please DONT do that. The code here is fbdev code and shouldn't bother about
> DRM data structures. Actually, it shouldn't be here: a number of fbdev
> drivers with deferred I/O contain similar code and the fbdev module should
> provide us with a helper. (I think I even had some patches somewhere.)
Well my thinking is that it's a drm driver, so if we have issue with limit
checks blowing up it makes more sense to check them against drm limits.
Plus a lot more people understand those than fbdev. They should all match
anyway, or if they dont, we have a bug. The thing is, if you change this
further to just pass the drm_framebuffer, then this 100% becomes a drm
function, which could be used by anything in drm really.
But also *shrug*.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PULL] drm-fixes for 6.3-rc7
Hi Linus, People seem back, still not much. -Daniel drm-fixes-2023-04-13: drm-fixes for -rc7 - two fbcon regressions - amdgpu: dp mst, smu13 - i915: dual link dsi for tgl+ - armada, nouveau, drm/sched, fbmem The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-04-13 for you to fetch changes up to cab2932213c5cd72a9e04e5e82002e81b946592b: Merge tag 'drm-misc-fixes-2023-04-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-04-13 20:47:58 +0200) drm-fixes for -rc7 - two fbcon regressions - amdgpu: dp mst, smu13 - i915: dual link dsi for tgl+ - armada, nouveau, drm/sched, fbmem Asahi Lina (1): drm/scheduler: Fix UAF race in drm_sched_entity_push_job() Christophe JAILLET (1): drm/armada: Fix a potential double free in an error handling path Daniel Vetter (6): fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace Merge tag 'amd-drm-fixes-6.3-2023-04-12' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2023-04-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes fbcon: Fix error paths in set_con2fb_map fbcon: set_con2fb_map needs to set con2fb_map! Merge tag 'drm-misc-fixes-2023-04-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Evan Quan (1): drm/amd/pm: correct the pcie link state check for SMU13 Horatio Zhang (2): drm/amd/pm: correct SMU13.0.7 pstate profiling clock settings drm/amd/pm: correct SMU13.0.7 max shader clock reporting Jani Nikula (1): drm/i915/dsi: fix DSS CTL register offsets for TGL+ Karol Herbst (1): drm/nouveau/fb: add missing sysmen flush callbacks Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes Wayne Lin (1): drm/amd/display: Pass the right info to drm_dp_remove_payload .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 57 -- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 6 ++ .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 4 +- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 87 +++--- drivers/gpu/drm/armada/armada_drv.c| 1 - drivers/gpu/drm/i915/display/icl_dsi.c | 20 - drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c | 1 + drivers/gpu/drm/scheduler/sched_entity.c | 11 ++- drivers/video/fbdev/core/fbcon.c | 18 ++--- drivers/video/fbdev/core/fbmem.c | 2 + 13 files changed, 175 insertions(+), 35 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] video: au1100fb: Move a variable assignment behind a null pointer check in au1100fb_setmode()
Date: Thu, 13 Apr 2023 21:35:36 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “au1100fb_setmode”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “info” behind the null pointer check.
This issue was detected by using the Coccinelle software.
Fixes: 3b495f2bb749b828499135743b9ddec46e34fda8 ("Au1100 FB driver uplift for
2.6.")
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/au1100fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index cb317398e71a..fcb47b350bc9 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -137,13 +137,15 @@ static int au1100fb_fb_blank(int blank_mode, struct
fb_info *fbi)
*/
int au1100fb_setmode(struct au1100fb_device *fbdev)
{
- struct fb_info *info = &fbdev->info;
+ struct fb_info *info;
u32 words;
int index;
if (!fbdev)
return -EINVAL;
+ info = &fbdev->info;
+
/* Update var-dependent FB info */
if (panel_is_active(fbdev->panel) || panel_is_color(fbdev->panel)) {
if (info->var.bits_per_pixel <= 8) {
--
2.40.0
[PATCH] video: fbdev: mmp: Fix deferred clk handling in mmphw_probe()
When dev_err_probe() is called, 'ret' holds the value of the previous
successful devm_request_irq() call.
'ret' should be assigned with a meaningful value before being used in
dev_err_probe().
While at it, use and return "PTR_ERR(ctrl->clk)" instead of a hard-coded
"-ENOENT" so that -EPROBE_DEFER is handled and propagated correctly.
Fixes: 81b63420564d ("video: fbdev: mmp: Make use of the helper function
dev_err_probe()")
Signed-off-by: Christophe JAILLET
---
drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
index a9df8ee79810..51fbf02a0343 100644
--- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
@@ -514,9 +514,9 @@ static int mmphw_probe(struct platform_device *pdev)
/* get clock */
ctrl->clk = devm_clk_get(ctrl->dev, mi->clk_name);
if (IS_ERR(ctrl->clk)) {
+ ret = PTR_ERR(ctrl->clk);
dev_err_probe(ctrl->dev, ret,
"unable to get clk %s\n", mi->clk_name);
- ret = -ENOENT;
goto failed;
}
clk_prepare_enable(ctrl->clk);
--
2.34.1
Re: [RFC PATCH 0/2] drm/mgag200: Use 24bit format in VRAM
Hi Am 12.04.23 um 15:39 schrieb Jocelyn Falempe: The bandwidth between system memory and VRAM is very limited on G200. So when using a 32bit framebuffer on system memory, convert it to 24bit when copying the frame to the VRAM, this allows to go 33% faster. Converting the format on the fly is negligible, even on low end CPU. I'm skeptical about this idea. We emulated a number of formats in simpledrm and got a lot of flames and pushback. The argument was that we should export the formats that hardware supports and not pretend to support anything else. The only exception allowed was emulating XRGB, because it's the common ground hat everything in userspace supports. I see that this is a bit different from your patches, but not so much. When userspace wants 32-bit XRGB, it should get it if possible. I'd rather suggest to set the console to 16 bit and also resort the formats array. It is supposed to be sorted by preference. RGB565 should maybe be the top most entry, followed by RGB888. Then you'd have to teach userspace to respect these settings. I'm not sure if all compositors do. Best regards Thomas [PATCH 1/2] drm/mgag200: simplify offset and scale computation. [PATCH 2/2] drm/mgag200: Use 24bit format in VRAM drivers/gpu/drm/mgag200/mgag200_mode.c | 87 --- 1 file changed, 36 insertions(+), 51 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PULL] drm-misc-fixes
On Thu, Apr 13, 2023 at 08:42:33PM +0200, Thomas Zimmermann wrote: > Hi Dave and Daniel, > > this is the PR for drm-misc-fixes for this week. > > Best regards > Thomas > > drm-misc-fixes-2023-04-13: > Short summary of fixes pull: > > * armada: Fix double free > * fb: Clear FB_ACTIVATE_KD_TEXT in ioctl > * nouveau: Add missing callbacks > * scheduler: Fix use-after-free error > The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: > > Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-04-13 Pulled, thanks > > for you to fetch changes up to 5603effb8295ada8419408d038a34ca89d658229: > > Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes > (2023-04-12 12:01:32 +0200) > > > Short summary of fixes pull: > > * armada: Fix double free > * fb: Clear FB_ACTIVATE_KD_TEXT in ioctl > * nouveau: Add missing callbacks > * scheduler: Fix use-after-free error > > > Asahi Lina (1): > drm/scheduler: Fix UAF race in drm_sched_entity_push_job() > > Christophe JAILLET (1): > drm/armada: Fix a potential double free in an error handling path > > Daniel Vetter (1): > fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace > > Karol Herbst (1): > drm/nouveau/fb: add missing sysmen flush callbacks > > Maarten Lankhorst (1): > Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes > > drivers/gpu/drm/armada/armada_drv.c| 1 - > drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 1 + > drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c | 1 + > drivers/gpu/drm/scheduler/sched_entity.c | 11 +-- > drivers/video/fbdev/core/fbmem.c | 2 ++ > 7 files changed, 15 insertions(+), 3 deletions(-) > > -- > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
Hi
Am 13.04.23 um 20:56 schrieb Daniel Vetter:
[...]
This should switch the existing code over to using drm_framebuffer instead
of fbdev:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ef4eb8b12766..99ca69dd432f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -647,22 +647,26 @@ static void drm_fb_helper_damage(struct drm_fb_helper
*helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t
off, size_t len,
struct drm_rect *clip)
{
+ struct drm_fb_helper *helper = info->par;
+
off_t end = off + len;
u32 x1 = 0;
u32 y1 = off / info->fix.line_length;
- u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 x2 = helper->fb->height;
+ unsigned stride = helper->fb->pitches[0];
+ u32 y2 = DIV_ROUND_UP(end, stride);
+ int bpp = drm_format_info_bpp(helper->fb->format, 0);
Please DONT do that. The code here is fbdev code and shouldn't bother
about DRM data structures. Actually, it shouldn't be here: a number of
fbdev drivers with deferred I/O contain similar code and the fbdev
module should provide us with a helper. (I think I even had some patches
somewhere.)
Best regards
Thomas
if ((y2 - y1) == 1) {
/*
* We've only written to a single scanline. Try to reduce
* the number of horizontal pixels that need an update.
*/
- off_t bit_off = (off % info->fix.line_length) * 8;
- off_t bit_end = (end % info->fix.line_length) * 8;
+ off_t bit_off = (off % stride) * 8;
+ off_t bit_end = (end % stride) * 8;
- x1 = bit_off / info->var.bits_per_pixel;
- x2 = DIV_ROUND_UP(bit_end, info->var.bits_per_pixel);
+ x1 = bit_off / bpp;
+ x2 = DIV_ROUND_UP(bit_end, bpp);
}
drm_rect_init(clip, x1, y1, x2 - x1, y2 - y1);
+ screen_size = sizes->surface_height * buffer->fb->pitches[0];
+
screen_buffer = vzalloc(screen_size);
if (!screen_buffer) {
ret = -ENOMEM;
Cheers, Daniel
--
2.25.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2] drm/fbdev-generic: prohibit potential out-of-bounds access
Hi,
thanks for the patch. This is effectively a revert of commit
8fbc9af55de0 ("drm/fbdev-generic: Set screen size to size of GEM
buffer"). Please add a Fixes tag.
Am 13.04.23 um 20:06 schrieb Sui Jingfeng:
From: Sui Jingfeng
The crazy fbdev test of IGT may write after EOF, which lead to out-of-bound
Please drop 'crazy'. :)
access for the drm drivers using fbdev-generic. For example, run fbdev test
on a x86-64+ast2400 platform with 1680x1050 resolution will cause the linux
kernel hang with following call trace:
Oops: [#1] PREEMPT SMP PTI
[IGT] fbdev: starting subtest eof
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+0xa/0x20
RSP: 0018:a17d40167d98 EFLAGS: 00010246
RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
RBP: a17d40167e20 R08: R09: 89522ecff8c0
R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
R13: 1a40 R14: 041a R15: a17d40167e30
FS: () GS:89525738() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
Call Trace:
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430
worker_thread+0x4e/0x3c0
? __pfx_worker_thread+0x10/0x10
kthread+0xf4/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
CR2: a17d40e0b000
---[ end trace ]---
The indirect reason is drm_fb_helper_memory_range_to_clip() generate damage
rectangles which partially or completely go out of the active display area.
The second of argument 'off' is passing from the user-space, this will lead
to the out-of-bound if it is large than (fb_height + 1) * fb_pitches; while
DIV_ROUND_UP() may also controbute to error by 1.
This patch will add code to restrict the damage rect computed go beyond of
the last line of the framebuffer.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 16
drivers/gpu/drm/drm_fbdev_generic.c | 2 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64458982be40..6bb1b8b27d7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -641,19 +641,27 @@ static void drm_fb_helper_damage(struct drm_fb_helper
*helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t
off, size_t len,
struct drm_rect *clip)
{
+ u32 line_length = info->fix.line_length;
+ u32 fb_height = info->var.yres;
off_t end = off + len;
u32 x1 = 0;
- u32 y1 = off / info->fix.line_length;
+ u32 y1 = off / line_length;
u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 y2 = DIV_ROUND_UP(end, line_length);
+
+ /* Don't allow any of them beyond the bottom bound of display area */
+ if (y1 > fb_height)
+ y1 = fb_height;
+ if (y2 > fb_height)
+ y2 = fb_height;
if ((y2 - y1) == 1) {
/*
* We've only written to a single scanline. Try to reduce
* the number of horizontal pixels that need an update.
*/
- off_t bit_off = (off % info->fix.line_length) * 8;
- off_t bit_end = (end % info->fix.line_length) * 8;
+ off_t bit_off = (off % line_length) * 8;
+ off_t bit_end = (end % line_length) * 8;
Please scratch all these changes. The current code should work as
intended. Only the generic fbdev emulation uses this code and it should
really be moved there at some point.
x1 = bit_off / info->var.bits_per_pixel;
x2 = DIV_ROUND_UP(bit_end, info->var.bits_per_pixel);
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 8e5148bf40bb..b057cfbba938 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -94,7 +94,7 @@ static int drm_fbdev_generic_helper_fb_probe(struct
drm_fb_helper *fb_helper,
fb_helper->buffer = buffer;
fb_helper->fb = buffer->fb;
- screen_size = buffer->gem->size;
+ screen_size = sizes->surface_height * buffer->fb->pitches[0];
I guess we simply go back to this line. I'd R-b a patch that does
exactly this.
But some explanation is in order. Maybe you can add this as a comment to
the computation, as it's not obvious:
The value of screen_size should actually be the size of the gem buffer.
In a physical framebuffer (i.e., video memory), the size
Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement wait_hpd_asserted
Hi,
On Wed, Apr 12, 2023 at 9:19 PM Nikita Travkin wrote:
>
> Doug Anderson писал(а) 13.04.2023 01:22:
> > Hi,
> >
> > On Sat, Apr 8, 2023 at 1:20 AM Nikita Travkin wrote:
> >>
> >> This bridge doesn't actually implement HPD due to it being way too slow
> >> but instead expects the panel driver to wait enough to assume HPD is
> >> asserted. However some panels (such as the generic 'edp-panel') expect
> >> the bridge to deal with the delay and pass maximum delay to the aux
> >> instead.
> >>
> >> In order to support such panels, add a dummy implementation of wait
> >> that would just sleep the maximum delay and assume no failure has
> >> happened.
> >>
> >> Signed-off-by: Nikita Travkin
> >> ---
> >> This was suggested in [1] to make sure DT users can be semantically
> >> correct (not adding no-hpd when the line is actually there) while
> >> still using a hard delay to be faster than waiting the long debounce
> >> time.
> >>
> >> [1] -
> >> https://lore.kernel.org/all/CAD=FV=VR7sKsquE25eF7joc7gPApu-vqwduZzjE=wfcoxjm...@mail.gmail.com/
> >> ---
> >> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 19 +++
> >> 1 file changed, 19 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> index 7a748785c545..260cad1fd1da 100644
> >> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> @@ -618,6 +618,24 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux
> >> *aux,
> >> return len;
> >> }
> >>
> >> +static int ti_sn_aux_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned
> >> long wait_us)
> >> +{
> >> + /*
> >> +* The HPD in this chip is a bit useless (See comment in
> >> +* ti_sn65dsi86_enable_comms) so if our driver is expected to wait
> >> +* for HPD, we just assume it's asserted after the wait_us delay.
> >> +*
> >> +* In case we are asked to wait forever (wait_us=0) take
> >> conservative
> >> +* 500ms delay.
> >> +*/
> >> + if (wait_us == 0)
> >> + wait_us = 50;
> >> +
> >> + usleep_range(wait_us, wait_us + 1000);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static int ti_sn_aux_probe(struct auxiliary_device *adev,
> >>const struct auxiliary_device_id *id)
> >> {
> >> @@ -627,6 +645,7 @@ static int ti_sn_aux_probe(struct auxiliary_device
> >> *adev,
> >> pdata->aux.name = "ti-sn65dsi86-aux";
> >> pdata->aux.dev = &adev->dev;
> >> pdata->aux.transfer = ti_sn_aux_transfer;
> >> + pdata->aux.wait_hpd_asserted = ti_sn_aux_wait_hpd_asserted;
> >
> > This looks reasonable to me, but I think you only want this
> > implementation if the "no-hpd" property _isn't_ present. In other
> > words:
> >
> > if (!of_property_read_bool(np, "no-hpd"))
> > pdata->aux.wait_hpd_asserted = ti_sn_aux_wait_hpd_asserted;
> >
> > Essentially:
> >
> > * If "no-hpd" is present in ti-sn65dsi86 then we'll assume that HPD is
> > handled by the panel driver via a GPIO or a "no-hpd" there (which will
> > cause the panel driver to wait the maximum duration).
> >
> > * If "no-hpd" isn't present in ti-sn65dsi86 then HPD is actually
> > hooked up and thus the panel driver _won't_ handle it.
> >
> > Does that seem right? Presumably this should be explained by comments.
> >
>
> This does sound reasonable indeed, I didn't think to add it
> conditionally because, looking at the current users of
> wait_hpd_asserted, they will first try the "no-hpd" paths
> and will only call the bridge when they think it's on the
> bridge to wait.
>
> Thus, if DT is modeled properly - Panel has no-hpd or a gpio,
> wait_hpd_asserted will never be called anyway. Other bridges
> seem to also unconditionally enable the method.
>
> For this to be a trouble, a panel driver has to be "broken"
> with some form of calling wait_hpd_asserted despite knowing
> the HPD line is not hooked up...
>
> So I feel like guarding the wait_hpd_asserted for no-hpd
> users should not actually change much, but if you think
> I should add the check anyway, please let me know.
Ah, true, it shouldn't actually matter. I guess I still like it
slightly better with the extra check but not enough that I'll insist
on it. Thus:
Reviewed-by: Douglas Anderson
I can commit this to drm-misc-next, but I'll plan to wait ~1 week to
see if anyone else has any comments about it.
-Doug
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On Fri, Apr 14, 2023 at 01:00:07AM +0800, Sui Jingfeng wrote: > > On 2023/4/13 23:56, Daniel Vetter wrote: > > On Thu, 13 Apr 2023 at 17:35, Sui Jingfeng <15330273...@189.cn> wrote: > > > Hi, > > > > > > On 2023/4/13 01:44, Daniel Vetter wrote: > > > > On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote: > > > > > Hi, > > > > > > > > > > On 2023/4/11 22:53, Daniel Vetter wrote: > > > > > > On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote: > > > > > > > From: Sui Jingfeng > > > > > > > > > > > > > > We should setting the screen buffer size according to the > > > > > > > screen's actual > > > > > > > size, rather than the size of the GEM object backing the front > > > > > > > framebuffer. > > > > > > > The size of GEM buffer is page size aligned, while the size of > > > > > > > active area > > > > > > > of a specific screen is *NOT* necessarily page size aliged. For > > > > > > > example, > > > > > > > 1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the > > > > > > > damage rect > > > > > > > computed by drm_fb_helper_memory_range_to_clip() goes out of > > > > > > > bottom bounds > > > > > > > of the display. > > > > > > > > > > > > > > Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 > > > > > > > resolution > > > > > > > will cause the system hang with the following call trace: > > > > > > > > > > > > > > Oops: [#1] PREEMPT SMP PTI > > > > > > > [IGT] fbdev: starting subtest eof > > > > > > > Workqueue: events drm_fb_helper_damage_work [drm_kms_helper] > > > > > > > [IGT] fbdev: starting subtest nullptr > > > > > > > > > > > > > > RIP: 0010:memcpy_erms+0xa/0x20 > > > > > > > RSP: 0018:a17d40167d98 EFLAGS: 00010246 > > > > > > > RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: > > > > > > > 14c0 > > > > > > > RDX: 1a40 RSI: a17d40e0b000 RDI: > > > > > > > a17d4eb8 > > > > > > > RBP: a17d40167e20 R08: R09: > > > > > > > 89522ecff8c0 > > > > > > > R10: a17d4e4c5000 R11: R12: > > > > > > > a17d4eb7fa80 > > > > > > > R13: 1a40 R14: 041a R15: > > > > > > > a17d40167e30 > > > > > > > FS: () GS:89525738() > > > > > > > knlGS: > > > > > > > CS: 0010 DS: ES: CR0: 80050033 > > > > > > > CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: > > > > > > > 001706e0 > > > > > > > Call Trace: > > > > > > > > > > > > > > ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 > > > > > > > [drm_kms_helper] > > > > > > > drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper] > > > > > > > process_one_work+0x21f/0x430 > > > > > > > worker_thread+0x4e/0x3c0 > > > > > > > ? __pfx_worker_thread+0x10/0x10 > > > > > > > kthread+0xf4/0x120 > > > > > > > ? __pfx_kthread+0x10/0x10 > > > > > > > ret_from_fork+0x2c/0x50 > > > > > > > > > > > > > > CR2: a17d40e0b000 > > > > > > > ---[ end trace ]--- > > > > > > > > > > > > > > We also add trival code in this patch to restrict the damage rect > > > > > > > beyond > > > > > > > the last line of the framebuffer. > > > > > > Nice catch! > > > > >:) > > > > > > > Signed-off-by: Sui Jingfeng > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > > > > > > > drivers/gpu/drm/drm_fbdev_generic.c | 2 ++ > > > > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > > > > > > b/drivers/gpu/drm/drm_fb_helper.c > > > > > > > index 64458982be40..a2b749372759 100644 > > > > > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > > > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > > > > > @@ -645,7 +645,7 @@ static void > > > > > > > drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t > > > > > > > off, > > > > > > > u32 x1 = 0; > > > > > > > u32 y1 = off / info->fix.line_length; > > > > > > > u32 x2 = info->var.xres; > > > > > > > - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length); > > > > > > > + u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length), > > > > > > > info->var.yres); > > > > > > So for additional robustness I think it'd be good if we change the > > > > > > entire > > > > > > computation here to use drm_framebuffer data and not fb_info data, > > > > > > because > > > > > > fundamentally that's what the drm kms code consumes. It should all > > > > > > match > > > > > > anyway, but I think it makes the code more obviously correct. > > > > > > > > > > > > So in the entire function instead of looking at fb_info->fix we > > > > > > should > > > > > > probably look at > > > > > > > > > > > > struct drm_fb_helper *helper = info->par; > > > > > > > > > > > > And then helper->fb->pitches[0] and help
Re: [PATCH v10 00/23] drm/i915/vm_bind: Add VM_BIND functionality
On Tue, Jan 17, 2023 at 11:15:46PM -0800, Niranjana Vishwanathapura wrote: DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst * The IGT RFC series is posted as, [PATCH i-g-t v10 0/19] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support v7: Rebased, minor cleanups as per review feedback v8: Rebased, add capture support v9: Address capture support feedback from v8 v10: Properly handle vma->resource for mappings with capture request Test-with: 20230118071350.17498-1-niranjana.vishwanathap...@intel.com Signed-off-by: Niranjana Vishwanathapura Hi, It has become clear that we have a long way towards fully featured implementation of VM_BIND in i915. Examples of the many challenges include integration with display, integration with userspace drivers, a rewrite of all the i915 IGTs to support execbuf3, alignment with DRM GPU VA manager[1] etc. We are stopping further VM_BIND upstreaming efforts in i915 so we can accelerate the merge plan for the new drm/xe driver[2] which has been designed for VM_BIND from the beginning. Since we are not proceeding further with this i915 VM_BIND patch series, the MTL support needed for setting the MOCS and PAT settings in an immutable way at buffer creation time has been posted in a separate series[3] under review. Thanks for all your feedback on this series which is much appreciated. Regards, Niranjana [1] https://www.spinics.net/lists/nouveau/msg11069.html [2] https://www.spinics.net/lists/dri-devel/msg390882.html [3] https://patchwork.freedesktop.org/series/115980/ Niranjana Vishwanathapura (23): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Support partially mapped vma resource drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support drm/i915/vm_bind: Properly build persistent map sg table drm/i915/vm_bind: Support capture of persistent mappings Documentation/gpu/i915.rst| 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 522 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 872 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++ .../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915
Re: linux-next: manual merge of the drm tree with the powerpc tree
Hi Mark,
On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/Kconfig
>
> between commit:
>
> 78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
>
> from the powerpc tree and commit:
>
> 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
>
> from the drm tree.
>
> I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
> 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.
This resolution is not quite right on next-20230412 and next-20230413,
as the drm tree's rename was not taken into account on the conflicting
line. In other words, I need this diff for everything to work properly.
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index b990ef80d686..2d8e55e29637 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
Please consider resolving this in a future -next update, I was rather
surprised that my AMD test machine's graphical output was not working
until I noticed the configuration difference :)
Cheers,
Nathan
Re: [PULL] drm-intel-next-fixes
On Thu, Apr 13, 2023 at 03:12:19PM +0300, Joonas Lahtinen wrote: > Hi Dave & Daniel, > > Just one Cc:stable fix for indirect sampler state this week on > drm-intel-next-fixes. > > Regards, Joonas > > *** > > drm-intel-next-fixes-2023-04-13: > > Short summary of fixes pull (less than what git shortlog provides): > > Just one Cc:stable fix for sampler indirect state in bindless heap. > > The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585: > > Merge tag 'mediatek-drm-next-6.4' of > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into > drm-next (2023-04-11 12:28:10 +0200) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel > tags/drm-intel-next-fixes-2023-04-13 Pulled, thanks. > > for you to fetch changes up to 81900e3a37750d8c6ad705045310e002f6dd0356: > > drm/i915: disable sampler indirect state in bindless heap (2023-04-12 > 11:36:09 +0300) > > > Short summary of fixes pull (less than what git shortlog provides): > > Just one Cc:stable fix for sampler indirect state in bindless heap. > > > Lionel Landwerlin (1): > drm/i915: disable sampler indirect state in bindless heap > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + > drivers/gpu/drm/i915/gt/intel_workarounds.c | 19 +++ > 2 files changed, 20 insertions(+) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PULL] drm-misc-fixes
Hi Dave and Daniel, this is the PR for drm-misc-fixes for this week. Best regards Thomas drm-misc-fixes-2023-04-13: Short summary of fixes pull: * armada: Fix double free * fb: Clear FB_ACTIVATE_KD_TEXT in ioctl * nouveau: Add missing callbacks * scheduler: Fix use-after-free error The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-04-13 for you to fetch changes up to 5603effb8295ada8419408d038a34ca89d658229: Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes (2023-04-12 12:01:32 +0200) Short summary of fixes pull: * armada: Fix double free * fb: Clear FB_ACTIVATE_KD_TEXT in ioctl * nouveau: Add missing callbacks * scheduler: Fix use-after-free error Asahi Lina (1): drm/scheduler: Fix UAF race in drm_sched_entity_push_job() Christophe JAILLET (1): drm/armada: Fix a potential double free in an error handling path Daniel Vetter (1): fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace Karol Herbst (1): drm/nouveau/fb: add missing sysmen flush callbacks Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes drivers/gpu/drm/armada/armada_drv.c| 1 - drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c | 1 + drivers/gpu/drm/scheduler/sched_entity.c | 11 +-- drivers/video/fbdev/core/fbmem.c | 2 ++ 7 files changed, 15 insertions(+), 3 deletions(-) -- 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
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 9:40 AM Tvrtko Ursulin
wrote:
>
>
> On 13/04/2023 14:27, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 12/04/2023 20:18, Daniel Vetter wrote:
> >>> On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> >> On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>>
> >>> On 11/04/2023 23:56, Rob Clark wrote:
> From: Rob Clark
>
> Add support to dump GEM stats to fdinfo.
>
> v2: Fix typos, change size units to match docs, use div_u64
> v3: Do it in core
>
> Signed-off-by: Rob Clark
> Reviewed-by: Emil Velikov
> ---
> Documentation/gpu/drm-usage-stats.rst | 21
> drivers/gpu/drm/drm_file.c| 76
> +++
> include/drm/drm_file.h| 1 +
> include/drm/drm_gem.h | 19 +++
> 4 files changed, 117 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b46327356e80..b5e7802532ed 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -105,6 +105,27 @@ object belong to this client, in the respective
> memory region.
> Default unit shall be bytes with optional unit specifiers of
> 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-shared-memory: [KiB|MiB]
> +
> +The total size of buffers that are shared with another file (ie.
> have more
> +than a single handle).
> +
> +- drm-private-memory: [KiB|MiB]
> +
> +The total size of buffers that are not shared with another file.
> +
> +- drm-resident-memory: [KiB|MiB]
> +
> +The total size of buffers that are resident in system memory.
> >>>
> >>> I think this naming maybe does not work best with the existing
> >>> drm-memory- keys.
> >>
> >> Actually, it was very deliberate not to conflict with the existing
> >> drm-memory- keys ;-)
> >>
> >> I wouldn't have preferred drm-memory-{active,resident,...} but it
> >> could be mis-parsed by existing userspace so my hands were a bit tied.
> >>
> >>> How about introduce the concept of a memory region from the start and
> >>> use naming similar like we do for engines?
> >>>
> >>> drm-memory-$CATEGORY-$REGION: ...
> >>>
> >>> Then we document a bunch of categories and their semantics, for
> >>> instance:
> >>>
> >>> 'size' - All reachable objects
> >>> 'shared' - Subset of 'size' with handle_count > 1
> >>> 'resident' - Objects with backing store
> >>> 'active' - Objects in use, subset of resident
> >>> 'purgeable' - Or inactive? Subset of resident.
> >>>
> >>> We keep the same semantics as with process memory accounting (if I got
> >>> it right) which could be desirable for a simplified mental model.
> >>>
> >>> (AMD needs to remind me of their 'drm-memory-...' keys semantics. If
> >>> we
> >>> correctly captured this in the first round it should be equivalent to
> >>> 'resident' above. In any case we can document no category is equal to
> >>> which category, and at most one of the two must be output.)
> >>>
> >>> Region names we at most partially standardize. Like we could say
> >>> 'system' is to be used where backing store is system RAM and others
> >>> are
> >>> driver defined.
> >>>
> >>> Then discrete GPUs could emit N sets of key-values, one for each
> >>> memory
> >>> region they support.
> >>>
> >>> I think this all also works for objects which can be migrated between
> >>> memory regions. 'Size' accounts them against all regions while for
> >>> 'resident' they only appear in the region of their current placement,
> >>> etc.
> >>
> >> I'm not too sure how to rectify different memory regions with this,
> >> since drm core doesn't really know about the driver's memory regions.
> >> Perhaps we can go back to this being a helper and drivers with vram
> >> just don't use the helper? Or??
> >
> > I think if you flip it around to drm-$CATEGORY-memory{-$REGION}: then it
> > all works out reasonably consistently?
>
> That is basically what we have now. I could append -system to each to
> make things easier to add vram/etc (from a uabi standpoint)..
> >>>
> >>> What you have isn't really -system, but everything. So doesn't really make
> >>> sense to me to ma
[PATCH v2] drm/fbdev-generic: prohibit potential out-of-bounds access
From: Sui Jingfeng
The crazy fbdev test of IGT may write after EOF, which lead to out-of-bound
access for the drm drivers using fbdev-generic. For example, run fbdev test
on a x86-64+ast2400 platform with 1680x1050 resolution will cause the linux
kernel hang with following call trace:
Oops: [#1] PREEMPT SMP PTI
[IGT] fbdev: starting subtest eof
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+0xa/0x20
RSP: 0018:a17d40167d98 EFLAGS: 00010246
RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
RBP: a17d40167e20 R08: R09: 89522ecff8c0
R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
R13: 1a40 R14: 041a R15: a17d40167e30
FS: () GS:89525738() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
Call Trace:
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430
worker_thread+0x4e/0x3c0
? __pfx_worker_thread+0x10/0x10
kthread+0xf4/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
CR2: a17d40e0b000
---[ end trace ]---
The indirect reason is drm_fb_helper_memory_range_to_clip() generate damage
rectangles which partially or completely go out of the active display area.
The second of argument 'off' is passing from the user-space, this will lead
to the out-of-bound if it is large than (fb_height + 1) * fb_pitches; while
DIV_ROUND_UP() may also controbute to error by 1.
This patch will add code to restrict the damage rect computed go beyond of
the last line of the framebuffer.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 16
drivers/gpu/drm/drm_fbdev_generic.c | 2 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64458982be40..6bb1b8b27d7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -641,19 +641,27 @@ static void drm_fb_helper_damage(struct drm_fb_helper
*helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t
off, size_t len,
struct drm_rect *clip)
{
+ u32 line_length = info->fix.line_length;
+ u32 fb_height = info->var.yres;
off_t end = off + len;
u32 x1 = 0;
- u32 y1 = off / info->fix.line_length;
+ u32 y1 = off / line_length;
u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 y2 = DIV_ROUND_UP(end, line_length);
+
+ /* Don't allow any of them beyond the bottom bound of display area */
+ if (y1 > fb_height)
+ y1 = fb_height;
+ if (y2 > fb_height)
+ y2 = fb_height;
if ((y2 - y1) == 1) {
/*
* We've only written to a single scanline. Try to reduce
* the number of horizontal pixels that need an update.
*/
- off_t bit_off = (off % info->fix.line_length) * 8;
- off_t bit_end = (end % info->fix.line_length) * 8;
+ off_t bit_off = (off % line_length) * 8;
+ off_t bit_end = (end % line_length) * 8;
x1 = bit_off / info->var.bits_per_pixel;
x2 = DIV_ROUND_UP(bit_end, info->var.bits_per_pixel);
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 8e5148bf40bb..b057cfbba938 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -94,7 +94,7 @@ static int drm_fbdev_generic_helper_fb_probe(struct
drm_fb_helper *fb_helper,
fb_helper->buffer = buffer;
fb_helper->fb = buffer->fb;
- screen_size = buffer->gem->size;
+ screen_size = sizes->surface_height * buffer->fb->pitches[0];
screen_buffer = vzalloc(screen_size);
if (!screen_buffer) {
ret = -ENOMEM;
--
2.25.1
Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated
"Pierre Asselin" writes:
>> diff --git a/drivers/firmware/sysfb_simplefb.c
>> b/drivers/firmware/sysfb_simplefb.c
>> index 82c64cb9f531..0ab8c542b1f5 100644
>> --- a/drivers/firmware/sysfb_simplefb.c
>> +++ b/drivers/firmware/sysfb_simplefb.c
>> @@ -55,14 +55,10 @@ __init bool sysfb_parse_mode(const struct screen_info
>> *si,
>> * ignore simplefb formats with alpha bits, as EFI and VESA
>> * don't specify alpha channels.
>> */
>> -if (si->lfb_depth > 8) {
>> -bits_per_pixel = max(max3(si->red_size + si->red_pos,
>> - si->green_size + si->green_pos,
>> - si->blue_size + si->blue_pos),
>> - si->rsvd_size + si->rsvd_pos);
>> -} else {
>> +if (si->lfb_depth > 8)
>> +bits_per_pixel = si->lfb_linelength * 8 / si->lfb_width;
>> +else
>> bits_per_pixel = si->lfb_depth;
>> -}
>>
>> for (i = 0; i < ARRAY_SIZE(formats); ++i) {
>> const struct simplefb_format *f = &formats[i];
>>
>> base-commit: e62252bc55b6d4eddc6c2bdbf95a448180d6a08d
>> --
>> 2.40.0
>
> Patch is good on both boxes.
>
Thanks for testing it! I'll wait for Thomas though before posting as a
proper patch. I'm sure whether we can rely on lfb_linelength or not...
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
RE: [PATCH v4 08/12] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
Hi,
> Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
>
Looks Good to me
Reviewed-by: Suraj Kandpal
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 438
> +++
> include/drm/display/drm_dsc_helper.h | 2 +
> 2 files changed, 440 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index aec6f8c201af..65e810a54257 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -740,6 +740,438 @@ static const struct rc_parameters_data
> rc_parameters_1_2_444[] = {
> { /* sentinel */ }
> };
>
> +static const struct rc_parameters_data rc_parameters_1_2_422[] = {
> + {
> + .bpp = DSC_BPP(6), .bpc = 8,
> + { 512, 15, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11,
> -12 },
> + { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 10,
> + { 512, 15, 6144, 7, 16, 15, 15, {
> + { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
> -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15,
> -12 },
> + { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 12,
> + { 512, 15, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
> + { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
> + { 20, 21, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 14,
> + { 512, 15, 6144, 15, 24, 23, 23, {
> + { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2
> },
> + { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15,
> 20, -8 },
> + { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
> + { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
> + { 24, 25, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 16,
> + { 512, 15, 6144, 19, 28, 27, 27, {
> + { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2
> },
> + { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19,
> 24, -8 },
> + { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
> + { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
> + { 28, 29, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 8,
> + { 410, 15, 5632, 3, 12, 11, 11, {
> + { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10,
> -10 },
> + { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 10,
> + { 410, 15, 5632, 7, 16, 15, 15, {
> + { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
> -8 },
> + { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14,
> -10 },
> + { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 12,
> + { 410, 15, 5632, 11, 20, 19, 19, {
> + { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2
> },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
> 16, -8 },
> + { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
> + { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
> + { 19, 20, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 14,
> + { 410, 15, 5632, 15, 24, 23, 23, {
> + { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2
>
Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated
> diff --git a/drivers/firmware/sysfb_simplefb.c
> b/drivers/firmware/sysfb_simplefb.c
> index 82c64cb9f531..0ab8c542b1f5 100644
> --- a/drivers/firmware/sysfb_simplefb.c
> +++ b/drivers/firmware/sysfb_simplefb.c
> @@ -55,14 +55,10 @@ __init bool sysfb_parse_mode(const struct screen_info
> *si,
>* ignore simplefb formats with alpha bits, as EFI and VESA
>* don't specify alpha channels.
>*/
> - if (si->lfb_depth > 8) {
> - bits_per_pixel = max(max3(si->red_size + si->red_pos,
> - si->green_size + si->green_pos,
> - si->blue_size + si->blue_pos),
> - si->rsvd_size + si->rsvd_pos);
> - } else {
> + if (si->lfb_depth > 8)
> + bits_per_pixel = si->lfb_linelength * 8 / si->lfb_width;
> + else
> bits_per_pixel = si->lfb_depth;
> - }
>
> for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> const struct simplefb_format *f = &formats[i];
>
> base-commit: e62252bc55b6d4eddc6c2bdbf95a448180d6a08d
> --
> 2.40.0
Patch is good on both boxes.
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On 2023/4/13 23:56, Daniel Vetter wrote:
On Thu, 13 Apr 2023 at 17:35, Sui Jingfeng <15330273...@189.cn> wrote:
Hi,
On 2023/4/13 01:44, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote:
Hi,
On 2023/4/11 22:53, Daniel Vetter wrote:
On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
We should setting the screen buffer size according to the screen's actual
size, rather than the size of the GEM object backing the front framebuffer.
The size of GEM buffer is page size aligned, while the size of active area
of a specific screen is *NOT* necessarily page size aliged. For example,
1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the damage rect
computed by drm_fb_helper_memory_range_to_clip() goes out of bottom bounds
of the display.
Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 resolution
will cause the system hang with the following call trace:
Oops: [#1] PREEMPT SMP PTI
[IGT] fbdev: starting subtest eof
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+0xa/0x20
RSP: 0018:a17d40167d98 EFLAGS: 00010246
RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
RBP: a17d40167e20 R08: R09: 89522ecff8c0
R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
R13: 1a40 R14: 041a R15: a17d40167e30
FS: () GS:89525738()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
Call Trace:
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430
worker_thread+0x4e/0x3c0
? __pfx_worker_thread+0x10/0x10
kthread+0xf4/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
CR2: a17d40e0b000
---[ end trace ]---
We also add trival code in this patch to restrict the damage rect beyond
the last line of the framebuffer.
Nice catch!
:)
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_fbdev_generic.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64458982be40..a2b749372759 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -645,7 +645,7 @@ static void drm_fb_helper_memory_range_to_clip(struct
fb_info *info, off_t off,
u32 x1 = 0;
u32 y1 = off / info->fix.line_length;
u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length),
info->var.yres);
So for additional robustness I think it'd be good if we change the entire
computation here to use drm_framebuffer data and not fb_info data, because
fundamentally that's what the drm kms code consumes. It should all match
anyway, but I think it makes the code more obviously correct.
So in the entire function instead of looking at fb_info->fix we should
probably look at
struct drm_fb_helper *helper = info->par;
And then helper->fb->pitches[0] and helper->fb->height.
If you agree would be great if you can please respin with that (and the
commit message augmented to explain why we do the change)?
Yes, I'm agree.
Thank you for guidance, I will refine this patch with `helper = info->par`.
I will send a v2 when I finished.
if ((y2 - y1) == 1) {
/*
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 8e5148bf40bb..a6daecb5f640 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -95,6 +95,8 @@ static int drm_fbdev_generic_helper_fb_probe(struct
drm_fb_helper *fb_helper,
fb_helper->fb = buffer->fb;
screen_size = buffer->gem->size;
I guess you forgot to remove this line here?
Yes, this line should be removed in this patch. I overlooked this, sorry.
Also I'm not understanding
why this matters, I think you're fix only needs the above chunk, not this
one? If I got this right then please drop this part, there's drivers which
only use drm_fb_helper.c but not drm_fbdev_generic.c, and from what I can
tell they all still set the gem buffer size here.
If otoh we need this too, then there's a few more places that need to be
fixed.
I think we need this line, otherwise wrapped around will be happen.
Because I found that the value of variable`y1` will be larger in number than
the variable `y2` by 1,
which are computed in drm_fb_helper_memory_range_to_clip().
[PATCH v2 7/7] drm/i915: Do state check for color management changes
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?
v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 842d70f0dfd2..9e4767e1b900 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -228,6 +228,8 @@ void intel_modeset_verify_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *new_crtc_state)
{
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+ (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
--
2.39.2
[PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts
From: Ville Syrjälä
Apparently desktop gen3 parts don't support the
10bit gamma mode at all. Stop claiming otherwise.
As is the case with pipe A on gen3 mobile parts, the
PIPECONF gamma mode bit can be set but it has no
effect on the output.
PNV seems to be the only slight exception, but generally
the desktop PNV variant looks more like a mobile part so
this is not entirely surprising.
Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cddb6e197972..305c05c3f93b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
.dma_mask_size = 32, \
I9XX_PIPE_OFFSETS, \
I9XX_CURSOR_OFFSETS, \
- I9XX_COLORS, \
GEN_DEFAULT_PAGE_SIZES, \
GEN_DEFAULT_REGIONS
static const struct intel_device_info i915g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915G),
+ I845_COLORS,
.has_coherent_ggtt = false,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
static const struct intel_device_info i915gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915GM),
+ I9XX_COLORS,
.is_mobile = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
static const struct intel_device_info i945g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945G),
+ I845_COLORS,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
static const struct intel_device_info i945gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945GM),
+ I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
@@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
static const struct intel_device_info g33_info = {
GEN3_FEATURES,
PLATFORM(INTEL_G33),
+ I845_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {
static const struct intel_device_info pnv_g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+ I9XX_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
static const struct intel_device_info pnv_m_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+ I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.has_overlay = 1,
--
2.39.2
[PATCH v2 5/7] drm/i915: Implement CTM property support for VLV
From: Ville Syrjälä
VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, which less precisions/range. In fact CHV also has the WGC
but using it there doesn't reall make sense when you have the
superior CGM CSC around.
Hook up the necessary stuff to expose the WGC as the CTM
crtc property.
One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c| 170 +-
.../drm/i915/display/intel_crtc_state_dump.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.c | 8 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/i915_reg.h | 15 ++
5 files changed, 198 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 7a705e7d8776..e36d8c248b84 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -587,6 +587,98 @@ static u16 ctm_to_twos_complement(u64 coeff, int int_bits,
int frac_bits)
return c & (BIT(int_bits + frac_bits) - 1);
}
+/*
+ * VLV/CHV Wide Gamut Color Correction (WGC) CSC
+ * |r| | c0 c1 c2 | |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b| | c6 c7 c8 | |b|
+ *
+ * Coefficients are two's complement s2.10.
+ */
+static void vlv_wgc_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
+ struct intel_csc_matrix *csc)
+{
+ const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
+ int i;
+
+ for (i = 0; i < 9; i++)
+ csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 2, 10);
+}
+
+static void vlv_load_wgc_csc(struct intel_crtc *crtc,
+const struct intel_csc_matrix *csc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C01_C00(pipe),
+ csc->coeff[1] << 16 | csc->coeff[0]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C02(pipe),
+ csc->coeff[2]);
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C11_C10(pipe),
+ csc->coeff[4] << 16 | csc->coeff[3]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C12(pipe),
+ csc->coeff[5]);
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C21_C20(pipe),
+ csc->coeff[7] << 16 | csc->coeff[6]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C22(pipe),
+ csc->coeff[8]);
+}
+
+static void vlv_read_wgc_csc(struct intel_crtc *crtc,
+struct intel_csc_matrix *csc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tmp;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C01_C00(pipe));
+ csc->coeff[0] = tmp & 0x;
+ csc->coeff[1] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C02(pipe));
+ csc->coeff[2] = tmp & 0x;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C11_C10(pipe));
+ csc->coeff[3] = tmp & 0x;
+ csc->coeff[4] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C12(pipe));
+ csc->coeff[5] = tmp & 0x;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C21_C20(pipe));
+ csc->coeff[6] = tmp & 0x;
+ csc->coeff[7] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C22(pipe));
+ csc->coeff[8] = tmp & 0x;
+}
+
+static void vlv_read_csc(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+ if (crtc_state->wgc_enable)
+ vlv_read_wgc_csc(crtc, &crtc_state->csc);
+}
+
+static void vlv_assign_csc(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ if (crtc_state->hw.ctm) {
+ drm_WARN_ON(&i915->drm, !crtc_state->wgc_enable);
+
+ vlv_wgc_csc_convert_ctm(crtc_state, &crtc_state->csc);
+ } else {
+ drm_WARN_ON(&i915->drm, crtc_state->wgc_enable);
+
+ intel_csc_clear(&crtc_state->csc);
+ }
+}
+
/*
* CHV Color Gamut Mapping (CGM) CSC
* |r| | c0 c1 c2 | |r|
@@ -672,6 +764,8 @@ static void chv_assign_csc(struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ drm_WARN_ON(&i915->drm, crtc_state->wgc_enable);
+
if (crtc_state->hw.ctm) {
drm_WARN_ON(&i915->drm, (crtc_
[PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV
From: Ville Syrjälä
On CHV toggling the CGM CSC on/off while the pipe is running leads
to underruns. Looks like we'd have to do the toggling strictly inside
the start_of_vblank-frame_start window to avoid this, but that window
is less than a scanline so there's no way we can guarantee hitting it.
As a workaround let's just leave the CGM CSC permanently enabled.
Fortunately the CGM gamma/degamma units don't seem to suffer from
this malady.
I also tried turning off CGM unit clock gating, but that did not
help.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 63141f4ed372..7a705e7d8776 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -605,6 +605,16 @@ static void chv_cgm_csc_convert_ctm(const struct
intel_crtc_state *crtc_state,
csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
}
+#define CHV_CGM_CSC_COEFF_1_0 (1 << 12)
+
+static const struct intel_csc_matrix chv_cgm_csc_matrix_identity = {
+ .coeff = {
+ CHV_CGM_CSC_COEFF_1_0, 0, 0,
+ 0, CHV_CGM_CSC_COEFF_1_0, 0,
+ 0, 0, CHV_CGM_CSC_COEFF_1_0,
+ },
+};
+
static void chv_load_cgm_csc(struct intel_crtc *crtc,
const struct intel_csc_matrix *csc)
{
@@ -667,9 +677,9 @@ static void chv_assign_csc(struct intel_crtc_state
*crtc_state)
chv_cgm_csc_convert_ctm(crtc_state, &crtc_state->csc);
} else {
- drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
CGM_PIPE_MODE_CSC) != 0);
+ drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
CGM_PIPE_MODE_CSC) == 0);
- intel_csc_clear(&crtc_state->csc);
+ crtc_state->csc = chv_cgm_csc_matrix_identity;
}
}
@@ -2033,6 +2043,13 @@ static u32 chv_cgm_mode(const struct intel_crtc_state
*crtc_state)
!lut_is_legacy(crtc_state->hw.gamma_lut))
cgm_mode |= CGM_PIPE_MODE_GAMMA;
+ /*
+* Toggling the CGM CSC on/off outside of the tiny window
+* between start of vblank and frame start causes underruns.
+* Always enable the CGM CSC as a workaround.
+*/
+ cgm_mode |= CGM_PIPE_MODE_CSC;
+
return cgm_mode;
}
--
2.39.2
[PATCH v2 2/7] drm/i915: Expose crtc CTM property on ilk/snb
From: Ville Syrjälä The ilk/snb code is internally fully capable of handling the CTM property, so expose it. Note that we still choose not to expose DEGAMMA_LUT though. The hardware is capable if degamma or gamma, but not both similtanously due to lack of the split gamma mode. Exposing both LUTs might encourage userspace to try enabling both at the same time. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 07f1afe1d406..4fc16cac052d 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -3473,7 +3473,7 @@ void intel_color_crtc_init(struct intel_crtc *crtc) gamma_lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size; degamma_lut_size = INTEL_INFO(i915)->display.color.degamma_lut_size; - has_ctm = degamma_lut_size != 0; + has_ctm = DISPLAY_VER(i915) >= 5 && !IS_VALLEYVIEW(i915); /* * "DPALETTE_A: NOTE: The 8-bit (non-10-bit) mode is the -- 2.39.2
[PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
From: Ville Syrjälä
The CHV CGM CSC coefficients are in s4.12 two's complement
format. Fix the CTM->CGM conversion to handle that correctly
instead of pretending that the hw coefficients are also
in some sign-magnitude format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 46 ++
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 4fc16cac052d..63141f4ed372 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
intel_crtc_state *crtc_state)
icl_update_output_csc(crtc, &crtc_state->output_csc);
}
+static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int frac_bits)
+{
+ s64 c = CTM_COEFF_ABS(coeff);
+
+ /* leave an extra bit for rounding */
+ c >>= 32 - frac_bits - 1;
+
+ /* round and drop the extra bit */
+ c = (c + 1) >> 1;
+
+ if (CTM_COEFF_NEGATIVE(coeff))
+ c = -c;
+
+ c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
+ (s64)(BIT(int_bits + frac_bits - 1) - 1));
+
+ return c & (BIT(int_bits + frac_bits) - 1);
+}
+
+/*
+ * CHV Color Gamut Mapping (CGM) CSC
+ * |r| | c0 c1 c2 | |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b| | c6 c7 c8 | |b|
+ *
+ * Coefficients are two's complement s4.12.
+ */
static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
struct intel_csc_matrix *csc)
{
const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
int i;
- for (i = 0; i < 9; i++) {
- u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
-
- /* Round coefficient. */
- abs_coeff += 1 << (32 - 13);
- /* Clamp to hardware limits. */
- abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
-
- csc->coeff[i] = 0;
-
- /* Write coefficients in S3.12 format. */
- if (ctm->matrix[i] & (1ULL << 63))
- csc->coeff[i] |= 1 << 15;
-
- csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
- csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
- }
+ for (i = 0; i < 9; i++)
+ csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
}
static void chv_load_cgm_csc(struct intel_crtc *crtc,
--
2.39.2
[PATCH v2 1/7] drm/uapi: Document CTM matrix better
From: Ville Syrjälä
Document in which order the CTM matrix elements are stored.
Signed-off-by: Ville Syrjälä
---
include/uapi/drm/drm_mode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..43691058d28f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -834,6 +834,11 @@ struct drm_color_ctm {
/*
* Conversion matrix in S31.32 sign-magnitude
* (not two's complement!) format.
+*
+* out matrixin
+* |R| |0 1 2| |R|
+* |G| = |3 4 5| x |G|
+* |B| |6 7 8| |B|
*/
__u64 matrix[9];
};
--
2.39.2
[PATCH v2 0/7] drm/i915: CTM stuff mostly
From: Ville Syrjälä Mostly some CTM stuff: - document the uapi better - fix CHV CSC negative coefficients - expose CTM on ilk/snb/vlv - a bonus gamma patch for gen3 - cure CGM CSC underruns on CHV (new in v2) Test-with: 20230411161555.10001-1-ville.syrj...@linux.intel.com Ville Syrjälä (7): drm/uapi: Document CTM matrix better drm/i915: Expose crtc CTM property on ilk/snb drm/i915: Fix CHV CGM CSC coefficient sign handling drm/i915: Always enable CGM CSC on CHV drm/i915: Implement CTM property support for VLV drm/i915: No 10bit gamma on desktop gen3 parts drm/i915: Do state check for color management changes drivers/gpu/drm/i915/display/intel_color.c| 237 -- .../drm/i915/display/intel_crtc_state_dump.c | 6 +- drivers/gpu/drm/i915/display/intel_display.c | 8 + .../drm/i915/display/intel_display_types.h| 3 + .../drm/i915/display/intel_modeset_verify.c | 2 + drivers/gpu/drm/i915/i915_pci.c | 8 +- drivers/gpu/drm/i915/i915_reg.h | 15 ++ include/uapi/drm/drm_mode.h | 5 + 8 files changed, 260 insertions(+), 24 deletions(-) -- 2.39.2
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Wed, Apr 12, 2023 at 10:42 AM Tvrtko Ursulin
wrote:
>
>
> On 11/04/2023 23:56, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add support to dump GEM stats to fdinfo.
> >
> > v2: Fix typos, change size units to match docs, use div_u64
> > v3: Do it in core
> >
> > Signed-off-by: Rob Clark
> > Reviewed-by: Emil Velikov
> > ---
> > Documentation/gpu/drm-usage-stats.rst | 21
> > drivers/gpu/drm/drm_file.c| 76 +++
> > include/drm/drm_file.h| 1 +
> > include/drm/drm_gem.h | 19 +++
> > 4 files changed, 117 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > b/Documentation/gpu/drm-usage-stats.rst
> > index b46327356e80..b5e7802532ed 100644
> > --- a/Documentation/gpu/drm-usage-stats.rst
> > +++ b/Documentation/gpu/drm-usage-stats.rst
> > @@ -105,6 +105,27 @@ object belong to this client, in the respective memory
> > region.
> > Default unit shall be bytes with optional unit specifiers of 'KiB' or
> > 'MiB'
> > indicating kibi- or mebi-bytes.
> >
> > +- drm-shared-memory: [KiB|MiB]
> > +
> > +The total size of buffers that are shared with another file (ie. have more
> > +than a single handle).
> > +
> > +- drm-private-memory: [KiB|MiB]
> > +
> > +The total size of buffers that are not shared with another file.
> > +
> > +- drm-resident-memory: [KiB|MiB]
> > +
> > +The total size of buffers that are resident in system memory.
>
> I think this naming maybe does not work best with the existing
> drm-memory- keys.
>
> How about introduce the concept of a memory region from the start and
> use naming similar like we do for engines?
>
> drm-memory-$CATEGORY-$REGION: ...
>
> Then we document a bunch of categories and their semantics, for instance:
>
> 'size' - All reachable objects
> 'shared' - Subset of 'size' with handle_count > 1
> 'resident' - Objects with backing store
> 'active' - Objects in use, subset of resident
> 'purgeable' - Or inactive? Subset of resident.
>
> We keep the same semantics as with process memory accounting (if I got
> it right) which could be desirable for a simplified mental model.
>
> (AMD needs to remind me of their 'drm-memory-...' keys semantics. If we
> correctly captured this in the first round it should be equivalent to
> 'resident' above. In any case we can document no category is equal to
> which category, and at most one of the two must be output.)
We've had the standard TTM pools for a while:
drm-memory-vram
drm-memory-gtt
drm-memory-cpu
And we recently added the following, mainly for profiling for mesa:
amd-memory-visible-vram
amd-evicted-vram
amd-evicted-visible-vram
amd-requested-vram
amd-requested-visible-vram
amd-requested-gtt
amd-memory-visible-vram is a subset of drm-memory-vram, not a separate pool.
Alex
>
> Region names we at most partially standardize. Like we could say
> 'system' is to be used where backing store is system RAM and others are
> driver defined.
>
> Then discrete GPUs could emit N sets of key-values, one for each memory
> region they support.
>
> I think this all also works for objects which can be migrated between
> memory regions. 'Size' accounts them against all regions while for
> 'resident' they only appear in the region of their current placement, etc.
>
> Userspace can aggregate if it wishes to do so but kernel side should not.
>
> > +
> > +- drm-purgeable-memory: [KiB|MiB]
> > +
> > +The total size of buffers that are purgeable.
> > +
> > +- drm-active-memory: [KiB|MiB]
> > +
> > +The total size of buffers that are active on one or more rings.
> > +
> > - drm-cycles-
> >
> > Engine identifier string must be the same as the one specified in the
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index 37dfaa6be560..46fdd843bb3a 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "drm_crtc_internal.h"
> > @@ -871,6 +872,79 @@ void drm_send_event(struct drm_device *dev, struct
> > drm_pending_event *e)
> > }
> > EXPORT_SYMBOL(drm_send_event);
> >
> > +static void print_size(struct drm_printer *p, const char *stat, size_t sz)
> > +{
> > + const char *units[] = {"", " KiB", " MiB"};
> > + unsigned u;
> > +
> > + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> > + if (sz < SZ_1K)
> > + break;
> > + sz = div_u64(sz, SZ_1K);
> > + }
> > +
> > + drm_printf(p, "%s:\t%zu%s\n", stat, sz, units[u]);
> > +}
> > +
> > +static void print_memory_stats(struct drm_printer *p, struct drm_file
> > *file)
> > +{
> > + struct drm_gem_object *obj;
> > + struct {
> > + size_t shared;
> > + size_t private;
> > + size_t resident;
> > + size_t purgeable;
> > + size_t active;
> > + } size = {0};
> > + bool has_status = fal
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On 13/04/2023 14:27, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
On 12/04/2023 20:18, Daniel Vetter wrote:
On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
wrote:
On 11/04/2023 23:56, Rob Clark wrote:
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
Documentation/gpu/drm-usage-stats.rst | 21
drivers/gpu/drm/drm_file.c| 76 +++
include/drm/drm_file.h| 1 +
include/drm/drm_gem.h | 19 +++
4 files changed, 117 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..b5e7802532ed 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,6 +105,27 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-shared-memory: [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-private-memory: [KiB|MiB]
+
+The total size of buffers that are not shared with another file.
+
+- drm-resident-memory: [KiB|MiB]
+
+The total size of buffers that are resident in system memory.
I think this naming maybe does not work best with the existing
drm-memory- keys.
Actually, it was very deliberate not to conflict with the existing
drm-memory- keys ;-)
I wouldn't have preferred drm-memory-{active,resident,...} but it
could be mis-parsed by existing userspace so my hands were a bit tied.
How about introduce the concept of a memory region from the start and
use naming similar like we do for engines?
drm-memory-$CATEGORY-$REGION: ...
Then we document a bunch of categories and their semantics, for instance:
'size' - All reachable objects
'shared' - Subset of 'size' with handle_count > 1
'resident' - Objects with backing store
'active' - Objects in use, subset of resident
'purgeable' - Or inactive? Subset of resident.
We keep the same semantics as with process memory accounting (if I got
it right) which could be desirable for a simplified mental model.
(AMD needs to remind me of their 'drm-memory-...' keys semantics. If we
correctly captured this in the first round it should be equivalent to
'resident' above. In any case we can document no category is equal to
which category, and at most one of the two must be output.)
Region names we at most partially standardize. Like we could say
'system' is to be used where backing store is system RAM and others are
driver defined.
Then discrete GPUs could emit N sets of key-values, one for each memory
region they support.
I think this all also works for objects which can be migrated between
memory regions. 'Size' accounts them against all regions while for
'resident' they only appear in the region of their current placement, etc.
I'm not too sure how to rectify different memory regions with this,
since drm core doesn't really know about the driver's memory regions.
Perhaps we can go back to this being a helper and drivers with vram
just don't use the helper? Or??
I think if you flip it around to drm-$CATEGORY-memory{-$REGION}: then it
all works out reasonably consistently?
That is basically what we have now. I could append -system to each to
make things easier to add vram/etc (from a uabi standpoint)..
What you have isn't really -system, but everything. So doesn't really make
sense to me to mark this -system, it's only really true for integrated (if
they don't have stolen or something like that).
Also my comment was more in reply to Tvrtko's suggestion.
Right so my proposal was drm-memory-$CATEGORY-$REGION which I think aligns
with the current drm-memory-$REGION by extending, rather than creating
confusion with different order of key name components.
Oh my comment was pretty much just bikeshed, in case someone creates a
$REGION that other drivers use for $CATEGORY. Kinda Rob's parsing point.
So $CATEGORY before the -memory.
Otoh I don't think that'll happen, so I guess we can go with whatever more
folks like :-) I don't really care much personally.
Okay I missed the parsing problem.
AMD currently has (among others) drm-memory-vram, which we could define in
the spec maps to category X, if category component is not present.
Some examples:
drm-memory-resident-system:
drm-memory-size-lmem0:
drm-memory-active-vram:
Etc.. I think it creates a consistent story.
Other than this, my two I think significant opens which haven't been
addressed yet are:
1)
Why do we want totals (not per region) wh
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 06:19:16PM +0200, Andi Shyti wrote:
> On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote:
> >
> >
> > On 4/13/2023 8:52 AM, Matt Roper wrote:
> > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote:
> > > > Hi Tvrtko,
> > > >
> > > > (I forgot to CC Daniele)
> > > >
> > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote:
> > > > > On 13/04/2023 10:20, Andi Shyti wrote:
> > > > > > From: Paulo Zanoni
> > > > > >
> > > > > > In multitile systems IRQ need to be reset and enabled per GT.
> > > > > >
> > > > > > Although in MTL the GUnit misc interrupts register set are
> > > > > > available only in GT-0, we need to loop through all the GT's
> > > > > > in order to initialize the media engine which lies on a different
> > > > > > GT.
> > > > > >
> > > > > > Signed-off-by: Paulo Zanoni
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Signed-off-by: Andi Shyti
> > > > > > ---
> > > > > > Hi,
> > > > > >
> > > > > > proposing again this patch, apparently GuC needs this patch to
> > > > > > initialize the media GT.
> > > > > What is the resolution for Matt's concern that this is wrong for MTL?
> > > > There are two explanations, one easy and one less easy.
> > > >
> > > > The easy one: without this patch i915 doesn't boot on MTL!(*)
> > > >
> > > > The second explanation is that in MTL the media engine has it's
> > > > own set of misc irq's registers and those are on a different GT
> > > > (Daniele pointed this out).
> > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true;
> > > it's just a single sgunit register (0x1900e8) that has different
> > > bitfields for the primary GuC and the media GuC. So I still think we
> > > should avoid looping over GTs; it's actually much simpler to handle
> > > things in a single pass since we can just determine the single register
> > > value once (all fields) and write it directly, instead of doing two
> > > separate RMW updates to the same register to try to avoid clobbering
> > > the other GuC's settings.
>
> if we handle exceptions in a single pass wouldn't we have many
> exceptions to handle in the long run?
I don't think so, it basically boils down to something along the lines
of
if (MEDIA_VER(i915) >= 13)
val = HIGH_BITS | LOW_BITS;
else
val = HIGH_BITS;
...
intel_uncore_write(val);
which isn't really any more complicated than today's logic:
called for each gt {
...
if (gt is MEDIA)
bits = LOW_BITS;
else
bits = HIGH_BITS;
...
intel_uncore_rmw(bits);
}
Matt
>
> > > For pre-MTL platforms, it's the same register, except that the bitfield
> > > now devoted to the media GuC was previously used for something else
> > > (scatter/gather).
> >
> > It's not just the GuC, the VCS/VECS engine programming is also tied to the
> > media GT (via the HAS_ENGINE checks). It looks like we unconditionally
> > program VCS 0 and 2, so it'll still work for MTL, but if we get a device
> > with more VCS engines it'll break. Maybe we can add a MTL version of the
> > function that just programs everything unconditionally? Going forward it
> > should be ok to program things for engines that don't exist, but I'm not
> > sure we can do that for older platforms that came before the extra engines
> > were ever defined in HW.
>
> This is more or less what Tvrtko has suggested, as well. Looks to
> me like replicating some code... anyway, I will try and see how
> it looks like.
>
> Andi
>
> PS Thanks Matt, Daniele and Tvrtko for the feedback.
>
> > Daniele
> >
> > >
> > >
> > > Matt
> > >
> > > > I sent this patch not to bypass any review, but to restart the
> > > > discussion as this patch was just dropped.
> > > >
> > > > Thanks,
> > > > Andi
> > > >
> > > >
> > > > (*)
> > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7)
> > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT)
> > > > status=0X0
> > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT
> > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT
> > > > [drm] *ERROR* GT1: Enabling uc failed (-5)
> > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated
"Pierre Asselin" writes: >> p...@panix.com (Pierre Asselin) writes: [...] >>> - bits_per_pixel = max(max3(si->red_size + si->red_pos, >>> + bits_per_pixel = max3(max3(si->red_size + si->red_pos, >>> si->green_size + si->green_pos, >>> si->blue_size + si->blue_pos), >>> -si->rsvd_size + si->rsvd_pos); >>> +si->rsvd_size + si->rsvd_pos, >>> +si->lfb_depth); > > >> I would defer to Thomas but personally I don't like it. Seems to me that >> this is getting too complicated just to workaround buggy BIOS that are not >> reporting consistent information about their firmware-provided >> framebuffer. > > Okay, but remember, this is a regression. The buggy BIOSes were there Yes, I agree that is a regression and has to be fixed. I'm just arguing against this particular fix. > the whole time and the old code that matched f->bits_per_pixel against > si->lfb_depth used to work against these buggy BIOSes. > > And is it a bug, or is it an underspecified standard ? "These bits aren't > reserved, we just ignore them" or some such. > > My reading of Thomas' comments in the code was that sometimes lfb_depth > was reported too small but never too large ? But I'm not sure. It's > true in my two cases. > I (mis?)understood that it could be too small as well. But that's why I prefer Thomas to chime in before agreeing on any path forward. But he is in vacation this week I believe. >> I would either trust the pixel channel information (what Thomas patch did) >> + my patch to calculate the stride (since we can't trust the line lenght >> which is based on the reported depth) + a DMI table for broken machines. > >> But that will only work if your systems are the exception and not a common >> issue, otherwise then Thomas' approach won't work if there are too many >> buggy BIOS out there. > > The laptop is ancient but the Dell tower is maybe 4 years old. The > BIOS is 09/11/2019 according to dmidecode, and the most recent for > this box. > I see. >> Another option is to do the opposite, not calculate a BPP using the pixel >> and then use that value to calculate a new stride, but instead assume that >> the lfb_linelength is correct and use that to calculate the BPP. > > Or reject (some) inconsistencies in the struct screen_info and return > false, so the kernel falls back to e.g. vesa ? > That a reasonable approach too. But better if we can make simpledrm work too since many distros have dropped all the fbdev drivers in favor of it. >> Something like the following patch, which should also fix your regression >> and may be enough to address Thomas' concerns of inconsistent depths too? > > I'll try that patch. > Thanks for all your information and testing with this bug! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote: > > > On 4/13/2023 8:52 AM, Matt Roper wrote: > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > > > Hi Tvrtko, > > > > > > (I forgot to CC Daniele) > > > > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > > > From: Paulo Zanoni > > > > > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > > > > > Although in MTL the GUnit misc interrupts register set are > > > > > available only in GT-0, we need to loop through all the GT's > > > > > in order to initialize the media engine which lies on a different > > > > > GT. > > > > > > > > > > Signed-off-by: Paulo Zanoni > > > > > Cc: Tvrtko Ursulin > > > > > Signed-off-by: Andi Shyti > > > > > --- > > > > > Hi, > > > > > > > > > > proposing again this patch, apparently GuC needs this patch to > > > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > > There are two explanations, one easy and one less easy. > > > > > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > > > > > The second explanation is that in MTL the media engine has it's > > > own set of misc irq's registers and those are on a different GT > > > (Daniele pointed this out). > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; > > it's just a single sgunit register (0x1900e8) that has different > > bitfields for the primary GuC and the media GuC. So I still think we > > should avoid looping over GTs; it's actually much simpler to handle > > things in a single pass since we can just determine the single register > > value once (all fields) and write it directly, instead of doing two > > separate RMW updates to the same register to try to avoid clobbering > > the other GuC's settings. > > > > For pre-MTL platforms, it's the same register, except that the bitfield > > now devoted to the media GuC was previously used for something else > > (scatter/gather). > > It's not just the GuC, the VCS/VECS engine programming is also tied to the > media GT (via the HAS_ENGINE checks). It looks like we unconditionally > program VCS 0 and 2, so it'll still work for MTL, but if we get a device > with more VCS engines it'll break. Maybe we can add a MTL version of the > function that just programs everything unconditionally? Going forward it > should be ok to program things for engines that don't exist, but I'm not > sure we can do that for older platforms that came before the extra engines > were ever defined in HW. Right, so I think the engine handling is already correct for MTL today; the main concern would be how it might need to change for other future platforms if more media engines show back up on a media GT. I think we can wait and cross that bridge if/when we get to it. With focus moving over to the Xe KMD, we might be on a completely different driver by the time the hardware adds back in more media engines that aren't already covered unconditionally. Matt > > Daniele > > > > > > > Matt > > > > > I sent this patch not to bypass any review, but to restart the > > > discussion as this patch was just dropped. > > > > > > Thanks, > > > Andi > > > > > > > > > (*) > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > > > status=0X0 > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > > > [drm] *ERROR* GT1: Enabling uc failed (-5) > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged! > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
Hi Paulo, > https://en.wikipedia.org/wiki/Ship_of_Theseus > > My original patch was written in 2018. Since then, the implementation > has been rebased and changed multiple times, the commit message has > been changed, the subject line has been changed, yet none of that is > documented in the patch's revision history: it was all removed and it > now looks like I'm the author of the version that was submitted this > month. I never liked this "erase the internal patch's changelog before > submitting it upstream for the first time" process, I think it erases > crucial information and misleads people. > > I know I said something different earlier in private, but after further > reflection, I concluded I do not feel comfortable having my name as the > Author or as the Signed-off-by in this patch. Please remove it. You can > add a "Based-on-patch-by: Paulo Zanoni " if > you want, but that's not necessary. > > This should also help in case some bug is bisected to this patch, then > I won't need to spend time researching who I should forward the emails > to. Sure! When porting and back porting patches I try to preserve as much as possible the original authorship. But, if you feel more comfortable, I can take it on me. Andi > Thanks, > Paulo > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > Although in MTL the GUnit misc interrupts register set are > > available only in GT-0, we need to loop through all the GT's > > in order to initialize the media engine which lies on a different > > GT. > > > > Signed-off-by: Paulo Zanoni > > Cc: Tvrtko Ursulin > > Signed-off-by: Andi Shyti
Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated
> p...@panix.com (Pierre Asselin) writes:
>
>> After careful reading of the comments in f35cd3fa7729, would this
>> be an appropriate fix ? Does it still address all the issues raised
>> by Thomas ?
>>
>> (not tested)
>>
>> diff --git a/drivers/firmware/sysfb_simplefb.c
>> b/drivers/firmware/sysfb_simplefb.c
>> index 82c64cb9f531..9f5299d54732 100644
>> --- a/drivers/firmware/sysfb_simplefb.c
>> +++ b/drivers/firmware/sysfb_simplefb.c
>> @@ -56,10 +56,11 @@ __init bool sysfb_parse_mode(const struct
>> screen_info *si,
>> * don't specify alpha channels.
>> */
>> if (si->lfb_depth > 8) {
>> -bits_per_pixel = max(max3(si->red_size + si->red_pos,
>> +bits_per_pixel = max3(max3(si->red_size + si->red_pos,
>>si->green_size + si->green_pos,
>>si->blue_size + si->blue_pos),
>> - si->rsvd_size + si->rsvd_pos);
>> + si->rsvd_size + si->rsvd_pos,
>> + si->lfb_depth);
> I would defer to Thomas but personally I don't like it. Seems to me that
> this is getting too complicated just to workaround buggy BIOS that are not
> reporting consistent information about their firmware-provided
> framebuffer.
Okay, but remember, this is a regression. The buggy BIOSes were there
the whole time and the old code that matched f->bits_per_pixel against
si->lfb_depth used to work against these buggy BIOSes.
And is it a bug, or is it an underspecified standard ? "These bits aren't
reserved, we just ignore them" or some such.
My reading of Thomas' comments in the code was that sometimes lfb_depth
was reported too small but never too large ? But I'm not sure. It's
true in my two cases.
> I would either trust the pixel channel information (what Thomas patch did)
> + my patch to calculate the stride (since we can't trust the line lenght
> which is based on the reported depth) + a DMI table for broken machines.
> But that will only work if your systems are the exception and not a common
> issue, otherwise then Thomas' approach won't work if there are too many
> buggy BIOS out there.
The laptop is ancient but the Dell tower is maybe 4 years old. The
BIOS is 09/11/2019 according to dmidecode, and the most recent for
this box.
> Another option is to do the opposite, not calculate a BPP using the pixel
> and then use that value to calculate a new stride, but instead assume that
> the lfb_linelength is correct and use that to calculate the BPP.
Or reject (some) inconsistencies in the struct screen_info and return
false, so the kernel falls back to e.g. vesa ?
> Something like the following patch, which should also fix your regression
> and may be enough to address Thomas' concerns of inconsistent depths too?
I'll try that patch.
Re: [BUG?] INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 3 jiffies s: 309 root: 0x1/.
On Thu, Apr 13, 2023 at 04:32:32PM +0100, Rui Salvaterra wrote: > Hi, Paul, > > On Thu, 13 Apr 2023 at 15:43, Paul E. McKenney wrote: > > > > My guess would be that you have CONFIG_RCU_EXP_CPU_STALL_TIMEOUT set to > > some small non-zero number, for example, you might have set up a recent > > Android .config or some such. The default of zero would give you about > > 21 seconds rather than the three jiffies that you are seeing. > > > > Could you please check your .config? > > Well, this is embarrassing. I can't fathom why/how, but I had it set > to 20, on this machine. That is, 20 millisseconds. I guess its a > miracle I haven't seen *more* expedited RCU traces. Sorry for the > noise, everyone. Been there, done that! And actually, it is kind of reassuring that the Linux kernel avoids tens-of-milliseocnds latency blows in the common case on your system. Thanx, Paul
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote: > > > On 4/13/2023 8:52 AM, Matt Roper wrote: > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > > > Hi Tvrtko, > > > > > > (I forgot to CC Daniele) > > > > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > > > From: Paulo Zanoni > > > > > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > > > > > Although in MTL the GUnit misc interrupts register set are > > > > > available only in GT-0, we need to loop through all the GT's > > > > > in order to initialize the media engine which lies on a different > > > > > GT. > > > > > > > > > > Signed-off-by: Paulo Zanoni > > > > > Cc: Tvrtko Ursulin > > > > > Signed-off-by: Andi Shyti > > > > > --- > > > > > Hi, > > > > > > > > > > proposing again this patch, apparently GuC needs this patch to > > > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > > There are two explanations, one easy and one less easy. > > > > > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > > > > > The second explanation is that in MTL the media engine has it's > > > own set of misc irq's registers and those are on a different GT > > > (Daniele pointed this out). > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; > > it's just a single sgunit register (0x1900e8) that has different > > bitfields for the primary GuC and the media GuC. So I still think we > > should avoid looping over GTs; it's actually much simpler to handle > > things in a single pass since we can just determine the single register > > value once (all fields) and write it directly, instead of doing two > > separate RMW updates to the same register to try to avoid clobbering > > the other GuC's settings. if we handle exceptions in a single pass wouldn't we have many exceptions to handle in the long run? > > For pre-MTL platforms, it's the same register, except that the bitfield > > now devoted to the media GuC was previously used for something else > > (scatter/gather). > > It's not just the GuC, the VCS/VECS engine programming is also tied to the > media GT (via the HAS_ENGINE checks). It looks like we unconditionally > program VCS 0 and 2, so it'll still work for MTL, but if we get a device > with more VCS engines it'll break. Maybe we can add a MTL version of the > function that just programs everything unconditionally? Going forward it > should be ok to program things for engines that don't exist, but I'm not > sure we can do that for older platforms that came before the extra engines > were ever defined in HW. This is more or less what Tvrtko has suggested, as well. Looks to me like replicating some code... anyway, I will try and see how it looks like. Andi PS Thanks Matt, Daniele and Tvrtko for the feedback. > Daniele > > > > > > > Matt > > > > > I sent this patch not to bypass any review, but to restart the > > > discussion as this patch was just dropped. > > > > > > Thanks, > > > Andi > > > > > > > > > (*) > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > > > status=0X0 > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > > > [drm] *ERROR* GT1: Enabling uc failed (-5) > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 4/13/2023 8:52 AM, Matt Roper wrote: On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: On 13/04/2023 10:20, Andi Shyti wrote: From: Paulo Zanoni In multitile systems IRQ need to be reset and enabled per GT. Although in MTL the GUnit misc interrupts register set are available only in GT-0, we need to loop through all the GT's in order to initialize the media engine which lies on a different GT. Signed-off-by: Paulo Zanoni Cc: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi, proposing again this patch, apparently GuC needs this patch to initialize the media GT. What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; it's just a single sgunit register (0x1900e8) that has different bitfields for the primary GuC and the media GuC. So I still think we should avoid looping over GTs; it's actually much simpler to handle things in a single pass since we can just determine the single register value once (all fields) and write it directly, instead of doing two separate RMW updates to the same register to try to avoid clobbering the other GuC's settings. For pre-MTL platforms, it's the same register, except that the bitfield now devoted to the media GuC was previously used for something else (scatter/gather). It's not just the GuC, the VCS/VECS engine programming is also tied to the media GT (via the HAS_ENGINE checks). It looks like we unconditionally program VCS 0 and 2, so it'll still work for MTL, but if we get a device with more VCS engines it'll break. Maybe we can add a MTL version of the function that just programs everything unconditionally? Going forward it should be ok to program things for engines that don't exist, but I'm not sure we can do that for older platforms that came before the extra engines were ever defined in HW. Daniele Matt I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. Thanks, Andi (*) [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) status=0X0 [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT [drm] *ERROR* GT1: Enabling uc failed (-5) [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
Re: [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, 2023-04-13 at 11:20 +0200, Andi Shyti wrote:
> From: Paulo Zanoni
Hi
https://en.wikipedia.org/wiki/Ship_of_Theseus
My original patch was written in 2018. Since then, the implementation
has been rebased and changed multiple times, the commit message has
been changed, the subject line has been changed, yet none of that is
documented in the patch's revision history: it was all removed and it
now looks like I'm the author of the version that was submitted this
month. I never liked this "erase the internal patch's changelog before
submitting it upstream for the first time" process, I think it erases
crucial information and misleads people.
I know I said something different earlier in private, but after further
reflection, I concluded I do not feel comfortable having my name as the
Author or as the Signed-off-by in this patch. Please remove it. You can
add a "Based-on-patch-by: Paulo Zanoni " if
you want, but that's not necessary.
This should also help in case some bug is bisected to this patch, then
I won't need to spend time researching who I should forward the emails
to.
Thanks,
Paulo
>
> In multitile systems IRQ need to be reset and enabled per GT.
>
> Although in MTL the GUnit misc interrupts register set are
> available only in GT-0, we need to loop through all the GT's
> in order to initialize the media engine which lies on a different
> GT.
>
> Signed-off-by: Paulo Zanoni
> Cc: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> ---
> Hi,
>
> proposing again this patch, apparently GuC needs this patch to
> initialize the media GT.
>
> Andi
>
> Changelog
> =
> v1 -> v2
> - improve description in the commit log.
>
> drivers/gpu/drm/i915/i915_irq.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d24bdea65a3dc..524d64bf5d186 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2764,14 +2764,19 @@ static void dg1_irq_reset(struct drm_i915_private
> *dev_priv)
> {
> struct intel_gt *gt = to_gt(dev_priv);
> struct intel_uncore *uncore = gt->uncore;
> + unsigned int i;
>
>
>
>
> dg1_master_intr_disable(dev_priv->uncore.regs);
>
>
>
>
> - gen11_gt_irq_reset(gt);
> - gen11_display_irq_reset(dev_priv);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_reset(gt);
>
>
>
>
> - GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> - GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + uncore = gt->uncore;
> + GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> + GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + }
> +
> + gen11_display_irq_reset(dev_priv);
> }
>
>
>
>
> void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> @@ -3425,13 +3430,16 @@ static void gen11_irq_postinstall(struct
> drm_i915_private *dev_priv)
>
>
>
>
> static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
> {
> - struct intel_gt *gt = to_gt(dev_priv);
> - struct intel_uncore *uncore = gt->uncore;
> u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> + struct intel_gt *gt;
> + unsigned int i;
>
>
>
>
> - gen11_gt_irq_postinstall(gt);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_postinstall(gt);
>
>
>
>
> - GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
> + GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
> + gu_misc_masked);
> + }
>
>
>
>
> if (HAS_DISPLAY(dev_priv)) {
> icp_irq_postinstall(dev_priv);
> @@ -3440,8 +3448,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
> *dev_priv)
> GEN11_DISPLAY_IRQ_ENABLE);
> }
>
>
>
>
> - dg1_master_intr_enable(uncore->regs);
> - intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
> + dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
> + intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
> }
>
>
>
>
> static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
[PATCH v2] drm/msm/dpu: always program dsc active bits
In current code, the DSC active bits are written only if cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
+ DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On Thu, 13 Apr 2023 at 17:35, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/13 01:44, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote:
> >> Hi,
> >>
> >> On 2023/4/11 22:53, Daniel Vetter wrote:
> >>> On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> We should setting the screen buffer size according to the screen's actual
> size, rather than the size of the GEM object backing the front
> framebuffer.
> The size of GEM buffer is page size aligned, while the size of active
> area
> of a specific screen is *NOT* necessarily page size aliged. For example,
> 1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the damage
> rect
> computed by drm_fb_helper_memory_range_to_clip() goes out of bottom
> bounds
> of the display.
>
> Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 resolution
> will cause the system hang with the following call trace:
>
> Oops: [#1] PREEMPT SMP PTI
> [IGT] fbdev: starting subtest eof
> Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
> [IGT] fbdev: starting subtest nullptr
>
> RIP: 0010:memcpy_erms+0xa/0x20
> RSP: 0018:a17d40167d98 EFLAGS: 00010246
> RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
> RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
> RBP: a17d40167e20 R08: R09: 89522ecff8c0
> R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
> R13: 1a40 R14: 041a R15: a17d40167e30
> FS: () GS:89525738()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
> Call Trace:
>
> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
> drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
> process_one_work+0x21f/0x430
> worker_thread+0x4e/0x3c0
> ? __pfx_worker_thread+0x10/0x10
> kthread+0xf4/0x120
> ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x2c/0x50
>
> CR2: a17d40e0b000
> ---[ end trace ]---
>
> We also add trival code in this patch to restrict the damage rect beyond
> the last line of the framebuffer.
> >>> Nice catch!
> >> :)
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> drivers/gpu/drm/drm_fbdev_generic.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 64458982be40..a2b749372759 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -645,7 +645,7 @@ static void
> drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t off,
> u32 x1 = 0;
> u32 y1 = off / info->fix.line_length;
> u32 x2 = info->var.xres;
> - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
> + u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length),
> info->var.yres);
> >>> So for additional robustness I think it'd be good if we change the entire
> >>> computation here to use drm_framebuffer data and not fb_info data, because
> >>> fundamentally that's what the drm kms code consumes. It should all match
> >>> anyway, but I think it makes the code more obviously correct.
> >>>
> >>> So in the entire function instead of looking at fb_info->fix we should
> >>> probably look at
> >>>
> >>> struct drm_fb_helper *helper = info->par;
> >>>
> >>> And then helper->fb->pitches[0] and helper->fb->height.
> >>>
> >>> If you agree would be great if you can please respin with that (and the
> >>> commit message augmented to explain why we do the change)?
> >> Yes, I'm agree.
> >>
> >> Thank you for guidance, I will refine this patch with `helper = info->par`.
> >>
> >> I will send a v2 when I finished.
> >>
> if ((y2 - y1) == 1) {
> /*
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 8e5148bf40bb..a6daecb5f640 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -95,6 +95,8 @@ static int drm_fbdev_generic_helper_fb_probe(struct
> drm_fb_helper *fb_helper,
> fb_helper->fb = buffer->fb;
> screen_size = buffer->gem->size;
> >>> I guess you forgot to remove this line here?
> >> Yes, this line should be removed in this patch. I overlooked this, sorry.
> >
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > Hi Tvrtko, > > (I forgot to CC Daniele) > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > From: Paulo Zanoni > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > Although in MTL the GUnit misc interrupts register set are > > > available only in GT-0, we need to loop through all the GT's > > > in order to initialize the media engine which lies on a different > > > GT. > > > > > > Signed-off-by: Paulo Zanoni > > > Cc: Tvrtko Ursulin > > > Signed-off-by: Andi Shyti > > > --- > > > Hi, > > > > > > proposing again this patch, apparently GuC needs this patch to > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > There are two explanations, one easy and one less easy. > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > The second explanation is that in MTL the media engine has it's > own set of misc irq's registers and those are on a different GT > (Daniele pointed this out). Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; it's just a single sgunit register (0x1900e8) that has different bitfields for the primary GuC and the media GuC. So I still think we should avoid looping over GTs; it's actually much simpler to handle things in a single pass since we can just determine the single register value once (all fields) and write it directly, instead of doing two separate RMW updates to the same register to try to avoid clobbering the other GuC's settings. For pre-MTL platforms, it's the same register, except that the bitfield now devoted to the media GuC was previously used for something else (scatter/gather). Matt > > I sent this patch not to bypass any review, but to restart the > discussion as this patch was just dropped. > > Thanks, > Andi > > > (*) > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > status=0X0 > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > [drm] *ERROR* GT1: Enabling uc failed (-5) > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged! -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 5:58 AM Tvrtko Ursulin
wrote:
>
>
> On 12/04/2023 20:18, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> >> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >>>
> >>> On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 11/04/2023 23:56, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> v2: Fix typos, change size units to match docs, use div_u64
> >> v3: Do it in core
> >>
> >> Signed-off-by: Rob Clark
> >> Reviewed-by: Emil Velikov
> >> ---
> >>Documentation/gpu/drm-usage-stats.rst | 21
> >>drivers/gpu/drm/drm_file.c| 76
> >> +++
> >>include/drm/drm_file.h| 1 +
> >>include/drm/drm_gem.h | 19 +++
> >>4 files changed, 117 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index b46327356e80..b5e7802532ed 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -105,6 +105,27 @@ object belong to this client, in the respective
> >> memory region.
> >>Default unit shall be bytes with optional unit specifiers of 'KiB'
> >> or 'MiB'
> >>indicating kibi- or mebi-bytes.
> >>
> >> +- drm-shared-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are shared with another file (ie. have
> >> more
> >> +than a single handle).
> >> +
> >> +- drm-private-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are not shared with another file.
> >> +
> >> +- drm-resident-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are resident in system memory.
> >
> > I think this naming maybe does not work best with the existing
> > drm-memory- keys.
>
> Actually, it was very deliberate not to conflict with the existing
> drm-memory- keys ;-)
>
> I wouldn't have preferred drm-memory-{active,resident,...} but it
> could be mis-parsed by existing userspace so my hands were a bit tied.
>
> > How about introduce the concept of a memory region from the start and
> > use naming similar like we do for engines?
> >
> > drm-memory-$CATEGORY-$REGION: ...
> >
> > Then we document a bunch of categories and their semantics, for
> > instance:
> >
> > 'size' - All reachable objects
> > 'shared' - Subset of 'size' with handle_count > 1
> > 'resident' - Objects with backing store
> > 'active' - Objects in use, subset of resident
> > 'purgeable' - Or inactive? Subset of resident.
> >
> > We keep the same semantics as with process memory accounting (if I got
> > it right) which could be desirable for a simplified mental model.
> >
> > (AMD needs to remind me of their 'drm-memory-...' keys semantics. If we
> > correctly captured this in the first round it should be equivalent to
> > 'resident' above. In any case we can document no category is equal to
> > which category, and at most one of the two must be output.)
> >
> > Region names we at most partially standardize. Like we could say
> > 'system' is to be used where backing store is system RAM and others are
> > driver defined.
> >
> > Then discrete GPUs could emit N sets of key-values, one for each memory
> > region they support.
> >
> > I think this all also works for objects which can be migrated between
> > memory regions. 'Size' accounts them against all regions while for
> > 'resident' they only appear in the region of their current placement,
> > etc.
>
> I'm not too sure how to rectify different memory regions with this,
> since drm core doesn't really know about the driver's memory regions.
> Perhaps we can go back to this being a helper and drivers with vram
> just don't use the helper? Or??
> >>>
> >>> I think if you flip it around to drm-$CATEGORY-memory{-$REGION}: then it
> >>> all works out reasonably consistently?
> >>
> >> That is basically what we have now. I could append -system to each to
> >> make things easier to add vram/etc (from a uabi standpoint)..
> >
> > What you have isn't really -system, but everything. So doesn't really make
> > sense to me to mark this -system, it's only really true for integrated (if
> > they don't have stolen or something like that).
> >
> > Also my comment was more in reply to Tvrtko's suggestion.
>
> Right so my proposal was drm-memory-$CATEGORY-$REGION which I think
> aligns with the current drm-memory-$REGION by extending, rather than
> creating confusion with different order of key name c
Re: [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
On Thu, Apr 13, 2023 at 6:07 AM Tvrtko Ursulin
wrote:
>
>
> On 12/04/2023 23:42, Rob Clark wrote:
> > From: Rob Clark
>
> There is more do to here to remove my client->id fully (would now be
> dead code) so maybe easiest if you drop this patch and I do it after you
> land this and it propagates to our branches? I'd like to avoid pain with
> conflicts if possible..
That is fine by me
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/i915/i915_driver.c | 3 ++-
> > drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
> > drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> > 3 files changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index db7a86def7e2..0d91f85f8b97 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops
> > = {
> > .compat_ioctl = i915_ioc32_compat_ioctl,
> > .llseek = noop_llseek,
> > #ifdef CONFIG_PROC_FS
> > - .show_fdinfo = i915_drm_client_fdinfo,
> > + .show_fdinfo = drm_show_fdinfo,
> > #endif
> > };
> >
> > @@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
> > .open = i915_driver_open,
> > .lastclose = i915_driver_lastclose,
> > .postclose = i915_driver_postclose,
> > + .show_fdinfo = i915_drm_client_fdinfo,
> >
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> > b/drivers/gpu/drm/i915/i915_drm_client.c
> > index b09d1d386574..4a77e5e47f79 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.c
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> > @@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx,
> > unsigned int class)
> > }
> >
> > static void
> > -show_client_class(struct seq_file *m,
> > +show_client_class(struct drm_printer *p,
> > struct i915_drm_client *client,
> > unsigned int class)
> > {
> > @@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
> > rcu_read_unlock();
> >
> > if (capacity)
> > - seq_printf(m, "drm-engine-%s:\t%llu ns\n",
> > + drm_printf(p, "drm-engine-%s:\t%llu ns\n",
> > uabi_class_names[class], total);
> >
> > if (capacity > 1)
> > - seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
> > + drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
> > uabi_class_names[class],
> > capacity);
> > }
> >
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
> > {
> > - struct drm_file *file = f->private_data;
> > struct drm_i915_file_private *file_priv = file->driver_priv;
> > struct drm_i915_private *i915 = file_priv->dev_priv;
> > struct i915_drm_client *client = file_priv->client;
> > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > unsigned int i;
> >
> > /*
> > @@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> >* **
> >*/
> >
> > - seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
> > - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
> > -pci_domain_nr(pdev->bus), pdev->bus->number,
> > -PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> > - seq_printf(m, "drm-client-id:\t%u\n", client->id);
> > -
> > /*
> >* Temporarily skip showing client engine information with GuC
> > submission till
> >* fetching engine busyness is implemented in the GuC submission
> > backend
> > @@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> > return;
> >
> > for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> > - show_client_class(m, client, i);
> > + show_client_class(p, client, i);
> > }
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> > b/drivers/gpu/drm/i915/i915_drm_client.h
> > index 69496af996d9..ef85fef45de5 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.h
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> > @@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct
> > i915_drm_client *client)
> > struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients
> > *clients);
> >
> > #ifdef CONFIG_PROC_FS
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
> > #endif
> >
> > void i915_drm_clients_fini(struct i915_drm_clients *clients);
Re: [PATCH 2/5] drm/debugfs: rework debugfs directory creation v3
Hi Christian, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm-intel/for-linux-next drm-intel/for-linux-next-fixes tegra/for-next linus/master v6.3-rc6 next-20230412] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-debugfs-rework-debugfs-directory-creation-v3/20230412-235231 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230412145206.2483-3-christian.koenig%40amd.com patch subject: [PATCH 2/5] drm/debugfs: rework debugfs directory creation v3 config: hexagon-randconfig-r002-20230409 (https://download.01.org/0day-ci/archive/20230413/202304132344.9oz5dfji-...@intel.com/config) compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 9638da200e00bd069e6dd63604e14cbafede9324) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/92a7a4f0fd59d427c5827c323692b76095f90efc git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Christian-K-nig/drm-debugfs-rework-debugfs-directory-creation-v3/20230412-235231 git checkout 92a7a4f0fd59d427c5827c323692b76095f90efc # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202304132344.9oz5dfji-...@intel.com/ All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/drm_drv.c:38: In file included from include/drm/drm_accel.h:11: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:334: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) ^ In file included from drivers/gpu/drm/drm_drv.c:38: In file included from include/drm/drm_accel.h:11: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:334: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) ^ In file included from drivers/gpu/drm/drm_drv.c:38: In file included from include/drm/drm_accel.h:11: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:334: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); ~~ ^ include/asm-gene
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
Hi,
On 2023/4/13 01:44, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote:
Hi,
On 2023/4/11 22:53, Daniel Vetter wrote:
On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
We should setting the screen buffer size according to the screen's actual
size, rather than the size of the GEM object backing the front framebuffer.
The size of GEM buffer is page size aligned, while the size of active area
of a specific screen is *NOT* necessarily page size aliged. For example,
1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the damage rect
computed by drm_fb_helper_memory_range_to_clip() goes out of bottom bounds
of the display.
Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 resolution
will cause the system hang with the following call trace:
Oops: [#1] PREEMPT SMP PTI
[IGT] fbdev: starting subtest eof
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+0xa/0x20
RSP: 0018:a17d40167d98 EFLAGS: 00010246
RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
RBP: a17d40167e20 R08: R09: 89522ecff8c0
R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
R13: 1a40 R14: 041a R15: a17d40167e30
FS: () GS:89525738() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
Call Trace:
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430
worker_thread+0x4e/0x3c0
? __pfx_worker_thread+0x10/0x10
kthread+0xf4/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
CR2: a17d40e0b000
---[ end trace ]---
We also add trival code in this patch to restrict the damage rect beyond
the last line of the framebuffer.
Nice catch!
:)
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_fbdev_generic.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64458982be40..a2b749372759 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -645,7 +645,7 @@ static void drm_fb_helper_memory_range_to_clip(struct
fb_info *info, off_t off,
u32 x1 = 0;
u32 y1 = off / info->fix.line_length;
u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length),
info->var.yres);
So for additional robustness I think it'd be good if we change the entire
computation here to use drm_framebuffer data and not fb_info data, because
fundamentally that's what the drm kms code consumes. It should all match
anyway, but I think it makes the code more obviously correct.
So in the entire function instead of looking at fb_info->fix we should
probably look at
struct drm_fb_helper *helper = info->par;
And then helper->fb->pitches[0] and helper->fb->height.
If you agree would be great if you can please respin with that (and the
commit message augmented to explain why we do the change)?
Yes, I'm agree.
Thank you for guidance, I will refine this patch with `helper = info->par`.
I will send a v2 when I finished.
if ((y2 - y1) == 1) {
/*
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 8e5148bf40bb..a6daecb5f640 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -95,6 +95,8 @@ static int drm_fbdev_generic_helper_fb_probe(struct
drm_fb_helper *fb_helper,
fb_helper->fb = buffer->fb;
screen_size = buffer->gem->size;
I guess you forgot to remove this line here?
Yes, this line should be removed in this patch. I overlooked this, sorry.
Also I'm not understanding
why this matters, I think you're fix only needs the above chunk, not this
one? If I got this right then please drop this part, there's drivers which
only use drm_fb_helper.c but not drm_fbdev_generic.c, and from what I can
tell they all still set the gem buffer size here.
If otoh we need this too, then there's a few more places that need to be
fixed.
I think we need this line, otherwise wrapped around will be happen.
Because I found that the value of variable`y1` will be larger in number than
the variable `y2` by 1,
which are computed in drm_fb_helper_memory_range_to_clip().
This phenomenon will emerged on platforms with large page size or
non page size divisiable display resolution case. Take the LoongArch and
Mips as an example,
th
Re: [PATCH] drm/rockchip: vop2: fix suspend/resume
On Thu, Apr 13, 2023 at 04:43:47PM +0200, Sascha Hauer wrote:
> During a suspend/resume cycle the VO power domain will be disabled and
> the VOP2 registers will reset to their default values. After that the
> cached register values will be out of sync and the read/modify/write
> operations we do on the window registers will result in bogus values
> written. Fix this by re-initializing the register cache each time we
> enable the VOP2. With this the VOP2 will show a picture after a
> suspend/resume cycle whereas without this the screen stays dark.
>
> Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sascha Hauer
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index ba3b817895091..d9daa686b014d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -215,6 +215,8 @@ struct vop2 {
> struct vop2_win win[];
> };
>
> +static const struct regmap_config vop2_regmap_config;
> +
> static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> {
> return container_of(crtc, struct vop2_video_port, crtc);
> @@ -839,6 +841,12 @@ static void vop2_enable(struct vop2 *vop2)
> return;
> }
>
> + ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
> + if (ret) {
> + drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
> + return;
> + }
> +
> if (vop2->data->soc_id == 3566)
> vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
>
> --
> 2.39.2
>
I confirmed this works on my Anbernic RG353P which uses the rk3566 SOC.
Before applying the patch I displayed a color pattern with modetest
before suspend and it appeared correctly. Then I suspended and resumed
the device, attempted to display the same color pattern, and only got
a single pixel on an otherwise blank display. After applying the patch
I performed the same test and the color pattern appeared correctly
both before and after suspend (and the display was no longer blank
after resume from suspend).
Tested-by: Chris Morgan
[PATCH v2] radeon: avoid double free in ci_dpm_init()
Several calls to ci_dpm_fini() will attempt to free resources that
either have been freed before or haven't been allocated yet. This
may lead to undefined or dangerous behaviour.
For instance, if r600_parse_extended_power_table() fails, it might
call r600_free_extended_power_table() as will ci_dpm_fini() later
during error handling.
Fix this by only freeing pointers to objects previously allocated.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
Cc: sta...@vger.kernel.org
Co-developed-by: Natalia Petrova
Signed-off-by: Nikita Zhandarovich
---
v2: free only resouces allocated prior, do not remove ci_dpm_fini()
or other deallocating calls altogether; fix commit message.
v1: https://lore.kernel.org/all/20230403182808.8699-1-n.zhandarov...@fintech.ru/
drivers/gpu/drm/radeon/ci_dpm.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8ef25ab305ae..b8f4dac68d85 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5517,6 +5517,7 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
u8 frev, crev;
u8 *power_state_offset;
struct ci_ps *ps;
+ int ret;
if (!atom_parse_data_header(mode_info->atom_context, index, NULL,
&frev, &crev, &data_offset))
@@ -5546,11 +5547,15 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
&non_clock_info_array->nonClockInfo[non_clock_array_index];
- if (!rdev->pm.power_state[i].clock_info)
- return -EINVAL;
+ if (!rdev->pm.power_state[i].clock_info) {
+ ret = -EINVAL;
+ goto err_free_ps;
+ }
ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL);
- if (ps == NULL)
- return -ENOMEM;
+ if (ps == NULL) {
+ ret = -ENOMEM;
+ goto err_free_ps;
+ }
rdev->pm.dpm.ps[i].ps_priv = ps;
ci_parse_pplib_non_clock_info(rdev, &rdev->pm.dpm.ps[i],
non_clock_info,
@@ -5590,6 +5595,12 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
}
return 0;
+
+err_free_ps:
+ for (i = 0; i < rdev->pm.dpm.num_ps; i++)
+ kfree(rdev->pm.dpm.ps[i].ps_priv);
+ kfree(rdev->pm.dpm.ps);
+ return ret;
}
static int ci_get_vbios_boot_values(struct radeon_device *rdev,
@@ -5678,25 +5689,26 @@ int ci_dpm_init(struct radeon_device *rdev)
ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state);
if (ret) {
- ci_dpm_fini(rdev);
+ kfree(rdev->pm.dpm.priv);
return ret;
}
ret = r600_get_platform_caps(rdev);
if (ret) {
- ci_dpm_fini(rdev);
+ kfree(rdev->pm.dpm.priv);
return ret;
}
ret = r600_parse_extended_power_table(rdev);
if (ret) {
- ci_dpm_fini(rdev);
+ kfree(rdev->pm.dpm.priv);
return ret;
}
ret = ci_parse_power_table(rdev);
if (ret) {
- ci_dpm_fini(rdev);
+ kfree(rdev->pm.dpm.priv);
+ r600_free_extended_power_table(rdev);
return ret;
}
Re: [BUG?] INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 3 jiffies s: 309 root: 0x1/.
On Thu, Apr 13, 2023 at 08:30:02AM +0100, Rui Salvaterra wrote:
> Hi again, everyone.
>
> So, while preparing to file the bug report with the requested
> information, I got a trace completely unrelated to DRM (on a swapon
> call, it seems).
>
> [4.868340] rcu: INFO: rcu_sched detected expedited stalls on
> CPUs/tasks: { 4- } 3 jiffies s: 265 root: 0x10/.
> [4.868349] rcu: blocking rcu_node structures (internal RCU debug):
> [4.868351] Sending NMI from CPU 3 to CPUs 4:
> [4.868355] NMI backtrace for cpu 4
> [4.868357] CPU: 4 PID: 462 Comm: swapon Not tainted 6.3.0-rc6-debug+ #57
> [4.868359] Hardware name: Apple Inc.
> Macmini6,2/Mac-F65AE981FFA204ED, BIOS 429.0.0.0.0 03/18/2022
> [4.868360] RIP: 0010:zram_submit_bio+0x57c/0x940
> [4.868365] Code: 04 4c 01 f0 48 8d 48 08 f0 48 0f ba 68 08 0d 0f
> 82 80 00 00 00 4c 89 ef e8 01 eb ff ff 49 8b 45 00 4a 8d 44 30 09 f0
> 80 20 df 48 ff 45 00 48 81 eb 00 10 00 00 41 83 c4 01 48 81 fb ff
> 0f 00
> [4.868366] RSP: 0018:8881057dbcd8 EFLAGS: 0246
> [4.868368] RAX: c90001c186d9 RBX: 3e893000 RCX:
> c90001c186d8
> [4.868369] RDX: c90001c186d0 RSI: RDI:
> 88810083b400
> [4.868369] RBP: 88810083b470 R08: 00027e40 R09:
> 00025850
> [4.868370] R10: 0014b212 R11: 88810ba03180 R12:
> 000c176d
> [4.868371] R13: 88810083b400 R14: 00c176d0 R15:
>
> [4.868372] FS: 7fbd8f8ce800() GS:88826610()
> knlGS:
> [4.868373] CS: 0010 DS: ES: CR0: 80050033
> [4.868374] CR2: 563005371000 CR3: 00010355c003 CR4:
> 001706e0
> [4.868375] Call Trace:
> [4.868377]
> [4.868378] ? block_read_full_folio+0x23e/0x2e0
> [4.868383] ? kmem_cache_alloc+0x1b/0x110
> [4.868385] ? mempool_alloc+0x37/0x140
> [4.868388] ? pcpu_block_update_hint_alloc+0xce/0x2f0
> [4.868390] __submit_bio+0x41/0xd0
> [4.868394] submit_bio_noacct_nocheck+0xc4/0x2b0
> [4.868396] blk_next_bio+0x55/0x70
> [4.868398] __blkdev_issue_discard+0xc8/0x180
> [4.868401] blkdev_issue_discard+0x3c/0x80
> [4.868403] __x64_sys_swapon+0xb71/0x1120
> [4.868407] do_syscall_64+0x2b/0x50
> [4.868410] entry_SYSCALL_64_after_hwframe+0x46/0xb0
> [4.868414] RIP: 0033:0x7fbd8f712d5b
> [4.868416] Code: 73 01 c3 48 8b 0d bd 30 0e 00 f7 d8 64 89 01 48
> 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 a7 00 00
> 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 30 0e 00 f7 d8 64 89
> 01 48
> [4.868417] RSP: 002b:7ffcaf9a3448 EFLAGS: 0246 ORIG_RAX:
> 00a7
> [4.868418] RAX: ffda RBX: 00018064 RCX:
> 7fbd8f712d5b
> [4.868419] RDX: 00018064 RSI: 00018064 RDI:
> 56300535fb10
> [4.868420] RBP: 7ffcaf9a3530 R08: 00014b213000 R09:
> 7fbd8f7f70f0
> [4.868420] R10: 1000 R11: 0246 R12:
> 56300535fb10
> [4.868421] R13: 0064 R14: 7ffcaf9a3530 R15:
>
> [4.868423]
>
> Could it be that RCU is reporting expedited stalls too eagerly? And,
> if so, why only on this machine?
My guess would be that you have CONFIG_RCU_EXP_CPU_STALL_TIMEOUT set to
some small non-zero number, for example, you might have set up a recent
Android .config or some such. The default of zero would give you about
21 seconds rather than the three jiffies that you are seeing.
Could you please check your .config?
Thanx, Paul
[PATCH] drm/rockchip: vop2: fix suspend/resume
During a suspend/resume cycle the VO power domain will be disabled and
the VOP2 registers will reset to their default values. After that the
cached register values will be out of sync and the read/modify/write
operations we do on the window registers will result in bogus values
written. Fix this by re-initializing the register cache each time we
enable the VOP2. With this the VOP2 will show a picture after a
suspend/resume cycle whereas without this the screen stays dark.
Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index ba3b817895091..d9daa686b014d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -215,6 +215,8 @@ struct vop2 {
struct vop2_win win[];
};
+static const struct regmap_config vop2_regmap_config;
+
static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
{
return container_of(crtc, struct vop2_video_port, crtc);
@@ -839,6 +841,12 @@ static void vop2_enable(struct vop2 *vop2)
return;
}
+ ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
+ if (ret) {
+ drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
+ return;
+ }
+
if (vop2->data->soc_id == 3566)
vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
--
2.39.2
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 13/04/2023 14:56, Andi Shyti wrote: Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: On 13/04/2023 10:20, Andi Shyti wrote: From: Paulo Zanoni In multitile systems IRQ need to be reset and enabled per GT. Although in MTL the GUnit misc interrupts register set are available only in GT-0, we need to loop through all the GT's in order to initialize the media engine which lies on a different GT. Signed-off-by: Paulo Zanoni Cc: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi, proposing again this patch, apparently GuC needs this patch to initialize the media GT. What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. I see. It does not sound too challenging to handle with a little bit of refactoring. Move writes engine registers to a helper and add a MTL specific reset/postinstall? Then MTL can do the engine ones outside the for_each_gt loop and the replicated ones under it. Give or take, I did not look into the details. Regards, Tvrtko
Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
Hi Suraj, On 07/04/2023 06:11, Kandpal, Suraj wrote: Hi Dmitry -Original Message- From: Dmitry Baryshkov Sent: Friday, April 7, 2023 8:28 AM To: Kandpal, Suraj ; Jani Nikula ; dri-devel@lists.freedesktop.org; intel- g...@lists.freedesktop.org Cc: Nautiyal, Ankit K ; Shankar, Uma ; Maarten Lankhorst Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC Hi Suraj On 28/03/2023 16:20, Kandpal, Suraj wrote: -Original Message- From: dri-devel On Behalf Of Jani Nikula Sent: Wednesday, March 8, 2023 5:00 PM To: Kandpal, Suraj ; dri- de...@lists.freedesktop.org; intel-...@lists.freedesktop.org Cc: Dmitry Baryshkov ; Nautiyal, Ankit K ; Shankar, Uma ; Kandpal, Suraj Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC On Wed, 22 Feb 2023, Suraj Kandpal wrote: This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. There have been discussions prior to this series in which some patches have gotten rb and can be found in the below link https://patchwork.freedesktop.org/series/113729 I think it would be useful to get [1] from Dmitry merged to drm-misc-next first, have that in drm-next, and again backmerged to drm-intel-next before this. At least patches 1-5. There's not much point in all drivers duplicating the parameters, and we need to move towards common code. Dmitry has been helpful in contributing this to us. BR, Jani. Hi Jani, Maarten has acked the patch series to be merged through drm-intel and in the meantime I will work with Dmitry to pull the common code to avoid duplication I wanted to check, are there any updates from your side regarding the series at [1] ? Will have a look and float comments if any by Monday Please excuse me for being slightly stubborn here. We are slowly getting other patches piled up with dependency on this series. It is fine that it doesn't get into 6.4 (which it probably definitely missed by now), but we would like to know if we have to redo/update anything or if it is fine as is and it is going to be merged by i915 in 6.5 cycle. Thank you for the understanding. Regards, Suraj Kandpal [1] https://patchwork.freedesktop.org/series/114473/ -- With best wishes Dmitry Regards, Suraj Kandpal -- With best wishes Dmitry
Re: [RFC PATCH v2 2/2] dt-bindings: gpu: Add Imagination Technologies PowerVR GPU
On 13/04/2023 12:34, Sarah Walker wrote:
> Signed-off-by: Sarah Walker
NAK, multiple problems.
Missing commit msg.
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
Missing tests - not CCed to proper lists.
> ---
> .../devicetree/bindings/gpu/img,powervr.yaml | 105 ++
> 1 file changed, 105 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> new file mode 100644
> index ..f722fd1d4e8f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR MIT)
> +# Copyright (c) 2022 Imagination Technologies Ltd.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/gpu/img-powervr.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
Drop quotes.
> +
> +title: Imagination Technologies PowerVR GPU
> +
> +maintainers:
> + - Sarah Walker
> +
> +properties:
> + compatible:
> +oneOf:
> + - items:
> + - enum:
> + - mediatek,mt8173-gpu
> + - const: img,powervr-series6xt
> + - items:
> + - enum:
> + - ti,am62-gpu
> + - const: img,powervr-seriesaxe
> +
> + reg:
> +minItems: 1
Drop minItems.
> +maxItems: 1
> +
> + clocks:
> +minItems: 1> +maxItems: 3
> +
> + clock-names:
> +items:
> + - const: core_clk
> + - const: mem_clk
> + - const: sys_clk
Drop _clk suffixes.
> +
> + interrupts:
> +items:
> + - description: GPU interrupt
> +
> + interrupt-names:
> +items:
> + - const: gpu
> +
> + power-domains:
> +maxItems: 1
> +
> + operating-points-v2: true
No opp-table?
> + power-supply: true
> +
> + "#cooling-cells":
> +const: 2
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: mediatek,mt8173-gpu
> +then:
> + properties:
> +reg:
> + minItems: 2
> + maxItems: 2
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: img,powervr-series6xt
> +then:
> + properties:
> +clocks:
> + minItems: 3
This is really not tested... Misisng additionalProperties:false.
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +gpu@1300 {
> +compatible = "mediatek,mt8173-gpu", "img,powervr-series6xt";
> +reg = <0 0x1300 0 0x>, <0 0x13fff000 0 0x1000>;
> +power-domains = <&scpsys MT8173_POWER_DOMAIN_MFG>;
> +power-supply = <&da9211_vgpu_reg>;
> +operating-points-v2 = <&gpu_opp_table>;
> +clocks = <&gpu_ckgen 0>,
> + <&gpu_ckgen 1>,
> + <&gpu_ckgen 2>;
> +clock-names = "core_clk",
> + "mem_clk",
> + "sys_clk";
> +interrupts = ;
> +interrupt-names = "gpu";
> +};
> +
Stray blank line.
Best regards,
Krzysztof
[PATCH v2] video/hdmi: minor fixes for *_infoframe_init functions
Multiple hdmi_*_infoframe_init() functions that initialize different
types of hdmi infoframes only return default 0 value (contrary to their
descriptions). Yet these functions are still checked against possible
errors in case of failure.
This patch removes redundant checks for errors in calls to following
functions:
- hdmi_spd_infoframe_init
- hdmi_audio_infoframe_init
- hdmi_vendor_infoframe_init
- hdmi_drm_infoframe_init
Also, change their return types to void and fix descriptions.
Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
InfoFrames")
Signed-off-by: Nikita Zhandarovich
---
v2: Fix build warning by removing unnecessary call to drm_WARN_ON()
with uninitialized value.
Reported-by: kernel test robot
Link:
https://lore.kernel.org/oe-kbuild-all/202304131234.ht3mzkju-...@intel.com/
drivers/gpu/drm/display/drm_hdmi_helper.c | 5 +---
drivers/gpu/drm/drm_edid.c| 5 +---
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 +--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 14 ++
drivers/gpu/drm/radeon/r600_hdmi.c
drivers/gpu/drm/display/drm_hdmi_helper.c | 5 +---
drivers/gpu/drm/drm_edid.c| 5 +---
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 ++---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 14 ++
drivers/gpu/drm/radeon/r600_hdmi.c| 6 +
drivers/gpu/drm/sti/sti_hdmi.c| 6 +
drivers/gpu/drm/tegra/hdmi.c | 7 +
drivers/gpu/drm/tegra/sor.c | 6 +
drivers/gpu/drm/vc4/vc4_hdmi.c| 7 +
drivers/video/hdmi.c | 44 ++-
include/linux/hdmi.h | 8 +++---
11 files changed, 23 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index faf5e9efa7d3..ce7038a3a183 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -27,7 +27,6 @@ int drm_hdmi_infoframe_set_hdr_metadata(struct
hdmi_drm_infoframe *frame,
{
struct drm_connector *connector;
struct hdr_output_metadata *hdr_metadata;
- int err;
if (!frame || !conn_state)
return -EINVAL;
@@ -47,9 +46,7 @@ int drm_hdmi_infoframe_set_hdr_metadata(struct
hdmi_drm_infoframe *frame,
connector->hdr_sink_metadata.hdmi_type1.eotf))
DRM_DEBUG_KMS("Unknown EOTF %d\n",
hdr_metadata->hdmi_metadata_type1.eotf);
- err = hdmi_drm_infoframe_init(frame);
- if (err < 0)
- return err;
+ hdmi_drm_infoframe_init(frame);
frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
frame->metadata_type = hdr_metadata->hdmi_metadata_type1.metadata_type;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 261a62e15934..c268148502d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -7159,7 +7159,6 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
*/
bool has_hdmi_infoframe = connector ?
connector->display_info.has_hdmi_infoframe : false;
- int err;
if (!frame || !mode)
return -EINVAL;
@@ -7167,9 +7166,7 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
if (!has_hdmi_infoframe)
return -EINVAL;
- err = hdmi_vendor_infoframe_init(frame);
- if (err < 0)
- return err;
+ hdmi_vendor_infoframe_init(frame);
/*
* Even if it's not absolutely necessary to send the infoframe
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c0ce6d3dc505..59e2f53015c0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -778,12 +778,9 @@ intel_hdmi_compute_spd_infoframe(struct intel_encoder
*encoder,
intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_SPD);
if (IS_DGFX(i915))
- ret = hdmi_spd_infoframe_init(frame, "Intel", "Discrete gfx");
+ hdmi_spd_infoframe_init(frame, "Intel", "Discrete gfx");
else
- ret = hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx");
-
- if (drm_WARN_ON(encoder->base.dev, ret))
- return false;
+ hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx");
frame->sdi = HDMI_SPD_SDI_PC;
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a8e0a13f516..75899e4a011f 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -995,12 +995,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct mtk_hdmi
*hdmi,
u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_SPD_INFOFRAME_SIZE];
ssize_t err;
- err = hdmi_spd_infoframe_init(&frame,
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > On 13/04/2023 10:20, Andi Shyti wrote: > > From: Paulo Zanoni > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > Although in MTL the GUnit misc interrupts register set are > > available only in GT-0, we need to loop through all the GT's > > in order to initialize the media engine which lies on a different > > GT. > > > > Signed-off-by: Paulo Zanoni > > Cc: Tvrtko Ursulin > > Signed-off-by: Andi Shyti > > --- > > Hi, > > > > proposing again this patch, apparently GuC needs this patch to > > initialize the media GT. > > What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. Thanks, Andi (*) [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) status=0X0 [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT [drm] *ERROR* GT1: Enabling uc failed (-5) [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
Re: [PATCH 3/5] drm/debugfs: remove dev->debugfs_list and debugfs_mutex v2
On Thu, Apr 13, 2023 at 11:34:45AM +0200, Christian König wrote:
> Am 12.04.23 um 17:11 schrieb Daniel Vetter:
> > On Wed, Apr 12, 2023 at 04:52:04PM +0200, Christian König wrote:
> > > The mutex was completely pointless in the first place since any
> > > parallel adding of files to this list would result in random
> > > behavior since the list is filled and consumed multiple times.
> > >
> > > Completely drop that approach and just create the files directly but
> > > return -ENODEV while opening the file when the minors are not
> > > registered yet.
> > This part seems to be missing?
>
> I wanted to move this into a separate patch and then forgot to add it. Going
> to fix that.
>
> > The other issue is that partial driver load cleanup now goes boom I think,
> > you need to both remove them all in _unregister but also in final drm_dev
> > cleanup. Or I'm missing how this works. Maybe you could also use drmm_ for
> > that to make sure it's always done.
>
> Good point. Should we call the cleanup function from both the unregister and
> the final drm_dev cleanup or just the later?
I think both:
- unregister to make sure userspace can't access the files when the driver
is unloading, because the _remove() is the only thing that actually
synchronizes with parallel read/write() and waits for those to finish.
Really don't want to hand-roll that, it's a lot more tricky than the
"are we registered already" check :-)
- As cleanup for the case we never registered, and hence
drm_dev_unregister wont be called.
I guess if you make both the exact same function and that unconditionally
(any checks needed within that function) it hopefully aviods the
not-registered error path from bitrotting.
-Daniel
>
> Thanks,
> Christian.
>
> >
> > There shouldn't be a race as long as the "are we registered yet" check is
> > there, since in that case the driver never registered. So no problems
> > trying to access the files when they could try to access things which are
> > already cleaned up.
> >
> > I think with those details ironed out this makes some sense to me,
> > assuming I understood it correctly.
> >
> > > v2: rebase on debugfs directory rework, limit access before minors are
> > > registered.
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/gpu/drm/drm_debugfs.c | 27 ++-
> > > drivers/gpu/drm/drm_drv.c | 3 ---
> > > drivers/gpu/drm/drm_internal.h| 5 -
> > > drivers/gpu/drm/drm_mode_config.c | 2 --
> > > include/drm/drm_device.h | 15 ---
> > > 5 files changed, 2 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> > > index 59c3d76d28f4..427c5eb4eca0 100644
> > > --- a/drivers/gpu/drm/drm_debugfs.c
> > > +++ b/drivers/gpu/drm/drm_debugfs.c
> > > @@ -245,7 +245,6 @@ int drm_debugfs_register(struct drm_minor *minor, int
> > > minor_id,
> > >struct dentry *root)
> > > {
> > > struct drm_device *dev = minor->dev;
> > > - struct drm_debugfs_entry *entry, *tmp;
> > > char name[64];
> > > INIT_LIST_HEAD(&minor->debugfs_list);
> > > @@ -260,30 +259,9 @@ int drm_debugfs_register(struct drm_minor *minor,
> > > int minor_id,
> > > if (dev->driver->debugfs_init && dev->render != minor)
> > > dev->driver->debugfs_init(minor);
> > > - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> > > - debugfs_create_file(entry->file.name, 0444,
> > > - minor->debugfs_root, entry,
> > > &drm_debugfs_entry_fops);
> > > - list_del(&entry->list);
> > > - }
> > > -
> > > return 0;
> > > }
> > > -void drm_debugfs_late_register(struct drm_device *dev)
> > > -{
> > > - struct drm_minor *minor = dev->primary;
> > > - struct drm_debugfs_entry *entry, *tmp;
> > > -
> > > - if (!minor)
> > > - return;
> > > -
> > > - list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
> > > - debugfs_create_file(entry->file.name, 0444,
> > > - minor->debugfs_root, entry,
> > > &drm_debugfs_entry_fops);
> > > - list_del(&entry->list);
> > > - }
> > > -}
> > > -
> > > int drm_debugfs_remove_files(const struct drm_info_list *files, int
> > > count,
> > >struct drm_minor *minor)
> > > {
> > > @@ -353,9 +331,8 @@ void drm_debugfs_add_file(struct drm_device *dev,
> > > const char *name,
> > > entry->file.data = data;
> > > entry->dev = dev;
> > > - mutex_lock(&dev->debugfs_mutex);
> > > - list_add(&entry->list, &dev->debugfs_list);
> > > - mutex_unlock(&dev->debugfs_mutex);
> > > + debugfs_create_file(name, 0444, dev->debugfs_root, entry,
> > > + &drm_debugfs_entry_fops);
> > > }
> > > EXPORT_SYMBOL(drm_debugfs_add_file);
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_d
Re: [PATCH] drm/stm: ltdc: fix late dereference check
Hi Raphael,
thanks for the patch.
Reviewed-by: Yannick Fertre
On 4/12/23 11:25, Raphael GALLAIS-POU wrote:
Attention: Sender not authenticated
--
In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a
container_of() before the pointer check. This could cause a kernel panic.
Fix this smatch warning:
drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable
dereferenced before check 'crtc' (see line 1119)
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Link: https://lore.kernel.org/lkml/202212241802.zelfzcxb-...@intel.com/
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/ltdc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 03c6becda795..b8be4c1db423 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1145,7 +1145,7 @@ static void ltdc_crtc_disable_vblank(struct drm_crtc
*crtc)
static int ltdc_crtc_set_crc_source(struct drm_crtc *crtc, const char *source)
{
- struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct ltdc_device *ldev;
int ret;
DRM_DEBUG_DRIVER("\n");
@@ -1153,6 +1153,8 @@ static int ltdc_crtc_set_crc_source(struct drm_crtc
*crtc, const char *source)
if (!crtc)
return -ENODEV;
+ ldev = crtc_to_ltdc(crtc);
+
if (source && strcmp(source, "auto") == 0) {
ldev->crc_active = true;
ret = regmap_set_bits(ldev->regmap, LTDC_GCR, GCR_CRCEN);
--
2.25.1
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 20:18, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> > > On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> > > >
> > > > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > > > > From: Rob Clark
> > > > > > >
> > > > > > > Add support to dump GEM stats to fdinfo.
> > > > > > >
> > > > > > > v2: Fix typos, change size units to match docs, use div_u64
> > > > > > > v3: Do it in core
> > > > > > >
> > > > > > > Signed-off-by: Rob Clark
> > > > > > > Reviewed-by: Emil Velikov
> > > > > > > ---
> > > > > > >Documentation/gpu/drm-usage-stats.rst | 21
> > > > > > >drivers/gpu/drm/drm_file.c| 76
> > > > > > > +++
> > > > > > >include/drm/drm_file.h| 1 +
> > > > > > >include/drm/drm_gem.h | 19 +++
> > > > > > >4 files changed, 117 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > index b46327356e80..b5e7802532ed 100644
> > > > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > @@ -105,6 +105,27 @@ object belong to this client, in the
> > > > > > > respective memory region.
> > > > > > >Default unit shall be bytes with optional unit specifiers of
> > > > > > > 'KiB' or 'MiB'
> > > > > > >indicating kibi- or mebi-bytes.
> > > > > > >
> > > > > > > +- drm-shared-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are shared with another file (ie.
> > > > > > > have more
> > > > > > > +than a single handle).
> > > > > > > +
> > > > > > > +- drm-private-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are not shared with another file.
> > > > > > > +
> > > > > > > +- drm-resident-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are resident in system memory.
> > > > > >
> > > > > > I think this naming maybe does not work best with the existing
> > > > > > drm-memory- keys.
> > > > >
> > > > > Actually, it was very deliberate not to conflict with the existing
> > > > > drm-memory- keys ;-)
> > > > >
> > > > > I wouldn't have preferred drm-memory-{active,resident,...} but it
> > > > > could be mis-parsed by existing userspace so my hands were a bit tied.
> > > > >
> > > > > > How about introduce the concept of a memory region from the start
> > > > > > and
> > > > > > use naming similar like we do for engines?
> > > > > >
> > > > > > drm-memory-$CATEGORY-$REGION: ...
> > > > > >
> > > > > > Then we document a bunch of categories and their semantics, for
> > > > > > instance:
> > > > > >
> > > > > > 'size' - All reachable objects
> > > > > > 'shared' - Subset of 'size' with handle_count > 1
> > > > > > 'resident' - Objects with backing store
> > > > > > 'active' - Objects in use, subset of resident
> > > > > > 'purgeable' - Or inactive? Subset of resident.
> > > > > >
> > > > > > We keep the same semantics as with process memory accounting (if I
> > > > > > got
> > > > > > it right) which could be desirable for a simplified mental model.
> > > > > >
> > > > > > (AMD needs to remind me of their 'drm-memory-...' keys semantics.
> > > > > > If we
> > > > > > correctly captured this in the first round it should be equivalent
> > > > > > to
> > > > > > 'resident' above. In any case we can document no category is equal
> > > > > > to
> > > > > > which category, and at most one of the two must be output.)
> > > > > >
> > > > > > Region names we at most partially standardize. Like we could say
> > > > > > 'system' is to be used where backing store is system RAM and others
> > > > > > are
> > > > > > driver defined.
> > > > > >
> > > > > > Then discrete GPUs could emit N sets of key-values, one for each
> > > > > > memory
> > > > > > region they support.
> > > > > >
> > > > > > I think this all also works for objects which can be migrated
> > > > > > between
> > > > > > memory regions. 'Size' accounts them against all regions while for
> > > > > > 'resident' they only appear in the region of their current
> > > > > > placement, etc.
> > > > >
> > > > > I'm not too sure how to rectify different memory regions with this,
> > > > > since drm core doesn't really know about the driver's memory regions.
> > > > > Perhaps we can go back to this being a helper and drivers with vram
> > > > > just don't use the helper? Or??
> > > >
> > > > I think if you flip it around to drm-$CATEGORY-memory{-$REGION}: then it
> > > > all works out reasonably consistently?
> > >
> > > That is basically what we have now. I could append -system to ea
Re: [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
On Thu, 13 Apr 2023 at 11:46, Christian König wrote: > > Am 13.04.23 um 10:48 schrieb Daniel Vetter: > > On Wed, 12 Apr 2023 at 16:18, Christian König > > wrote: > >> Am 12.04.23 um 11:08 schrieb Daniel Vetter: > >>> On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote: > On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote: > > Am 11.04.23 um 11:51 schrieb Daniel Vetter: > >> On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote: > >>> When swapping out, we will split multi-order pages both in order to > >>> move them to the swap-cache and to be able to return memory to the > >>> swap cache as soon as possible on a page-by-page basis. > >>> Reduce the page max order to the system PMD size, as we can then be > >>> nicer > >>> to the system and avoid splitting gigantic pages. > >>> > >>> Looking forward to when we might be able to swap out PMD size folios > >>> without splitting, this will also be a benefit. > >>> > >>> v2: > >>> - Include all orders up to the PMD size (Christian König) > >>> v3: > >>> - Avoid compilation errors for architectures with special PFN_SHIFTs > >>> > >>> Signed-off-by: Thomas Hellström > >>> Reviewed-by: Christian König > >> Apparently this fails on ppc build testing. Please supply build fix > >> asap > >> (or I guess we need to revert). I'm kinda not clear why this only > >> showed > >> up when I merged the drm-misc-next pr into drm-next ... > > I'm really wondering this as well. It looks like PMD_SHIFT isn't a > > constant > > on this particular platform. > > > > But from what I can find in the upstream 6.2 kernel PMD_SHIFT always > > seems > > to be a constant. > > > > So how exactly can that here break? > There's some in-flight patches to rework MAX_ORDER and other things in > linux-next, maybe it's recent? If you check out linux-next then you need > to reapply the patch (since sfr reverted it). > >>> So I looked and on ppc64 PMD_SHIFT is defined in terms of > >>> PTE_INDEX_SIZE, which is defined (for book3s) in terms of the variable > >>> __pte_index_size. This is in 6.3 already and seems pretty old. > >> Ah! I missed that one, thanks. > >> > >>> So revert? Or fixup patch to make this work on ppc? > >> I think for now just revert or change it so that we check if PMD_SHIFT > >> is a constant. > >> > >> Thomas do you have any quick solution? > > I guess Thomas is on vacations. Can you pls do the revert and push it > > to drm-misc-next-fixes so this won't get lost? > > The offending patch hasn't showed up in drm-misc-next-fixes nor > drm-misc-fixes yet. Looks like the branches are lacking behind. > > I can revert it on drm-misc-next, but I', not 100% sure that will then > get picked up in time. It's there now, Maarten forwarded drm-misc-next-fixes this morning. That's why I pinged here again, trees are ready to land the revert :-) -Daniel > > Christian. > > > > > Acked-by: Daniel Vetter > > > > preemptively for that. Normally I think we could wait a bit more but > > it's really close to merge window PR and I don't like handing too many > > open things to Dave when he's back :-) > > -Daniel > > > >> Christian. > >> > >>> > >>> --- > >>> drivers/gpu/drm/ttm/ttm_pool.c | 30 +++--- > >>> 1 file changed, 19 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c > >>> b/drivers/gpu/drm/ttm/ttm_pool.c > >>> index dfce896c4bae..18c342a919a2 100644 > >>> --- a/drivers/gpu/drm/ttm/ttm_pool.c > >>> +++ b/drivers/gpu/drm/ttm/ttm_pool.c > >>> @@ -47,6 +47,11 @@ > >>> #include "ttm_module.h" > >>> +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT) > >>> +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1) > >>> +/* Some architectures have a weird PMD_SHIFT */ > >>> +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? > >>> __TTM_DIM_ORDER : MAX_ORDER) > >>> + > >>> /** > >>> * struct ttm_pool_dma - Helper object for coherent DMA mappings > >>> * > >>> @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644); > >>> static atomic_long_t allocated_pages; > >>> -static struct ttm_pool_type global_write_combined[MAX_ORDER]; > >>> -static struct ttm_pool_type global_uncached[MAX_ORDER]; > >>> +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER]; > >>> +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER]; > >>> -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER]; > >>> -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER]; > >>> +static struct ttm_pool_type > >>> global_dma32_write_combined[TTM_DIM_ORDER]; > >>> +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER]; > >>> static spinlock_t shrinker_lock; > >>> static struct list_head shrinke
Re: [PULL] drm-intel-fixes
On Thu, Apr 13, 2023 at 10:13:57AM +0300, Jani Nikula wrote: > > Hi Dave & Daniel - > > One DSI fix, stable material. > > drm-intel-fixes-2023-04-13: > drm/i915 fixes for v6.3-rc7: > - Fix dual link DSI for TGL+ > > BR, > Jani. > > The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: > > Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-04-13 Pulled, thanks > > for you to fetch changes up to 6b8446859c971a5783a2cdc90adf32e64de3bd23: > > drm/i915/dsi: fix DSS CTL register offsets for TGL+ (2023-04-11 11:41:57 > +0300) > > > drm/i915 fixes for v6.3-rc7: > - Fix dual link DSI for TGL+ > > > Jani Nikula (1): > drm/i915/dsi: fix DSS CTL register offsets for TGL+ > > drivers/gpu/drm/i915/display/icl_dsi.c | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
On 12/04/2023 23:42, Rob Clark wrote:
From: Rob Clark
There is more do to here to remove my client->id fully (would now be
dead code) so maybe easiest if you drop this patch and I do it after you
land this and it propagates to our branches? I'd like to avoid pain with
conflicts if possible..
Regards,
Tvrtko
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index db7a86def7e2..0d91f85f8b97 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
#ifdef CONFIG_PROC_FS
- .show_fdinfo = i915_drm_client_fdinfo,
+ .show_fdinfo = drm_show_fdinfo,
#endif
};
@@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+ .show_fdinfo = i915_drm_client_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..4a77e5e47f79 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned
int class)
}
static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
struct i915_drm_client *client,
unsigned int class)
{
@@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
rcu_read_unlock();
if (capacity)
- seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ drm_printf(p, "drm-engine-%s:\t%llu ns\n",
uabi_class_names[class], total);
if (capacity > 1)
- seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
+ drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
uabi_class_names[class],
capacity);
}
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
{
- struct drm_file *file = f->private_data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_drm_client *client = file_priv->client;
- struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int i;
/*
@@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
file *f)
* **
*/
- seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
- seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
- pci_domain_nr(pdev->bus), pdev->bus->number,
- PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
- seq_printf(m, "drm-client-id:\t%u\n", client->id);
-
/*
* Temporarily skip showing client engine information with GuC
submission till
* fetching engine busyness is implemented in the GuC submission backend
@@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file
*f)
return;
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
- show_client_class(m, client, i);
+ show_client_class(p, client, i);
}
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..ef85fef45de5 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct i915_drm_client
*client)
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
#ifdef CONFIG_PROC_FS
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
#endif
void i915_drm_clients_fini(struct i915_drm_clients *clients);
Re: [PATCH v4 1/6] drm: Add common fdinfo helper
On 13/04/2023 09:46, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 10:07:11AM +0200, Christian König wrote:
Am 13.04.23 um 00:42 schrieb Rob Clark:
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 10 +++-
drivers/gpu/drm/drm_file.c| 35 +++
include/drm/drm_drv.h | 7 ++
include/drm/drm_file.h| 4 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..2ab32c40e93c 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -126,7 +126,15 @@ percentage utilization of the engine, whereas
drm-engine- only reflects
time active without considering what frequency the engine is operating as a
percentage of it's maximum frequency.
+Implementation Details
+==
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement &drm_driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo(). But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
I'm really wondering if it wouldn't be less mid-layering if we let the
drivers call the drm function to print the common values instead of the
other way around?
The idea is that we plug this into DRM_GEM_FOPS and then everyone gets it
by default. So it's a bit a tradeoff between midlayering and having
inconsistent uapi between drivers. And there's generic tools that parse
this, so consistency across drivers is good.
My gut feeling was that after a bit of experimenting with lots of
different drivers for fdinfo stuff it's time to push for a bit more
standardization and less fragmentation.
We can of course later on course-correct and shuffle things around again,
e.g. by pushing more things into the gem_bo_fops->status hook (ttm and
other memory manager libs could implement a decent one by default), or
moving more into the drm_driver->show_fdinfo callback again.
If you look at kms we also shuffle things back&forth between core (for
more consistency) and drivers (for more flexibility where needed).
The important part here imo is that we start with some scaffolding to be
able to do this. Like another thing that I think we want is some
drm_fdinfo_print functions that make sure the formatting is guaranteed
consistents and we don't trip up parsers (like some drivers use " \t" as
separator instead of just "\t", I guess by accident).
On this particular part I'd say it's even better to keep userspace on
their toes and not let them hardcode assumption about how much and what
whitespace characters to expect.
Otherwise I agree that mid-layer or not can be changed later, as long as
my opens from elsewhere in the thread are closed before merging.
Regards,
Tvrtko
Apart from thatquestion the patch looks good to me.
Ack? Or want the above recorded in the commit message, I think it'd make
sense to put it there.
-Daniel
Christian.
+
Driver specific implementations
-===
+---
:ref:`i915-usage-stats`
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..6d5bdd684ae2 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
*/
struct drm_file *drm_file_alloc(struct drm_minor *minor)
{
+ static atomic64_t ident = ATOMIC_INIT(0);
struct drm_device *dev = minor->dev;
struct drm_file *file;
int ret;
@@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
+ /* Get a unique identifier for fdinfo: */
+ file->client_id = atomic64_inc_return(&ident);
file->pid = get_pid(task_pid(current));
file->minor = minor;
@@ -868,6 +871,38 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+/**
+ * drm_show_fdinfo - helper for drm file fops
+ * @seq_file: output stream
+ * @f: the device file instance
+ *
+ * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
+ * process using the GPU. See also &drm_driver.show_fdinfo.
+ *
+ * For text output format description please see
Documentation/gpu/drm-usage-stats.rst
+ */
+void drm_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_device *dev = file->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(&p, "drm-driver:
Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
+ Wayne
On Thu, Apr 13, 2023 at 8:31 AM Jani Nikula wrote:
>
> On Thu, 13 Apr 2023, Jeff Layton wrote:
> > I've been experiencing some intermittent crashes down in the display
> > driver code. The symptoms are ususally a line like this in dmesg:
> >
> > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > 6d3a3885: -5
> >
> > ...followed by an Oops due to a NULL pointer dereference.
> >
> > The real bug is probably in the caller of this function, which is
> > passing it a NULL state pointer, but this patch at least keeps my
> > machine from oopsing when this occurs.
>
> My fear is that papering over this makes the root cause harder to find.
>
> Cc: Harry, Alex
>
>
> BR,
> Jani.
>
>
> >
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > Signed-off-by: Jeff Layton
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 38dab76ae69e..87ad406c50f9 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> > drm_dp_mst_topology_mgr *mgr,
> >
> > /* Skip failed payloads */
> > if (payload->vc_start_slot == -1) {
> > - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> > failed, skipping part 2\n",
> > + drm_dbg_kms(state ? state->dev : NULL,
> > + "Part 1 of payload creation for %s failed,
> > skipping part 2\n",
> > payload->port->connector->name);
> > return -EIO;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On 12/04/2023 20:18, Daniel Vetter wrote:
On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
wrote:
On 11/04/2023 23:56, Rob Clark wrote:
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
Documentation/gpu/drm-usage-stats.rst | 21
drivers/gpu/drm/drm_file.c| 76 +++
include/drm/drm_file.h| 1 +
include/drm/drm_gem.h | 19 +++
4 files changed, 117 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..b5e7802532ed 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,6 +105,27 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-shared-memory: [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-private-memory: [KiB|MiB]
+
+The total size of buffers that are not shared with another file.
+
+- drm-resident-memory: [KiB|MiB]
+
+The total size of buffers that are resident in system memory.
I think this naming maybe does not work best with the existing
drm-memory- keys.
Actually, it was very deliberate not to conflict with the existing
drm-memory- keys ;-)
I wouldn't have preferred drm-memory-{active,resident,...} but it
could be mis-parsed by existing userspace so my hands were a bit tied.
How about introduce the concept of a memory region from the start and
use naming similar like we do for engines?
drm-memory-$CATEGORY-$REGION: ...
Then we document a bunch of categories and their semantics, for instance:
'size' - All reachable objects
'shared' - Subset of 'size' with handle_count > 1
'resident' - Objects with backing store
'active' - Objects in use, subset of resident
'purgeable' - Or inactive? Subset of resident.
We keep the same semantics as with process memory accounting (if I got
it right) which could be desirable for a simplified mental model.
(AMD needs to remind me of their 'drm-memory-...' keys semantics. If we
correctly captured this in the first round it should be equivalent to
'resident' above. In any case we can document no category is equal to
which category, and at most one of the two must be output.)
Region names we at most partially standardize. Like we could say
'system' is to be used where backing store is system RAM and others are
driver defined.
Then discrete GPUs could emit N sets of key-values, one for each memory
region they support.
I think this all also works for objects which can be migrated between
memory regions. 'Size' accounts them against all regions while for
'resident' they only appear in the region of their current placement, etc.
I'm not too sure how to rectify different memory regions with this,
since drm core doesn't really know about the driver's memory regions.
Perhaps we can go back to this being a helper and drivers with vram
just don't use the helper? Or??
I think if you flip it around to drm-$CATEGORY-memory{-$REGION}: then it
all works out reasonably consistently?
That is basically what we have now. I could append -system to each to
make things easier to add vram/etc (from a uabi standpoint)..
What you have isn't really -system, but everything. So doesn't really make
sense to me to mark this -system, it's only really true for integrated (if
they don't have stolen or something like that).
Also my comment was more in reply to Tvrtko's suggestion.
Right so my proposal was drm-memory-$CATEGORY-$REGION which I think
aligns with the current drm-memory-$REGION by extending, rather than
creating confusion with different order of key name components.
AMD currently has (among others) drm-memory-vram, which we could define
in the spec maps to category X, if category component is not present.
Some examples:
drm-memory-resident-system:
drm-memory-size-lmem0:
drm-memory-active-vram:
Etc.. I think it creates a consistent story.
Other than this, my two I think significant opens which haven't been
addressed yet are:
1)
Why do we want totals (not per region) when userspace can trivially
aggregate if they want. What is the use case?
2)
Current proposal limits the value to whole objects and fixates that by
having it in the common code. If/when some driver is able to support
sub-BO granularity they will need to opt out of the common printer at
which point it may be less churn to start with a helper rather than
mid-layer. Or maybe some drivers already support this, I don't know.
Given how important VM
[PATCH 2/2] phy: mediatek: hdmi: mt8195: fix wrong pll calculus
The clock rate calculus in mtk_hdmi_pll_calc() was wrong when it has
been replaced by 'div_u64'.
Fix the issue by multiplying the values in the denominator instead of
dividing them.
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index e10da6c4147e..5e84b294a43e 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -271,7 +271,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
* [32,24] 9bit integer, [23,0]:24bit fraction
*/
pcw = div_u64(((u64)ns_hdmipll_ck) << PCW_DECIMAL_WIDTH,
- da_hdmitx21_ref_ck / PLL_FBKDIV_HS3);
+ da_hdmitx21_ref_ck * PLL_FBKDIV_HS3);
if (pcw > GENMASK_ULL(32, 0))
return -EINVAL;
@@ -288,7 +288,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
posdiv2 = 1;
/* Digital clk divider, max /32 */
- digital_div = div_u64((u64)ns_hdmipll_ck, posdiv1 / posdiv2 /
pixel_clk);
+ digital_div = div_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
--
2.39.2
[PATCH 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
by the kernel test robot.
Fix the issue by removing the variable altogether and testing out the
return value of mtk_hdmi_pll_set_hw()
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reported-by: kernel test robot
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..e10da6c4147e 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
u8 txpredivs[4] = { 2, 4, 6, 12 };
u32 fbkdiv_low;
- int i, ret;
+ int i;
pixel_clk = rate;
tmds_clk = pixel_clk;
@@ -292,10 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
*hdmi_phy, struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ if (mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
- txposdiv, digital_div);
- if (ret)
+ txposdiv, digital_div))
return -EINVAL;
return 0;
--
2.39.2
[PATCH 0/2] Fix mtk-hdmi-mt8195 unitialized variable usage and clock rate calculation
I've received a report from kernel test report [1] that a variable was used unitialized in the mtk8195 hdmi phy code. I've upon fixing that issue found out that the clock rate calculation was erroneous since the calculus was moved to div_u64. I'm providing those two fixes on top of 45810d486bb44 from the linux-phy repository [2]. [1] https://lore.kernel.org/oe-kbuild-all/202304130304.gmtrudbd-...@intel.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git Signed-off-by: Guillaume Ranquet --- Guillaume Ranquet (2): phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc phy: mediatek: hdmi: mt8195: fix wrong pll calculus drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) --- base-commit: 45810d486bb44bd60213d5f09a713df81b987972 change-id: 20230413-fixes-for-mt8195-hdmi-phy-9e1513b5baad Best regards, -- Guillaume Ranquet
Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
On Thu, 2023-04-13 at 15:31 +0300, Jani Nikula wrote:
> On Thu, 13 Apr 2023, Jeff Layton wrote:
> > I've been experiencing some intermittent crashes down in the display
> > driver code. The symptoms are ususally a line like this in dmesg:
> >
> > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > 6d3a3885: -5
> >
> > ...followed by an Oops due to a NULL pointer dereference.
> >
> > The real bug is probably in the caller of this function, which is
> > passing it a NULL state pointer, but this patch at least keeps my
> > machine from oopsing when this occurs.
>
> My fear is that papering over this makes the root cause harder to find.
>
> Cc: Harry, Alex
>
>
> BR,
> Jani.
>
>
I'm happy to help track down the root cause. Display drivers are
somewhat outside my wheelhouse though.
Maybe we can throw a WARNING when this happens? I'd just like it to not
crash my machine.
> >
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > Signed-off-by: Jeff Layton
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 38dab76ae69e..87ad406c50f9 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> > drm_dp_mst_topology_mgr *mgr,
> >
> > /* Skip failed payloads */
> > if (payload->vc_start_slot == -1) {
> > - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> > failed, skipping part 2\n",
> > + drm_dbg_kms(state ? state->dev : NULL,
> > + "Part 1 of payload creation for %s failed, skipping
> > part 2\n",
> > payload->port->connector->name);
> > return -EIO;
> > }
>
--
Jeff Layton
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 13/04/2023 12:56, Tvrtko Ursulin wrote:
On 12/04/2023 12:33, Andi Shyti wrote:
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
Above two paragraphs seems to have redundancy in the message they convey.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
These two too. So I think commit message can be a bit polished.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++--
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..668c95af8cbcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context
*ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+ * While building the chain of requests, we need to ensure
+ * that no one can sneak into the timeline unnoticed.
+ */
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context
*ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
+ i915_sw_fence_await(&rq->submit);
+ i915_request_get(rq);
+ i915_request_add_locked(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
i915_request_put(*out);
Could you help me understand this please. I have a few questions -
first, what are the actual mechanics of fence error transfer here? I see
the submit fence is being blocked until the next request is submitted -
effectively previous request is only allowed to get on the hardware
after the next one has been queued up. But I don't immediately see what
that does in practice.
Second question relates to the need to hold the timeline mutex
throughout. Presumably this is so two copy or migrate operations on the
same context do not interleave, which can otherwise happen?
Would the error propagation be doable without the lock held by chaining
on the previous request _completion_ fence? If so I am sure that would
have a performance impact, because chunk by chunk would need a GPU<->CPU
round trip to schedule. How much of an impact I don't know. Maybe
enlarging CHUNK_SZ to compensate is an option?
Or if the perf hit would be bearable for stable backports only (much
smaller patch) and then for tip we can do this full speed solution.
But yes, I would first want to understand the actual error propagation
mechanism because sadly my working knowledge is a bit rusty.
Another option - maybe - is this related to revert of fence error
propagation? If it is and having that would avoid the need for this
invasive fix, maybe we unrevert 3761baae908a7b5012be08d70fa553cc2eb82305
with edits to limit to special contexts? If doable..
Regards,
Tvrtko
- *out = i915_request_get(rq);
- i915_request_add(rq);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(&ce->timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct
intel_context *ce,
if (HAS_64K_PAGES(i915) && is_lmem)
offset = CHUNK_SZ;
+ /*
+ * While building the chain of requests, we need to ensure
+ * that no one can sneak into the timeline unnoticed.
+ */
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_creat
Re: [RFC PATCH v2 0/2] Imagination Technologies PowerVR DRM driver
On Thu, 13 Apr 2023, Sarah Walker wrote: > The code in this patch, along with some of its history, can also be found > here: > https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/powervr-next FYI patch 1/2 is likely so big that it gets dropped by the list. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
On Thu, 13 Apr 2023, Jeff Layton wrote:
> I've been experiencing some intermittent crashes down in the display
> driver code. The symptoms are ususally a line like this in dmesg:
>
> amdgpu :30:00.0: [drm] Failed to create MST payload for port
> 6d3a3885: -5
>
> ...followed by an Oops due to a NULL pointer dereference.
>
> The real bug is probably in the caller of this function, which is
> passing it a NULL state pointer, but this patch at least keeps my
> machine from oopsing when this occurs.
My fear is that papering over this makes the root cause harder to find.
Cc: Harry, Alex
BR,
Jani.
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> Signed-off-by: Jeff Layton
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 38dab76ae69e..87ad406c50f9 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> drm_dp_mst_topology_mgr *mgr,
>
> /* Skip failed payloads */
> if (payload->vc_start_slot == -1) {
> - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> + drm_dbg_kms(state ? state->dev : NULL,
> + "Part 1 of payload creation for %s failed, skipping
> part 2\n",
> payload->port->connector->name);
> return -EIO;
> }
--
Jani Nikula, Intel Open Source Graphics Center
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one Cc:stable fix for indirect sampler state this week on drm-intel-next-fixes. Regards, Joonas *** drm-intel-next-fixes-2023-04-13: Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585: Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next (2023-04-11 12:28:10 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-04-13 for you to fetch changes up to 81900e3a37750d8c6ad705045310e002f6dd0356: drm/i915: disable sampler indirect state in bindless heap (2023-04-12 11:36:09 +0300) Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. Lionel Landwerlin (1): drm/i915: disable sampler indirect state in bindless heap drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 19 +++ 2 files changed, 20 insertions(+)
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 12/04/2023 12:33, Andi Shyti wrote:
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
Above two paragraphs seems to have redundancy in the message they convey.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
These two too. So I think commit message can be a bit polished.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++--
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..668c95af8cbcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
+ i915_sw_fence_await(&rq->submit);
+ i915_request_get(rq);
+ i915_request_add_locked(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
i915_request_put(*out);
Could you help me understand this please. I have a few questions -
first, what are the actual mechanics of fence error transfer here? I see
the submit fence is being blocked until the next request is submitted -
effectively previous request is only allowed to get on the hardware
after the next one has been queued up. But I don't immediately see what
that does in practice.
Second question relates to the need to hold the timeline mutex
throughout. Presumably this is so two copy or migrate operations on the
same context do not interleave, which can otherwise happen?
Would the error propagation be doable without the lock held by chaining
on the previous request _completion_ fence? If so I am sure that would
have a performance impact, because chunk by chunk would need a GPU<->CPU
round trip to schedule. How much of an impact I don't know. Maybe
enlarging CHUNK_SZ to compensate is an option?
Or if the perf hit would be bearable for stable backports only (much
smaller patch) and then for tip we can do this full speed solution.
But yes, I would first want to understand the actual error propagation
mechanism because sadly my working knowledge is a bit rusty.
- *out = i915_request_get(rq);
- i915_request_add(rq);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(&ce->timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct intel_context *ce,
if (HAS_64K_PAGES(i915) && is_lmem)
offset = CHUNK_SZ;
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
Re: [PATCH 2/5] drm/debugfs: rework debugfs directory creation v3
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes tegra/for-next linus/master v6.3-rc6
next-20230412]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-debugfs-rework-debugfs-directory-creation-v3/20230412-235231
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230412145206.2483-3-christian.koenig%40amd.com
patch subject: [PATCH 2/5] drm/debugfs: rework debugfs directory creation v3
config: arc-randconfig-r043-20230413
(https://download.01.org/0day-ci/archive/20230413/202304131935.9bjnzso4-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/92a7a4f0fd59d427c5827c323692b76095f90efc
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-debugfs-rework-debugfs-directory-creation-v3/20230412-235231
git checkout 92a7a4f0fd59d427c5827c323692b76095f90efc
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304131935.9bjnzso4-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_drv.c: In function 'drm_dev_unregister':
>> drivers/gpu/drm/drm_drv.c:1011:9: error: implicit declaration of function
>> 'drm_debugfs_dev_fini'; did you mean 'drm_debugfs_dev_init'?
>> [-Werror=implicit-function-declaration]
1011 | drm_debugfs_dev_fini(dev);
| ^~~~
| drm_debugfs_dev_init
cc1: some warnings being treated as errors
vim +1011 drivers/gpu/drm/drm_drv.c
974
975 /**
976 * drm_dev_unregister - Unregister DRM device
977 * @dev: Device to unregister
978 *
979 * Unregister the DRM device from the system. This does the reverse of
980 * drm_dev_register() but does not deallocate the device. The caller
must call
981 * drm_dev_put() to drop their final reference.
982 *
983 * A special form of unregistering for hotpluggable devices is
drm_dev_unplug(),
984 * which can be called while there are still open users of @dev.
985 *
986 * This should be called first in the device teardown code to make sure
987 * userspace can't access the device instance any more.
988 */
989 void drm_dev_unregister(struct drm_device *dev)
990 {
991 if (drm_core_check_feature(dev, DRIVER_LEGACY))
992 drm_lastclose(dev);
993
994 dev->registered = false;
995
996 drm_client_dev_unregister(dev);
997
998 if (drm_core_check_feature(dev, DRIVER_MODESET))
999 drm_modeset_unregister_all(dev);
1000
1001 if (dev->driver->unload)
1002 dev->driver->unload(dev);
1003
1004 drm_legacy_pci_agp_destroy(dev);
1005 drm_legacy_rmmaps(dev);
1006
1007 remove_compat_control_link(dev);
1008 drm_minor_unregister(dev, DRM_MINOR_ACCEL);
1009 drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
1010 drm_minor_unregister(dev, DRM_MINOR_RENDER);
> 1011 drm_debugfs_dev_fini(dev);
1012 }
1013 EXPORT_SYMBOL(drm_dev_unregister);
1014
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 12/04/2023 14:10, Rodrigo Vivi wrote:
On Wed, Apr 12, 2023 at 12:56:26PM +0200, Andi Shyti wrote:
Hi Rodrigo,
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Try to find from which kernel version this needs to go in. For instance
if we look at cf586021642d80 it would be v5.15+, but actually in that
commit there are no users apart from selftests. So I think find the
first user which can be user facing and mark the appropriate kernel
version in the stable tag.
Reviewed-by: Matthew Auld
With Matt's comment regarding missing lock in intel_context_migrate_clear
addressed, this is:
Acked-by: Nirmoy Das
Nack!
Please get some ack from Joonas or Tvrtko before merging this series.
There is no architectural change... of course, Joonas and Tvrtko
are more than welcome (and actually invited) to look into this
patch.
And, btw, there are still some discussions ongoing on this whole
series, so that I'm not going to merge it any time soon. I'm just
happy to revive the discussion.
It is a big series targeting stable o.O where the revisions in the cover
letter are not helping me to be confident that this is the right approach
instead of simply reverting the original offending commit:
cf586021642d ("drm/i915/gt: Pipelined page migration")
Why should we remove all the migration completely? What about the
copy?
Is there any other alternative that doesn't hurt the Linux stable rules?
I honestly fail to see this one here is "obviously corrected and tested"
and it looks to me that it has more "than 100 lines, with context".
Does this series really "fix only one thing" with 5 patches?
This is challenging.
Fix to me looks needed on the high level (haven't read the patch details
yet), but when a series sent to stable can go quite badly and we had
such problem very recently with only a two patch series. And it is also
indeed quite large.
Reverting cf586021642d80 definitely isn't an option because stuff
depends on the code added by it and would need an alternative
implementation. Losing async clear/migrate which would be bad and could
also a large patch to implement the alternative.
So since I think we are indeed stuck with fixing this - would it be
better to squash it all into one patch for easier backporting?
We can also look if there are ways to make the diff smaller.
Regards,
Tvrtko
It looks to me that we are adding magic on top of magic to workaround
the deadlocks, but then adding more waits inside locks... And this with
the hang checks vs heartbeats, is this really an issue on current upstream
code? or was only on DII?
There is no real magic happening here. It's just that the error
message was not reaching the end of the operation while this
patch is passing it over.
Where was the bug report to start with?
Matt has reported this, I will give to you the necessary links to
it offline.
It would be really good to have a report to see if this is
"real bug that bothers people (not a, “This could be a problem…” type thing)."
All quotes above are from:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Thanks for looking into this,
Andi
[PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:
amdgpu :30:00.0: [drm] Failed to create MST payload for port
6d3a3885: -5
...followed by an Oops due to a NULL pointer dereference.
The real bug is probably in the caller of this function, which is
passing it a NULL state pointer, but this patch at least keeps my
machine from oopsing when this occurs.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
Signed-off-by: Jeff Layton
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69e..87ad406c50f9 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
drm_dp_mst_topology_mgr *mgr,
/* Skip failed payloads */
if (payload->vc_start_slot == -1) {
- drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
failed, skipping part 2\n",
+ drm_dbg_kms(state ? state->dev : NULL,
+ "Part 1 of payload creation for %s failed, skipping
part 2\n",
payload->port->connector->name);
return -EIO;
}
--
2.39.2
[RFC PATCH v2 2/2] dt-bindings: gpu: Add Imagination Technologies PowerVR GPU
Signed-off-by: Sarah Walker
---
.../devicetree/bindings/gpu/img,powervr.yaml | 105 ++
1 file changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr.yaml
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
new file mode 100644
index ..f722fd1d4e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR MIT)
+# Copyright (c) 2022 Imagination Technologies Ltd.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/gpu/img-powervr.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Imagination Technologies PowerVR GPU
+
+maintainers:
+ - Sarah Walker
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - mediatek,mt8173-gpu
+ - const: img,powervr-series6xt
+ - items:
+ - enum:
+ - ti,am62-gpu
+ - const: img,powervr-seriesaxe
+
+ reg:
+minItems: 1
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 3
+
+ clock-names:
+items:
+ - const: core_clk
+ - const: mem_clk
+ - const: sys_clk
+
+ interrupts:
+items:
+ - description: GPU interrupt
+
+ interrupt-names:
+items:
+ - const: gpu
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+ power-supply: true
+
+ "#cooling-cells":
+const: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: mediatek,mt8173-gpu
+then:
+ properties:
+reg:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+compatible:
+ contains:
+const: img,powervr-series6xt
+then:
+ properties:
+clocks:
+ minItems: 3
+
+examples:
+ - |
+#include
+#include
+
+gpu@1300 {
+compatible = "mediatek,mt8173-gpu", "img,powervr-series6xt";
+reg = <0 0x1300 0 0x>, <0 0x13fff000 0 0x1000>;
+power-domains = <&scpsys MT8173_POWER_DOMAIN_MFG>;
+power-supply = <&da9211_vgpu_reg>;
+operating-points-v2 = <&gpu_opp_table>;
+clocks = <&gpu_ckgen 0>,
+ <&gpu_ckgen 1>,
+ <&gpu_ckgen 2>;
+clock-names = "core_clk",
+ "mem_clk",
+ "sys_clk";
+interrupts = ;
+interrupt-names = "gpu";
+};
+
--
2.40.0
[RFC PATCH v2 0/2] Imagination Technologies PowerVR DRM driver
This patch adds the initial DRM driver for Imagination Technologies PowerVR GPUs, starting with those based on our Rogue architecture. It's worth pointing out that this is a new driver, written from the ground up, rather than a refactored version of our existing downstream driver (pvrsrvkm). This new DRM driver supports: - GEM shmem allocations - dma-buf / PRIME - Per-context (device node open) userspace managed virtual address space - DRM sync objects (binary and timeline) - Power management suspend / resume - GPU job submission (geometry, fragment, compute, transfer) - META firmware processor - MIPS firmware processor - Basic GPU hang recovery Still to do: - Document format of job streams and static context state - GPU hang detection - Handling for running out of parameter buffer space (this has made progress since RFC v1, but is still incomplete) Currently our main focus is on our GX6250, AXE-1-16M and BXS-4-64 GPUs. Testing so far has been done using an Acer Chromebook R13 (GX6250 GPU) and a TI SK-AM62 board (AXE-1-16M GPU). An example SK-AM62 development board can be obtained here: https://beagleboard.org/play Firmware for the GX6250 and AXE-1-16M can be found here: https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr A Vulkan driver that works with our downstream kernel driver has already been merged into Mesa [1][2]. Support for this new DRM driver is being maintained in a draft merge request [3], with the branch located here: https://gitlab.freedesktop.org/frankbinns/mesa/-/tree/powervr-winsys The Vulkan driver is progressing towards Vulkan 1.0. We're code complete, and are working towards passing conformance. This is a work in progress, so we're not sharing numbers just yet. We are still looking at whether any functionality can be replaced with DRM common code. We are still considering drm_sched and the GPU VA manager. The code in this patch, along with some of its history, can also be found here: https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/powervr-next Sending this out now as it felt like a good point to get some feedback. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15243 [2] https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/imagination/vulkan [3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15507 v2: * Redesigned and simplified UAPI based on RFC feedback from XDC 2022 * Support for transfer and partial render jobs * Support for timeline sync objects RFC v1: https://lists.freedesktop.org/archives/dri-devel/2022-August/367814.html Sarah Walker (2): drm/imagination: Add initial Imagination Technologies PowerVR driver dt-bindings: gpu: Add Imagination Technologies PowerVR GPU .../devicetree/bindings/gpu/img,powervr.yaml | 105 + drivers/gpu/drm/imagination/Kconfig | 11 + drivers/gpu/drm/imagination/Makefile | 36 + drivers/gpu/drm/imagination/pvr_ccb.c | 380 + drivers/gpu/drm/imagination/pvr_ccb.h | 51 + drivers/gpu/drm/imagination/pvr_cccb.c| 390 ++ drivers/gpu/drm/imagination/pvr_cccb.h| 112 + drivers/gpu/drm/imagination/pvr_context.c | 1428 drivers/gpu/drm/imagination/pvr_context.h | 412 ++ drivers/gpu/drm/imagination/pvr_debugfs.c | 53 + drivers/gpu/drm/imagination/pvr_debugfs.h | 29 + drivers/gpu/drm/imagination/pvr_device.c | 762 ++ drivers/gpu/drm/imagination/pvr_device.h | 760 ++ drivers/gpu/drm/imagination/pvr_device_info.c | 223 + drivers/gpu/drm/imagination/pvr_device_info.h | 133 + drivers/gpu/drm/imagination/pvr_drv.c | 1634 + drivers/gpu/drm/imagination/pvr_drv.h | 89 + drivers/gpu/drm/imagination/pvr_dump.c| 353 + drivers/gpu/drm/imagination/pvr_dump.h| 17 + drivers/gpu/drm/imagination/pvr_free_list.c | 559 ++ drivers/gpu/drm/imagination/pvr_free_list.h | 185 + drivers/gpu/drm/imagination/pvr_fw.c | 1107 +++ drivers/gpu/drm/imagination/pvr_fw.h | 345 + drivers/gpu/drm/imagination/pvr_fw_info.h | 115 + drivers/gpu/drm/imagination/pvr_fw_meta.c | 598 ++ drivers/gpu/drm/imagination/pvr_fw_meta.h | 14 + drivers/gpu/drm/imagination/pvr_fw_mips.c | 276 + drivers/gpu/drm/imagination/pvr_fw_mips.h | 38 + .../gpu/drm/imagination/pvr_fw_startstop.c| 279 + .../gpu/drm/imagination/pvr_fw_startstop.h| 13 + drivers/gpu/drm/imagination/pvr_fw_trace.c| 505 ++ drivers/gpu/drm/imagination/pvr_fw_trace.h| 78 + drivers/gpu/drm/imagination/pvr_gem.c | 1122 +++ drivers/gpu/drm/imagination/pvr_gem.h | 386 + drivers/gpu/drm/imagination/pvr_hwrt.c| 551 ++ drivers/gpu/drm/imagination/pvr_hwrt.h| 163 + drivers/gpu/drm/imagination/pvr_job.c | 1096 +++ drivers/gpu/drm/imagination/pvr_job.h | 116 + drivers/gpu/drm/imagination/pvr_params.c | 147 + drivers/gpu/drm/imagination/pvr_params.h | 72 + drivers/gpu/drm/i
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 13/04/2023 10:20, Andi Shyti wrote:
From: Paulo Zanoni
In multitile systems IRQ need to be reset and enabled per GT.
Although in MTL the GUnit misc interrupts register set are
available only in GT-0, we need to loop through all the GT's
in order to initialize the media engine which lies on a different
GT.
Signed-off-by: Paulo Zanoni
Cc: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
proposing again this patch, apparently GuC needs this patch to
initialize the media GT.
What is the resolution for Matt's concern that this is wrong for MTL?
Regards,
Tvrtko
Changelog
=
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d24bdea65a3dc..524d64bf5d186 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2764,14 +2764,19 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
- gen11_display_irq_reset(dev_priv);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_reset(gt);
- GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
- GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ uncore = gt->uncore;
+ GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+ GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ }
+
+ gen11_display_irq_reset(dev_priv);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3425,13 +3430,16 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_postinstall(gt);
- GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+ GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+ }
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3440,8 +3448,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(uncore->regs);
- intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
+ intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
Re: [PATCH v4 3/6] drm/amdgpu: Switch to fdinfo helper
Am 13.04.23 um 00:42 schrieb Rob Clark:
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f5ffca24def4..6c0e0c614b94 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2752,7 +2752,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.compat_ioctl = amdgpu_kms_compat_ioctl,
#endif
#ifdef CONFIG_PROC_FS
- .show_fdinfo = amdgpu_show_fdinfo
+ .show_fdinfo = drm_show_fdinfo,
#endif
};
@@ -2807,6 +2807,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = &amdgpu_driver_kms_fops,
.release = &amdgpu_driver_release_kms,
+ .show_fdinfo = amdgpu_show_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 99a7855ab1bc..c2fdd5e448d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -53,9 +53,8 @@ static const char *amdgpu_ip_name[AMDGPU_HW_IP_NUM] = {
[AMDGPU_HW_IP_VCN_JPEG] = "jpeg",
};
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file)
{
- struct drm_file *file = f->private_data;
struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
struct amdgpu_fpriv *fpriv = file->driver_priv;
struct amdgpu_vm *vm = &fpriv->vm;
@@ -86,18 +85,15 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
* **
*/
- seq_printf(m, "pasid:\t%u\n", fpriv->vm.pasid);
- seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name);
- seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", domain, bus, dev, fn);
- seq_printf(m, "drm-client-id:\t%Lu\n", vm->immediate.fence_context);
- seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
- seq_printf(m, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
- seq_printf(m, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
+ drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
+ drm_printf(p, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
+ drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
+ drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
- seq_printf(m, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
+ drm_printf(p, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
ktime_to_ns(usage[hw_ip]));
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
index e86834bfea1d..0398f5a159ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
@@ -37,6 +37,6 @@
#include "amdgpu_ids.h"
uint32_t amdgpu_get_ip_count(struct amdgpu_device *adev, int id);
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f);
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file);
#endif
Re: [PATCH v4 1/6] drm: Add common fdinfo helper
Am 13.04.23 um 10:46 schrieb Daniel Vetter:
On Thu, Apr 13, 2023 at 10:07:11AM +0200, Christian König wrote:
Am 13.04.23 um 00:42 schrieb Rob Clark:
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 10 +++-
drivers/gpu/drm/drm_file.c| 35 +++
include/drm/drm_drv.h | 7 ++
include/drm/drm_file.h| 4 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..2ab32c40e93c 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -126,7 +126,15 @@ percentage utilization of the engine, whereas
drm-engine- only reflects
time active without considering what frequency the engine is operating as a
percentage of it's maximum frequency.
+Implementation Details
+==
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement &drm_driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo(). But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
I'm really wondering if it wouldn't be less mid-layering if we let the
drivers call the drm function to print the common values instead of the
other way around?
The idea is that we plug this into DRM_GEM_FOPS and then everyone gets it
by default. So it's a bit a tradeoff between midlayering and having
inconsistent uapi between drivers. And there's generic tools that parse
this, so consistency across drivers is good.
My gut feeling was that after a bit of experimenting with lots of
different drivers for fdinfo stuff it's time to push for a bit more
standardization and less fragmentation.
Yeah, that's indeed a trade of.
We can of course later on course-correct and shuffle things around again,
e.g. by pushing more things into the gem_bo_fops->status hook (ttm and
other memory manager libs could implement a decent one by default), or
moving more into the drm_driver->show_fdinfo callback again.
If you look at kms we also shuffle things back&forth between core (for
more consistency) and drivers (for more flexibility where needed).
The important part here imo is that we start with some scaffolding to be
able to do this. Like another thing that I think we want is some
drm_fdinfo_print functions that make sure the formatting is guaranteed
consistents and we don't trip up parsers (like some drivers use " \t" as
separator instead of just "\t", I guess by accident).
That's indeed a bit ugly and should probably be fixed on a higher level
in the fs code.
Something like fdinfo_print(seq, name, format, value);
Apart from thatquestion the patch looks good to me.
Ack? Or want the above recorded in the commit message, I think it'd make
sense to put it there.
Well if Rob mentions this trade of in the commit message or even better
code document feel free to add my rb to the patch.
Christian.
-Daniel
Christian.
+
Driver specific implementations
-===
+---
:ref:`i915-usage-stats`
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..6d5bdd684ae2 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
*/
struct drm_file *drm_file_alloc(struct drm_minor *minor)
{
+ static atomic64_t ident = ATOMIC_INIT(0);
struct drm_device *dev = minor->dev;
struct drm_file *file;
int ret;
@@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
+ /* Get a unique identifier for fdinfo: */
+ file->client_id = atomic64_inc_return(&ident);
file->pid = get_pid(task_pid(current));
file->minor = minor;
@@ -868,6 +871,38 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+/**
+ * drm_show_fdinfo - helper for drm file fops
+ * @seq_file: output stream
+ * @f: the device file instance
+ *
+ * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
+ * process using the GPU. See also &drm_driver.show_fdinfo.
+ *
+ * For text output format description please see
Documentation/gpu/drm-usage-stats.rst
+ */
+void drm_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_device *dev = file->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(&p, "drm-driver:\t%s\n", dev->dr
Re: [PATCH] Revert "accel/qaic: Add mhi_qaic_cntl"
Hi, On 13.04.2023 10:49, Daniel Vetter wrote: > On Wed, Apr 12, 2023 at 04:05:42PM +0200, Stanislaw Gruszka wrote: >> On Wed, Apr 12, 2023 at 07:57:44AM -0600, Jeffrey Hugo wrote: >>> This reverts commit 566fc96198b4bb07ca6806386956669881225271. >>> >>> This exposes a userspace API that is still under debate. Revert the >>> change before the uAPI gets exposed to avoid making a mistake. QAIC is >>> otherwise still functional. >>> >>> Suggested-by: Daniel Vetter >>> Signed-off-by: Jeffrey Hugo >>> Reviewed-by: Pranjal Ramajor Asha Kanojiya >> Reviewed-by: Stanislaw Gruszka > > I think Ack from Oded would be good (but iirc there's some holidays going > on), but I guess Greg's is good enough. Can you pls push this to > drm-misc-next-fixes (it's open now for merge window fixes) since Jeff > isn't set up yet? > I've pushed this revert to drm-misc-next-fixes. Regards, Jacek
Re: [PATCH] drm/i915: Fix memory leaks in i915 selftests
Hi Andi,
thank you for your reminder, next time I will pay attention to my
format, and when someone has already
reviewed, add the Reviewed-by field
Regards.
On 2023/4/13 16:44, Andi Shyti wrote:
On Thu, Apr 13, 2023 at 03:55:26PM +0800, Cong Liu wrote:
This patch fixes memory leaks on error escapes in function fake_get_pages
Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
creation")
Signed-off-by: Cong Liu
OK, while I was proposing the adjustments suggested by Jani you
already replied to the e-mail. I will keep your version.
Anyway, next time, please, do not forget to add the r-b's, in
this case it was Andrzej's.
Andi
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 5361ce70d3f2..154801f1c468 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -69,8 +69,10 @@ static int fake_get_pages(struct drm_i915_gem_object *obj)
rem = round_up(obj->base.size, BIT(31)) >> 31;
/* restricted by sg_alloc_table */
- if (overflows_type(rem, unsigned int))
+ if (overflows_type(rem, unsigned int)) {
+ kfree(pages);
return -E2BIG;
+ }
if (sg_alloc_table(pages, rem, GFP)) {
kfree(pages);
--
2.34.1
No virus found
Checked by Hillstone Network AntiVirus
[PATCH v2 3/5] drm/panel: nt36523: Add DCS backlight support
This chip supports controlling the backlight via DCS commands, on at
least some panels. Add support for doing so.
Note this may only concern the NT36523*W* variant. Nobody knows, really,
there's no docs.
Reviewed-by: Linus Walleij
Reviewed-by: Jianhua Lu
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/panel/panel-novatek-nt36523.c | 68 +--
1 file changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36523.c
b/drivers/gpu/drm/panel/panel-novatek-nt36523.c
index d30dbbfb67b1..b0466abae812 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36523.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36523.c
@@ -5,6 +5,7 @@
* Copyright (c) 2022, 2023 Jianhua Lu
*/
+#include
#include
#include
#include
@@ -53,6 +54,7 @@ struct panel_desc {
int (*init_sequence)(struct panel_info *pinfo);
bool is_dual_dsi;
+ bool has_dcs_backlight;
};
static inline struct panel_info *to_panel_info(struct drm_panel *panel)
@@ -679,6 +681,59 @@ static const struct drm_panel_funcs nt36523_panel_funcs = {
.get_modes = nt36523_get_modes,
};
+static int nt36523_bl_update_status(struct backlight_device *bl)
+{
+ struct mipi_dsi_device *dsi = bl_get_data(bl);
+ u16 brightness = backlight_get_brightness(bl);
+ int ret;
+
+ dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+ ret = mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
+ if (ret < 0)
+ return ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ return 0;
+}
+
+static int nt36523_bl_get_brightness(struct backlight_device *bl)
+{
+ struct mipi_dsi_device *dsi = bl_get_data(bl);
+ u16 brightness;
+ int ret;
+
+ dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+ ret = mipi_dsi_dcs_get_display_brightness_large(dsi, &brightness);
+ if (ret < 0)
+ return ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ return brightness;
+}
+
+static const struct backlight_ops nt36523_bl_ops = {
+ .update_status = nt36523_bl_update_status,
+ .get_brightness = nt36523_bl_get_brightness,
+};
+
+static struct backlight_device *nt36523_create_backlight(struct
mipi_dsi_device *dsi)
+{
+ struct device *dev = &dsi->dev;
+ const struct backlight_properties props = {
+ .type = BACKLIGHT_RAW,
+ .brightness = 512,
+ .max_brightness = 4095,
+ .scale = BACKLIGHT_SCALE_NON_LINEAR,
+ };
+
+ return devm_backlight_device_register(dev, dev_name(dev), dev, dsi,
+ &nt36523_bl_ops, &props);
+}
+
static int nt36523_probe(struct mipi_dsi_device *dsi)
{
struct device *dev = &dsi->dev;
@@ -730,9 +785,16 @@ static int nt36523_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, pinfo);
drm_panel_init(&pinfo->panel, dev, &nt36523_panel_funcs,
DRM_MODE_CONNECTOR_DSI);
- ret = drm_panel_of_backlight(&pinfo->panel);
- if (ret)
- return dev_err_probe(dev, ret, "failed to get backlight\n");
+ if (pinfo->desc->has_dcs_backlight) {
+ pinfo->panel.backlight = nt36523_create_backlight(dsi);
+ if (IS_ERR(pinfo->panel.backlight))
+ return dev_err_probe(dev,
PTR_ERR(pinfo->panel.backlight),
+"Failed to create backlight\n");
+ } else {
+ ret = drm_panel_of_backlight(&pinfo->panel);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get
backlight\n");
+ }
drm_panel_add(&pinfo->panel);
--
2.40.0
