Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"
On Tue, Oct 18, 2022 at 10:24:13AM +0200, Christoph Hellwig wrote: > On Tue, Oct 18, 2022 at 05:52:16AM +0200, Marek Marczykowski-Górecki wrote: > > not only) when using IGD in Xen PV dom0. After not very long time Xorg > > crashes, and dmesg contain messages like this: > > > > i915 :00:02.0: [drm] GPU HANG: ecode 7:1:01fffbfe, in Xorg [5337] > > i915 :00:02.0: [drm] Resetting rcs0 for stopped heartbeat on rcs0 > > i915 :00:02.0: [drm] Xorg[5337] context reset due to GPU hang > > > > > I tried reverting just this commit on top of 6.0.x, but the context > > changed significantly in subsequent commits, so after trying reverting > > it together with 3 or 4 more commits I gave up. > > > > What may be an important detail, the system heavily uses cross-VM shared > > memory (gntdev) to map window contents from VMs. This is Qubes OS, and > > it uses Xen 4.14. > > Can you try the patch below? Yes, this seems to help. And since this is a PV domain, with Jan proposed change it should work too. Intuitively this indeed should be PV-only thing (as was forcing swiotlb before). -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
[PATCH] parport_pc: Remove WCH CH382 PCI-E single parallel port card.
WCH CH382L PCI-E adapter with 1 parallel port has been included
inside parport_serial.
Signed-off-by: Zhang Xincheng
---
drivers/parport/parport_pc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 7c45927e2131..cf0cefe38e90 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2613,7 +2613,6 @@ enum parport_pc_pci_cards {
netmos_9901,
netmos_9865,
quatech_sppxp100,
- wch_ch382l,
};
@@ -2677,7 +2676,6 @@ static struct parport_pc_pci {
/* netmos_9901 */ { 1, { { 0, -1 }, } },
/* netmos_9865 */ { 1, { { 0, -1 }, } },
/* quatech_sppxp100 */ { 1, { { 0, 1 }, } },
- /* wch_ch382l */{ 1, { { 2, -1 }, } },
};
static const struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2769,8 +2767,6 @@ static const struct pci_device_id parport_pc_pci_tbl[] = {
/* Quatech SPPXP-100 Parallel port PCI ExpressCard */
{ PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SPPXP_100,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, quatech_sppxp100 },
- /* WCH CH382L PCI-E single parallel port card */
- { 0x1c00, 0x3050, 0x1c00, 0x3050, 0, 0, wch_ch382l },
{ 0, } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);
--
2.20.1
Re: [PATCH] drm: Remove drm_mode_config::fb_base
Hi Am 18.10.22 um 17:52 schrieb Zack Rusin: [...] @@ -527,7 +527,7 @@ void psb_modeset_init(struct drm_device *dev) /* set memory base */ /* Oaktrail and Poulsbo should use BAR 2*/ - pci_read_config_dword(pdev, PSB_BSM, (u32 *)&(dev->mode_config.fb_base)); + pci_read_config_dword(pdev, PSB_BSM, (u32 *)&(dev_priv->fb_base)); Although probably correct, that code looks questionable. Maybe have a local fb_base of type u32 and assign that to the field in dev_priv. It's the safe variant. I thought the same, but I don't have a psb system to test so I opted to preserve exactly what the code was doing before. fb_base in either case is a resource_size_t, and I'm guessing the entire thing depends, in either case, on drm_psb_private being kzalloc's. I'm happy to change to just use a local u32 but I can't test it so if there's some side-effect to upper bits in fb_base in that driver we'll break it. IIRC PSB hardware is only available in 32-bit systems. 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] drm: tests: Fix a buffer overflow in format_helper_test
The xrgb2101010 format conversion test (unlike for other formats) does
an endianness conversion on the results. However, it always converts
TEST_BUF_SIZE 32-bit integers, which results in reading from (and
writing to) more memory than in present in the result buffer. Instead,
use the buffer size, divided by sizeof(u32).
The issue could be reproduced with KASAN:
./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
--kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
--kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
drm_format_helper_test.*xrgb2101010
Reported-by: Linux Kernel Functional Testing
Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for
drm_fb_xrgb_to_xrgb2101010()")
Signed-off-by: David Gow
---
This is a fix for the issue reported here:
https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=k8p...@mail.gmail.com/
Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairaca...@riseup.net/
Cheers,
-- David
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 8d86c250c2ec..2191e57f2297 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -438,7 +438,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
kunit *test)
iosys_map_set_vaddr(&src, xrgb);
drm_fb_xrgb_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb,
¶ms->clip);
- buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
+ buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
}
--
2.38.0.413.g74048e4d9e-goog
Re: [PATCH v12,2/3] drm: mediatek: Set dpi format in mmsys
Il 19/10/22 04:52, xinlei@mediatek.com ha scritto: From: Xinlei Lee Dpi output needs to adjust the output format to dual edge for MT8186. Co-developed-by: Jitao Shi Signed-off-by: Jitao Shi Signed-off-by: Xinlei Lee Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v3] drm: Remove drm_mode_config::fb_base
Hi Am 18.10.22 um 18:49 schrieb Zack Rusin: From: Zack Rusin v3: Fix a silly pci_resource_len mistake spotted by Laurent The fb_base in struct drm_mode_config has been unused for a long time. Some drivers set it and some don't leading to a very confusing state where the variable can't be relied upon, because there's no indication as to which driver sets it and which doesn't. The only usage of fb_base is internal to two drivers so instead of trying to force it into all the drivers to get it into a coherent state completely remove it. Signed-off-by: Zack Rusin With the LKP report fixed: Reviewed-by: Thomas Zimmermann Best regards Thomas --- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 2 -- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 -- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 -- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 1 - drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 2 -- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 -- drivers/gpu/drm/ast/ast_mode.c | 1 - drivers/gpu/drm/gma500/framebuffer.c | 6 +++--- drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 16 +++- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 3 --- drivers/gpu/drm/mgag200/mgag200_mode.c | 1 - drivers/gpu/drm/msm/msm_fbdev.c | 2 -- drivers/gpu/drm/nouveau/nouveau_display.c| 1 - drivers/gpu/drm/nouveau/nv04_fbcon.c | 6 -- drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 -- drivers/gpu/drm/qxl/qxl_display.c| 2 -- drivers/gpu/drm/radeon/radeon_display.c | 2 -- drivers/gpu/drm/radeon/radeon_fb.c | 2 +- drivers/gpu/drm/tegra/fb.c | 1 - drivers/gpu/drm/tiny/bochs.c | 1 - include/drm/drm_mode_config.h| 2 -- 22 files changed, 12 insertions(+), 48 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c index f4b5301ea2a0..09dec2561adf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c @@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle) adev_to_drm(adev)->mode_config.preferred_depth = 24; adev_to_drm(adev)->mode_config.prefer_shadow = 1; - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; - r = amdgpu_display_modeset_create_props(adev); if (r) return r; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c index 288fce7dc0ed..05051d5d2ec3 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c @@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; - r = amdgpu_display_modeset_create_props(adev); if (r) return r; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c index cbe5250b31cb..c928bc9eb202 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c @@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; - r = amdgpu_display_modeset_create_props(adev); if (r) return r; diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index b1c44fab074f..62315fd5a05f 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.preferred_depth = 24; adev_to_drm(adev)->mode_config.prefer_shadow = 1; adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; r = amdgpu_display_modeset_create_props(adev); if (r) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c index a22b45c92792..87d5e4c21cb3 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c @@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle) adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; - r = amdgpu_display_modeset_create_props(adev); if (r) return r; diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index c053cb79cd06..0db2a88cd4d7 100644 --- a/drivers/gpu/drm/amd/display/amd
Re: [Intel-gfx] [PATCH] drm/i915/slpc: Optmize waitboost for SLPC
On 18/10/2022 23:15, Vinay Belgaumkar wrote:
Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rps.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2..a20ae4fceac8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1005,13 +1005,20 @@ void intel_rps_dec_waiters(struct intel_rps *rps)
void intel_rps_boost(struct i915_request *rq)
{
struct intel_guc_slpc *slpc;
+ struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
return;
+ /* If GuC is already requesting RP0, skip */
+ if (rps_uses_slpc(rps)) {
+ slpc = rps_to_slpc(rps);
+ if (intel_rps_get_requested_frequency(rps) == slpc->rp0_freq)
+ return;
+ }
+
Feels a little bit like a layering violation. Wait boost reference
counts and request markings will changed based on asynchronous state - a
mmio read.
Also, a little below we have this:
"""
/* Serializes with i915_request_retire() */
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
/* Return if old value is non zero */
if (!atomic_fetch_inc(&slpc->num_waiters))
*** Wouldn't it skip doing anything here already? ***
schedule_work(&slpc->boost_work);
return;
}
if (atomic_fetch_inc(&rps->num_waiters))
return;
"""
But I wonder if this is not a layering violation already. Looks like one
for me at the moment. And as it happens there is an ongoing debug of
clvk slowness where I was a bit puzzled by the lack of "boost fence" in
trace_printk logs - but now I see how that happens. Does not feel right
to me that we lose that tracing with SLPC.
So in general - why the correct approach wouldn't be to solve this in
the worker - which perhaps should fork to slpc specific branch and do
the consolidations/skips based on mmio reads in there?
Regards,
Tvrtko
/* Serializes with i915_request_retire() */
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
- struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
[PATCH -next] drm/amd/display: Make some symbols static
These symbols qp_table_422_10bpc_min, qp_table_444_8bpc_max,
qp_table_420_12bpc_max, qp_table_444_10bpc_min, qp_table_420_8bpc_max,
qp_table_444_8bpc_min, qp_table_444_12bpc_min, qp_table_420_12bpc_min,
qp_table_422_12bpc_min, qp_table_422_12bpc_max, qp_table_444_12bpc_max,
qp_table_420_8bpc_min, qp_table_422_8bpc_min, qp_table_422_10bpc_max,
qp_table_420_10bpc_max, qp_table_420_10bpc_min, qp_table_444_10bpc_max,
qp_table_422_8bpc_max are not used outside of the file,
so mark them static.
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:28:18: warning:
symbol 'qp_table_422_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:61:18: warning:
symbol 'qp_table_444_8bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:102:18: warning:
symbol 'qp_table_420_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:135:18: warning:
symbol 'qp_table_444_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:188:18: warning:
symbol 'qp_table_420_8bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:209:18: warning:
symbol 'qp_table_444_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:250:18: warning:
symbol 'qp_table_444_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:315:18: warning:
symbol 'qp_table_420_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:348:18: warning:
symbol 'qp_table_422_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:389:18: warning:
symbol 'qp_table_422_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:430:18: warning:
symbol 'qp_table_444_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:495:18: warning:
symbol 'qp_table_420_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:516:18: warning:
symbol 'qp_table_422_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:541:18: warning:
symbol 'qp_table_422_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:574:16: warning:
symbol 'qp_table_420_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:601:18: warning:
symbol 'qp_table_420_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:628:18: warning:
symbol 'qp_table_444_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:681:18: warning:
symbol 'qp_table_422_8bpc_max' was not declared. Should it be static?
Signed-off-by: ruanjinjie
---
.../drm/amd/display/dc/dml/dsc/qp_tables.h| 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h
b/drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h
index e5fac9f4181d..dcff0dd2b6a1 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h
@@ -25,7 +25,7 @@
*/
-const qp_table qp_table_422_10bpc_min = {
+static const qp_table qp_table_422_10bpc_min = {
{ 6, { 0, 4, 5, 6, 6, 6, 6, 7, 7, 8, 9, 9, 9, 12, 16} },
{ 6.5, { 0, 4, 5, 6, 6, 6, 6, 7, 7, 8, 9, 9, 9, 12, 16} },
{ 7, { 0, 4, 5, 6, 6, 6, 6, 7, 7, 7, 9, 9, 9, 11, 15} },
@@ -58,7 +58,7 @@ const qp_table qp_table_422_10bpc_min = {
};
-const qp_table qp_table_444_8bpc_max = {
+static const qp_table qp_table_444_8bpc_max = {
{ 6, { 4, 6, 8, 8, 9, 9, 9, 10, 11, 12, 12, 12, 12, 13, 15} },
{ 6.5, { 4, 6, 7, 8, 8, 8, 9, 10, 11, 11, 12, 12, 12, 13, 15} },
{ 7, { 4, 5, 7, 7, 8, 8, 8, 9, 10, 11, 11, 12, 12, 13, 14} },
@@ -99,7 +99,7 @@ const qp_table qp_table_444_8bpc_max = {
};
-const qp_table qp_table_420_12bpc_max = {
+static const qp_table qp_table_420_12bpc_max = {
{ 4, {11, 12, 13, 14, 15, 15, 15, 16, 17, 18, 18, 19, 19, 21, 22} },
{ 4.5, {10, 11, 12, 13, 14, 15, 15, 16, 17, 18, 18, 19, 19, 20, 21} },
{ 5, { 9, 11, 12, 13, 14, 15, 15, 16, 17, 17, 18, 18, 19, 20, 21} },
@@ -132,7 +132,7 @@ const qp_table qp_table_420_12bpc_max = {
};
-const qp_table qp_table_444_10bpc_min = {
+static const qp_table qp_table_444_10bpc_min = {
{ 6, { 0, 4, 7, 7, 9, 9, 9, 9, 9, 10, 10, 10, 10, 12, 18} }
Re: [PATCH 3/4] drm/i915/gt: Use RC6 residency types as arguments to residency functions
On Tue, 18 Oct 2022, Ashutosh Dixit wrote: > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h > b/drivers/gpu/drm/i915/gt/intel_rc6.h > index b6fea71afc223..3105bc72c096b 100644 > --- a/drivers/gpu/drm/i915/gt/intel_rc6.h > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h > @@ -6,7 +6,7 @@ > #ifndef INTEL_RC6_H > #define INTEL_RC6_H > > -#include "i915_reg_defs.h" > +#include "intel_rc6_types.h" > > struct intel_engine_cs; > struct intel_rc6; > @@ -21,7 +21,9 @@ void intel_rc6_sanitize(struct intel_rc6 *rc6); > void intel_rc6_enable(struct intel_rc6 *rc6); > void intel_rc6_disable(struct intel_rc6 *rc6); > > -u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, i915_reg_t reg); > -u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg); > +u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, enum intel_rc6_res_type > id); > +u64 intel_rc6_residency_us(struct intel_rc6 *rc6, enum intel_rc6_res_type > id); > +void intel_rc6_print_residency(struct seq_file *m, const char *title, > +enum intel_rc6_res_type id); > > #endif /* INTEL_RC6_H */ Please apply this on top to avoid includes from includes. diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h b/drivers/gpu/drm/i915/gt/intel_rc6.h index 3105bc72c096..456fa668a276 100644 --- a/drivers/gpu/drm/i915/gt/intel_rc6.h +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h @@ -6,10 +6,11 @@ #ifndef INTEL_RC6_H #define INTEL_RC6_H -#include "intel_rc6_types.h" +#include -struct intel_engine_cs; +enum intel_rc6_res_type; struct intel_rc6; +struct seq_file; void intel_rc6_init(struct intel_rc6 *rc6); void intel_rc6_fini(struct intel_rc6 *rc6); -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v5 12/22] drm/connector: Add a function to lookup a TV mode by its name
On Tue, Oct 18, 2022 at 02:29:00PM +0200, Noralf Trønnes wrote:
>
>
> Den 18.10.2022 11.33, skrev Maxime Ripard:
> > On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
> >> Den 13.10.2022 15.18, skrev Maxime Ripard:
> >>> As part of the command line parsing rework coming in the next patches,
> >>> we'll need to lookup drm_connector_tv_mode values by their name, already
> >>> defined in drm_tv_mode_enum_list.
> >>>
> >>> In order to avoid any code duplication, let's do a function that will
> >>> perform a lookup of a TV mode name and return its value.
> >>>
> >>> Signed-off-by: Maxime Ripard
> >>> ---
> >>> drivers/gpu/drm/drm_connector.c | 24
> >>> include/drm/drm_connector.h | 2 ++
> >>> 2 files changed, 26 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_connector.c
> >>> b/drivers/gpu/drm/drm_connector.c
> >>> index 820f4c730b38..30611c616435 100644
> >>> --- a/drivers/gpu/drm/drm_connector.c
> >>> +++ b/drivers/gpu/drm/drm_connector.c
> >>> @@ -991,6 +991,30 @@ static const struct drm_prop_enum_list
> >>> drm_tv_mode_enum_list[] = {
> >>> };
> >>> DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
> >>>
> >>> +/**
> >>> + * drm_get_tv_mode_from_name - Translates a TV mode name into its enum
> >>> value
> >>> + * @name: TV Mode name we want to convert
> >>> + * @len: Length of @name
> >>> + *
> >>> + * Translates @name into an enum drm_connector_tv_mode.
> >>> + *
> >>> + * Returns: the enum value on success, a negative errno otherwise.
> >>> + */
> >>> +int drm_get_tv_mode_from_name(const char *name, size_t len)
> >>
> >> Do we really need to pass in length here? item->name has to always be
> >> NUL terminated otherwise things would break elsewhere, so it shouldn't
> >> be necessary AFAICS.
> >
> > The only user so far is the command-line parsing code, and we might very
> > well have an option after the tv_mode, something like
> > 720x480i,tv_mode=NTSC,rotate=180
> >
> > In this case, we won't get a NULL-terminated name.
>
> My point is that item->name will always be NUL terminated so strcmp()
> will never look past that.
Right, but we don't have the guarantee that strlen(item->name) <
strlen(name), and we could thus just access after the end of our name
Maxime
signature.asc
Description: PGP signature
[PATCH 6.0 352/862] video/aperture: Disable and unregister sysfb devices via aperture helpers
From: Thomas Zimmermann
[ Upstream commit 5e01376124309b4dbd30d413f43c0d9c2f60edea ]
Call sysfb_disable() before removing conflicting devices in aperture
helpers. Fixes sysfb state if fbdev has been disabled.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Fixes: fb84efa28a48 ("drm/aperture: Run fbdev removal before internal helpers")
Cc: Zack Rusin
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Alex Deucher
Cc: Zhen Lei
Cc: Changcheng Deng
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Link:
https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-8-tzimmerm...@suse.de
Signed-off-by: Sasha Levin
---
drivers/video/aperture.c | 14 ++
drivers/video/fbdev/core/fbmem.c | 12
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 538f2d40acda..d245826a9324 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -286,7 +287,20 @@ int aperture_remove_conflicting_devices(resource_size_t
base, resource_size_t si
#if IS_REACHABLE(CONFIG_FB)
struct apertures_struct *a;
int ret;
+#endif
+
+ /*
+* If a driver asked to unregister a platform device registered by
+* sysfb, then can be assumed that this is a driver for a display
+* that is set up by the system firmware and has a generic driver.
+*
+* Drivers for devices that don't have a generic driver will never
+* ask for this, so let's assume that a real driver for the display
+* was already probed and prevent sysfb to register devices later.
+*/
+ sysfb_disable();
+#if IS_REACHABLE(CONFIG_FB)
a = alloc_apertures(1);
if (!a)
return -ENOMEM;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 02b0cf2cfafe..bda4d304feb6 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1777,17 +1776,6 @@ int remove_conflicting_framebuffers(struct
apertures_struct *a,
do_free = true;
}
- /*
-* If a driver asked to unregister a platform device registered by
-* sysfb, then can be assumed that this is a driver for a display
-* that is set up by the system firmware and has a generic driver.
-*
-* Drivers for devices that don't have a generic driver will never
-* ask for this, so let's assume that a real driver for the display
-* was already probed and prevent sysfb to register devices later.
-*/
- sysfb_disable();
-
mutex_lock(®istration_lock);
do_remove_conflicting_framebuffers(a, name, primary);
mutex_unlock(®istration_lock);
--
2.35.1
[PATCH 6.0 373/862] drm/panel: use select for Ili9341 panel driver helpers
From: Randy Dunlap
[ Upstream commit 84dfc46594b0167e5d3736273b0e0e05365da641 ]
Use 'select' instead of 'depends on' for DRM helpers for the
Ilitek ILI9341 panel driver.
This is what is done in the vast majority of other cases and
this makes it possible to fix a build error with drm_mipi_dbi.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Randy Dunlap
Cc: Dillon Min
Cc: Linus Walleij
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Linus Walleij
Link:
https://patchwork.freedesktop.org/patch/msgid/20220823004227.10820-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panel/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a9043eacce97..a582ddd583c2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -165,8 +165,8 @@ config DRM_PANEL_ILITEK_IL9322
config DRM_PANEL_ILITEK_ILI9341
tristate "Ilitek ILI9341 240x320 QVGA panels"
depends on OF && SPI
- depends on DRM_KMS_HELPER
- depends on DRM_GEM_CMA_HELPER
+ select DRM_KMS_HELPER
+ select DRM_GEM_DMA_HELPER
depends on BACKLIGHT_CLASS_DEVICE
select DRM_MIPI_DBI
help
--
2.35.1
[PATCH 6.0 374/862] drm: fix drm_mipi_dbi build errors
From: Randy Dunlap
[ Upstream commit eb7de496451bd969e203f02f66585131228ba4ae ]
drm_mipi_dbi needs lots of DRM_KMS_HELPER support, so select
that Kconfig symbol like it is done is most other uses, and
the way that it was before MIPS_DBI was moved from tinydrm
to its core location.
Fixes these build errors:
ld: drivers/gpu/drm/drm_mipi_dbi.o: in function `mipi_dbi_buf_copy':
drivers/gpu/drm/drm_mipi_dbi.c:205: undefined reference to `drm_gem_fb_get_obj'
ld: drivers/gpu/drm/drm_mipi_dbi.c:211: undefined reference to
`drm_gem_fb_begin_cpu_access'
ld: drivers/gpu/drm/drm_mipi_dbi.c:215: undefined reference to `drm_gem_fb_vmap'
ld: drivers/gpu/drm/drm_mipi_dbi.c:222: undefined reference to `drm_fb_swab'
ld: drivers/gpu/drm/drm_mipi_dbi.c:224: undefined reference to `drm_fb_memcpy'
ld: drivers/gpu/drm/drm_mipi_dbi.c:227: undefined reference to
`drm_fb_xrgb_to_rgb565'
ld: drivers/gpu/drm/drm_mipi_dbi.c:235: undefined reference to
`drm_gem_fb_vunmap'
ld: drivers/gpu/drm/drm_mipi_dbi.c:237: undefined reference to
`drm_gem_fb_end_cpu_access'
ld: drivers/gpu/drm/drm_mipi_dbi.o: in function
`mipi_dbi_dev_init_with_formats':
ld: drivers/gpu/drm/drm_mipi_dbi.o:/X64/../drivers/gpu/drm/drm_mipi_dbi.c:469:
undefined reference to `drm_gem_fb_create_with_dirty'
Fixes: 174102f4de23 ("drm/tinydrm: Move mipi-dbi")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Dillon Min
Cc: Linus Walleij
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Linus Walleij
Link:
https://patchwork.freedesktop.org/patch/msgid/20220823004243.11596-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 6c2256e8474b..679ad054ea4b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -31,6 +31,7 @@ menuconfig DRM
config DRM_MIPI_DBI
tristate
depends on DRM
+ select DRM_KMS_HELPER
config DRM_MIPI_DSI
bool
--
2.35.1
Re: [PATCH 2/2] drm/tiny: add support for tft displays based on ilitek,ili9488
On Tue, Oct 18, 2022 at 08:31:22PM +0200, Michael Nazzareno Trimarchi wrote: Hi Michael, > Hi > > On Tue, Oct 18, 2022 at 6:46 PM Tommaso Merciai > wrote: > > > > This adds support for ilitek,ili9488 based displays with shift register > > in front of controller. Waveshare,pico-restouch-lcd-3.5 are such displays > > > > Signed-off-by: Tommaso Merciai > > --- > > Because I start to make it working this driver, I think that my > signed-off is missing here Yes, right. :) I upload in v2, my bad > > > drivers/gpu/drm/tiny/Kconfig | 13 + > > drivers/gpu/drm/tiny/Makefile | 1 + > > drivers/gpu/drm/tiny/ili9488.c | 440 + > > 3 files changed, 454 insertions(+) > > create mode 100644 drivers/gpu/drm/tiny/ili9488.c > > > > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig > > index 027cd87c3d0d7..6e708e8414806 100644 > > --- a/drivers/gpu/drm/tiny/Kconfig > > +++ b/drivers/gpu/drm/tiny/Kconfig > > @@ -148,6 +148,19 @@ config TINYDRM_ILI9486 > > > > If M is selected the module will be called ili9486. > > > > +config TINYDRM_ILI9488 > > + tristate "DRM support for ILI9488 display panels" > > + depends on DRM && SPI > > + select DRM_KMS_HELPER > > + select DRM_GEM_CMA_HELPER > > + select DRM_MIPI_DBI > > + select BACKLIGHT_CLASS_DEVICE > > + help > > + DRM driver for the following Ilitek ILI9488 panels: > > + * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5") > > + > > + If M is selected the module will be called ili9486. > > + > > config TINYDRM_MI0283QT > > tristate "DRM support for MI0283QT" > > depends on DRM && SPI > > diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile > > index 1d9d6227e7ab7..aad6683b2ac40 100644 > > --- a/drivers/gpu/drm/tiny/Makefile > > +++ b/drivers/gpu/drm/tiny/Makefile > > @@ -11,6 +11,7 @@ obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o > > obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o > > obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o > > obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o > > +obj-$(CONFIG_TINYDRM_ILI9488) += ili9488.o > > obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o > > obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o > > obj-$(CONFIG_TINYDRM_ST7586) += st7586.o > > diff --git a/drivers/gpu/drm/tiny/ili9488.c b/drivers/gpu/drm/tiny/ili9488.c > > new file mode 100644 > > index 0..b94d9d4ff4544 > > --- /dev/null > > +++ b/drivers/gpu/drm/tiny/ili9488.c > > @@ -0,0 +1,440 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * DRM driver for Ilitek ILI9488 panels > > + * > > + * Copyright 2020 Kamlesh Gurudasani > > + */ > > Code was changed a bit so please add copyright of me and you Agree, thanks. > > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define ILI9488_VCOM_CONTROL_1 0xC5 > > +#define ILI9488_COLUMN_ADDRESS_SET 0x2A > > +#define ILI9488_PAGE_ADDRESS_SET 0x2B > > +#define ILI9488_MEMORY_WRITE 0x2C > > +#define ILI9488_POSITIVE_GAMMA_CORRECTION 0xE0 > > +#define ILI9488_NEGATIVE_GAMMA_CORRECTION 0xE1 > > +#define ILI9488_POWER_CONTROL_10xC0 > > +#define ILI9488_POWER_CONTROL_20xC1 > > +#define ILI9488_POWER_CONTROL_30xC2 > > +#define ILI9488_MEM_ACCESS_CONTROL 0x36 > > +#define ILI9488_COLMOD_PIXEL_FORMAT_SET0x3A > > +#define ILI9488_INTERFACE_MODE_CONTROL 0xB0 > > +#define ILI9488_FRAME_RATE_CONTROL_PARTIAL 0xB3 > > +#define ILI9488_DISPLAY_INVERSION_ON 0x21 > > +#define ILI9488_DISPLAY_INVERSION_CONTROL 0xB4 > > +#define ILI9488_DISPLAY_FUNCTION_CONTROL 0xB6 > > +#define ILI9488_ENTRY_MODE_SET 0xB7 > > +#define ILI9488_HS_LANES_CONTROL 0xBE > > +#define ILI9488_SET_IMAGE_FUNCTION 0xE9 > > +#define ILI9488_ADJUST_CONTROL_3 0xF7 > > +#define ILI9488_DISPLAY_ON 0x29 > > +#define ILI9488_DISPLAY_OFF0x28 > > +#define ILI9488_ENTER_SLEEP_MODE 0x10 > > +#define ILI9488_DBI_BPP18 0x06 > > +#define ILI9488_DBI_BPP16 0x05 > > +#define ILI9488_DPI_BPP24 0x70 > > +#define ILI9488_DPI_BPP18 0x60 > > +#define ILI9488_DPI_BPP16 0x50 > > +#define ILI9488_FRAME_RATE_CONTROL_NORMAL 0xB1 > > +#define ILI9488_SLEEP_OUT 0x11 > > + > > +#define ILI9488_MADCTL_RGB BIT(2) > > +#define ILI9488_MADCTL_BGR BIT(3) > > +#define
[PATCH v3] drm: mediatek: Modify dpi power on/off sequence.
From: Xinlei Lee
Modify dpi power on/off sequence so that the first gpio operation will take
effect.
Fixes: 6bd4763fd532 ("drm/mediatek: set dpi pin mode to gpio low to avoid
leakage current")
Signed-off-by: Xinlei Lee
---
change note:
v2: Remove the empty line between Fixes: and S-o-b.
v1: Rebase on linus/master v6.1-rc1. Change nothing.
Because dpi power_on/off is protected by dpi->refcount, the first time
it cannot be powered on and off successfully, it will cause leakage.
---
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 508a6d994e83..f83cf64c2828 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -461,9 +461,6 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
if (--dpi->refcount != 0)
return;
- if (dpi->pinctrl && dpi->pins_gpio)
- pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
-
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
@@ -488,9 +485,6 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_pixel;
}
- if (dpi->pinctrl && dpi->pins_dpi)
- pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
-
return 0;
err_pixel:
@@ -720,6 +714,9 @@ static void mtk_dpi_bridge_disable(struct drm_bridge
*bridge)
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ if (dpi->pinctrl && dpi->pins_gpio)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
mtk_dpi_power_off(dpi);
}
@@ -727,6 +724,9 @@ static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ if (dpi->pinctrl && dpi->pins_dpi)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, &dpi->mode);
mtk_dpi_enable(dpi);
--
2.18.0
Re: [PATCH 2/2] drm/tiny: add support for tft displays based on ilitek, ili9488
Hello Tommaso,
On 10/18/22 18:45, Tommaso Merciai wrote:
[...]
> +config TINYDRM_ILI9488
> + tristate "DRM support for ILI9488 display panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_MIPI_DBI
> + select BACKLIGHT_CLASS_DEVICE
> + help
> + DRM driver for the following Ilitek ILI9488 panels:
> + * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5")
> +
> + If M is selected the module will be called ili9486.
> +
Typo here, should be ili9488.
[...]
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
Please sort these alphabetically
> +
> +static void ili9488_rgb565_to_rgb666_line(u8 *dst, u16 *sbuf,
> + unsigned int pixels)
> +{
> + unsigned int x;
> +
> + for (x = 0; x < pixels; x++) {
> + *dst++ = ((*sbuf & 0xF800) >> 8);
> + *dst++ = ((*sbuf & 0x07E0) >> 3);
> + *dst++ = ((*sbuf & 0x001F) << 3);
> + sbuf++;
> + }
> +}
> +
If these format conversions helpers are really needed, they need to be
added as helpers to drivers/gpu/drm/drm_format_helper.c instead.
> +static void ili9488_rgb565_to_rgb666(u8 *dst, void *vaddr,
> + struct drm_framebuffer *fb,
> + struct drm_rect *rect)
> +{
> + unsigned long linepixels = drm_rect_width(rect);
> + unsigned long lines = drm_rect_height(rect);
> + size_t dst_len = linepixels * 3;
> + size_t src_len = linepixels * fb->format->cpp[0];
> + unsigned int y;
> + u16 *sbuf;
> +
> + /*
> + * The cma memory is write-combined so reads are uncached.
> + * Speed up by fetching one line at a time.
> + */
> + sbuf = kmalloc(src_len, GFP_KERNEL);
> + if (!sbuf)
> + return;
This will cause an extra copy even when CMA isn't used. Please take a look
how the format helpers do this. You should pass a struct iosys_map param
and internally use the drm_fb_xfrm() helper that would handle both the I/O
mem and system memory cases.
> +static int ili9488_buf_copy(void *dst, struct drm_framebuffer *fb,
> + struct drm_rect *rect)
> +{
> + struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
> + void *src = cma_obj->vaddr;
> + int ret = 0;
> +
> + ret = drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE);
> + if (ret)
> + return ret;
> +
If you rebase on top of the "[PATCH 0/5] drm: Add new plane helpers to
begin/end FB access" series then an explicit CPU access to GEM BOs sync
isn't needed anymore:
https://lore.kernel.org/dri-devel/20221017111510.20818-1-tzimmerm...@suse.de/
> + switch (fb->format->format) {
> + case DRM_FORMAT_RGB565:
> + ili9488_rgb565_to_rgb666(dst, src, fb, rect);
This is the biggest issue I see with this driver. The exported format is
RGB565 but RGB666 is used. I believe the policy is for the driver to expose
the native format to user-space.
I know that there isn't a DRM_FORMAT_RGB666 in neither DRM nor mesa, but
still I think that adding it should be part of this series. If you also
want to expose DRM_FORMAT_RGB565 for compatibility reasons, then I guess
that's OK but as mentioned the format helpers need to be in the DRM core.
[...]
> +static void ili9488_fb_dirty(struct drm_framebuffer *fb, struct drm_rect
> *rect)
> +{
This looks very similar, if not the same than the mipi_dbi_fb_dirty() helper.
[...]
> +static void ili9488_pipe_update(struct drm_simple_display_pipe *pipe,
> +struct drm_plane_state *old_state)
> +{
And same for this, it's basically mipi_dbi_pipe_update() if you end using the
mipi_dbi_fb_dirty() helper instead of a custom ili9488_fb_dirty() handler.
> + struct drm_plane_state *state = pipe->plane.state;
> + struct drm_rect rect;
> +
> + if (!pipe->crtc.state->active)
> + return;
> +
> + if (drm_atomic_helper_damage_merged(old_state, state, &rect))
> + ili9488_fb_dirty(state->fb, &rect);
I see that most MIPI DBI drivers use this function to merge all the damage clips
into a big rectangle. Is there a reason why this is done in this way rather than
just iterating over all the damage areas and update them one by one?
Since for example there are multiple damage clips that aren't close to each
other,
the resulting rectangle could be quite big.
[...]
> +DEFINE_DRM_GEM_CMA_FOPS(ili9488_fops);
> +
Do you really need CMA for this? Can't you just use DEFINE_DRM_GEM_FOPS()
instead?
> +static struct drm_driver ili9488_driver = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .fops = &ili9488_fops,
> + DRM_GEM_CMA_DRIVER_OPS_VMAP,
DRM_GEM_SHMEM_DRIVER_OPS, ?
> + .debugfs_init
Re: [RFC PATCH] drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices
On 2022-08-26 12:16:40, Dmitry Baryshkov wrote:
> On 05/08/2022 15:24, Marijn Suijten wrote:
> > On 2022-08-05 14:56:30, Dmitry Baryshkov wrote:
> >> The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
> >> components") changed the MDP5 driver to look for the interconnect paths
> >> in the MDSS device rather than in the MDP5 device itself. This was left
> >> unnoticed since on my testing devices the interconnects probably didn't
> >> reach the sync state.
> >>
> >> Rather than just using the MDP5 device for ICC path lookups for the MDP5
> >> devices, introduce an additional helper to check both MDP5/DPU and MDSS
> >> nodes. This will be helpful for the MDP5->DPU conversion, since the
> >> driver will have to check both nodes.
> >>
> >> Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
> >> Reported-by: Marijn Suijten
> >> Reported-by: Yassine Oudjana
> >> Signed-off-by: Dmitry Baryshkov
> >
> > Tested-by: Marijn Suijten # On sdm630
> >
> > But I'm not sure about giving my Reviewed-by to this, as I'd rather
> > *correct* the DT bindings for sdm630 and msm8996 to provide
> > interconnects in the MDSS node unless there are strong reasons not to
> > (and I don't consider "backwards compatibility" to be one, this binding
> > "never even existed" if mdp5.txt is to be believed).
>
> As a kind of a joke, I'd prefer to have interconnects in the mdp/dpu
> device node. In the end, the interconnects describe the path between the
> display controller and the DDR, not the path between the whole MDSS and DDR.
>
> So, for next chipsets I'd vote to move icc to dpu/mdp node (and maybe
> even move existing inerconnects to the dpu node).
Sure. In that case, do you want to rework this patch / code again to
only look in the DPU/MDP, and not at MDSS at all? (Or is that another
DT API break we'd rather not make?)
- Marijn
Re: [RFC PATCH] drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices
On 19/10/2022 12:13, Marijn Suijten wrote:
On 2022-08-26 12:16:40, Dmitry Baryshkov wrote:
On 05/08/2022 15:24, Marijn Suijten wrote:
On 2022-08-05 14:56:30, Dmitry Baryshkov wrote:
The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
components") changed the MDP5 driver to look for the interconnect paths
in the MDSS device rather than in the MDP5 device itself. This was left
unnoticed since on my testing devices the interconnects probably didn't
reach the sync state.
Rather than just using the MDP5 device for ICC path lookups for the MDP5
devices, introduce an additional helper to check both MDP5/DPU and MDSS
nodes. This will be helpful for the MDP5->DPU conversion, since the
driver will have to check both nodes.
Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
Reported-by: Marijn Suijten
Reported-by: Yassine Oudjana
Signed-off-by: Dmitry Baryshkov
Tested-by: Marijn Suijten # On sdm630
But I'm not sure about giving my Reviewed-by to this, as I'd rather
*correct* the DT bindings for sdm630 and msm8996 to provide
interconnects in the MDSS node unless there are strong reasons not to
(and I don't consider "backwards compatibility" to be one, this binding
"never even existed" if mdp5.txt is to be believed).
As a kind of a joke, I'd prefer to have interconnects in the mdp/dpu
device node. In the end, the interconnects describe the path between the
display controller and the DDR, not the path between the whole MDSS and DDR.
So, for next chipsets I'd vote to move icc to dpu/mdp node (and maybe
even move existing inerconnects to the dpu node).
Sure. In that case, do you want to rework this patch / code again to
only look in the DPU/MDP, and not at MDSS at all? (Or is that another
DT API break we'd rather not make?)
I'd rather not make this break. Let's keep backwards compatibility at
least for now.
--
With best wishes
Dmitry
[PATCH v5 0/2] *** IT6505 driver read dt properties ***
This series let driver can read properties from dt to restrict dp output bandwidth. Changes in v3: -Rename property name. Changes in v4: -Use data-lanes and link-frequencies instead of "ite,dp-output-data-lane-count" and "ite,dp-output-max-pixel-clock-mhz". Changes in v5: -Add a port and a endpoint. -Move data-lanes property to the output endpoint. allen chen (2): dt-bindings: it6505: add properties to restrict output bandwidth drm/bridge: add it6505 driver to read data-lanes and link-frequencies from dt .../bindings/display/bridge/ite,it6505.yaml | 89 +-- drivers/gpu/drm/bridge/ite-it6505.c | 80 - 2 files changed, 160 insertions(+), 9 deletions(-) -- 2.25.1
[PATCH v5 1/2] dt-bindings: it6505: add properties to restrict output bandwidth
From: allen chen
Add properties to restrict dp output data-lanes and clock.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.yaml | 89 +--
1 file changed, 83 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
index 833d11b2303a7..8e607b6929fc9 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -52,9 +52,70 @@ properties:
maxItems: 1
description: extcon specifier for the Power Delivery
- port:
-$ref: /schemas/graph.yaml#/properties/port
-description: A port node pointing to DPI host port node
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: A port node pointing to DPI host port node
+
+properties:
+ endpoint:
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+ link-frequencies:
+minItems: 1
+maxItems: 1
+description: Allowed max link frequencies in Hz
+
+ port@1:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: Video port for DP output
+
+properties:
+ endpoint:
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+oneOf:
+ - minItems: 1
+maxItems: 1
+uniqueItems: true
+items:
+ enum:
+- 0
+- 1
+description: For one lane operation.
+
+ - minItems: 2
+maxItems: 2
+uniqueItems: true
+items:
+ enum:
+- 0
+- 1
+description: For two lanes operation.
+
+ - minItems: 4
+maxItems: 4
+uniqueItems: true
+items:
+ enum:
+- 0
+- 1
+- 2
+- 3
+description: For four lanes operation.
+required:
+ - port@0
+ - port@1
required:
- compatible
@@ -63,6 +124,7 @@ required:
- interrupts
- reset-gpios
- extcon
+ - ports
additionalProperties: false
@@ -85,9 +147,24 @@ examples:
reset-gpios = <&pio 179 1>;
extcon = <&usbc_extcon>;
-port {
-it6505_in: endpoint {
-remote-endpoint = <&dpi_out>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+it6505_in: endpoint {
+remote-endpoint = <&dpi_out>;
+link-frequencies = /bits/ 64 <15000>;
+};
+};
+
+port@1 {
+reg = <1>;
+it6505_out: endpoint {
+remote-endpoint = <&dp_in>;
+data-lanes = <0 1>;
+};
};
};
};
--
2.25.1
[PATCH v5 2/2] drm/bridge: add it6505 driver to read data-lanes and link-frequencies from dt
From: allen chen
Add driver to read data-lanes and link-frequencies from dt property to
restrict output bandwidth.
Signed-off-by: Allen chen
Signed-off-by: Pin-yen Lin
---
drivers/gpu/drm/bridge/ite-it6505.c | 80 +++--
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index a4302492cf8df..ed4536cde3140 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -437,6 +437,8 @@ struct it6505 {
bool powered;
bool hpd_state;
u32 afe_setting;
+ u32 max_dpi_pixel_clock;
+ u32 max_lane_count;
enum hdcp_state hdcp_status;
struct delayed_work hdcp_work;
struct work_struct hdcp_wait_ksv_list;
@@ -1476,7 +1478,8 @@ static void it6505_parse_link_capabilities(struct it6505
*it6505)
it6505->lane_count = link->num_lanes;
DRM_DEV_DEBUG_DRIVER(dev, "Sink support %d lanes training",
it6505->lane_count);
- it6505->lane_count = min_t(int, it6505->lane_count, MAX_LANE_COUNT);
+ it6505->lane_count = min_t(int, it6505->lane_count,
+ it6505->max_lane_count);
it6505->branch_device = drm_dp_is_branch(it6505->dpcd);
DRM_DEV_DEBUG_DRIVER(dev, "Sink %sbranch device",
@@ -2912,7 +2915,7 @@ it6505_bridge_mode_valid(struct drm_bridge *bridge,
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
return MODE_NO_INTERLACE;
- if (mode->clock > DPI_PIXEL_CLK_MAX)
+ if (mode->clock > it6505->max_dpi_pixel_clock)
return MODE_CLOCK_HIGH;
it6505->video_info.clock = mode->clock;
@@ -3099,10 +3102,32 @@ static int it6505_init_pdata(struct it6505 *it6505)
return 0;
}
+static int it6505_get_data_lanes_count(const struct device_node *endpoint,
+ const unsigned int min,
+ const unsigned int max)
+{
+ int ret;
+
+ ret = of_property_count_u32_elems(endpoint, "data-lanes");
+ if (ret < 0)
+ return ret;
+
+ if (ret < min || ret > max)
+ return -EINVAL;
+
+ return ret;
+}
+
static void it6505_parse_dt(struct it6505 *it6505)
{
struct device *dev = &it6505->client->dev;
+ struct device_node *np = dev->of_node, *ep = NULL;
+ int len;
+ u64 link_frequencies;
+ u32 data_lanes[4];
u32 *afe_setting = &it6505->afe_setting;
+ u32 *max_lane_count = &it6505->max_lane_count;
+ u32 *max_dpi_pixel_clock = &it6505->max_dpi_pixel_clock;
it6505->lane_swap_disabled =
device_property_read_bool(dev, "no-laneswap");
@@ -3118,7 +3143,56 @@ static void it6505_parse_dt(struct it6505 *it6505)
} else {
*afe_setting = 0;
}
- DRM_DEV_DEBUG_DRIVER(dev, "using afe_setting: %d", *afe_setting);
+
+ ep = of_graph_get_endpoint_by_regs(np, 1, 0);
+ of_node_put(ep);
+
+ if (ep) {
+ len = it6505_get_data_lanes_count(ep, 1, 4);
+
+ if (len > 0 && len != 3) {
+ of_property_read_u32_array(ep, "data-lanes",
+ data_lanes, len);
+ *max_lane_count = len;
+ } else {
+ *max_lane_count = MAX_LANE_COUNT;
+ dev_err(dev, "error data-lanes, use default");
+ }
+ } else {
+ *max_lane_count = MAX_LANE_COUNT;
+ dev_err(dev, "error endpoint, use default");
+ }
+
+ ep = of_graph_get_endpoint_by_regs(np, 0, 0);
+ of_node_put(ep);
+
+ if (ep) {
+ len = of_property_read_variable_u64_array(ep,
+ "link-frequencies",
+ &link_frequencies, 0,
+ 1);
+ if (len >= 0) {
+ do_div(link_frequencies, 1000);
+ if (link_frequencies > 297000) {
+ dev_err(dev,
+ "max pixel clock error, use default");
+ *max_dpi_pixel_clock = DPI_PIXEL_CLK_MAX;
+ } else {
+ *max_dpi_pixel_clock = link_frequencies;
+ }
+ } else {
+ dev_err(dev, "error link frequencies, use default");
+ *max_dpi_pixel_clock = DPI_PIXEL_CLK_MAX;
+ }
+ } else {
+ dev_err(dev, "error endpoint, use default");
+ *max_dpi_pixel_clock = DPI_PIXEL_CLK_MAX;
+ }
+
+ DRM_DEV_DEBUG_DRIVER(dev, "using afe_setting: %u, max_lane_count: %u",
+it65
Re: [PATCH v2 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On 13-10-2022 05:33, Daniele Ceraolo Spurio wrote:
> On MTL the primary GT doesn't have any media capabilities, so no video
> engines and no HuC. We must therefore skip the HuC fetch and load on
> that specific case. Given that other multi-GT platforms might have HuC
> on the primary GT, we can't just check for that and it is easier to
> instead check for the lack of VCS engines.
>
> Based on code from Aravind Iddamsetty
>
> v2: clarify which engine_mask is used for each GT and why (Tvrtko)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Aravind Iddamsetty
> Cc: John Harrison
> Cc: Alan Previn
> Cc: Tvrtko Ursulin
> Reviewed-by: Aravind Iddamsetty #v1
> ---
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 29 ++
> drivers/gpu/drm/i915/i915_drv.h| 9 +---
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 4d1cc383b681..ca170ea3426c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -203,12 +203,41 @@ void intel_huc_unregister_gsc_notifier(struct intel_huc
> *huc, struct bus_type *b
> huc->delayed_load.nb.notifier_call = NULL;
> }
>
> +static bool vcs_supported(struct intel_gt *gt)
> +{
> + intel_engine_mask_t mask = gt->info.engine_mask;
> +
> + /*
> + * We reach here from i915_driver_early_probe for the primary GT before
> + * its engine mask is set, so we use the device info engine mask for it;
> + * this means we're not taking VCS fusing into account, but if the
> + * primary GT supports VCS engines we expect at least one of them to
> + * remain unfused so we're fine.
> + * For other GTs we expect the GT-specific mask to be set before we
> + * call this function.
> + */
Comment sounds good to me. as the rest of the change is same as v1, You
can have my r-b for this.
Thanks,
Aravind.
> + GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
> +
> + if (gt_is_root(gt))
> + mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
> + else
> + mask = gt->info.engine_mask;
> +
> + return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
> +}
> +
> void intel_huc_init_early(struct intel_huc *huc)
> {
> struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
> + struct intel_gt *gt = huc_to_gt(huc);
>
> intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
>
> + if (!vcs_supported(gt)) {
> + intel_uc_fw_change_status(&huc->fw,
> INTEL_UC_FIRMWARE_NOT_SUPPORTED);
> + return;
> + }
> +
> if (GRAPHICS_VER(i915) >= 11) {
> huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
> huc->status.mask = HUC_LOAD_SUCCESSFUL;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 90ed8e6db2fe..90a347140e90 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -776,12 +776,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
> #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
>
> -#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
> +#define __ENGINE_INSTANCES_MASK(mask, first, count) ({
> \
> unsigned int first__ = (first); \
> unsigned int count__ = (count); \
> - ((gt)->info.engine_mask &
> \
> - GENMASK(first__ + count__ - 1, first__)) >> first__; \
> + ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__; \
> })
> +
> +#define ENGINE_INSTANCES_MASK(gt, first, count) \
> + __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
> +
> #define RCS_MASK(gt) \
> ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
> #define BCS_MASK(gt) \
Re: [PATCH v2 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On 19-10-2022 06:14, John Harrison wrote: > On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote: >> From: Aravind Iddamsetty >> >> With MTL standalone media architecture the wopcm layout has changed with >> separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size > What is GCD? Graphics Companion Die, no media on it. Thanks, Aravind.
Re: [PATCH] drm/i915/gvt: Add missing vfio_unregister_group_dev() call
On 10/6/22 18:31, Alex Williamson wrote: > On Thu, 6 Oct 2022 08:37:09 -0300 > Jason Gunthorpe wrote: > >> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote: >>> We can't have a .remove callback that does nothing, this breaks >>> removing the device while it's in use. Once we have the >>> vfio_unregister_group_dev() fix below, we'll block until the device is >>> unused, at which point vgpu->attached becomes false. Unless I'm >>> missing something, I think we should also follow-up with a patch to >>> remove that bogus warn-on branch, right? Thanks, >> >> Yes, looks right to me. >> >> I question all the logical arround attached, where is the locking? > > Zhenyu, Zhi, Kevin, > > Could someone please take a look at use of vgpu->attached in the GVT-g > driver? It's use in intel_vgpu_remove() is bogus, the .release > callback needs to use vfio_unregister_group_dev() to wait for the > device to be unused. The WARN_ON/return here breaks all future use of > the device. I assume @attached has something to do with the page table > interface with KVM, but it all looks racy anyway. > Thanks for pointing this out. It was introduced in the GVT-g refactor patch series and Christoph might not want to touch the vgpu->released while he needed a new state. I dig it a bit. vgpu->attached would be used for preventing multiple open on a single vGPU and indicate the kvm_get_kvm() has been done. vgpu->released was to prevent the release before close, which is now handled by the vfio_device_*. What I would like to do are: 1) Remove the vgpu->released. 2) Use alock to protect vgpu->attached. After those were solved, the WARN_ON/return in the intel_vgpu_remove() should be safely removed as the .release will be called after .close_device deceases the vfio_device->refcnt to zero. Thanks, Zhi. > Also, whatever purpose vgpu->released served looks unnecessary now. > Thanks, > > Alex >
Re: [PATCH v4] drm: Remove drm_mode_config::fb_base
On Tue, Oct 18, 2022 at 10:43:50PM -0400, Zack Rusin wrote: > From: Zack Rusin > > v4: Fix issue spotted by the kernel test robot > > The fb_base in struct drm_mode_config has been unused for a long time. > Some drivers set it and some don't leading to a very confusing state > where the variable can't be relied upon, because there's no indication > as to which driver sets it and which doesn't. > > The only usage of fb_base is internal to two drivers so instead of trying > to force it into all the drivers to get it into a coherent state > completely remove it. > > Signed-off-by: Zack Rusin Reviewed-by: Laurent Pinchart Please include the tag if you post a v5 of the patch. > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 2 -- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 -- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 -- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 1 - > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 2 -- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 -- > drivers/gpu/drm/ast/ast_mode.c | 2 -- > drivers/gpu/drm/gma500/framebuffer.c | 6 +++--- > drivers/gpu/drm/gma500/psb_drv.h | 1 + > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 16 +++- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 3 --- > drivers/gpu/drm/mgag200/mgag200_mode.c | 1 - > drivers/gpu/drm/msm/msm_fbdev.c | 2 -- > drivers/gpu/drm/nouveau/nouveau_display.c| 1 - > drivers/gpu/drm/nouveau/nv04_fbcon.c | 6 -- > drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 -- > drivers/gpu/drm/qxl/qxl_display.c| 2 -- > drivers/gpu/drm/radeon/radeon_display.c | 2 -- > drivers/gpu/drm/radeon/radeon_fb.c | 2 +- > drivers/gpu/drm/tegra/fb.c | 1 - > drivers/gpu/drm/tiny/bochs.c | 1 - > include/drm/drm_mode_config.h| 2 -- > 22 files changed, 12 insertions(+), 49 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c > index f4b5301ea2a0..09dec2561adf 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c > @@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle) > adev_to_drm(adev)->mode_config.preferred_depth = 24; > adev_to_drm(adev)->mode_config.prefer_shadow = 1; > > - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > - > r = amdgpu_display_modeset_create_props(adev); > if (r) > return r; > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c > index 288fce7dc0ed..05051d5d2ec3 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c > @@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle) > > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; > > - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > - > r = amdgpu_display_modeset_create_props(adev); > if (r) > return r; > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c > index cbe5250b31cb..c928bc9eb202 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c > @@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle) > > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; > > - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > - > r = amdgpu_display_modeset_create_props(adev); > if (r) > return r; > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > index b1c44fab074f..62315fd5a05f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > @@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle) > adev_to_drm(adev)->mode_config.preferred_depth = 24; > adev_to_drm(adev)->mode_config.prefer_shadow = 1; > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; > - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > > r = amdgpu_display_modeset_create_props(adev); > if (r) > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c > index a22b45c92792..87d5e4c21cb3 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c > @@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle) > > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true; > > - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > - > r = amdgpu_display_modeset_create_props(adev); > if (r) > return r; > diff --git a/driv
RE: [PATCH] drm/i915/gvt: Add missing vfio_unregister_group_dev() call
> From: Wang, Zhi A
> Sent: Wednesday, October 19, 2022 5:41 PM
>
> On 10/6/22 18:31, Alex Williamson wrote:
> > On Thu, 6 Oct 2022 08:37:09 -0300
> > Jason Gunthorpe wrote:
> >
> >> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> >>> We can't have a .remove callback that does nothing, this breaks
> >>> removing the device while it's in use. Once we have the
> >>> vfio_unregister_group_dev() fix below, we'll block until the device is
> >>> unused, at which point vgpu->attached becomes false. Unless I'm
> >>> missing something, I think we should also follow-up with a patch to
> >>> remove that bogus warn-on branch, right? Thanks,
> >>
> >> Yes, looks right to me.
> >>
> >> I question all the logical arround attached, where is the locking?
> >
> > Zhenyu, Zhi, Kevin,
> >
> > Could someone please take a look at use of vgpu->attached in the GVT-g
> > driver? It's use in intel_vgpu_remove() is bogus, the .release
> > callback needs to use vfio_unregister_group_dev() to wait for the
> > device to be unused. The WARN_ON/return here breaks all future use of
> > the device. I assume @attached has something to do with the page table
> > interface with KVM, but it all looks racy anyway.
> >
> Thanks for pointing this out.
>
> It was introduced in the GVT-g refactor patch series and Christoph might
> not want to touch the vgpu->released while he needed a new state.
>
> I dig it a bit. vgpu->attached would be used for preventing multiple open
> on a single vGPU and indicate the kvm_get_kvm() has been done.
vfio core already ensures that .open_device() is called only once:
vfio_device_open()
{
...
mutex_lock(&device->dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
...
if (device->ops->open_device) {
ret = device->ops->open_device(device);
...
}
> vgpu->released was to prevent the release before close, which is now
> handled by the vfio_device_*.
>
> What I would like to do are:
> 1) Remove the vgpu->released. 2) Use alock to protect vgpu->attached.
>
> After those were solved, the WARN_ON/return in the intel_vgpu_remove()
> should be safely removed as the .release will be called after .close_device
> deceases the vfio_device->refcnt to zero.
>
> Thanks,
> Zhi.
>
> > Also, whatever purpose vgpu->released served looks unnecessary now.
> > Thanks,
> >
> > Alex
> >
Re: [PATCH v7 00/10] drm: bridge: Add Samsung MIPI DSIM bridge
Hi Jagan On Wed, 2022-10-05 at 20:42 +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. > > Changes for v7: > * fix the drm bridge attach chain for exynos drm dsi driver > * fix the hw_type checking logic > > Changes for v6: > * handle previous bridge for exynos dsi while attaching bridge > > Changes for v5: > * bridge changes to support multi-arch > * updated and clear commit messages > * add hw_type via plat data > * removed unneeded quirk > * rebased on linux-next > > Changes for v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > * update init handling to ensure host init done on first cmd transfer > > Changes for v3: > * fix the mult-arch build > * fix dsi host init > * updated commit messages > > Changes for v2: > * fix bridge handling > * fix dsi host init > * correct the commit messages > > Patch 0001: Samsung DSIM bridge > > Patch 0002: PHY optional > > Patch 0003: OF-graph or Child node lookup > > Patch 0004: DSI host initialization > > Patch 0005: atomic check > > Patch 0006: PMS_P offset via plat data > > Patch 0007: atomic_get_input_bus_fmts > > Patch 0008: input_bus_flags > > Patch 0009: document fsl,imx8mm-mipi-dsim > > Patch 0010: add i.MX8MM DSIM support > > Tested in Engicam i.Core MX8M Mini SoM. Thanks for this work! This also works great on Verdin iMX8M Mini together with the SN65DSI84-based Verdin DSI to LVDS Adapter. Tested-by: Marcel Ziswiler > Repo: > https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v7 > > Any inputs? > Jagan. > > Jagan Teki (10): > drm: bridge: Add Samsung DSIM bridge driver > drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices > drm: bridge: samsung-dsim: Mark PHY as optional > drm: bridge: samsung-dsim: Handle proper DSI host initialization > drm: bridge: samsung-dsim: Add atomic_check > drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset > drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts > drm: bridge: samsung-dsim: Add input_bus_flags > dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support > drm: bridge: samsung-dsim: Add i.MX8MM support > > .../bindings/display/exynos/exynos_dsim.txt | 1 + > MAINTAINERS | 9 + > drivers/gpu/drm/bridge/Kconfig | 12 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 1856 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1766 +--- > include/drm/bridge/samsung-dsim.h | 115 + > 8 files changed, 2108 insertions(+), 1653 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c > create mode 100644 include/drm/bridge/samsung-dsim.h Cheers Marcel
Re: [PATCH 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.
On 10/17/22 21:54, Zack Rusin wrote:
From: Maaz Mombasawala
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenence burden.
As part of this effort, refactor the res_ht hashtable used for resource
validation during execbuf execution to use linux/hashtable implementation.
This also refactors vmw_validation_context to use vmw_sw_context as the
container for the hashtable, whereas before it used a vmwgfx_open_hash
directly. This makes vmw_validation_context less generic, but there is
no functional change since res_ht is the only instance where validation
context used a hashtable in vmwgfx driver.
Why is a pointer to the vmw_sw_context added to the validation context,
rather than a pointer to the new hash table type itself? Seems like an
unnecessary indirection which adds a dependency on the sw context to the
validation context?
Signed-off-by: Maaz Mombasawala
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 24 --
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 55 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 26 +++---
5 files changed, 58 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 13b90273eb77..8d77e79bd904 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -830,6 +830,22 @@ static void vmw_write_driver_id(struct vmw_private *dev)
}
}
+static void vmw_sw_context_init(struct vmw_private *dev_priv)
+{
+ struct vmw_sw_context *sw_context = &dev_priv->ctx;
+
+ hash_init(sw_context->res_ht);
+}
+
+static void vmw_sw_context_fini(struct vmw_private *dev_priv)
+{
+ struct vmw_sw_context *sw_context = &dev_priv->ctx;
+
+ vfree(sw_context->cmd_bounce);
+ if (sw_context->staged_bindings)
+ vmw_binding_state_free(sw_context->staged_bindings);
+}
+
static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
{
int ret;
@@ -839,6 +855,8 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
u32 pci_id)
dev_priv->drm.dev_private = dev_priv;
+ vmw_sw_context_init(dev_priv);
+
mutex_init(&dev_priv->cmdbuf_mutex);
mutex_init(&dev_priv->binding_mutex);
spin_lock_init(&dev_priv->resource_lock);
@@ -1168,9 +1186,7 @@ static void vmw_driver_unload(struct drm_device *dev)
unregister_pm_notifier(&dev_priv->pm_nb);
- if (dev_priv->ctx.res_ht_initialized)
- vmwgfx_ht_remove(&dev_priv->ctx.res_ht);
- vfree(dev_priv->ctx.cmd_bounce);
+ vmw_sw_context_fini(dev_priv);
if (dev_priv->enable_fb) {
vmw_fb_off(dev_priv);
vmw_fb_close(dev_priv);
@@ -1198,8 +1214,6 @@ static void vmw_driver_unload(struct drm_device *dev)
vmw_irq_uninstall(&dev_priv->drm);
ttm_object_device_release(&dev_priv->tdev);
- if (dev_priv->ctx.staged_bindings)
- vmw_binding_state_free(dev_priv->ctx.staged_bindings);
for (i = vmw_res_context; i < vmw_res_max; ++i)
idr_destroy(&dev_priv->res_idr[i]);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 09e2d738aa87..d87aeedb78d0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
@@ -93,6 +94,7 @@
#define VMW_RES_STREAM ttm_driver_type2
#define VMW_RES_FENCE ttm_driver_type3
#define VMW_RES_SHADER ttm_driver_type4
+#define VMW_RES_HT_ORDER 12
#define MKSSTAT_CAPACITY_LOG2 5U
#define MKSSTAT_CAPACITY (1U << MKSSTAT_CAPACITY_LOG2)
@@ -425,8 +427,7 @@ struct vmw_ctx_validation_info;
* @ctx: The validation context
*/
struct vmw_sw_context{
- struct vmwgfx_open_hash res_ht;
- bool res_ht_initialized;
+ DECLARE_HASHTABLE(res_ht, VMW_RES_HT_ORDER);
bool kernel;
struct vmw_fpriv *fp;
struct drm_file *filp;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index f085dbd4736d..c943ab801ca7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0 OR MIT
/**
*
- * Copyright 2009 - 2015 VMware, Inc., Palo Alto, CA., USA
+ * Copyright 2009 - 2022 VMware, Inc., Palo Alto, CA., USA
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the
@@ -25,6 +25,7 @@
*
**/
#include
+#include
#include "vmwgfx_drv.h"
#include "vmw
Re: [PATCH v5 12/22] drm/connector: Add a function to lookup a TV mode by its name
Den 19.10.2022 10.48, skrev Maxime Ripard:
> On Tue, Oct 18, 2022 at 02:29:00PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 18.10.2022 11.33, skrev Maxime Ripard:
>>> On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
Den 13.10.2022 15.18, skrev Maxime Ripard:
> As part of the command line parsing rework coming in the next patches,
> we'll need to lookup drm_connector_tv_mode values by their name, already
> defined in drm_tv_mode_enum_list.
>
> In order to avoid any code duplication, let's do a function that will
> perform a lookup of a TV mode name and return its value.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_connector.c | 24
> include/drm/drm_connector.h | 2 ++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 820f4c730b38..30611c616435 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -991,6 +991,30 @@ static const struct drm_prop_enum_list
> drm_tv_mode_enum_list[] = {
> };
> DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
>
> +/**
> + * drm_get_tv_mode_from_name - Translates a TV mode name into its enum
> value
> + * @name: TV Mode name we want to convert
> + * @len: Length of @name
> + *
> + * Translates @name into an enum drm_connector_tv_mode.
> + *
> + * Returns: the enum value on success, a negative errno otherwise.
> + */
> +int drm_get_tv_mode_from_name(const char *name, size_t len)
Do we really need to pass in length here? item->name has to always be
NUL terminated otherwise things would break elsewhere, so it shouldn't
be necessary AFAICS.
>>>
>>> The only user so far is the command-line parsing code, and we might very
>>> well have an option after the tv_mode, something like
>>> 720x480i,tv_mode=NTSC,rotate=180
>>>
>>> In this case, we won't get a NULL-terminated name.
>>
>> My point is that item->name will always be NUL terminated so strcmp()
>> will never look past that.
>
> Right, but we don't have the guarantee that strlen(item->name) <
> strlen(name), and we could thus just access after the end of our name
>
Ok, using the length limiting str funtions is the safe thing to do, so
len needs to stay. But I don't get the 'strlen(item->name) == len'
check. strncmp() will stop when it reaches a NUL in either string so no
need for the length check?
Anyways:
Reviewed-by: Noralf Trønnes
Re: [PATCH] drm: Remove drm_mode_config::fb_base
On Wed, Oct 19, 2022 at 09:32:26AM +0200, Thomas Zimmermann wrote: > Am 18.10.22 um 17:52 schrieb Zack Rusin: > IIRC PSB hardware is only available in 32-bit systems. Dunno about deep details, but IIUC the Intel Tangier and Intel Annioedale are 64-bit SoCs that have Imagination + Intel IPs, the latter from this GMA5xx/GMA6xx family. -- With Best Regards, Andy Shevchenko
Re: [PATCH] drm: Remove drm_mode_config::fb_base
Am 19.10.22 um 13:08 schrieb andriy.shevche...@linux.intel.com: On Wed, Oct 19, 2022 at 09:32:26AM +0200, Thomas Zimmermann wrote: Am 18.10.22 um 17:52 schrieb Zack Rusin: IIRC PSB hardware is only available in 32-bit systems. Dunno about deep details, but IIUC the Intel Tangier and Intel Annioedale are 64-bit SoCs that have Imagination + Intel IPs, the latter from this GMA5xx/GMA6xx family. Ok :| -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test
[cc Javier]
Hi David,
On 10/19/22 04:32, David Gow wrote:
> The xrgb2101010 format conversion test (unlike for other formats) does
> an endianness conversion on the results. However, it always converts
> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
> writing to) more memory than in present in the result buffer. Instead,
> use the buffer size, divided by sizeof(u32).
>
> The issue could be reproduced with KASAN:
> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
> --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
> --kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
> drm_format_helper_test.*xrgb2101010
>
> Reported-by: Linux Kernel Functional Testing
> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for
> drm_fb_xrgb_to_xrgb2101010()")
> Signed-off-by: David Gow
Reviewed-by: Maíra Canal
> ---
>
> This is a fix for the issue reported here:
> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=k8p...@mail.gmail.com/
>
> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairaca...@riseup.net/
I believe this patch will go to the drm-misc-fixes tree, so I can rebase
the series (and address the format issues) as this patch hits mainline.
Best Regards,
- Maíra Canal
>
> Cheers,
> -- David
>
> ---
> drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 8d86c250c2ec..2191e57f2297 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct
> kunit *test)
> iosys_map_set_vaddr(&src, xrgb);
>
> drm_fb_xrgb_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb,
> ¶ms->clip);
> - buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
> + buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
> KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> }
>
[PATCH 0/2] Selftest fixes for 6.1
From: Tvrtko Ursulin Warning - not much tested, mainly bypassing trybot for quick turnaround. Tvrtko Ursulin (2): drm/i915/selftests: Fix waiting for threads to start drm/i915/selftests: Fix selftests for 6.1 kthread_stop semantics .../drm/i915/gem/selftests/i915_gem_context.c | 9 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 13 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +- drivers/gpu/drm/i915/i915_selftest.h | 14 ++ drivers/gpu/drm/i915/selftests/i915_request.c | 136 -- .../gpu/drm/i915/selftests/i915_selftest.c| 18 +++ 6 files changed, 140 insertions(+), 55 deletions(-) -- 2.34.1
[PATCH 1/2] drm/i915/selftests: Fix waiting for threads to start
From: Tvrtko Ursulin
Tests which want to make sure all threads have started have to do that
explicitly since one yield() can not guarantee it. Issue is that many
tests then proceed to call kthread_stop() which can therefore return even
before the thread has been started and will instead just return an error
status.
Add a simple macro helper which can wait on a bunch of threads to start
and use it. Also refactor some tests so the helper can be used.
Signed-off-by: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 10 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +-
drivers/gpu/drm/i915/i915_selftest.h | 12 ++
drivers/gpu/drm/i915/selftests/i915_request.c | 126 --
5 files changed, 111 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index c6ad67b90e8a..f5dc7ba2cdd7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -181,6 +181,7 @@ static int live_nop_switch(void *arg)
struct parallel_switch {
struct task_struct *tsk;
struct intel_context *ce[2];
+ bool running;
};
static int __live_parallel_switch1(void *data)
@@ -189,6 +190,7 @@ static int __live_parallel_switch1(void *data)
IGT_TIMEOUT(end_time);
unsigned long count;
+ WRITE_ONCE(arg->running, true);
count = 0;
do {
struct i915_request *rq = NULL;
@@ -233,6 +235,7 @@ static int __live_parallel_switchN(void *data)
unsigned long count;
int n;
+ WRITE_ONCE(arg->running, true);
count = 0;
do {
for (n = 0; n < ARRAY_SIZE(arg->ce); n++) {
@@ -370,7 +373,7 @@ static int live_parallel_switch(void *arg)
get_task_struct(data[n].tsk);
}
- yield(); /* start all threads before we kthread_stop() */
+ __igt_start_threads(data, count, tsk, running);
for (n = 0; n < count; n++) {
int status;
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 56b7d5b5fea0..07f572ee9923 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -3479,6 +3479,7 @@ struct preempt_smoke {
unsigned int ncontext;
struct rnd_state prng;
unsigned long count;
+ bool running;
};
static struct i915_gem_context *smoke_context(struct preempt_smoke *smoke)
@@ -3544,6 +3545,7 @@ static int smoke_crescendo_thread(void *arg)
IGT_TIMEOUT(end_time);
unsigned long count;
+ WRITE_ONCE(smoke->running, true);
count = 0;
do {
struct i915_gem_context *ctx = smoke_context(smoke);
@@ -3576,23 +3578,25 @@ static int smoke_crescendo(struct preempt_smoke *smoke,
unsigned int flags)
if (!arg)
return -ENOMEM;
+ memset(arg, 0, I915_NUM_ENGINES * sizeof(*arg));
+
for_each_engine(engine, smoke->gt, id) {
arg[id] = *smoke;
- arg[id].engine = engine;
if (!(flags & BATCH))
arg[id].batch = NULL;
arg[id].count = 0;
- tsk[id] = kthread_run(smoke_crescendo_thread, arg,
+ tsk[id] = kthread_run(smoke_crescendo_thread, &arg[id],
"igt/smoke:%d", id);
if (IS_ERR(tsk[id])) {
err = PTR_ERR(tsk[id]);
break;
}
+ arg[id].engine = engine;
get_task_struct(tsk[id]);
}
- yield(); /* start all threads before we kthread_stop() */
+ __igt_start_threads(arg, I915_NUM_ENGINES, engine, running);
count = 0;
for_each_engine(engine, smoke->gt, id) {
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 7f3bb1d34dfb..ea1542e6b157 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -870,6 +870,7 @@ struct active_engine {
struct intel_engine_cs *engine;
unsigned long resets;
unsigned int flags;
+ bool running;
};
#define TEST_ACTIVEBIT(0)
@@ -910,6 +911,8 @@ static int active_engine(void *data)
unsigned long count;
int err = 0;
+ WRITE_ONCE(arg->running, true);
+
for (count = 0; count < ARRAY_SIZE(ce); count++) {
ce[count] = intel_context_create(engine);
if (IS_ERR(ce[count])) {
@@ -1048,7 +1051,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
get_task_struct(tsk);
}
- yield(); /* start all thre
[PATCH 2/2] drm/i915/selftests: Fix selftests for 6.1 kthread_stop semantics
From: Tvrtko Ursulin
Since a7c01fa93aeb ("signal: break out of wait loops on kthread_stop()")
kthread_stop will mark a pending signal which breaks __igt_timeout when
used from selftests threads. Result of this is overly short test execution
time which renders some tests useless.
Add a new __igt_thread_timeout helper and use it from selftest threads.
Signed-off-by: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 3 ++-
drivers/gpu/drm/i915/i915_selftest.h | 2 ++
drivers/gpu/drm/i915/selftests/i915_request.c | 10 +-
drivers/gpu/drm/i915/selftests/i915_selftest.c | 18 ++
5 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index f5dc7ba2cdd7..1172d0d6e07a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -221,7 +221,7 @@ static int __live_parallel_switch1(void *data)
return err;
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
return 0;
@@ -262,7 +262,7 @@ static int __live_parallel_switchN(void *data)
}
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
i915_request_put(rq);
pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 07f572ee9923..e63c0ac3d861 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -3558,7 +3558,8 @@ static int smoke_crescendo_thread(void *arg)
return err;
count++;
- } while (count < smoke->ncontext && !__igt_timeout(end_time, NULL));
+ } while (count < smoke->ncontext &&
+!__igt_thread_timeout(end_time, NULL));
smoke->count = count;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index e4fcb71fb0ee..a233f167ec44 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -131,6 +131,8 @@ static inline int i915_perf_selftests(struct pci_dev *pdev)
{ return 0; }
__printf(2, 3)
bool __igt_timeout(unsigned long timeout, const char *fmt, ...);
+__printf(2, 3)
+bool __igt_thread_timeout(unsigned long timeout, const char *fmt, ...);
#define igt_timeout(t, fmt, ...) \
__igt_timeout((t), KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 9c313e9a771b..5c576ee94e5d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -1467,7 +1467,7 @@ static int __live_parallel_engine1(void *arg)
break;
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
intel_engine_pm_put(engine);
pr_info("%s: %lu request + sync\n", engine->name, count);
@@ -1496,7 +1496,7 @@ static int __live_parallel_engineN(void *arg)
i915_request_add(rq);
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
intel_engine_pm_put(engine);
pr_info("%s: %lu requests\n", engine->name, count);
@@ -2978,7 +2978,7 @@ static int p_sync0(void *arg)
break;
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
if (busy) {
ktime_t now;
@@ -3053,7 +3053,7 @@ static int p_sync1(void *arg)
break;
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
i915_request_put(prev);
if (busy) {
@@ -3118,7 +3118,7 @@ static int p_many(void *arg)
i915_request_add(rq);
count++;
- } while (!__igt_timeout(end_time, NULL));
+ } while (!__igt_thread_timeout(end_time, NULL));
if (busy) {
ktime_t now;
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..afba2c3db1a9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -397,6 +397,24 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
return true;
Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()
On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
> wrote:
> >
> > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
> > > to reference count the device returned by acpi_get_pci_dev() as
> > > expected by its callers which in some cases may cause device objects
> > > to be dropped prematurely.
> > >
> > > Add the missing get_device() to acpi_get_pci_dev().
> > >
> > > Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> >
> > FYI this (and the rtc-cmos regression discussed in
> > https://lore.kernel.org/linux-acpi/5887691.lOV4Wx5bFT@kreacher/)
> > took down the entire Intel gfx CI.
>
> Sorry for the disturbance.
>
> > I've applied both fixes into our fixup branch and things are looking much
> > healthier now.
>
> Thanks for letting me know.
>
> I've just added the $subject patch to my linux-next branch as an
> urgent fix and the other one has been applied to the RTC tree.
>
> > This one caused i915 selftests to eat a lot of POISON_FREE
> > in the CI. While bisecting it locally I didn't have
> > poisoning enabled so I got refcount_t undeflows instead.
>
> Unfortunately, making no mistakes is generally hard to offer.
>
> If catching things like this early is better, what about pulling my
> bleeding-edge branch, where all of my changes are staged before going
> into linux-next, into the CI?
Pretty sure we don't have the resources to become the CI for
everyone. So testing random trees is not really possible. And
the alternative of pulling random trees into drm-tip is probably
a not a popular idea either. We used to pull in the sound tree
since it's pretty closely tied to graphics, but I think we
stopped even that because it eneded up pulling the whole of
-rc1 in at random points in time when we were't expecting it.
Ideally each subsystem would have its own CI, or there should
be some kernel wide thing. But I suppose the progress towards
something like that is glacial.
That said, we do test linux-next to some degree. And looks like
at least one of these could have been caught a bit earlier through
that. Unfortunately no one is really keeping an eye on that so
things tend to slip through. Probably need to figure out something
to make better use of that.
>
> > https://intel-gfx-ci.01.org/tree/drm-tip/index.html has a lot
> > of colorful boxes to click if you're interested in any of the
> > logs. The fixes are included in the CI_DRM_12259 build. Earlier
> > builds were broken.
>
> Thanks!
--
Ville Syrjälä
Intel
Re: [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers
Hi,
please see my review below.
Am 07.10.22 um 14:49 schrieb Thierry Reding:
From: Thierry Reding
Simple framebuffers can be set up in system memory, which cannot be
requested and/or I/O remapped using the I/O resource helpers. Add a
separate code path that obtains system memory framebuffers from the
reserved memory region referenced in the memory-region property.
v2: make screen base a struct iosys_map to avoid sparse warnings
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tiny/simpledrm.c | 177 ---
1 file changed, 141 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 18489779fb8a..cf36f67d22e4 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
#include
@@ -207,7 +208,9 @@ struct simpledrm_device {
unsigned int pitch;
/* memory management */
- void __iomem *screen_base;
+ struct iosys_map screen_base;
+ phys_addr_t sysmem_start;
+ size_t sysmem_size;
Please store a pointer to the struct reserved_mem here. If set, we use
it; if NULL, we use the memory region as before.
/* modesetting */
uint32_t formats[8];
@@ -441,6 +444,106 @@ static int simpledrm_device_init_regulators(struct
simpledrm_device *sdev)
}
#endif
+/*
+ * Memory management
+ */
+
+static int simpledrm_device_init_mm_sysmem(struct simpledrm_device *sdev,
phys_addr_t start,
+ size_t size)
+{
+ struct drm_device *dev = &sdev->dev;
+ phys_addr_t end = start + size - 1;
+ void *screen_base;
+
+ drm_info(dev, "using system memory framebuffer at [%pa-%pa]\n", &start,
&end);
+
+ screen_base = devm_memremap(dev->dev, start, size, MEMREMAP_WC);
+ if (!screen_base)
+ return -ENOMEM;
+
+ iosys_map_set_vaddr(&sdev->screen_base, screen_base);
+
+ return 0;
+}
+
+static int simpledrm_device_init_mm_io(struct simpledrm_device *sdev,
phys_addr_t start,
+ size_t size)
+{
+ struct drm_device *dev = &sdev->dev;
+ phys_addr_t end = start + size - 1;
+ void __iomem *screen_base;
+ struct resource *mem;
+
+ drm_info(dev, "using I/O memory framebuffer at [%pa-%pa]\n", &start,
&end);
+
+ mem = devm_request_mem_region(dev->dev, start, size,
sdev->dev.driver->name);
+ if (!mem) {
+ /*
+* We cannot make this fatal. Sometimes this comes from magic
+* spaces our resource handlers simply don't know about. Use
+* the I/O-memory resource as-is and try to map that instead.
+*/
+ drm_warn(dev, "could not acquire memory region [%pa-%pa]\n",
&start, &end);
+ } else {
+ size = resource_size(mem);
+ start = mem->start;
+ }
+
+ screen_base = devm_ioremap_wc(dev->dev, start, size);
+ if (!screen_base)
+ return -ENOMEM;
+
+ iosys_map_set_vaddr_iomem(&sdev->screen_base, screen_base);
+
+ return 0;
+}
+
+static void simpledrm_device_exit_mm(void *data)
+{
+ struct simpledrm_device *sdev = data;
+ struct drm_device *dev = &sdev->dev;
+
+ of_reserved_mem_device_release(dev->dev);
+}
+
+static int simpledrm_device_init_mm(struct simpledrm_device *sdev)
+{
No such _init_mm() helper please. Simply do everything in the _create()
function.
+ int (*init)(struct simpledrm_device *sdev, phys_addr_t start, size_t
size);
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = to_platform_device(dev->dev);
+ phys_addr_t start, end;
+ size_t size;
+ int ret;
+
+ ret = of_reserved_mem_device_init_by_idx(dev->dev, dev->dev->of_node,
0);
Instead of doing our own lookup of the memory node, I'd prefer to keep
this function. If we encasulate it, it's better than reinventing the
wheel within this driver.
A number of helpers look-up the various properties from the device tree.
They are at [1] and below. We should add a new helper that reads the
memory node via of_reserved_mem_device_init_by_idx(). Here's some
example code
struct reserved_mem *
simplefb_get_memory_of(drm_device dev, of_node node)
{
sdev = simpledrm_device_of_dev(dev)
ret = of_reserved_mem_device_init_by_idx()
if (ret)
return ERR_PTR()
ret = devm_add_action_or_reset(dev->dev,
simpledrm_device_exit_mm, sdev)
if (ret)
return ERR_PTR()
return sdev->rmem;
}
That wraps the rmem instance quite nicely and is similar to the rest of
the code. You can call this function within the else branch at [2].
Later in _create() where we map the I/O memory, branch depending on the
returned value of rmem.
if (rmem) {
de
Re: Issue on unmap_grant_pages before releasing dmabuf
On 19.10.22 12:43, Oleksii Moisieiev wrote: Greetings. I need your advise about the problem I'm facing right now: I'm working on the new type of dmabuf export implementation. This is going to be new ioctl to the gntdev and it's purpose is to use external buffer, provided by file descriptor as the backing storage during export to grant refs. Few words about the functionality I'm working on right now: My setup is based on IMX8QM (please see PS below if you need configuration details) When using dma-buf exporter to create dma-buf with backing storage and map it to the grant refs, provided from the domain, we've met a problem, that several HW (i.MX8 gpu in our case) do not support external buffer and requires backing storage to be created using it's native tools (eglCreateImageKHR returns EGL_NO_IMAGE_KHR for buffers, which were not created using gbm_bo_create). That's why new ioctls were added to be able to pass existing dma-buffer fd as input parameter and use it as backing storage to export to refs. Kernel version on IMX8QM board is 5.10.72 and itworks fine on this kernel version. New ioctls source code can be found here: https://github.com/oleksiimoisieiev/linux/tree/gntdev_map_buf_upstr_for-linus-6.1_2 Now regarding the problem I've met when rebased those code on master: On my test stand I use DRM_IOCTL_MODE_CREATE_DUMB/DRM_IOCTL_MODE_DESTROY_DUMB ioctls to allocate buffer and I'm observing the following backtrace on DRM_IOCTL_MODE_DESTROY_DUMB: Unable to handle kernel paging request at virtual address 00038798 Mem abort info: ESR = 0x9605 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x0005 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=6df98000 [00038798] pgd=080064f4f003, p4d=080064f4f003, pud= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: xen_pciback overlay crct10dif_ce ip_tables x_tables ipv6 PU: 0 PID: 34 Comm: kworker/0:1 Not tainted 6.0.0 #85 Hardware name: linux,dummy-virt (DT) Workqueue: events virtio_gpu_dequeue_ctrl_func pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : check_move_unevictable_folios+0xb8/0x4d0 lr : check_move_unevictable_folios+0xb4/0x4d0 sp : 881a3ad0 x29: 881a3ad0 x28: 03856ac98800 x27: x26: de7b168ee9d8 x25: 03856ae26008 x24: x23: de7b1758d6c0 x22: 0001 x21: 881a3b68 x20: 0001 x19: fc0e15935040 x18: x17: 250a68e3d000 x16: 0012 x15: 8000881a38d7 x14: x13: de7b175a3150 x12: 2c55 x11: 0ec7 x10: de7b176113f8 x9 : de7b175a3150 x8 : 00014ec7 x7 : de7b175fb150 x6 : 881a3b70 x5 : 0001 x4 : x3 : 03856ac98850 x2 : x1 : x0 : 00038700 Call trace: check_move_unevictable_folios+0xb8/0x4d0 check_move_unevictable_pages+0x8c/0x110 drm_gem_put_pages+0x118/0x198 drm_gem_shmem_put_pages_locked+0x4c/0x70 drm_gem_shmem_unpin+0x30/0x50 virtio_gpu_cleanup_object+0x84/0x130 virtio_gpu_cmd_unref_cb+0x18/0x2c virtio_gpu_dequeue_ctrl_func+0x124/0x290 process_one_work+0x1d0/0x320 worker_thread+0x14c/0x444 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 97fc3fe1 aa1303e0 94003ac7 b480 (f9404c00) ---[ end trace ]--- After some investigation I think I've found the cause of the problem: This is the functionality, added in commit 3f9f1c67572f5e5e6dc84216d48d1480f3c4fcf6 which introduces safe mechanism to unmap grant pages which is waiting until page_count(page) = 1 before doing unmap. The problem is that DRM_IOCTL_MODE_CREATE_DUMB creates buffer where page_count(page) = 2. On my QEMU test stand I'm using Xen 4.16 (aarch64) with debian based Dom0 + DomU on the latest kernels. I've created some apps for testing: The first one is to allocate grant refs on DomU: https://github.com/oleksiimoisieiev/linux/tree/gntdev_map_buf_upstr_for-linus-6.1_2 The name is test.ko and it can be built using command: cd ./test; make NOTE: makefile expects kernel build to be present on ../../test-build directory. It should be run on DomU using command: insmod test.ko; echo "create" > /sys/kernel/etx_sysfs/etx_value Result will be the following: [ 126.104903] test: loading out-of-tree module taints kernel. [ 126.150586] Sysfs - Write!!! [ 126.150773] create [ 126.150773] [ 126.150888] Hello, World! [ 126.151203] Hello, World! [ 126.151324] gref 301 [ 126.151376] addr 0883d000 [ 126.151431] gref 302 [ 126.151454] addr 0883e000 [ 126.151478] gref 303 [ 126.151497] addr 0883f000 [ 126.151525] gref 304 [ 126.151546] addr 0884 [ 126.151573] gref 305 [ 126.151593] addr 08841000 The second i
Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi
Hi Laurent On Sun, Oct 16, 2022 at 3:33 AM Laurent Pinchart wrote: > > Hello, > > On Fri, Oct 14, 2022 at 03:08:49PM +0100, Dave Stevenson wrote: > > On Thu, 13 Oct 2022 at 13:58, Francesco Dolcini wrote: > > > On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote: > > > > From: Max Krummenacher > > > > > > > > The property is used to set the enum bus_format and infer the bpc > > > > for a panel defined by 'panel-dpi'. > > > > This specifies how the panel is connected to the display interface. > > > > > > > > Signed-off-by: Max Krummenacher > > > > > > > > > > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > index dae0676b5c6e..52f5db03b6a8 100644 > > > > --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > @@ -26,7 +26,28 @@ properties: > > > >height-mm: true > > > >label: true > > > >panel-timing: true > > > > - port: true > > > > + > > > > + port: > > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > > +description: > > > > + Input port node, receives the panel data. > > > > + > > > > +properties: > > > > + endpoint: > > > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > > > > + > > > > +properties: > > > > + bus-format: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +minimum: 0x1001 > > > > +maximum: 0x1fff > > > > +description: | > > > > + Describes how the display panel is connected to the > > > > display interface. > > > > + Valid values are defined in > > > > . > > > > + The mapping between the color/significance of the panel > > > > lines to the > > > > + parallel data lines are defined in: > > > > + > > > > https://www.kernel.org/doc/html/v5.17/userspace-api/media/v4l/subdev-formats.html#packed-rgb-formats > > > > + > > > > > > Last month I had the chance to talk in person about this topic with > > > Dave, Marek and Max in Dublin. > > > > > > My understanding is that this change is addressing a general need, Dave > > > confirmed me they have a downstream patch for raspberrypi [1]. > > > > > > From what I could tell the only concern is about the actual encoding of > > > this `bus-format` property. > > > > > > I am personally convinced that a simple enum is the way to go, I think > > > that Marek proposal is adding complexity and not flexibility (from my > > > understanding Dave is on the same page, just correct me if I > > > misunderstood you). > > > > Yes I agree with you here. > > > > This binding is for the panel, and currently the only path to pass the > > panel mode to the DPI transmitter is one or more MEDIA_BUS_FMT_* enums > > in struct drm_display_info *bus_formats. > > > > Looking at Marek's comment over DSI and data-lanes, yes both source > > and sink could advertise a data-lanes property to cover the condition > > where they aren't wired up in a 1:1 fashion. Reality is that most > > drivers don't support reordering the lanes - looking at the bindings, > > only one (msm) documents the use of data-lanes on the host side. > > rcar_mipi_dsi looks at the number of lanes specified only, and then > > checks that the number requested by the device is <= the number > > configured. > > > > As I see it, the comparison here is that this "bus-format" property is > > the equivalent of the data-lanes on the sink, and is the desired > > number of lanes value passed from sink to source (one integer, not a > > mapping). > > If the source can reorder the lanes, then that is a property of the > > source. This binding is for the sink, and so isn't a reasonable > > comparison. It also doesn't have to be called "bus-format" on the > > source, and can take a totally different form. > > I'll admit that I know data-lane configuration more from CSI2, but > > within V4L2 it is the node that can support reordering that should > > have the lanes in a non-incrementing order, and that is normally the > > SoC rather than the sensor. The same would seem to apply here - it's > > the SoC that can remap the signals, not the panel. > > > > It could be argued that for DPI the panel should only advertise the > > panel's bit depth for each channel, not the padding. The panel is > > generic and could handle any wiring/padding options, and it isn't > > necessarily a simple 16/18/24/32 bit bus representation, just a > > collection of N wires. > > Padding and wiring is a function of the DPI transmitter / SoC, or > > potentially an interconnect node between the two. > > Sooo... I'm not sure where to start :-) > > I think the trouble when describing the connection between a source and > a sink in DT is that none of the source or sink is an ideal place to > describe properties of the connect
Re: [PATCH v3 1/8] drm/amd/display: Introduce KUnit tests for fixed31_32 library
Em sex., 30 de set. de 2022 às 11:14, Harry Wentland escreveu: > > > > On 9/12/22 11:59, Maíra Canal wrote: > > From: Tales Aparecida > > > > The fixed31_32 library performs a lot of the mathematical operations > > involving fixed-point arithmetic and the conversion of integers to > > fixed-point representation. > > > > This unit tests intend to assure the proper functioning of the basic > > mathematical operations of fixed-point arithmetic, such as > > multiplication, conversion from fractional to fixed-point number, > > and more. Use kunit_tool to run: > > > > $ ./tools/testing/kunit/kunit.py run --arch=x86_64 \ > > --kunitconfig=drivers/gpu/drm/amd/display/tests/ > > > > Reviewed-by: David Gow > > Signed-off-by: Tales Aparecida > > Signed-off-by: Maíra Canal > > --- > > drivers/gpu/drm/amd/display/Kconfig | 13 + > > drivers/gpu/drm/amd/display/Makefile | 2 +- > > .../gpu/drm/amd/display/tests/.kunitconfig| 6 + > > drivers/gpu/drm/amd/display/tests/Makefile| 12 + > > .../display/tests/dc/basics/fixpt31_32_test.c | 232 ++ > > 5 files changed, 264 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/amd/display/tests/.kunitconfig > > create mode 100644 drivers/gpu/drm/amd/display/tests/Makefile > > create mode 100644 > > drivers/gpu/drm/amd/display/tests/dc/basics/fixpt31_32_test.c > > > > diff --git a/drivers/gpu/drm/amd/display/Kconfig > > b/drivers/gpu/drm/amd/display/Kconfig > > index 96cbc87f7b6b..cc44cfe88607 100644 > > --- a/drivers/gpu/drm/amd/display/Kconfig > > +++ b/drivers/gpu/drm/amd/display/Kconfig > > @@ -55,4 +55,17 @@ config DRM_AMD_SECURE_DISPLAY > > Cooperate with specific DMCU FW. > > > > > > +config AMD_DC_BASICS_KUNIT_TEST > > I would prefer if we kept the same prefix as for other > configs in the file: "DRM_AMD_DC". Maybe name all the > KUNIT configs here "DRM_AMD_DC_KUNIT_XYZ". > > > > + bool "Enable KUnit tests for the 'basics' sub-component of DAL" if > > !KUNIT_ALL_TESTS > > + depends on DRM_AMD_DC && KUNIT > > + default KUNIT_ALL_TESTS > > + help > > + Enables unit tests for the Display Core. Only useful for > > kernel > > + devs running KUnit. > > + > > + For more information on KUnit and unit tests in general > > please refer to > > + the KUnit documentation in Documentation/dev-tools/kunit/. > > + > > + If unsure, say N. > > + > > endmenu > > diff --git a/drivers/gpu/drm/amd/display/Makefile > > b/drivers/gpu/drm/amd/display/Makefile > > index 2633de77de5e..0f329aab13f0 100644 > > --- a/drivers/gpu/drm/amd/display/Makefile > > +++ b/drivers/gpu/drm/amd/display/Makefile > > @@ -43,7 +43,7 @@ endif > > #TODO: remove when Timing Sync feature is complete > > subdir-ccflags-y += -DBUILD_FEATURE_TIMING_SYNC=0 > > > > -DAL_LIBS = amdgpu_dm dc modules/freesync modules/color > > modules/info_packet modules/power dmub/src > > +DAL_LIBS = amdgpu_dm dc modules/freesync modules/color > > modules/info_packet modules/power dmub/src tests > > Can we put these tests into a 'kunit' directory instead of 'tests'? > We use the codebase on other platforms and 'tests' might be > confusing to some AMD-internal developers, whereas 'kunit' is > explicit and will ensure people understand where these are coming > from and how to use them. > > Other than the CONFIG and directory naming these tests look really > nice. Thanks for your contribution. > > Harry > Hi, Harry. Thank you for your feedback and comments. We'll change the directory and config entries' names in a new version. Magali > > > > ifdef CONFIG_DRM_AMD_DC_HDCP > > DAL_LIBS += modules/hdcp > > diff --git a/drivers/gpu/drm/amd/display/tests/.kunitconfig > > b/drivers/gpu/drm/amd/display/tests/.kunitconfig > > new file mode 100644 > > index ..60f2ff8158f5 > > --- /dev/null > > +++ b/drivers/gpu/drm/amd/display/tests/.kunitconfig > > @@ -0,0 +1,6 @@ > > +CONFIG_KUNIT=y > > +CONFIG_PCI=y > > +CONFIG_DRM=y > > +CONFIG_DRM_AMDGPU=y > > +CONFIG_DRM_AMD_DC=y > > +CONFIG_AMD_DC_BASICS_KUNIT_TEST=y > > \ No newline at end of file > > diff --git a/drivers/gpu/drm/amd/display/tests/Makefile > > b/drivers/gpu/drm/amd/display/tests/Makefile > > new file mode 100644 > > index ..ef16497318e8 > > --- /dev/null > > +++ b/drivers/gpu/drm/amd/display/tests/Makefile > > @@ -0,0 +1,12 @@ > > +# SPDX-License-Identifier: MIT > > +# > > +# Makefile for the KUnit Tests for DC > > +# > > + > > +ifdef CONFIG_AMD_DC_BASICS_KUNIT_TEST > > + DC_TESTS += dc/basics/fixpt31_32_test.o > > +endif > > + > > +AMD_DAL_DC_TESTS = $(addprefix $(AMDDALPATH)/tests/,$(DC_TESTS)) > > + > > +AMD_DISPLAY_FILES += $(AMD_DAL_DC_TESTS) > > diff --git a/drivers/gpu/drm/amd/display/tests/dc/basics/fixpt31_32_test.c > > b/drivers/gpu/drm/amd/display/tests/dc/basics/fixpt31_32_test.c > > new file mode 100644 > > index ..2fc489203499 > > --- /dev/null > > +++
Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()
On Wed, 19 Oct 2022, Ville Syrjälä wrote: > On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote: >> If catching things like this early is better, what about pulling my >> bleeding-edge branch, where all of my changes are staged before going >> into linux-next, into the CI? > > Pretty sure we don't have the resources to become the CI for > everyone. So testing random trees is not really possible. And > the alternative of pulling random trees into drm-tip is probably > a not a popular idea either. We used to pull in the sound tree > since it's pretty closely tied to graphics, but I think we > stopped even that because it eneded up pulling the whole of > -rc1 in at random points in time when we were't expecting it. Basically, we only pull branches to drm-tip that are managed using our tools and our development model and under our control. It was too much trouble dealing with conflicts, Linus' master being pulled in at random points (like in the middle of the merge window), and stuff like that, with the external trees. > Ideally each subsystem would have its own CI, or there should > be some kernel wide thing. But I suppose the progress towards > something like that is glacial. > > That said, we do test linux-next to some degree. And looks like > at least one of these could have been caught a bit earlier through > that. Unfortunately no one is really keeping an eye on that so > things tend to slip through. Probably need to figure out something > to make better use of that. Yeah, we need to pay more attention to linux-next test results, as well as Linus' master during the merge window. It's not necessarily easy with the volatility of linux-next, you could easily have very broken runs followed by good ones, but the low hanging fruit is raising more flags and being louder about it earlier when everything's busted for several days in linux-next or Linus' master. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[PATCH] video: fix repeated words in comments
Delete the redundant word 'the'.
Signed-off-by: Jilin Yuan
---
drivers/video/fbdev/sis/sis_accel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/sis_accel.c
b/drivers/video/fbdev/sis/sis_accel.c
index 1914ab5a5a91..5850e4325f07 100644
--- a/drivers/video/fbdev/sis/sis_accel.c
+++ b/drivers/video/fbdev/sis/sis_accel.c
@@ -202,7 +202,7 @@ SiS310SubsequentScreenToScreenCopy(struct sis_video_info
*ivideo, int src_x, int
* and destination blitting areas overlap and
* adapt the bitmap addresses synchronously
* if the coordinates exceed the valid range.
-* The the areas do not overlap, we do our
+* The areas do not overlap, we do our
* normal check.
*/
if((mymax - mymin) < height) {
--
2.36.1
Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()
On Wed, Oct 19, 2022 at 2:22 PM Ville Syrjälä
wrote:
>
> On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > > >
> > > > Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
> > > > to reference count the device returned by acpi_get_pci_dev() as
> > > > expected by its callers which in some cases may cause device objects
> > > > to be dropped prematurely.
> > > >
> > > > Add the missing get_device() to acpi_get_pci_dev().
> > > >
> > > > Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> > >
> > > FYI this (and the rtc-cmos regression discussed in
> > > https://lore.kernel.org/linux-acpi/5887691.lOV4Wx5bFT@kreacher/)
> > > took down the entire Intel gfx CI.
> >
> > Sorry for the disturbance.
> >
> > > I've applied both fixes into our fixup branch and things are looking much
> > > healthier now.
> >
> > Thanks for letting me know.
> >
> > I've just added the $subject patch to my linux-next branch as an
> > urgent fix and the other one has been applied to the RTC tree.
> >
> > > This one caused i915 selftests to eat a lot of POISON_FREE
> > > in the CI. While bisecting it locally I didn't have
> > > poisoning enabled so I got refcount_t undeflows instead.
> >
> > Unfortunately, making no mistakes is generally hard to offer.
> >
> > If catching things like this early is better, what about pulling my
> > bleeding-edge branch, where all of my changes are staged before going
> > into linux-next, into the CI?
>
> Pretty sure we don't have the resources to become the CI for
> everyone. So testing random trees is not really possible. And
> the alternative of pulling random trees into drm-tip is probably
> a not a popular idea either. We used to pull in the sound tree
> since it's pretty closely tied to graphics, but I think we
> stopped even that because it eneded up pulling the whole of
> -rc1 in at random points in time when we were't expecting it.
I see.
> Ideally each subsystem would have its own CI, or there should
> be some kernel wide thing. But I suppose the progress towards
> something like that is glacial.
Well, I definitely cannot afford a dedicated CI just for my tree and I
haven't got any useful information from KernlCI yet (even though hey
pull and test my linux-next branch on a regular basis).
KernelCI seems to be focusing on different set of hardware, so to speak.
> That said, we do test linux-next to some degree. And looks like
> at least one of these could have been caught a bit earlier through
> that. Unfortunately no one is really keeping an eye on that so
> things tend to slip through. Probably need to figure out something
> to make better use of that.
I think it could also be possible to contribute to KernelCI to get
more useful x86 coverage from it.
[PATCH] agp/via: fix repeated words in comments
Delete the redundant word 'as'.
Signed-off-by: Jilin Yuan
---
drivers/char/agp/via-agp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/agp/via-agp.c b/drivers/char/agp/via-agp.c
index b2f484f527fb..2a4befd1c438 100644
--- a/drivers/char/agp/via-agp.c
+++ b/drivers/char/agp/via-agp.c
@@ -398,7 +398,7 @@ static struct agp_device_ids via_agp_device_ids[] =
* by 3D driver which wasn't available for the VT3336 and VT3364
* generation until now. Unfortunately, by testing, VT3364 works
* but VT3336 doesn't. - explanation from via, just leave this as
-* as a placeholder to avoid future patches adding it back in.
+* a placeholder to avoid future patches adding it back in.
*/
#if 0
{
--
2.36.1
[PATCH] Make xilinxfb_release() return void
The function xilinxfb_release() returns zero unconditionally. Make it
return void. There is no semantic change, the only effect is that it
becomes obvious that the driver's .remove() callback always returns zero.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König
---
drivers/video/fbdev/xilinxfb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
index 438e2c78142f..1ac83900a21c 100644
--- a/drivers/video/fbdev/xilinxfb.c
+++ b/drivers/video/fbdev/xilinxfb.c
@@ -376,7 +376,7 @@ static int xilinxfb_assign(struct platform_device *pdev,
return rc;
}
-static int xilinxfb_release(struct device *dev)
+static void xilinxfb_release(struct device *dev)
{
struct xilinxfb_drvdata *drvdata = dev_get_drvdata(dev);
@@ -402,8 +402,6 @@ static int xilinxfb_release(struct device *dev)
if (!(drvdata->flags & BUS_ACCESS_FLAG))
dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
#endif
-
- return 0;
}
/* -
@@ -480,7 +478,9 @@ static int xilinxfb_of_probe(struct platform_device *pdev)
static int xilinxfb_of_remove(struct platform_device *op)
{
- return xilinxfb_release(&op->dev);
+ xilinxfb_release(&op->dev);
+
+ return 0;
}
/* Match table for of_platform binding */
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.37.2
Re: [PATCH -next] drm/amd/display: make dcn32_mmhubbub_funcs static
On 2022-10-19 02:31, ruanjinjie wrote:
> The symbol is not used outside of the file, so mark it static.
>
> Fixes the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mmhubbub.c:214:28:
> warning: symbol 'dcn32_mmhubbub_funcs' was
> not declared. Should it be static?
>
> Signed-off-by: ruanjinjie
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
> index 41b0baf8e183..c3b089ba511a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
> @@ -211,7 +211,7 @@ static void mmhubbub32_config_mcif_arb(struct mcif_wb
> *mcif_wb,
> REG_UPDATE(MCIF_WB_ARBITRATION_CONTROL,
> MCIF_WB_CLIENT_ARBITRATION_SLICE, params->arbitration_slice);
> }
>
> -const struct mcif_wb_funcs dcn32_mmhubbub_funcs = {
> +static const struct mcif_wb_funcs dcn32_mmhubbub_funcs = {
> .warmup_mcif= mmhubbub32_warmup_mcif,
> .enable_mcif= mmhubbub2_enable_mcif,
> .disable_mcif = mmhubbub2_disable_mcif,
Re: [PATCH -next] drm/amd/display: make dcn32_mpc_funcs static
On 2022-10-19 02:23, ruanjinjie wrote:
> The symbol is not used outside of the file, so mark it static.
>
> Fixes the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mpc.c:985:24: warning:
> symbol 'dcn32_mpc_funcs' was not declared. Should it be static?
>
> Signed-off-by: ruanjinjie
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
> index 4edd0655965b..206a5ddbaf6d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
> @@ -982,7 +982,7 @@ static bool mpc32_program_3dlut(
> return true;
> }
>
> -const struct mpc_funcs dcn32_mpc_funcs = {
> +static const struct mpc_funcs dcn32_mpc_funcs = {
> .read_mpcc_state = mpc1_read_mpcc_state,
> .insert_plane = mpc1_insert_plane,
> .remove_mpcc = mpc1_remove_mpcc,
Re: 答复: [PATCH] drm/amdkfd: use vma_lookup() instead of find_vma()
Am 2022-10-17 um 20:47 schrieb tomorrow Wang (王德明):
Hi,
The function vma_lookup show below. Vma valid check is included in it. Or,
What other questions do you have?
My question is, why did you leave the find_vma call in
svm_range_is_valid unchanged? I don't see a technical reason, but maybe
I'm missing something. If there is a reason, please explain. If there is
no reason, please fix that place as well for consistency.
Thanks,
Felix
static inline
struct vm_area_struct *vma_lookup(struct mm_struct *mm, unsigned long addr)
{
struct vm_area_struct *vma = find_vma(mm, addr);
if (vma && addr < vma->vm_start)
vma = NULL;
return vma;
}
from: Felix Kuehling
time: 2022年10月18日 3:35
to: tomorrow Wang (王德明) ;
airl...@gmail.com; dan...@ffwll.ch; alexander.deuc...@amd.com;
christian.koe...@amd.com; xinhui@amd.com
linux-ker...@vger.kernel.org
sub: Re: [PATCH] drm/amdkfd: use vma_lookup() instead of find_vma()
On 2022-10-06 22:48, Deming Wang wrote:
Using vma_lookup() verifies the start address is contained in the
found vma. This results in easier to read the code.
Thank you for the patches. This and your other patch look good to me.
However, you missed one use of find_vma in svm_range_is_valid. Is that an
oversight or is there a reason why we need to use find_vma there?
If you're going to respin it, you may also squash the two patches into one.
Thanks,
Felix
Signed-off-by: Deming Wang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 64fdf63093a0..cabcc2ca3c23 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1586,8 +1586,8 @@ static int svm_range_validate_and_map(struct
mm_struct *mm,
unsigned long npages;
bool readonly;
- vma = find_vma(mm, addr);
- if (!vma || addr < vma->vm_start) {
+ vma = vma_lookup(mm, addr);
+ if (!vma) {
r = -EFAULT;
goto unreserve_out;
}
@@ -2542,8 +2542,8 @@ svm_range_get_range_boundaries(struct
kfd_process *p, int64_t addr,
struct interval_tree_node *node;
unsigned long start_limit, end_limit;
- vma = find_vma(p->mm, addr << PAGE_SHIFT);
- if (!vma || (addr << PAGE_SHIFT) < vma->vm_start) {
+ vma = vma_lookup(p->mm, addr << PAGE_SHIFT);
+ if (!vma) {
pr_debug("VMA does not exist in address [0x%llx]\n", addr);
return -EFAULT;
}
@@ -2871,8 +2871,8 @@ svm_range_restore_pages(struct amdgpu_device
*adev, unsigned int pasid,
/* __do_munmap removed VMA, return success as we are handling stale
* retry fault.
*/
- vma = find_vma(mm, addr << PAGE_SHIFT);
- if (!vma || (addr << PAGE_SHIFT) < vma->vm_start) {
+ vma = vma_lookup(mm, addr << PAGE_SHIFT);
+ if (!vma) {
pr_debug("address 0x%llx VMA is removed\n", addr);
r = 0;
goto out_unlock_range;
Re: [PATCH v4 09/17] drm/i915/vm_bind: Add out fence support
On 19/10/2022 03:43, Niranjana Vishwanathapura wrote:
On Tue, Oct 18, 2022 at 04:28:07PM +0100, Matthew Auld wrote:
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
.../drm/i915/gem/i915_gem_vm_bind_object.c | 82 +++
drivers/gpu/drm/i915/i915_vma.c | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
include/uapi/drm/i915_drm.h | 49 ++-
5 files changed, 146 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
#include
+struct dma_fence;
struct drm_device;
struct drm_file;
struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device
*dev, void *data,
void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3ea3cb3ed97e..63889ba00183 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
#include
+#include
+
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_vm_bind.h"
@@ -100,6 +102,76 @@ static void i915_gem_vm_bind_remove(struct
i915_vma *vma, bool release_obj)
i915_gem_object_put(vma->obj);
}
+static int i915_vm_bind_add_fence(struct drm_file *file, struct
i915_vma *vma,
+ u32 handle, u64 point)
+{
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file, handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ return -ENOENT;
+ }
+
+ /*
+ * For timeline syncobjs we need to preallocate chains for
+ * later signaling.
+ */
+ if (point) {
+ vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+ if (!vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_put(syncobj);
+ return -ENOMEM;
+ }
+ } else {
+ vma->vm_bind_fence.chain_fence = NULL;
+ }
+ vma->vm_bind_fence.syncobj = syncobj;
+ vma->vm_bind_fence.value = point;
+
+ return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+ if (!vma->vm_bind_fence.syncobj)
+ return;
+
+ drm_syncobj_put(vma->vm_bind_fence.syncobj);
+ dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+ vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence)
+{
+ struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+ if (!syncobj)
+ return;
+
+ if (vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+ /*
+ * The chain's ownership is transferred to the
+ * timeline.
+ */
+ vma->vm_bind_fence.chain_fence = NULL;
+ } else {
+ drm_syncobj_replace_fence(syncobj, fence);
+ }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
struct drm_i915_gem_vm_unbind *va)
{
@@ -237,6 +309,13 @@ static int i915_gem_vm_bind_obj(struct
i915_address_space *vm,
goto unlock_vm;
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+ ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+ va->fence.value);
+ if (ret)
+ goto put_vma;
+ }
+
pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER | PIN_VALIDATE;
for_i915_gem_ww(&ww, ret, true) {
@@ -258,6 +337,9 @@ static int i915_gem_vm_bind_obj(struct
i915_address_space *vm,
i915_gem_object_get(vma->obj);
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)
+ i915_vm_bind_put_fence(vma);
+put_vma:
if (ret)
i915_vma_destroy(vma);
unlock_vm:
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 04abdb92c2b2..eaa13e9ba966 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i91
[PATCH] drm/connector: Set DDC pointer in drmm_connector_init
Commit 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
introduced the function drmm_connector_init() with a parameter for an
optional ddc pointer to the i2c controller used to access the DDC bus.
However, the underlying call to __drm_connector_init() was always
setting it to NULL instead of passing the ddc argument around.
This resulted in unexpected null pointer dereference on platforms
expecting to get a DDC controller.
Fixes: 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..61c29ce74b03 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -435,7 +435,7 @@ int drmm_connector_init(struct drm_device *dev,
if (drm_WARN_ON(dev, funcs && funcs->destroy))
return -EINVAL;
- ret = __drm_connector_init(dev, connector, funcs, connector_type, NULL);
+ ret = __drm_connector_init(dev, connector, funcs, connector_type, ddc);
if (ret)
return ret;
--
2.37.3
[PATCH 2/7] drm/atomic: drop extra bracket from log messages
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index e659fdae477d..826cb2212b26 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -463,7 +463,7 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] unknown property [PROP:%d:%s]]\n",
+ "[CRTC:%d:%s] unknown property [PROP:%d:%s]\n",
crtc->base.id, crtc->name,
property->base.id, property->name);
return -EINVAL;
@@ -586,7 +586,7 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
property, val);
} else {
drm_dbg_atomic(plane->dev,
- "[PLANE:%d:%s] unknown property [PROP:%d:%s]]\n",
+ "[PLANE:%d:%s] unknown property [PROP:%d:%s]\n",
plane->base.id, plane->name,
property->base.id, property->name);
return -EINVAL;
@@ -781,7 +781,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state, property, val);
} else {
drm_dbg_atomic(connector->dev,
- "[CONNECTOR:%d:%s] unknown property
[PROP:%d:%s]]\n",
+ "[CONNECTOR:%d:%s] unknown property
[PROP:%d:%s]\n",
connector->base.id, connector->name,
property->base.id, property->name);
return -EINVAL;
--
2.38.0
[PATCH 3/7] drm/atomic: log when getting/setting unknown properties
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 826cb2212b26..39f3f491c148 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -498,8 +498,13 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
- else
+ else {
+ drm_dbg_atomic(dev,
+ "[CRTC:%d:%s] unknown property [PROP:%d:%s]\n",
+ crtc->base.id, crtc->name,
+ property->base.id, property->name);
return -EINVAL;
+ }
return 0;
}
@@ -645,6 +650,10 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
+ drm_dbg_atomic(dev,
+ "[PLANE:%d:%s] unknown property [PROP:%d:%s]\n",
+ plane->base.id, plane->name,
+ property->base.id, property->name);
return -EINVAL;
}
@@ -861,6 +870,10 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
return connector->funcs->atomic_get_property(connector,
state, property, val);
} else {
+ drm_dbg_atomic(dev,
+ "[CONNECTOR:%d:%s] unknown property
[PROP:%d:%s]\n",
+ connector->base.id, connector->name,
+ property->base.id, property->name);
return -EINVAL;
}
@@ -899,6 +912,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
break;
}
default:
+ drm_dbg_atomic(dev, "[OBJECT:%d] has no properties\n", obj->id);
ret = -EINVAL;
break;
}
@@ -1035,6 +1049,7 @@ int drm_atomic_set_property(struct drm_atomic_state
*state,
break;
}
default:
+ drm_dbg_atomic(prop->dev, "[OBJECT:%d] has no properties\n",
obj->id);
ret = -EINVAL;
break;
}
--
2.38.0
[PATCH 1/7] drm/atomic: log drm_atomic_replace_property_blob_from_id() errors
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..e659fdae477d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -374,16 +374,25 @@ drm_atomic_replace_property_blob_from_id(struct
drm_device *dev,
if (blob_id != 0) {
new_blob = drm_property_lookup_blob(dev, blob_id);
- if (new_blob == NULL)
+ if (new_blob == NULL) {
+ drm_dbg_atomic(dev,
+ "cannot find blob ID %llu\n", blob_id);
return -EINVAL;
+ }
if (expected_size > 0 &&
new_blob->length != expected_size) {
+ drm_dbg_atomic(dev,
+ "[BLOB:%d] length %zu different from
expected %zu\n",
+ new_blob->base.id, new_blob->length,
expected_size);
drm_property_blob_put(new_blob);
return -EINVAL;
}
if (expected_elem_size > 0 &&
new_blob->length % expected_elem_size != 0) {
+ drm_dbg_atomic(dev,
+ "[BLOB:%d] length %zu not divisible by
element size %zu\n",
+ new_blob->base.id, new_blob->length,
expected_elem_size);
drm_property_blob_put(new_blob);
return -EINVAL;
}
--
2.38.0
[PATCH 6/7] drm/atomic: log when page-flip is requested without CRTCs
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 3df3f7ba0af3..b996351beb57 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1261,8 +1261,10 @@ static int prepare_signaling(struct drm_device *dev,
* Having this flag means user mode pends on event which will never
* reach due to lack of at least one CRTC for signaling
*/
- if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+ if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
+ drm_dbg_atomic(dev, "need at least one CRTC for
DRM_MODE_PAGE_FLIP_EVENT");
return -EINVAL;
+ }
return 0;
}
--
2.38.0
[PATCH 5/7] drm/atomic: log on attempt to set legacy DPMS property
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 5aa2ecd1af3d..3df3f7ba0af3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -711,6 +711,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
* is done in legacy setprop path for us. Disallow (for
* now?) atomic writes to DPMS property:
*/
+ drm_dbg_atomic(dev,
+ "legacy [PROP:%d:%s] can only be set via legacy
uAPI\n",
+ property->base.id, property->name);
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
state->tv.select_subconnector = val;
--
2.38.0
[PATCH 4/7] drm/atomic: log when CRTC_ID prop value is invalid
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 39f3f491c148..5aa2ecd1af3d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -539,8 +539,12 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
- if (val && !crtc)
+ if (val && !crtc) {
+ drm_dbg_atomic(dev,
+ "[PROP:%d:%s] cannot find CRTC with ID
%llu\n",
+ property->base.id, property->name, val);
return -EACCES;
+ }
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -695,8 +699,12 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
- if (val && !crtc)
+ if (val && !crtc) {
+ drm_dbg_atomic(dev,
+ "[PROP:%d:%s] cannot find CRTC with ID
%llu\n",
+ property->base.id, property->name, val);
return -EACCES;
+ }
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
--
2.38.0
[PATCH 7/7] drm/atomic: log errors in drm_mode_atomic_ioctl()
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index b996351beb57..eb18ab4e6ef8 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1397,11 +1397,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
obj = drm_mode_object_find(dev, file_priv, obj_id,
DRM_MODE_OBJECT_ANY);
if (!obj) {
+ drm_dbg_atomic(dev, "cannot find object ID %d", obj_id);
ret = -ENOENT;
goto out;
}
if (!obj->properties) {
+ drm_dbg_atomic(dev, "[OBJECT:%d] has no properties",
obj_id);
drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
@@ -1428,6 +1430,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
prop = drm_mode_obj_find_prop_id(obj, prop_id);
if (!prop) {
+ drm_dbg_atomic(dev,
+ "[OBJECT:%d] cannot find
property ID %d",
+ obj_id, prop_id);
drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
--
2.38.0
[PATCH 00/17] ARM: remove old board files
From: Arnd Bergmann This is the first part of the removal of old board files, addressing all the easy cases: cns3xxx and iop32x get removed completely, including a handful of device driversm while ep93xx, dove, mv78xx0, orion, footbridge and omap1 all keep basic platform support but drop support for all boards that have no known users. There are seven patches for other subsystems in this series. It would be helpful to get everything merged in the same release if there are no objections, but I don't care if I include them in the soc tree with an Ack from the subsystem maintainers or the patches are applied directly into the subsystem trees. Arnd Bergmann (17): ARM: at91: remove stale MAINTAINER file entries ARM: cns3xxx: remove entire platform mmc: remove cns3xxx driver ARM: ep93xx: remove old board files ASoC: remove unused ep93xx files ARM: mv78xx0: un-deprecate Terastation WXL ARM: orion: remove unused board files ARM: orion5x: remove dsa_chip_data references ARM: iop32x: remove the platform dmaengine: remove iop-adma driver gpio: remove iop driver ARM: footbridge: remove CATS ARM: omap1: remove unused board files ARM: omap1: remove dead code fbdev: omapfb: remove unused board support spi: remove omap 100K driver mfd: remove htc-i2cpld driver CC: Russell King CC: Aaro Koskinen CC: Janusz Krzysztofik CC: Tony Lindgren CC: Andrew Lunn CC: Sebastian Hesselbarth CC: Gregory Clement CC: Hartley Sweeten CC: Alexander Sverdlin CC: Paul Walmsley CC: Kevin Hilman CC: Vinod Koul CC: Linus Walleij CC: Bartosz Golaszewski CC: Lee Jones CC: Ulf Hansson CC: Mark Brown CC: Felipe Balbi CC: Greg Kroah-Hartman CC: Alan Stern CC: Bin Liu CC: Helge Deller CC: Wim Van Sebroeck CC: Guenter Roeck CC: Liam Girdwood CC: Jaroslav Kysela CC: Takashi Iwai Cc: Hubert Feurstein Cc: Krzysztof Halasa Cc: Lennert Buytenhek Cc: Sergey Lapin CC: Krzysztof Kozlowski CC: Dan Williams CC: "Pali Rohár" CC: linux-ker...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-o...@vger.kernel.org CC: linux-...@vger.kernel.org CC: dmaeng...@vger.kernel.org CC: linux-g...@vger.kernel.org CC: linux-...@vger.kernel.org CC: linux-...@vger.kernel.org CC: linux-...@vger.kernel.org CC: linux-fb...@vger.kernel.org CC: dri-devel@lists.freedesktop.org CC: linux-watch...@vger.kernel.org CC: alsa-de...@alsa-project.org MAINTAINERS | 57 - arch/arm/Kconfig |6 +- arch/arm/Kconfig.debug | 52 +- arch/arm/Makefile|2 - arch/arm/boot/compressed/misc-ep93xx.h | 13 +- arch/arm/configs/cns3420vb_defconfig | 63 - arch/arm/configs/iop32x_defconfig| 126 -- arch/arm/configs/mv78xx0_defconfig |3 - arch/arm/configs/omap1_defconfig |2 - arch/arm/kernel/entry-common.S | 15 - arch/arm/kernel/head.S |2 +- arch/arm/mach-cns3xxx/Kconfig| 21 - arch/arm/mach-cns3xxx/Makefile |6 - arch/arm/mach-cns3xxx/cns3420vb.c| 252 --- arch/arm/mach-cns3xxx/cns3xxx.h | 593 --- arch/arm/mach-cns3xxx/core.c | 410 - arch/arm/mach-cns3xxx/core.h | 32 - arch/arm/mach-cns3xxx/devices.c | 108 -- arch/arm/mach-cns3xxx/devices.h | 17 - arch/arm/mach-cns3xxx/pcie.c | 290 arch/arm/mach-cns3xxx/pm.c | 120 -- arch/arm/mach-cns3xxx/pm.h | 20 - arch/arm/mach-dove/Kconfig |8 - arch/arm/mach-dove/Makefile |1 - arch/arm/mach-dove/dove-db-setup.c | 101 -- arch/arm/mach-ep93xx/Kconfig | 63 - arch/arm/mach-ep93xx/Makefile|5 - arch/arm/mach-ep93xx/adssphere.c | 41 - arch/arm/mach-ep93xx/gesbc9312.c | 41 - arch/arm/mach-ep93xx/micro9.c| 125 -- arch/arm/mach-ep93xx/simone.c| 128 -- arch/arm/mach-ep93xx/snappercl15.c | 162 -- arch/arm/mach-footbridge/Kconfig | 12 - arch/arm/mach-footbridge/Makefile|2 - arch/arm/mach-footbridge/cats-hw.c | 98 -- arch/arm/mach-footbridge/cats-pci.c | 64 - arch/arm/mach-footbridge/common.c|3 - arch/arm/mach-iop32x/Kconfig | 54 - arch/arm/mach-iop32x/Makefile| 20 - arch/arm/mach-iop32x/adma.c | 163 -- arch/arm/mach-iop32x/cp6.c | 48 - arch/arm/mach-iop32x/em7210.c| 232 --- arch/arm/mach-iop32x/glantank.c | 214 --- arch/arm/mach-iop32x/glantank.h | 12 - arch/arm/mach-iop32x/gpio-iop32x.h | 11 - arch/arm/mach-iop32x/hardware.h | 38 - arch/arm/mach-iop32x/i2c.c
Re: [PATCH 2/4] drm/i915/mtl: Modify CAGF functions for MTL
On Tue, Oct 18, 2022 at 10:20:41PM -0700, Ashutosh Dixit wrote:
> From: Badal Nilawar
>
> Update CAGF functions for MTL to get actual resolved frequency of 3D and
> SAMedia.
>
> v2: Update MTL_MIRROR_TARGET_WP1 position/formatting (MattR)
> Move MTL branches in cagf functions to top (MattR)
> Fix commit message (Andi)
> v3: Added comment about registers not needing forcewake for Gen12+ and
> returning 0 freq in RC6
>
> Bspec: 66300
>
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Badal Nilawar
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
> drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++--
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index a7a0129d0e3fc..b4b1b54ad738f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -21,6 +21,10 @@
> */
> #define PERF_REG(offset) _MMIO(offset)
>
> +/* MTL workpoint reg to get core C state and actual freq of 3D, SAMedia */
> +#define MTL_MIRROR_TARGET_WP1_MMIO(0xc60)
> +#define MTL_CAGF_MASK REG_GENMASK(8, 0)
> +
> /* RPM unit config (Gen8+) */
> #define RPM_CONFIG0 _MMIO(0xd00)
> #define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index df21258976d86..5a743ae4dd11e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2093,7 +2093,9 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32
> rpstat)
> struct drm_i915_private *i915 = rps_to_i915(rps);
> u32 cagf;
>
> - if (GRAPHICS_VER(i915) >= 12)
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> + cagf = rpstat & MTL_CAGF_MASK;
I believe we should advocate more the use of the REG_FIELD_GET
cagf = REG_FIELD_GET(MTL_CAGF_MASK, rpstat);
> + else if (GRAPHICS_VER(i915) >= 12)
> cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
// witht the proper REG_GENAMSK usage on the gen12_cagf_mask...
> else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> cagf = (rpstat >> 8) & 0xff;
#define RPE_MASK REG_GENMASK(15, 8)
cagf = REG_FIELD_GET(RPE_MASK, rpstat)
> @@ -2116,7 +2118,13 @@ static u32 read_cagf(struct intel_rps *rps)
> struct intel_uncore *uncore = rps_to_uncore(rps);
^
> u32 freq;
>
> - if (GRAPHICS_VER(i915) >= 12) {
> + /*
> + * For Gen12+ reading freq from HW does not need a forcewake and
> + * registers will return 0 freq when GT is in RC6
> + */
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> + freq = intel_uncore_read(rps_to_gt(rps)->uncore,
> MTL_MIRROR_TARGET_WP1);
here we should use directly the local uncore already declared above with the
same helper...
and consistent with the following elses...
> + } else if (GRAPHICS_VER(i915) >= 12) {
> freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
> } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> vlv_punit_get(i915);
> --
> 2.38.0
>
Re: [Intel-gfx] [PATCH 0/2] Selftest fixes for 6.1
On 19/10/2022 13:10, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Warning - not much tested, mainly bypassing trybot for quick turnaround. Please ignore - this is quite broken and problem more complicated. Regards, Tvrtko Tvrtko Ursulin (2): drm/i915/selftests: Fix waiting for threads to start drm/i915/selftests: Fix selftests for 6.1 kthread_stop semantics .../drm/i915/gem/selftests/i915_gem_context.c | 9 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 13 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +- drivers/gpu/drm/i915/i915_selftest.h | 14 ++ drivers/gpu/drm/i915/selftests/i915_request.c | 136 -- .../gpu/drm/i915/selftests/i915_selftest.c| 18 +++ 6 files changed, 140 insertions(+), 55 deletions(-)
[PATCH printk v2 00/38] reduce console_lock scope
This is v2 of a series to prepare for threaded/atomic printing. It is a rework of patches 6-12 of the v1 [0]. From the v1, patches 1-5 are already mainline and a rework of patches >12 will be posted in a later series. This series focuses on reducing the scope of the BKL console_lock. It achieves this by switching to SRCU and a dedicated mutex for console list iteration and modification, respectively. The console_lock will no longer offer this protection and is completely removed from (un)register_console() and console_stop/start() code. All users of the console_lock for list iteration have been modified. For the call sites where the console_lock is still needed (because of other reasons), I added comments to explain exactly why the console_lock was needed. The base commit for this series is from Paul McKenney's RCU tree and provides an NMI-safe SRCU implementation [1]. Without the NMI-safe SRCU implementation, this series is not less safe than mainline. But we will need the NMI-safe SRCU implementation for atomic consoles anyway, so we might as well get it in now. Especially since it _does_ increase the reliability for mainline in the panic path. Changes since v2: general: - introduce console_is_enabled() to document safe data race on console->flags - switch all "console->flags & CON_ENABLED" code sites to console_is_enabled() - add "for_each_console_srcu" to .clang-format - cleanup/clarify comments relating to console_lock coverage/usage um: - kmsg_dumper: use srcu instead of console_lock for list iteration kgdb/kdb: - configure_kgdboc: keep console_lock for console->device() synchronization, use srcu for list iteration - kgdboc_earlycon_pre_exp_handler: use srcu instead of documenting unsafety for list iteration - kgdboc_earlycon_init: use console_list_lock instead of console_lock to lock list - kdb_msg_write: use srcu instead of documenting unsafety for list iteration tty: - show_cons_active: keep console_lock for console->device() synchronization fbdev: - xen-fbfront: xenfb_probe: use srcu instead of console_lock for list iteration, introduce console_force_preferred() to safely implement hack proc/consoles: - show_console_dev: keep console_lock for console->device() synchronization - c_next: use hlist_entry_safe() instead of hlist_for_each_entry_continue() printk: - remove console_lock from console_stop/start() and (un)register_console() - introduce console_srcu_read_(un)lock() to wrap scru read (un)lock - rename cons_first() macro to console_first() - for_each_console: add lockdep check instead of introducing new for_each_registered_console() - console_list_lock: add warning if in read-side critical section - release srcu read lock on handover - console_flush_all: use srcu instead of relying on console lock for list iteration - console_unblank: use srcu instead of relying on console_lock for list iteration - console_flush_on_panic: use srcu for list iteration and document console->seq race - device: keep console_lock for console->device() synchronization, usr srcu for list iteration - register_console: split list adding logic into the 3 distinct scenarios - register_console: set initial sequence number before adding to list - unregister_console: fix ENODEV return value if the console is not registered - console_stop: synchronize srcu - printk_late_init: use _safe variant of iteration - __pr_flush: use srcu instead of relying on console_lock for list iteration John Ogness [0] https://lore.kernel.org/r/20220924000454.3319186-1-john.ogn...@linutronix.de [1] https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=srcunmisafe.2022.10.18b John Ogness (37): printk: Convert console_drivers list to hlist printk: Prepare for SRCU console list protection printk: introduce console_is_enabled() wrapper printk: use console_is_enabled() tty: nfcon: use console_is_enabled() um: kmsg_dump: use console_is_enabled() efi: earlycon: use console_is_enabled() netconsole: use console_is_enabled() tty: hvc: use console_is_enabled() tty: serial: earlycon: use console_is_enabled() tty: serial: kgdboc: use console_is_enabled() tty: serial: pic32_uart: use console_is_enabled() tty: serial: samsung_tty: use console_is_enabled() tty: serial: serial_core: use console_is_enabled() tty: serial: xilinx_uartps: use console_is_enabled() tty: tty_io: use console_is_enabled() usb: early: xhci-dbc: use console_is_enabled() kdb: kdb_io: use console_is_enabled() um: kmsg_dumper: use srcu console list iterator serial: kgdboc: use srcu console list iterator serial: kgdboc: document console_lock usage tty: tty_io: document console_lock usage xen: fbfront: use srcu console list iterator proc: consoles: document console_lock usage kdb: use srcu console list iterator printk: console_flush_all: use srcu console list iterator printk: console_unblank: use srcu console list iterator p
Re: [PATCH 1/4] drm/i915: Use GEN12_RPSTAT register for GT freq
On Tue, Oct 18, 2022 at 10:20:40PM -0700, Ashutosh Dixit wrote:
> From: Don Hiatt
>
> On GEN12+ use GEN12_RPSTAT register to get actual resolved GT
> freq. GEN12_RPSTAT does not require a forcewake and will return 0 freq if
> GT is in RC6.
>
> v2:
> - Fixed review comments(Ashutosh)
> - Added function intel_rps_read_rpstat_fw to read RPSTAT without
> forcewake, required especially for GEN6_RPSTAT1 (Ashutosh, Tvrtko)
> v3:
> - Updated commit title and message for more clarity (Ashutosh)
> - Replaced intel_rps_read_rpstat with direct read to GEN12_RPSTAT1 in
> read_cagf (Ashutosh)
>
> Cc: Don Hiatt
> Cc: Andi Shyti
> Signed-off-by: Don Hiatt
> Signed-off-by: Badal Nilawar
> Signed-off-by: Ashutosh Dixit
> Reviewed-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> drivers/gpu/drm/i915/gt/intel_rps.c | 32 +
> drivers/gpu/drm/i915/gt/intel_rps.h | 2 ++
> drivers/gpu/drm/i915/i915_pmu.c | 3 +--
> 4 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 36d95b79022c0..a7a0129d0e3fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1543,6 +1543,8 @@
>
> #define GEN12_RPSTAT1_MMIO(0x1381b4)
> #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> +#define GEN12_CAGF_SHIFT 11
we don't need to define the shift if we use the REG_FIELD_GET
> +#define GEN12_CAGF_MASKREG_GENMASK(19, 11)
ah, cool, this is already right and in place
(ignore my comment about this in the other patch)
>
> #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
> #define GEN11_CSME (31)
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index fc23c562d9b2a..df21258976d86 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2068,12 +2068,34 @@ void intel_rps_sanitize(struct intel_rps *rps)
> rps_disable_interrupts(rps);
> }
>
> +u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
> +{
> + struct drm_i915_private *i915 = rps_to_i915(rps);
> + i915_reg_t rpstat;
> +
> + rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
> +
> + return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
> +}
> +
> +u32 intel_rps_read_rpstat(struct intel_rps *rps)
> +{
> + struct drm_i915_private *i915 = rps_to_i915(rps);
> + i915_reg_t rpstat;
> +
> + rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
> +
> + return intel_uncore_read(rps_to_gt(rps)->uncore, rpstat);
> +}
> +
> u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
> u32 cagf;
>
> - if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> + if (GRAPHICS_VER(i915) >= 12)
> + cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
> + else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> cagf = (rpstat >> 8) & 0xff;
> else if (GRAPHICS_VER(i915) >= 9)
> cagf = (rpstat & GEN9_CAGF_MASK) >> GEN9_CAGF_SHIFT;
> @@ -2094,7 +2116,9 @@ static u32 read_cagf(struct intel_rps *rps)
> struct intel_uncore *uncore = rps_to_uncore(rps);
> u32 freq;
>
> - if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> + if (GRAPHICS_VER(i915) >= 12) {
> + freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
> + } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> vlv_punit_get(i915);
> freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
> vlv_punit_put(i915);
> @@ -2260,7 +2284,7 @@ static void rps_frequency_dump(struct intel_rps *rps,
> struct drm_printer *p)
> rpinclimit = intel_uncore_read(uncore, GEN6_RP_UP_THRESHOLD);
> rpdeclimit = intel_uncore_read(uncore, GEN6_RP_DOWN_THRESHOLD);
>
> - rpstat = intel_uncore_read(uncore, GEN6_RPSTAT1);
> + rpstat = intel_rps_read_rpstat(rps);
> rpcurupei = intel_uncore_read(uncore, GEN6_RP_CUR_UP_EI) &
> GEN6_CURICONT_MASK;
> rpcurup = intel_uncore_read(uncore, GEN6_RP_CUR_UP) &
> GEN6_CURBSYTAVG_MASK;
> rpprevup = intel_uncore_read(uncore, GEN6_RP_PREV_UP) &
> GEN6_CURBSYTAVG_MASK;
> @@ -2395,7 +2419,7 @@ static void slpc_frequency_dump(struct intel_rps *rps,
> struct drm_printer *p)
> drm_printf(p, "PM MASK=0x%08x\n", pm_mask);
> drm_printf(p, "pm_intrmsk_mbz: 0x%08x\n",
> rps->pm_intrmsk_mbz);
> - drm_printf(p, "RPSTAT1: 0x%08x\n", intel_uncore_read(uncore,
> GEN6_RPSTAT1));
> + drm_printf(p, "RPSTAT1: 0x%08x\n", intel_rps_read_rpstat(rps));
> drm_printf(p, "RPNSW
[PATCH printk v2 38/38] printk, xen: fbfront: create/use safe function for forcing preferred
With commit 9e124fe16ff2("xen: Enable console tty by default in domU
if it's not a dummy") a hack was implemented to make sure that the
tty console remains the console behind the /dev/console device. The
main problem with the hack is that, after getting the console pointer
to the tty console, it is assumed the pointer is still valid after
releasing the console_sem. This assumption is incorrect and unsafe.
Make the hack safe by introducing a new function
console_force_preferred() to perform the full operation under
the console_list_lock.
Signed-off-by: John Ogness
---
drivers/video/fbdev/xen-fbfront.c | 8 +---
include/linux/console.h | 1 +
kernel/printk/printk.c| 69 +++
3 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 2552c853c6c2..aa362b25a60f 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -512,12 +512,8 @@ static void xenfb_make_preferred_console(void)
}
console_srcu_read_unlock(cookie);
- if (c) {
- unregister_console(c);
- c->flags |= CON_CONSDEV;
- c->flags &= ~CON_PRINTBUFFER; /* don't print again */
- register_console(c);
- }
+ if (c)
+ console_force_preferred(c);
}
static int xenfb_resume(struct xenbus_device *dev)
diff --git a/include/linux/console.h b/include/linux/console.h
index bf1e8136424a..41378b00bbdd 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -235,6 +235,7 @@ enum con_flush_mode {
};
extern int add_preferred_console(char *name, int idx, char *options);
+extern void console_force_preferred(struct console *c);
extern void register_console(struct console *);
extern int unregister_console(struct console *);
extern void console_lock(void);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 840d581c4b23..9a056a42b8d8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3207,38 +3207,17 @@ static void try_enable_default_console(struct console
*newcon)
static int unregister_console_locked(struct console *console);
-/*
- * The console driver calls this routine during kernel initialization
- * to register the console printing procedure with printk() and to
- * print any messages that were printed by the kernel before the
- * console driver was initialized.
- *
- * This can happen pretty early during the boot process (because of
- * early_printk) - sometimes before setup_arch() completes - be careful
- * of what kernel features are used - they may not be initialised yet.
- *
- * There are two types of consoles - bootconsoles (early_printk) and
- * "real" consoles (everything which is not a bootconsole) which are
- * handled differently.
- * - Any number of bootconsoles can be registered at any time.
- * - As soon as a "real" console is registered, all bootconsoles
- *will be unregistered automatically.
- * - Once a "real" console is registered, any attempt to register a
- *bootconsoles will be rejected
- */
-void register_console(struct console *newcon)
+static void register_console_locked(struct console *newcon)
{
struct console *con;
bool bootcon_enabled = false;
bool realcon_enabled = false;
int err;
- console_list_lock();
-
for_each_console(con) {
if (WARN(con == newcon, "console '%s%d' already registered\n",
con->name, con->index)) {
- goto unlock;
+ return;
}
if (con->flags & CON_BOOT)
@@ -3251,7 +3230,7 @@ void register_console(struct console *newcon)
if (newcon->flags & CON_BOOT && realcon_enabled) {
pr_info("Too late to register bootconsole %s%d\n",
newcon->name, newcon->index);
- goto unlock;
+ return;
}
/*
@@ -3282,7 +3261,7 @@ void register_console(struct console *newcon)
/* printk() messages are not printed to the Braille console. */
if (err || newcon->flags & CON_BRL)
- goto unlock;
+ return;
/*
* If we have a bootconsole, and are switching to a real console,
@@ -3346,7 +3325,31 @@ void register_console(struct console *newcon)
unregister_console_locked(con);
}
}
-unlock:
+}
+
+/*
+ * The console driver calls this routine during kernel initialization
+ * to register the console printing procedure with printk() and to
+ * print any messages that were printed by the kernel before the
+ * console driver was initialized.
+ *
+ * This can happen pretty early during the boot process (because of
+ * early_printk) - sometimes before setup_arch() completes - be careful
+ * of what kernel features are used - they may not be in
[PATCH printk v2 24/38] xen: fbfront: use srcu console list iterator
Since the console_lock is not being used for anything other than
safe console list traversal, use srcu console list iteration instead.
Signed-off-by: John Ogness
---
drivers/video/fbdev/xen-fbfront.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 4d2694d904aa..2552c853c6c2 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -500,16 +500,18 @@ static int xenfb_probe(struct xenbus_device *dev,
static void xenfb_make_preferred_console(void)
{
struct console *c;
+ int cookie;
if (console_set_on_cmdline)
return;
- console_lock();
- for_each_console(c) {
+ cookie = console_srcu_read_lock();
+ for_each_console_srcu(c) {
if (!strcmp(c->name, "tty") && c->index == 0)
break;
}
- console_unlock();
+ console_srcu_read_unlock(cookie);
+
if (c) {
unregister_console(c);
c->flags |= CON_CONSDEV;
--
2.30.2
[PATCH 14/17] ARM: omap1: remove dead code
From: Arnd Bergmann
After the removal of the unused board files, I went through the
omap1 code to look for code that no longer has any callers
and remove that.
In particular, support for the omap7xx/omap8xx family is now
completely unused, so I'm only leaving omap15xx/omap16xx/omap59xx.
Cc: Aaro Koskinen
Cc: Janusz Krzysztofik
Cc: Tony Lindgren
Cc: linux-o...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock_data.c | 17 +-
arch/arm/mach-omap1/common.h | 8 ---
arch/arm/mach-omap1/devices.c | 58 ++-
arch/arm/mach-omap1/dma.c | 25 +---
arch/arm/mach-omap1/i2c.c | 14 +
arch/arm/mach-omap1/io.c | 24
arch/arm/mach-omap1/irq.c | 20 +--
arch/arm/mach-omap1/irqs.h | 9 ---
arch/arm/mach-omap1/mcbsp.c| 83 ---
arch/arm/mach-omap1/mtd-xip.h | 4 --
arch/arm/mach-omap1/mux.c | 52 -
arch/arm/mach-omap1/pm.c | 76 -
arch/arm/mach-omap1/pm.h | 39 +
arch/arm/mach-omap1/serial.c | 15 -
arch/arm/mach-omap1/sleep.S| 80 --
arch/arm/mach-omap1/sram-init.c| 7 +--
arch/arm/mach-omap1/usb.c | 34 +++
drivers/spi/spi-omap-uwire.c | 16 +-
drivers/usb/gadget/udc/omap_udc.c | 24 +---
drivers/usb/host/ohci-omap.c | 6 +-
drivers/usb/musb/musb_dma.h| 11 +---
drivers/usb/phy/phy-isp1301-omap.c | 91 +-
drivers/video/fbdev/omap/lcdc.c| 2 -
include/linux/soc/ti/omap1-soc.h | 35
24 files changed, 39 insertions(+), 711 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 96d846c37c43..c58d200e4816 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -720,8 +720,6 @@ int __init omap1_clk_init(void)
cpu_mask |= CK_16XX;
if (cpu_is_omap1510())
cpu_mask |= CK_1510;
- if (cpu_is_omap7xx())
- cpu_mask |= CK_7XX;
if (cpu_is_omap310())
cpu_mask |= CK_310;
@@ -730,9 +728,6 @@ int __init omap1_clk_init(void)
ck_dpll1_p = &ck_dpll1;
ck_ref_p = &ck_ref;
- if (cpu_is_omap7xx())
- ck_ref.rate = 1300;
-
pr_info("Clocks: ARM_SYSST: 0x%04x DPLL_CTL: 0x%04x ARM_CKCTL:
0x%04x\n",
omap_readw(ARM_SYSST), omap_readw(DPLL_CTL),
omap_readw(ARM_CKCTL));
@@ -771,12 +766,6 @@ int __init omap1_clk_init(void)
}
}
- if (machine_is_omap_perseus2() || machine_is_omap_fsample()) {
- /* Select slicer output as OMAP input clock */
- omap_writew(omap_readw(OMAP7XX_PCC_UPLD_CTRL) & ~0x1,
- OMAP7XX_PCC_UPLD_CTRL);
- }
-
/* Amstrad Delta wants BCLK high when inactive */
if (machine_is_ams_delta())
omap_writel(omap_readl(ULPD_CLOCK_CTRL) |
@@ -784,11 +773,7 @@ int __init omap1_clk_init(void)
ULPD_CLOCK_CTRL);
/* Turn off DSP and ARM_TIMXO. Make sure ARM_INTHCK is not divided */
- /* (on 730, bit 13 must not be cleared) */
- if (cpu_is_omap7xx())
- omap_writew(omap_readw(ARM_CKCTL) & 0x2fff, ARM_CKCTL);
- else
- omap_writew(omap_readw(ARM_CKCTL) & 0x0fff, ARM_CKCTL);
+ omap_writew(omap_readw(ARM_CKCTL) & 0x0fff, ARM_CKCTL);
/* Put DSP/MPUI into reset until needed */
omap_writew(0, ARM_RSTCT1);
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 5ceff05e15c0..3fd9ed9efb12 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -35,14 +35,6 @@
#include "soc.h"
#include "i2c.h"
-#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
-void omap7xx_map_io(void);
-#else
-static inline void omap7xx_map_io(void)
-{
-}
-#endif
-
#ifdef CONFIG_ARCH_OMAP15XX
void omap1510_fpga_init_irq(void);
void omap15xx_map_io(void);
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 80e94770582a..42d1631cecc0 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,8 +63,6 @@ static void omap_init_rtc(void)
static inline void omap_init_rtc(void) {}
#endif
-static inline void omap_init_mbox(void) { }
-
/*-*/
#if IS_ENABLED(CONFIG_MMC_OMAP)
@@ -73,22 +71,16 @@ static inline void omap1_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
if (controller_nr == 0) {
- if (cpu_is_omap7xx()) {
- omap_cfg_reg(MMC_7XX_CMD);
- omap_cfg_reg(MMC_7XX_CLK);
- omap_cfg_reg(MMC_7XX_DAT0);
-
[PATCH 15/17] fbdev: omapfb: remove unused board support
From: Arnd Bergmann
A number of omap1 based board files got removed, so the corresponding
framebuffer drivers are no longer used. The remaining ones are for
ams_delta, osk and palmTE, which are still part of the mainline kernel.
Cc: Aaro Koskinen
Cc: Janusz Krzysztofik
Cc: Tony Lindgren
Cc: linux-o...@vger.kernel.org
Cc: Marek Vasut
Cc: Angelo Arrifano
Cc: Imre Deak
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/omap/Kconfig | 9 ---
drivers/video/fbdev/omap/Makefile| 6 --
drivers/video/fbdev/omap/lcd_h3.c| 82
drivers/video/fbdev/omap/lcd_htcherald.c | 59 --
drivers/video/fbdev/omap/lcd_inn1510.c | 69 -
drivers/video/fbdev/omap/lcd_inn1610.c | 99
drivers/video/fbdev/omap/lcd_palmtt.c| 65
drivers/video/fbdev/omap/lcd_palmz71.c | 59 --
8 files changed, 448 deletions(-)
delete mode 100644 drivers/video/fbdev/omap/lcd_h3.c
delete mode 100644 drivers/video/fbdev/omap/lcd_htcherald.c
delete mode 100644 drivers/video/fbdev/omap/lcd_inn1510.c
delete mode 100644 drivers/video/fbdev/omap/lcd_inn1610.c
delete mode 100644 drivers/video/fbdev/omap/lcd_palmtt.c
delete mode 100644 drivers/video/fbdev/omap/lcd_palmz71.c
diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig
index b1786cf1b486..a6548283451f 100644
--- a/drivers/video/fbdev/omap/Kconfig
+++ b/drivers/video/fbdev/omap/Kconfig
@@ -40,15 +40,6 @@ config FB_OMAP_LCD_MIPID
the Mobile Industry Processor Interface DBI-C/DCS
specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
-config FB_OMAP_LCD_H3
- bool "TPS65010 LCD controller on OMAP-H3"
- depends on MACH_OMAP_H3 || COMPILE_TEST
- depends on TPS65010=y
- default y
- help
- Say Y here if you want to have support for the LCD on the
- H3 board.
-
config FB_OMAP_DMA_TUNE
bool "Set DMA SDRAM access priority high"
depends on FB_OMAP
diff --git a/drivers/video/fbdev/omap/Makefile
b/drivers/video/fbdev/omap/Makefile
index b88e02f5cb1f..504edb9c09dd 100644
--- a/drivers/video/fbdev/omap/Makefile
+++ b/drivers/video/fbdev/omap/Makefile
@@ -17,16 +17,10 @@ objs-y$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
lcds-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
-lcds-y$(CONFIG_FB_OMAP_LCD_H3) += lcd_h3.o
lcds-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
-lcds-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o
-lcds-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
-lcds-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
-lcds-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
lcds-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
lcds-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
-lcds-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o
omapfb-objs := $(objs-yy)
diff --git a/drivers/video/fbdev/omap/lcd_h3.c
b/drivers/video/fbdev/omap/lcd_h3.c
deleted file mode 100644
index 1766dff767bb..
--- a/drivers/video/fbdev/omap/lcd_h3.c
+++ /dev/null
@@ -1,82 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * LCD panel support for the TI OMAP H3 board
- *
- * Copyright (C) 2004 Nokia Corporation
- * Author: Imre Deak
- */
-
-#include
-#include
-#include
-#include
-
-#include "omapfb.h"
-
-#define MODULE_NAME"omapfb-lcd_h3"
-
-static int h3_panel_enable(struct lcd_panel *panel)
-{
- int r = 0;
-
- /* GPIO1 and GPIO2 of TPS65010 send LCD_ENBKL and LCD_ENVDD signals */
- r = tps65010_set_gpio_out_value(GPIO1, HIGH);
- if (!r)
- r = tps65010_set_gpio_out_value(GPIO2, HIGH);
- if (r)
- pr_err(MODULE_NAME ": Unable to turn on LCD panel\n");
-
- return r;
-}
-
-static void h3_panel_disable(struct lcd_panel *panel)
-{
- int r = 0;
-
- /* GPIO1 and GPIO2 of TPS65010 send LCD_ENBKL and LCD_ENVDD signals */
- r = tps65010_set_gpio_out_value(GPIO1, LOW);
- if (!r)
- tps65010_set_gpio_out_value(GPIO2, LOW);
- if (r)
- pr_err(MODULE_NAME ": Unable to turn off LCD panel\n");
-}
-
-static struct lcd_panel h3_panel = {
- .name = "h3",
- .config = OMAP_LCDC_PANEL_TFT,
-
- .data_lines = 16,
- .bpp= 16,
- .x_res = 240,
- .y_res = 320,
- .pixel_clock= 12000,
- .hsw= 12,
- .hfp= 14,
- .hbp= 72 - 12,
- .vsw= 1,
- .vfp= 1,
- .vbp= 0,
- .pcd= 0,
-
- .enable = h3_panel_enable,
- .disable= h3_panel_disable,
-};
-
-static int h3_panel_probe(struct platform_device *pdev)
-{
- omapfb_register_panel(&h3_panel);
- return 0;
-}
-
-static struct platform_driver h3_panel_driver = {
- .probe = h3_
Re: [PATCH v4 12/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.
Legacy features like relocations etc are not supported by execbuf3.
v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 580 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 +
drivers/gpu/drm/i915/i915_driver.c| 1 +
include/uapi/drm/i915_drm.h | 61 ++
5 files changed, 645 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8d76bb888dc3..6a801684d569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..a9b4cc44bf66
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,580 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
Are we building/including the docs for this somewhere? Looks like we are
missing some stuff like @fences/@num_fences in the kernel-doc.
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+
[PATCH 1/6] drm/ttm: rework on ttm_resource to use size_t type
Change ttm_resource structure from num_pages to size_t size in bytes.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 8
include/drm/ttm/ttm_resource.h | 2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c8e8be774f1..394ccb13eaed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -51,8 +51,8 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object
*bo,
struct ttm_resource_manager *man;
int i, mem_type;
- drm_printf(&p, "No space for %p (%lu pages, %zuK, %zuM)\n",
- bo, bo->resource->num_pages, bo->base.size >> 10,
+ drm_printf(&p, "No space for %p (%lu size, %zuK, %zuM)\n",
+ bo, bo->resource->size, bo->base.size >> 10,
bo->base.size >> 20);
for (i = 0; i < placement->num_placement; i++) {
mem_type = placement->placement[i].mem_type;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fa04e62202c1..da5493f789df 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -173,7 +173,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter,
src_iter);
if (!src_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
@@ -357,9 +357,9 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
map->virtual = NULL;
map->bo = bo;
- if (num_pages > bo->resource->num_pages)
+ if (num_pages > PFN_UP(bo->resource->size))
return -EINVAL;
- if ((start_page + num_pages) > bo->resource->num_pages)
+ if ((start_page + num_pages) > PFN_UP(bo->resource->size))
return -EINVAL;
ret = ttm_mem_io_reserve(bo->bdev, bo->resource);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 38119311284d..876e7d07273c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -217,7 +217,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
page_last = vma_pages(vma) + vma->vm_pgoff -
drm_vma_node_start(&bo->base.vma_node);
- if (unlikely(page_offset >= bo->resource->num_pages))
+ if (unlikely(page_offset >= PFN_UP(bo->resource->size)))
return VM_FAULT_SIGBUS;
prot = ttm_io_prot(bo, bo->resource, prot);
@@ -412,7 +412,7 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
<< PAGE_SHIFT);
int ret;
- if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->resource->num_pages)
+ if (len < 1 || (offset + len) > bo->resource->size)
return -EIO;
ret = ttm_bo_reserve(bo, true, false, NULL);
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index f7c16c46cfbc..0a8bc0b7f380 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,7 +83,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- node->base.num_pages,
+ PFN_UP(node->base.size),
bo->page_alignment, 0,
place->fpfn, lpfn, mode);
spin_unlock(&rman->lock);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index a729c32a1e48..f9cce0727d40 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -177,7 +177,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
struct ttm_resource_manager *man;
res->start = 0;
- res->num_pages = PFN_UP(bo->base.size);
+ res->size = bo->base.size;
res->mem_type = place->mem_type;
res->placement = place->flags;
res->bus.addr = NULL;
@@ -192,7 +192,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
list_add_tail(&res->lru, &bo->bdev->pinned);
else
list_add_tail(&res->lru, &man->lru[bo->priority]);
- man->usage += res->num_pages << PAGE_SHIFT;
+ man->usage += res->size;
spin_unlock(&bo->bdev->lru_lock);
}
EXPORT_SYMBOL
[PATCH 2/6] drm/amd: fix’s on ttm_resource rework to use size_t type
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
6 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..e51f80bb1d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
cur->size = size;
cur->remaining = size;
cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ WARN_ON(res && start + size > res->size);
return;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 5e6ddc7e101c..677ad2016976 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -127,7 +127,7 @@ TRACE_EVENT(amdgpu_bo_create,
TP_fast_assign(
__entry->bo = bo;
- __entry->pages = bo->tbo.resource->num_pages;
+ __entry->pages = PFN_UP(bo->tbo.resource->size);
__entry->type = bo->tbo.resource->mem_type;
__entry->prefer = bo->preferred_domains;
__entry->allow = bo->allowed_domains;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dc262d2c2925..36066965346f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -381,7 +381,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
dst.offset = 0;
r = amdgpu_ttm_copy_mem_to_mem(adev, &src, &dst,
- new_mem->num_pages << PAGE_SHIFT,
+ new_mem->size,
amdgpu_bo_encrypted(abo),
bo->base.resv, &fence);
if (r)
@@ -424,7 +424,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
static bool amdgpu_mem_visible(struct amdgpu_device *adev,
struct ttm_resource *mem)
{
- u64 mem_size = (u64)mem->num_pages << PAGE_SHIFT;
+ u64 mem_size = (u64)mem->size;
struct amdgpu_res_cursor cursor;
u64 end;
@@ -568,7 +568,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device
*bdev,
struct ttm_resource *mem)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bdev);
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ size_t bus_size = (size_t)mem->size;
switch (mem-
[PATCH 3/6] drm/i915: fix’s on ttm_resource rework to use size_t type
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c | 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4f861782c3e8..7a1e92c11946 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -649,7 +649,7 @@ bool i915_ttm_resource_mappable(struct ttm_resource *res)
if (!i915_ttm_cpu_maps_iomem(res))
return true;
- return bman_res->used_visible_size == bman_res->base.num_pages;
+ return bman_res->used_visible_size == PFN_UP(bman_res->base.size);
}
static int i915_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index dcc081874ec8..114e5e39aa72 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -158,7 +158,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct
ttm_resource *res,
u32 page_alignment)
{
struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
- const u64 size = res->num_pages << PAGE_SHIFT;
+ const u64 size = res->size;
const u32 max_segment = round_down(UINT_MAX, page_alignment);
struct drm_buddy *mm = bman_res->mm;
struct list_head *blocks = &bman_res->blocks;
@@ -177,7 +177,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct
ttm_resource *res,
i915_refct_sgt_init(rsgt, size);
st = &rsgt->table;
- if (sg_alloc_table(st, res->num_pages, GFP_KERNEL)) {
+ if (sg_alloc_table(st, PFN_UP(res->size), GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
return ERR_PTR(-ENOMEM);
}
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index e19452f0e100..7e611476c7a4 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -62,8 +62,8 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (place->fpfn || lpfn != man->size)
bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION;
- GEM_BUG_ON(!bman_res->base.num_pages);
- size = bman_res->base.num_pages << PAGE_SHIFT;
+ GEM_BUG_ON(!bman_res->base.size);
+ size = bman_res->base.size;
min_page_size = bman->default_page_size;
if (bo->page_alignment)
@@ -72,7 +72,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
GEM_BUG_ON(min_page_size < mm->chunk_size);
GEM_BUG_ON(!IS_ALIGNED(size, min_page_size));
- if (place->fpfn + bman_res->base.num_pages != place->lpfn &&
+ if (place->fpfn + PFN_UP(bman_res->base.size) != place->lpfn &&
place->flags & TTM_PL_FLAG_CONTIGUOUS) {
unsigned long pages;
@@ -108,7 +108,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
goto err_free_blocks;
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
- u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
+ u64 original_size = (u64)bman_res->base.size;
drm_buddy_block_trim(mm,
original_size,
@@ -116,7 +116,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
}
if (lpfn <= bman->visible_size) {
- bman_res->used_visible_size = bman_res->base.num_pages;
+ bman_res->used_visible_size = PFN_UP(bman_res->base.size);
} else {
struct drm_buddy_block *block;
@@ -228,7 +228,7 @@ static bool i915_ttm_buddy_man_compatible(struct
ttm_resource_manager *man,
if (!place->fpfn &&
place->lpfn == i915_ttm_buddy_man_visible_size(man))
- return bman_res->used_visible_size == res->num_pages;
+ return bman_res->used_visible_size == PFN_UP(res->size);
/* Check each drm buddy block individually */
list_for_each_entry(block, &bman_res->blocks, link) {
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..cf89d0c2a2d9 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -244,7 +244,7 @@ void intel_region_ttm_resource_free(struct
intel_memory_region *mem,
struct ttm_resource_manager *man = mem->region_private;
struct ttm_buffer_object mock_bo = {};
- mock_bo.base.size = res->num_pages << PAGE_SHIFT;
[PATCH 4/6] drm/nouveau: fix’s on ttm_resource rework to use size_t type
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c| 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
11 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 126b3c6e12f9..16ca4a141866 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -532,7 +532,7 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
- ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.resource->num_pages,
&nvbo->kmap);
+ ret = ttm_bo_kmap(&nvbo->bo, 0, PFN_UP(nvbo->bo.resource->size),
&nvbo->kmap);
ttm_bo_unreserve(&nvbo->bo);
return ret;
@@ -1236,7 +1236,7 @@ vm_fault_t nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
} else {
/* make sure bo is in mappable vram */
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
- bo->resource->start + bo->resource->num_pages < mappable)
+ bo->resource->start + PFN_UP(bo->resource->size) < mappable)
return 0;
for (i = 0; i < nvbo->placement.num_placement; ++i) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
index 7390132129fe..e2ce44adaa5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
@@ -52,7 +52,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
u32 src_offset = old_reg->start << PAGE_SHIFT;
u32 dst_ctxdma = nouveau_bo_mem_ctxdma(bo, chan, new_reg);
u32 dst_offset = new_reg->start << PAGE_SHIFT;
- u32 page_count = new_reg->num_pages;
+ u32 page_count = PFN_UP(new_reg->size);
int ret;
ret = PUSH_WAIT(push, 3);
@@ -62,7 +62,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
PUSH_MTHD(push, NV039, SET_CONTEXT_DMA_BUFFER_IN, src_ctxdma,
SET_CONTEXT_DMA_BUFFER_OUT, dst_ctxdma);
- page_count = new_reg->num_pages;
+ page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 2047) ? 2047 : page_count;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo5039.c
b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
index 4c75c7b3804c..c6cf3629a9f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo5039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
@@ -41,7 +41,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
{
struct nouveau_mem *mem = nouveau_mem(old_reg);
struct nvif_push *push = chan->chan.push;
- u64 length = (new_reg->num_pages << PAGE_SHIFT);
+ u64 length = new_reg->size;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
int src_tiled = !!mem->kind;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
index ed6c09d67840..9b7ba31fae13 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
@@ -44,7 +44,7 @@ nv84_bo_move_exec(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
if (ret)
return ret;
- PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->num_pages << PAGE_SHIFT,
+ PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->size,
0x0308, upper_32_bits(mem->vma[0].addr),
0x030c, lower_32_bits(mem->vma[0].addr),
0x0310, upper_32_bits(mem->vma[1].addr),
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
index dec29b2d8bb2..a15a38a87a95 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
@@ -44,10 +44,10 @@ nva3_bo_move_copy(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
struct nvif_push *push = chan->chan.push;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
- u32 page_count = new_reg->num_pages;
+ u32 page_count = PFN_UP(new_reg->size);
int ret;
- page_count = new_reg->num_pages;
+ page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 8191) ? 8191 : page_count
[PATCH 5/6] drm/radeon: fix’s on ttm_resource rework to use size_t type
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 446f7bae54c4..4c930f0cf132 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -400,8 +400,8 @@ static int cmp_size_smaller_first(void *priv, const struct
list_head *a,
struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list,
tv.head);
/* Sort A before B if A is smaller. */
- return (int)la->robj->tbo.resource->num_pages -
- (int)lb->robj->tbo.resource->num_pages;
+ return (int)PFN_UP(la->robj->tbo.resource->size) -
+ (int)PFN_UP(lb->robj->tbo.resource->size);
}
/**
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 00c33b24d5d3..710d04fcbea6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -232,7 +232,7 @@ int radeon_bo_kmap(struct radeon_bo *bo, void **ptr)
}
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
if (r) {
return r;
}
@@ -737,7 +737,7 @@ vm_fault_t radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
if (bo->resource->mem_type != TTM_PL_VRAM)
return 0;
- size = bo->resource->num_pages << PAGE_SHIFT;
+ size = bo->resource->size;
offset = bo->resource->start << PAGE_SHIFT;
if ((offset + size) <= rdev->mc.visible_vram_size)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index c9fed5f2b870..22676617e1a5 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -22,7 +22,7 @@ TRACE_EVENT(radeon_bo_create,
TP_fast_assign(
__entry->bo = bo;
- __entry->pages = bo->tbo.resource->num_pages;
+ __entry->pages = PFN_UP(bo->tbo.resource->size);
),
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d33fec488713..fff48306c05f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -181,7 +181,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
BUILD_BUG_ON((PAGE_SIZE % RADEON_GPU_PAGE_SIZE) != 0);
- num_pages = new_mem->num_pages * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
+ num_pages = PFN_UP(new_mem->size) * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
fence = radeon_copy(rdev, old_start, new_start, num_pages,
bo->base.resv);
if (IS_ERR(fence))
return PTR_ERR(fence);
@@ -268,7 +268,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
static int radeon_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
{
struct radeon_device *rdev = radeon_get_rdev(bdev);
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ size_t bus_size = (size_t)mem->size;
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
--
2.32.0
[PATCH 6/6] drm/vmwgfx: fix’s on ttm_resource rework to use size_t type
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 6 +++---
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index 09fe20e918f9..c52c7bf1485b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -483,8 +483,8 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
d.src_addr = NULL;
d.dst_pages = dst->ttm->pages;
d.src_pages = src->ttm->pages;
- d.dst_num_pages = dst->resource->num_pages;
- d.src_num_pages = src->resource->num_pages;
+ d.dst_num_pages = PFN_UP(dst->resource->size);
+ d.src_num_pages = PFN_UP(src->resource->size);
d.dst_prot = ttm_io_prot(dst, dst->resource, PAGE_KERNEL);
d.src_prot = ttm_io_prot(src, src->resource, PAGE_KERNEL);
d.diff = diff;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 822251aaab0a..134a13a50861 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -194,7 +194,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
int ret = 0;
place = vmw_vram_placement.placement[0];
- place.lpfn = bo->resource->num_pages;
+ place.lpfn = PFN_UP(bo->resource->size);
placement.num_placement = 1;
placement.placement = &place;
placement.num_busy_placement = 1;
@@ -211,7 +211,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
* that situation.
*/
if (bo->resource->mem_type == TTM_PL_VRAM &&
- bo->resource->start < bo->resource->num_pages &&
+ bo->resource->start < PFN_UP(bo->resource->size) &&
bo->resource->start > 0 &&
buf->base.pin_count == 0) {
ctx.interruptible = false;
@@ -352,7 +352,7 @@ void *vmw_bo_map_and_cache(struct vmw_buffer_object *vbo)
if (virtual)
return virtual;
- ret = ttm_bo_kmap(bo, 0, bo->resource->num_pages, &vbo->map);
+ ret = ttm_bo_kmap(bo, 0, PFN_UP(bo->resource->size), &vbo->map);
if (ret)
DRM_ERROR("Buffer object map failed: %d.\n", ret);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index 79b30dc9d825..c5ed49241f9d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -427,7 +427,7 @@ static int vmw_cotable_resize(struct vmw_resource *res,
size_t new_size)
* Do a page by page copy of COTables. This eliminates slow vmap()s.
* This should really be a TTM utility.
*/
- for (i = 0; i < old_bo->resource->num_pages; ++i) {
+ for (i = 0; i < PFN_UP(old_bo->resource->size); ++i) {
bool dummy;
ret = ttm_bo_kmap(old_bo, i, 1, &old_map);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index f085dbd4736d..2fb53aa57a56 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1047,7 +1047,7 @@ static int vmw_query_bo_switch_prepare(struct vmw_private
*dev_priv,
if (unlikely(new_query_bo != sw_context->cur_query_bo)) {
- if (unlikely(new_query_bo->base.resource->num_pages > 4)) {
+ if (unlikely(PFN_UP(new_query_bo->base.resource->size) > 4)) {
VMW_DEBUG_USER("Query buffer too large.\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index 60e3cc537f36..abd5e3323ebf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -71,7 +71,7 @@ static int vmw_gmrid_man_get_node(struct ttm_resource_manager
*man,
spin_lock(&gman->lock);
if (gman->max_gmr_pages > 0) {
- gman->used_gmr_pages += (*res)->num_pages;
+ gman->used_gmr_pages += PFN_UP((*res)->size);
/*
* Because the graphics memory is a soft limit we can try to
* expand it instead of letting the userspace apps crash.
@@ -114,7 +114,7 @@ static int vmw_gmrid_man_get_node(struct
ttm_resource_manager *man,
return 0;
nospace:
- gman->used_gmr_pages -= (*res)->num_pages;
+ gman->used_gmr_pages -= PFN_UP((*res)->size);
spin_unlock(&gman->lock);
ida_free(&gman->gmr_ida,
Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi
Hi Laurent On Sun, 16 Oct 2022 at 02:33, Laurent Pinchart wrote: > > Hello, > > On Fri, Oct 14, 2022 at 03:08:49PM +0100, Dave Stevenson wrote: > > On Thu, 13 Oct 2022 at 13:58, Francesco Dolcini wrote: > > > On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote: > > > > From: Max Krummenacher > > > > > > > > The property is used to set the enum bus_format and infer the bpc > > > > for a panel defined by 'panel-dpi'. > > > > This specifies how the panel is connected to the display interface. > > > > > > > > Signed-off-by: Max Krummenacher > > > > > > > > > > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > index dae0676b5c6e..52f5db03b6a8 100644 > > > > --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > > > @@ -26,7 +26,28 @@ properties: > > > >height-mm: true > > > >label: true > > > >panel-timing: true > > > > - port: true > > > > + > > > > + port: > > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > > +description: > > > > + Input port node, receives the panel data. > > > > + > > > > +properties: > > > > + endpoint: > > > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > > > > + > > > > +properties: > > > > + bus-format: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +minimum: 0x1001 > > > > +maximum: 0x1fff > > > > +description: | > > > > + Describes how the display panel is connected to the > > > > display interface. > > > > + Valid values are defined in > > > > . > > > > + The mapping between the color/significance of the panel > > > > lines to the > > > > + parallel data lines are defined in: > > > > + > > > > https://www.kernel.org/doc/html/v5.17/userspace-api/media/v4l/subdev-formats.html#packed-rgb-formats > > > > + > > > > > > Last month I had the chance to talk in person about this topic with > > > Dave, Marek and Max in Dublin. > > > > > > My understanding is that this change is addressing a general need, Dave > > > confirmed me they have a downstream patch for raspberrypi [1]. > > > > > > From what I could tell the only concern is about the actual encoding of > > > this `bus-format` property. > > > > > > I am personally convinced that a simple enum is the way to go, I think > > > that Marek proposal is adding complexity and not flexibility (from my > > > understanding Dave is on the same page, just correct me if I > > > misunderstood you). > > > > Yes I agree with you here. > > > > This binding is for the panel, and currently the only path to pass the > > panel mode to the DPI transmitter is one or more MEDIA_BUS_FMT_* enums > > in struct drm_display_info *bus_formats. > > > > Looking at Marek's comment over DSI and data-lanes, yes both source > > and sink could advertise a data-lanes property to cover the condition > > where they aren't wired up in a 1:1 fashion. Reality is that most > > drivers don't support reordering the lanes - looking at the bindings, > > only one (msm) documents the use of data-lanes on the host side. > > rcar_mipi_dsi looks at the number of lanes specified only, and then > > checks that the number requested by the device is <= the number > > configured. > > > > As I see it, the comparison here is that this "bus-format" property is > > the equivalent of the data-lanes on the sink, and is the desired > > number of lanes value passed from sink to source (one integer, not a > > mapping). > > If the source can reorder the lanes, then that is a property of the > > source. This binding is for the sink, and so isn't a reasonable > > comparison. It also doesn't have to be called "bus-format" on the > > source, and can take a totally different form. > > I'll admit that I know data-lane configuration more from CSI2, but > > within V4L2 it is the node that can support reordering that should > > have the lanes in a non-incrementing order, and that is normally the > > SoC rather than the sensor. The same would seem to apply here - it's > > the SoC that can remap the signals, not the panel. > > > > It could be argued that for DPI the panel should only advertise the > > panel's bit depth for each channel, not the padding. The panel is > > generic and could handle any wiring/padding options, and it isn't > > necessarily a simple 16/18/24/32 bit bus representation, just a > > collection of N wires. > > Padding and wiring is a function of the DPI transmitter / SoC, or > > potentially an interconnect node between the two. > > Sooo... I'm not sure where to start :-) > > I think the trouble when describing the connection between a source and > a sink in DT is that none of the source or sink is an ideal place to > describe properties of the connection
Re: [PATCH] drm/connector: Set DDC pointer in drmm_connector_init
Am 19.10.22 um 16:34 schrieb Maxime Ripard:
Commit 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
introduced the function drmm_connector_init() with a parameter for an
optional ddc pointer to the i2c controller used to access the DDC bus.
However, the underlying call to __drm_connector_init() was always
setting it to NULL instead of passing the ddc argument around.
This resulted in unexpected null pointer dereference on platforms
expecting to get a DDC controller.
Fixes: 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
Signed-off-by: Maxime Ripard
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..61c29ce74b03 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -435,7 +435,7 @@ int drmm_connector_init(struct drm_device *dev,
if (drm_WARN_ON(dev, funcs && funcs->destroy))
return -EINVAL;
- ret = __drm_connector_init(dev, connector, funcs, connector_type, NULL);
+ ret = __drm_connector_init(dev, connector, funcs, connector_type, ddc);
if (ret)
return ret;
--
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
dri-devel@lists.freedesktop.org
From: Arnd Bergmann Most of the legacy PXA board files were marked as unused in linux-5.19 and can get removed in linux-6.2. There is support for pxa250/pxa270/pxa300 using devicetree already, which supports a number of boards, but progress on converting the remaining ones has stalled over the past few years. The two boards that are left in the tree for now are the three 'sharpsl' variants (spitz/akita/borzoi) and the 'gumstix' family of machines. Both of these are supported by qemu, which can be helpful for completing the DT conversion. Only PXA25x and PXA27x are left with full boardfile support, so PXA300 can get a lot simpler while still working with DT, and PXA310/320/93x can be removed entirely. A good number of drivers become impossible to select after this, so each of these also get dropped. I'm including the driver patches in the series here and can either merge them through the soc tree, or they can get picked up by the individual subsystem maintainers. Since both the platform and the drivers get removed, the order should not matter. Note that the patches here are generated with 'git format-patch -D' and don't contain the contents of removed files because of the significant size (the first patch is close to a megabyte). Arnd Bergmann (30): ARM: pxa: remove unused board files ARM: pxa: remove irda leftover ARM: pxa: remove unused pxa3xx-ulpi ARM: pxa: drop pxa310/pxa320/pxa93x support ARM: pxa: prune unused device support power: remove z2_battery driver power: remove tosa_battery driver ata: remove palmld pata driver backlight: remove pxa tosa support input: remove pxa930_trkball driver input: remove pxa930_rotary keyboard driver input: remove zylonite touchscreen driver pcmcia: remove unused pxa/sa1100 drivers ASoC: pxa: remove unused board support ALSA: remove ac97 bus support mfd: remove wm97xx driver input: remove wm97xx support parport: remove ax88796 driver power: remove pda_power supply driver rtc: remove v3020 driver mfd: remove toshiba tmio drivers mfd: remove ucb1400 support mtd: remove tmio_nand driver mmc: remove tmio_mmc driver fbdev: remove tmiofb driver fbdev: remove w100fb driver leds: remove asic3 driver usb: remove ohci-tmio driver w1: remove ds1wm driver mfd: remove htc-pasic3 driver Cc: Alan Stern Cc: Alexandre Belloni Cc: Bartosz Golaszewski Cc: Damien Le Moal Cc: Daniel Mack Cc: Dmitry Torokhov Cc: Dominik Brodowski Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Haojian Zhuang Cc: Helge Deller Cc: Jaroslav Kysela Cc: Jingoo Han Cc: Lee Jones Cc: Lennert Buytenhek Cc: Liam Girdwood Cc: Linus Walleij Cc: Marek Vasut Cc: Mark Brown Cc: Michael Petchkovsky Cc: Miquel Raynal Cc: Paul Parsons Cc: Philipp Zabel Cc: Robert Jarzmik Cc: Russell King Cc: Sebastian Reichel Cc: Sergey Lapin Cc: Sergey Shtylyov Cc: Sudip Mukherjee Cc: Takashi Iwai Cc: Ulf Hansson Cc: Vignesh Raghavendra Cc: Viresh Kumar Cc: Wolfram Sang Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-g...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: patc...@opensource.cirrus.com Cc: linux-l...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: alsa-de...@alsa-project.org Documentation/power/power_supply_class.rst|4 +- MAINTAINERS | 100 +- arch/arm/Kconfig |1 - arch/arm/configs/cm_x300_defconfig| 163 -- arch/arm/configs/colibri_pxa270_defconfig | 157 -- arch/arm/configs/colibri_pxa300_defconfig | 60 - arch/arm/configs/corgi_defconfig | 247 --- arch/arm/configs/eseries_pxa_defconfig| 97 - arch/arm/configs/ezx_defconfig| 389 arch/arm/configs/h5000_defconfig | 74 - arch/arm/configs/lpd270_defconfig | 58 - arch/arm/configs/lubbock_defconfig| 53 - arch/arm/configs/magician_defconfig | 151 -- arch/arm/configs/mainstone_defconfig | 51 - arch/arm/configs/palmz72_defconfig| 75 - arch/arm/configs/pcm027_defconfig | 90 - arch/arm/configs/pxa255-idp_defconfig | 55 - arch/arm/configs/pxa_defconfig|3 - arch/arm/configs/trizeps4_defconfig | 207 --- arch/arm/configs/viper_defconfig | 160 -- arch/arm/configs/xcep_defconfig | 89 - arch/arm/configs/zeus_defconfig | 173 -- arch/arm/mach-pxa/Kconfig | 583 +- arch/arm/mach-pxa/Makefile| 60 +- arch/arm/mach-pxa/balloon3-pcmcia.c | 137 -- arch/arm/mach-pxa/balloon3.c | 821 arc
Re: [PATCH v2 36/37] arm64: dts: zynqmp: Add ports for the DisplayPort subsystem
Hi Michal,
I plan to send a pull request for the series soon. Patches 01/37 to
35/37 will go through the DRM tree. How would you like to handle this
patch and the next ? They depend on the DT binding changes in 01/37.
On Thu, Sep 29, 2022 at 01:47:18AM +0300, Laurent Pinchart wrote:
> The DPSUB DT bindings now specify ports to model the connections with
> the programmable logic and the DisplayPort output. Add them to the
> device tree.
>
> Signed-off-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index a549265e55f6..307c76cd8544 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -930,6 +930,30 @@ zynqmp_dpsub: display@fd4a {
> <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO1>,
> <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO2>,
> <&zynqmp_dpdma ZYNQMP_DPDMA_GRAPHICS>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + port@2 {
> + reg = <2>;
> + };
> + port@3 {
> + reg = <3>;
> + };
> + port@4 {
> + reg = <4>;
> + };
> + port@5 {
> + reg = <5>;
> + };
> + };
> };
> };
> };
--
Regards,
Laurent Pinchart
Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test
On 10/19/22 13:36, Maíra Canal wrote:
> [cc Javier]
>
> Hi David,
>
> On 10/19/22 04:32, David Gow wrote:
>> The xrgb2101010 format conversion test (unlike for other formats) does
>> an endianness conversion on the results. However, it always converts
>> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
>> writing to) more memory than in present in the result buffer. Instead,
>> use the buffer size, divided by sizeof(u32).
>>
>> The issue could be reproduced with KASAN:
>> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
>> --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
>> --kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
>> drm_format_helper_test.*xrgb2101010
>>
>> Reported-by: Linux Kernel Functional Testing
>> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for
>> drm_fb_xrgb_to_xrgb2101010()")
>> Signed-off-by: David Gow
>
> Reviewed-by: Maíra Canal
>
The fix makes sense to me as well,
Reviewed-by: Javier Martinez Canillas
>> ---
>>
>> This is a fix for the issue reported here:
>> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=k8p...@mail.gmail.com/
>>
>> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
>> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairaca...@riseup.net/
>
> I believe this patch will go to the drm-misc-fixes tree, so I can rebase
> the series (and address the format issues) as this patch hits mainline.
>
Awesome. I assume you are pushing to drm-misc-fixes then?
Thanks a lot David and Maíra for taking care of this!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v4 14/17] drm/i915/vm_bind: Expose i915_request_await_bind()
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 8 +---
drivers/gpu/drm/i915/i915_vma.h | 6 ++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4975fc662c86..ab89e907f2eb 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1884,18 +1884,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
}
-static int
-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
- return __i915_request_await_exclusive(rq, &vma->active);
-}
-
static int __i915_vma_move_to_active(struct i915_vma *vma, struct
i915_request *rq)
{
int err;
/* Wait for the vma to be bound before we start! */
- err = __i915_request_await_bind(rq, vma);
+ err = i915_request_await_bind(rq, vma);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 04770f8ba815..19e57e12b956 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -54,6 +54,12 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma,
unsigned int flags);
/* do not reserve memory to prevent deadlocks */
#define __EXEC_OBJECT_NO_RESERVE BIT(31)
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
Some kernel doc might be good?
Reviewed-by: Matthew Auld
+{
+ return __i915_request_await_exclusive(rq, &vma->active);
+}
+
int __must_check _i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq,
struct dma_fence *fence,
Re: [PATCH v4 13/17] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 16 +++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index eaa13e9ba966..4975fc662c86 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -439,12 +439,21 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion
Maybe mention the locking since this is now more than just DEBUG_GEM
stuff. I assume we need the object lock or otherwise some guarantee that
the vma is pinned?
Reviewed-by: Matthew Auld
+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
{
struct dma_fence *fence = i915_active_fence_get(&vma->active.excl);
int err;
+ /* Ensure vma bind is initiated */
+ if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+ return -EINVAL;
+
if (!fence)
return 0;
@@ -457,9 +466,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma *vma)
return err;
}
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
I915_SELFTEST_EXPORT void
i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1cadbf8fdedf..04770f8ba815 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -440,6 +440,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
int i915_vma_wait_for_bind(struct i915_vma *vma);
int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
/**
* i915_vma_get_current_resource - Get the current resource of the vma
dri-devel@lists.freedesktop.org
From: Arnd Bergmann Most of the legacy PXA board files were marked as unused in linux-5.19 and can get removed in linux-6.2. There is support for pxa250/pxa270/pxa300 using devicetree already, which supports a number of boards, but progress on converting the remaining ones has stalled over the past few years. The two boards that are left in the tree for now are the three 'sharpsl' variants (spitz/akita/borzoi) and the 'gumstix' family of machines. Both of these are supported by qemu, which can be helpful for completing the DT conversion. Only PXA25x and PXA27x are left with full boardfile support, so PXA300 can get a lot simpler while still working with DT, and PXA310/320/93x can be removed entirely. A good number of drivers become impossible to select after this, so each of these also get dropped. I'm including the driver patches in the series here and can either merge them through the soc tree, or they can get picked up by the individual subsystem maintainers. Since both the platform and the drivers get removed, the order should not matter. Note that the patches here are generated with 'git format-patch -D' and don't contain the contents of removed files because of the significant size (the first patch is close to a megabyte). Arnd Bergmann (30): ARM: pxa: remove unused board files ARM: pxa: remove irda leftover ARM: pxa: remove unused pxa3xx-ulpi ARM: pxa: drop pxa310/pxa320/pxa93x support ARM: pxa: prune unused device support power: remove z2_battery driver power: remove tosa_battery driver ata: remove palmld pata driver backlight: remove pxa tosa support input: remove pxa930_trkball driver input: remove pxa930_rotary keyboard driver input: remove zylonite touchscreen driver pcmcia: remove unused pxa/sa1100 drivers ASoC: pxa: remove unused board support ALSA: remove ac97 bus support mfd: remove wm97xx driver input: remove wm97xx support parport: remove ax88796 driver power: remove pda_power supply driver rtc: remove v3020 driver mfd: remove toshiba tmio drivers mfd: remove ucb1400 support mtd: remove tmio_nand driver mmc: remove tmio_mmc driver fbdev: remove tmiofb driver fbdev: remove w100fb driver leds: remove asic3 driver usb: remove ohci-tmio driver w1: remove ds1wm driver mfd: remove htc-pasic3 driver Cc: st...@rowland.harvard.edu Cc: alexandre.bell...@bootlin.com Cc: b...@bgdev.pl Cc: damien.lem...@opensource.wdc.com Cc: dan...@zonque.org Cc: dmitry.torok...@gmail.com Cc: li...@dominikbrodowski.net Cc: ba...@kernel.org Cc: gre...@linuxfoundation.org Cc: haojian.zhu...@gmail.com Cc: del...@gmx.de Cc: pe...@perex.cz Cc: jingooh...@gmail.com Cc: l...@kernel.org Cc: ker...@wantstofly.org Cc: lgirdw...@gmail.com Cc: linus.wall...@linaro.org Cc: marek.va...@gmail.com Cc: broo...@kernel.org Cc: mkpe...@internode.on.net Cc: miquel.ray...@bootlin.com Cc: lost.dista...@yahoo.com Cc: philipp.za...@gmail.com Cc: robert.jarz...@free.fr Cc: li...@armlinux.org.uk Cc: s...@kernel.org Cc: sla...@ossfans.org Cc: s.shtyl...@omp.ru Cc: sudipm.mukher...@gmail.com Cc: ti...@suse.com Cc: ulf.hans...@linaro.org Cc: vigne...@ti.com Cc: viresh.ku...@linaro.org Cc: wsa+rene...@sang-engineering.com Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-g...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: patc...@opensource.cirrus.com Cc: linux-l...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: alsa-de...@alsa-project.org Documentation/power/power_supply_class.rst|4 +- MAINTAINERS | 100 +- arch/arm/Kconfig |1 - arch/arm/configs/cm_x300_defconfig| 163 -- arch/arm/configs/colibri_pxa270_defconfig | 157 -- arch/arm/configs/colibri_pxa300_defconfig | 60 - arch/arm/configs/corgi_defconfig | 247 --- arch/arm/configs/eseries_pxa_defconfig| 97 - arch/arm/configs/ezx_defconfig| 389 arch/arm/configs/h5000_defconfig | 74 - arch/arm/configs/lpd270_defconfig | 58 - arch/arm/configs/lubbock_defconfig| 53 - arch/arm/configs/magician_defconfig | 151 -- arch/arm/configs/mainstone_defconfig | 51 - arch/arm/configs/palmz72_defconfig| 75 - arch/arm/configs/pcm027_defconfig | 90 - arch/arm/configs/pxa255-idp_defconfig | 55 - arch/arm/configs/pxa_defconfig|3 - arch/arm/configs/trizeps4_defconfig | 207 --- arch/arm/configs/viper_defconfig | 160 -- arch/arm/configs/xcep_defconfig | 89 - arch/arm/configs/zeus_defconfig | 173 -- arch/arm/mach-pxa/Kcon
[PATCH v1 2/7] vfio/ccw: remove private->sch
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_chp.c | 5 +++--
drivers/s390/cio/vfio_ccw_drv.c | 3 +--
drivers/s390/cio/vfio_ccw_fsm.c | 27 ---
drivers/s390/cio/vfio_ccw_ops.c | 12 ++--
drivers/s390/cio/vfio_ccw_private.h | 7 ---
5 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_chp.c b/drivers/s390/cio/vfio_ccw_chp.c
index 13b26a1c7988..d3f3a611f95b 100644
--- a/drivers/s390/cio/vfio_ccw_chp.c
+++ b/drivers/s390/cio/vfio_ccw_chp.c
@@ -16,6 +16,7 @@ static ssize_t vfio_ccw_schib_region_read(struct
vfio_ccw_private *private,
char __user *buf, size_t count,
loff_t *ppos)
{
+ struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned int i = VFIO_CCW_OFFSET_TO_INDEX(*ppos) - VFIO_CCW_NUM_REGIONS;
loff_t pos = *ppos & VFIO_CCW_OFFSET_MASK;
struct ccw_schib_region *region;
@@ -27,12 +28,12 @@ static ssize_t vfio_ccw_schib_region_read(struct
vfio_ccw_private *private,
mutex_lock(&private->io_mutex);
region = private->region[i].data;
- if (cio_update_schib(private->sch)) {
+ if (cio_update_schib(sch)) {
ret = -ENODEV;
goto out;
}
- memcpy(region, &private->sch->schib, sizeof(*region));
+ memcpy(region, &sch->schib, sizeof(*region));
if (copy_to_user(buf, (void *)region + pos, count)) {
ret = -EFAULT;
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 634760ca0dea..4ee953c8ae39 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -154,7 +154,6 @@ static struct vfio_ccw_private
*vfio_ccw_alloc_private(struct subchannel *sch)
if (!private)
return ERR_PTR(-ENOMEM);
- private->sch = sch;
mutex_init(&private->io_mutex);
private->state = VFIO_CCW_STATE_STANDBY;
INIT_LIST_HEAD(&private->crw);
@@ -383,7 +382,7 @@ static int vfio_ccw_chp_event(struct subchannel *sch,
if (!private || !mask)
return 0;
- trace_vfio_ccw_chp_event(private->sch->schid, mask, event);
+ trace_vfio_ccw_chp_event(sch->schid, mask, event);
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: mask=0x%x event=%d\n",
sch->schid.cssid,
sch->schid.ssid, sch->schid.sch_no,
diff --git a/drivers/s390/cio/vfio_ccw_fsm.c b/drivers/s390/cio/vfio_ccw_fsm.c
index a59c758869f8..e67fad897af3 100644
--- a/drivers/s390/cio/vfio_ccw_fsm.c
+++ b/drivers/s390/cio/vfio_ccw_fsm.c
@@ -18,15 +18,13 @@
static int fsm_io_helper(struct vfio_ccw_private *private)
{
- struct subchannel *sch;
+ struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
union orb *orb;
int ccode;
__u8 lpm;
unsigned long flags;
int ret;
- sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
orb = cp_get_orb(&private->cp, (u32)(addr_t)sch, sch->lpm);
@@ -80,13 +78,11 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
static int fsm_do_halt(struct vfio_ccw_private *private)
{
- struct subchannel *sch;
+ struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned long flags;
int ccode;
int ret;
- sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
VFIO_CCW_TRACE_EVENT(2, "haltIO");
@@ -121,13 +117,11 @@ static int fsm_do_halt(struct vfio_ccw_private *private)
static int fsm_do_clear(struct vfio_ccw_private *private)
{
- struct subchannel *sch;
+ struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned long flags;
int ccode;
int ret;
- sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
VFIO_CCW_TRACE_EVENT(2, "clearIO");
@@ -160,7 +154,7 @@ static int fsm_do_clear(struct vfio_ccw_private *private)
static void fsm_notoper(struct vfio_ccw_private *private,
enum vfio_ccw_event event)
{
- struct subchannel *sch = private->sch;
+ struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: notoper event %x state %x\n",
sch->schid.cssid,
@@ -228,7 +222,7 @@ static void fsm_async_retry(struct vfio_ccw_private
*private,
static void fsm_disabled_irq(struct vfio_ccw_private *private,
enum vfio_ccw_event event)
{
- struct subchannel *sch = private->sch;
+ struct subchannel *sch = to_subc
[PATCH v1 1/7] vfio/ccw: create a parent struct
Move the stuff associated with the mdev parent (and thus the
subchannel struct) into its own struct, and leave the rest in
the existing private structure.
The subchannel will point to the parent, and the parent will point
to the private, for the areas where one or both are needed. Further
separation of these structs will follow.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 104
drivers/s390/cio/vfio_ccw_ops.c | 9 ++-
drivers/s390/cio/vfio_ccw_parent.h | 28
drivers/s390/cio/vfio_ccw_private.h | 5 --
4 files changed, 112 insertions(+), 34 deletions(-)
create mode 100644 drivers/s390/cio/vfio_ccw_parent.h
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 7f5402fe857a..634760ca0dea 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -20,6 +20,7 @@
#include "chp.h"
#include "ioasm.h"
#include "css.h"
+#include "vfio_ccw_parent.h"
#include "vfio_ccw_private.h"
struct workqueue_struct *vfio_ccw_work_q;
@@ -36,7 +37,8 @@ debug_info_t *vfio_ccw_debug_trace_id;
*/
int vfio_ccw_sch_quiesce(struct subchannel *sch)
{
- struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
+ struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
+ struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
DECLARE_COMPLETION_ONSTACK(completion);
int iretry, ret = 0;
@@ -51,19 +53,21 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
break;
}
- /*
-* Flush all I/O and wait for
-* cancel/halt/clear completion.
-*/
- private->completion = &completion;
- spin_unlock_irq(sch->lock);
+ if (private) {
+ /*
+* Flush all I/O and wait for
+* cancel/halt/clear completion.
+*/
+ private->completion = &completion;
+ spin_unlock_irq(sch->lock);
- if (ret == -EBUSY)
- wait_for_completion_timeout(&completion, 3*HZ);
+ if (ret == -EBUSY)
+ wait_for_completion_timeout(&completion, 3*HZ);
- private->completion = NULL;
- flush_workqueue(vfio_ccw_work_q);
- spin_lock_irq(sch->lock);
+ private->completion = NULL;
+ flush_workqueue(vfio_ccw_work_q);
+ spin_lock_irq(sch->lock);
+ }
ret = cio_disable_subchannel(sch);
} while (ret == -EBUSY);
@@ -121,7 +125,22 @@ static void vfio_ccw_crw_todo(struct work_struct *work)
*/
static void vfio_ccw_sch_irq(struct subchannel *sch)
{
- struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
+ struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
+ struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
+
+ /*
+* The subchannel should still be disabled at this point,
+* so an interrupt would be quite surprising. As with an
+* interrupt while the FSM is closed, let's attempt to
+* disable the subchannel again.
+*/
+ if (!private) {
+ VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: unexpected interrupt\n",
+ sch->schid.cssid, sch->schid.ssid, sch->schid.sch_no);
+
+ cio_disable_subchannel(sch);
+ return;
+ }
inc_irq_stat(IRQIO_CIO);
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
@@ -201,10 +220,19 @@ static void vfio_ccw_free_private(struct vfio_ccw_private
*private)
mutex_destroy(&private->io_mutex);
kfree(private);
}
+
+static void vfio_ccw_free_parent(struct device *dev)
+{
+ struct vfio_ccw_parent *parent = container_of(dev, struct
vfio_ccw_parent, dev);
+
+ kfree(parent);
+}
+
static int vfio_ccw_sch_probe(struct subchannel *sch)
{
struct pmcw *pmcw = &sch->schib.pmcw;
struct vfio_ccw_private *private;
+ struct vfio_ccw_parent *parent;
int ret = -ENOMEM;
if (pmcw->qf) {
@@ -213,18 +241,28 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
return -ENODEV;
}
+ parent = kzalloc(sizeof(*parent), GFP_KERNEL);
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ parent->dev.release = &vfio_ccw_free_parent;
+ device_initialize(&parent->dev);
+
private = vfio_ccw_alloc_private(sch);
- if (IS_ERR(private))
+ if (IS_ERR(private)) {
+ put_device(&parent->dev);
return PTR_ERR(private);
+ }
- dev_set_drvdata(&sch->dev, private);
+ dev_set_drvdata(&sch->dev, parent);
+ dev_set_drvdata(&parent->dev, private);
[PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 29 -
drivers/s390/cio/vfio_ccw_ops.c | 28 ++--
drivers/s390/cio/vfio_ccw_private.h | 3 ---
drivers/vfio/vfio_main.c| 3 ---
4 files changed, 18 insertions(+), 45 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 686a9b9f6731..9bbf41315aca 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -146,35 +146,6 @@ static void vfio_ccw_sch_irq(struct subchannel *sch)
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
}
-struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
-{
- struct vfio_ccw_private *private;
-
- private = kzalloc(sizeof(*private), GFP_KERNEL);
- if (!private)
- return ERR_PTR(-ENOMEM);
-
- return private;
-}
-
-void vfio_ccw_free_private(struct vfio_ccw_private *private)
-{
- struct vfio_ccw_crw *crw, *temp;
-
- list_for_each_entry_safe(crw, temp, &private->crw, next) {
- list_del(&crw->next);
- kfree(crw);
- }
-
- kmem_cache_free(vfio_ccw_crw_region, private->crw_region);
- kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
- kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
- kmem_cache_free(vfio_ccw_io_region, private->io_region);
- kfree(private->cp.guest_cp);
- mutex_destroy(&private->io_mutex);
- kfree(private);
-}
-
static void vfio_ccw_free_parent(struct device *dev)
{
struct vfio_ccw_parent *parent = container_of(dev, struct
vfio_ccw_parent, dev);
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 261cb8150abb..9619dc35080f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -103,15 +103,10 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
struct vfio_ccw_private *private;
int ret;
- private = vfio_ccw_alloc_private(sch);
- if (!private)
- return -ENOMEM;
-
- ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
- if (ret) {
- kfree(private);
- return ret;
- }
+ private = vfio_alloc_device(vfio_ccw_private, vdev, &mdev->dev,
+ &vfio_ccw_dev_ops);
+ if (IS_ERR(private))
+ return PTR_ERR(private);
dev_set_drvdata(&parent->dev, private);
@@ -136,8 +131,21 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device
*vdev)
{
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
+ struct vfio_ccw_crw *crw, *temp;
+
+ list_for_each_entry_safe(crw, temp, &private->crw, next) {
+ list_del(&crw->next);
+ kfree(crw);
+ }
+
+ kmem_cache_free(vfio_ccw_crw_region, private->crw_region);
+ kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
+ kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
+ kmem_cache_free(vfio_ccw_io_region, private->io_region);
+ kfree(private->cp.guest_cp);
+ mutex_destroy(&private->io_mutex);
- vfio_ccw_free_private(private);
+ vfio_free_device(vdev);
}
static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_private.h
b/drivers/s390/cio/vfio_ccw_private.h
index ddaf6846022d..2ca408881659 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -116,9 +116,6 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch);
void vfio_ccw_sch_io_todo(struct work_struct *work);
void vfio_ccw_crw_todo(struct work_struct *work);
-struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch);
-void vfio_ccw_free_private(struct vfio_ccw_private *private);
-
extern struct mdev_driver vfio_ccw_mdev_driver;
/*
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2d168793d4e1..28f36c6d9d3f 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -386,8 +386,6 @@ EXPORT_SYMBOL_GPL(_vfio_alloc_device);
/*
* Initialize a vfio_device so it can be registered to vfio core.
- *
- * Only vfio-ccw driver should call this interface.
*/
int vfio_init_device(struct vfio_device *device, struct device *dev,
const struct vfio_device_ops *ops)
@@ -422,7 +420,6 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
ida_free(&vfio.device_ida, device->index);
return ret;
}
-EXPORT_SYMBOL_GPL(vfio_init_device);
/*
* The helper called by driver @release callback to free
[PATCH v1 4/7] vfio/ccw: move private to mdev lifecycle
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 17 ++---
drivers/s390/cio/vfio_ccw_ops.c | 26 +-
drivers/s390/cio/vfio_ccw_private.h | 3 +++
3 files changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index cc9ed2fd970f..686a9b9f6731 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -146,7 +146,7 @@ static void vfio_ccw_sch_irq(struct subchannel *sch)
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
}
-static struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
+struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
{
struct vfio_ccw_private *private;
@@ -157,7 +157,7 @@ static struct vfio_ccw_private
*vfio_ccw_alloc_private(struct subchannel *sch)
return private;
}
-static void vfio_ccw_free_private(struct vfio_ccw_private *private)
+void vfio_ccw_free_private(struct vfio_ccw_private *private)
{
struct vfio_ccw_crw *crw, *temp;
@@ -185,7 +185,6 @@ static void vfio_ccw_free_parent(struct device *dev)
static int vfio_ccw_sch_probe(struct subchannel *sch)
{
struct pmcw *pmcw = &sch->schib.pmcw;
- struct vfio_ccw_private *private;
struct vfio_ccw_parent *parent;
int ret = -ENOMEM;
@@ -202,14 +201,7 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
parent->dev.release = &vfio_ccw_free_parent;
device_initialize(&parent->dev);
- private = vfio_ccw_alloc_private(sch);
- if (IS_ERR(private)) {
- put_device(&parent->dev);
- return PTR_ERR(private);
- }
-
dev_set_drvdata(&sch->dev, parent);
- dev_set_drvdata(&parent->dev, private);
parent->mdev_type.sysfs_name = "io";
parent->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
@@ -226,9 +218,7 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
return 0;
out_free:
- dev_set_drvdata(&parent->dev, NULL);
dev_set_drvdata(&sch->dev, NULL);
- vfio_ccw_free_private(private);
put_device(&parent->dev);
return ret;
}
@@ -236,13 +226,10 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
static void vfio_ccw_sch_remove(struct subchannel *sch)
{
struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
- struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
mdev_unregister_parent(&parent->parent);
dev_set_drvdata(&sch->dev, NULL);
-
- vfio_ccw_free_private(private);
put_device(&parent->dev);
VFIO_CCW_MSG_EVENT(4, "unbound from subchannel %x.%x.%04x\n",
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 626b8eb3507b..3e627b236241 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
{
struct subchannel *sch = to_subchannel(mdev->dev.parent);
struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
- struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
+ struct vfio_ccw_private *private;
int ret;
- if (private->state == VFIO_CCW_STATE_NOT_OPER)
- return -ENODEV;
+ private = vfio_ccw_alloc_private(sch);
+ if (!private)
+ return -ENOMEM;
ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
- if (ret)
+ if (ret) {
+ kfree(private);
return ret;
+ }
+
+ dev_set_drvdata(&parent->dev, private);
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
sch->schid.cssid,
@@ -123,6 +128,7 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
return 0;
err_put_vdev:
+ dev_set_drvdata(&parent->dev, NULL);
vfio_put_device(&private->vdev);
return ret;
}
@@ -132,15 +138,6 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device
*vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
- /*
-* We cannot free vfio_ccw_private here because it includes
-* parent info which must be free'ed by css driver.
-*
-* Use a workaround by memset'ing the core device part and
-* then notifying the remove path that all active references
-* to this device have been released.
-*/
- memset(vdev, 0, sizeof(*vdev));
complete(&private->release_comp);
}
@@ -157,6 +154,7 @@ static void vfio_ccw_mdev_remove(struct md
[PATCH v1 7/7] vfio: Remove vfio_free_device
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.
Signed-off-by: Eric Farman
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 -
drivers/s390/cio/vfio_ccw_ops.c | 2 --
drivers/s390/crypto/vfio_ap_ops.c | 6 --
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 -
drivers/vfio/pci/vfio_pci_core.c | 1 -
drivers/vfio/platform/vfio_amba.c | 1 -
drivers/vfio/platform/vfio_platform.c | 1 -
drivers/vfio/vfio_main.c | 22 --
include/linux/vfio.h | 1 -
samples/vfio-mdev/mbochs.c| 1 -
samples/vfio-mdev/mdpy.c | 1 -
samples/vfio-mdev/mtty.c | 1 -
12 files changed, 4 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 7a45e5360caf..eee6805e67de 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1461,7 +1461,6 @@ static void intel_vgpu_release_dev(struct vfio_device
*vfio_dev)
struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
intel_gvt_destroy_vgpu(vgpu);
- vfio_free_device(vfio_dev);
}
static const struct vfio_device_ops intel_vgpu_dev_ops = {
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 9619dc35080f..cfb2e5c8e717 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -144,8 +144,6 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device
*vdev)
kmem_cache_free(vfio_ccw_io_region, private->io_region);
kfree(private->cp.guest_cp);
mutex_destroy(&private->io_mutex);
-
- vfio_free_device(vdev);
}
static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 0b4cc8c597ae..f108c0f14712 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -765,11 +765,6 @@ static void vfio_ap_mdev_unlink_fr_queues(struct
ap_matrix_mdev *matrix_mdev)
}
}
-static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
-{
- vfio_free_device(vdev);
-}
-
static void vfio_ap_mdev_remove(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(&mdev->dev);
@@ -1784,7 +1779,6 @@ static const struct attribute_group vfio_queue_attr_group
= {
static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {
.init = vfio_ap_mdev_init_dev,
- .release = vfio_ap_mdev_release_dev,
.open_device = vfio_ap_mdev_open_device,
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index b16874e913e4..7b8889f55007 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -568,7 +568,6 @@ static void vfio_fsl_mc_release_dev(struct vfio_device
*core_vdev)
vfio_fsl_uninit_device(vdev);
mutex_destroy(&vdev->igate);
- vfio_free_device(core_vdev);
}
static int vfio_fsl_mc_remove(struct fsl_mc_device *mc_dev)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index badc9d828cac..9be2d5be5d95 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -2109,7 +2109,6 @@ void vfio_pci_core_release_dev(struct vfio_device
*core_vdev)
mutex_destroy(&vdev->vma_lock);
kfree(vdev->region);
kfree(vdev->pm_save);
- vfio_free_device(core_vdev);
}
EXPORT_SYMBOL_GPL(vfio_pci_core_release_dev);
diff --git a/drivers/vfio/platform/vfio_amba.c
b/drivers/vfio/platform/vfio_amba.c
index eaea63e5294c..18faf2678b99 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -95,7 +95,6 @@ static void vfio_amba_release_dev(struct vfio_device
*core_vdev)
vfio_platform_release_common(vdev);
kfree(vdev->name);
- vfio_free_device(core_vdev);
}
static void vfio_amba_remove(struct amba_device *adev)
diff --git a/drivers/vfio/platform/vfio_platform.c
b/drivers/vfio/platform/vfio_platform.c
index 82cedcebfd90..9910451dc341 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -83,7 +83,6 @@ static void vfio_platform_release_dev(struct vfio_device
*core_vdev)
container_of(core_vdev, struct vfio_platform_device, vdev);
vfio_platform_release_common(vdev);
- vfio_free_device(core_vdev);
}
static int vfio_platform_remove(struct platform_device *pdev)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 28f36c6d9d3f..8a1d83cbb05a 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -339,13 +339,10 @@ static void vfio_device_release(struct de
[PATCH v1 3/7] vfio/ccw: move private initialization to callback
There's already a device initialization callback that is
used to initialize the release completion workaround.
Move the other elements of the vfio_ccw_private struct that
require distinct initialization over to that routine.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_drv.c | 57 +++--
drivers/s390/cio/vfio_ccw_ops.c | 43 ++
drivers/s390/cio/vfio_ccw_private.h | 7 +++-
3 files changed, 55 insertions(+), 52 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 4ee953c8ae39..cc9ed2fd970f 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -24,10 +24,10 @@
#include "vfio_ccw_private.h"
struct workqueue_struct *vfio_ccw_work_q;
-static struct kmem_cache *vfio_ccw_io_region;
-static struct kmem_cache *vfio_ccw_cmd_region;
-static struct kmem_cache *vfio_ccw_schib_region;
-static struct kmem_cache *vfio_ccw_crw_region;
+struct kmem_cache *vfio_ccw_io_region;
+struct kmem_cache *vfio_ccw_cmd_region;
+struct kmem_cache *vfio_ccw_schib_region;
+struct kmem_cache *vfio_ccw_crw_region;
debug_info_t *vfio_ccw_debug_msg_id;
debug_info_t *vfio_ccw_debug_trace_id;
@@ -74,7 +74,7 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
return ret;
}
-static void vfio_ccw_sch_io_todo(struct work_struct *work)
+void vfio_ccw_sch_io_todo(struct work_struct *work)
{
struct vfio_ccw_private *private;
struct irb *irb;
@@ -110,7 +110,7 @@ static void vfio_ccw_sch_io_todo(struct work_struct *work)
eventfd_signal(private->io_trigger, 1);
}
-static void vfio_ccw_crw_todo(struct work_struct *work)
+void vfio_ccw_crw_todo(struct work_struct *work)
{
struct vfio_ccw_private *private;
@@ -154,52 +154,7 @@ static struct vfio_ccw_private
*vfio_ccw_alloc_private(struct subchannel *sch)
if (!private)
return ERR_PTR(-ENOMEM);
- mutex_init(&private->io_mutex);
- private->state = VFIO_CCW_STATE_STANDBY;
- INIT_LIST_HEAD(&private->crw);
- INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
- INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
-
- private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
- GFP_KERNEL);
- if (!private->cp.guest_cp)
- goto out_free_private;
-
- private->io_region = kmem_cache_zalloc(vfio_ccw_io_region,
- GFP_KERNEL | GFP_DMA);
- if (!private->io_region)
- goto out_free_cp;
-
- private->cmd_region = kmem_cache_zalloc(vfio_ccw_cmd_region,
- GFP_KERNEL | GFP_DMA);
- if (!private->cmd_region)
- goto out_free_io;
-
- private->schib_region = kmem_cache_zalloc(vfio_ccw_schib_region,
- GFP_KERNEL | GFP_DMA);
-
- if (!private->schib_region)
- goto out_free_cmd;
-
- private->crw_region = kmem_cache_zalloc(vfio_ccw_crw_region,
- GFP_KERNEL | GFP_DMA);
-
- if (!private->crw_region)
- goto out_free_schib;
return private;
-
-out_free_schib:
- kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
-out_free_cmd:
- kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
-out_free_io:
- kmem_cache_free(vfio_ccw_io_region, private->io_region);
-out_free_cp:
- kfree(private->cp.guest_cp);
-out_free_private:
- mutex_destroy(&private->io_mutex);
- kfree(private);
- return ERR_PTR(-ENOMEM);
}
static void vfio_ccw_free_private(struct vfio_ccw_private *private)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index cf383c729d53..626b8eb3507b 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -50,8 +50,51 @@ static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
+ mutex_init(&private->io_mutex);
+ private->state = VFIO_CCW_STATE_STANDBY;
+ INIT_LIST_HEAD(&private->crw);
+ INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
+ INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
init_completion(&private->release_comp);
+
+ private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
+ GFP_KERNEL);
+ if (!private->cp.guest_cp)
+ goto out_free_private;
+
+ private->io_region = kmem_cache_zalloc(vfio_ccw_io_region,
+ GFP_KERNEL | GFP_DMA);
+ if (!private->io_region)
+ goto out_free_cp;
+
+ private->cmd_region = kmem_cache_zalloc(vfio_ccw_cmd_region,
+ GFP_
[PATCH v1 5/7] vfio/ccw: remove release completion
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.
Signed-off-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_ops.c | 14 +-
drivers/s390/cio/vfio_ccw_private.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 3e627b236241..261cb8150abb 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -55,7 +55,6 @@ static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
INIT_LIST_HEAD(&private->crw);
INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
- init_completion(&private->release_comp);
private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
GFP_KERNEL);
@@ -138,7 +137,7 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device
*vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
- complete(&private->release_comp);
+ vfio_ccw_free_private(private);
}
static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
@@ -156,17 +155,6 @@ static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
dev_set_drvdata(&parent->dev, NULL);
vfio_put_device(&private->vdev);
- /*
-* Wait for all active references on mdev are released so it
-* is safe to defer kfree() to a later point.
-*
-* TODO: the clean fix is to split parent/mdev info from ccw
-* private structure so each can be managed in its own life
-* cycle.
-*/
- wait_for_completion(&private->release_comp);
-
- vfio_ccw_free_private(private);
}
static int vfio_ccw_mdev_open_device(struct vfio_device *vdev)
diff --git a/drivers/s390/cio/vfio_ccw_private.h
b/drivers/s390/cio/vfio_ccw_private.h
index c1959b8bfe86..ddaf6846022d 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -87,7 +87,6 @@ struct vfio_ccw_crw {
* @req_trigger: eventfd ctx for signaling userspace to return device
* @io_work: work for deferral process of I/O handling
* @crw_work: work for deferral process of CRW handling
- * @release_comp: synchronization helper for vfio device release
*/
struct vfio_ccw_private {
struct vfio_device vdev;
@@ -111,8 +110,6 @@ struct vfio_ccw_private {
struct eventfd_ctx *req_trigger;
struct work_struct io_work;
struct work_struct crw_work;
-
- struct completion release_comp;
} __aligned(8);
int vfio_ccw_sch_quiesce(struct subchannel *sch);
--
2.34.1
[PATCH v1 0/7] vfio-ccw parent rework
Hi all,
There have been discussions and attempts [1][2] to rework the vfio-ccw device
lifecycle to better align with the needs/expectations of vfio and mdev.
While those languished, commit cb9ff3f3b84c ("vfio: Add helpers for unifying
vfio_device life cycle") implemented a couple of tricks that help vfio and the
drivers that interact with it, while keeping vfio-ccw as-is. A handful of
commits titled "vfio/xxx: Use the new device life cycle helpers" implemented
those tricks for each of the drivers.
This series attempts to address the oddities/shortcomings of vfio-ccw, such
that vfio-ccw can use the same helpers as everyone else, and the tricks that
were implemented by the other drivers can be removed. It is built on 6.1-rc1,
and thus includes the various changes [3][4] that have occurred in and around
these parts.
Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
In summary, the mdev pieces are split out of vfio_ccw_private and into a
new vfio_ccw_parent struct that will continue to follow today's lifecycle.
The remainder (bulk) of the private struct moves to follow the mdev
probe/remove pair. There's opportunity for further separation of the
things in the private struct, which would simplify some of the vfio-ccw
code, but it got too hairy as I started that. Once vfio-ccw is no longer
considered unique, those cleanups can happen at our leisure.
Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of
vfio_alloc_device, and thus removes vfio_init_device from the outside world.
Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello,
CC list!), letting it be handled by vfio_device_release directly.
Looking forward to the feedback.
Thanks,
Eric
[1] https://lore.kernel.org/kvm/0-v3-57c1502c62fd+2190-ccw_mdev_...@nvidia.com/
[2] https://lore.kernel.org/kvm/20220602171948.2790690-1-far...@linux.ibm.com/
[3] https://lore.kernel.org/kvm/20220923092652.100656-1-...@lst.de/
[4] https://lore.kernel.org/kvm/20220921104401.38898-1-kevin.t...@intel.com/
Eric Farman (7):
vfio/ccw: create a parent struct
vfio/ccw: remove private->sch
vfio/ccw: move private initialization to callback
vfio/ccw: move private to mdev lifecycle
vfio/ccw: remove release completion
vfio/ccw: replace vfio_init_device with _alloc_
vfio: Remove vfio_free_device
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 -
drivers/s390/cio/vfio_ccw_chp.c | 5 +-
drivers/s390/cio/vfio_ccw_drv.c | 182 ++
drivers/s390/cio/vfio_ccw_fsm.c | 27 ++--
drivers/s390/cio/vfio_ccw_ops.c | 108 ++-
drivers/s390/cio/vfio_ccw_parent.h| 28
drivers/s390/cio/vfio_ccw_private.h | 22 ++--
drivers/s390/crypto/vfio_ap_ops.c | 6 -
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 -
drivers/vfio/pci/vfio_pci_core.c | 1 -
drivers/vfio/platform/vfio_amba.c | 1 -
drivers/vfio/platform/vfio_platform.c | 1 -
drivers/vfio/vfio_main.c | 25 +---
include/linux/vfio.h | 1 -
samples/vfio-mdev/mbochs.c| 1 -
samples/vfio-mdev/mdpy.c | 1 -
samples/vfio-mdev/mtty.c | 1 -
17 files changed, 204 insertions(+), 208 deletions(-)
create mode 100644 drivers/s390/cio/vfio_ccw_parent.h
--
2.34.1
Re: [PATCH 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.
On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote:
> ⚠ External Email
>
> On 10/17/22 21:54, Zack Rusin wrote:
> > From: Maaz Mombasawala
> >
> > Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
> > to reduce maintenence burden.
> > As part of this effort, refactor the res_ht hashtable used for resource
> > validation during execbuf execution to use linux/hashtable implementation.
> > This also refactors vmw_validation_context to use vmw_sw_context as the
> > container for the hashtable, whereas before it used a vmwgfx_open_hash
> > directly. This makes vmw_validation_context less generic, but there is
> > no functional change since res_ht is the only instance where validation
> > context used a hashtable in vmwgfx driver.
>
> Why is a pointer to the vmw_sw_context added to the validation context,
> rather than a pointer to the new hash table type itself? Seems like an
> unnecessary indirection which adds a dependency on the sw context to the
> validation context?
Hi, Thomas. Thanks for taking a look at this! That's because the entire public
interface of hashtable depends on it being a struct on which sizeof works rather
than a pointer, i.e. almost the entire interface of hasthbale.h is defined and
they
all require that HASH_SIZE(hashtable) which is defined as
#define HASH_SIZE(hashtable) (ARRAY_SIZE(hashtable))
works on the hashtable. So the interface of hashtable.h can't operate on
pointers,
but rather needs the full struct.
So the only two options are either rewriting the functions from
linux/hashtable.h to
take explicit HASH_SIZE(hashtable) or make sure that in the functions where you
will
use hashtable.h you pass the parent struct so that sizeof on the hashtable works
correctly. I've seen both approaches in the kernel, but in this case we thought
the
latter made more sense.
> > + if (ctx->sw_context) {
> > struct vmwgfx_hash_item *hash;
> > + unsigned long key = (unsigned long) vbo;
> >
> > - if (!vmwgfx_ht_find_item(ctx->ht, (unsigned long) vbo, &hash))
> > - bo_node = container_of(hash, typeof(*bo_node), hash);
> > + hash_for_each_possible_rcu(ctx->sw_context->res_ht, hash,
> > head, key) {
>
> This open-coded loop seems to be used throughout the conversion, and
> also in other patches. Perhaps a small helper in place?
Yes, that's a good idea. We'll see if we can abstract that. The tricky bit of
abstracting code that's using hash_* functions is that, as mentioned above,
these
are all macros that depend on hashtable not being a pointer, so if you can't fit
your helper in another define then you have the same choice as above (i.e.
rewrite
whatever hash_* function you were using to allow for explicit hash size, or make
your helper take the parent of the hash as argument).
> Otherwise LGTM.
Thanks!
z
Re: [PATCH 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.
Hi, Zack, On 10/19/22 18:32, Zack Rusin wrote: On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote: ⚠ External Email On 10/17/22 21:54, Zack Rusin wrote: From: Maaz Mombasawala Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable to reduce maintenence burden. As part of this effort, refactor the res_ht hashtable used for resource validation during execbuf execution to use linux/hashtable implementation. This also refactors vmw_validation_context to use vmw_sw_context as the container for the hashtable, whereas before it used a vmwgfx_open_hash directly. This makes vmw_validation_context less generic, but there is no functional change since res_ht is the only instance where validation context used a hashtable in vmwgfx driver. Why is a pointer to the vmw_sw_context added to the validation context, rather than a pointer to the new hash table type itself? Seems like an unnecessary indirection which adds a dependency on the sw context to the validation context? Hi, Thomas. Thanks for taking a look at this! That's because the entire public interface of hashtable depends on it being a struct on which sizeof works rather than a pointer, i.e. almost the entire interface of hasthbale.h is defined and they all require that HASH_SIZE(hashtable) which is defined as #define HASH_SIZE(hashtable) (ARRAY_SIZE(hashtable)) works on the hashtable. So the interface of hashtable.h can't operate on pointers, but rather needs the full struct. So the only two options are either rewriting the functions from linux/hashtable.h to take explicit HASH_SIZE(hashtable) or make sure that in the functions where you will use hashtable.h you pass the parent struct so that sizeof on the hashtable works correctly. I've seen both approaches in the kernel, but in this case we thought the latter made more sense. Ah, Ok, yes, tricky one. Lots of options, none of them perfect. Reviewed-by: Thomas Hellström
Re: [PATCH 1/6] drm/ttm: rework on ttm_resource to use size_t type
Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:
Change ttm_resource structure from num_pages to size_t size in bytes.
When you remove the num_pages field (instead of adding the size
additionally) you need to change all drivers in one patch.
Otherwise the build would break in between patches and that's not
something we can do.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 8
include/drm/ttm/ttm_resource.h | 2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c8e8be774f1..394ccb13eaed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -51,8 +51,8 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object
*bo,
struct ttm_resource_manager *man;
int i, mem_type;
- drm_printf(&p, "No space for %p (%lu pages, %zuK, %zuM)\n",
- bo, bo->resource->num_pages, bo->base.size >> 10,
+ drm_printf(&p, "No space for %p (%lu size, %zuK, %zuM)\n",
+ bo, bo->resource->size, bo->base.size >> 10,
Please just remove printing the resource size completely here.
bo->base.size >> 20);
for (i = 0; i < placement->num_placement; i++) {
mem_type = placement->placement[i].mem_type;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fa04e62202c1..da5493f789df 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -173,7 +173,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter,
src_iter);
Please use ttm->num_pages here (IIRC).
if (!src_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
@@ -357,9 +357,9 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
map->virtual = NULL;
map->bo = bo;
- if (num_pages > bo->resource->num_pages)
+ if (num_pages > PFN_UP(bo->resource->size))
return -EINVAL;
- if ((start_page + num_pages) > bo->resource->num_pages)
+ if ((start_page + num_pages) > PFN_UP(bo->resource->size))
return -EINVAL;
ret = ttm_mem_io_reserve(bo->bdev, bo->resource);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 38119311284d..876e7d07273c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -217,7 +217,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
page_last = vma_pages(vma) + vma->vm_pgoff -
drm_vma_node_start(&bo->base.vma_node);
- if (unlikely(page_offset >= bo->resource->num_pages))
+ if (unlikely(page_offset >= PFN_UP(bo->resource->size)))
Please use bo->base.size here. The resource size can actually be larger
than the BO size, but the extra space shouldn't be CPU map-able.
return VM_FAULT_SIGBUS;
prot = ttm_io_prot(bo, bo->resource, prot);
@@ -412,7 +412,7 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
<< PAGE_SHIFT);
int ret;
- if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->resource->num_pages)
+ if (len < 1 || (offset + len) > bo->resource->size)
Same here, please use bo->base.size.
return -EIO;
ret = ttm_bo_reserve(bo, true, false, NULL);
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index f7c16c46cfbc..0a8bc0b7f380 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,7 +83,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- node->base.num_pages,
+ PFN_UP(node->base.size),
bo->page_alignment, 0,
place->fpfn, lpfn, mode);
spin_unlock(&rman->lock);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index a729c32a1e48..f9cce0727d40 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -177,7 +177,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
struct ttm_resource_manager *man;
res->start = 0;
- res->n
Re: [PATCH 2/6] drm/amd: fix’s on ttm_resource rework to use size_t type
Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
6 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..e51f80bb1d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
Here bo->tbo.base.size would make more sense, but apart from that the
patch looks good to me.
Regards,
Christian.
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
cur->size = size;
cur->remaining = size;
cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ WARN_ON(res && start + size > res->size);
return;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 5e6ddc7e101c..677ad2016976 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -127,7 +127,7 @@ TRACE_EVENT(amdgpu_bo_create,
TP_fast_assign(
__entry->bo = bo;
- __entry->pages = bo->tbo.resource->num_pages;
+ __entry->pages = PFN_UP(bo->tbo.resource->size);
__entry->type = bo->tbo.resource->mem_type;
__entry->prefer = bo->preferred_domains;
__entry->allow = bo->allowed_domains;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dc262d2c2925..36066965346f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -381,7 +381,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
dst.offset = 0;
r = amdgpu_ttm_copy_mem_to_mem(adev, &src, &dst,
- new_mem->num_pages << PAGE_SHIFT,
+ new_mem->size,
amdgpu_bo_encrypted(abo),
bo->base.resv, &fence);
if (r)
@@ -424,7 +424,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
static bool amdgpu_mem_visible(struct amdgpu_device *adev,
struct ttm_resource *mem)
{
- u64 mem_size = (u64)mem->num_pages << PAGE_SHIFT;
+ u64 mem_size = (u64)mem->size;
struct amdgpu_res_cursor cursor;
u64 end;
@@ -568,7 +568,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device *bdev,
struct ttm_resource *mem)
{
struct amd
Re: [PATCH 3/6] drm/i915: fix’s on ttm_resource rework to use size_t type
Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
Acked-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c | 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4f861782c3e8..7a1e92c11946 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -649,7 +649,7 @@ bool i915_ttm_resource_mappable(struct ttm_resource *res)
if (!i915_ttm_cpu_maps_iomem(res))
return true;
- return bman_res->used_visible_size == bman_res->base.num_pages;
+ return bman_res->used_visible_size == PFN_UP(bman_res->base.size);
}
static int i915_ttm_io_mem_reserve(struct ttm_device *bdev, struct ttm_resource *mem)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index dcc081874ec8..114e5e39aa72 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -158,7 +158,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct
ttm_resource *res,
u32 page_alignment)
{
struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
- const u64 size = res->num_pages << PAGE_SHIFT;
+ const u64 size = res->size;
const u32 max_segment = round_down(UINT_MAX, page_alignment);
struct drm_buddy *mm = bman_res->mm;
struct list_head *blocks = &bman_res->blocks;
@@ -177,7 +177,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct
ttm_resource *res,
i915_refct_sgt_init(rsgt, size);
st = &rsgt->table;
- if (sg_alloc_table(st, res->num_pages, GFP_KERNEL)) {
+ if (sg_alloc_table(st, PFN_UP(res->size), GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
return ERR_PTR(-ENOMEM);
}
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index e19452f0e100..7e611476c7a4 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -62,8 +62,8 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (place->fpfn || lpfn != man->size)
bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION;
- GEM_BUG_ON(!bman_res->base.num_pages);
- size = bman_res->base.num_pages << PAGE_SHIFT;
+ GEM_BUG_ON(!bman_res->base.size);
+ size = bman_res->base.size;
min_page_size = bman->default_page_size;
if (bo->page_alignment)
@@ -72,7 +72,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
GEM_BUG_ON(min_page_size < mm->chunk_size);
GEM_BUG_ON(!IS_ALIGNED(size, min_page_size));
- if (place->fpfn + bman_res->base.num_pages != place->lpfn &&
+ if (place->fpfn + PFN_UP(bman_res->base.size) != place->lpfn &&
place->flags & TTM_PL_FLAG_CONTIGUOUS) {
unsigned long pages;
@@ -108,7 +108,7 @@ static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager *man,
goto err_free_blocks;
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
- u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
+ u64 original_size = (u64)bman_res->base.size;
drm_buddy_block_trim(mm,
original_size,
@@ -116,7 +116,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
}
if (lpfn <= bman->visible_size) {
- bman_res->used_visible_size = bman_res->base.num_pages;
+ bman_res->used_visible_size = PFN_UP(bman_res->base.size);
} else {
struct drm_buddy_block *block;
@@ -228,7 +228,7 @@ static bool i915_ttm_buddy_man_compatible(struct ttm_resource_manager *man,
if (!place->fpfn &&
place->lpfn == i915_ttm_buddy_man_visible_size(man))
- return bman_res->used_visible_size == res->num_pages;
+ return bman_res->used_visible_size == PFN_UP(res->size);
/* Check each drm buddy block individually */
list_for_each_entry(block, &bman_res->blocks, link) {
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..cf89d0c2a2d9 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -244,7 +244,7 @@ void intel_region_ttm_resource_free(struct
intel_memory_region *mem,
struct ttm_resource_manager *man = mem->region_private;
struct ttm_buffer_object mock_bo = {};
-
Re: [PATCH 4/6] drm/nouveau: fix’s on ttm_resource rework to use size_t type
Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
I'm not an expert for nouveau so it might be possible that we better use
bo->base.size instead of bo->resource->size at some places. But that can
be cleaned up later if anybody really cares.
Acked-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c| 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
11 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 126b3c6e12f9..16ca4a141866 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -532,7 +532,7 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
- ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.resource->num_pages, &nvbo->kmap);
+ ret = ttm_bo_kmap(&nvbo->bo, 0, PFN_UP(nvbo->bo.resource->size),
&nvbo->kmap);
ttm_bo_unreserve(&nvbo->bo);
return ret;
@@ -1236,7 +1236,7 @@ vm_fault_t nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
} else {
/* make sure bo is in mappable vram */
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
- bo->resource->start + bo->resource->num_pages < mappable)
+ bo->resource->start + PFN_UP(bo->resource->size) < mappable)
return 0;
for (i = 0; i < nvbo->placement.num_placement; ++i) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
index 7390132129fe..e2ce44adaa5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
@@ -52,7 +52,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
u32 src_offset = old_reg->start << PAGE_SHIFT;
u32 dst_ctxdma = nouveau_bo_mem_ctxdma(bo, chan, new_reg);
u32 dst_offset = new_reg->start << PAGE_SHIFT;
- u32 page_count = new_reg->num_pages;
+ u32 page_count = PFN_UP(new_reg->size);
int ret;
ret = PUSH_WAIT(push, 3);
@@ -62,7 +62,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
PUSH_MTHD(push, NV039, SET_CONTEXT_DMA_BUFFER_IN, src_ctxdma,
SET_CONTEXT_DMA_BUFFER_OUT, dst_ctxdma);
- page_count = new_reg->num_pages;
+ page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 2047) ? 2047 : page_count;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo5039.c b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
index 4c75c7b3804c..c6cf3629a9f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo5039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
@@ -41,7 +41,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
{
struct nouveau_mem *mem = nouveau_mem(old_reg);
struct nvif_push *push = chan->chan.push;
- u64 length = (new_reg->num_pages << PAGE_SHIFT);
+ u64 length = new_reg->size;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
int src_tiled = !!mem->kind;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
index ed6c09d67840..9b7ba31fae13 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
@@ -44,7 +44,7 @@ nv84_bo_move_exec(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
if (ret)
return ret;
- PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->num_pages << PAGE_SHIFT,
+ PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->size,
0x0308, upper_32_bits(mem->vma[0].addr),
0x030c, lower_32_bits(mem->vma[0].addr),
0x0310, upper_32_bits(mem->vma[1].addr),
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
index dec29b2d8bb2..a15a38a87a95 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
@@ -44,10 +44,10 @@ nva3_bo_move_copy(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
struct nvif_push *push = chan->chan.push;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
- u32 page_count = new_reg-
Re: [PATCH 5/6] drm/radeon: fix’s on ttm_resource rework to use size_t type
Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:
Fix the ttm_resource from num_pages to size_t size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 446f7bae54c4..4c930f0cf132 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -400,8 +400,8 @@ static int cmp_size_smaller_first(void *priv, const struct
list_head *a,
struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list,
tv.head);
/* Sort A before B if A is smaller. */
- return (int)la->robj->tbo.resource->num_pages -
- (int)lb->robj->tbo.resource->num_pages;
+ return (int)PFN_UP(la->robj->tbo.resource->size) -
+ (int)PFN_UP(lb->robj->tbo.resource->size);
I think you can drop the conversion and PFN_UP. What we need here is a
compare result. Something like this:
if (la->robj->tbo.resource->size > lb->robj->tbo.resource->size)
return 1;
if (la->robj->tbo.resource->size < lb->robj->tbo.resource->size)
return -1;
return 0;
And I think it makes more sense to use tbo.base.size here as well
instead of the resource size.
Regards,
Christian.
}
/**
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 00c33b24d5d3..710d04fcbea6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -232,7 +232,7 @@ int radeon_bo_kmap(struct radeon_bo *bo, void **ptr)
}
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
if (r) {
return r;
}
@@ -737,7 +737,7 @@ vm_fault_t radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
if (bo->resource->mem_type != TTM_PL_VRAM)
return 0;
- size = bo->resource->num_pages << PAGE_SHIFT;
+ size = bo->resource->size;
offset = bo->resource->start << PAGE_SHIFT;
if ((offset + size) <= rdev->mc.visible_vram_size)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index c9fed5f2b870..22676617e1a5 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -22,7 +22,7 @@ TRACE_EVENT(radeon_bo_create,
TP_fast_assign(
__entry->bo = bo;
- __entry->pages = bo->tbo.resource->num_pages;
+ __entry->pages = PFN_UP(bo->tbo.resource->size);
),
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d33fec488713..fff48306c05f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -181,7 +181,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
BUILD_BUG_ON((PAGE_SIZE % RADEON_GPU_PAGE_SIZE) != 0);
- num_pages = new_mem->num_pages * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
+ num_pages = PFN_UP(new_mem->size) * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
fence = radeon_copy(rdev, old_start, new_start, num_pages,
bo->base.resv);
if (IS_ERR(fence))
return PTR_ERR(fence);
@@ -268,7 +268,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
static int radeon_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
{
struct radeon_device *rdev = radeon_get_rdev(bdev);
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ size_t bus_size = (size_t)mem->size;
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
Re: [RFC PATCH v5 5/6] drm/tidss: Add IO CTRL and Power support for OLDI TX in am625
Hi Tomi
On 12-Oct-22 17:59, Tomi Valkeinen wrote:
On 28/09/2022 20:52, Aradhya Bhatia wrote:
The ctrl mmr module of the AM625 is different from the AM65X SoC. Thus
the ctrl mmr registers that supported the OLDI TX power have become
different in AM625 SoC.
Add IO CTRL support and control the OLDI TX power for AM625.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 55 ++--
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 6 +++
2 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 88008ad39b55..68444e0cd8d7 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -921,21 +921,52 @@ int dispc_vp_bus_check(struct dispc_device
*dispc, u32 hw_videoport,
static void dispc_oldi_tx_power(struct dispc_device *dispc, bool power)
{
- u32 val = power ? 0 : OLDI_PWRDN_TX;
+ u32 val;
if (WARN_ON(!dispc->oldi_io_ctrl))
return;
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
- OLDI_PWRDN_TX, val);
+ if (dispc->feat->subrev == DISPC_AM65X) {
+ val = power ? 0 : OLDI_PWRDN_TX;
+
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
+ OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
+ OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
+ OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
+ OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
+ OLDI_PWRDN_TX, val);
+
+ } else if (dispc->feat->subrev == DISPC_AM625) {
+ if (power) {
+ switch (dispc->oldi_mode) {
+ case OLDI_SINGLE_LINK_SINGLE_MODE:
+ /* Power down OLDI TX 1 */
+ val = OLDI1_PWRDN_TX;
+ break;
+
+ case OLDI_SINGLE_LINK_CLONE_MODE:
+ case OLDI_DUAL_LINK_MODE:
+ /* No Power down */
+ val = 0;
+ break;
+
+ default:
+ /* Power down both the OLDI TXes */
+ val = OLDI0_PWRDN_TX | OLDI1_PWRDN_TX;
+ break;
+ }
+ } else {
+ /* Power down both the OLDI TXes */
+ val = OLDI0_PWRDN_TX | OLDI1_PWRDN_TX;
+ }
Ugh, I hate power-down bits. So you "enable" it to disable it =). What's
the default value or the register here? Or will this always be called?
I.e. if we only use DPI, do we power down the OLDIs somewhere (or does
it matter)?
The power bits are defaulted to keep the OLDI TXes powered off, and they
have to be turned ON.
This function is also called to power off the OLDI TXes, from
dispc_vp_unprepare. And that happens with "power" variable as false. So
the else condition above is indeed required.
You are right about the other scenario though. If DPI is only used, the
mode will be set to OLDI_MODE_OFF and in that case, the dispc_vp_prepare
function will NOT be called for the OLDI VP thereby rendering the
"default" clause of the switch statement, for powering down the OLDIs,
essentially useless. I just put it there because of convention.
+
+ regmap_update_bits(dispc->oldi_io_ctrl, OLDI_PD_CTRL,
+ OLDI0_PWRDN_TX | OLDI1_PWRDN_TX, val);
+ }
}
static void dispc_set_num_datalines(struct dispc_device *dispc,
@@ -2831,7 +2862,7 @@ int dispc_init(struct tidss_device *tidss)
dispc->vp_data[i].gamma_table = gamma_table;
}
- if (feat->subrev == DISPC_AM65X) {
+ if (feat->subrev == DISPC_AM65X || feat->subrev == DISPC_AM625) {
r = dispc_init_am65x_oldi_io_ctrl(dev, dispc);
if (r)
return r;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
index 13feedfe5d6d..510bee70b3b8 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -238,6 +238,12 @@ enum dispc_common_regs {
#define OLDI_DAT3_IO_CTRL 0x0C
#define OLDI_CLK_IO_CTRL 0x10
+/* Only for AM625 OLDI TX */
+#define OLDI_PD_CTRL 0x100
+#define OLDI_LB_CTRL 0x104
+
#define OLDI_PWRDN_TX BIT(8)
+#define OLDI0_PWRDN_TX BIT(0)
+#define OLDI1_PWRDN_TX BIT(1)
Maybe these (the new and old ones) should be platfo
Re: [PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_
On Wed, Oct 19, 2022 at 06:21:34PM +0200, Eric Farman wrote: > /* > * Initialize a vfio_device so it can be registered to vfio core. > - * > - * Only vfio-ccw driver should call this interface. > */ > int vfio_init_device(struct vfio_device *device, struct device *dev, >const struct vfio_device_ops *ops) > @@ -422,7 +420,6 @@ int vfio_init_device(struct vfio_device *device, struct > device *dev, > ida_free(&vfio.device_ida, device->index); > return ret; > } > -EXPORT_SYMBOL_GPL(vfio_init_device); Should be made static as well Jason
Re: [PATCH v1 7/7] vfio: Remove vfio_free_device
On Wed, Oct 19, 2022 at 06:21:35PM +0200, Eric Farman wrote:
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
>
> Signed-off-by: Eric Farman
Reviewed-by: Jason Gunthorpe
Jason
Re: [PATCH v1 0/7] vfio-ccw parent rework
On Wed, Oct 19, 2022 at 06:21:28PM +0200, Eric Farman wrote: > This series attempts to address the oddities/shortcomings of vfio-ccw, such > that vfio-ccw can use the same helpers as everyone else, and the tricks that > were implemented by the other drivers can be removed. It is built on 6.1-rc1, > and thus includes the various changes [3][4] that have occurred in and around > these parts. It looks good to me if you are happy with the ccw part Thanks, Jason
