[pull] amdgpu drm-fixes-5.16
Hi Dave, Daniel, Fixes for 5.16. The following changes since commit a687efed194bdc185fd7cb33920fe8b4e60ecb9e: Merge tag 'drm-intel-fixes-2021-12-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-12-03 05:59:31 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.16-2021-12-08 for you to fetch changes up to 0755c38eb007196a5f779298b4a5f46c4eec41d2: drm/amd/display: prevent reading unitialized links (2021-12-08 23:24:08 -0500) amd-drm-fixes-5.16-2021-12-08: amdgpu: - DPIA fix - eDP fix Mikita Lipski (1): drm/amd/display: prevent reading unitialized links Nicholas Kazlauskas (1): drm/amd/display: Fix DPIA outbox timeout after S3/S4/reset drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++- drivers/gpu/drm/amd/display/dc/dc_link.h | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-)
RE: [PATCH] net: mana: Fix memory leak in mana_hwc_create_wq
> From: José Expósito
> Sent: Wednesday, December 8, 2021 2:37 PM
>
> If allocating the DMA buffer fails, mana_hwc_destroy_wq was called
> without previously storing the pointer to the queue.
>
> In order to avoid leaking the pointer to the queue, store it as soon as
> it is allocated.
>
> Addresses-Coverity-ID: 1484720 ("Resource leak")
> Signed-off-by: José Expósito
Reviewed-by: Dexuan Cui
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
> On Fri, 03 Dec 2021, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register. Adjust the size to include it. Found with a
> > -Warray-bounds build:
> >
> > drivers/gpu/drm/drm_dp_helper.c: In function
> > 'drm_dp_get_adjust_request_post_cursor':
> > drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
> > array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> > [-Werror=array-bounds]
> >59 | return link_status[r - DP_LANE0_1_STATUS];
> > |~~~^~~
> > drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
> > 'link_status'
> > 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > |
> > ~^~~~
> >
> > Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> > Signed-off-by: Kees Cook
>
> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
> published in 2014, and Tegra is the only user of
> drm_dp_get_adjust_request_post_cursor().
>
> Instead of bumping the link status read size from 6 to 11 for all
> drivers I'd much rather see some other (maybe Tegra specific) solution
> to this.
Hmmm... Well given this is currently non-functional on Tegra (and is an
OOB memory read), how about just removing it entirely?
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 23f9073bc473..c9528aa62c9c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
-u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane)
-{
- unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
- u8 value = dp_link_status(link_status, offset);
-
- return (value >> (lane << 1)) & 0x3;
-}
-EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-
static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
rd_interval)
{
if (rd_interval > 4)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
index 70dfb7d1dec5..bb5bfa93950f 100644
--- a/drivers/gpu/drm/tegra/dp.c
+++ b/drivers/gpu/drm/tegra/dp.c
@@ -559,8 +559,7 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link
*link,
drm_dp_get_adjust_request_pre_emphasis(status, i) >>
DP_TRAIN_PRE_EMPHASIS_SHIFT;
- adjust->post_cursor[i] =
- drm_dp_get_adjust_request_post_cursor(status, i);
+ adjust->post_cursor[i] = 0;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 30359e434c3f..28378db676c8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
int lane);
u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane);
-u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane);
#define DP_BRANCH_OUI_HEADER_SIZE 0xc
#define DP_RECEIVER_CAP_SIZE 0xf
Or maybe do a long link status read in Tegra only?
--
Kees Cook
Re: [PATCH 17/18] drm: rockchip: Add VOP2 driver
Hi Sascha,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on rockchip/for-next]
[also build test ERROR on drm/drm-next drm-intel/for-linux-next
drm-exynos/exynos-drm-next v5.16-rc4]
[cannot apply to drm-tip/drm-tip tegra-drm/drm/tegra/for-next airlied/drm-next
next-20211208]
[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]
url:
https://github.com/0day-ci/linux/commits/Sascha-Hauer/drm-rockchip-RK356x-VOP2-support/20211208-231502
base:
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
for-next
config: arc-allyesconfig
(https://download.01.org/0day-ci/archive/20211209/202112090830.yvovxyce-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 11.2.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/0day-ci/linux/commit/8d57a528cbdfec4716a21d22d3d6c04c40451355
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sascha-Hauer/drm-rockchip-RK356x-VOP2-support/20211208-231502
git checkout 8d57a528cbdfec4716a21d22d3d6c04c40451355
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross
O=build_dir ARCH=arc SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c: In function
'vop2_dither_setup':
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1489:22: error: implicit
>> declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
1489 | *dsp_ctrl |= FIELD_PREP(RK3568_VP_DSP_CTRL__DITHER_DOWN_SEL,
| ^~
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c: In function
'vop2_setup_cluster_alpha':
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1861:33: warning: variable
'top_win_pstate' set but not used [-Wunused-but-set-variable]
1861 | struct drm_plane_state *top_win_pstate;
| ^~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +1489 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
1463
1464 static void vop2_dither_setup(struct drm_crtc *crtc, uint32_t *dsp_ctrl)
1465 {
1466 struct rockchip_crtc_state *vcstate =
to_rockchip_crtc_state(crtc->state);
1467
1468 switch (vcstate->bus_format) {
1469 case MEDIA_BUS_FMT_RGB565_1X16:
1470 *dsp_ctrl |= RK3568_VP_DSP_CTRL__DITHER_DOWN_EN;
1471 break;
1472 case MEDIA_BUS_FMT_RGB666_1X18:
1473 case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
1474 case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
1475 *dsp_ctrl |= RK3568_VP_DSP_CTRL__DITHER_DOWN_EN;
1476 *dsp_ctrl |= RGB888_TO_RGB666;
1477 break;
1478 case MEDIA_BUS_FMT_YUV8_1X24:
1479 case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
1480 *dsp_ctrl |= RK3568_VP_DSP_CTRL__PRE_DITHER_DOWN_EN;
1481 break;
1482 default:
1483 break;
1484 }
1485
1486 if (vcstate->output_mode != ROCKCHIP_OUT_MODE_)
1487 *dsp_ctrl |= RK3568_VP_DSP_CTRL__PRE_DITHER_DOWN_EN;
1488
> 1489 *dsp_ctrl |= FIELD_PREP(RK3568_VP_DSP_CTRL__DITHER_DOWN_SEL,
1490 DITHER_DOWN_ALLEGRO);
1491 }
1492
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] MAINTAINERS: Update e-mail addresses for Laura Abbott
Hello Laura, On Wed, 8 Dec 2021 at 04:25, wrote: > > From: Laura Abbott > > Consolodate everything under an @kernel.org address. > > Signed-off-by: Laura Abbott > --- > Sumit, can you take this through your tree? Thanks for the patch; sure I will! > --- > .mailmap| 3 +++ > MAINTAINERS | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index 6277bb27b4bf..e7a5bb0c35ae 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -203,6 +203,9 @@ Koushik > Krzysztof Kozlowski > Krzysztof Kozlowski > Kuninori Morimoto > +Laura Abbott > +Laura Abbott > +Laura Abbott > Leonardo Bras > Leonid I Ananiev > Leon Romanovsky > diff --git a/MAINTAINERS b/MAINTAINERS > index 43007f2d29e0..21ab7c9d1bee 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5715,7 +5715,7 @@ DMA-BUF HEAPS FRAMEWORK > M: Sumit Semwal > R: Benjamin Gaignard > R: Liam Mark > -R: Laura Abbott > +R: Laura Abbott > R: Brian Starkey > R: John Stultz > L: linux-me...@vger.kernel.org > -- > 2.33.1 > Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v6] drm/msm/dp: do not initialize phy until plugin interrupt received
Quoting Kuogee Hsieh (2021-12-08 12:36:24)
> Current DP drivers have regulators, clocks, irq and phy are grouped
> together within a function and executed not in a symmetric manner.
> This increase difficulty of code maintenance and limited code scalability.
> This patch divided the driver life cycle of operation into four states,
s/divided/divides/
> resume (including booting up), dongle plugin, dongle unplugged and suspend.
> Regulators, core clocks and irq are grouped together and enabled at resume
> (or booting up) so that the DP controller is armed and ready to receive HPD
> plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
> into DUT (device under test). Once HPD plugin interrupt is received, DP
> controller will initialize phy so that dpcd read/write will function and
> following link training can be proceeded successfully. DP phy will be
> disabled after main link is teared down at end of unplugged HPD interrupt
> handle triggered by dongle unplugged out of DUT. Finally regulators, code
> clocks and irq are disabled at corresponding suspension.
>
> Changes in V2:
> -- removed unnecessary dp_ctrl NULL check
> -- removed unnecessary phy init_count and power_count DRM_DEBUG_DP logs
> -- remove flip parameter out of dp_ctrl_irq_enable()
> -- add fixes tag
>
> Changes in V3:
> -- call dp_display_host_phy_init() instead of dp_ctrl_phy_init() at
> dp_display_host_init() for eDP
>
> Changes in V4:
> -- rewording commit text to match this commit changes
>
> Changes in V5:
> -- rebase on top of msm-next branch
>
> Changes in V6:
> -- delete flip variable
>
> Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
> Chipsets")
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 87
> -
> drivers/gpu/drm/msm/dp/dp_ctrl.h| 9 ++--
> drivers/gpu/drm/msm/dp/dp_display.c | 81 --
> 3 files changed, 102 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index c724cb0..7f0d647 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1365,60 +1365,54 @@ static int dp_ctrl_enable_stream_clocks(struct
> dp_ctrl_private *ctrl)
> return ret;
> }
>
> -int dp_ctrl_host_init(struct dp_ctrl *dp_ctrl, bool flip, bool reset)
> +void dp_ctrl_irq_enable(struct dp_ctrl *dp_ctrl)
> +{
> + struct dp_ctrl_private *ctrl;
> +
> + ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
> +
> + dp_catalog_ctrl_reset(ctrl->catalog);
> +
> + dp_catalog_ctrl_enable_irq(ctrl->catalog, true);
> +}
> +
> +void dp_ctrl_irq_disable(struct dp_ctrl *dp_ctrl)
> +{
> + struct dp_ctrl_private *ctrl;
> +
> + ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
> +
> + dp_catalog_ctrl_reset(ctrl->catalog);
> +
> + dp_catalog_ctrl_enable_irq(ctrl->catalog, false);
> +}
The above could be one function with true/false for enable wrappers and
be a little shorter or the same length. It would also avoid problems if
the sequence needs to change. But speaking of that sequence, why doesn't
a dp_catalog_ctrl_reset() disable the irq automatically? I'd think we
could simply reset the whole controller for irq disable? But then,
shouldn't we only reset the controller on the enable path and only
disable the irq bits on irq_disable? If not, then the function name is
misleading. We're resetting the dp controller and enabling or disabling
irqs.
> +
> +void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
> {
> struct dp_ctrl_private *ctrl;
> struct dp_io *dp_io;
> struct phy *phy;
>
> - if (!dp_ctrl) {
> - DRM_ERROR("Invalid input data\n");
> - return -EINVAL;
> - }
> -
> ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
> dp_io = &ctrl->parser->io;
> phy = dp_io->phy;
>
> - ctrl->dp_ctrl.orientation = flip;
> -
> - if (reset)
> - dp_catalog_ctrl_reset(ctrl->catalog);
> -
> - DRM_DEBUG_DP("flip=%d\n", flip);
> dp_catalog_ctrl_phy_reset(ctrl->catalog);
> phy_init(phy);
> - dp_catalog_ctrl_enable_irq(ctrl->catalog, true);
> -
> - return 0;
> }
>
[...]
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index d44f18b..0a53066 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -83,6 +83,7 @@ struct dp_display_private {
>
> /* state variables */
> bool core_initialized;
> + bool phy_initialized;
> bool hpd_irq_on;
> bool audio_supported;
>
> @@ -375,21 +376,46 @@ static int dp_display_process_hpd_high(struct
> dp_display_private *dp)
> return rc;
> }
>
> -static void dp_display_host_init(struct dp_display_private *dp, int reset)
> +static void dp_display
[BUG] gpu: drm: possible ABBA deadlock in drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd()
Hello, My static analysis tool reports a possible ABBA deadlock in the drm driver in Linux 5.10: drm_gem_prime_fd_to_handle() mutex_lock(&dev->object_name_lock); --> Line 313 (Lock A) drm_gem_handle_delete() drm_gem_object_release_handle() drm_gem_remove_prime_handles() mutex_lock(&filp->prime.lock); --> Line 16 (Lock B) drm_gem_prime_handle_to_fd() mutex_lock(&file_priv->prime.lock); --> Line 433 (Lock B) mutex_lock(&dev->object_name_lock); --> Line 466 (Lock A) When drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd() are concurrently executed, the deadlock can occur. I am not quite sure whether this possible deadlock is real and how to fix it if it is real. Any feedback would be appreciated, thanks :) Reported-by: TOTE Robot Best wishes, Jia-Ju Bai
[PATCH] drm/selftests/test-drm_dp_mst_helper: Fix memory leak in sideband_msg_req_encode_decode
Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move
'sideband_msg_req_encode_decode' onto the heap")
Addresses-Coverity-ID: 1475685 ("Resource leak")
Signed-off-by: José Expósito
---
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
index 6b4759ed6bfd..c491429f1a02 100644
--- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
+++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
@@ -131,8 +131,10 @@ sideband_msg_req_encode_decode(struct
drm_dp_sideband_msg_req_body *in)
return false;
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
- if (!txmsg)
+ if (!txmsg) {
+ kfree(out);
return false;
+ }
drm_dp_encode_sideband_req(in, txmsg);
ret = drm_dp_decode_sideband_req(txmsg, out);
--
2.25.1
Re: [PATCH v5] drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read failed
Quoting Kuogee Hsieh (2021-12-08 09:41:02)
> Add checking aux read/write status at both dp_link_parse_sink_count()
> and dp_link_parse_sink_status_filed() to avoid long timeout delay if
> dp aux read/write failed at timeout due to cable unplugged.
>
> Changes in V4:
> -- split this patch as stand alone patch
>
> Changes in v5:
> -- rebase on msm-next branch
>
> Signed-off-by: Kuogee Hsieh
>
Remove this newline please.
> Reviewed-by: Stephen Boyd
> Tested-by: Stephen Boyd
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 12 +---
> drivers/gpu/drm/msm/dp/dp_link.c| 19 ++-
> 2 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 3d61459..0766752 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -692,9 +692,15 @@ static int dp_irq_hpd_handle(struct dp_display_private
> *dp, u32 data)
> return 0;
> }
>
> - ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
> - if (ret == -ECONNRESET) { /* cable unplugged */
> - dp->core_initialized = false;
> + /*
> +* dp core (ahb/aux clks) must be initialized before
> +* irq_hpd be handled
> +*/
> + if (dp->core_initialized) {
This part of the commit isn't described in the commit text. Can you add
some more details in the commit text about this?
> + ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
> + if (ret == -ECONNRESET) { /* cable unplugged */
> + dp->core_initialized = false;
> + }
> }
> DRM_DEBUG_DP("hpd_state=%d\n", state);
>
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote: > > I think a similar problem exists for device private fault handling as well > > and > > it has been on my list of things to fix for a while. I think the solution > > is to > > call try_get_page(), except it doesn't work with device pages due to the > > whole > > refcount thing. That issue is blocking a fair bit of work now so I've > > started > > looking into it. > > Where is this? Nothing posted yet. I've been going through the mailing list and the old thread[1] to get an understanding of what is left to do. If you have any suggestions they would be welcome. [1] https://lore.kernel.org/all/20211014153928.16805-3-alex.sie...@amd.com/
[PATCH v2] drm/vmwgfx: Bump the minor version
From: Zack Rusin v2: Old userspace doesn't like 3.x.x and we'd like to keep it working, so lets just bump the minor version until we have no choice. With GEM, GL4.3, stats and removal of a lot of old code it's time to bump the minor version of the driver. Signed-off-by: Zack Rusin --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 1760ba1b0d4a..4ec2b99351cf 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -54,9 +54,9 @@ #define VMWGFX_DRIVER_NAME "vmwgfx" -#define VMWGFX_DRIVER_DATE "20210722" +#define VMWGFX_DRIVER_DATE "20211206" #define VMWGFX_DRIVER_MAJOR 2 -#define VMWGFX_DRIVER_MINOR 19 +#define VMWGFX_DRIVER_MINOR 20 #define VMWGFX_DRIVER_PATCHLEVEL 0 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) #define VMWGFX_MAX_RELOCATIONS 2048 -- 2.32.0
Re: [PATCH v4 14/14] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
Quoting Sean Paul (2021-11-04 20:04:31)
> From: Sean Paul
>
> This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
$ git grep "This patch" -- Documentation/process/
> helpers.
>
> Cc: Stephen Boyd
> Cc: Abhinav Kumar
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-14-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-15-s...@poorly.run
> #v3
>
> Changes in v2:
> -Squash [1] into this patch with the following changes (Stephen)
> -Update the sc7180 dtsi file
> -Remove resource names and just use index (Stephen)
> Changes in v3:
> -Split out the dtsi change from v2 (Stephen)
> -Fix set-but-unused warning identified by 0-day
> -Fix up a couple of style nits (Stephen)
> -Store HDCP key directly in dp_hdcp struct (Stephen)
> -Remove wmb in HDCP key initialization, move an_seed (Stephen)
> -Use FIELD_PREP for bstatus/bcaps (Stephen)
> -#define read_poll_timeout values (Stephen)
> -Remove unnecessary parentheses in dp_hdcp_store_ksv_fifo (Stephen)
> -Add compatible string for hdcp (Stephen)
> -Rename dp_hdcp_write_* functions (Abhinav)
> -Add 1us delay between An reads (Abhinav)
> -Delete unused dp_hdcp_read_* functions
> Changes in v4:
> -Rebase on Bjorn's multi-dp patchset
>
> [1]
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
Looks mostly ok to me. One nit below but otherwise you can have my
Reviewed-by: Stephen Boyd
> diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> b/drivers/gpu/drm/msm/dp/dp_debug.c
> index da4323556ef3..c16fce17d096 100644
> --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
> @@ -198,6 +201,35 @@ static int dp_test_active_open(struct inode *inode,
> inode->i_private);
> }
>
> +static ssize_t dp_hdcp_key_write(struct file *file, const char __user *ubuf,
> +size_t len, loff_t *offp)
I deem this API through debugfs no good, but I can see that opening the
can of worms that is programming the key other ways is worse, so alright.
> +{
> + char *input_buffer;
> + int ret;
> + struct dp_debug_private *debug = file->private_data;
> +
> + if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
> + return -EINVAL;
> +
[]
> diff --git a/drivers/gpu/drm/msm/dp/dp_hdcp.c
> b/drivers/gpu/drm/msm/dp/dp_hdcp.c
> new file mode 100644
> index ..03ea3a974576
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/dp/dp_hdcp.c
> @@ -0,0 +1,462 @@
[...]
> +
> +int dp_hdcp_attach(struct dp_hdcp *hdcp, struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_hdcp_helper_data *helper_data;
> + int ret;
> +
> + /* HDCP is not configured for this device */
> + if (!hdcp->parser->io.dp_controller.hdcp_key.base)
> + return 0;
> +
> + helper_data = drm_hdcp_helper_initialize_dp(connector, hdcp->aux,
> + &dp_hdcp_funcs, false);
> + if (IS_ERR_OR_NULL(helper_data))
Just IS_ERR()?
> + return PTR_ERR(helper_data);
Because PTR_ERR() on NULL is zero. Maybe return PTR_ERR_OR_ZERO() is
supposed to be here? Or I don't understand why
drm_hdcp_helper_initialize_dp() would return NULL.
> +
> + ret = drm_connector_attach_content_protection_property(connector,
> false);
> + if (ret) {
> + drm_hdcp_helper_destroy(helper_data);
> + drm_err(dev, "Failed to attach content protection prop %d\n",
> ret);
> + return ret;
> + }
Re: [PATCH] drm/mediatek: Set the default value of rotation to DRM_MODE_ROTATE_0
Hi Mark:
Mark Yacoub 於 2021年10月28日 週四 上午12:28寫道：
>
> From: Mark Yacoub
>
> At the reset hook, call __drm_atomic_helper_plane_reset which is
> called at the initialization of the plane and sets the default value of
> rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1.
This patch looks good to me, but please fix this checkpatch warning:
WARNING: From:/Signed-off-by: email address mismatch: 'From: Mark
Yacoub ' != 'Signed-off-by: Mark Yacoub
'
total: 0 errors, 1 warnings, 11 lines checked
Regards,
Chun-Kuang.
>
> Tested on Jacuzzi (MTK).
> Resolves IGT@kms_properties@plane-properties-{legacy,atomic}
>
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index e6dcb34d30522..accd26481b9fb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -44,9 +44,10 @@ static void mtk_plane_reset(struct drm_plane *plane)
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (!state)
> return;
> - plane->state = &state->base;
> }
>
> + __drm_atomic_helper_plane_reset(plane, &state->base);
> +
> state->base.plane = plane;
> state->pending.format = DRM_FORMAT_RGB565;
> }
> --
> 2.33.0.1079.g6e70778dc9-goog
>
Re: [PATCH v4 1/4] dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional
On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein wrote: > > From: Laurent Pinchart > > The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by > means not available to the kernel. Make the GPIO optional. Sorry, I couldn't understand what it means. Does it mean VCC enabled designs no need to enable GPIO? I've a design that do support both EN and VCC. Jagan.
Re: [PATCH v6 7/7] drm/mediatek: Add mt8195 DisplayPort driver
On Wed, Nov 10, 2021 at 9:08 PM Guillaume Ranquet wrote:
>
> From: Markus Schneider-Pargmann
>
> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
> according phy driver mediatek-dp-phy.
>
> It supports both functional units on the mt8195, the embedded
> DisplayPort as well as the external DisplayPort units. It offers
> hot-plug-detection, audio up to 8 channels, and DisplayPort 1.4 with up
> to 4 lanes.
>
> The driver creates a child device for the phy. The child device will
> never exist without the parent being active. As they are sharing a
> register range, the parent passes a regmap pointer to the child so that
> both can work with the same register range. The phy driver sets device
> data that is read by the parent to get the phy device that can be used
> to control the phy properties.
>
> This driver is based on an initial version by
> Jason-JH.Lin .
>
> Signed-off-by: Markus Schneider-Pargmann
> Signed-off-by: Guillaume Ranquet
> Reported-by: kernel test robot
> ---
> +static int mtk_dp_probe(struct platform_device *pdev)
> +{
> + struct mtk_dp *mtk_dp;
> + struct device *dev = &pdev->dev;
> + int ret;
> + int irq_num = 0;
> + struct drm_panel *panel = NULL;
> +
> + mtk_dp = devm_kzalloc(dev, sizeof(*mtk_dp), GFP_KERNEL);
> + if (!mtk_dp)
> + return -ENOMEM;
> +
> + mtk_dp->dev = dev;
> +
> + irq_num = platform_get_irq(pdev, 0);
> + if (irq_num < 0) {
> + dev_err(dev, "failed to request dp irq resource\n");
> + return -EPROBE_DEFER;
> + }
> +
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel,
> + &mtk_dp->next_bridge);
> + if (ret == -ENODEV) {
> + dev_info(
> + dev,
> + "No panel connected in devicetree, continuing as
> external DP\n");
> + mtk_dp->next_bridge = NULL;
> + } else if (ret) {
> + dev_err(dev, "Failed to find panel or bridge: %d\n", ret);
Hi,
We're seeing
[0.424599] mediatek-drm-dp 1c50.edp_tx: Failed to find panel
or bridge: -517
It's probably better to use dev_err_probe here.
Thanks
> + return ret;
> + }
> +
> + if (panel) {
> + mtk_dp->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> + if (IS_ERR(mtk_dp->next_bridge)) {
> + ret = PTR_ERR(mtk_dp->next_bridge);
> + dev_err(dev, "Failed to create bridge: %d\n", ret);
> + return -EPROBE_DEFER;
> + }
> + }
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
> On Fri, 03 Dec 2021, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register. Adjust the size to include it. Found with a
> > -Warray-bounds build:
> >
> > drivers/gpu/drm/drm_dp_helper.c: In function
> > 'drm_dp_get_adjust_request_post_cursor':
> > drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
> > array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> > [-Werror=array-bounds]
> >59 | return link_status[r - DP_LANE0_1_STATUS];
> > |~~~^~~
> > drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
> > 'link_status'
> > 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> > link_status[DP_LINK_STATUS_SIZE],
> > |
> > ~^~~~
> >
> > Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> > Signed-off-by: Kees Cook
>
> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
> published in 2014, and Tegra is the only user of
> drm_dp_get_adjust_request_post_cursor().
I see POST_CURSOR2 is used here too:
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
Here's a version of that for tegra (untested):
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 23f9073bc473..c9528aa62c9c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
link_status[DP_LINK_STATUS_SIZE],
}
EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
-u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane)
-{
- unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
- u8 value = dp_link_status(link_status, offset);
-
- return (value >> (lane << 1)) & 0x3;
-}
-EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-
static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
rd_interval)
{
if (rd_interval > 4)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
index 70dfb7d1dec5..f5535eb04c6b 100644
--- a/drivers/gpu/drm/tegra/dp.c
+++ b/drivers/gpu/drm/tegra/dp.c
@@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link
*link,
{
struct drm_dp_link_train_set *adjust = &link->train.adjust;
unsigned int i;
+ u8 post_cursor;
+ int err;
+
+ err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
+ &post_cursor, sizeof(post_cursor));
+ if (err < 0) {
+ DRM_ERROR("failed to read post_cursor2: %d\n", err);
+ post_cursor = 0;
+ }
for (i = 0; i < link->lanes; i++) {
adjust->voltage_swing[i] =
@@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link
*link,
DP_TRAIN_PRE_EMPHASIS_SHIFT;
adjust->post_cursor[i] =
- drm_dp_get_adjust_request_post_cursor(status, i);
+ (post_cursor >> (i << 1)) & 0x3;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 30359e434c3f..28378db676c8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
int lane);
u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane);
-u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane);
#define DP_BRANCH_OUI_HEADER_SIZE 0xc
#define DP_RECEIVER_CAP_SIZE 0xf
Is that the right way to go?
--
Kees Cook
[PATCH] drm:amdgpu:remove unneeded variable
From: chiminghao
return value form directly instead of
taking this in another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: chiminghao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c | 5 +
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 ++
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
index 5cf142e849bb..fb92f827eeb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
@@ -37,12 +37,9 @@
long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
{
unsigned int nr = DRM_IOCTL_NR(cmd);
- int ret;
if (nr < DRM_COMMAND_BASE)
return drm_compat_ioctl(filp, cmd, arg);
- ret = amdgpu_drm_ioctl(filp, cmd, arg);
-
- return ret;
+ return amdgpu_drm_ioctl(filp, cmd, arg);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index cb82404df534..269a7b04b7e7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1742,7 +1742,7 @@ static int gmc_v9_0_hw_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
bool value;
- int r, i;
+ int i;
/* The sequence of these two function calls matters.*/
gmc_v9_0_init_golden_registers(adev);
@@ -1777,9 +1777,7 @@ static int gmc_v9_0_hw_init(void *handle)
if (adev->umc.funcs && adev->umc.funcs->init_registers)
adev->umc.funcs->init_registers(adev);
- r = gmc_v9_0_gart_enable(adev);
-
- return r;
+ return gmc_v9_0_gart_enable(adev);
}
/**
--
2.25.1
[PATCH] drm: Remove duplicate include
Clean up the following includecheck warning: ./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include #include #include -#include #ifdef CONFIG_X86 #include -- 1.8.3.1
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
Hi Tim On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote: > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > wrote: > > > > Hi Sam, > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg wrote: > > > > > > Hi Jagan, > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > >users like i.MX8MM. > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > component_ops and fixing exynos specific code in order to make > > > > the bridge more mature to use and the same is mentioned in > > > > drivers TODO. > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > Anyone interest, please have a look on this repo > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > the exynos platform? > > > > > > > > Any inputs? > > > > > > I really like where you are headign with this! > > > No testing - sorry. But I will try to provide a bit of feedback on the > > > individual patches. > > > > > > I hope you find a way to move forward with this. > > > > Thanks for the response. > > > > We have found some issues with Bridge conversion on existing exynos > > drivers. The component based DSI drivers(like exynos) are difficult to > > attach if it involves kms hotplug. kms hotplug would require drm > > pointer and that pointer would only available after the bind call > > finishes. But the bridge attach in bind call will defer till it find > > the attached bridge. > > > > Right now I'm trying to find the proper way to attach the bridges for > > component based DSI drivers which involves kms hot-plug. > > > > If you have any ideas on this, please let me know. > > > > Jagan, > > How is your progress on this series? Looking at your repo it looks > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > branch but you've got a lot of things there that are likely not > related to this series? I have a bit of work on those patches and tested on imx8mn. Basically: - add the dsi timing calculation - change few difference with samsung bridge - fix crashes of my dsi panels - compare with NXP driver the final results I found that I have one problem that gives me some instability. In the NXP original driver the panel needs to be enabled in bridge_enable before out the standby. If I understand correctly, our standby should be done after. I would like to have some feedback and help and testing on other boards/devices and some suggestions on how to handle some of the differences. Another big problem is etnavi that is not stable Michael > > Best regards, > > Tim > > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [Freedreno] [PATCH] drm/msm/dp: Move debugfs files into subdirectory
On 2021-10-18 11:36, Bjorn Andersson wrote:
On Mon 18 Oct 11:07 PDT 2021, abhin...@codeaurora.org wrote:
Hi Bjorn
On 2021-10-17 09:42, Bjorn Andersson wrote:
> On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
>
> > On 2021-10-15 16:17, Bjorn Andersson wrote:
> > > In the cleanup path of the MSM DP driver the DP driver's debugfs files
> > > are destroyed by invoking debugfs_remove_recursive() on debug->root,
> > > which during initialization has been set to minor->debugfs_root.
> > >
> > > To allow cleaning up the DP driver's debugfs files either each dentry
> > > needs to be kept track of or the files needs to be put in a subdirectory
> > > which can be removed in one go.
> > >
> > > By choosing to put the debugfs files in a subdirectory, based on the
> > > name of the associated connector this also solves the problem that these
> > > names would collide as support for multiple DP instances are introduced.
> > >
> > > One alternative solution to the problem with colliding file names would
> > > have been to put keep track of the individual files and put them under
> > > the connector's debugfs directory. But while the drm_connector has been
> > > allocated, its associated debugfs directory has not been created at the
> > > time of initialization of the dp_debug.
> > >
> > > Signed-off-by: Bjorn Andersson
> >
> > I have been thinking about this problem ever since multi-DP has been
> > posted
> > :)
> > Creating sub-directories seems right but at the moment it looks like
> > IGT
> > which
> > uses these debugfs nodes doesnt check sub-directories:
> >
> >
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/msm_dp_compliance.c#L215
> >
> > It looks for the DP debugfs nodes under /sys/kernel/debug/dri/*/
> >
> > We have to fix IGT too to be able to handle multi-DP cases. I will
> > try to
> > come up
> > with a proposal to address this.
> >
> > Till then, can we go with the other solution to keep track of the
> > dentries?
> >
>
> I'm afraid I don't see what you're proposing.
>
> Afaict we need one set of dp_test{type,active,data} per DP controller,
> so even doing this by keeping track of the dentries requires that we
> rename the files based on some identifier (id or connector name) - which
> will cause igt to break.
Yes, I also thought the same that there needs to be some identifier.
"To allow cleaning up the DP driver's debugfs files either each dentry
needs to be kept track of or the files needs to be put in a
subdirectory
which can be removed in one go"
I guess I misunderstood your statement in the commit text thinking
that you
had some other way to keep track of the dentries as it mentioned that
use a subdirectory OR keep track of each dentry.
No, I did write that code as well and then ditched it.
Unfortunately I don't think it would help you, because we still need to
add some identifier to the file names and preferably we should add that
to the single case as well to make things consistent.
>
> As such, I think the practical path forward is that we merge the
> multi-DP series as currently proposed. This will not cause any issues on
> single-DP systems, but on multi-DP systems we will have warnings about
> duplicate debugfs entries in the kernel logs.
>
> Then you can figure out how to rework igt to deal with the multiple DP
> instances and update the dp_debug interface accordingly.
>
Fine with me, I will take care of this.
Cool, thanks.
Regards,
Bjorn
Following up on this, Rob has posted the igt change today which i acked.
https://patchwork.freedesktop.org/patch/465930/
With this in place, we can actually go ahead with this change.
Hence,
Reviewed-by: Abhinav Kumar
>
> Which also implies that we should hold this patch back. But if we go
> that path, I think we should fix dp_debug_deinit() so that it doesn't
> remove /sys/kernel/debug/dri/128 when the DP driver is unloaded.
Yes, lets hold this patch back till I fix multi-DP for IGT.
>
> Regards,
> Bjorn
>
> > > ---
> > >
> > > This depends on
> > >
https://lore.kernel.org/linux-arm-msm/20211010030435.4000642-1-bjorn.anders...@linaro.org/
> > > reducing the connector from a double pointer.
> > >
> > > drivers/gpu/drm/msm/dp/dp_debug.c | 15 +--
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > > index da4323556ef3..67da4c69eca1 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
> > > @@ -210,26 +210,29 @@ static const struct file_operations
> > > test_active_fops = {
> > > static int dp_debug_init(struct dp_debug *dp_debug, struct drm_minor
> > > *minor)
> > > {
> > > int rc = 0;
> > > +char path[64];
> > > struct dp_debug_private *debug = container_of(dp_debug,
> > > struct dp_debug_private, dp_debug);
> > >
> > > -debugfs_create_file("dp_debug", 0444, minor->debugfs_
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
On Thu, Dec 09, 2021 at 12:45:24PM +1100, Alistair Popple wrote:
> On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote:
> > > I think a similar problem exists for device private fault handling as
> > > well and
> > > it has been on my list of things to fix for a while. I think the solution
> > > is to
> > > call try_get_page(), except it doesn't work with device pages due to the
> > > whole
> > > refcount thing. That issue is blocking a fair bit of work now so I've
> > > started
> > > looking into it.
> >
> > Where is this?
>
> Nothing posted yet. I've been going through the mailing list and the old
> thread[1] to get an understanding of what is left to do. If you have any
> suggestions they would be welcome.
Oh, that
Joao's series here is the first step:
https://lore.kernel.org/linux-mm/20211202204422.26777-1-joao.m.mart...@oracle.com/
I already sent a patch to remove the DRM usage of PUD/PMD -
0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Next, someone needs to change FSDAX to have a folio covering the
ZONE_DEVICE pages before it installs a PUD or PMD. I don't know
anything about FS's to know how to do this at all.
Thus all PUD/PMD entries will point at a head page or larger of a
compound. This is important because all the existing machinery for THP
assumes 1 PUD/PMD means 1 struct page to manipulate.
Then, consolidate all the duplicated code that runs when a page is
removed from a PTE/PMD/PUD etc into a function. Figure out why the
duplications are different to make them the same (I have some rough
patches for this step)
Start with PUD and have zap on PUD call the consolidated function and
make vmf_insert_pfn_pud_prot() accept a struct page not pfn and incr
the refcount. PUD is easy because there is no THP
Then do the same to PMD without breaking the THP code
Then make the PTE also incr the refcount on insert and zap
Exterminate vma_is_special_huge() along the way, there is no such
thing as a special huge VMA without a pud/pmd_special flag so all
things installed here must be struct page and not special.
Then the patches that are already posted are applicable and we can
kill the refcount == 1 stuff. No 0 ref count pages installed in page
tables.
Once all of that is done it is fairly straightforward to remove
pud/pmd/pte_devmap entirely and the pgmap stuff from gup.c
Jason
Re: [PATCH v2 1/3] of: Move simple-framebuffer device handling from simplefb to of
Hi
Am 08.12.21 um 18:49 schrieb Rob Herring:
On Tue, Dec 7, 2021 at 1:31 AM Hector Martin wrote:
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Signed-off-by: Hector Martin
---
drivers/of/platform.c | 5 +
drivers/video/fbdev/simplefb.c | 21 +
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..e097f40b03c0 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,11 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
+ for_each_child_of_node(of_chosen, node) {
+ if (of_device_is_compatible(node, "simple-framebuffer"))
node = of_get_compatible_child(of_chosen, "simple-framebuffer");
of_platform_device_create(node, NULL, NULL);
of_node_put(node);
Please Cc the DT list. Looks like this patch can be applied
independently. (Better get the other 2 into drm-misc soon or it will
miss 5.17).
Can we merge the whole patchset through drm-misc? Patches 2 and 3 are
useless without the first one.
Best regards
Thomas
Rob
--
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: [BUG] gpu: drm: amd: amdgpu: possible ABBA deadlock in amdgpu_set_power_dpm_force_performance_level() and amdgpu_debugfs_process_reg_op()
Hello, Could you please provide the feedback to my previous report? Thanks a lot :) Best wishes, Jia-Ju Bai On 2021/9/15 17:39, Jia-Ju Bai wrote: Hello, My static analysis tool reports a possible ABBA deadlock in the amdgpu driver in Linux 5.10: amdgpu_debugfs_process_reg_op() mutex_lock(&adev->grbm_idx_mutex); --> Line 250 (Lock A) mutex_lock(&adev->pm.mutex); --> Line 259 (Lock B) amdgpu_set_power_dpm_force_performance_level() mutex_lock(&adev->pm.mutex); --> Line 381 (Lock B) pp_dpm_force_performance_level() --> function pointer via "amdgpu_dpm_force_performance_level()" pp_dpm_en_umd_pstate() amdgpu_device_ip_set_clockgating_state() gfx_v7_0_set_clockgating_state() --> function pointer via "funcs->set_clockgating_state()" gfx_v7_0_enable_mgcg() mutex_lock(&adev->grbm_idx_mutex); --> Line 3646 (Lock A) mutex_lock(&adev->grbm_idx_mutex); --> Line 3697 (Lock A) When amdgpu_debugfs_process_reg_op() and amdgpu_set_power_dpm_force_performance_level() are concurrently executed, the deadlock can occur. I am not quite sure whether this possible deadlock is real and how to fix it if it is real. Any feedback would be appreciated, thanks :) Reported-by: TOTE Robot Best wishes, Jia-Ju Bai
Re: [PATCH] drm/ingenic: fix error code in ingenic_drm_gem_create_object()
FYI this issue was fixed by [1]. Please don't merge.
[1]
https://lore.kernel.org/dri-devel/20211130095255.26710-1-tzimmerm...@suse.de/
Am 18.11.21 um 12:15 schrieb Dan Carpenter:
The ->gem_create_object() function pointers are supposed to return NULL
on error. This function returns an error pointer but none of the
callers expect that so it will lead to an Oops. See drm_gem_vram_create()
for example of it checks for NULL but an error pointer would lead to a
crash.
Fixes: 4a791cb6d34f ("drm/ingenic: Add option to alloc cached GEM buffers")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index a5df1c8d34cd..eb7266a0b037 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -757,7 +757,7 @@ ingenic_drm_gem_create_object(struct drm_device *drm,
size_t size)
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
- return ERR_PTR(-ENOMEM);
+ return NULL;
obj->map_noncoherent = priv->soc_info->map_noncoherent;
--
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
[PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2
Always waiting for the exclusive fence resulted on some performance
regressions. So try to wait for the shared fences first, then the
exclusive fence should always be signaled already.
v2: fix incorrectly placed "(", add some comment why we do this.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 05d0b3eb3690..0ae416aa76dc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
if (ret)
return ret;
- }
- fobj = dma_resv_shared_list(resv);
- fence = dma_resv_excl_fence(resv);
+ fobj = NULL;
+ } else {
+ fobj = dma_resv_shared_list(resv);
+ }
- if (fence) {
+ /* Waiting for the exclusive fence first causes performance regressions
+* under some circumstances. So manually wait for the shared ones first.
+*/
+ for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) {
struct nouveau_channel *prev = NULL;
bool must_wait = true;
+ fence = rcu_dereference_protected(fobj->shared[i],
+ dma_resv_held(resv));
+
f = nouveau_local_fence(fence, chan->drm);
if (f) {
rcu_read_lock();
@@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
if (must_wait)
ret = dma_fence_wait(fence, intr);
-
- return ret;
}
- if (!exclusive || !fobj)
- return ret;
-
- for (i = 0; i < fobj->shared_count && !ret; ++i) {
+ fence = dma_resv_excl_fence(resv);
+ if (fence) {
struct nouveau_channel *prev = NULL;
bool must_wait = true;
- fence = rcu_dereference_protected(fobj->shared[i],
- dma_resv_held(resv));
-
f = nouveau_local_fence(fence, chan->drm);
if (f) {
rcu_read_lock();
@@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
if (must_wait)
ret = dma_fence_wait(fence, intr);
+
+ return ret;
}
return ret;
--
2.25.1
Re: [PATCH v4 3/4] dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings
On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein wrote: > > Add a VCC regulator which needs to be enabled before the EN pin is > released. > > Reviewed-by: Sam Ravnborg > Acked-by: Rob Herring > Signed-off-by: Alexander Stein > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > index c3f3e73f740a..48a97bb3e2e0 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > @@ -32,6 +32,9 @@ properties: > maxItems: 1 > description: GPIO specifier for bridge_en pin (active high). > > + vcc-supply: > +description: A 1.8V power supply (see regulator/regulator.yaml). Reviewed-by: Jagan Teki
Re: [PATCH v4 4/4] drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein
wrote:
>
> VCC needs to be enabled before releasing the enable GPIO.
>
> Signed-off-by: Alexander Stein
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 065610edc37a..54d18e82ed74 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -143,6 +144,7 @@ struct sn65dsi83 {
> struct mipi_dsi_device *dsi;
> struct drm_bridge *panel_bridge;
> struct gpio_desc*enable_gpio;
> + struct regulator*vcc;
> int dsi_lanes;
> boollvds_dual_link;
> boollvds_dual_link_even_odd_swap;
> @@ -337,6 +339,12 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
> *bridge,
> u16 val;
> int ret;
>
> + ret = regulator_enable(ctx->vcc);
> + if (ret) {
> + dev_err(ctx->dev, "Failed to enable vcc\n");
> + return;
> + }
Better check the vcc and enable it since it is an optional one.
Jagan.
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
> > Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
> >> Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> >>> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
> Avoid long term pinning for Coherent device type pages. This could
> interfere with their own device memory manager.
> If caller tries to get user device coherent pages with PIN_LONGTERM flag
> set, those pages will be migrated back to system memory.
>
> Signed-off-by: Alex Sierra
> ---
> mm/gup.c | 32 ++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 886d6148d3d0..1572eacf07f4 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1689,17 +1689,37 @@ struct page *get_dump_page(unsigned long addr)
> #endif /* CONFIG_ELF_CORE */
>
> #ifdef CONFIG_MIGRATION
> +static int migrate_device_page(unsigned long address,
> +struct page *page)
> +{
> +struct vm_area_struct *vma = find_vma(current->mm, address);
> +struct vm_fault vmf = {
> +.vma = vma,
> +.address = address & PAGE_MASK,
> +.flags = FAULT_FLAG_USER,
> +.pgoff = linear_page_index(vma, address),
> +.gfp_mask = GFP_KERNEL,
> +.page = page,
> +};
> +if (page->pgmap && page->pgmap->ops->migrate_to_ram)
> +return page->pgmap->ops->migrate_to_ram(&vmf);
> >>> How does this synchronise against pgmap being released? As I understand
> >>> things
> >>> at this point we're not holding a reference on either the page or pgmap,
> >>> so
> >>> the page and therefore the pgmap may have been freed.
> >>>
> >>> I think a similar problem exists for device private fault handling as
> >>> well and
> >>> it has been on my list of things to fix for a while. I think the solution
> >>> is to
> >>> call try_get_page(), except it doesn't work with device pages due to the
> >>> whole
> >>> refcount thing. That issue is blocking a fair bit of work now so I've
> >>> started
> >>> looking into it.
> >> At least the page should have been pinned by the __get_user_pages_locked
> >> call in __gup_longterm_locked. That refcount is dropped in
> >> check_and_migrate_movable_pages when it returns 0 or an error.
> > Never mind. We unpin the pages first. Alex, would the migration work if
> > we unpinned them afterwards? Also, the normal CPU page fault code path
> > seems to make sure the page is locked (check in pfn_swap_entry_to_page)
> > before calling migrate_to_ram.
I don't think that's true. The check in pfn_swap_entry_to_page() is only for
migration entries:
BUG_ON(is_migration_entry(entry) && !PageLocked(p));
As this is coherent memory though why do we have to call into a device driver
to do the migration? Couldn't this all be done in the kernel?
> No, you can not unpinned after migration. Due to the expected_count VS
> page_count condition at migrate_page_move_mapping, during migrate_page call.
>
> Regards,
> Alex Sierra
>
> > Regards,
> >Felix
> >
> >
>
Re: [PATCH v2] drm/vmwgfx: Bump the minor version
On Wed, 2021-12-08 at 21:49 -0500, Zack Rusin wrote: > From: Zack Rusin > > v2: Old userspace doesn't like 3.x.x and we'd like to keep it working, > so lets just bump the minor version until we have no choice. > > With GEM, GL4.3, stats and removal of a lot of old code it's time to > bump the minor version of the driver. > > Signed-off-by: Zack Rusin > --- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > index 1760ba1b0d4a..4ec2b99351cf 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > @@ -54,9 +54,9 @@ > > > #define VMWGFX_DRIVER_NAME "vmwgfx" > -#define VMWGFX_DRIVER_DATE "20210722" > +#define VMWGFX_DRIVER_DATE "20211206" > #define VMWGFX_DRIVER_MAJOR 2 > -#define VMWGFX_DRIVER_MINOR 19 > +#define VMWGFX_DRIVER_MINOR 20 > #define VMWGFX_DRIVER_PATCHLEVEL 0 > #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) > #define VMWGFX_MAX_RELOCATIONS 2048 Reviewed-by: Martin Krastev
Re: [PATCH 06/12] drm/vmwgfx: Update device headers for GL43
On Mon, 2021-12-06 at 12:26 -0500, Zack Rusin wrote: > From: Zack Rusin > > Update the headers for GL43 userspace works that landed in Mesa3D. Also > update the license headers to conform to the kernel guidelines. > > For GL43 the virtual device got D3D11.1 support with some GL extensions. > > Signed-off-by: Zack Rusin > --- > drivers/gpu/drm/vmwgfx/device_include/svga3d_cmd.h | 6 +++--- > .../gpu/drm/vmwgfx/device_include/svga3d_devcaps.h | 10 +++--- > drivers/gpu/drm/vmwgfx/device_include/svga3d_dx.h | 12 ++-- > .../gpu/drm/vmwgfx/device_include/svga3d_limits.h | 8 +--- > drivers/gpu/drm/vmwgfx/device_include/svga3d_reg.h | 6 +++--- > .../gpu/drm/vmwgfx/device_include/svga3d_types.h | 7 +++ > .../gpu/drm/vmwgfx/device_include/svga_escape.h| 6 +++--- > .../gpu/drm/vmwgfx/device_include/svga_overlay.h | 6 +++--- > drivers/gpu/drm/vmwgfx/device_include/svga_reg.h | 14 -- > 9 files changed, 41 insertions(+), 34 deletions(-) Reviewed-by: Martin Krastev
Re: [PATCH 11/12] drm/vmwgfx: Remove usage of MOBFMT_RANGE
On Mon, 2021-12-06 at 12:26 -0500, Zack Rusin wrote:
> From: Zack Rusin
>
> Using MOBFMT_RANGE in the early days of guest backed objects was a major
> performance win but that has changed a lot since. There's no more
> a performance reason to use MOBFMT_RANGE. The device can/will still
> profit from the pages being contiguous but marking them as MOBFMT_RANGE
> no longer matters.
> Benchmarks (e.g. heaven, valley) show that creating page tables
> for mob memory is actually faster than using mobfmt ranges.
>
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 6 --
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 12
> 3 files changed, 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 21dd69e5cdfb..1760ba1b0d4a 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -333,7 +333,6 @@ struct vmw_sg_table {
> struct page **pages;
> const dma_addr_t *addrs;
> struct sg_table *sgt;
> - unsigned long num_regions;
> unsigned long num_pages;
> };
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> index 65f7c2bdc322..2d91a44a3b22 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> @@ -146,9 +146,6 @@ static int vmw_setup_otable_base(struct vmw_private
> *dev_priv,
> if (otable->size <= PAGE_SIZE) {
> mob->pt_level = VMW_MOBFMT_PTDEPTH_0;
> mob->pt_root_page = vmw_piter_dma_addr(&iter);
> - } else if (vsgt->num_regions == 1) {
> - mob->pt_level = SVGA3D_MOBFMT_RANGE;
> - mob->pt_root_page = vmw_piter_dma_addr(&iter);
> } else {
> ret = vmw_mob_pt_populate(dev_priv, mob);
> if (unlikely(ret != 0))
> @@ -623,9 +620,6 @@ int vmw_mob_bind(struct vmw_private *dev_priv,
> if (likely(num_data_pages == 1)) {
> mob->pt_level = VMW_MOBFMT_PTDEPTH_0;
> mob->pt_root_page = vmw_piter_dma_addr(&data_iter);
> - } else if (vsgt->num_regions == 1) {
> - mob->pt_level = SVGA3D_MOBFMT_RANGE;
> - mob->pt_root_page = vmw_piter_dma_addr(&data_iter);
> } else if (unlikely(mob->pt_bo == NULL)) {
> ret = vmw_mob_pt_populate(dev_priv, mob);
> if (unlikely(ret != 0))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 20f752ff6168..b84ecc6d6611 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -288,8 +288,6 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
> {
> struct vmw_private *dev_priv = vmw_tt->dev_priv;
> struct vmw_sg_table *vsgt = &vmw_tt->vsgt;
> - struct vmw_piter iter;
> - dma_addr_t old;
> int ret = 0;
>
> if (vmw_tt->mapped)
> @@ -321,16 +319,6 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
> break;
> }
>
> - old = ~((dma_addr_t) 0);
> - vmw_tt->vsgt.num_regions = 0;
> - for (vmw_piter_start(&iter, vsgt, 0); vmw_piter_next(&iter);) {
> - dma_addr_t cur = vmw_piter_dma_addr(&iter);
> -
> - if (cur != old + PAGE_SIZE)
> - vmw_tt->vsgt.num_regions++;
> - old = cur;
> - }
> -
> vmw_tt->mapped = true;
> return 0;
>
Reviewed-by: Martin Krastev
Re: [Nouveau] Regression in 5.15 in nouveau
Am 07.12.21 um 21:45 schrieb Dan Moulding:
There is a pretty obvious typo in there:
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -359,7 +359,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
fobj = dma_resv_shared_list(resv);
}
- for (i = 0; (i < fobj ? fobj->shared_count : 0) && !ret; ++i) {
+ for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) {
struct nouveau_channel *prev = NULL;
bool must_wait = true;
With that it works and I don't see the flickering in a short test. I
will do more testing, but maybe Dan can test, too.
Cheers,
Stefan
After fixing the typo the patch is working for me, also. dmesg is also
clean. I will continue running the patched kernel. If I see any
issues, I will report back here.
Thanks for fixing that stupid typo. I've just send out an updated
version to the mailing list with everybody in CC.
Please review and/or comment further.
Regards,
Christian.
Cheers,
-- Dan
Re: [PATCH v1 1/1] drm: Replace kernel.h with the necessary inclusions
On Tue, Nov 23, 2021 at 06:32:46PM +0200, Andy Shevchenko wrote: > On Mon, Nov 15, 2021 at 01:35:47PM +0200, Andy Shevchenko wrote: > > On Wed, Nov 10, 2021 at 05:39:33PM +0100, Thomas Zimmermann wrote: > > > Am 10.11.21 um 17:34 schrieb Andy Shevchenko: > > > > On Wed, Nov 10, 2021 at 3:55 PM Thomas Zimmermann > > > > wrote: > > > > > Am 10.11.21 um 11:24 schrieb Andy Shevchenko: > > > > ... > > > > > > > > +#include > > > > > > > > > > I built this patch on a recent drm-misc-next, but there's no > > > > > linux/container_of.h > > > > > > > > Thank you for trying. It's in the upstream, whenever drm-misc-next > > > > switches to newer/newest upstream it will be there. I assume it will > > > > happen after v5.16-rc1? > > > > > > Yes, we'll certainly backmerge soon after rc1 has been released. If I > > > forget > > > to add the patch then, please send a reminder. > > > > > > Once the necessary headers are available, > > > > $ git log --oneline v5.16-rc1 -- include/linux/container_of.h > > e1edc277e6f6 linux/container_of.h: switch to static_assert > > d2a8ebbf8192 kernel.h: split out container_of() and typeof_member() macros > > > > > the patch is > > > Acked-by: Thomas Zimmermann > > > > Thanks! > > Maybe I misunderstood something, I thought that DRM people may apply this, > is it incorrect assumption? It still does not appear in Linux Next... What should I do to move this forward, please? -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 14/16] drm/i915: Remove assert_object_held_shared
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst wrote: > > This duck tape workaround is no longer required, unbind and destroy are > fixed to take the obj->resv mutex before destroying and obj->mm.lock has > been removed, always requiring obj->resv as well. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
Re: [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind
On Thu, 9 Dec 2021 at 13:46, Maarten Lankhorst
wrote:
>
> On 09-12-2021 14:40, Matthew Auld wrote:
> > On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst
> > wrote:
> >> On 09-12-2021 14:05, Matthew Auld wrote:
> >>> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> >>> wrote:
> We want to remove more members of i915_vma, which requires the locking
> to be
> held more often.
>
> Start requiring gem object lock for i915_vma_unbind, as it's one of the
> callers that may unpin pages.
>
> Some special care is needed when evicting, because the last reference to
> the
> object may be held by the VMA, so after __i915_vma_unbind, vma may be
> garbage,
> and we need to cache vma->obj before unlocking.
>
> Signed-off-by: Maarten Lankhorst
> ---
> >>>
> >>>
> @@ -129,22 +129,47 @@ void i915_ggtt_suspend_vm(struct
> i915_address_space *vm)
>
> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
>
> +retry:
> + i915_gem_drain_freed_objects(vm->i915);
> +
> mutex_lock(&vm->mutex);
>
> /* Skip rewriting PTE on VMA unbind. */
> open = atomic_xchg(&vm->open, 0);
>
> list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
> + struct drm_i915_gem_object *obj = vma->obj;
> +
> GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
> +
> i915_vma_wait_for_bind(vma);
>
> - if (i915_vma_is_pinned(vma))
> + if (i915_vma_is_pinned(vma) || !i915_vma_is_bound(vma,
> I915_VMA_GLOBAL_BIND))
> continue;
>
> - if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
> - __i915_vma_evict(vma);
> - drm_mm_remove_node(&vma->node);
> + /* unlikely to race when GPU is idle, so no worry about
> slowpath.. */
> + if (!i915_gem_object_trylock(obj, NULL)) {
> + atomic_set(&vm->open, open);
> >>> Does this need a comment about barriers?
> >> Not sure, it's guarded by vm->mutex.
> +
> + i915_gem_object_get(obj);
> >>> Should this not be kref_get_unless_zero? Assuming the vm->mutex is the
> >>> only thing keeping the object alive here, won't this lead to potential
> >>> uaf/double-free or something? Also should we not plonk this before the
> >>> trylock? Or maybe I'm missing something here?
> >> Normally you're correct, this is normally the case, but we drain freed
> >> objects and this path should only be run during s/r, at which point
> >> userspace should be dead, GPU idle, and we just drained all freed objects
> >> above.
> >>
> >> It would be a bug if we still found a dead object, as nothing should be
> >> running.
> > Hmm, Ok. So why do we expect the trylock to ever fail here? Who else
> > can grab it at this stage?
> It probably shouldn't, should probably be a WARN if it happens.
r-b with that then.
> + mutex_unlock(&vm->mutex);
> +
> + i915_gem_object_lock(obj, NULL);
> + open = i915_vma_unbind(vma);
> + i915_gem_object_unlock(obj);
> +
> + GEM_WARN_ON(open);
> +
> + i915_gem_object_put(obj);
> + goto retry;
> }
> +
> + i915_vma_wait_for_bind(vma);
> >>> We also call wait_for_bind above, is that intentional?
> >> Should be harmless, but first one should probably be removed. :)
> >>
>
Re: [Intel-gfx] [PATCH v2 11/16] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
Can this be reworded slightly? Not sure what is meant by "unbind kill" here.
> because we're removing short term pinning, we may have to unbind the
> object from gtt manually, using a i915_gem_evict_vm() call.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 65fc6ff5f59d..6d557bb9926f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -357,8 +357,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> }
>
> - /* The entire mappable GGTT is pinned? Unexpected! */
> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
> + /*
> +* The entire mappable GGTT is pinned? Unexpected!
> +* Try to evict the object we locked too, as normally we skip
> it
> +* due to lack of short term pinning inside execbuf.
> +*/
> + if (vma == ERR_PTR(-ENOSPC)) {
> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
> + if (!ret) {
> + ret = i915_gem_evict_vm(&ggtt->vm, &ww);
Would it make sense to pass an extra flag for the above ggtt_pin(maybe
PIN_EVICT_SHARED)? Such that evict_for_something can handle the
already locked object and then also any vma sharing the same dma-resv
object here? Or at least trying to nuke the entire vm, just for the
mappable portion seems maybe overkill? Or perhaps we never expect to
hit this in the real world?
Reviewed-by: Matthew Auld
> + mutex_unlock(&ggtt->vm.mutex);
> + }
> + if (ret)
> + goto err_reset;
> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> + }
> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
> }
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> --
> 2.34.0
>
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Hi Rajneesh, yes, separating this from the drm_gem_mmap_obj() change is certainly a good idea. The child cannot access the BOs mapped by the parent anyway with access restrictions applied exactly that is not correct. That behavior is actively used by some userspace stacks as far as I know. Regards, Christian. Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh: Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
Re: [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> We want to remove more members of i915_vma, which requires the locking to be
> held more often.
>
> Start requiring gem object lock for i915_vma_unbind, as it's one of the
> callers that may unpin pages.
>
> Some special care is needed when evicting, because the last reference to the
> object may be held by the VMA, so after __i915_vma_unbind, vma may be garbage,
> and we need to cache vma->obj before unlocking.
>
> Signed-off-by: Maarten Lankhorst
> ---
> @@ -129,22 +129,47 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
>
> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
>
> +retry:
> + i915_gem_drain_freed_objects(vm->i915);
> +
> mutex_lock(&vm->mutex);
>
> /* Skip rewriting PTE on VMA unbind. */
> open = atomic_xchg(&vm->open, 0);
>
> list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
> + struct drm_i915_gem_object *obj = vma->obj;
> +
> GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
> +
> i915_vma_wait_for_bind(vma);
>
> - if (i915_vma_is_pinned(vma))
> + if (i915_vma_is_pinned(vma) || !i915_vma_is_bound(vma,
> I915_VMA_GLOBAL_BIND))
> continue;
>
> - if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
> - __i915_vma_evict(vma);
> - drm_mm_remove_node(&vma->node);
> + /* unlikely to race when GPU is idle, so no worry about
> slowpath.. */
> + if (!i915_gem_object_trylock(obj, NULL)) {
> + atomic_set(&vm->open, open);
Does this need a comment about barriers?
> +
> + i915_gem_object_get(obj);
Should this not be kref_get_unless_zero? Assuming the vm->mutex is the
only thing keeping the object alive here, won't this lead to potential
uaf/double-free or something? Also should we not plonk this before the
trylock? Or maybe I'm missing something here?
> + mutex_unlock(&vm->mutex);
> +
> + i915_gem_object_lock(obj, NULL);
> + open = i915_vma_unbind(vma);
> + i915_gem_object_unlock(obj);
> +
> + GEM_WARN_ON(open);
> +
> + i915_gem_object_put(obj);
> + goto retry;
> }
> +
> + i915_vma_wait_for_bind(vma);
We also call wait_for_bind above, is that intentional?
RE: [v3 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake S
> -Original Message-
> From: Hansen, Dave
> Sent: Thursday, December 9, 2021 2:27 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; Ingo Molnar
> ; Borislav Petkov ; Dave Hansen
> ; Joonas Lahtinen
> ; Tvrtko Ursulin
> ; Roper, Matthew D
> ; Jani Nikula ;
> Souza, Jose
> Subject: Re: [v3 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake S
>
> On 12/2/21 10:35 PM, Anusha Srivatsa wrote:
> > diff --git a/arch/x86/kernel/early-quirks.c
> > b/arch/x86/kernel/early-quirks.c index 391a4e2b8604..fd2d3ab38ebb
> > 100644
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> > @@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> > INTEL_RKL_IDS(&gen11_early_ops),
> > INTEL_ADLS_IDS(&gen11_early_ops),
> > INTEL_ADLP_IDS(&gen11_early_ops),
> > + INTEL_RPLS_IDS(&gen11_early_ops),
> > };
>
> For arch/x86 purposes:
>
> Acked-by: Dave Hansen
Thanks for the ack!
Anusha
Re: [PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
Hi all
On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
wrote:
>
> All the panel driver check the fact that their prepare/unprepare
> call was already called. It's not an ideal solution but fix
> for now the problem on ili9881c
>
> [ 9862.283296] [ cut here ]
> [ 9862.288490] unbalanced disables for vcc3v3_lcd
> [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851
> _regulator_disable+0xd4/0x190
>
> from:
>
> [ 9862.038619] drm_panel_unprepare+0x2c/0x4c
> [ 9862.043212] panel_bridge_post_disable+0x18/0x24
> [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0
> [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
>
> and:
>
> [ 9862.183103] drm_panel_unprepare+0x2c/0x4c
> [ 9862.187695] panel_bridge_post_disable+0x18/0x24
> [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> [ 9862.199117] disable_outputs+0x120/0x31c
>
> Signed-off-by: Michael Trimarchi
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> index 103a16018975..f75eecb0e65c 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> @@ -52,6 +52,8 @@ struct ili9881c {
>
> struct regulator*power;
> struct gpio_desc*reset;
> +
> + boolprepared;
> };
>
I found that this can be a general problem. Should not mandatory to
track panel status
DRM_PANEL_PREPARED
DRM_PANEL_ENABLED
Michael
> #define ILI9881C_SWITCH_PAGE_INSTR(_page) \
> @@ -707,6 +709,10 @@ static int ili9881c_prepare(struct drm_panel *panel)
> unsigned int i;
> int ret;
>
> + /* Preparing when already prepared is a no-op */
> + if (ctx->prepared)
> + return 0;
> +
> /* Power the panel */
> ret = regulator_enable(ctx->power);
> if (ret)
> @@ -745,6 +751,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
> if (ret)
> return ret;
>
> + ctx->prepared = true;
> +
> return 0;
> }
>
> @@ -770,10 +778,16 @@ static int ili9881c_unprepare(struct drm_panel *panel)
> {
> struct ili9881c *ctx = panel_to_ili9881c(panel);
>
> + /* Unpreparing when already unprepared is a no-op */
> + if (!ctx->prepared)
> + return 0;
> +
> mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> regulator_disable(ctx->power);
> gpiod_set_value(ctx->reset, 1);
>
> + ctx->prepared = false;
> +
> return 0;
> }
>
> --
> 2.25.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
[PULL] drm-misc-next
Hi Dave and Daniel,
here's this week's PR for drm-misc-next.
There was a problem with merging commit e580ea25c08d ("drm/cma-helper: Pass
GEM CMA object in public interfaces") into drm-tip. The commit is correct
in drm-misc-next, but it conflicted with commit 96c5f82ef0a1 ("drm/vc4: fix
error code in vc4_create_object()") from drm-misc-fixes. This affected vc4.
After merging this PR, you may want to double check that vc4_create_object()
returns an error pointer. [1]
Best regards
Thomas
[1]
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/vc4/vc4_bo.c?h=drm-misc-next-2021-12-09#n394
drm-misc-next-2021-12-09:
drm-misc-next for 5.17:
UAPI Changes:
Cross-subsystem Changes:
* dma-buf: Make fences mandatory in dma_resv_add_excl_fence
Core Changes:
* Move hashtable to legacy code
* Return error pointers from struct drm_driver.gem_create_object
* cma-helper: Improve public interfaces; Remove CONFIG_DRM_KMS_CMA_HELPER
option
* mipi-dbi: Don't depend on CMA helpers
* ttm: Don't include DRM hashtable; Stop prunning fences after wait;
Documentation
Driver Changes:
* aspeed: Select CONFIG_DRM_GEM_CMA_HELPER
* bridge/lontium-lt9611: Fix HDMI sensing
* bridge/parade-ps8640: Fixes
* bridge/sn65dsi86: Defer probe is no dsi host found
* fsl-dcu: Select CONFIG_DRM_GEM_CMA_HELPER
* i915: Remove dma_resv_prune
* omapdrm: Fix scatterlist export; Support virtual planes; Fixes
* panel: Boe-tv110c9m,Inx-hj110iz: Update init code
* qxl: Use dma-resv iterator
* rockchip: Use generic fbdev emulation
* tidss: Fixes
* vmwgfx: Fix leak on probe errors; Fail probing on broken hosts; New
placement for MOB page tables; Hide internal BOs from userspace; Cleanups
The following changes since commit 69d846126e1653ca9043c3766c66684132586941:
drm: Fix build error caused by missing drm_nomodeset.o (2021-11-27 21:05:58
+0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-12-09
for you to fetch changes up to 03848335b5b1faa4a4641fcf30b7c233579a45aa:
drm/bridge: sn65dsi86: defer if there is no dsi host (2021-12-08 08:47:10
-0800)
drm-misc-next for 5.17:
UAPI Changes:
Cross-subsystem Changes:
* dma-buf: Make fences mandatory in dma_resv_add_excl_fence
Core Changes:
* Move hashtable to legacy code
* Return error pointers from struct drm_driver.gem_create_object
* cma-helper: Improve public interfaces; Remove CONFIG_DRM_KMS_CMA_HELPER
option
* mipi-dbi: Don't depend on CMA helpers
* ttm: Don't include DRM hashtable; Stop prunning fences after wait;
Documentation
Driver Changes:
* aspeed: Select CONFIG_DRM_GEM_CMA_HELPER
* bridge/lontium-lt9611: Fix HDMI sensing
* bridge/parade-ps8640: Fixes
* bridge/sn65dsi86: Defer probe is no dsi host found
* fsl-dcu: Select CONFIG_DRM_GEM_CMA_HELPER
* i915: Remove dma_resv_prune
* omapdrm: Fix scatterlist export; Support virtual planes; Fixes
* panel: Boe-tv110c9m,Inx-hj110iz: Update init code
* qxl: Use dma-resv iterator
* rockchip: Use generic fbdev emulation
* tidss: Fixes
* vmwgfx: Fix leak on probe errors; Fail probing on broken hosts; New
placement for MOB page tables; Hide internal BOs from userspace; Cleanups
Arnd Bergmann (3):
drm: fsl-dcu: select CONFIG_DRM_GEM_CMA_HELPER
drm: aspeed: select CONFIG_DRM_GEM_CMA_HELPER
omapdrm: dss: mark runtime PM functions __maybe_unused
Benoit Parrot (8):
drm/omap: Add ability to check if requested plane modes can be supported
drm/omap: Add ovl checking funcs to dispc_ops
drm/omap: introduce omap_hw_overlay
drm/omap: omap_plane: subclass drm_plane_state
drm/omap: Add global state as a private atomic object
drm/omap: dynamically assign hw overlays to planes
drm/omap: add plane_atomic_print_state support
drm/omap: Add a 'right overlay' to plane state
Cai Huoqing (1):
drm/tidss: Fix warning: unused variable 'tidss_pm_ops'
Christian König (3):
drm/qxl: use iterator instead of dma_resv_shared_list
drm/ttm: stop pruning fences after wait
dma-buf: make fence mandatory for dma_resv_add_excl_fence v2
Douglas Anderson (1):
drm/bridge: parade-ps8640: Add backpointer to drm_device in drm_dp_aux
Ivaylo Dimitrov (1):
drm: omapdrm: Export correct scatterlist for TILER backed BOs
John Keeping (2):
drm/rockchip: use generic fbdev setup
drm/rockchip: pass 0 to drm_fbdev_generic_setup()
Maarten Lankhorst (1):
drm/i915: Remove dma_resv_prune
Neil Armstrong (1):
drm/omap: add sanity plane state check
Peter Collingbourne (1):
lontium-lt9611: check a different register bit for HDMI sensing
Rob Clark (1):
drm/bridge: sn65dsi86: defer if there is no dsi host
Thomas Zimmermann (9):
drm/ttm: Don't include drm_hashtab.h
drm/vmwgfx: Copy DRM
Re: Habanalabs, Ask for the linux firmware code which loads by coprocesseor
On Tue, Dec 7, 2021 at 9:19 AM Cai Huoqing wrote: > > Hi Oded Gabbay and habanalabs folks. > > I'm insterested in this kind of AI acceralator. > > After scanning the driver code. > It seems that there are a linux firmware which is loaded by > coprocessor(an slave cpu ?). > shows in the code. > > ./goya/goya.c:74:#define GOYA_LINUX_FW_FILE "habanalabs/goya/goya-fit.itb" > ./goya/goya.c:2436: return hl_fw_load_fw_to_device(hdev, > GOYA_LINUX_FW_FILE, dst, 0, 0); > ./goya/goya.c:2507: fw_loader->linux_img.image_name = GOYA_LINUX_FW_FILE; > ./gaudi/gaudi.c:63:#define GAUDI_LINUX_FW_FILE > "habanalabs/gaudi/gaudi-fit.itb" > ./gaudi/gaudi.c:3945: return hl_fw_load_fw_to_device(hdev, > GAUDI_LINUX_FW_FILE, dst, 0, 0); > ./gaudi/gaudi.c:4011: fw_loader->linux_img.image_name = GAUDI_LINUX_FW_FILE; > > And the host driver(/driver/misc/habanalabs) communicate with the slave > firmware > by MMIO or share memory, right? > > If that, would you mind provide the source code of linux firmware > to avoid the confusion from code reading. Hi Cai, You can download the source code from: https://vault.habana.ai/artifactory/misc/hl-linux.bz2 > > BTW, where can I find the register description datasheet We don't supply this information. Thanks, Oded
Re: [PATCH 08/12] drm/vmwgfx: support 64 UAVs
On Mon, 2021-12-06 at 12:26 -0500, Zack Rusin wrote:
> From: Zack Rusin
>
> If the host supports SVGA3D_DEVCAP_GL43, we can handle 64 instead of
> just 8 UAVs.
> Based on a patch from Roland Scheidegger .
>
> Signed-off-by: Roland Scheidegger
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_binding.h | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 20
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
> 5 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
> index fc8cc222ec51..9aa69ba85670 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
> @@ -1070,7 +1070,7 @@ static int vmw_emit_set_uav(struct
> vmw_ctx_binding_state *cbs)
> size_t cmd_size, view_id_size;
> const struct vmw_resource *ctx = vmw_cbs_context(cbs);
>
> - vmw_collect_view_ids(cbs, loc, SVGA3D_MAX_UAVIEWS);
> + vmw_collect_view_ids(cbs, loc, vmw_max_num_uavs(cbs->dev_priv));
> view_id_size = cbs->bind_cmd_count*sizeof(uint32);
> cmd_size = sizeof(*cmd) + view_id_size;
> cmd = VMW_CMD_CTX_RESERVE(ctx->dev_priv, cmd_size, ctx->id);
> @@ -1100,7 +1100,7 @@ static int vmw_emit_set_cs_uav(struct
> vmw_ctx_binding_state *cbs)
> size_t cmd_size, view_id_size;
> const struct vmw_resource *ctx = vmw_cbs_context(cbs);
>
> - vmw_collect_view_ids(cbs, loc, SVGA3D_MAX_UAVIEWS);
> + vmw_collect_view_ids(cbs, loc, vmw_max_num_uavs(cbs->dev_priv));
> view_id_size = cbs->bind_cmd_count*sizeof(uint32);
> cmd_size = sizeof(*cmd) + view_id_size;
> cmd = VMW_CMD_CTX_RESERVE(ctx->dev_priv, cmd_size, ctx->id);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
> index dcb71fd0bb3b..6b1b234d12a1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
> @@ -200,7 +200,7 @@ struct vmw_dx_shader_bindings {
> * @splice_index: The device splice index set by user-space.
> */
> struct vmw_ctx_bindinfo_uav {
> - struct vmw_ctx_bindinfo_view views[SVGA3D_MAX_UAVIEWS];
> + struct vmw_ctx_bindinfo_view views[SVGA3D_DX11_1_MAX_UAVIEWS];
> uint32 index;
> };
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 71b6b1219ce1..2d59bdad0373 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -364,6 +364,7 @@ static void vmw_print_sm_type(struct vmw_private
> *dev_priv)
> [VMW_SM_4] = "SM4",
> [VMW_SM_4_1] = "SM4_1",
> [VMW_SM_5] = "SM_5",
> + [VMW_SM_5_1X] = "SM_5_1X",
> [VMW_SM_MAX] = "Invalid"
> };
> BUILD_BUG_ON(ARRAY_SIZE(names) != (VMW_SM_MAX + 1));
> @@ -1083,8 +1084,11 @@ static int vmw_driver_load(struct vmw_private
> *dev_priv, u32 pci_id)
> dev_priv->sm_type = VMW_SM_4_1;
> if (has_sm4_1_context(dev_priv) &&
> (dev_priv->capabilities2 & SVGA_CAP2_DX3)) {
> - if (vmw_devcap_get(dev_priv, SVGA3D_DEVCAP_SM5))
> + if (vmw_devcap_get(dev_priv, SVGA3D_DEVCAP_SM5)) {
> dev_priv->sm_type = VMW_SM_5;
> + if (vmw_devcap_get(dev_priv,
> SVGA3D_DEVCAP_GL43))
> + dev_priv->sm_type = VMW_SM_5_1X;
> + }
> }
> }
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index daa4501d17ec..21dd69e5cdfb 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -488,6 +488,7 @@ enum {
> * @VMW_SM_4: Context support upto SM4.
> * @VMW_SM_4_1: Context support upto SM4_1.
> * @VMW_SM_5: Context support up to SM5.
> + * @VMW_SM_5_1X: Adds support for sm5_1 and gl43 extensions.
> * @VMW_SM_MAX: Should be the last.
> */
> enum vmw_sm_type {
> @@ -495,6 +496,7 @@ enum vmw_sm_type {
> VMW_SM_4,
> VMW_SM_4_1,
> VMW_SM_5,
> + VMW_SM_5_1X,
> VMW_SM_MAX
> };
>
> @@ -755,6 +757,24 @@ static inline bool has_sm5_context(const struct
> vmw_private *dev_priv)
> return (dev_priv->sm_type >= VMW_SM_5);
> }
>
> +/**
> + * has_gl43_context - Does the device support GL43 context.
> + * @dev_priv: Device private.
> + *
> + * Return: Bool value if device support SM5 context or not.
> + */
> +static inline bool has_gl43_context(const struct vmw_private *dev_priv)
> +{
> + return (dev_priv->sm_type >= VMW_SM_5_1X);
> +}
> +
> +
> +static inline u32 vmw_max_num_uavs(struct vmw_private *dev_priv)
> +{
> + return (has_gl43_context(dev_priv) ?
> +
[PATCH] drm/imx: Fix memory leak in imx_pd_connector_get_modes
Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code from
of_get_drm_display_mode()")
Addresses-Coverity-ID: 1443943 ("Resource leak")
Signed-off-by: José Expósito
---
drivers/gpu/drm/imx/parallel-display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index a8aba0141ce7..3bf8e0a4803a 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -75,8 +75,10 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
ret = of_get_drm_display_mode(np, &imxpd->mode,
&imxpd->bus_flags,
OF_USE_NATIVE_MODE);
- if (ret)
+ if (ret) {
+ drm_mode_destroy(connector->dev, mode);
return ret;
+ }
drm_mode_copy(mode, &imxpd->mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
--
2.25.1
Re: (EXT) Re: [PATCH v4 1/4] dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional
Am Donnerstag, dem 09.12.2021 um 12:37 +0530 schrieb Jagan Teki:
> On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein
> <
> alexander.st...@ew.tq-group.com
> > wrote:
> > From: Laurent Pinchart <
> > laurent.pinch...@ideasonboard.com
> > >
> >
> > The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled
> > by
> > means not available to the kernel. Make the GPIO optional.
>
> Sorry, I couldn't understand what it means. Does it mean VCC enabled
> designs no need to enable GPIO? I've a design that do support both EN
> and VCC.
The patches 1 & 2 are only about the "enable" gpio for the bridge, it's
unrelated to the VCC regulator introduced in patch 3 & 4.
Maybe the commit message should say:
> The SN65DSI8x EN signal may be hard-wired to VCC, or otherwise
controlled[...]
But I copied the message from bbda1704fc15 ("drm/bridge: ti-sn65dsi86:
Make enable GPIO optional").
This is for use-cases where there is no GPIO the kernel can use, to
control the EN pad of the bridge. Thus make this gpio optional in
bindings and driver.
HTH
Alexander
Re: [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions
On Thu, Dec 9, 2021 at 5:30 PM Dmitry Osipenko wrote:
> 09.12.2021 18:05, Akhil R пишет:
> > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
> > +{
> > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert;
> > + struct gpio_desc *alert_gpiod;
> > + struct i2c_client *ara;
> > +
> > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN);
> > + if (IS_ERR(alert_gpiod))
> > + return PTR_ERR(alert_gpiod);
> > +
> > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod);
> > + if (smbalert->alert_data.irq <= 0)
> > + return smbalert->alert_data.irq;
>
> 0 is the error condition.
I'm not sure what you implied here. gpiod_to_irq() returns 0 if and
only if it goes to the architectures where it might be possible to
have valid vIRQ 0, but this is not the case (at least I never heard of
a such) for GPIO controllers on such platforms. So, looking at the
above code I may tell that the '=' part is redundant.
--
With Best Regards,
Andy Shevchenko
[PATCH v6 00/11] More preparation for multi gt patches
Hi, the first patch concludes the first stage of refactoring which makes the use of intel_gt on the different subsystem. It's taken from Matt's series and it has alread been reviewed. The patch has just been replaced before any multitile patches and I think it can be already pushed. Patch 2-10 are a simple abstraction of the i915->gt which now is under the to_gt() wrapper. This part is mostly taken from Michał. Patch 11 changes i915->gt to i915->gt0. Andi Changelog: == Patchwork: https://patchwork.freedesktop.org/series/97020/ v5 -> v6: - fixed the assignement of i915->gt->ggtt = ggtt in the mock gem device that was making use of it before. v4 -> v5: - use to_gt() instead of to_root_gt() and use Michał work done previously. - split the /i915->gt/to_gt()/ patch in smaller chunks in order to make review easier. (Thanks Lucas) v3 -> v4: - the intel_gt_init_early() has been split as it was causing some headaches for the order of the early initialization. The split has been done keeping in mind the coming next patch in the series that wil make this a static function. v2 -> v3: - sed -i ... took too much freedom and changed more than it was supposed to. - fix a compile error which did not appear in my local build v1 -> v2: - patch 2: do not use anymore the reference i915->gt but use to_root_gt(), coming from Matt Roper's patch. - fix some comments from Chris. Andi Shyti (3): drm/i915/selftests: Use to_gt() helper drm/i915/pxp: Use to_gt() helper drm/i915: Rename i915->gt to i915->gt0 Michał Winiarski (8): drm/i915: Store backpointer to GT in uncore drm/i915: Introduce to_gt() helper drm/i915/display: Use to_gt() helper drm/i915/gt: Use to_gt() helper drm/i915/gem: Use to_gt() helper drm/i915/gvt: Use to_gt() helper drm/i915: Use to_gt() helper drm/i915: Use to_gt() helper for GGTT accesses .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 18 +++--- drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/display/intel_overlay.c | 2 +- .../drm/i915/display/intel_plane_initial.c| 2 +- .../drm/i915/display/skl_universal_plane.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 22 drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 +++--- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 8 +-- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 8 +-- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 12 ++-- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +- .../i915/gem/selftests/i915_gem_client_blt.c | 4 +- .../drm/i915/gem/selftests/i915_gem_context.c | 12 ++-- .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 42 +++--- .../drm/i915/gem/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 ++--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt.c| 11 ++-- drivers/gpu/drm/i915/gt/intel_gt.h| 1 + .../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 7 +-- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 +- drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++-- drivers/gpu/drm/i915/gt/selftest_context.c| 2 +- drivers/gpu/drm/i915/gt/selftest_engine.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 +- .../drm/i915/gt/selftest_engine_heartbeat.c | 4 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 6 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +-- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +- drivers/gpu/drm/i915/gt/selftest_migrate.c| 4 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 4 +- .../drm/i915/gt/selftest_ring_submission.c| 4 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 2 +- drivers/gpu/drm/i915/gvt/gvt.c| 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c
[PATCH v6 09/11] drm/i915: Use to_gt() helper
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs.c| 38 +++
drivers/gpu/drm/i915/i915_debugfs_params.c | 4 +-
drivers/gpu/drm/i915/i915_driver.c | 32 ++---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 16 +++
drivers/gpu/drm/i915/i915_getparam.c | 10 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c| 56 +++---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_pmu.c| 14 +++---
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 22 -
drivers/gpu/drm/i915/intel_gvt.c | 2 +-
drivers/gpu/drm/i915/intel_wopcm.c | 2 +-
14 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bafb902269de..93c3d154885b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -65,7 +65,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
intel_device_info_print_static(INTEL_INFO(i915), &p);
intel_device_info_print_runtime(RUNTIME_INFO(i915), &p);
i915_print_iommu_status(i915, &p);
- intel_gt_info_print(&i915->gt.info, &p);
+ intel_gt_info_print(&to_gt(i915)->info, &p);
intel_driver_caps_print(&i915->caps, &p);
kernel_param_lock(THIS_MODULE);
@@ -293,7 +293,7 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
gpu = NULL;
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
- gpu = i915_gpu_coredump(&i915->gt, ALL_ENGINES);
+ gpu = i915_gpu_coredump(to_gt(i915), ALL_ENGINES);
if (IS_ERR(gpu))
return PTR_ERR(gpu);
@@ -351,7 +351,7 @@ static const struct file_operations i915_error_state_fops =
{
static int i915_frequency_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *i915 = node_to_i915(m->private);
- struct intel_gt *gt = &i915->gt;
+ struct intel_gt *gt = to_gt(i915);
struct drm_printer p = drm_seq_file_printer(m);
intel_gt_pm_frequency_dump(gt, &p);
@@ -439,11 +439,11 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
static int i915_rps_boost_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct intel_rps *rps = &dev_priv->gt.rps;
+ struct intel_rps *rps = &to_gt(dev_priv)->rps;
seq_printf(m, "RPS enabled? %s\n", yesno(intel_rps_is_enabled(rps)));
seq_printf(m, "RPS active? %s\n", yesno(intel_rps_is_active(rps)));
- seq_printf(m, "GPU busy? %s\n", yesno(dev_priv->gt.awake));
+ seq_printf(m, "GPU busy? %s\n", yesno(to_gt(dev_priv)->awake));
seq_printf(m, "Boosts outstanding? %d\n",
atomic_read(&rps->num_waiters));
seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->power.interactive));
@@ -476,7 +476,7 @@ static int i915_runtime_pm_status(struct seq_file *m, void
*unused)
seq_printf(m, "Runtime power status: %s\n",
enableddisabled(!dev_priv->power_domains.init_wakeref));
- seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
+ seq_printf(m, "GPU idle: %s\n", yesno(!to_gt(dev_priv)->awake));
seq_printf(m, "IRQs disabled: %s\n",
yesno(!intel_irqs_enabled(dev_priv)));
#ifdef CONFIG_PM
@@ -508,18 +508,18 @@ static int i915_engine_info(struct seq_file *m, void
*unused)
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
seq_printf(m, "GT awake? %s [%d], %llums\n",
- yesno(i915->gt.awake),
- atomic_read(&i915->gt.wakeref.count),
- ktime_to_ms(intel_gt_get_awake_time(&i915->gt)));
+ yesno(to_gt(i915)->awake),
+ atomic_read(&to_gt(i915)->wakeref.count),
+ ktime_to_ms(intel_gt_get_awake_time(to_gt(i915;
seq_printf(m, "CS timestamp frequency: %u Hz, %d ns\n",
- i915->gt.clock_frequency,
- i915->gt.clock_period_ns);
+ to_gt(i915)->clock_frequency,
+ to_gt(i915)->clock_period_ns);
p = drm_seq_file_printer(m);
for_each_uabi_engine(engine, i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
- intel_gt_show_timelines(&i915->gt, &p, i915_request_show_with_schedule);
+ intel_gt_show_timelines(to_gt(i915), &p,
i915_request_show_with_schedule);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
@@ -558,14 +558,14 @@ static int i915_wedged_get(voi
Re: [PATCH v2] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
Hello Johannes, Sorry for the late response. I was on holidays for a week and just came back. On 12/4/21 13:41, Johannes Stezenbach wrote: > Hi, > > On Wed, Oct 20, 2021 at 06:57:40PM +0200, Javier Martinez Canillas wrote: >> This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a. >> >> That change attempted to improve the DRM drivers fbdev emulation device >> names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb. >> >> But unfortunately, there are user-space programs such as pm-utils that >> match against the fbdev names and so broke after the mentioned commit. >> >> Since the names in /proc/fb are used by tools that consider it an uAPI, >> let's restore the old names even when this lead to silly names like the >> one mentioned above. > > I would like to ask about the fate of this patch. It doesn't > seem to have been picked up by anyone, does it? > Thanks for the reminder. I've just pushed this to the drm-misc-fixes branch. > > Thanks, > Johannes > Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH v6 01/11] drm/i915: Store backpointer to GT in uncore
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
drivers/gpu/drm/i915/i915_driver.c | 5 +++--
drivers/gpu/drm/i915/intel_uncore.c | 9 +
drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
7 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f2422d48be32..f98f0fb21efb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -25,11 +25,8 @@
#include "shmem_utils.h"
#include "pxp/intel_pxp.h"
-void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
- gt->i915 = i915;
- gt->uncore = &i915->uncore;
-
spin_lock_init(>->irq_lock);
INIT_LIST_HEAD(>->closed_vma);
@@ -48,6 +45,12 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
intel_rps_init_early(>->rps);
}
+void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+{
+ gt->i915 = i915;
+ gt->uncore = &i915->uncore;
+}
+
int intel_gt_probe_lmem(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 74e771871a9b..3ace129eb2af 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -35,6 +35,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
*huc)
}
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
+void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
int intel_gt_probe_lmem(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index e9125f14b3d1..42ae5a12040d 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -314,8 +314,9 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
+ intel_gt_init_early(&dev_priv->gt, dev_priv);
intel_uncore_mmio_debug_init_early(&dev_priv->mmio_debug);
- intel_uncore_init_early(&dev_priv->uncore, dev_priv);
+ intel_uncore_init_early(&dev_priv->uncore, &dev_priv->gt);
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
@@ -346,7 +347,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_wopcm_init_early(&dev_priv->wopcm);
- intel_gt_init_early(&dev_priv->gt, dev_priv);
+ __intel_gt_init_early(&dev_priv->gt, dev_priv);
i915_gem_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index abdac78d3976..fc25ebf1a593 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2061,12 +2061,13 @@ void intel_uncore_cleanup_mmio(struct intel_uncore
*uncore)
}
void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915)
+struct intel_gt *gt)
{
spin_lock_init(&uncore->lock);
- uncore->i915 = i915;
- uncore->rpm = &i915->runtime_pm;
- uncore->debug = &i915->mmio_debug;
+ uncore->i915 = gt->i915;
+ uncore->gt = gt;
+ uncore->rpm = >->i915->runtime_pm;
+ uncore->debug = >->i915->mmio_debug;
}
static void uncore_raw_init(struct intel_uncore *uncore)
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index d1d17b04e29f..210fe2a71612 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
void __iomem *regs;
struct drm_i915_private *i915;
+ struct intel_gt *gt;
struct intel_runtime_pm *rpm;
spinlock_t lock; /** lock is also taken in irq contexts. */
@@ -217,7 +218,7 @@ u32 intel_uncore_read_with_mcr_steering(struct intel_uncore
*uncore,
void
intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug);
void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915);
+
[PATCH 1/2] drm/i915: Introduce new Tile 4 format
This tiling layout uses 4KB tiles in a row-major layout. It has the same
shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
only differs from Tile Y at the 256B granularity in between. At this
granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape
of 64B x 8 rows.
Signed-off-by: Stanislav Lisovskiy
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 7f652c96845b..a146c6df1066 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -565,6 +565,17 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
+/*
+ * Intel Tile 4 layout
+ *
+ * This is a tiled layout using 4KB tiles in a row-major layout. It has the
same
+ * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
+ * only differs from Tile Y at the 256B granularity in between. At this
+ * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a
shape
+ * of 64B x 8 rows.
+ */
+#define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.24.1.485.gad05a3d8e5
[PATCH 2/2] drm/i915/dg2: Tile 4 plane format support
Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Moved Tile4 assocating struct for modifier/display to
the beginning(Imre Deak)
- Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
checks(Imre Deak)
- Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
(Imre Deak)
v3: - Rebased patch on top of new changes related to plane_caps.
- Added static assert to check that PLANE_CTL_TILING_YF
matches PLANE_CTL_TILING_4(Nanley Chery)
- Fixed naming and layout description for Tile 4 in drm uapi
header(Nanley Chery)
v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
Cc: Matt Roper
Cc: Maarten Lankhorst
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Matt Roper
Signed-off-by: Juha-Pekka Heikkilä
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
drivers/gpu/drm/i915/display/intel_fb.h | 1 +
drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
.../drm/i915/display/intel_plane_initial.c| 1 +
.../drm/i915/display/skl_universal_plane.c| 23 ---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
11 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 128d4943a43b..83253c62b6d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -,6 +,7 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state, struct int
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+ case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg_kms(&i915->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 23cfe2e5ce2a..94c57facbb46 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -135,11 +135,16 @@ struct intel_modifier_desc {
INTEL_PLANE_CAP_CCS_MC)
#define INTEL_PLANE_CAP_TILING_MASK(INTEL_PLANE_CAP_TILING_X | \
INTEL_PLANE_CAP_TILING_Y | \
-INTEL_PLANE_CAP_TILING_Yf)
+INTEL_PLANE_CAP_TILING_Yf | \
+INTEL_PLANE_CAP_TILING_4)
#define INTEL_PLANE_CAP_TILING_NONE0
static const struct intel_modifier_desc intel_modifiers[] = {
{
+ .modifier = I915_FORMAT_MOD_4_TILED,
+ .display_ver = { 13, 13 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4,
+ }, {
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
.display_ver = { 12, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
@@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED:
+ /*
+* Each 4K tile consists of 64B(8*8) subtiles, with
+* same shape as Y Tile(i.e 4*16B OWords)
+*/
+ return 128;
case I915_FORMAT_MOD_Y_TILED_CCS:
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
@@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
return I915_TILING_Y;
case INTEL_PLANE_CAP_TILING_X:
return I915_TILING_X;
+ case INTEL_PLANE_CAP_TILING_4:
case INTEL_PLANE_CAP_TILING_Yf:
case INTEL_PLANE_CAP_TILING_NONE:
return I915_TILING_NONE;
@@ -737,6 +749,7 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index ba9df8986c1e..12386f13a4e0 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -27,6 +27,7 @@ struct intel_plane_state;
#define INTEL_PLANE_CAP_TILING_X BIT(3)
#define INTEL_PLANE_CAP_TILING_Y BIT(4)
#define INTE
Re: [PATCH v4 4/4] drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
Hi Laurent,
On Thu, Dec 9, 2021 at 10:09 PM Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> On Thu, Dec 09, 2021 at 12:34:49PM +0530, Jagan Teki wrote:
> > On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein wrote:
> > >
> > > VCC needs to be enabled before releasing the enable GPIO.
> > >
> > > Signed-off-by: Alexander Stein
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > index 065610edc37a..54d18e82ed74 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > @@ -33,6 +33,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -143,6 +144,7 @@ struct sn65dsi83 {
> > > struct mipi_dsi_device *dsi;
> > > struct drm_bridge *panel_bridge;
> > > struct gpio_desc*enable_gpio;
> > > + struct regulator*vcc;
> > > int dsi_lanes;
> > > boollvds_dual_link;
> > > boollvds_dual_link_even_odd_swap;
> > > @@ -337,6 +339,12 @@ static void sn65dsi83_atomic_enable(struct
> > > drm_bridge *bridge,
> > > u16 val;
> > > int ret;
> > >
> > > + ret = regulator_enable(ctx->vcc);
> > > + if (ret) {
> > > + dev_err(ctx->dev, "Failed to enable vcc\n");
> > > + return;
> > > + }
> >
> > Better check the vcc and enable it since it is an optional one.
>
> Won't the regulator core create a dummy regulator if none is specified
> in DT ?
Agreed, thanks (Usually I do check to avoid NULL pointer if any).
Jagan.
[PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2021-12-09: A fix in syncobj to handle fence already signalled better, and a fix for a ttm_bo_swapout eviction check. The following changes since commit 679d94cd7d900871e5bc9cf780bd5b73af35ab42: dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow (2021-12-01 15:30:10 +0530) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-12-09 for you to fetch changes up to b19926d4f3a660a8b76e5d989ffd1168e619a5c4: drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence. (2021-12-08 17:19:48 +0100) A fix in syncobj to handle fence already signalled better, and a fix for a ttm_bo_swapout eviction check. Bas Nieuwenhuizen (1): drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence. Christian König (1): drm/ttm: fix ttm_bo_swapout drivers/gpu/drm/drm_syncobj.c | 11 ++- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 2 files changed, 12 insertions(+), 2 deletions(-) signature.asc Description: PGP signature
[PATCH v6 02/11] drm/i915: Introduce to_gt() helper
From: Michał Winiarski
To allow further refactoring and abstract away the fact that GT is
stored inside i915 private.
No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 7 +--
drivers/gpu/drm/i915/i915_drv.h| 5 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index acc49c56a9f3..9db3dcbd917f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -9,11 +9,6 @@
#include "intel_engine_pm.h"
#include "intel_gt_buffer_pool.h"
-static struct intel_gt *to_gt(struct intel_gt_buffer_pool *pool)
-{
- return container_of(pool, struct intel_gt, buffer_pool);
-}
-
static struct list_head *
bucket_for_size(struct intel_gt_buffer_pool *pool, size_t sz)
{
@@ -141,7 +136,7 @@ static struct intel_gt_buffer_pool_node *
node_create(struct intel_gt_buffer_pool *pool, size_t sz,
enum i915_map_type type)
{
- struct intel_gt *gt = to_gt(pool);
+ struct intel_gt *gt = container_of(pool, struct intel_gt, buffer_pool);
struct intel_gt_buffer_pool_node *node;
struct drm_i915_gem_object *obj;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ae7dc7862b5d..c6f34ac353ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1080,6 +1080,11 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
return pci_get_drvdata(pdev);
}
+static inline struct intel_gt *to_gt(struct drm_i915_private *i915)
+{
+ return &i915->gt;
+}
+
/* Simple iterator over all initialised engines */
#define for_each_engine(engine__, dev_priv__, id__) \
for ((id__) = 0; \
--
2.34.1
Re: [PATCH v1 1/1] drm: Replace kernel.h with the necessary inclusions
Hi Am 09.12.21 um 13:24 schrieb Andy Shevchenko: On Tue, Nov 23, 2021 at 06:32:46PM +0200, Andy Shevchenko wrote: On Mon, Nov 15, 2021 at 01:35:47PM +0200, Andy Shevchenko wrote: On Wed, Nov 10, 2021 at 05:39:33PM +0100, Thomas Zimmermann wrote: Am 10.11.21 um 17:34 schrieb Andy Shevchenko: On Wed, Nov 10, 2021 at 3:55 PM Thomas Zimmermann wrote: Am 10.11.21 um 11:24 schrieb Andy Shevchenko: ... +#include I built this patch on a recent drm-misc-next, but there's no linux/container_of.h Thank you for trying. It's in the upstream, whenever drm-misc-next switches to newer/newest upstream it will be there. I assume it will happen after v5.16-rc1? Yes, we'll certainly backmerge soon after rc1 has been released. If I forget to add the patch then, please send a reminder. Once the necessary headers are available, $ git log --oneline v5.16-rc1 -- include/linux/container_of.h e1edc277e6f6 linux/container_of.h: switch to static_assert d2a8ebbf8192 kernel.h: split out container_of() and typeof_member() macros the patch is Acked-by: Thomas Zimmermann Thanks! Maybe I misunderstood something, I thought that DRM people may apply this, is it incorrect assumption? It still does not appear in Linux Next... What should I do to move this forward, please? It's now in drm-misc-next. Sorry that it fell through the cracks. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH v4 04/16] drm/i915/xehpsdv: Add has_flat_ccs to device info
From: CQ Tang
Platforms of XeHP and beyond support 3D surface (buffer) compression and
various compression formats. This is accomplished by an additional
compression control state (CCS) stored for each surface.
Gen 12 devices(TGL family and DG1) stores compression states in a separate
region of memory. It is managed by user-space and has an associated set of
user-space managed page tables used by hardware for address translation.
In Xe HP and beyond (XEHPSDV, DG2, etc), there is a new feature introduced
i.e Flat CCS. It replaced AUX page tables with a flat indexed region of
device memory for storing compression states.
Cc: Joonas Lahtinen
Cc: Matthew Auld
Signed-off-by: CQ Tang
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aeafce112dcd..ad2dd18f7622 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1543,6 +1543,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
#define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
+#define HAS_FLAT_CCS(dev_priv) (INTEL_INFO(dev_priv)->has_flat_ccs)
+
#define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
#define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b523eb1ece5d..382e7278058a 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1005,6 +1005,7 @@ static const struct intel_device_info adl_p_info = {
XE_HP_PAGE_SIZES, \
.dma_mask_size = 46, \
.has_64bit_reloc = 1, \
+ .has_flat_ccs = 1, \
.has_global_mocs = 1, \
.has_gt_uc = 1, \
.has_llc = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 213ae2c07126..cbbb40e8451f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -129,6 +129,7 @@ enum intel_ppgtt_type {
func(has_64k_pages); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
+ func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_l3_dpf); \
--
2.20.1
[PATCH v4 6/6] Documentation/gpu: Add amdgpu and dc glossary
In the DC driver, we have multiple acronyms that are not obvious most of the time; the same idea is valid for amdgpu. This commit introduces a DC and amdgpu glossary in order to make it easier to navigate through our driver. Changes since V3: - Yann: Add new acronyms to amdgpu glossary - Daniel: Add link between dc and amdgpu glossary Changes since V2: - Add MMHUB Changes since V1: - Yann: Divide glossary based on driver context. - Alex: Make terms more consistent and update CPLIB - Add new acronyms to the glossary Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/amdgpu-glossary.rst | 87 +++ .../gpu/amdgpu/display/dc-glossary.rst| 237 ++ Documentation/gpu/amdgpu/display/index.rst| 1 + Documentation/gpu/amdgpu/index.rst| 7 + 4 files changed, 332 insertions(+) create mode 100644 Documentation/gpu/amdgpu/amdgpu-glossary.rst create mode 100644 Documentation/gpu/amdgpu/display/dc-glossary.rst diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst new file mode 100644 index ..859dcec6c6f9 --- /dev/null +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -0,0 +1,87 @@ +=== +AMDGPU Glossary +=== + +Here you can find some generic acronyms used in the amdgpu driver. Notice that +we have a dedicated glossary for Display Core at +'Documentation/gpu/amdgpu/display/dc-glossary.rst'. + +.. glossary:: + +CP + Command Processor + +CPLIB + Content Protection Library + +DFS + Digital Frequency Synthesizer + +ECP + Enhanced Content Protection + +EOP + End Of Pipe/Pipeline + +GC + Graphics and Compute + +GMC + Graphic Memory Controller + +IH + Interrupt Handler + +HQD + Hardware Queue Descriptor + +IB + Indirect Buffer + +IP +Intellectual Property blocks + +KCQ + Kernel Compute Queue + +KGQ + Kernel Graphics Queue + +KIQ + Kernel Interface Queue + +MEC + MicroEngine Compute + +MES + MicroEngine Scheduler + +MMHUB + Multi-Media HUB + +MQD + Memory Queue Descriptor + +PPLib + PowerPlay Library - PowerPlay is the power management component. + +PSP +Platform Security Processor + +RCL + RunList Controller + +SDMA + System DMA + +SMU + System Management Unit + +SS + Spread Spectrum + +VCE + Video Compression Engine + +VCN + Video Codec Next diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst new file mode 100644 index ..116f5f0942fd --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst @@ -0,0 +1,237 @@ +=== +DC Glossary +=== + +On this page, we try to keep track of acronyms related to the display +component. If you do not find what you are looking for, look at the +'Documentation/gpu/amdgpu/amdgpu-glossary.rst'; if you cannot find it anywhere, +consider asking in the amdgfx and update this page. + +.. glossary:: + +ABM + Adaptive Backlight Modulation + +APU + Accelerated Processing Unit + +ASIC + Application-Specific Integrated Circuit + +ASSR + Alternate Scrambler Seed Reset + +AZ + Azalia (HD audio DMA engine) + +BPC + Bits Per Colour/Component + +BPP + Bits Per Pixel + +Clocks + * PCLK: Pixel Clock + * SYMCLK: Symbol Clock + * SOCCLK: GPU Engine Clock + * DISPCLK: Display Clock + * DPPCLK: DPP Clock + * DCFCLK: Display Controller Fabric Clock + * REFCLK: Real Time Reference Clock + * PPLL: Pixel PLL + * FCLK: Fabric Clock + * MCLK: Memory Clock + +CRC + Cyclic Redundancy Check + +CRTC + Cathode Ray Tube Controller - commonly called "Controller" - Generates + raw stream of pixels, clocked at pixel clock + +CVT + Coordinated Video Timings + +DAL + Display Abstraction layer + +DC (Software) + Display Core + +DC (Hardware) + Display Controller + +DCC + Delta Colour Compression + +DCE + Display Controller Engine + +DCHUB + Display Controller HUB + +ARB + Arbiter + +VTG + Vertical Timing Generator + +DCN + Display Core Next + +DCCG + Display Clock Generator block + +DDC + Display Data Channel + +DIO + Display IO + +DPP + Display Pipes and Planes + +DSC + Display Stream Compression (Reduce the amount of bits to represent pixel + count while at the same pixel clock) + +dGPU + discrete GPU + +DMIF + Display Memory Interface + +DML + Display Mode Library + +DMCU + Display Micro-Controller Unit + +DMCUB + Display Micro-Controller Unit, version B + +DPCD + DisplayPort Configuration Data + +DPM(S) +
[PULL] drm-intel-gt-next
Hi Dave, Daniel, Here goes the first PR towards 5.17. On the bugfixing front most user visible items are a fix for GPU hangs caused by certain media and OpenCL workloads applicable from Gen9 (Skylake) onward, a fix for GPU hangs in Gnome shell on Tigerlake platforms and a fix for runtime power management handling in the PXP code. Other than that there is a bunch of bugfixes relating to the GuC backend (locking, error capture, engine resets, incorrect error handling in the uapi entry points, selftest timeout increases where required, removing a tracepoint field). Continuing with the GuC but on the feature front, it has gained support for wait boosting and accurate engine busyness statistics bringing it closer to parity with the existing driver paths. Among other fixes, most interesting ones are closing the missed async clflush under memory pressure corner case, making sure MOCS cannot be used to bypass the last level cache when reading the scratch page and improving the robustness of error capture under memory pressure. With regards to new platform support a few DG2 and XeHP SDV workarounds have arrived, together with some fixes for DG2 buffer migration. Also some code refactoring happened to prepare for more future platforms. Work on discrete memory enablement and TTM has continued with good pace, both by fixing code previously merged and by adding new functionality. Failsafe and asynchronous migration would be the headline features here, fixing both possible security issues and also improving eviction performance. TTM backend has also gained support for cached system memory which improves performance during shrinking and prepares the code base for using TTM with integrated GPUs. Other than these headline features and fixes, there is a bunch of smaller cleanups and further fixups as usual. There are also two drm-next backmarges from the rc2 timeframe which Thomas and Maarten needed for their feature work on async migration and ongoing driver refactoring. Regards, Tvrtko *** drm-intel-gt-next-2021-12-09: Core Changes: - Fix PENDING_ERROR leak in dma_fence_array_signaled() (Thomas Hellström) Driver Changes: - Fix runtime PM handling during PXP suspend (Tejas Upadhyay) - Improve eviction performance on discrete by implementing async TTM moves (Thomas Hellström, Maarten Lankhorst) - Improve robustness of error capture under memory pressure (Thomas Hellström) - Fix GuC PMU versus GPU reset handling (Umesh Nerlige Ramappa) - Use per device iommu check (Tvrtko Ursulin) - Make error capture work with async migration (Thomas Hellström) - Revert incorrect implementation of Wa_1508744258 causing hangs (José Roberto de Souza) - Disable coarse power gating on some DG2 steppings workaround (Matt Roper) - Add IC cache invalidation workaround on DG2 (Ramalingam C) - Move two Icelake workarounds to the right place (Raviteja Goud Talla) - Fix error pointer dereference in i915_gem_do_execbuffer() (Dan Carpenter) - Fixup a couple of generic and DG2 specific issues in migration code (Matthew Auld) - Fix kernel-doc warnings in i915_drm_object.c (Randy Dunlap) - Drop stealing of bits from i915_sw_fence function pointer (Matthew Brost) - Introduce new macros for i915 PTE (Michael Cheng) - Prep work for engine reset by reset domain lookup (Tejas Upadhyay) - Fixup drm-intel-gt-next build failure (Matthew Auld) - Fix live_engine_busy_stats selftests in GuC mode (Umesh Nerlige Ramappa) - Remove dma_resv_prune (Maarten Lankhorst) - Preserve huge pages enablement after driver reload (Matthew Auld) - Fix a NULL pointer dereference in igt_request_rewind() (selftests) (Zhou Qingyang) - Add workaround numbers to GEN7_COMMON_SLICE_CHICKEN1 whitelisting (José Roberto de Souza) - Increase timeouts in i915_gem_contexts selftests to handle GuC being slower (Bruce Chang) drm-intel-gt-next-2021-11-22: Driver Changes: - Fix media and OpenCL system hangs on Gen9 due a missing workaround (Cooper) - Fix build on non-x86 due missing wbinvd_on_all_cpus (Matthew Auld) - Fix recursive lock in GuC submission (Matthew Brost) - Revert 'guc_id' from i915_request tracepoint (Joonas) - Improve accuracy of engine busyness query with GuC submission (Umesh) - Always flush the scratch page so Bypass-LLC MOCS works correctly (Matthew Auld) - Stop caching the scratch page (Matthew Auld) - Make sure to flush even if async flush unexpectedly fails (Matthew Auld) - Skip flushing when obtaining dmabuf pages on discrete (Matthew Auld) - Implement waitboosting with GuC submission (Vinay) - Failsafe migration blits (Thomas) - Fix per-engine resets with GuC submission (Matthew Brost, Thomas) - Fix error capture in GuC mode (John) - Fix gem_madvise for ttm+shmem objects (Thomas) - Fix illegal addition to shrinker list with the TTM backend (Thomas) - Skip error capture when wedged on init (Tvrtko) - fix NULL vs IS_ERR() checking when creating GuC parallel contexts (Dan) - Drain the ttm delayed workqueue too (Maarten) - Add initial Xe_HP SDV wor
[PATCH v6 03/11] drm/i915/display: Use to_gt() helper
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display.c | 18 +-
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
.../gpu/drm/i915/display/skl_universal_plane.c | 2 +-
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 89005628cc3a..c2c512cd8ec0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -819,7 +819,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
* maximum clocks following a vblank miss (see do_rps_boost()).
*/
if (!state->rps_interactive) {
- intel_rps_mark_interactive(&dev_priv->gt.rps, true);
+ intel_rps_mark_interactive(&to_gt(dev_priv)->rps, true);
state->rps_interactive = true;
}
@@ -853,7 +853,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
return;
if (state->rps_interactive) {
- intel_rps_mark_interactive(&dev_priv->gt.rps, false);
+ intel_rps_mark_interactive(&to_gt(dev_priv)->rps, false);
state->rps_interactive = false;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 128d4943a43b..b5cab57a26a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -841,7 +841,7 @@ __intel_display_resume(struct drm_device *dev,
static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
{
return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
- intel_has_gpu_reset(&dev_priv->gt));
+ intel_has_gpu_reset(to_gt(dev_priv)));
}
void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
@@ -860,14 +860,14 @@ void intel_display_prepare_reset(struct drm_i915_private
*dev_priv)
return;
/* We have a modeset vs reset deadlock, defensively unbreak it. */
- set_bit(I915_RESET_MODESET, &dev_priv->gt.reset.flags);
+ set_bit(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags);
smp_mb__after_atomic();
- wake_up_bit(&dev_priv->gt.reset.flags, I915_RESET_MODESET);
+ wake_up_bit(&to_gt(dev_priv)->reset.flags, I915_RESET_MODESET);
if (atomic_read(&dev_priv->gpu_error.pending_fb_pin)) {
drm_dbg_kms(&dev_priv->drm,
"Modeset potentially stuck, unbreaking through
wedging\n");
- intel_gt_set_wedged(&dev_priv->gt);
+ intel_gt_set_wedged(to_gt(dev_priv));
}
/*
@@ -918,7 +918,7 @@ void intel_display_finish_reset(struct drm_i915_private
*dev_priv)
return;
/* reset doesn't touch the display */
- if (!test_bit(I915_RESET_MODESET, &dev_priv->gt.reset.flags))
+ if (!test_bit(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags))
return;
state = fetch_and_zero(&dev_priv->modeset_restore_state);
@@ -956,7 +956,7 @@ void intel_display_finish_reset(struct drm_i915_private
*dev_priv)
drm_modeset_acquire_fini(ctx);
mutex_unlock(&dev->mode_config.mutex);
- clear_bit_unlock(I915_RESET_MODESET, &dev_priv->gt.reset.flags);
+ clear_bit_unlock(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags);
}
static void icl_set_pipe_chicken(const struct intel_crtc_state *crtc_state)
@@ -8564,19 +8564,19 @@ static void intel_atomic_commit_fence_wait(struct
intel_atomic_state *intel_stat
for (;;) {
prepare_to_wait(&intel_state->commit_ready.wait,
&wait_fence, TASK_UNINTERRUPTIBLE);
- prepare_to_wait(bit_waitqueue(&dev_priv->gt.reset.flags,
+ prepare_to_wait(bit_waitqueue(&to_gt(dev_priv)->reset.flags,
I915_RESET_MODESET),
&wait_reset, TASK_UNINTERRUPTIBLE);
if (i915_sw_fence_done(&intel_state->commit_ready) ||
- test_bit(I915_RESET_MODESET, &dev_priv->gt.reset.flags))
+ test_bit(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags))
break;
schedule();
}
finish_wait(&intel_state->commit_ready.wait, &wait_fence);
- finish_wait(bit_waitqueue(&dev_priv->gt.reset.flags,
+ finish_wait(bit_waitqueue(&to_gt(dev_priv)->reset.flags,
I915_RESET_MODESET),
&wait_reset);
}
diff --git a/drivers/gpu/drm/i915/displ
[PATCH v6 10/11] drm/i915: Use to_gt() helper for GGTT accesses
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winiarski
Cc: Michal Wajdeczko
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
.../gpu/drm/i915/display/intel_plane_initial.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 16
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c| 2 +-
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 16
.../gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +++---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 16
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
drivers/gpu/drm/i915/selftests/i915_gem.c| 8
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 6 +++---
drivers/gpu/drm/i915/selftests/i915_request.c| 2 +-
drivers/gpu/drm/i915/selftests/i915_vma.c| 2 +-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
drivers/gpu/drm/i915/selftests/mock_gtt.c| 2 +-
28 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8be01b93015f..98319c0322d7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -595,7 +595,7 @@ static void ivb_fbc_activate(struct intel_fbc *fbc)
else if (DISPLAY_VER(i915) == 9)
skl_fbc_program_cfb_stride(fbc);
- if (i915->ggtt.num_fences)
+ if (to_gt(i915)->ggtt->num_fences)
snb_fbc_program_fence(fbc);
intel_de_write(i915, ILK_DPFC_CONTROL,
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 01ce1d72297f..e4186a0b8edb 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -94,7 +94,7 @@ initial_plane_vma(struct drm_i915_private *i915,
goto err_obj;
}
- vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
+ vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
if (IS_ERR(vma))
goto err_obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index babfecb17ad1..e5b0f66ea1fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -174,7 +174,7 @@ i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
vm = ctx->vm;
if (!vm)
- vm = &ctx->i915->ggtt.vm;
+ vm = &to_gt(ctx->i915)->ggtt->vm;
vm = i915_vm_get(vm);
return vm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ec7c4a29a720..3078611d5bfe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1106,7 +1106,7 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
reloc_cache *cache)
{
struct drm_i915_private *i915 =
container_of(cache, struct i915_execbuffer, reloc_cache)->i915;
- return &i915->ggtt;
+ return to_gt(i915)->ggtt;
}
static void reloc_cache_reset(struct reloc_cache *cache, struct
i915_execbuffer *eb)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 1ca5c062974e..bd5890780810 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -295,7 +295,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *i915 = to_i915(dev);
struct intel_runtime_pm *rpm = &i915->runtime_pm;
- struct i915_ggtt *ggtt = &i915->ggtt;
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
bool write = area->vm_flags & VM_WRITE;
struct i915_gem_ww_ctx ww;
inte
[PATCH 1/2] dt-bindings: i2c: tegra: Add SMBus feature properties
Tegra I2C can use a gpio as an smbus-alert. Document the usage of
the same.
Signed-off-by: Akhil R
---
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
index 3f2f990..71ee79b 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -70,6 +70,10 @@ Required properties:
- rx
- tx
+optional properties:
+- smbalert-gpio: Must contain an entry for the gpio to be used as smbus alert.
+ It will be used only if optional smbus-alert property is present.
+
Example:
i2c@7000c000 {
--
2.7.4
Re: [Intel-gfx] [PATCH v2 11/16] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On 09-12-2021 13:17, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> wrote:
>> Now that we cannot unbind kill the currently locked object directly
> Can this be reworded slightly? Not sure what is meant by "unbind kill" here.
Oops, the word 'kill' doesn't belong here.
>> because we're removing short term pinning, we may have to unbind the
>> object from gtt manually, using a i915_gem_evict_vm() call.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index 65fc6ff5f59d..6d557bb9926f 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -357,8 +357,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
>> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> }
>>
>> - /* The entire mappable GGTT is pinned? Unexpected! */
>> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
>> + /*
>> +* The entire mappable GGTT is pinned? Unexpected!
>> +* Try to evict the object we locked too, as normally we
>> skip it
>> +* due to lack of short term pinning inside execbuf.
>> +*/
>> + if (vma == ERR_PTR(-ENOSPC)) {
>> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
>> + if (!ret) {
>> + ret = i915_gem_evict_vm(&ggtt->vm, &ww);
> Would it make sense to pass an extra flag for the above ggtt_pin(maybe
> PIN_EVICT_SHARED)? Such that evict_for_something can handle the
> already locked object and then also any vma sharing the same dma-resv
> object here? Or at least trying to nuke the entire vm, just for the
> mappable portion seems maybe overkill? Or perhaps we never expect to
> hit this in the real world?
>
> Reviewed-by: Matthew Auld
Yeah, effect would be the same though. When fully reworking eviction and vm
locks, it might be better to do so though.
>
>> + mutex_unlock(&ggtt->vm.mutex);
>> + }
>> + if (ret)
>> + goto err_reset;
>> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> + }
>> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
>> }
>> if (IS_ERR(vma)) {
>> ret = PTR_ERR(vma);
>> --
>> 2.34.0
>>
[PATCH v6 04/11] drm/i915/gt: Use to_gt() helper
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 10 +-
drivers/gpu/drm/i915/gt/selftest_context.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c| 4 ++--
drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c| 6 +++---
drivers/gpu/drm/i915/gt/selftest_gt_pm.c| 8
drivers/gpu/drm/i915/gt/selftest_hangcheck.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_migrate.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_reset.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +++---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +++---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c | 2 +-
23 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 8f8bea08e734..9ce85a845105 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
disabled |= (I915_SCHEDULER_CAP_ENABLED |
I915_SCHEDULER_CAP_PRIORITY);
- if (intel_uc_uses_guc_submission(&i915->gt.uc))
+ if (intel_uc_uses_guc_submission(&to_gt(i915)->uc))
enabled |= I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP;
for (i = 0; i < ARRAY_SIZE(map); i++) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index cbc6d2b1fd9e..f5c8fd3911b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1229,7 +1229,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
{
int ret;
- ret = ggtt_probe_hw(&i915->ggtt, &i915->gt);
+ ret = ggtt_probe_hw(&i915->ggtt, to_gt(i915));
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 07ff7ba7b2b7..36eb980d757e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
return 0;
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
- struct intel_ips *ips = &i915->gt.rps.ips;
+ struct intel_ips *ips = &to_gt(i915)->rps.ips;
spin_lock_irq(&mchdev_lock);
chipset_val = __ips_chipset_val(ips);
@@ -2329,7 +2329,7 @@ bool i915_gpu_raise(void)
if (!i915)
return false;
- rps = &i915->gt.rps;
+ rps = &to_gt(i915)->rps;
spin_lock_irq(&mchdev_lock);
if (rps->max_freq_softlimit < rps->max_freq)
@@ -2356,7 +2356,7 @@ bool i915_gpu_lower(void)
if (!i915)
return false;
- rps = &i915->gt.rps;
+ rps = &to_gt(i915)->rps;
spin_lock_irq(&mchdev_lock);
if (rps->max_freq_softlimit > rps->min_freq)
@@ -2382,7 +2382,7 @@ bool i915_gpu_busy(void)
if (!i915)
return false;
- ret = i915->gt.awake;
+ ret = to_gt(i915)->awake;
drm_dev_put(&i915->drm);
return ret;
@@ -2405,11 +2405,11 @@ bool i915_gpu_turbo_disable(void)
if (!i915)
return false;
- rps = &i915->gt.rps;
+ rps = &to_gt(i915)->rps;
spin_lock_irq(&mchdev_lock);
rps->max_freq_softlimit = rps->min_freq;
- ret = !__gen5_rps_set(&i915->gt.rps, rps->min_freq);
+ ret = !__gen5_rps_set(&to_gt(i915)->rps, rps->min_freq);
spin_unlock_irq(&mchdev_lock);
drm_dev_put(&i915->drm);
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3113266c286e..ab3277a3d593 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -929,7 +929,7 @@ hsw_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_
[PATCH] drm/i915: Don't leak the capture list items
When we recently converted the capture code to use vma snapshots,
we forgot to free the struct i915_capture_list list items after use.
Fix that by bringing back a kfree.
Fixes: ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the
current vma state")
Cc: Ramalingam C
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_request.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 471cde0e9883..fe682b6902aa 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -307,6 +307,7 @@ void i915_request_free_capture_list(struct
i915_capture_list *capture)
struct i915_capture_list *next = capture->next;
i915_vma_snapshot_put(capture->vma_snapshot);
+ kfree(capture);
capture = next;
}
}
--
2.31.1
[PATCH v4 1/6] Documentation/gpu: Reorganize DC documentation
Display core documentation is not well organized, and it is hard to find
information due to the lack of sections. This commit reorganizes the
documentation layout, and it is preparation work for future changes.
Changes since V1:
- Christian: Group amdgpu documentation together.
- Daniel: Drop redundant amdgpu prefix.
- Jani: Create index pages.
- Yann: Mirror display folder in the documentation.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu-dc.rst | 74 ---
Documentation/gpu/amdgpu/display/dc-debug.rst | 4 +
.../gpu/amdgpu/display/display-manager.rst| 42 +++
Documentation/gpu/amdgpu/display/index.rst| 29
.../gpu/{amdgpu.rst => amdgpu/index.rst} | 18 -
Documentation/gpu/drivers.rst | 3 +-
6 files changed, 91 insertions(+), 79 deletions(-)
delete mode 100644 Documentation/gpu/amdgpu-dc.rst
create mode 100644 Documentation/gpu/amdgpu/display/dc-debug.rst
create mode 100644 Documentation/gpu/amdgpu/display/display-manager.rst
create mode 100644 Documentation/gpu/amdgpu/display/index.rst
rename Documentation/gpu/{amdgpu.rst => amdgpu/index.rst} (96%)
diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst
deleted file mode 100644
index f7ff7e1309de..
--- a/Documentation/gpu/amdgpu-dc.rst
+++ /dev/null
@@ -1,74 +0,0 @@
-===
-drm/amd/display - Display Core (DC)
-===
-
-*placeholder - general description of supported platforms, what dc is, etc.*
-
-Because it is partially shared with other operating systems, the Display Core
-Driver is divided in two pieces.
-
-1. **Display Core (DC)** contains the OS-agnostic components. Things like
- hardware programming and resource management are handled here.
-2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the
- amdgpu base driver and DRM are implemented here.
-
-It doesn't help that the entire package is frequently referred to as DC. But
-with the context in mind, it should be clear.
-
-When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for
-supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line.
-Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`.
-
-To determine if DC is loaded, search dmesg for the following entry:
-
-``Display Core initialized with ``
-
-AMDgpu Display Manager
-==
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :doc: overview
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
- :internal:
-
-Lifecycle
--
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :doc: DM Lifecycle
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :functions: dm_hw_init dm_hw_fini
-
-Interrupts
---
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
- :doc: overview
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
- :internal:
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq
-
-Atomic Implementation
--
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :doc: atomic
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
-
-Display Core
-
-
-**WIP**
-
-FreeSync Video
---
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
- :doc: FreeSync Video
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst
b/Documentation/gpu/amdgpu/display/dc-debug.rst
new file mode 100644
index ..bbb8c3fc8eee
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dc-debug.rst
@@ -0,0 +1,4 @@
+Display Core Debug tools
+
+
+TODO
diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst
b/Documentation/gpu/amdgpu/display/display-manager.rst
new file mode 100644
index ..7ce31f89d9a0
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -0,0 +1,42 @@
+==
+AMDgpu Display Manager
+==
+
+.. contents:: Table of Contents
+:depth: 3
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+ :internal:
+
+Lifecycle
+=
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+ :doc: DM Lifecycle
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+ :functions: dm_hw_init dm_hw_fini
+
+Interrupts
+==
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgp
[PATCH v6 08/11] drm/i915/pxp: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 5d169624ad60..726c2b5a3fa3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -14,9 +14,11 @@
#include "intel_pxp_tee.h"
#include "intel_pxp_tee_interface.h"
-static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
+static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
{
- return &kdev_to_i915(i915_kdev)->gt.pxp;
+ struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
+
+ return &to_gt(i915)->pxp;
}
static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
--
2.34.1
[PATCH v4 2/6] Documentation/gpu: Document amdgpu_dm_visual_confirm debugfs entry
Display core provides a feature that makes it easy for users to debug Multiple planes by enabling a visual notification at the bottom of each plane. This commit introduces how to use such a feature. Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/display/dc-debug.rst | 34 ++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst index bbb8c3fc8eee..532cbbd64863 100644 --- a/Documentation/gpu/amdgpu/display/dc-debug.rst +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -1,4 +1,36 @@ + Display Core Debug tools -TODO +DC Debugfs +== + +Multiple Planes Debug +- + +If you want to enable or debug multiple planes in a specific user-space +application, you can leverage a debug feature named visual confirm. For +enabling it, you will need:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +You need to reload your GUI to see the visual confirmation. When the plane +configuration changes or a full update occurs there will be a colored bar at +the bottom of each hardware plane being drawn on the screen. + +* The color indicates the format - For example, red is AR24 and green is NV12 +* The height of the bar indicates the index of the plane +* Pipe split can be observed if there are two bars with a difference in height + covering the same plane + +Consider the video playback case in which a video is played in a specific +plane, and the desktop is drawn in another plane. The video plane should +feature one or two green bars at the bottom of the video depending on pipe +split configuration. + +* There should **not** be any visual corruption +* There should **not** be any underflow or screen flashes +* There should **not** be any black screens +* There should **not** be any cursor corruption +* Multiple plane **may** be briefly disabled during window transitions or + resizing but should come back after the action has finished -- 2.25.1
[PATCH v6 05/11] drm/i915/gem: Use to_gt() helper
From: Michał Winiarski
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 22
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++--
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 6 ++---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 12 -
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +--
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 10 +++
.../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 26 ++-
15 files changed, 55 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 347dab952e90..cad3f0b2be9e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct
drm_i915_private *i915,
* colateral damage, and we should not pretend we can by
* exposing the interface.
*/
- if (!intel_has_reset_engine(&i915->gt))
+ if (!intel_has_reset_engine(to_gt(i915)))
return -ENODEV;
pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
@@ -254,7 +254,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
if (!protected) {
pc->uses_protected_content = false;
- } else if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
+ } else if (!intel_pxp_is_enabled(&to_gt(i915)->pxp)) {
ret = -ENODEV;
} else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
@@ -268,8 +268,8 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
*/
pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
- if (!intel_pxp_is_active(&i915->gt.pxp))
- ret = intel_pxp_start(&i915->gt.pxp);
+ if (!intel_pxp_is_active(&to_gt(i915)->pxp))
+ ret = intel_pxp_start(&to_gt(i915)->pxp);
}
return ret;
@@ -571,7 +571,7 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
intel_engine_mask_t prev_mask;
/* FIXME: This is NIY for execlists */
- if (!(intel_uc_uses_guc_submission(&i915->gt.uc)))
+ if (!(intel_uc_uses_guc_submission(&to_gt(i915)->uc)))
return -ENODEV;
if (get_user(slot, &ext->engine_index))
@@ -833,7 +833,7 @@ static int set_proto_ctx_sseu(struct drm_i915_file_private
*fpriv,
sseu = &pc->legacy_rcs_sseu;
}
- ret = i915_gem_user_to_context_sseu(&i915->gt, &user_sseu, sseu);
+ ret = i915_gem_user_to_context_sseu(to_gt(i915), &user_sseu, sseu);
if (ret)
return ret;
@@ -1044,7 +1044,7 @@ static struct i915_gem_engines *alloc_engines(unsigned
int count)
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
struct intel_sseu rcs_sseu)
{
- const struct intel_gt *gt = &ctx->i915->gt;
+ const struct intel_gt *gt = to_gt(ctx->i915);
struct intel_engine_cs *engine;
struct i915_gem_engines *e, *err;
enum intel_engine_id id;
@@ -1521,7 +1521,7 @@ static int __context_set_persistence(struct
i915_gem_context *ctx, bool state)
* colateral damage, and we should not pretend we can by
* exposing the interface.
*/
- if (!intel_has_reset_engine(&ctx->i915->gt))
+ if (!intel_has_reset_engine(to_gt(ctx->i915)))
return -ENODEV;
i915_gem_context_clear_persistence(ctx);
@@ -1559,7 +1559,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(&i915->gt, 0);
+ ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt)) {
drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1742,7 +1742,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (args->flags)
return -EINVA
[PATCH v6 07/11] drm/i915/selftests: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 6 ++--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +--
drivers/gpu/drm/i915/selftests/i915_perf.c| 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 10 +++
.../gpu/drm/i915/selftests/i915_selftest.c| 4 +--
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
.../gpu/drm/i915/selftests/igt_live_test.c| 4 +--
.../drm/i915/selftests/intel_memory_region.c | 4 +--
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 30 +--
drivers/gpu/drm/i915/selftests/mock_gtt.c | 6 ++--
drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
14 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 61bf4560d8af..2dac9be1de58 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -254,7 +254,7 @@ int i915_active_live_selftests(struct drm_i915_private
*i915)
SUBTEST(live_active_barrier),
};
- if (intel_gt_is_wedged(&i915->gt))
+ if (intel_gt_is_wedged(to_gt(i915)))
return 0;
return i915_subtests(tests, i915);
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 152d9ab135b1..b5576888cd78 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -248,7 +248,7 @@ int i915_gem_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_gem_ww_ctx),
};
- if (intel_gt_is_wedged(&i915->gt))
+ if (intel_gt_is_wedged(to_gt(i915)))
return 0;
return i915_live_subtests(tests, i915);
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 7e0658a77659..75b709c26dd3 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -545,7 +545,7 @@ int i915_gem_evict_mock_selftests(void)
return -ENOMEM;
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
- err = i915_subtests(tests, &i915->gt);
+ err = i915_subtests(tests, to_gt(i915));
mock_destroy_device(i915);
return err;
@@ -557,8 +557,8 @@ int i915_gem_evict_live_selftests(struct drm_i915_private
*i915)
SUBTEST(igt_evict_contexts),
};
- if (intel_gt_is_wedged(&i915->gt))
+ if (intel_gt_is_wedged(to_gt(i915)))
return 0;
- return intel_gt_live_subtests(tests, &i915->gt);
+ return intel_gt_live_subtests(tests, to_gt(i915));
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 46f4236039a9..48123c3e1ff0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -155,7 +155,7 @@ static int igt_ppgtt_alloc(void *arg)
if (!HAS_PPGTT(dev_priv))
return 0;
- ppgtt = i915_ppgtt_create(&dev_priv->gt, 0);
+ ppgtt = i915_ppgtt_create(to_gt(dev_priv), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1053,7 +1053,7 @@ static int exercise_ppgtt(struct drm_i915_private
*dev_priv,
if (IS_ERR(file))
return PTR_ERR(file);
- ppgtt = i915_ppgtt_create(&dev_priv->gt, 0);
+ ppgtt = i915_ppgtt_create(to_gt(dev_priv), 0);
if (IS_ERR(ppgtt)) {
err = PTR_ERR(ppgtt);
goto out_free;
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index 9e9a6cb1d9e5..88db2e3d81d0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -424,7 +424,7 @@ int i915_perf_live_selftests(struct drm_i915_private *i915)
if (!perf->metrics_kobj || !perf->ops.enable_metric_set)
return 0;
- if (intel_gt_is_wedged(&i915->gt))
+ if (intel_gt_is_wedged(to_gt(i915)))
return 0;
err = alloc_empty_config(&i915->perf);
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 9979ef9197cd..92a859b34190 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -841,7 +841,7 @@ static struct i915_vma *empty_batch(struct drm_i915_private
*i915)
__i915_gem_object_flush_map(obj, 0, 64);
i915_gem_object_unpin_map(obj);
- intel_gt_c
[PATCH v4 10/16] drm/i915/migrate: add acceleration support for DG2
From: Matthew Auld
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 189 +++-
1 file changed, 150 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 64ffaacac1e0..0fb83d0bec91 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -33,6 +33,38 @@ static bool engine_supports_migration(struct intel_engine_cs
*engine)
return true;
}
+static void xehpsdv_toggle_pdes(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data)
+{
+ struct insert_pte_data *d = data;
+
+ /*
+* Insert a dummy PTE into every PT that will map to LMEM to ensure
+* we have a correctly setup PDE structure for later use.
+*/
+ vm->insert_page(vm, 0, d->offset, I915_CACHE_NONE, PTE_LM);
+ GEM_BUG_ON(!pt->is_compact);
+ d->offset += SZ_2M;
+}
+
+static void xehpsdv_insert_pte(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data)
+{
+ struct insert_pte_data *d = data;
+
+ /*
+* We are playing tricks here, since the actual pt, from the hw
+* pov, is only 256bytes with 32 entries, or 4096bytes with 512
+* entries, but we are still guaranteed that the physical
+* alignment is 64K underneath for the pt, and we are careful
+* not to access the space in the void.
+*/
+ vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE, PTE_LM);
+ d->offset += SZ_64K;
+}
+
static void insert_pte(struct i915_address_space *vm,
struct i915_page_table *pt,
void *data)
@@ -75,7 +107,12 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
* i.e. within the same non-preemptible window so that we do not switch
* to another migration context that overwrites the PTE.
*
-* TODO: Add support for huge LMEM PTEs
+* On platforms with HAS_64K_PAGES support we have three windows, and
+* dedicate two windows just for mapping lmem pages(smem <-> smem is not
+* a thing), since we are forced to use 64K GTT pages underneath which
+* requires also modifying the PDE. An alternative might be to instead
+* map the PD into the GTT, and then on the fly toggle the 4K/64K mode
+* in the PDE from the same batch that also modifies the PTEs.
*/
vm = i915_ppgtt_create(gt, I915_BO_ALLOC_PM_EARLY);
@@ -87,6 +124,9 @@ static struct i915_address_space *migrate_vm(struct intel_gt
*gt)
goto err_vm;
}
+ if (HAS_64K_PAGES(gt->i915))
+ stash.pt_sz = I915_GTT_PAGE_SIZE_64K;
+
/*
* Each engine instance is assigned its own chunk in the VM, so
* that we can run multiple instances concurrently
@@ -106,14 +146,20 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
* We copy in 8MiB chunks. Each PDE covers 2MiB, so we need
* 4x2 page directories for source/destination.
*/
- sz = 2 * CHUNK_SZ;
+ if (HAS_64K_PAGES(gt->i915))
+ sz = 3 * CHUNK_SZ;
+ else
+ sz = 2 * CHUNK_SZ;
d.offset = base + sz;
/*
* We need another page directory setup so that we can write
* the 8x512 PTE in each chunk.
*/
- sz += (sz >> 12) * sizeof(u64);
+ if (HAS_64K_PAGES(gt->i915))
+ sz += (sz / SZ_2M) * SZ_64K;
+ else
+ sz += (sz >> 12) * sizeof(u64);
err = i915_vm_alloc_pt_stash(&vm->vm, &stash, sz);
if (err)
@@ -134,7 +180,18 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
goto err_vm;
/* Now allow the GPU to rewrite the PTE via its own ppGTT */
- vm->vm.foreach(&vm->vm, base, d.offset - base, insert_pte, &d);
+ if (HAS_64K_PAGES(gt->i915)) {
+ vm->vm.foreach(&vm->vm, base, d.offset - base,
+ xehpsdv_insert_pte, &d);
+ d.offset = base + CHUNK_SZ;
+ vm->vm.foreach(&vm->vm,
+ d.offset,
+ 2 * CHUNK_SZ,
+ xehpsdv_toggle_pdes, &d);
+ } else {
+ vm->vm.foreach(&v
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
RE: [PATCH 2/2] drm/i915/dg2: Tile 4 plane format support
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Thursday, December 9, 2021 5:47 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Lisovskiy, Stanislav
> ; Saarinen, Jani ; C,
> Ramalingam ; ville.syrj...@linux.intel.com; Deak,
> Imre ; Chery, Nanley G
> Subject: [PATCH 2/2] drm/i915/dg2: Tile 4 plane format support
>
> Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic
> shape
> as for legacy TileY which will be supported by Display13.
>
> v2: - Moved Tile4 assocating struct for modifier/display to
> the beginning(Imre Deak)
> - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> checks(Imre Deak)
> - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> (Imre Deak)
>
> v3: - Rebased patch on top of new changes related to plane_caps.
> - Added static assert to check that PLANE_CTL_TILING_YF
> matches PLANE_CTL_TILING_4(Nanley Chery)
> - Fixed naming and layout description for Tile 4 in drm uapi
> header(Nanley Chery)
>
> v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
>
Oh, when we discussed this I didn't realize until later that you were asking
for feedback on whether or not the fourcc changes needed to be split out.
I think either way (combined or separate) is fine. Sorry for the confusion.
-Nanley
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Stanislav Lisovskiy
> Signed-off-by: Matt Roper
> Signed-off-by: Juha-Pekka Heikkilä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
> drivers/gpu/drm/i915/display/intel_fb.h | 1 +
> drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
> .../drm/i915/display/intel_plane_initial.c| 1 +
> .../drm/i915/display/skl_universal_plane.c| 23 ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> 11 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 128d4943a43b..83253c62b6d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -,6 +,7 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state, struct int
> case I915_FORMAT_MOD_X_TILED:
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> + case I915_FORMAT_MOD_4_TILED:
> break;
> default:
> drm_dbg_kms(&i915->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 23cfe2e5ce2a..94c57facbb46 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -135,11 +135,16 @@ struct intel_modifier_desc {
>INTEL_PLANE_CAP_CCS_MC)
> #define INTEL_PLANE_CAP_TILING_MASK (INTEL_PLANE_CAP_TILING_X
> | \
>INTEL_PLANE_CAP_TILING_Y | \
> - INTEL_PLANE_CAP_TILING_Yf)
> + INTEL_PLANE_CAP_TILING_Yf | \
> + INTEL_PLANE_CAP_TILING_4)
> #define INTEL_PLANE_CAP_TILING_NONE 0
>
> static const struct intel_modifier_desc intel_modifiers[] = {
> {
> + .modifier = I915_FORMAT_MOD_4_TILED,
> + .display_ver = { 13, 13 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4,
> + }, {
> .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> .display_ver = { 12, 13 },
> .plane_caps = INTEL_PLANE_CAP_TILING_Y |
> INTEL_PLANE_CAP_CCS_MC, @@ -545,6 +550,12 @@
> intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane)
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_4_TILED:
> + /*
> + * Each 4K tile consists of 64B(8*8) subtiles, with
> + * same shape as Y Tile(i.e 4*16B OWords)
> + */
> + return 128;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> return 128;
> @@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> fb_modifier)
> return I915_TILING_Y;
> case INTEL_PLANE_CAP_TILING_X:
> return I915_TILING_X;
> + case INTEL_PLANE_CAP_TILING_4:
> case INTEL_PLANE_CAP_TILING_Yf:
> case INTEL_PLANE_CAP_TILING_NONE:
> return I915_TILING_NONE;
> @
[PATCH v4 4/6] Documentation/gpu: How to collect DTN log
Introduce how to collect DTN log from debugfs. Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/display/dc-debug.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst index 6dbd21f7f59e..40c55a618918 100644 --- a/Documentation/gpu/amdgpu/display/dc-debug.rst +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -58,3 +58,20 @@ In this case, if you have a pipe split, you will see one small red bar at the bottom of the display covering the entire display width and another bar covering the second pipe. In other words, you will see a bit high bar in the second pipe. + +DTN Debug += + +DC (DCN) provides an extensive log that dumps multiple details from our +hardware configuration. Via debugfs, you can capture those status values by +using Display Test Next (DTN) log, which can be captured via debugfs by using:: + + cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +Since this log is updated accordingly with DCN status, you can also follow the +change in real-time by using something like:: + + sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +When reporting a bug related to DC, consider attaching this log before and +after you reproduce the bug. -- 2.25.1
[PATCH v6 06/11] drm/i915/gvt: Use to_gt() helper
From: Michał Winiarski Use to_gt() helper consistently throughout the codebase. Pure mechanical s/i915->gt/to_gt(i915). No functional changes. Signed-off-by: Michał Winiarski Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gvt/gvt.c | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c index cbac409f6c8a..f0b69e4dcb52 100644 --- a/drivers/gpu/drm/i915/gvt/gvt.c +++ b/drivers/gpu/drm/i915/gvt/gvt.c @@ -205,7 +205,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915) spin_lock_init(&gvt->scheduler.mmio_context_lock); mutex_init(&gvt->lock); mutex_init(&gvt->sched_lock); - gvt->gt = &i915->gt; + gvt->gt = to_gt(i915); i915->gvt = gvt; init_device_info(gvt); diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index 6c804102528b..42a0c9ae0a73 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -1386,7 +1386,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu) enum intel_engine_id i; int ret; - ppgtt = i915_ppgtt_create(&i915->gt, I915_BO_ALLOC_PM_EARLY); + ppgtt = i915_ppgtt_create(to_gt(i915), I915_BO_ALLOC_PM_EARLY); if (IS_ERR(ppgtt)) return PTR_ERR(ppgtt); -- 2.34.1
[PATCH v4 0/6] Expand display core documentation
Display Core (DC) is one of the components under amdgpu, and it has
multiple features directly related to the KMS API. Unfortunately, we
don't have enough documentation about DC in the upstream, which makes
the life of some external contributors a little bit more challenging.
For these reasons, this patchset reworks part of the DC documentation
and introduces a new set of details on how the display core works on DCN
IP. Another improvement that this documentation effort tries to bring is
making explicit some of our hardware-specific details to guide
user-space developers better.
In my view, it is easier to review this series if you apply it in your
local kernel and build the HTML version (make htmldocs). I'm suggesting
this approach because I added a few SVG diagrams that will be easier to
see in the HTML version. If you cannot build the documentation, try to
open the SVG images while reviewing the content. In summary, in this
series, you will find:
1. Patch 1: Re-arrange of display core documentation. This is
preparation work for the other patches, but it is also a way to expand
this documentation.
2. Patch 2 to 4: Document some common debug options related to display.
3. Patch 5: This patch provides an overview of how our display core next
works and a brief explanation of each component.
4. Patch 6: We use a lot of acronyms in our driver; for this reason, we
exposed a glossary with common terms used by display core.
Please let us know what you think we can improve this series and what
kind of content you want to see for the next series.
Changes since V3:
- Add new acronyms to amdgpu glossary
- Add link between dc and amdgpu glossary
Changes since V2:
- Add a comment about MMHUBBUB
Changes since V1:
- Group amdgpu documentation together.
- Create index pages.
- Mirror display folder in the documentation.
- Divide glossary based on driver context.
- Make terms more consistent and update CPLIB
- Add new acronyms to the glossary
Thanks
Siqueira
Rodrigo Siqueira (6):
Documentation/gpu: Reorganize DC documentation
Documentation/gpu: Document amdgpu_dm_visual_confirm debugfs entry
Documentation/gpu: Document pipe split visual confirmation
Documentation/gpu: How to collect DTN log
Documentation/gpu: Add basic overview of DC pipeline
Documentation/gpu: Add amdgpu and dc glossary
Documentation/gpu/amdgpu-dc.rst | 74 --
Documentation/gpu/amdgpu/amdgpu-glossary.rst | 87 ++
.../gpu/amdgpu/display/config_example.svg | 414 ++
Documentation/gpu/amdgpu/display/dc-debug.rst | 77 ++
.../gpu/amdgpu/display/dc-glossary.rst| 237
.../amdgpu/display/dc_pipeline_overview.svg | 1125 +
.../gpu/amdgpu/display/dcn-overview.rst | 171 +++
.../gpu/amdgpu/display/display-manager.rst| 42 +
.../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++
Documentation/gpu/amdgpu/display/index.rst| 29 +
.../gpu/{amdgpu.rst => amdgpu/index.rst} | 25 +-
Documentation/gpu/drivers.rst |3 +-
12 files changed, 2690 insertions(+), 79 deletions(-)
delete mode 100644 Documentation/gpu/amdgpu-dc.rst
create mode 100644 Documentation/gpu/amdgpu/amdgpu-glossary.rst
create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg
create mode 100644 Documentation/gpu/amdgpu/display/dc-debug.rst
create mode 100644 Documentation/gpu/amdgpu/display/dc-glossary.rst
create mode 100644 Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg
create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst
create mode 100644 Documentation/gpu/amdgpu/display/display-manager.rst
create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg
create mode 100644 Documentation/gpu/amdgpu/display/index.rst
rename Documentation/gpu/{amdgpu.rst => amdgpu/index.rst} (95%)
--
2.25.1
[PATCH v4 14/16] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 67 ++---
1 file changed, 62 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..b7441593434c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,62 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* **DG2 64K min page size implications:**
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* **Special DG2 GTT address alignment requirement:**
+*
+* The GTT alignment will also need be at least 64K for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE(which covers a 2M virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To handle the above the kernel implements a memory coloring scheme to
+* prevent userspace from mixing I915_MEMORY_CLASS_DEVICE and
+* I915_MEMORY_CLASS_SYSTEM objects in the same PDE. If the kernel is
+* ever unable to evict the required pages for the given PDE(different
+* color) when inserting the object into the GTT then it will simply
+* fail the request.
+*
+* Since userspace needs to manage the GTT address space themselves,
+* special care is needed to ensure this doesn't happen. The simplest
+* scheme is to simply align and round up all I915_MEMORY_CLASS_DEVICE
+* objects to 2M, which avoids any issues here. At the very least this
+* is likely needed for objects that can be placed in both
+* I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM, to avoid
+* potential issues when the kernel needs to migrate the object behind
+* the scenes, since that might also involve evicting other objects.
+*
+* **To summarise the GTT rules, on platforms like DG2:**
+*
+* 1) All objects that can be placed in I915_MEMORY_CLASS_DEVICE must
+* have 64K alignment. The kernel will reject this otherwise.
+*
+* 2) All I915_MEMORY_CLASS_DEVICE objects must never be placed in
+* the same PDE with other I915_MEMORY_CLASS_SYSTEM objects. The
+* kernel will reject this otherwise.
+*
+* 3) Objects that can be placed in both I915_MEMORY_CLASS_DEVICE and
Re: [Intel-gfx] [PATCH] drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices
On 09/12/2021 00:24, John Harrison wrote:
On 12/8/2021 09:58, Robert Beckett wrote:
On 07/12/2021 23:15, John Harrison wrote:
On 12/7/2021 09:53, Adrian Larumbe wrote:
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error
handling in
the FW init and load functions so that the driver's probe() function
will
fail if GuC could not be loaded.
We still need to load the i915 driver in fall back mode (display but
no engines) if the GuC is missing. Otherwise you may have just
bricked the user's device.
good point, well made.
though this still seems like an issue for gen12+ (excluding rkl and adl).
maybe a redesign of toplevel driver probe, with
i915_driver_early_probe before i915_driver_create could work. If the
GuC fw is not found, it could then register a new kms only version of
i915_drm_driver.
or something like like that ...
Or we could just leave it all alone?
AFAIK, this is working just fine at the moment. If the platform default
is to use GuC submission and you have the fw then the driver loads fine.
If the platform default is to use GuC submission and you don't have the
firmware then the driver wedges but keeps loading. That means it returns
no engines to userland but the display is unaffected. Hence the user
gets a slow but safe fallback path in which they can still load their
Ubuntu desktop and try to work out what package they need to install.
What is the problem that this patch is trying to fix?
In dg2 enablement branch, when fw was unavailable, submissions could
still be attempted and it would segfault the kernel due to some function
pointers not being set up.
From what you said, it sounds like this may just be a bug in the dg2
enablement, which we can diagnose and fix if so.
Though I still think it would be a better design to only register kms
capabilities if that is all that will be supported without the fw. It
seems a bit messy to advertise render and create the render node for
userland sw to attempt to use and have it fail, but if that is the
prefered design, then we can make dg2 match that.
John.
Also, we do want to be able to disable the GuC via the enable_guc
module parameter.
John.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7660eba893fa..8b0778b6d9ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -277,14 +277,19 @@ static void guc_disable_communication(struct
intel_guc *guc)
drm_dbg(&i915->drm, "GuC communication disabled\n");
}
-static void __uc_fetch_firmwares(struct intel_uc *uc)
+static int __uc_fetch_firmwares(struct intel_uc *uc)
{
+ struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
GEM_BUG_ON(!intel_uc_wants_guc(uc));
err = intel_uc_fw_fetch(&uc->guc.fw);
if (err) {
+ /* GuC is mandatory on Gen12 and beyond */
+ if (GRAPHICS_VER(i915) >= 12)
+ return err;
+
/* Make sure we transition out of transient "SELECTED"
state */
if (intel_uc_wants_huc(uc)) {
drm_dbg(&uc_to_gt(uc)->i915->drm,
@@ -293,11 +298,13 @@ static void __uc_fetch_firmwares(struct
intel_uc *uc)
INTEL_UC_FIRMWARE_ERROR);
}
- return;
+ return 0;
}
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(&uc->huc.fw);
+
+ return 0;
}
static void __uc_cleanup_firmwares(struct intel_uc *uc)
@@ -308,14 +315,19 @@ static void __uc_cleanup_firmwares(struct
intel_uc *uc)
static int __uc_init(struct intel_uc *uc)
{
+ struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
struct intel_guc *guc = &uc->guc;
struct intel_huc *huc = &uc->huc;
int ret;
GEM_BUG_ON(!intel_uc_wants_guc(uc));
- if (!intel_uc_uses_guc(uc))
- return 0;
+ if (!intel_uc_uses_guc(uc)) {
+ if (GRAPHICS_VER(i915) >= 12)
+ return -EINVAL;
+ else
+ return 0;
+ }
if (i915_inject_probe_failure(uc_to_gt(uc)->i915))
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 866b462821c0..3bcd781447bc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -17,7 +17,7 @@ struct intel_uc;
struct intel_uc_ops {
int (*sanitize)(struct intel_uc *uc);
- void (*init_fw)(struct intel_uc *uc);
+ int (*init_fw)(struct intel_uc *uc);
void (*fini_fw)(struct intel_uc *uc);
int (*init)(struct intel_uc *uc);
void (*fini)(struct intel_uc *uc);
@@ -104,7 +104,7 @@ static inline _TYPE intel_uc_##
[PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions
Emulate the SMBus block read using ContinueXfer and SMBus using GPIO
interrupt.
For SMBus block read, the driver reads the first byte with ContinueXfer
set which will help to parse the data count and read the remaining bytes
without stop condition in between.
SMBus alert is implemented using external gpio interrupt.
Signed-off-by: Akhil R
---
drivers/i2c/busses/i2c-tegra.c | 54 +-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index a5be8f0..3b70013 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -226,6 +227,11 @@ struct tegra_i2c_hw_feature {
bool has_interface_timing_reg;
};
+struct tegra_i2c_smbalert {
+ struct i2c_smbus_alert_setup alert_data;
+ struct i2c_client *ara;
+};
+
/**
* struct tegra_i2c_dev - per device I2C context
* @dev: device reference for power management
@@ -280,6 +286,8 @@ struct tegra_i2c_dev {
int msg_err;
u8 *msg_buf;
+ struct tegra_i2c_smbalert smbalert;
+
struct completion dma_complete;
struct dma_chan *tx_dma_chan;
struct dma_chan *rx_dma_chan;
@@ -1232,6 +1240,11 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
return err;
i2c_dev->msg_buf = msg->buf;
+
+ /* The condition true implies smbus block read and len is already read*/
+ if (msg->flags & I2C_M_RECV_LEN && end_state != MSG_END_CONTINUE)
+ i2c_dev->msg_buf = msg->buf + 1;
+
i2c_dev->msg_buf_remaining = msg->len;
i2c_dev->msg_err = I2C_ERR_NONE;
i2c_dev->msg_read = !!(msg->flags & I2C_M_RD);
@@ -1388,6 +1401,15 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg msgs[],
else
end_type = MSG_END_REPEAT_START;
}
+ /* If M_RECV_LEN use ContinueXfer to read the first byte */
+ if (msgs[i].flags & I2C_M_RECV_LEN) {
+ ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i],
MSG_END_CONTINUE);
+ if (ret)
+ break;
+ /* Set the read byte as msg len */
+ msgs[i].len = msgs[i].buf[0];
+ dev_dbg(i2c_dev->dev, "reading %d bytes\n",
msgs[i].len);
+ }
ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type);
if (ret)
break;
@@ -1415,7 +1437,8 @@ static u32 tegra_i2c_func(struct i2c_adapter *adap)
{
struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
u32 ret = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
- I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
+ I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_10BIT_ADDR |
+ I2C_FUNC_PROTOCOL_MANGLING;
if (i2c_dev->hw->has_continue_xfer_support)
ret |= I2C_FUNC_NOSTART;
@@ -1727,6 +1750,29 @@ static int tegra_i2c_init_hardware(struct tegra_i2c_dev
*i2c_dev)
return ret;
}
+static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
+{
+ struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert;
+ struct gpio_desc *alert_gpiod;
+ struct i2c_client *ara;
+
+ alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN);
+ if (IS_ERR(alert_gpiod))
+ return PTR_ERR(alert_gpiod);
+
+ smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod);
+ if (smbalert->alert_data.irq <= 0)
+ return smbalert->alert_data.irq;
+
+ ara = i2c_new_smbus_alert_device(&i2c_dev->adapter,
&smbalert->alert_data);
+ if (IS_ERR(ara))
+ return PTR_ERR(ara);
+
+ smbalert->ara = ara;
+
+ return 0;
+}
+
static int tegra_i2c_probe(struct platform_device *pdev)
{
struct tegra_i2c_dev *i2c_dev;
@@ -1821,6 +1867,12 @@ static int tegra_i2c_probe(struct platform_device *pdev)
if (err)
goto release_rpm;
+ if (device_property_read_bool(i2c_dev->dev, "smbus-alert")) {
+ err = tegra_i2c_setup_smbalert(i2c_dev);
+ if (err)
+ dev_warn(&pdev->dev, "smbus-alert setup failed: %d\n",
err);
+ }
+
return 0;
release_rpm:
--
2.7.4
Re: [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind
On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst
wrote:
>
> On 09-12-2021 14:05, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> > wrote:
> >> We want to remove more members of i915_vma, which requires the locking to
> >> be
> >> held more often.
> >>
> >> Start requiring gem object lock for i915_vma_unbind, as it's one of the
> >> callers that may unpin pages.
> >>
> >> Some special care is needed when evicting, because the last reference to
> >> the
> >> object may be held by the VMA, so after __i915_vma_unbind, vma may be
> >> garbage,
> >> and we need to cache vma->obj before unlocking.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >
> >
> >> @@ -129,22 +129,47 @@ void i915_ggtt_suspend_vm(struct i915_address_space
> >> *vm)
> >>
> >> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
> >>
> >> +retry:
> >> + i915_gem_drain_freed_objects(vm->i915);
> >> +
> >> mutex_lock(&vm->mutex);
> >>
> >> /* Skip rewriting PTE on VMA unbind. */
> >> open = atomic_xchg(&vm->open, 0);
> >>
> >> list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
> >> + struct drm_i915_gem_object *obj = vma->obj;
> >> +
> >> GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
> >> +
> >> i915_vma_wait_for_bind(vma);
> >>
> >> - if (i915_vma_is_pinned(vma))
> >> + if (i915_vma_is_pinned(vma) || !i915_vma_is_bound(vma,
> >> I915_VMA_GLOBAL_BIND))
> >> continue;
> >>
> >> - if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
> >> - __i915_vma_evict(vma);
> >> - drm_mm_remove_node(&vma->node);
> >> + /* unlikely to race when GPU is idle, so no worry about
> >> slowpath.. */
> >> + if (!i915_gem_object_trylock(obj, NULL)) {
> >> + atomic_set(&vm->open, open);
> > Does this need a comment about barriers?
> Not sure, it's guarded by vm->mutex.
> >> +
> >> + i915_gem_object_get(obj);
> > Should this not be kref_get_unless_zero? Assuming the vm->mutex is the
> > only thing keeping the object alive here, won't this lead to potential
> > uaf/double-free or something? Also should we not plonk this before the
> > trylock? Or maybe I'm missing something here?
>
> Normally you're correct, this is normally the case, but we drain freed
> objects and this path should only be run during s/r, at which point userspace
> should be dead, GPU idle, and we just drained all freed objects above.
>
> It would be a bug if we still found a dead object, as nothing should be
> running.
Hmm, Ok. So why do we expect the trylock to ever fail here? Who else
can grab it at this stage?
>
> >> + mutex_unlock(&vm->mutex);
> >> +
> >> + i915_gem_object_lock(obj, NULL);
> >> + open = i915_vma_unbind(vma);
> >> + i915_gem_object_unlock(obj);
> >> +
> >> + GEM_WARN_ON(open);
> >> +
> >> + i915_gem_object_put(obj);
> >> + goto retry;
> >> }
> >> +
> >> + i915_vma_wait_for_bind(vma);
> > We also call wait_for_bind above, is that intentional?
>
> Should be harmless, but first one should probably be removed. :)
>
[PATCH v4 5/6] Documentation/gpu: Add basic overview of DC pipeline
This commit describes how DCN works by providing high-level diagrams with an explanation of each component. In particular, it details the Global Sync signals. Change since V2: - Add a comment about MMHUBBUB. Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/display/config_example.svg | 414 ++ .../amdgpu/display/dc_pipeline_overview.svg | 1125 + .../gpu/amdgpu/display/dcn-overview.rst | 171 +++ .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++ Documentation/gpu/amdgpu/display/index.rst| 23 +- 5 files changed, 2206 insertions(+), 12 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg create mode 100644 Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index ..cdac9858601c --- /dev/null +++ b/Documentation/gpu/amdgpu/display/config_example.svg @@ -0,0 +1,414 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="144.63406mm" + height="66.596054mm" + viewBox="0 0 144.15195 66.596054" + version="1.1" + id="svg8" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="config_example.svg"> + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + + + +Configurations +A +B +C + + + + + +A +B +C +C +Old config +Old config + + +VUpdate +UpdateLock +Register updatePending Status +Buf 0 +Buf 1 + + diff --git a/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg new file mode 100644 index ..9adecebfe65b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg @@ -0,0 +1,1125 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="1296.7491" + height="741.97845" + viewBox="0 0 343.0982 196.31514" + version="1.1" + id="svg8" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="dc_pipeline_overview.svg"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + DCHUB + HUBP(n) + + + DPP(n) + + + + MPC + + + + OPTC + + + + DIO + + + + DCCG + + + + DMU + + + + + AZ + + + + MMHUBBUB + + + + DWB(n) + + + + + + + + + + + + +Global sync +Pixel data +Sideband signal +Config. Bus + +SDP + +Monitor + + OPP + + + + + + + + + + + + +dc_plane +dc_stream + + + +dc_state + + + +Code struct + + + +dc_link + + + +Floating pointcalculation + + + +bit-depthreduction/dither +} +Notes + + diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst new file mode 100644 index ..f98624d7828e --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,171 @@ +
Re: [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions
09.12.2021 18:05, Akhil R пишет:
> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
> +{
> + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert;
> + struct gpio_desc *alert_gpiod;
> + struct i2c_client *ara;
> +
> + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN);
> + if (IS_ERR(alert_gpiod))
> + return PTR_ERR(alert_gpiod);
> +
> + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod);
> + if (smbalert->alert_data.irq <= 0)
> + return smbalert->alert_data.irq;
0 is the error condition.
Re: [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind
On 09-12-2021 14:05, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> wrote:
>> We want to remove more members of i915_vma, which requires the locking to be
>> held more often.
>>
>> Start requiring gem object lock for i915_vma_unbind, as it's one of the
>> callers that may unpin pages.
>>
>> Some special care is needed when evicting, because the last reference to the
>> object may be held by the VMA, so after __i915_vma_unbind, vma may be
>> garbage,
>> and we need to cache vma->obj before unlocking.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>
>
>> @@ -129,22 +129,47 @@ void i915_ggtt_suspend_vm(struct i915_address_space
>> *vm)
>>
>> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
>>
>> +retry:
>> + i915_gem_drain_freed_objects(vm->i915);
>> +
>> mutex_lock(&vm->mutex);
>>
>> /* Skip rewriting PTE on VMA unbind. */
>> open = atomic_xchg(&vm->open, 0);
>>
>> list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
>> + struct drm_i915_gem_object *obj = vma->obj;
>> +
>> GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
>> +
>> i915_vma_wait_for_bind(vma);
>>
>> - if (i915_vma_is_pinned(vma))
>> + if (i915_vma_is_pinned(vma) || !i915_vma_is_bound(vma,
>> I915_VMA_GLOBAL_BIND))
>> continue;
>>
>> - if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
>> - __i915_vma_evict(vma);
>> - drm_mm_remove_node(&vma->node);
>> + /* unlikely to race when GPU is idle, so no worry about
>> slowpath.. */
>> + if (!i915_gem_object_trylock(obj, NULL)) {
>> + atomic_set(&vm->open, open);
> Does this need a comment about barriers?
Not sure, it's guarded by vm->mutex.
>> +
>> + i915_gem_object_get(obj);
> Should this not be kref_get_unless_zero? Assuming the vm->mutex is the
> only thing keeping the object alive here, won't this lead to potential
> uaf/double-free or something? Also should we not plonk this before the
> trylock? Or maybe I'm missing something here?
Normally you're correct, this is normally the case, but we drain freed objects
and this path should only be run during s/r, at which point userspace should be
dead, GPU idle, and we just drained all freed objects above.
It would be a bug if we still found a dead object, as nothing should be running.
>> + mutex_unlock(&vm->mutex);
>> +
>> + i915_gem_object_lock(obj, NULL);
>> + open = i915_vma_unbind(vma);
>> + i915_gem_object_unlock(obj);
>> +
>> + GEM_WARN_ON(open);
>> +
>> + i915_gem_object_put(obj);
>> + goto retry;
>> }
>> +
>> + i915_vma_wait_for_bind(vma);
> We also call wait_for_bind above, is that intentional?
Should be harmless, but first one should probably be removed. :)
[PATCH] i2c: tegra: use i2c_timings for bus clock freq
Use i2c_timings struct and corresponding methods to get bus clock frequency
Signed-off-by: Akhil R
---
drivers/i2c/busses/i2c-tegra.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
The patch is in response to the discussion in a previous patch to use
i2c_timings struct for bus freq.
ref. https://lkml.org/lkml/2021/11/25/767
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index a5be8f0..ffd2ad2 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -246,7 +246,7 @@ struct tegra_i2c_hw_feature {
* @msg_buf: pointer to current message data
* @msg_buf_remaining: size of unsent data in the message buffer
* @msg_read: indicates that the transfer is a read access
- * @bus_clk_rate: current I2C bus clock rate
+ * @timings: i2c timings information like bus frequency
* @multimaster_mode: indicates that I2C controller is in multi-master mode
* @tx_dma_chan: DMA transmit channel
* @rx_dma_chan: DMA receive channel
@@ -273,7 +273,7 @@ struct tegra_i2c_dev {
unsigned int nclocks;
struct clk *div_clk;
- u32 bus_clk_rate;
+ struct i2c_timings timings;
struct completion msg_complete;
size_t msg_buf_remaining;
@@ -642,14 +642,14 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
if (i2c_dev->is_vi)
tegra_i2c_vi_init(i2c_dev);
- switch (i2c_dev->bus_clk_rate) {
+ switch (i2c_dev->timings.bus_freq_hz) {
case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
default:
tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
- if (i2c_dev->bus_clk_rate > I2C_MAX_FAST_MODE_FREQ)
+ if (i2c_dev->timings.bus_freq_hz > I2C_MAX_FAST_MODE_FREQ)
non_hs_mode = i2c_dev->hw->clk_divisor_fast_plus_mode;
else
non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
@@ -685,7 +685,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
err = clk_set_rate(i2c_dev->div_clk,
- i2c_dev->bus_clk_rate * clk_multiplier);
+ i2c_dev->timings.bus_freq_hz * clk_multiplier);
if (err) {
dev_err(i2c_dev->dev, "failed to set div-clk rate: %d\n", err);
return err;
@@ -724,7 +724,7 @@ static int tegra_i2c_disable_packet_mode(struct
tegra_i2c_dev *i2c_dev)
* before disabling the controller so that the STOP condition has
* been delivered properly.
*/
- udelay(DIV_ROUND_UP(2 * 100, i2c_dev->bus_clk_rate));
+ udelay(DIV_ROUND_UP(2 * 100, i2c_dev->timings.bus_freq_hz));
cnfg = i2c_readl(i2c_dev, I2C_CNFG);
if (cnfg & I2C_CNFG_PACKET_MODE_EN)
@@ -1254,7 +1254,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
* Total bits = 9 bits per byte (including ACK bit) + Start & stop bits
*/
xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
- i2c_dev->bus_clk_rate);
+ i2c_dev->timings.bus_freq_hz);
int_mask = I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST;
tegra_i2c_unmask_irq(i2c_dev, int_mask);
@@ -1633,10 +1633,7 @@ static void tegra_i2c_parse_dt(struct tegra_i2c_dev
*i2c_dev)
bool multi_mode;
int err;
- err = device_property_read_u32(i2c_dev->dev, "clock-frequency",
- &i2c_dev->bus_clk_rate);
- if (err)
- i2c_dev->bus_clk_rate = I2C_MAX_STANDARD_MODE_FREQ;
+ i2c_parse_fw_timings(i2c_dev->dev, &i2c_dev->timings, true);
multi_mode = device_property_read_bool(i2c_dev->dev, "multi-master");
i2c_dev->multimaster_mode = multi_mode;
--
2.7.4
Re: [PATCH] net: mana: Fix memory leak in mana_hwc_create_wq
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski :
On Wed, 8 Dec 2021 23:37:23 +0100 you wrote:
> If allocating the DMA buffer fails, mana_hwc_destroy_wq was called
> without previously storing the pointer to the queue.
>
> In order to avoid leaking the pointer to the queue, store it as soon as
> it is allocated.
>
> Addresses-Coverity-ID: 1484720 ("Resource leak")
> Signed-off-by: José Expósito
>
> [...]
Here is the summary with links:
- net: mana: Fix memory leak in mana_hwc_create_wq
https://git.kernel.org/netdev/net/c/9acfc57fa2b8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Hi Guilherme, Am 09.12.21 um 17:00 schrieb Guilherme G. Piccoli: Hi all, I have a question about the possibility of reusing a framebuffer after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not a separate GPU hardware), but I guess the question is kinda generic hence I've looped most of the lists / people I think does make sense (apologies for duplicates). The context is: we have a hardware that has an amdgpu-controlled device (Vangogh model) and as soon as the machine boots, efifb is providing graphics - I understand the UEFI/GRUB outputs rely in EFI framebuffer as well. As soon amdgpu module is available, kernel loads it and it takes over the GPU, providing graphics. The kexec_file_load syscall allows to pass a valid screen_info structure, so by kexec'ing a new kernel, we have again efifb taking over on boot time, but this time I see nothing in the screen. I've manually blacklisted amdgpu in this new kexec'ed kernel, I'd like to rely in the simple framebuffer - the goal is to have a tiny kernel kexec'ed. I'm using kernel version 5.16.0-rc4. I've done some other experiments, for exemple: I've forced screen_info model to match VLFB, so vesafb took over after the kexec, with the same result. Also noticed that BusMaster bit was off after kexec, in the AMD APU PCIe device, so I've set it on efifb before probe, and finally tested the same things in qemu, with qxl, all with the same result (blank screen). The most interesting result I got (both with amdgpu and qemu/qxl) is that if I blacklist these drivers and let the machine continue using efifb since the beginning, after kexec the efifb is still able to produce graphics. Which then led me to think that likely there's something fundamentally "blocking" the reuse of the simple framebuffer after kexec, like maybe DRM stack is destroying the old framebuffer somehow? What kind of preparation is required at firmware level to make the simple EFI VGA framebuffer work, and could we perform this in a kexec (or "save it" before the amdgpu/qxl drivers take over and reuse later)? unfortunately what you try here will most likely not work easily. During bootup the ASIC is initialized in a VGA compatibility mode by the VBIOS which also allows efifb to display something. And among the first things amdgpu does is to disable this compatibility mode :) What you need to do to get this working again is to issue a PCIe reset of the GPU and then re-init the ASIC with the VBIOS tables. Alex should know more details about how to do this. Regards, Christian. Any advice is greatly appreciated! Thanks in advance, Guilherme
[PATCH 2/2] drm/amd/display: Reduce stack size for dml31 UseMinimumDCFCLK
From: Michel Dänzer
Use the struct display_mode_lib pointer instead of passing lots of large
arrays as parameters by value.
Addresses this warning (resulting in failure to build a RHEL debug kernel
with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function ‘UseMinimumDCFCLK’:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:7478:1:
warning: the frame size of 2128 bytes is larger than 2048 bytes
[-Wframe-larger-than=]
NOTE: AFAICT this function previously had no observable effect, since it
only modified parameters passed by value and doesn't return anything.
Now it may modify some values in struct display_mode_lib passed in by
reference.
Signed-off-by: Michel Dänzer
---
.../dc/dml/dcn31/display_mode_vba_31.c| 304 --
1 file changed, 69 insertions(+), 235 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index 8965f9af9d0a..6feb23432f8d 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -422,62 +422,8 @@ static void CalculateUrgentBurstFactor(
static void UseMinimumDCFCLK(
struct display_mode_lib *mode_lib,
- int MaxInterDCNTileRepeaters,
int MaxPrefetchMode,
- double FinalDRAMClockChangeLatency,
- double SREnterPlusExitTime,
- int ReturnBusWidth,
- int RoundTripPingLatencyCycles,
- int ReorderingBytes,
- int PixelChunkSizeInKByte,
- int MetaChunkSize,
- bool GPUVMEnable,
- int GPUVMMaxPageTableLevels,
- bool HostVMEnable,
- int NumberOfActivePlanes,
- double HostVMMinPageSize,
- int HostVMMaxNonCachedPageTableLevels,
- bool DynamicMetadataVMEnabled,
- enum immediate_flip_requirement ImmediateFlipRequirement,
- bool ProgressiveToInterlaceUnitInOPP,
- double
MaxAveragePercentOfIdealFabricAndSDPPortBWDisplayCanUseInNormalSystemOperation,
- double PercentOfIdealFabricAndSDPPortBWReceivedAfterUrgLatency,
- int VTotal[],
- int VActive[],
- int DynamicMetadataTransmittedBytes[],
- int DynamicMetadataLinesBeforeActiveRequired[],
- bool Interlace[],
- double RequiredDPPCLK[][2][DC__NUM_DPP__MAX],
- double RequiredDISPCLK[][2],
- double UrgLatency[],
- unsigned int NoOfDPP[][2][DC__NUM_DPP__MAX],
- double ProjectedDCFCLKDeepSleep[][2],
- double MaximumVStartup[][2][DC__NUM_DPP__MAX],
- double TotalVActivePixelBandwidth[][2],
- double TotalVActiveCursorBandwidth[][2],
- double TotalMetaRowBandwidth[][2],
- double TotalDPTERowBandwidth[][2],
- unsigned int TotalNumberOfActiveDPP[][2],
- unsigned int TotalNumberOfDCCActiveDPP[][2],
- int dpte_group_bytes[],
- double PrefetchLinesY[][2][DC__NUM_DPP__MAX],
- double PrefetchLinesC[][2][DC__NUM_DPP__MAX],
- int swath_width_luma_ub_all_states[][2][DC__NUM_DPP__MAX],
- int swath_width_chroma_ub_all_states[][2][DC__NUM_DPP__MAX],
- int BytePerPixelY[],
- int BytePerPixelC[],
- int HTotal[],
- double PixelClock[],
- double PDEAndMetaPTEBytesPerFrame[][2][DC__NUM_DPP__MAX],
- double DPTEBytesPerRow[][2][DC__NUM_DPP__MAX],
- double MetaRowBytes[][2][DC__NUM_DPP__MAX],
- bool DynamicMetadataEnable[],
- double VActivePixelBandwidth[][2][DC__NUM_DPP__MAX],
- double VActiveCursorBandwidth[][2][DC__NUM_DPP__MAX],
- double ReadBandwidthLuma[],
- double ReadBandwidthChroma[],
- double DCFCLKPerState[],
- double DCFCLKState[][2]);
+ int ReorderingBytes);
static void CalculatePixelDeliveryTimes(
unsigned int NumberOfActivePlanes,
@@ -5175,66 +5121,8 @@ void dml31_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
}
}
- if (v->UseMinimumRequiredDCFCLK == true) {
- UseMinimumDCFCLK(
- mode_lib,
- v->MaxInterDCNTileRepeaters,
- MaxPrefetchMode,
- v->DRAMClockChangeLatency,
- v->SREnterPlusExitTime,
- v->ReturnBusWidth,
- v->RoundTripPingLatencyCycles,
- Reor
Re: [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind
On 09-12-2021 14:40, Matthew Auld wrote:
> On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst
> wrote:
>> On 09-12-2021 14:05, Matthew Auld wrote:
>>> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
>>> wrote:
We want to remove more members of i915_vma, which requires the locking to
be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to
the
object may be held by the VMA, so after __i915_vma_unbind, vma may be
garbage,
and we need to cache vma->obj before unlocking.
Signed-off-by: Maarten Lankhorst
---
>>>
>>>
@@ -129,22 +129,47 @@ void i915_ggtt_suspend_vm(struct i915_address_space
*vm)
drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
+retry:
+ i915_gem_drain_freed_objects(vm->i915);
+
mutex_lock(&vm->mutex);
/* Skip rewriting PTE on VMA unbind. */
open = atomic_xchg(&vm->open, 0);
list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link) {
+ struct drm_i915_gem_object *obj = vma->obj;
+
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
+
i915_vma_wait_for_bind(vma);
- if (i915_vma_is_pinned(vma))
+ if (i915_vma_is_pinned(vma) || !i915_vma_is_bound(vma,
I915_VMA_GLOBAL_BIND))
continue;
- if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
- __i915_vma_evict(vma);
- drm_mm_remove_node(&vma->node);
+ /* unlikely to race when GPU is idle, so no worry about
slowpath.. */
+ if (!i915_gem_object_trylock(obj, NULL)) {
+ atomic_set(&vm->open, open);
>>> Does this need a comment about barriers?
>> Not sure, it's guarded by vm->mutex.
+
+ i915_gem_object_get(obj);
>>> Should this not be kref_get_unless_zero? Assuming the vm->mutex is the
>>> only thing keeping the object alive here, won't this lead to potential
>>> uaf/double-free or something? Also should we not plonk this before the
>>> trylock? Or maybe I'm missing something here?
>> Normally you're correct, this is normally the case, but we drain freed
>> objects and this path should only be run during s/r, at which point
>> userspace should be dead, GPU idle, and we just drained all freed objects
>> above.
>>
>> It would be a bug if we still found a dead object, as nothing should be
>> running.
> Hmm, Ok. So why do we expect the trylock to ever fail here? Who else
> can grab it at this stage?
It probably shouldn't, should probably be a WARN if it happens.
+ mutex_unlock(&vm->mutex);
+
+ i915_gem_object_lock(obj, NULL);
+ open = i915_vma_unbind(vma);
+ i915_gem_object_unlock(obj);
+
+ GEM_WARN_ON(open);
+
+ i915_gem_object_put(obj);
+ goto retry;
}
+
+ i915_vma_wait_for_bind(vma);
>>> We also call wait_for_bind above, is that intentional?
>> Should be harmless, but first one should probably be removed. :)
>>
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
That still won't work. But I think we could do this change for the amdgpu mmap callback only. Regards, Christian. Am 09.12.21 um 16:29 schrieb Bhardwaj, Rajneesh: Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank you! On 12/9/2021 10:27 AM, Christian König wrote: Hi Rajneesh, yes, separating this from the drm_gem_mmap_obj() change is certainly a good idea. The child cannot access the BOs mapped by the parent anyway with access restrictions applied exactly that is not correct. That behavior is actively used by some userspace stacks as far as I know. Regards, Christian. Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh: Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
Re: [PATCH v2 16/16] drm/i915: Remove short-term pins from execbuf, v5.
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst wrote: > > Add a flag PIN_VALIDATE, to indicate we don't need to pin and only > protected by the object lock. > > This removes the need to unpin, which is done by just releasing the > lock. > > eb_reserve is slightly reworked for readability, but the same steps > are still done: > - First pass pins with NONBLOCK. > - Second pass unbinds all objects first, then pins. > - Third pass is only called when not all objects are softpinned, and > unbinds all objects, then calls i915_gem_evict_vm(), then pins. > > When evicting the entire vm in eb_reserve() we do temporarily pin objects > that are marked with EXEC_OBJECT_PINNED. This is because they are already > at their destination, and i915_gem_evict_vm() would otherwise unbind them. > > However, we reduce the visibility of those pins by limiting the pin > to our call to i915_gem_evict_vm() only, and pin with vm->mutex held, > instead of the entire duration of the execbuf. > > Not sure the latter matters, one can hope.. > In theory we could kill the pinning by adding an extra flag to the vma > to temporarily prevent unbinding for gtt for i915_gem_evict_vm only, but > I think that might be overkill. We're still holding the object lock, and > we don't have blocking eviction yet. It's likely sufficient to simply > enforce EXEC_OBJECT_PINNED for all objects on >= gen12. > > Changes since v1: > - Split out eb_reserve() into separate functions for readability. > Changes since v2: > - Make batch buffer mappable on platforms where only GGTT is available, > to prevent moving the batch buffer during relocations. > Changes since v3: > - Preserve current behavior for batch buffer, instead be cautious when > calling i915_gem_object_ggtt_pin_ww, and re-use the current batch vma > if it's inside ggtt and map-and-fenceable. > - Remove impossible condition check from eb_reserve. (Matt) > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
[PATCH 0/2] Add SMBus features to Tegra I2C
Add support for SMBus Alert and SMBus block read functions to i2c-tegra driver Akhil R (2): dt-bindings: i2c: tegra: Add SMBus feature properties i2c: tegra: Add SMBus block read and SMBus alert functions .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++ drivers/i2c/busses/i2c-tegra.c | 54 +- 2 files changed, 57 insertions(+), 1 deletion(-) -- 2.7.4
Re: [PATCH] i2c: tegra: use i2c_timings for bus clock freq
On Thu, Dec 9, 2021 at 3:48 PM Akhil R wrote:
>
> Use i2c_timings struct and corresponding methods to get bus clock frequency
Thanks!
A couple of comments below, after addressing them, FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Akhil R
> ---
> drivers/i2c/busses/i2c-tegra.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> The patch is in response to the discussion in a previous patch to use
> i2c_timings struct for bus freq.
> ref. https://lkml.org/lkml/2021/11/25/767
A-ha.
Suggested-by: Andy Shevchenko
(or @linux.intel.com, I can't see it there)
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index a5be8f0..ffd2ad2 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -246,7 +246,7 @@ struct tegra_i2c_hw_feature {
> * @msg_buf: pointer to current message data
> * @msg_buf_remaining: size of unsent data in the message buffer
> * @msg_read: indicates that the transfer is a read access
> - * @bus_clk_rate: current I2C bus clock rate
> + * @timings: i2c timings information like bus frequency
> * @multimaster_mode: indicates that I2C controller is in multi-master mode
> * @tx_dma_chan: DMA transmit channel
> * @rx_dma_chan: DMA receive channel
> @@ -273,7 +273,7 @@ struct tegra_i2c_dev {
> unsigned int nclocks;
>
> struct clk *div_clk;
> - u32 bus_clk_rate;
> + struct i2c_timings timings;
>
> struct completion msg_complete;
> size_t msg_buf_remaining;
> @@ -642,14 +642,14 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> if (i2c_dev->is_vi)
> tegra_i2c_vi_init(i2c_dev);
>
> - switch (i2c_dev->bus_clk_rate) {
> + switch (i2c_dev->timings.bus_freq_hz) {
It would be easier to have all these to read when you introduce a
temporary variable:
struct i2c_timings *t = &i2c_dev->timings;
...
switch (t->...) {
...
> case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
> default:
> tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
> thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
> tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
>
> - if (i2c_dev->bus_clk_rate > I2C_MAX_FAST_MODE_FREQ)
> + if (i2c_dev->timings.bus_freq_hz > I2C_MAX_FAST_MODE_FREQ)
> non_hs_mode = i2c_dev->hw->clk_divisor_fast_plus_mode;
> else
> non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
> @@ -685,7 +685,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
>
> err = clk_set_rate(i2c_dev->div_clk,
> - i2c_dev->bus_clk_rate * clk_multiplier);
> + i2c_dev->timings.bus_freq_hz * clk_multiplier);
> if (err) {
> dev_err(i2c_dev->dev, "failed to set div-clk rate: %d\n",
> err);
> return err;
> @@ -724,7 +724,7 @@ static int tegra_i2c_disable_packet_mode(struct
> tegra_i2c_dev *i2c_dev)
> * before disabling the controller so that the STOP condition has
> * been delivered properly.
> */
> - udelay(DIV_ROUND_UP(2 * 100, i2c_dev->bus_clk_rate));
> + udelay(DIV_ROUND_UP(2 * 100, i2c_dev->timings.bus_freq_hz));
>
> cnfg = i2c_readl(i2c_dev, I2C_CNFG);
> if (cnfg & I2C_CNFG_PACKET_MODE_EN)
> @@ -1254,7 +1254,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> * Total bits = 9 bits per byte (including ACK bit) + Start & stop
> bits
> */
> xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
> - i2c_dev->bus_clk_rate);
> + i2c_dev->timings.bus_freq_hz);
>
> int_mask = I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST;
> tegra_i2c_unmask_irq(i2c_dev, int_mask);
> @@ -1633,10 +1633,7 @@ static void tegra_i2c_parse_dt(struct tegra_i2c_dev
> *i2c_dev)
> bool multi_mode;
> int err;
>
> - err = device_property_read_u32(i2c_dev->dev, "clock-frequency",
> - &i2c_dev->bus_clk_rate);
> - if (err)
> - i2c_dev->bus_clk_rate = I2C_MAX_STANDARD_MODE_FREQ;
> + i2c_parse_fw_timings(i2c_dev->dev, &i2c_dev->timings, true);
>
> multi_mode = device_property_read_bool(i2c_dev->dev, "multi-master");
> i2c_dev->multimaster_mode = multi_mode;
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions
09.12.2021 18:05, Akhil R пишет:
> Emulate the SMBus block read using ContinueXfer and SMBus using GPIO
> interrupt.
>
> For SMBus block read, the driver reads the first byte with ContinueXfer
> set which will help to parse the data count and read the remaining bytes
> without stop condition in between.
> SMBus alert is implemented using external gpio interrupt.
>
> Signed-off-by: Akhil R
> ---
> drivers/i2c/busses/i2c-tegra.c | 54
> +-
> 1 file changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index a5be8f0..3b70013 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -226,6 +227,11 @@ struct tegra_i2c_hw_feature {
> bool has_interface_timing_reg;
> };
>
> +struct tegra_i2c_smbalert {
smbalert isn't a word, should be smbus_alert. Same for the GPIO name and
other places.
> + struct i2c_smbus_alert_setup alert_data;
> + struct i2c_client *ara;
What "ara" stands for? Please use meaningful names, like alert_dev for
example.
I don't see where this member is used at all, please remove it.
> +};
> +
> /**
> * struct tegra_i2c_dev - per device I2C context
> * @dev: device reference for power management
> @@ -280,6 +286,8 @@ struct tegra_i2c_dev {
> int msg_err;
> u8 *msg_buf;
>
> + struct tegra_i2c_smbalert smbalert;
All properties must have doc comment.
> struct completion dma_complete;
> struct dma_chan *tx_dma_chan;
> struct dma_chan *rx_dma_chan;
> @@ -1232,6 +1240,11 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> return err;
>
> i2c_dev->msg_buf = msg->buf;
> +
> + /* The condition true implies smbus block read and len is already read*/
Proper SMBus capitalization in comments. Mussing whitespace in the end
of the comment.
> + if (msg->flags & I2C_M_RECV_LEN && end_state != MSG_END_CONTINUE)
> + i2c_dev->msg_buf = msg->buf + 1;
> +
> i2c_dev->msg_buf_remaining = msg->len;
> i2c_dev->msg_err = I2C_ERR_NONE;
> i2c_dev->msg_read = !!(msg->flags & I2C_M_RD);
> @@ -1388,6 +1401,15 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap,
> struct i2c_msg msgs[],
> else
> end_type = MSG_END_REPEAT_START;
> }
> + /* If M_RECV_LEN use ContinueXfer to read the first byte */
> + if (msgs[i].flags & I2C_M_RECV_LEN) {
> + ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i],
> MSG_END_CONTINUE);
> + if (ret)
> + break;
> + /* Set the read byte as msg len */
> + msgs[i].len = msgs[i].buf[0];
> + dev_dbg(i2c_dev->dev, "reading %d bytes\n",
> msgs[i].len);
> + }
> ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type);
> if (ret)
> break;
> @@ -1415,7 +1437,8 @@ static u32 tegra_i2c_func(struct i2c_adapter *adap)
> {
> struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
> u32 ret = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
> - I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
> + I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_10BIT_ADDR |
> + I2C_FUNC_PROTOCOL_MANGLING;
>
> if (i2c_dev->hw->has_continue_xfer_support)
> ret |= I2C_FUNC_NOSTART;
> @@ -1727,6 +1750,29 @@ static int tegra_i2c_init_hardware(struct
> tegra_i2c_dev *i2c_dev)
> return ret;
> }
>
> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
> +{
> + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert;
> + struct gpio_desc *alert_gpiod;
> + struct i2c_client *ara;
> +
> + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN);
> + if (IS_ERR(alert_gpiod))
> + return PTR_ERR(alert_gpiod);
> +
> + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod);
> + if (smbalert->alert_data.irq <= 0)
> + return smbalert->alert_data.irq;
> +
> + ara = i2c_new_smbus_alert_device(&i2c_dev->adapter,
> &smbalert->alert_data);
> + if (IS_ERR(ara))
> + return PTR_ERR(ara);
> +
> + smbalert->ara = ara;
> +
> + return 0;
> +}
> +
> static int tegra_i2c_probe(struct platform_device *pdev)
> {
> struct tegra_i2c_dev *i2c_dev;
> @@ -1821,6 +1867,12 @@ static int tegra_i2c_probe(struct platform_device
> *pdev)
> if (err)
> goto release_rpm;
>
> + if (device_property_read_bool(i2c_dev->dev, "smbus-alert")) {
I'd move this device_property_read_bool() inside of
tegra_i2c_setup_smbus_alert(), for consistency with the rest of the code
in this driver.
Although, you
Re: [PATCH v4 4/4] drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
Hi Alexander,
Thank you for the patch.
On Thu, Nov 18, 2021 at 10:19:55AM +0100, Alexander Stein wrote:
> VCC needs to be enabled before releasing the enable GPIO.
>
> Signed-off-by: Alexander Stein
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 065610edc37a..54d18e82ed74 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -143,6 +144,7 @@ struct sn65dsi83 {
> struct mipi_dsi_device *dsi;
> struct drm_bridge *panel_bridge;
> struct gpio_desc*enable_gpio;
> + struct regulator*vcc;
> int dsi_lanes;
> boollvds_dual_link;
> boollvds_dual_link_even_odd_swap;
> @@ -337,6 +339,12 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
> *bridge,
> u16 val;
> int ret;
>
> + ret = regulator_enable(ctx->vcc);
> + if (ret) {
> + dev_err(ctx->dev, "Failed to enable vcc\n");
I'd print the error code here as you do so in
sn65dsi83_atomic_disable().
> + return;
> + }
> +
> /* Deassert reset */
> gpiod_set_value(ctx->enable_gpio, 1);
> usleep_range(1000, 1100);
> @@ -486,11 +494,16 @@ static void sn65dsi83_atomic_disable(struct drm_bridge
> *bridge,
>struct drm_bridge_state *old_bridge_state)
> {
> struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> + int ret;
>
> /* Put the chip in reset, pull EN line low, and assure 10ms reset low
> timing. */
> gpiod_set_value(ctx->enable_gpio, 0);
> usleep_range(1, 11000);
>
> + ret = regulator_disable(ctx->vcc);
> + if (ret)
> + dev_err(ctx->dev, "Failed to disable vcc: %i\n", ret);
I wish printf didn't have identical %i and %d specifiers :-)
> +
> regcache_mark_dirty(ctx->regmap);
> }
>
> @@ -599,6 +612,12 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx,
> enum sn65dsi83_model model)
>
> ctx->panel_bridge = panel_bridge;
>
> + ctx->vcc = devm_regulator_get(dev, "vcc");
> + if (IS_ERR(ctx->vcc))
> + return dev_err_probe(dev, PTR_ERR(ctx->vcc),
> + "Failed to get supply 'vcc': %pe\n",
> + ERR_PTR(ret));
This doesn't seem right, ret doesn't contain any useful error code at
this point.
return dev_err_probe(dev, PTR_ERR(ctx->vcc),
"Failed to get supply 'vcc'\n");
should be enough, as dev_err_probe() adds the error to the message
internally.
With those small fixes,
Reviewed-by: Laurent Pinchart
> +
> return 0;
> }
>
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank you! On 12/9/2021 10:27 AM, Christian König wrote: Hi Rajneesh, yes, separating this from the drm_gem_mmap_obj() change is certainly a good idea. The child cannot access the BOs mapped by the parent anyway with access restrictions applied exactly that is not correct. That behavior is actively used by some userspace stacks as far as I know. Regards, Christian. Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh: Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
[PATCH v6 11/11] drm/i915: Rename i915->gt to i915->gt0
In preparation of the multitile support, highlight the root GT by
calling it gt0 inside the drm i915 private data.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 96e3553838ef..a4084f209097 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1008,7 +1008,7 @@ struct drm_i915_private {
struct i915_perf perf;
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
- struct intel_gt gt;
+ struct intel_gt gt0;
struct {
struct i915_gem_contexts {
@@ -1082,7 +1082,7 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
static inline struct intel_gt *to_gt(struct drm_i915_private *i915)
{
- return &i915->gt;
+ return &i915->gt0;
}
/* Simple iterator over all initialised engines */
--
2.34.1
[PATCH v4 16/16] Doc/gpu/rfc/i915: i915 DG2 uAPI
Details of the new features getting added as part of DG2 enabling and their implicit impact on the uAPI. v2: improvised the Flat-CCS documentation [Danvet & CQ] Signed-off-by: Ramalingam C cc: Daniel Vetter cc: Matthew Auld cc: Simon Ser cc: Pekka Paalanen Cc: Jordan Justen Cc: Kenneth Graunke Cc: mesa-...@lists.freedesktop.org Cc: Tony Ye Cc: Slawomir Milczarek --- Documentation/gpu/rfc/i915_dg2.rst | 32 ++ Documentation/gpu/rfc/index.rst| 3 +++ 2 files changed, 35 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_dg2.rst diff --git a/Documentation/gpu/rfc/i915_dg2.rst b/Documentation/gpu/rfc/i915_dg2.rst new file mode 100644 index ..9d28b1812bc7 --- /dev/null +++ b/Documentation/gpu/rfc/i915_dg2.rst @@ -0,0 +1,32 @@ + +I915 DG2 RFC Section + + +Upstream plan += +Plan to upstream the DG2 enabling is: + +* Merge basic HW enabling for DG2 (Still without pciid) +* Merge the 64k support for lmem +* Merge the flat CCS enabling patches +* Add the pciid for DG2 and enable the DG2 in CI + + +64K page support for lmem += +On DG2 hw, local-memory supports minimum GTT page size of 64k only. 4k is not +supported anymore. + +DG2 hw doesn't support the 64k (lmem) and 4k (smem) pages in the same ppgtt +Page table. Refer the struct drm_i915_gem_create_ext for the implication of +handling the 64k page size. + +.. kernel-doc:: include/uapi/drm/i915_drm.h +:functions: drm_i915_gem_create_ext + + +Flat CCS support for lmem += + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c +:doc: Flat-CCS - Memory compression for Local memory diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 91e93a705230..afb320ed4028 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -20,6 +20,9 @@ host such documentation: i915_gem_lmem.rst +.. toctree:: +i915_dg2.rst + .. toctree:: i915_scheduler.rst -- 2.20.1
[PATCH v4 3/6] Documentation/gpu: Document pipe split visual confirmation
Display core provides a feature that makes it easy for users to debug Pipe Split. This commit introduces how to use such a debug option. Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/display/dc-debug.rst | 28 +-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst index 532cbbd64863..6dbd21f7f59e 100644 --- a/Documentation/gpu/amdgpu/display/dc-debug.rst +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -2,8 +2,18 @@ Display Core Debug tools -DC Debugfs -== +DC Visual Confirmation +== + +Display core provides a feature named visual confirmation, which is a set of +bars added at the scanout time by the driver to convey some specific +information. In general, you can enable this debug option by using:: + + echo > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +Where `N` is an integer number for some specific scenarios that the developer +wants to enable, you will see some of these debug cases in the following +subsection. Multiple Planes Debug - @@ -34,3 +44,17 @@ split configuration. * There should **not** be any cursor corruption * Multiple plane **may** be briefly disabled during window transitions or resizing but should come back after the action has finished + +Pipe Split Debug + + +Sometimes we need to debug if DCN is splitting pipes correctly, and visual +confirmation is also handy for this case. Similar to the MPO case, you can use +the below command to enable visual confirmation:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +In this case, if you have a pipe split, you will see one small red bar at the +bottom of the display covering the entire display width and another bar +covering the second pipe. In other words, you will see a bit high bar in the +second pipe. -- 2.25.1
[PATCH v4 03/16] drm/i915/xehpsdv: implement memory coloring
From: Matthew Auld
The basic idea is that each 2M block(page-table) has a color, depending
on if the page-table is occupied by LMEM objects(64K) or SMEM
objects(4K), where our goal is to prevent mixing 64K and 4K GTT pages in
the page-table, which is not supported by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 16 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 6
drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++
drivers/gpu/drm/i915/i915_vma.c | 46 +++
4 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 8d081497e87e..5db11d8f7c7a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -463,6 +463,19 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
return idx;
}
+static void xehpsdv_ppgtt_color_adjust(const struct drm_mm_node *node,
+ unsigned long color,
+ u64 *start,
+ u64 *end)
+{
+ if (i915_node_color_differs(node, color))
+ *start = round_up(*start, SZ_2M);
+
+ node = list_next_entry(node, node_list);
+ if (i915_node_color_differs(node, color))
+ *end = round_down(*end, SZ_2M);
+}
+
static void
xehpsdv_ppgtt_insert_huge(struct i915_vma *vma,
struct sgt_dma *iter,
@@ -903,6 +916,9 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
}
+ if (HAS_64K_PAGES(gt->i915))
+ ppgtt->vm.mm.color_adjust = xehpsdv_ppgtt_color_adjust;
+
err = gen8_init_scratch(&ppgtt->vm);
if (err)
goto err_free;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 85ff11ebcbd5..01e9a98846fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -400,6 +400,12 @@ i915_vm_has_cache_coloring(struct i915_address_space *vm)
return i915_is_ggtt(vm) && vm->mm.color_adjust;
}
+static inline bool
+i915_vm_has_memory_coloring(struct i915_address_space *vm)
+{
+ return !i915_is_ggtt(vm) && vm->mm.color_adjust;
+}
+
static inline struct i915_ggtt *
i915_vm_to_ggtt(struct i915_address_space *vm)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 2b73ddb11c66..006bf4924c24 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -292,6 +292,13 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
/* Always look at the page afterwards to avoid the end-of-GTT */
end += I915_GTT_PAGE_SIZE;
+ } else if (i915_vm_has_memory_coloring(vm)) {
+ /*
+* Expand the search the cover the page-table boundries, in
+* case we need to flip the color of the page-table(s).
+*/
+ start = round_down(start, SZ_2M);
+ end = round_up(end, SZ_2M);
}
GEM_BUG_ON(start >= end);
@@ -321,6 +328,16 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
if (node->color == target->color)
continue;
}
+ } else if (i915_vm_has_memory_coloring(vm)) {
+ if (node->start + node->size <= target->start) {
+ if (node->color == target->color)
+ continue;
+ }
+
+ if (node->start >= target->start + target->size) {
+ if (node->color == target->color)
+ continue;
+ }
}
if (i915_vma_is_pinned(vma)) {
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 73972bf4052b..05719648580f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -613,6 +613,10 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
struct drm_mm_node *node = &vma->node;
struct drm_mm_node *other;
+ /* Only valid to be called on an already inserted vma */
+ GEM_BUG_ON(!drm_mm_node_allocated(node));
+ GEM_BUG_ON(list_empty(&node->node_list));
+
/*
* On some machines we have to be careful when putting differing types
* of snoopable memory together to avoid the prefetcher crossing memory
@@ -620,22 +624,34 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
* these constraints apply and set the drm_mm.color_
