Re: [PATCH 2/2] drm/edid: make drm_edid_block_valid() static

2024-05-30 Thread Zhi Wang
On Thu, 30 May 2024 15:43:52 +0300 Jani Nikula wrote: > drm_edid_block_valid() is no longer used outside of drm_edid.c. Make > it static. > > Signed-off-by: Jani Nikula > > --- > > Cc: Zhenyu Wang > Cc: Zhi Wang > Cc: intel-gvt-...@lis

Re: [PATCH 1/2] drm/i915/gvt: stop using drm_edid_block_valid()

2024-05-30 Thread Zhi Wang
the TODO comment about EDID extension block support. > > Signed-off-by: Jani Nikula > > --- > > Cc: Zhenyu Wang > Cc: Zhi Wang > Cc: intel-gvt-...@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-05-28 Thread Zhi Wang
On 28/05/2024 17.18, Danilo Krummrich wrote: > External email: Use caution opening links or attachments > > > On Tue, May 28, 2024 at 08:40:20AM +0000, Zhi Wang wrote: >> On 27/05/2024 22.18, Danilo Krummrich wrote: >>> External email: Use caution opening links or att

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-05-28 Thread Zhi Wang
On 28/05/2024 13.17, FUJITA Tomonori wrote: > External email: Use caution opening links or attachments > > > Hi, > > On Tue, 28 May 2024 08:40:20 + > Zhi Wang wrote: > >> On 27/05/2024 22.18, Danilo Krummrich wrote: >>> External email: U

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-05-28 Thread Zhi Wang
On 27/05/2024 22.18, Danilo Krummrich wrote: > External email: Use caution opening links or attachments > > > On Tue, May 21, 2024 at 08:32:31AM +0300, Zhi Wang wrote: >> On Mon, 20 May 2024 19:24:19 +0200 >> Danilo Krummrich wrote: >> >>> Add an abstrac

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-05-21 Thread Zhi Wang
On Mon, 20 May 2024 19:24:19 +0200 Danilo Krummrich wrote: > Add an abstraction around the kernels firmware API to request firmware > images. The abstraction provides functions to access the firmware > buffer and / or copy it to a new buffer allocated with a given > allocator backend. > Was pla

Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive

2024-05-03 Thread Zhi Wang
t; for users of I2C_ALGOBIT bitbanging interface, now that the approved > verbiage exists in the specification. > > Compile tested, no functionality changes intended > For GVT part, Acked-by: Zhi Wang Thanks, Zhi. > [1]: > https://lore.kernel.org/all/20240322132619.6389-1-wsa+ren

Re: [PATCH][next] drm/i915/gvt: remove redundant assignment to pointer map

2024-02-11 Thread Zhi Wang
_gvt_irq_info *up_irq_info = NULL; > u32 set_bits = 0; > u32 clear_bits = 0; Thanks for the patch! Reviewed-by: Zhi Wang

[PATCH v9 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-04-07 Thread Zhi Wang
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v9 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

2022-04-07 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO tracking table needs to be separated from GVT-g. v9: - Fix a problem might cause kernel panic. v8: - Use SPDX header in the

[PATCH v9 2/3] i915/gvt: Save the initial HW state snapshot in i915

2022-04-07 Thread Zhi Wang
state. v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v9 0/3] Refactor GVT-g MMIO tracking table and handlers

2022-04-07 Thread Zhi Wang
when CONFIG_DRM_I915_WERROR is turned on. (Jani) v2: - Implement a mmio table instead of generating it by marco in i915. (Jani) Zhi Wang (3): i915/gvt: Separate the MMIO tracking table from GVT-g i915/gvt: Save the initial HW state snapshot in i915 i915/gvt: Use the initial HW state snapshot

[PATCH v8 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-04-01 Thread Zhi Wang
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v8 2/3] i915/gvt: Save the initial HW state snapshot in i915

2022-04-01 Thread Zhi Wang
state. --- v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm

[PATCH v8 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

2022-04-01 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO tracking table needs to be separated from GVT-g. --- v8: - Use SPDX header in the intel_gvt_mmio_table.c - Reference the gvt.h with

[PATCH v8 0/3] Refactor GVT-g MMIO tracking table and handlers

2022-04-01 Thread Zhi Wang
ed on. (Jani) v2: - Implement a mmio table instead of generating it by marco in i915. (Jani) Zhi Wang (3): i915/gvt: Separate the MMIO tracking table from GVT-g i915/gvt: Save the initial HW state snapshot in i915 i915/gvt: Use the initial HW state snapshot saved in i915 drivers/gpu/drm

Re: [PATCH v7 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

2022-03-31 Thread Zhi Wang
Thanks. Let me fix that. :) On 3/31/22 04:33, Christoph Hellwig wrote: On Thu, Mar 31, 2022 at 08:04:04AM +, Wang, Zhi A wrote: Hi Chris: Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake desktop with some 3D workload. Sure, I should have done that from the

[PATCH v7 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-03-25 Thread Zhi Wang
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v7 2/3] i915/gvt: Save the initial HW state snapshot in i915

2022-03-25 Thread Zhi Wang
state. v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v7 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

2022-03-25 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO tracking table needs to be separated from GVT-g. v7: - Keep the marcos of device generation in GVT-g. (Christoph, Jani) v6: - Move

[PATCH v7 0/3] Refactor GVT-g MMIO tracking table and handlers

2022-03-25 Thread Zhi Wang
cking scripts. v3: - Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani) v2: - Implement a mmio table instead of generating it by marco in i915. (Jani) Zhi Wang (3): i915/gvt: Separate the MMIO tracking table from GVT-g i915/gvt: Save the initial HW state snapshot in i915 i915/gvt

[PATCH v6 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-02-08 Thread Zhi Wang
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v6 2/3] i915/gvt: Save the initial HW state snapshot in i915

2022-02-08 Thread Zhi Wang
state. v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API

2022-02-08 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g initialization path has to be separated into two phases: a) Early initialization. The early initialization of GVT requires to be done when

Re: [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API

2022-02-07 Thread Zhi Wang
On 2/7/22 05:48, Jani Nikula wrote: On Mon, 07 Feb 2022, Christoph Hellwig wrote: On Mon, Feb 07, 2022 at 08:28:13AM +, Wang, Zhi A wrote: 1) About having the mmio_table.h, I would like to keep the stuff in a dedicated header as putting them in intel_gvt.h might needs i915 guys to maintai

[PATCH 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-01-27 Thread Zhi Wang
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915

[PATCH 2/3] i915/gvt: save the initial HW state snapshot in i915.

2022-01-27 Thread Zhi Wang
state. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Vivi Rodrigo Cc: Zhenyu Wang Cc: Zhi Wang Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/intel_gvt.c | 110 ++- 2 files changed, 110

[PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API

2022-01-27 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g initialization path has to be separated into two phases: a) Early initialization. The early initialization of GVT requires to be done when

[PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API

2021-11-29 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g initialization path has to be separated into two phases: a) Early initialization. The early initialization of GVT requires to be done when

[PATCH v4 2/2] i915/gvt: save the MMIO snapshot in the early init of GVT-g

2021-11-29 Thread Zhi Wang
From: Zhi Wang To support the early init of GVT-g, which will be put in i915, after the GVT-g is moved into a dedicated module, we need to save the MMIO snapshot in the early init of GVT-g, when the HW hasn't been touched. v3: - Fix errors when CONFIG_DRM_I915_WERROR is turned on. (Jani

[PATCH v3 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API

2021-11-26 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g initialization path has to be seperated into two phases: a) Early initialization. The early initialization of GVT requires to be done when

[PATCH v3 2/2] i915/gvt: save the MMIO snapshot in the early init of GVT-g

2021-11-26 Thread Zhi Wang
From: Zhi Wang To support the early init of GVT-g, which will be put in i915, after the GVT-g is moved into a dedicated module, we need to save the MMIO snapshot in the early init of GVT-g, when the HW hasn't been touched. v3: - Fix errors when CONFIG_DRM_I915_WERROR is turned on. (Jani

[PATCH 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API

2021-11-19 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g initialization path has to be seperated into two phases: a) Early initialization. The early initialization of GVT requires to be done when

[PATCH 2/2] i915/gvt: save the MMIO snapshot in the early init of GVT-g

2021-11-19 Thread Zhi Wang
From: Zhi Wang To support the early init of GVT-g, which will be put in i915, after the GVT-g is moved into a dedicated module, we need to save the MMIO snapshot in the early init of GVT-g, when the HW hasn't been touched. Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jani Nikula Cc: J

[PATCH 2/3] i915/gvt: save the initial HW state snapshot in i915.

2021-11-08 Thread Zhi Wang
From: Zhi Wang Save the inital HW state snapshot in i915 so that the rest code of GVT-g can be moved into a dedicated module while it can still get a clean initial HW state saved at the correct time during the initialization of i915. The futhrer vGPU created by GVT-g will use this HW state as

[PATCH 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2021-11-08 Thread Zhi Wang
From: Zhi Wang The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Zhenyu Wang Cc: Zhi Wang Cc: Christoph Hellwig Cc: Jason Gunthorpe Signed-off-by: Zhi Wang

[PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

2021-11-08 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO snapshot still needs to be saved in i915 so that the inital clean HW state can be used for the further vGPU. Seperate the tracked MMIO

Re: Possible use_mm() mis-uses

2018-08-22 Thread Zhi Wang
Hi Linus: Thanks for letting us know that. We would fix this ASAP. The kvmgt.c module is a part of GVT-g code. It's our fault that we didn't find this mis-uses, not i915 or KVM guys. Wish they would feel better after seeing this message. Thanks, Zhi. On 08/23/18 00:44, Linus Torvalds wrote:

Re: [PATCH] drm/i915/gvt: use ARRAY_SIZE

2017-10-23 Thread Zhi Wang
Thanks, applied! On 10/16/17 10:32, Jérémy Lefaure wrote: Using the ARRAY_SIZE macro improves the readability of the code. Also, it's useless to use a variable to store this constant calculated at compile time. Found with Coccinelle with the following semantic patch: @r depends on (org || repor

Re: [PATCH] drm/i915/gvt: Clean up dead code in cmd_parser

2017-10-23 Thread Zhi Wang
Thanks, applied! :) On 10/16/17 06:32, Christos Gkekas wrote: Delete variables 'gma_bottom' that are set but never used. Signed-off-by: Christos Gkekas --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gv

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

2017-10-03 Thread Zhi Wang
Thanks for the patch! :) 2017-10-01 22:30 GMT+03:00 Jérémy Lefaure : > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof >