Re: [PATCH 1/3] drm/i915: Report steering details in debugfs
Hi Matt,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next drm/drm-next
next-20220310]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next
airlied/drm-next v5.17-rc8]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/i915-General-multicast-steering-updates/20220315-074349
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s001
(https://download.01.org/0day-ci/archive/20220315/202203151352.zdgy8h4m-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
#
https://github.com/0day-ci/linux/commit/cd773701a65fdee649b70395d226ba9b5f7d5d30
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Matt-Roper/i915-General-multicast-steering-updates/20220315-074349
git checkout cd773701a65fdee649b70395d226ba9b5f7d5d30
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gt/intel_gt.c:99:12: sparse: sparse: symbol
>> 'intel_steering_types' was not declared. Should it be static?
vim +/intel_steering_types +99 drivers/gpu/drm/i915/gt/intel_gt.c
98
> 99 const char *intel_steering_types[] = {
100 "L3BANK",
101 "MSLICE",
102 "LNCF",
103 };
104
---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 16/22] drm/tilcdc: Use drm_mode_copy()
On 18/02/2022 12:03, Ville Syrjala wrote:
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, )
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(, )
|
- memcpy(, E, S)
+ drm_mode_copy(, E)
)
@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 29890d704cb4..853c6b443fff 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -433,7 +433,7 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
set_scanout(crtc, fb);
- crtc->hwmode = crtc->state->adjusted_mode;
+ drm_mode_copy(>hwmode, >state->adjusted_mode);
tilcdc_crtc->hvtotal_us =
tilcdc_mode_hvtotal(>hwmode);
Reviewed-by: Tomi Valkeinen
Tomi
[PATCH v4] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)
Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.
Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.
Changes in V4:
- Pass boolean value to sspp blk based on supported rotations for each hw.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 187 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
4 files changed, 215 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..060bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_SC7280_MASK \
+ (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
};
+static const u32 rotation_v2_formats[] = {
+ DRM_FORMAT_NV12,
+ /* TODO add formats after validation */
+};
+
/*
* DPU sub blocks config
*/
@@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
*/
/* SSPP common configuration */
-
-#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
@@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+ .rotation_cfg = rot_cfg, \
}
#define _DMA_SBLK(num, sdma_pri) \
@@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
}
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
- _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
- _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
- _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
- _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3, NULL);
+
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+ .rot_maxheight = 1088,
+ .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+ .rot_format_list = rotation_v2_formats,
+};
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
- _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
- _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 6, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_2 =
- _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 7, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_3 =
- _VIG_SBLK("3", 8,
Re: [PATCH 00/30] fix typos in comments
Julia, > drivers/scsi/aic7xxx/aicasm/aicasm.c|2 +- > drivers/scsi/elx/libefc_sli/sli4.c |2 +- > drivers/scsi/lpfc/lpfc_mbox.c |2 +- > drivers/scsi/qla2xxx/qla_gs.c |2 +- Applied patches 2, 17, 24, and 25 to 5.18/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] drm/i915: Reduce stack usage in debugfs due to SSEU
From: John Harrison
sseu_dev_info is already a pretty large structure which will likely
continue to grow when future platforms increase potential DSS and EU
counts. Let's switch the stack placement of this structure in debugfs
with a dynamic allocation.
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 22 +---
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
index 6b944de48666..2d5d011e01db 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
{
struct drm_i915_private *i915 = gt->i915;
const struct intel_gt_info *info = >info;
- struct sseu_dev_info sseu;
+ struct sseu_dev_info *sseu;
intel_wakeref_t wakeref;
if (GRAPHICS_VER(i915) < 8)
@@ -258,23 +258,29 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
i915_print_sseu_info(m, true, HAS_POOLED_EU(i915), >sseu);
seq_puts(m, "SSEU Device Status\n");
- memset(, 0, sizeof(sseu));
- intel_sseu_set_info(, info->sseu.max_slices,
+
+ sseu = kzalloc(sizeof(*sseu), GFP_KERNEL);
+ if (!sseu)
+ return -ENOMEM;
+
+ intel_sseu_set_info(sseu, info->sseu.max_slices,
info->sseu.max_subslices,
info->sseu.max_eus_per_subslice);
with_intel_runtime_pm(>runtime_pm, wakeref) {
if (IS_CHERRYVIEW(i915))
- cherryview_sseu_device_status(gt, );
+ cherryview_sseu_device_status(gt, sseu);
else if (IS_BROADWELL(i915))
- bdw_sseu_device_status(gt, );
+ bdw_sseu_device_status(gt, sseu);
else if (GRAPHICS_VER(i915) == 9)
- gen9_sseu_device_status(gt, );
+ gen9_sseu_device_status(gt, sseu);
else if (GRAPHICS_VER(i915) >= 11)
- gen11_sseu_device_status(gt, );
+ gen11_sseu_device_status(gt, sseu);
}
- i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), );
+ i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), sseu);
+
+ kfree(sseu);
return 0;
}
--
2.34.1
Re: [PATCH v2 1/2] dt-bindings: pinctrl: aspeed: Update gfx node in example
On Tue, 15 Mar 2022 at 01:21, Linus Walleij wrote: > > On Fri, Mar 4, 2022 at 1:03 AM Joel Stanley wrote: > > > The example needs updating to match the to be added yaml bindings for > > the gfx node. > > > > Signed-off-by: Joel Stanley > > Reviewed-by: Linus Walleij > > I guess you will merge this elsewhere or shall I apply it to the pinctrl tree? Feel free to take this one. > > Yours, > Linus Walleij
Re: [PATCH v2 1/2] dt-bindings: pinctrl: aspeed: Update gfx node in example
On Fri, Mar 4, 2022 at 1:03 AM Joel Stanley wrote: > The example needs updating to match the to be added yaml bindings for > the gfx node. > > Signed-off-by: Joel Stanley Reviewed-by: Linus Walleij I guess you will merge this elsewhere or shall I apply it to the pinctrl tree? Yours, Linus Walleij
[PATCH 2/3] drm/i915/guc: add steering info to GuC register save/restore list
From: Daniele Ceraolo Spurio
GuC has its own steering mechanism and can't use the default set by i915,
so we need to provide the steering information that the FW will need to
save/restore registers while processing an engine reset. The GUC
interface allows us to do so as part of the register save/restore list
and it requires us to specify the steering for all multicast register, even
those that would be covered by the default setting for cpu access. Given
that we do not distinguish between registers that do not need steering and
registers that are guaranteed to work the default steering, we set the
steering for all entries in the guc list that do not require a special
steering (e.g. mslice) to the default settings; this will cost us a few
extra writes during engine reset but allows us to keep the steering
logic simple.
Cc: John Harrison
Cc: Matt Roper
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 29 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 54 +++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 3 ++
4 files changed, 73 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 041add4019fc..a5f01a8601e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -919,6 +919,35 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt,
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
}
+/**
+ * intel_gt_get_valid_steering_for_reg - get a valid steering for a register
+ * @gt: GT structure
+ * @reg: register for which the steering is required
+ * @sliceid: return variable for slice steering
+ * @subsliceid: return variable for subslice steering
+ *
+ * This function returns a slice/subslice pair that is guaranteed to work for
+ * read steering of the given register. Note that a value will be returned even
+ * if the register is not replicated and therefore does not actually require
+ * steering.
+ */
+void intel_gt_get_valid_steering_for_reg(struct intel_gt *gt, i915_reg_t reg,
+u8 *sliceid, u8 *subsliceid)
+{
+ int type;
+
+ for (type = 0; type < NUM_STEERING_TYPES; type++) {
+ if (intel_gt_reg_needs_read_steering(gt, reg, type)) {
+ intel_gt_get_valid_steering(gt, type, sliceid,
+ subsliceid);
+ return;
+ }
+ }
+
+ *sliceid = gt->default_steering.groupid;
+ *subsliceid = gt->default_steering.instanceid;
+}
+
u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg)
{
int type;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 3edece1865e4..996f8f3c17b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -84,6 +84,9 @@ static inline bool intel_gt_needs_read_steering(struct
intel_gt *gt,
return gt->steering_table[type];
}
+void intel_gt_get_valid_steering_for_reg(struct intel_gt *gt, i915_reg_t reg,
+u8 *sliceid, u8 *subsliceid);
+
u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index acc4a3766dc1..feb372fc0b48 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -276,15 +276,24 @@ __mmio_reg_add(struct temp_regset *regset, struct
guc_mmio_reg *reg)
return slot;
}
-static long __must_check guc_mmio_reg_add(struct temp_regset *regset,
- u32 offset, u32 flags)
+#define GUC_REGSET_STEERING(group, instance) ( \
+ FIELD_PREP(GUC_REGSET_STEERING_GROUP, (group)) | \
+ FIELD_PREP(GUC_REGSET_STEERING_INSTANCE, (instance)) | \
+ GUC_REGSET_NEEDS_STEERING \
+)
+
+static long __must_check guc_mmio_reg_add(struct intel_gt *gt,
+ struct temp_regset *regset,
+ i915_reg_t reg, u32 flags)
{
u32 count = regset->storage_used - (regset->registers -
regset->storage);
- struct guc_mmio_reg reg = {
+ u32 offset = i915_mmio_reg_offset(reg);
+ struct guc_mmio_reg entry = {
.offset = offset,
.flags = flags,
};
struct guc_mmio_reg *slot;
+ u8 group, inst;
/*
* The mmio list is built using separate lists within the driver.
@@ -292,11 +301,22 @@ static long __must_check guc_mmio_reg_add(struct
temp_regset *regset,
* register more than once. Do not consider this an error; silently
* move on if the register is already
[PATCH 3/3] drm/i915: Add support for steered register writes
Upcoming patches will need to steer writes to multicast registers as
well as reading them.
Although the setting of the 'multicast' bit should only really matter
for write operations (reads always operate in a unicast manner and give
us the result from one specific instance), Wa_22013088509 suggests that
we leave the multicast bit enabled when performing read operations, so
we follow suit here.
Cc: Harish Chegondi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 75 ++---
drivers/gpu/drm/i915/intel_uncore.h | 4 +-
3 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 19cd34f24263..62e0f075b1de 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -46,6 +46,7 @@
#define GEN8_MCR_SLICE_MASK GEN8_MCR_SLICE(3)
#define GEN8_MCR_SUBSLICE(subslice) (((subslice) & 3) << 24)
#define GEN8_MCR_SUBSLICE_MASK GEN8_MCR_SUBSLICE(3)
+#define GEN11_MCR_MULTICAST REG_BIT(31)
#define GEN11_MCR_SLICE(slice) (((slice) & 0xf) << 27)
#define GEN11_MCR_SLICE_MASK GEN11_MCR_SLICE(0xf)
#define GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) << 24)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index dd8fdd5863de..ef8ffc01ad19 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2464,17 +2464,46 @@ intel_uncore_forcewake_for_reg(struct intel_uncore
*uncore,
return fw_domains;
}
-u32 intel_uncore_read_with_mcr_steering_fw(struct intel_uncore *uncore,
- i915_reg_t reg,
- int slice, int subslice)
+/**
+ * uncore_rw_with_mcr_steering_fw - Access a register after programming
+ * the MCR selector register.
+ * @uncore: pointer to struct intel_uncore
+ * @reg: register being accessed
+ * @rw_flag: FW_REG_READ for read access or FW_REG_WRITE for write access
+ * @slice: slice number (ignored for multi-cast write)
+ * @subslice: sub-slice number (ignored for multi-cast write)
+ * @value: register value to be written (ignored for read)
+ *
+ * Return: 0 for write access. register value for read access.
+ *
+ * Caller needs to make sure the relevant forcewake wells are up.
+ */
+static u32 uncore_rw_with_mcr_steering_fw(struct intel_uncore *uncore,
+ i915_reg_t reg, u8 rw_flag,
+ int slice, int subslice, u32 value)
{
- u32 mcr_mask, mcr_ss, mcr, old_mcr, val;
+ u32 mcr_mask, mcr_ss, mcr, old_mcr, val = 0;
lockdep_assert_held(>lock);
if (GRAPHICS_VER(uncore->i915) >= 11) {
mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
mcr_ss = GEN11_MCR_SLICE(slice) | GEN11_MCR_SUBSLICE(subslice);
+
+ /*
+* Wa_22013088509
+*
+* The setting of the multicast/unicast bit usually wouldn't
+* matter for read operations (which always return the value
+* from a single register instance regardless of how that bit
+* is set), but some platforms have a workaround requiring us
+* to remain in multicast mode for reads. There's no real
+* downside to this, so we'll just go ahead and do so on all
+* platforms; we'll only clear the multicast bit from the mask
+* when exlicitly doing a write operation.
+*/
+ if (rw_flag == FW_REG_WRITE)
+ mcr_mask |= GEN11_MCR_MULTICAST;
} else {
mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
mcr_ss = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
@@ -2486,7 +2515,10 @@ u32 intel_uncore_read_with_mcr_steering_fw(struct
intel_uncore *uncore,
mcr |= mcr_ss;
intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
- val = intel_uncore_read_fw(uncore, reg);
+ if (rw_flag == FW_REG_READ)
+ val = intel_uncore_read_fw(uncore, reg);
+ else
+ intel_uncore_write_fw(uncore, reg, value);
mcr &= ~mcr_mask;
mcr |= old_mcr & mcr_mask;
@@ -2496,14 +2528,16 @@ u32 intel_uncore_read_with_mcr_steering_fw(struct
intel_uncore *uncore,
return val;
}
-u32 intel_uncore_read_with_mcr_steering(struct intel_uncore *uncore,
- i915_reg_t reg, int slice, int subslice)
+static u32 uncore_rw_with_mcr_steering(struct intel_uncore *uncore,
+ i915_reg_t reg, u8 rw_flag,
+ int
[PATCH 1/3] drm/i915: Report steering details in debugfs
Add a new 'steering' node in each gt's debugfs directory that tells
whether we're using explicit steering for various types of MCR ranges
and, if so, what MMIO ranges it applies to.
We're going to be transitioning away from implicit steering, even for
slice/dss steering soon, so the information reported here will become
increasingly valuable once that happens.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 46 +
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 13 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h| 5 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++-
5 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8a2483ccbfb9..041add4019fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -96,6 +96,12 @@ int intel_gt_assign_ggtt(struct intel_gt *gt)
return gt->ggtt ? 0 : -ENOMEM;
}
+const char *intel_steering_types[] = {
+ "L3BANK",
+ "MSLICE",
+ "LNCF",
+};
+
static const struct intel_mmio_range icl_l3bank_steering_table[] = {
{ 0x00B100, 0x00B3FF },
{},
@@ -932,6 +938,46 @@ u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t
reg)
return intel_uncore_read(gt->uncore, reg);
}
+static void report_steering_type(struct drm_printer *p,
+struct intel_gt *gt,
+enum intel_steering_type type,
+bool dump_table)
+{
+ const struct intel_mmio_range *entry;
+ u8 slice, subslice;
+
+ BUILD_BUG_ON(ARRAY_SIZE(intel_steering_types) != NUM_STEERING_TYPES);
+
+ if (!gt->steering_table[type]) {
+ drm_printf(p, "%s steering: uses default steering\n",
+ intel_steering_types[type]);
+ return;
+ }
+
+ intel_gt_get_valid_steering(gt, type, , );
+ drm_printf(p, "%s steering: sliceid=0x%x, subsliceid=0x%x\n",
+ intel_steering_types[type], slice, subslice);
+
+ if (!dump_table)
+ return;
+
+ for (entry = gt->steering_table[type]; entry->end; entry++)
+ drm_printf(p, "\t0x%06x - 0x%06x\n", entry->start, entry->end);
+}
+
+void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
+ bool dump_table)
+{
+ drm_printf(p, "Default steering: sliceid=0x%x, subsliceid=0x%x\n",
+ gt->default_steering.groupid,
+ gt->default_steering.instanceid);
+
+ if (HAS_MSLICES(gt->i915)) {
+ report_steering_type(p, gt, MSLICE, dump_table);
+ report_steering_type(p, gt, LNCF, dump_table);
+ }
+}
+
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 0f571c8ee22b..3edece1865e4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -87,6 +87,8 @@ static inline bool intel_gt_needs_read_steering(struct
intel_gt *gt,
u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
+void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
+ bool dump_table);
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index f103664b71d4..6f45b131a001 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -6,6 +6,7 @@
#include
#include "i915_drv.h"
+#include "intel_gt.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
#include "intel_gt_pm_debugfs.h"
@@ -57,10 +58,22 @@ static int __intel_gt_debugfs_reset_store(void *data, u64
val)
DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
__intel_gt_debugfs_reset_store, "%llu\n");
+static int steering_show(struct seq_file *m, void *data)
+{
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct intel_gt *gt = m->private;
+
+ intel_gt_report_steering(, gt, true);
+
+ return 0;
+}
+DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(steering);
+
static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
{
static const struct intel_gt_debugfs_file files[] = {
{ "reset", _fops, NULL },
+ { "steering", _fops },
};
intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
[PATCH 0/3] i915: General multicast steering updates
A few minor steering updates, mostly to prepare for other upcoming work. We'll soon be doing most of our steering explicitly, rather than relying on implicit steering as we do now, so reporting the steering assignments in debugfs will be helpful for debugging. We also have some features coming up soon that need to be able to issue unicast writes to a specific register instance. Finally, we need to inform the GuC about proper register steering so that it knows how to handle register save/restore operations. Daniele Ceraolo Spurio (1): drm/i915/guc: add steering info to GuC register save/restore list Matt Roper (2): drm/i915: Report steering details in debugfs drm/i915: Add support for steered register writes drivers/gpu/drm/i915/gt/intel_gt.c | 75 + drivers/gpu/drm/i915/gt/intel_gt.h | 5 ++ drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 13 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h| 5 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 54 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 3 + drivers/gpu/drm/i915/intel_uncore.c | 75 ++--- drivers/gpu/drm/i915/intel_uncore.h | 4 +- 10 files changed, 216 insertions(+), 27 deletions(-) -- 2.34.1
Re: [PATCH v2 8/8] drm/panfrost: Switch to generic memory shrinker
On 3/15/22 02:26, Alyssa Rosenzweig wrote: > On Tue, Mar 15, 2022 at 01:42:53AM +0300, Dmitry Osipenko wrote: >> Replace Panfrost's memory shrinker with a generic DRM memory shrinker. >> >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/gpu/drm/panfrost/Makefile | 1 - >> drivers/gpu/drm/panfrost/panfrost_device.h | 4 >> drivers/gpu/drm/panfrost/panfrost_drv.c| 19 ++- >> drivers/gpu/drm/panfrost/panfrost_gem.c| 27 ++ >> drivers/gpu/drm/panfrost/panfrost_gem.h| 9 >> drivers/gpu/drm/panfrost/panfrost_job.c| 22 +- >> 6 files changed, 40 insertions(+), 42 deletions(-) >> >> diff --git a/drivers/gpu/drm/panfrost/Makefile >> b/drivers/gpu/drm/panfrost/Makefile >> index b71935862417..ecf0864cb515 100644 >> --- a/drivers/gpu/drm/panfrost/Makefile >> +++ b/drivers/gpu/drm/panfrost/Makefile >> @@ -5,7 +5,6 @@ panfrost-y := \ >> panfrost_device.o \ >> panfrost_devfreq.o \ >> panfrost_gem.o \ >> -panfrost_gem_shrinker.o \ >> panfrost_gpu.o \ >> panfrost_job.o \ >> panfrost_mmu.o \ > > I'm not sure you actually deleted gem_shrinker anywhere in this patch? > Diff stat is too small. Indeed, I was also confused by the diffstat once noticed it after the patches were sent out. And yes, I missed to git-add the panfrost_gem_shrinker.c by accident. Good catch, thank you! I'll correct it in in the v3. Meanwhile, will be great if you or somebody else could test this Panfrost patch. I don't have any h/w with Mali on hands yet and only compile-tested it.
Re: [PATCH v2 8/8] drm/panfrost: Switch to generic memory shrinker
On Tue, Mar 15, 2022 at 01:42:53AM +0300, Dmitry Osipenko wrote: > Replace Panfrost's memory shrinker with a generic DRM memory shrinker. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/panfrost/Makefile | 1 - > drivers/gpu/drm/panfrost/panfrost_device.h | 4 > drivers/gpu/drm/panfrost/panfrost_drv.c| 19 ++- > drivers/gpu/drm/panfrost/panfrost_gem.c| 27 ++ > drivers/gpu/drm/panfrost/panfrost_gem.h| 9 > drivers/gpu/drm/panfrost/panfrost_job.c| 22 +- > 6 files changed, 40 insertions(+), 42 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/Makefile > b/drivers/gpu/drm/panfrost/Makefile > index b71935862417..ecf0864cb515 100644 > --- a/drivers/gpu/drm/panfrost/Makefile > +++ b/drivers/gpu/drm/panfrost/Makefile > @@ -5,7 +5,6 @@ panfrost-y := \ > panfrost_device.o \ > panfrost_devfreq.o \ > panfrost_gem.o \ > - panfrost_gem_shrinker.o \ > panfrost_gpu.o \ > panfrost_job.o \ > panfrost_mmu.o \ I'm not sure you actually deleted gem_shrinker anywhere in this patch? Diff stat is too small.
Re: [PATCH v3 8/8] drm: bridge: mcde_dsi: Switch to devm_drm_of_get_bridge
On Tue, Mar 8, 2022 at 9:27 AM Jagan Teki wrote: > devm_drm_of_get_bridge is capable of looking up the downstream > bridge and panel and trying to add a panel bridge if the panel > is found. > > Replace explicit finding calls with devm_drm_of_get_bridge. > > Cc: Linus Walleij > Signed-off-by: Jagan Teki > --- > Changes for v3: Allright v3 looks like it can work :) No time to test it on hardware right now, but: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel) wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been pretty clear that he won't accept patches that add
macros that works on one arch and warns on others anymore in i915 and
I figure even less so in drm code.
So we shouldn't try to move this out to drm. Instead we should
restrict the wbinvd() inside our driver to integrated and X86 only.
For discrete on all architectures we should be coherent and hence not
be needing wbinvd().
the warn is there to guarantee we don't forget a code path. However
simply adding the warning is the real issue: we should rather guarantee
we can't take that code path. I.e., as you said refactor the code to
guarantee it works on discrete without that logic.
$ git grep wbinvd_on_all_cpus -- drivers/gpu/drm/
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c: if (wbinvd_on_all_cpus())
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: * Currently we
just do a heavy handed wbinvd_on_all_cpus() here since
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: wbinvd_on_all_cpus();
It looks like we actually go through this on other discrete graphics. Is
this missing an update like s/IS_DG1/IS_DGFX/? Or should we be doing
something else?
drivers/gpu/drm/i915/gem/i915_gem_pm.c:#define wbinvd_on_all_cpus() \
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Those are for suspend. Revert ac05a22cd07a ("drm/i915/gem: Almagamate
clflushes on suspend")
or extract that part to a helper function and implement it differently
for arches != x86?
drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();
Probably take a similar approach to the suspend case?
drivers/gpu/drm/i915/gt/intel_ggtt.c: wbinvd_on_all_cpus();
For a helper function, I have a #define for all non x86 architecture
that gives a warn on [1] within drm_cache.h Or would it be better to
implement a helper function instead?
[1]. https://patchwork.freedesktop.org/patch/475750/?series=1=5
This one comes from 64b95df91f44 ("drm/i915: Assume exclusive access
to objects inside resume")
Shouldn't that be doing the invalidate if the write domain is
I915_GEM_DOMAIN_CPU
In the end I think the warning would be ok if it was the cherry on top,
to guarantee we don't take those paths. We should probably have a
warn_once() to avoid spamming the console. But we also have to rework
the code to guarantee we are the only ones who may eventually get that
warning, and not the end user.
Could we first add the helper function/#define for now, and rework the
code in a different patch series?
Lucas De Marchi
Thanks,
/Thomas
Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver
On 3/10/22 01:43, Dmitry Osipenko wrote: >> I think that, given virgl uses host storage, guest shrinker should be >> still useful.. so I think continue with this series. > Guest shrinker indeed will be useful for virgl today. I was already > questioning why virgl needs both host and guest storages, maybe it will > move to a host-only storage approach in the future. > > I think the variant with the timer expiration actually could be > interesting to try because it should allow host to purge its VM BOs by > itself, preventing host OOMs. While I was working on shrinker v2, I noticed that host-side allocation may take a significant time. So I decided to defer implementation of my idea of using timer-based expiration for host-only BOs. I'll need to examine it more. >> For host shrinker, I'll have to look more at when crosvm triggers >> balloon inflation. I could still go the MADV:WILLNEED_REPLACE >> approach instead, which does have the advantage of host kernel not >> relying on host userspace or vm having a chance to run in order to >> release pages. The downside (perhaps?) is it would be more specific >> to virtgpu-native-context and less so to virgl or venus (but I guess >> there doesn't currently exist a way for madvise to be useful for vk >> drivers). > I'll also take a look at what CrOS does, maybe it has some interesting > ideas. I looked at CrOS kernel and crosvm, and haven't noticed anything special there in regards to purging GPU's memory of VM on host-side memory pressure. If you'll find something, then please let me know. I sent out v2 of the shrinker series, but missed to CC you on it by accident, please find it here [1]. [1] https://lore.kernel.org/dri-devel/20220314224253.236359-1-dmitry.osipe...@collabora.com/T/#t
[PATCH v2 4/8] drm/virtio: Improve DMA API usage for shmem BOs
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's
GPU device for the DRM's device instead of the VirtIO-GPU device and drop
DMA-related hacks from the VirtIO-GPU driver.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 22 +++---
drivers/gpu/drm/virtio/virtgpu_drv.h| 5 +--
drivers/gpu/drm/virtio/virtgpu_kms.c| 7 ++--
drivers/gpu/drm/virtio/virtgpu_object.c | 56 +
drivers/gpu/drm/virtio/virtgpu_vq.c | 13 +++---
5 files changed, 37 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 5f25a8d15464..8449dad3e65c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -46,9 +46,9 @@ static int virtio_gpu_modeset = -1;
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, virtio_gpu_modeset, int, 0400);
-static int virtio_gpu_pci_quirk(struct drm_device *dev, struct virtio_device
*vdev)
+static int virtio_gpu_pci_quirk(struct drm_device *dev)
{
- struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
const char *pname = dev_name(>dev);
bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
char unique[20];
@@ -101,6 +101,7 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev,
struct virtio_device *vd
static int virtio_gpu_probe(struct virtio_device *vdev)
{
struct drm_device *dev;
+ struct device *dma_dev;
int ret;
if (drm_firmware_drivers_only() && virtio_gpu_modeset == -1)
@@ -109,18 +110,29 @@ static int virtio_gpu_probe(struct virtio_device *vdev)
if (virtio_gpu_modeset == 0)
return -EINVAL;
- dev = drm_dev_alloc(, >dev);
+ /*
+* If GPU's parent is a PCI device, then we will use this PCI device
+* for the DRM's driver device because GPU won't have PCI's IOMMU DMA
+* ops in this case since GPU device is sitting on a separate (from PCI)
+* virtio-bus.
+*/
+ if (!strcmp(vdev->dev.parent->bus->name, "pci"))
+ dma_dev = vdev->dev.parent;
+ else
+ dma_dev = >dev;
+
+ dev = drm_dev_alloc(, dma_dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
vdev->priv = dev;
if (!strcmp(vdev->dev.parent->bus->name, "pci")) {
- ret = virtio_gpu_pci_quirk(dev, vdev);
+ ret = virtio_gpu_pci_quirk(dev);
if (ret)
goto err_free;
}
- ret = virtio_gpu_init(dev);
+ ret = virtio_gpu_init(vdev, dev);
if (ret)
goto err_free;
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 0a194aaad419..b2d93cb12ebf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -100,8 +100,6 @@ struct virtio_gpu_object {
struct virtio_gpu_object_shmem {
struct virtio_gpu_object base;
- struct sg_table *pages;
- uint32_t mapped;
};
struct virtio_gpu_object_vram {
@@ -214,7 +212,6 @@ struct virtio_gpu_drv_cap_cache {
};
struct virtio_gpu_device {
- struct device *dev;
struct drm_device *ddev;
struct virtio_device *vdev;
@@ -282,7 +279,7 @@ extern struct drm_ioctl_desc
virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
/* virtgpu_kms.c */
-int virtio_gpu_init(struct drm_device *dev);
+int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev);
void virtio_gpu_deinit(struct drm_device *dev);
void virtio_gpu_release(struct drm_device *dev);
int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 3313b92db531..0d1e3eb61bee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -110,7 +110,7 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->num_capsets = num_capsets;
}
-int virtio_gpu_init(struct drm_device *dev)
+int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev)
{
static vq_callback_t *callbacks[] = {
virtio_gpu_ctrl_ack, virtio_gpu_cursor_ack
@@ -123,7 +123,7 @@ int virtio_gpu_init(struct drm_device *dev)
u32 num_scanouts, num_capsets;
int ret = 0;
- if (!virtio_has_feature(dev_to_virtio(dev->dev), VIRTIO_F_VERSION_1))
+ if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
return -ENODEV;
vgdev =
[PATCH v2 8/8] drm/panfrost: Switch to generic memory shrinker
Replace Panfrost's memory shrinker with a generic DRM memory shrinker.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h | 4
drivers/gpu/drm/panfrost/panfrost_drv.c| 19 ++-
drivers/gpu/drm/panfrost/panfrost_gem.c| 27 ++
drivers/gpu/drm/panfrost/panfrost_gem.h| 9
drivers/gpu/drm/panfrost/panfrost_job.c| 22 +-
6 files changed, 40 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index b71935862417..ecf0864cb515 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -5,7 +5,6 @@ panfrost-y := \
panfrost_device.o \
panfrost_devfreq.o \
panfrost_gem.o \
- panfrost_gem_shrinker.o \
panfrost_gpu.o \
panfrost_job.o \
panfrost_mmu.o \
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 8b25278f34c8..fe04b21fc044 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -115,10 +115,6 @@ struct panfrost_device {
atomic_t pending;
} reset;
- struct mutex shrinker_lock;
- struct list_head shrinker_list;
- struct shrinker shrinker;
-
struct panfrost_devfreq pfdevfreq;
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b6f0a19c83..b014dadcf51f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -160,7 +160,6 @@ panfrost_lookup_bos(struct drm_device *dev,
break;
}
- atomic_inc(>gpu_usecount);
job->mappings[i] = mapping;
}
@@ -390,7 +389,6 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
void *data,
{
struct panfrost_file_priv *priv = file_priv->driver_priv;
struct drm_panfrost_madvise *args = data;
- struct panfrost_device *pfdev = dev->dev_private;
struct drm_gem_object *gem_obj;
struct panfrost_gem_object *bo;
int ret = 0;
@@ -403,7 +401,6 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
void *data,
bo = to_panfrost_bo(gem_obj);
- mutex_lock(>shrinker_lock);
mutex_lock(>mappings.lock);
if (args->madv == PANFROST_MADV_DONTNEED) {
struct panfrost_gem_mapping *first;
@@ -429,17 +426,8 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
void *data,
args->retained = drm_gem_shmem_madvise(>base, args->madv);
- if (args->retained) {
- if (args->madv == PANFROST_MADV_DONTNEED)
- list_add_tail(>base.madv_list,
- >shrinker_list);
- else if (args->madv == PANFROST_MADV_WILLNEED)
- list_del_init(>base.madv_list);
- }
-
out_unlock_mappings:
mutex_unlock(>mappings.lock);
- mutex_unlock(>shrinker_lock);
drm_gem_object_put(gem_obj);
return ret;
@@ -570,9 +558,6 @@ static int panfrost_probe(struct platform_device *pdev)
ddev->dev_private = pfdev;
pfdev->ddev = ddev;
- mutex_init(>shrinker_lock);
- INIT_LIST_HEAD(>shrinker_list);
-
err = panfrost_device_init(pfdev);
if (err) {
if (err != -EPROBE_DEFER)
@@ -594,7 +579,7 @@ static int panfrost_probe(struct platform_device *pdev)
if (err < 0)
goto err_out1;
- panfrost_gem_shrinker_init(ddev);
+ drm_gem_shmem_shrinker_register(ddev);
return 0;
@@ -612,8 +597,8 @@ static int panfrost_remove(struct platform_device *pdev)
struct panfrost_device *pfdev = platform_get_drvdata(pdev);
struct drm_device *ddev = pfdev->ddev;
+ drm_gem_shmem_shrinker_unregister(ddev);
drm_dev_unregister(ddev);
- panfrost_gem_shrinker_cleanup(ddev);
pm_runtime_get_sync(pfdev->dev);
pm_runtime_disable(pfdev->dev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 293e799e2fe8..d164d05ed84e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -19,16 +19,6 @@ static void panfrost_gem_free_object(struct drm_gem_object
*obj)
struct panfrost_gem_object *bo = to_panfrost_bo(obj);
struct panfrost_device *pfdev = obj->dev->dev_private;
- /*
-* Make sure the BO is no longer inserted in the shrinker list before
-* taking care of the destruction itself. If we don't do that we have a
-* race condition between this function and what's done in
-* panfrost_gem_shrinker_scan().
-*/
- mutex_lock(>shrinker_lock);
- list_del_init(>base.madv_list);
[PATCH v2 7/8] drm/virtio: Support memory shrinking
Add memory shrinker support and new madvise IOCTL to the VirtIO-GPU
driver. Userspace (BO cache manager of Mesa driver) will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs
on OOM, thus shrinker will lower memory pressure and prevent OOM kills.
For the starter only support of handling guest-side memory pressure is
implemented.
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 21 +-
drivers/gpu/drm/virtio/virtgpu_gem.c| 96 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 37 ++
drivers/gpu/drm/virtio/virtgpu_kms.c| 10 +++
drivers/gpu/drm/virtio/virtgpu_object.c | 22 ++
drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
drivers/gpu/drm/virtio/virtgpu_vq.c | 15
include/uapi/drm/virtgpu_drm.h | 14
8 files changed, 229 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b2d93cb12ebf..86e5c7b83ec5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -94,6 +94,9 @@ struct virtio_gpu_object {
int uuid_state;
uuid_t uuid;
+
+ /* object's backing memory will stay pinned while count > 0 */
+ unsigned int mem_pin_count;
};
#define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, base.base)
@@ -261,6 +264,9 @@ struct virtio_gpu_device {
spinlock_t resource_export_lock;
/* protects map state and host_visible_mm */
spinlock_t host_visible_lock;
+
+ /* protects all memory management operations */
+ struct mutex mm_lock;
};
struct virtio_gpu_fpriv {
@@ -274,7 +280,7 @@ struct virtio_gpu_fpriv {
};
/* virtgpu_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 12
+#define DRM_VIRTIO_NUM_IOCTLS 13
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
@@ -310,6 +316,13 @@ void virtio_gpu_array_put_free(struct
virtio_gpu_object_array *objs);
void virtio_gpu_array_put_free_delayed(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object_array *objs);
void virtio_gpu_array_put_free_work(struct work_struct *work);
+int virtio_gpu_array_validate(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object_array *objs);
+int virtio_gpu_gem_host_mem_release(struct virtio_gpu_object *bo);
+bool virtio_gpu_gem_madvise(struct virtio_gpu_object *obj, int madv);
+int virtio_gpu_gem_pin(struct virtio_gpu_object *bo);
+void virtio_gpu_gem_unpin(struct virtio_gpu_object *bo);
+bool virtio_gpu_gem_is_pinned(struct virtio_gpu_object *bo);
/* virtgpu_vq.c */
int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev);
@@ -321,6 +334,8 @@ void virtio_gpu_cmd_create_resource(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_fence *fence);
void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo);
+int virtio_gpu_cmd_release_resource(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo);
void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
uint64_t offset,
uint32_t width, uint32_t height,
@@ -483,4 +498,8 @@ void virtio_gpu_vram_unmap_dma_buf(struct device *dev,
struct sg_table *sgt,
enum dma_data_direction dir);
+/* virtgpu_gem_shrinker.c */
+int virtio_gpu_gem_shrinker_init(struct virtio_gpu_device *vgdev);
+void virtio_gpu_gem_shrinker_fini(struct virtio_gpu_device *vgdev);
+
#endif
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 48d3c9955f0d..62cdc00f3009 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -282,3 +282,99 @@ void virtio_gpu_array_put_free_work(struct work_struct
*work)
}
spin_unlock(>obj_free_lock);
}
+
+int virtio_gpu_array_validate(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object_array *objs)
+{
+ struct drm_gem_shmem_object *shmem;
+ int ret = 0;
+ u32 i;
+
+ mutex_lock(>mm_lock);
+
+ for (i = 0; i < objs->nents; i++) {
+ shmem = to_drm_gem_shmem_obj(objs->objs[i]);
+ if (shmem->madv) {
+ ret = -ENOMEM;
+ break;
+ }
+ }
+
+ mutex_unlock(>mm_lock);
+
+ return ret;
+}
+
+bool virtio_gpu_gem_madvise(struct virtio_gpu_object *bo, int madv)
+{
+ struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
+ bool retained;
+
+ /*
+* For now
[PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
Introduce a common DRM SHMEM shrinker. It allows to reduce code
duplication among DRM drivers, it also handles complicated lockings
for the drivers. This is initial version of the shrinker that covers
basic needs of GPU drivers.
This patch is based on a couple ideas borrowed from Rob's Clark MSM
shrinker and Thomas' Zimmermann variant of SHMEM shrinker.
GPU drivers that want to use generic DRM memory shrinker must support
generic GEM reservations.
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 194 +
include/drm/drm_device.h | 4 +
include/drm/drm_gem.h | 11 ++
include/drm/drm_gem_shmem_helper.h | 25
4 files changed, 234 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 37009418cd28..35be2ee98f11 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -139,6 +139,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
+ /* take out shmem GEM object from the memory shrinker */
+ drm_gem_shmem_madvise(shmem, 0);
+
WARN_ON(shmem->vmap_use_count);
if (obj->import_attach) {
@@ -163,6 +166,42 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object *shmem)
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
+static void drm_gem_shmem_update_purgeable_status(struct drm_gem_shmem_object
*shmem)
+{
+ struct drm_gem_object *obj = >base;
+ struct drm_gem_shmem_shrinker *gem_shrinker = obj->dev->shmem_shrinker;
+ size_t page_count = obj->size >> PAGE_SHIFT;
+
+ if (!gem_shrinker || obj->import_attach || !obj->funcs->purge)
+ return;
+
+ mutex_lock(>vmap_lock);
+ mutex_lock(>pages_lock);
+ mutex_lock(_shrinker->lock);
+
+ if (shmem->madv < 0) {
+ list_del_init(>madv_list);
+ goto unlock;
+ } else if (shmem->madv > 0) {
+ if (!list_empty(>madv_list))
+ goto unlock;
+
+ WARN_ON(gem_shrinker->shrinkable_count + page_count <
page_count);
+ gem_shrinker->shrinkable_count += page_count;
+
+ list_add_tail(>madv_list, _shrinker->lru);
+ } else if (!list_empty(>madv_list)) {
+ list_del_init(>madv_list);
+
+ WARN_ON(gem_shrinker->shrinkable_count < page_count);
+ gem_shrinker->shrinkable_count -= page_count;
+ }
+unlock:
+ mutex_unlock(_shrinker->lock);
+ mutex_unlock(>pages_lock);
+ mutex_unlock(>vmap_lock);
+}
+
static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
@@ -366,6 +405,8 @@ int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
ret = drm_gem_shmem_vmap_locked(shmem, map);
mutex_unlock(>vmap_lock);
+ drm_gem_shmem_update_purgeable_status(shmem);
+
return ret;
}
EXPORT_SYMBOL(drm_gem_shmem_vmap);
@@ -409,6 +450,8 @@ void drm_gem_shmem_vunmap(struct drm_gem_shmem_object
*shmem,
mutex_lock(>vmap_lock);
drm_gem_shmem_vunmap_locked(shmem, map);
mutex_unlock(>vmap_lock);
+
+ drm_gem_shmem_update_purgeable_status(shmem);
}
EXPORT_SYMBOL(drm_gem_shmem_vunmap);
@@ -451,6 +494,8 @@ int drm_gem_shmem_madvise(struct drm_gem_shmem_object
*shmem, int madv)
mutex_unlock(>pages_lock);
+ drm_gem_shmem_update_purgeable_status(shmem);
+
return (madv >= 0);
}
EXPORT_SYMBOL(drm_gem_shmem_madvise);
@@ -763,6 +808,155 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
*dev,
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
+static struct drm_gem_shmem_shrinker *
+to_drm_shrinker(struct shrinker *shrinker)
+{
+ return container_of(shrinker, struct drm_gem_shmem_shrinker, base);
+}
+
+static unsigned long
+drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
+struct shrink_control *sc)
+{
+ struct drm_gem_shmem_shrinker *gem_shrinker = to_drm_shrinker(shrinker);
+ u64 count = gem_shrinker->shrinkable_count;
+
+ if (count >= SHRINK_EMPTY)
+ return SHRINK_EMPTY - 1;
+
+ return count ?: SHRINK_EMPTY;
+}
+
+static unsigned long
+drm_gem_shmem_shrinker_scan_objects(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ struct drm_gem_shmem_shrinker *gem_shrinker = to_drm_shrinker(shrinker);
+ struct drm_gem_shmem_object *shmem;
+ struct list_head still_in_list;
+ bool lock_contention = true;
+ struct drm_gem_object *obj;
+ unsigned long freed = 0;
+
+ INIT_LIST_HEAD(_in_list);
+
+ mutex_lock(_shrinker->lock);
+
+ while (freed < sc->nr_to_scan) {
+ shmem = list_first_entry_or_null(_shrinker->lru,
+
[PATCH v2 5/8] drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table()
drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
Correct the doc comment which says that it returns NULL on error.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 8ad0e02991ca..37009418cd28 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -662,7 +662,7 @@ EXPORT_SYMBOL(drm_gem_shmem_print_info);
* drm_gem_shmem_get_pages_sgt() instead.
*
* Returns:
- * A pointer to the scatter/gather table of pinned pages or NULL on failure.
+ * A pointer to the scatter/gather table of pinned pages or errno on failure.
*/
struct sg_table *drm_gem_shmem_get_sg_table(struct drm_gem_shmem_object *shmem)
{
--
2.35.1
[PATCH v2 3/8] drm/virtio: Unlock GEM reservations in error code path
Unlock reservations in the error code path of virtio_gpu_object_create()
to silence debug warning splat produced by ww_mutex_destroy(>lock)
when GEM is released with the held lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index bea7806a3ae3..0b8cbb87f8d8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -250,6 +250,8 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
ret = virtio_gpu_object_shmem_init(vgdev, bo, , );
if (ret != 0) {
+ if (fence)
+ virtio_gpu_array_unlock_resv(objs);
virtio_gpu_array_put_free(objs);
virtio_gpu_free_object(_obj->base);
return ret;
--
2.35.1
[PATCH v2 2/8] drm/virtio: Check whether transferred 2D BO is shmem
Transferred 2D BO always must be a shmem BO. Add check for that to prevent NULL dereference if userspace passes a VRAM BO. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 7c052efe8836..2edf31806b74 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -595,7 +595,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev, bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); - if (use_dma_api) + if (virtio_gpu_is_shmem(bo) && use_dma_api) dma_sync_sgtable_for_device(vgdev->vdev->dev.parent, shmem->pages, DMA_TO_DEVICE); -- 2.35.1
[PATCH v2 1/8] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling
drm_gem_shmem_get_sg_table() never ever returned NULL on error. Correct
the error handling to avoid crash on OOM.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_object.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index f293e6ad52da..bea7806a3ae3 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -168,9 +168,11 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
* since virtio_gpu doesn't support dma-buf import from other devices.
*/
shmem->pages = drm_gem_shmem_get_sg_table(>base);
- if (!shmem->pages) {
+ ret = PTR_ERR(shmem->pages);
+ if (ret) {
drm_gem_shmem_unpin(>base);
- return -EINVAL;
+ shmem->pages = NULL;
+ return ret;
}
if (use_dma_api) {
--
2.35.1
[PATCH v2 0/8] Add memory shrinker to VirtIO-GPU DRM driver
Hello, This patchset introduces memory shrinker for the VirtIO-GPU DRM driver. During OOM, the shrinker will release BOs that are marked as "not needed" by userspace using the new madvise IOCTL. The userspace in this case is the Mesa VirGL driver, it will mark the cached BOs as "not needed", allowing kernel driver to release memory of the cached shmem BOs on lowmem situations, preventing OOM kills. This patchset includes couple fixes for problems of VirtIO-GPU driver that I found while was working on the shrinker, it also includes prerequisite DMA API usage improvement needed by the shrinker. The Mesa and IGT patches will be kept on hold until this kernel series will be approved and applied. This patchset was tested using Qemu and crosvm, including both cases of IOMMU off/on. Note that this patchset only enables initial shrinking of the guest memory, shrinking of the host memory is unsupported yet. Mesa: https://gitlab.freedesktop.org/digetx/mesa/-/commits/virgl-madvise IGT: https://gitlab.freedesktop.org/digetx/igt-gpu-tools/-/tree/virtio-madvise Changelog: v2: - Improved shrinker by using a more fine-grained locking to reduce contention during scan of objects and dropped locking from the 'counting' callback by tracking count of shrinkable pages. This was suggested by Rob Clark in the comment to v1. - Factored out common shrinker code into drm_gem_shmem_helper.c and switched Panfrost driver to use the new common memory shrinker. This was proposed by Thomas Zimmermann in his prototype series that he shared with us in the comment to v1. Note that I only compile-tested the Panfrost driver. - Shrinker now takes object_name_lock during scan to prevent racing with dma-buf exporting. - Shrinker now takes vmap_lock during scan to prevent racing with shmem vmap/unmap code. - Added "Correct doc-comment of drm_gem_shmem_get_sg_table()" patch, which I sent out previously as a standalone change, since the drm_gem_shmem_helper.c is now touched by this patchset anyways and it doesn't hurt to group all the patches together. Dmitry Osipenko (8): drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling drm/virtio: Check whether transferred 2D BO is shmem drm/virtio: Unlock GEM reservations in error code path drm/virtio: Improve DMA API usage for shmem BOs drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table() drm/shmem-helper: Add generic memory shrinker drm/virtio: Support memory shrinking drm/panfrost: Switch to generic memory shrinker drivers/gpu/drm/drm_gem_shmem_helper.c | 196 - drivers/gpu/drm/panfrost/Makefile | 1 - drivers/gpu/drm/panfrost/panfrost_device.h | 4 - drivers/gpu/drm/panfrost/panfrost_drv.c| 19 +- drivers/gpu/drm/panfrost/panfrost_gem.c| 27 +-- drivers/gpu/drm/panfrost/panfrost_gem.h| 9 - drivers/gpu/drm/panfrost/panfrost_job.c| 22 ++- drivers/gpu/drm/virtio/virtgpu_drv.c | 22 ++- drivers/gpu/drm/virtio/virtgpu_drv.h | 26 ++- drivers/gpu/drm/virtio/virtgpu_gem.c | 96 ++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 37 drivers/gpu/drm/virtio/virtgpu_kms.c | 17 +- drivers/gpu/drm/virtio/virtgpu_object.c| 78 drivers/gpu/drm/virtio/virtgpu_plane.c | 17 +- drivers/gpu/drm/virtio/virtgpu_vq.c| 30 +++- include/drm/drm_device.h | 4 + include/drm/drm_gem.h | 11 ++ include/drm/drm_gem_shmem_helper.h | 25 +++ include/uapi/drm/virtgpu_drm.h | 14 ++ 19 files changed, 544 insertions(+), 111 deletions(-) -- 2.35.1
Parallel modesets and private state objects broken, where to go with MST?
Hi! First a little bit of background: I've recently been trying to get rid of all of the non-atomic payload bandwidth management code in the MST helpers in order to make it easier to implement DSC and fallback link rate retraining support down the line. Currently bandwidth information is stored in two places, partially in the MST atomic state and partially in the mst manager's payload table (which exists outside of the atomic state and has its own locking). The portions in the atomic state are used to try to determine if a given display configuration can fit within the given bandwidth limitations during the atomic check phase, and are implemented through the use of private state objects. My current goal has been to move as much of this as possible over to the atomic state and entirely get rid of the payload table along with it's locks. My main reason for doing this is that it both decomplicates things quite a bit, and I'm really also hoping that getting rid of that payload code will make it clearer to others how it works - and stop the influx of bandaid patches (e.g. adding more and more special cases to MST to fix poorly understood issues being hit in one specific driver and nowhere else) that I've had to spend way more time then I'd like trying to investigate and review. So, the actual problem: following a conversation with Daniel Vetter today I've gotten the impression that private modesetting objects are basically just broken with parallel modesets? I'm still wrapping my head around all of this honestly, but from what I've gathered: CRTC atomic infra knows how to do waits in the proper places for when other CRTCs need to be waited on to continue a modeset, but there's no such tracking with private objects. If I understand this correctly, that means that even if two CRTC modesets require pulling in the same private object state for the MST mgr: we're only provided a guarantee that the atomic checks pulling in that private object state won't concurrently. But when it comes to commits, it doesn't sound like there's any actual tracking for this and as such - two CRTC modesets which have both pulled in the MST private state object are not prevented from running concurrently. This unfortunately throws an enormous wrench into the MST atomic conversion I've been working on - as I was under the understanding while writing the code for this that all objects in an atomic state are blocked from being used in any new atomic commits (not checks, as parallel checks should be fine in my case) until there's no commits active with said object pulled into the atomic state. I certainly am not aware of any way parallel modesetting could actually be supported on MST, so it's not really a feature we want to deal with at all besides stopping it from happening. This also unfortunately means that the current atomic modesetting code we have for MST is potentially broken, although I assume we've never hit any real world issues with it because of the non-atomic locking we currently have for the payload table. So, Daniel had mentioned that supposedly you've been dealing with similar issues with VC4 and might have already made progress on coming up with ways to deal with it. If this is all correct, I'd definitely appreciate being able to take a look at your work on this to see how I can help move things forward. I've got a WIP of my atomic only MST branch as well: https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1 However it's very certainly broken right now (it compiles and I had thought it worked already, but I realized I totally forgot to come up with a way of doing bookkeeping for VC start slots atomically - which is what led me down this current rabbit hole), but it should at least give a general idea of what I'm trying to do. Anyway, let me know what you think. -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 00/22] drm: Review of mode copies
On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote: > drm: Add drm_mode_init() > drm/bridge: Use drm_mode_copy() > drm/imx: Use drm_mode_duplicate() > drm/panel: Use drm_mode_duplicate() > drm/vc4: Use drm_mode_copy() These have been pushed to drm-misc-next. > drm/amdgpu: Remove pointless on stack mode copies > drm/amdgpu: Use drm_mode_init() for on-stack modes > drm/amdgpu: Use drm_mode_copy() amdgpu ones are reviewed, but I'll leave them for the AMD folks to push to whichever tree they prefer. The rest are still in need of review: > drm/radeon: Use drm_mode_copy() > drm/gma500: Use drm_mode_copy() > drm/hisilicon: Use drm_mode_init() for on-stack modes > drm/msm: Nuke weird on stack mode copy > drm/msm: Use drm_mode_init() for on-stack modes > drm/msm: Use drm_mode_copy() > drm/mtk: Use drm_mode_init() for on-stack modes > drm/rockchip: Use drm_mode_copy() > drm/sti: Use drm_mode_copy() > drm/tilcdc: Use drm_mode_copy() > drm/i915: Use drm_mode_init() for on-stack modes > drm/i915: Use drm_mode_copy() > drm: Use drm_mode_init() for on-stack modes > drm: Use drm_mode_copy() -- Ville Syrjälä Intel
Re: [RFC PATCH 1/6] dt-bindings: display: imx: Add EPDC
On Sat, 12 Mar 2022 20:23:48 +0100
Jonathan Neuschäfer wrote:
> Hello Andreas,
>
> Sorry for the delay, I finally got around to having a look at the
> patchset.
>
> Some comments from skimming the patches below, and in my other replies.
>
>
> On Sun, Feb 06, 2022 at 09:00:11AM +0100, Andreas Kemnade wrote:
> > Add a binding for the Electrophoretic Display Controller found at least
> > in the i.MX6.
> > The timing subnode is directly here to avoid having display parameters
> > spread all over the plate.
> >
> > Supplies are organized the same way as in the fbdev driver in the
> > NXP/Freescale kernel forks. The regulators used for that purpose,
> > like the TPS65185, the SY7636A and MAX17135 have typically a single bit to
> > start a bunch of regulators of higher or negative voltage with a
> > well-defined timing. VCOM can be handled separately, but can also be
> > incorporated into that single bit.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > .../bindings/display/imx/fsl,mxc-epdc.yaml| 159 ++
> > 1 file changed, 159 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > new file mode 100644
> > index ..7e0795cc3f70
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> > @@ -0,0 +1,159 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> [...]
> > + - vscan-holdoff
> > + - sdoed-width
> > + - sdoed-delay
> > + - sdoez-width
> > + - sdoez-delay
> > + - gdclk-hp-offs
> > + - gdsp-offs
> > + - gdoe-offs
> > + - gdclk-offs
> > + - num-ce
>
> These parameters should perhaps have sane defaults in the driver, and be
> optional in the DT.
>
First of all I think I should document them better (as said in an
earlier review mail)
I doubt there are sane defaults, in vendor kernels, there is typically a
definition of these parameters and a video mode per display.
>
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +epdc: epdc@20f4000 {
> [...]
> > +
> > +timing {
> > +clock-frequency = <8000>;
> > +hactive = <1448>;
> > +hback-porch = <16>;
> > +hfront-porch = <102>;
> > +hsync-len = <28>;
> > +vactive = <1072>;
> > +vback-porch = <4>;
> > +vfront-porch = <4>;
> > +vsync-len = <2>;
> > +};
> > +};
>
> The way you did it here, the timing parameters are directly under the
> EPDC node in the DT, but I wonder if it would be better to have a
> separate node for the display panel, which can then provide the timing
> parameters either in the DT or in the panel driver (selected by compatible
> string of the panel).
>
IMHO it makes sense to store these timing parameters together with the
timing parameters from above. If that all somehow comes from a panel
driver, we need to design an interface for it. So for simplicity I
added the stuff just to the EPDC node.
Vendor kernel has this:
struct imx_epdc_fb_mode {
struct fb_videomode *vmode;
int vscan_holdoff;
int sdoed_width;
int sdoed_delay;
int sdoez_width;
int sdoez_delay;
int gdclk_hp_offs;
int gdsp_offs;
int gdoe_offs;
int gdclk_offs;
int num_ce;
};
So things are basically combined here.
Regards,
Andreas
Re: BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_vblanks()
On 3/11/22 17:22, Maxime Ripard wrote: > Hi Dmitry, > > On Thu, Mar 10, 2022 at 03:33:07AM +0300, Dmitry Osipenko wrote: >> I was playing/testing SuperTuxKart using VirtIO-GPU driver and spotted a >> UAF bug in drm_atomic_helper_wait_for_vblanks(). >> >> SuperTuxKart can use DRM directly, i.e. you can run game in VT without >> Xorg or Wayland, this is where bugs happens. SuperTuxKart uses a >> non-blocking atomic page flips and UAF happens when a new atomic state >> is committed while there is a previous page flip still in-fly. >> >> What happens is that the new and old atomic states refer to the same >> CRTC state somehow. Once the older atomic state is destroyed, the CRTC >> state is freed and the newer atomic state continues to use the freed >> CRTC state. > > I'm not sure what you mean by "the new and old atomic states refer to > the same CRTC state", are those the same pointers? Yes, the pointers are the same. I'd assume that the newer atomic state should duplicate CRTC state, but apparently it doesn't happen. >> The bug is easily reproducible (at least by me) by playing SuperTuxKart >> for a minute. It presents on latest -next and 5.17-rc7, I haven't >> checked older kernel versions. >> >> I'm not an expert of the non-blocking code paths in DRM, so asking for >> suggestions about where the root of the problem could be. > > Does it occur with other platforms? Can you easily test on something else? Shouldn't be easy to replicate this on other platforms, but I'll try.
Re: [PATCH 2/5] dyndbg: add class_id field and query support
On 3/11/22 20:06, jim.cro...@gmail.com wrote:
> On Fri, Mar 11, 2022 at 12:06 PM Jason Baron wrote:
>>
>>
>>
>> On 3/10/22 23:47, Jim Cromie wrote:
>>> DRM defines/uses 10 enum drm_debug_category's to create exclusive
>>> classes of debug messages. To support this directly in dynamic-debug,
>>> add the following:
>>>
>>> - struct _ddebug.class_id:4 - 4 bits is enough
>>> - define _DPRINTK_SITE_UNCLASSED 15 - see below
>>>
>>> and the query support:
>>> - struct _ddebug_query.class_id
>>> - ddebug_parse_query - looks for "class" keyword, then calls..
>>> - parse_class - accepts uint: 0-15, sets query.class_id and marker
>>> - vpr_info_dq - displays new field
>>> - ddebug_proc_show- append column with "cls:%d" if !UNCLASSED
>>>
>>> With the patch, one can enable current/unclassed callsites by:
>>>
>>> #> echo drm class 15 +p > /proc/dynamic_debug/control
>>>
>>
>> To me, this is hard to read, what the heck is '15'? I have to go look it
>> up in the control file and it's not descriptive. I think that using
>> classes/categories makes sense but I'm wondering if it can be a bit more
>> user friendly? Perhaps, we can pass an array of strings that is indexed
>> by the class id to each pr_debug() site that wants to use class. So
>> something like:
>>
>
> Im not at all averse to nice names, but as something added on.
>
> 1st, the interface to make friendlier is DRM's
>
> echo 0x04 > /sys/module/drm/parameters/debug # which category ?
>
> parm: debug:Enable debug output, where each bit enables a
> debug category.
> Bit 0 (0x01) will enable CORE messages (drm core code)
> Bit 1 (0x02) will enable DRIVER messages (drm controller code)
> Bit 2 (0x04) will enable KMS messages (modesetting code)
>
> echo DRM_UT_DRIVER,DRM_UT_KMS > /sys/module/drm/parameters/debug #
> now its pretty clear
>
> If that works, its cuz DEFINE_DYNAMIC_DEBUG_CLASSBITS()
> plucks class symbols out of its __VA_ARGS__, and #stringifes them.
> So that macro could then build the 1-per-module static constant string array
> and (only) the callbacks would be able to use it.
>
> from there, it shouldnt be hard to ref that from the module's ddebug_table,
> so parse_query could validate class args against the module given (or
> fail if none given)
>
> Speaking strictly, theres a gap:
>echo module * class DRM_UT_KMS +p > control
> is nonsense for * other than drm + drivers,
> but its fair/safe to just disallow wildcards on modname for this purpose.
>
> it does however imply that module foo must exist for FOO_CAT_1 to be usable.
> thats not currently the case:
> bash-5.1# echo module foo +p > /proc/dynamic_debug/control
> [ 15.403749] dyndbg: read 14 bytes from userspace
> [ 15.405413] dyndbg: query 0: "module foo +p" mod:*
> [ 15.406486] dyndbg: split into words: "module" "foo" "+p"
> [ 15.407070] dyndbg: op='+'
> [ 15.407388] dyndbg: flags=0x1
> [ 15.407809] dyndbg: *flagsp=0x1 *maskp=0x
> [ 15.408300] dyndbg: parsed: func="" file="" module="foo" format=""
> lineno=0-0 class=15
> [ 15.409151] dyndbg: no matches for query
> [ 15.409591] dyndbg: no-match: func="" file="" module="foo"
> format="" lineno=0-0 class=15
> [ 15.410524] dyndbg: processed 1 queries, with 0 matches, 0 errs
> bash-5.1#
>
> ISTM we can keep that "0 errs" response for that case, but still reject this:
>
>echo module foo class FOO_NOT_HERE +p > /proc/dynamic_debug/control
>
>
Ok, yeah so I guess I'm thinking about the 'class' more as global namespace,
so that for example, it could span modules, or be specific to certain modules.
I'm also thinking of it as a 'string' which is maybe hierarchical, so that it's
clear what sub-system, or sub-sub-system it belongs to. So for DRM for example,
it could be a string like "DRM:CORE". The index num I think is still helpful for
implementation so we don't have to store a pointer size, but I don't think it's
really exposed (except perhaps in module params b/c drm is doing that already?).
>> enum levels {
>> LOW,
>> MEDIUM,
>> HIGH
>> };
>
> I want to steer clear of "level" anything,
> since 2>1 implies non independence of the categories
>
>
Agreed, that was a bad example on my part.
I've put together a rough patch on top of your series, to make my thinking
hopefully clear. I also think that the module param callback thing could be
implemented in this 'global' space with the 0-14 low numbers, by adding
some sort of offset into the table. IE you would add the low number +
the offset to get the 'string' to add to the ddebug query. I commented it
out in my patch below b/c I didn't implement that part.
Thoughts?
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 664bb83778d2..b0bc1b536d54 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -8,6 +8,14 @@
#include
+enum ddebug_categories {
+FOO_BAR = 0,
+DRM_A = 1,
+DRM_B = 2,
+DRM_C =
Re: [v7 1/5] drm/edid: seek for available CEA and DisplayID block from specific EDID block index
On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
> On Sun, 13 Mar 2022, Lee Shawn C wrote:
> > drm_find_cea_extension() always look for a top level CEA block. Pass
> > ext_index from caller then this function to search next available
> > CEA ext block from a specific EDID block pointer.
> >
> > v2: save proper extension block index if CTA data information
> > was found in DispalyID block.
> > v3: using different parameters to store CEA and DisplayID block index.
> > configure DisplayID extansion block index before search available
> > DisplayID block.
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Ankit Nautiyal
> > Cc: Drew Davenport
> > Cc: intel-gfx
> > Signed-off-by: Lee Shawn C
> > ---
> > drivers/gpu/drm/drm_displayid.c | 10 +--
> > drivers/gpu/drm/drm_edid.c | 53 ++---
> > include/drm/drm_displayid.h | 4 +--
> > 3 files changed, 39 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_displayid.c
> > b/drivers/gpu/drm/drm_displayid.c
> > index 32da557b960f..31c3e6d7d549 100644
> > --- a/drivers/gpu/drm/drm_displayid.c
> > +++ b/drivers/gpu/drm/drm_displayid.c
> > @@ -59,11 +59,14 @@ static const u8 *drm_find_displayid_extension(const
> > struct edid *edid,
> > }
> >
> > void displayid_iter_edid_begin(const struct edid *edid,
> > - struct displayid_iter *iter)
> > + struct displayid_iter *iter, int *ext_index)
>
> Please don't do this. This just ruins the clean approach displayid
> iterator added.
>
> Instead of making the displayid iterator ugly, and leaking its
> abstractions, I'll repeat what I said should be done in reply to the
> very first version of this patch series [1]:
>
> "I think we're going to need abstracted EDID iteration similar to what
> I've done for DisplayID iteration. We can't have all places
> reimplementing the iteration like we have now."
>
> This isn't a problem that should be solved by having all the callers
> hold a bunch of local variables and pass them around to all the
> functions. Nobody's going to be able to keep track of this anymore. And
> this series, as it is, makes it harder to fix this properly later on.
I missed your original review comment, so apologies for repeating what you
said there already.
I'd agree that passing a starting index to the displayid_iter_*
functions is probably not the right direction here. More thoughts below.
>
>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/r/87czjf8dik@intel.com
>
>
>
> > {
> > memset(iter, 0, sizeof(*iter));
> >
> > iter->edid = edid;
> > +
> > + if (ext_index)
> > + iter->ext_index = *ext_index;
> > }
> >
> > static const struct displayid_block *
> > @@ -126,7 +129,10 @@ __displayid_iter_next(struct displayid_iter *iter)
> > }
> > }
> >
> > -void displayid_iter_end(struct displayid_iter *iter)
> > +void displayid_iter_end(struct displayid_iter *iter, int *ext_index)
> > {
> > + if (ext_index)
> > + *ext_index = iter->ext_index;
> > +
> > memset(iter, 0, sizeof(*iter));
> > }
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 561f53831e29..78c415aa6889 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3353,28 +3353,27 @@ const u8 *drm_find_edid_extension(const struct edid
> > *edid,
> > return edid_ext;
> > }
> >
> > -static const u8 *drm_find_cea_extension(const struct edid *edid)
> > +static const u8 *drm_find_cea_extension(const struct edid *edid,
> > + int *cea_ext_index, int
> > *displayid_ext_index)
As discussed above, passing both indices into this function may not be
the best approach here. But I think we need to keep track of some kind
of state in order to know which was the last CEA block that was
returned, and thus this function can return the next one after that,
whether it's in the CEA extension block or DisplayID block.
What do you think of using the pointer returned from this function as
that state? The caller could pass in a u8* that was returned from a
previous call. This function would iterate through the extension blocks
and skip the CEA blocks it finds until it finds the passed in pointer,
and then return the next one after (or NULL).
An alternative might be to create a linked list of ptrs to the edid
extension blocks, and allow a caller to iterate over them in whatever
way they need, but I'm not sure how useful that is elsewhere.
> > {
> > const struct displayid_block *block;
> > struct displayid_iter iter;
> > const u8 *cea;
> > - int ext_index = 0;
> >
> > - /* Look for a top level CEA extension block */
> > - /* FIXME: make callers iterate through multiple CEA ext blocks? */
> > - cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> > + /* Look for a CEA extension block from ext_index */
> > + cea =
Re: [PATCH 1/2] fbdev: Fix sys_imageblit() for arbitrary image widths
Hi Thomas,
On Sun, Mar 13, 2022 at 8:29 PM Thomas Zimmermann wrote:
> Commit 6f29e04938bf ("fbdev: Improve performance of sys_imageblit()")
> broke sys_imageblit() for image width that are not aligned to 8-bit
> boundaries. Fix this by handling the trailing pixels on each line
> separately. The performance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
Thanks for fixing! This was very valuable for hammering the bugs
out of ssd130xdrm and the xrgb888-to-mono conversion...
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 3/3] drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and .disable
Hi Christophe,
Le lun., mars 7 2022 at 19:12:49 +0100, Christophe Branchereau
a écrit :
Hi Paul, it should in theory, but doesn't work in practice, the
display doesn't like having that bit set outside of the init sequence.
Feel free to experiment if you think you can make it work though, you
should have that panel on 1 or 2 devices I think.
It does actually work in practice; what probably fails for you is the
regmap_set_bits(), which causes a spi-read-then-write. Since AFAIK it
is not possible to read registers from this panel (only write), then
this does not work.
An easy fix would be to just use REGCACHE_FLAT as the cache type in the
regmap_config. Then regmap_set_bits() can be used.
Cheers,
-Paul
KR
CB
On Wed, Mar 2, 2022 at 12:22 PM Paul Cercueil
wrote:
Hi Christophe,
Le mar., mars 1 2022 at 16:31:22 +0100, Christophe Branchereau
a écrit :
> Following the introduction of bridge_atomic_enable in the ingenic
> drm driver, the crtc is enabled between .prepare and .enable, if
> it exists.
>
> Add it so the backlight is only enabled after the crtc is, to
avoid
> graphical issues.
>
> Signed-off-by: Christophe Branchereau
> ---
> drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 23 --
> drivers/gpu/drm/panel/panel-innolux-ej030na.c | 31
> ---
> 2 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> index f043b484055b..b5736344e3ec 100644
> --- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> +++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> @@ -183,8 +183,6 @@ static int y030xx067a_prepare(struct drm_panel
> *panel)
> goto err_disable_regulator;
> }
>
> - msleep(120);
> -
> return 0;
>
> err_disable_regulator:
> @@ -202,6 +200,25 @@ static int y030xx067a_unprepare(struct
drm_panel
> *panel)
> return 0;
> }
>
> +static int y030xx067a_enable(struct drm_panel *panel)
> +{
> + if (panel->backlight) {
> + /* Wait for the picture to be ready before enabling
backlight */
> + msleep(120);
> + }
> +
> + return 0;
> +}
> +
> +static int y030xx067a_disable(struct drm_panel *panel)
> +{
> + struct y030xx067a *priv = to_y030xx067a(panel);
> +
> + regmap_clear_bits(priv->map, 0x06, REG06_XPSAVE);
Shouldn't that be balanced by a regmap_set_bits() in the .enable()
function?
Cheers,
-Paul
> +
> + return 0;
> +}
> +
> static int y030xx067a_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> @@ -239,6 +256,8 @@ static int y030xx067a_get_modes(struct
drm_panel
> *panel,
> static const struct drm_panel_funcs y030xx067a_funcs = {
> .prepare= y030xx067a_prepare,
> .unprepare = y030xx067a_unprepare,
> + .enable = y030xx067a_enable,
> + .disable= y030xx067a_disable,
> .get_modes = y030xx067a_get_modes,
> };
>
> diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
> b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
> index c558de3f99be..6de7370185cd 100644
> --- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
> +++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
> @@ -80,8 +80,6 @@ static const struct reg_sequence
> ej030na_init_sequence[] = {
> { 0x47, 0x08 },
> { 0x48, 0x0f },
> { 0x49, 0x0f },
> -
> - { 0x2b, 0x01 },
> };
>
> static int ej030na_prepare(struct drm_panel *panel)
> @@ -109,8 +107,6 @@ static int ej030na_prepare(struct drm_panel
> *panel)
> goto err_disable_regulator;
> }
>
> - msleep(120);
> -
> return 0;
>
> err_disable_regulator:
> @@ -128,6 +124,31 @@ static int ej030na_unprepare(struct drm_panel
> *panel)
> return 0;
> }
>
> +static int ej030na_enable(struct drm_panel *panel)
> +{
> + struct ej030na *priv = to_ej030na(panel);
> +
> + /* standby off */
> + regmap_write(priv->map, 0x2b, 0x01);
> +
> + if (panel->backlight) {
> + /* Wait for the picture to be ready before enabling
backlight */
> + msleep(120);
> + }
> +
> + return 0;
> +}
> +
> +static int ej030na_disable(struct drm_panel *panel)
> +{
> + struct ej030na *priv = to_ej030na(panel);
> +
> + /* standby on */
> + regmap_write(priv->map, 0x2b, 0x00);
> +
> + return 0;
> +}
> +
> static int ej030na_get_modes(struct drm_panel *panel,
>struct drm_connector *connector)
> {
> @@ -165,6 +186,8 @@ static int ej030na_get_modes(struct drm_panel
> *panel,
> static const struct drm_panel_funcs ej030na_funcs = {
> .prepare= ej030na_prepare,
> .unprepare = ej030na_unprepare,
> + .enable = ej030na_enable,
> + .disable= ej030na_disable,
>
Re: [PATCH 00/30] fix typos in comments
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski : On Mon, 14 Mar 2022 12:53:24 +0100 you wrote: > Various spelling mistakes in comments. > Detected with the help of Coccinelle. > > --- > > drivers/base/devres.c |4 ++-- > drivers/clk/qcom/gcc-sm6125.c |2 +- > drivers/clk/ti/clkctrl.c|2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |4 ++-- > drivers/gpu/drm/amd/display/dc/bios/command_table.c |6 +++--- > drivers/gpu/drm/amd/pm/amdgpu_pm.c |2 +- > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |4 ++-- > drivers/gpu/drm/sti/sti_gdp.c |2 +- > drivers/infiniband/hw/qib/qib_iba7220.c |4 ++-- > drivers/leds/leds-pca963x.c |2 +- > drivers/media/i2c/ov5695.c |2 +- > drivers/mfd/rohm-bd9576.c |2 +- > drivers/mtd/ubi/block.c |2 +- > drivers/net/can/usb/ucan.c |4 ++-- > drivers/net/ethernet/packetengines/yellowfin.c |2 +- > drivers/net/wireless/ath/ath6kl/htc_mbox.c |2 +- > drivers/net/wireless/cisco/airo.c |2 +- > drivers/net/wireless/mediatek/mt76/mt7915/init.c|2 +- > drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c |6 +++--- > drivers/platform/x86/uv_sysfs.c |2 +- > drivers/s390/crypto/pkey_api.c |2 +- > drivers/scsi/aic7xxx/aicasm/aicasm.c|2 +- > drivers/scsi/elx/libefc_sli/sli4.c |2 +- > drivers/scsi/lpfc/lpfc_mbox.c |2 +- > drivers/scsi/qla2xxx/qla_gs.c |2 +- > drivers/spi/spi-sun4i.c |2 +- > drivers/staging/rtl8723bs/core/rtw_mlme.c |2 +- > drivers/usb/gadget/udc/snps_udc_core.c |2 +- > fs/kernfs/file.c|2 +- > kernel/events/core.c|2 +- > 30 files changed, 39 insertions(+), 39 deletions(-) Here is the summary with links: - [03/30] ath6kl: fix typos in comments (no matching commit) - [10/30] mt76: mt7915: fix typos in comments (no matching commit) - [12/30] drivers: net: packetengines: fix typos in comments https://git.kernel.org/netdev/net-next/c/ebc0b8b5374e - [19/30] rtlwifi: rtl8821ae: fix typos in comments (no matching commit) - [20/30] airo: fix typos in comments (no matching commit) - [27/30] can: ucan: fix typos in comments (no matching commit) You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v4 1/4] drm/ingenic : add ingenic_drm_bridge_atomic_enable
Hi Christophe,
Le ven., mars 11 2022 at 18:02:37 +0100, Christophe Branchereau
a écrit :
This allows the CRTC to be enabled after panels have slept out,
and before their display is turned on, solving a graphical bug
on the newvision nv3502c
Signed-off-by: Christophe Branchereau
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821..51512f41263e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -226,6 +226,18 @@ static int ingenic_drm_update_pixclk(struct
notifier_block *nb,
}
}
+static void ingenic_drm_bridge_atomic_enable(struct drm_bridge
*bridge,
+struct drm_bridge_state
*old_bridge_state)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(bridge->dev);
+
+ regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
+
+ regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
+ JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
+ JZ_LCD_CTRL_ENABLE);
+}
+
static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -237,17 +249,11 @@ static void
ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
if (WARN_ON(IS_ERR(priv_state)))
return;
- regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
-
/* Set addresses of our DMA descriptor chains */
next_id = priv_state->use_palette ? HWDESC_PALETTE : 0;
regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv,
next_id));
regmap_write(priv->map, JZ_REG_LCD_DA1, dma_hwdesc_addr(priv, 1));
- regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
- JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
- JZ_LCD_CTRL_ENABLE);
-
drm_crtc_vblank_on(crtc);
}
@@ -968,6 +974,7 @@ static const struct drm_encoder_helper_funcs
ingenic_drm_encoder_helper_funcs =
static const struct drm_bridge_funcs ingenic_drm_bridge_funcs = {
.attach = ingenic_drm_bridge_attach,
+ .atomic_enable = ingenic_drm_bridge_atomic_enable,
Shouldn't we have a .atomic_disable() as well? If the CRTC is now
enabled in the bridge's .atomic_enable, it would make sense to have it
disabled in the .atomic_disable().
Cheers,
-Paul
.atomic_check = ingenic_drm_bridge_atomic_check,
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
--
2.35.1
Re: [PATCH v4 2/4] drm/panel: Add panel driver for NewVision NV3052C based LCDs
Hi Christophe,
Le ven., mars 11 2022 at 18:02:38 +0100, Christophe Branchereau
a écrit :
This driver supports the NewVision NV3052C based LCDs. Right now, it
only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel,
which
can be found in the Anbernic RG-350M handheld console.
Signed-off-by: Christophe Branchereau
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-newvision-nv3052c.c | 497
++
3 files changed, 507 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index bb2e47229c68..40084f709789 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -283,6 +283,15 @@ config DRM_PANEL_NEC_NL8048HL11
panel (found on the Zoom2/3/3630 SDP boards). To compile this
driver
as a module, choose M here.
+config DRM_PANEL_NEWVISION_NV3052C
+ tristate "NewVision NV3052C RGB/SPI panel"
+ depends on OF && SPI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_MIPI_DBI
+ help
+ Say Y here if you want to enable support for the panels built
+ around the NewVision NV3052C display controller.
+
config DRM_PANEL_NOVATEK_NT35510
tristate "Novatek NT35510 RGB panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index 5740911f637c..42a7ab54234b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) +=
panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
+obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) +=
panel-newvision-nv3052c.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
new file mode 100644
index ..fc31df0dee12
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NevVision NV3052C IPS LCD panel driver
NewVision*
+ *
+ * Copyright (C) 2020, Paul Cercueil
+ * Copyright (C) 2022, Christophe Branchereau
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+struct nv3052c_panel_info {
+ const struct drm_display_mode *display_modes;
+ unsigned int num_modes;
+ u16 width_mm, height_mm;
+ u32 bus_format, bus_flags;
+};
+
+struct nv3052c {
+ struct device *dev;
+ struct drm_panel panel;
+ struct mipi_dbi dbi;
+
+ const struct nv3052c_panel_info *panel_info;
+
+ struct regulator *supply;
+ struct gpio_desc *reset_gpio;
+};
+
+struct nv3052c_reg {
+ u8 cmd;
+ u8 val;
+};
+
+static const struct nv3052c_reg nv3052c_panel_regs[] = {
+ { 0xff, 0x30 },
+ { 0xff, 0x52 },
+ { 0xff, 0x01 },
+ { 0xe3, 0x00 },
+ { 0x40, 0x00 },
+ { 0x03, 0x40 },
+ { 0x04, 0x00 },
+ { 0x05, 0x03 },
+ { 0x08, 0x00 },
+ { 0x09, 0x07 },
+ { 0x0a, 0x01 },
+ { 0x0b, 0x32 },
+ { 0x0c, 0x32 },
+ { 0x0d, 0x0b },
+ { 0x0e, 0x00 },
+ { 0x23, 0xa0 },
+
+ { 0x24, 0x0c },
+ { 0x25, 0x06 },
+ { 0x26, 0x14 },
+ { 0x27, 0x14 },
+
+ { 0x38, 0xcc },
+ { 0x39, 0xd7 },
+ { 0x3a, 0x4a },
+
+ { 0x28, 0x40 },
+ { 0x29, 0x01 },
+ { 0x2a, 0xdf },
+ { 0x49, 0x3c },
+ { 0x91, 0x77 },
+ { 0x92, 0x77 },
+ { 0xa0, 0x55 },
+ { 0xa1, 0x50 },
+ { 0xa4, 0x9c },
+ { 0xa7, 0x02 },
+ { 0xa8, 0x01 },
+ { 0xa9, 0x01 },
+ { 0xaa, 0xfc },
+ { 0xab, 0x28 },
+ { 0xac, 0x06 },
+ { 0xad, 0x06 },
+ { 0xae, 0x06 },
+ { 0xaf, 0x03 },
+ { 0xb0, 0x08 },
+ { 0xb1, 0x26 },
+ { 0xb2, 0x28 },
+ { 0xb3, 0x28 },
+ { 0xb4, 0x33 },
+ { 0xb5, 0x08 },
+ { 0xb6, 0x26 },
+ { 0xb7, 0x08 },
+ { 0xb8, 0x26 },
+ { 0xf0, 0x00 },
+ { 0xf6, 0xc0 },
+
+ { 0xff, 0x30 },
+ { 0xff, 0x52 },
+ { 0xff, 0x02 },
+ { 0xb0, 0x0b },
+ { 0xb1, 0x16 },
+ { 0xb2, 0x17 },
+ { 0xb3, 0x2c },
+ { 0xb4, 0x32 },
+ { 0xb5, 0x3b },
+ { 0xb6, 0x29 },
+ { 0xb7, 0x40 },
+ { 0xb8, 0x0d },
+ { 0xb9, 0x05 },
+ { 0xba, 0x12 },
+ { 0xbb, 0x10 },
+ { 0xbc, 0x12 },
+ { 0xbd, 0x15 },
+ { 0xbe, 0x19 },
[PATCH] drm: Fix a infinite loop condition when order becomes 0
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
--
2.25.1
Re: [PATCH v3] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
On Mon, 14 Mar 2022 at 20:27, Vinod Polimera wrote:
>
> - Some DPU versions support inline rot90. It is supported only for
> limited amount of UBWC formats.
> - There are two versions of inline rotators, v1 (present on sm8250 and
> sm7250) and v2 (sc7280). These versions differ in the list of supported
> formats and in the scaler possibilities.
>
> Changes in RFC:
> - Rebase changes to the latest code base.
> - Append rotation config variables with v2 and
> remove unused variables.(Dmitry)
> - Move pixel_ext setup separately from scaler3 config.(Dmitry)
> - Add 270 degree rotation to supported rotation list.(Dmitry)
>
> Changes in V2:
> - Remove unused macros and fix indentation.
> - Add check if 90 rotation is supported and
> add supported rotations to rot_cfg.
>
> Changes in V3:
> - Fix indentation.
> - Move rot_supported to sspp capabilities. (Dmitry)
> - Config pixel_ext based on src_h/src_w directly. (Dmitry)
> - Misc changes.
>
> Co-developed-by: Kalyan Thota
> Signed-off-by: Kalyan Thota
> Signed-off-by: Vinod Polimera
> ---
> arch/arm64/configs/defconfig | 4 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 218
> +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 119 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
> 5 files changed, 253 insertions(+), 108 deletions(-)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 040420b..3bd91f7 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
Unrelated. Please drop.
> @@ -696,7 +696,7 @@ CONFIG_VIDEO_RCAR_DRIF=m
> CONFIG_VIDEO_IMX219=m
> CONFIG_VIDEO_OV5640=m
> CONFIG_VIDEO_OV5645=m
> -CONFIG_DRM=m
> +CONFIG_DRM=y
> CONFIG_DRM_I2C_NXP_TDA998X=m
> CONFIG_DRM_MALI_DISPLAY=m
> CONFIG_DRM_NOUVEAU=m
> @@ -721,7 +721,7 @@ CONFIG_DRM_SUN4I=m
> CONFIG_DRM_SUN6I_DSI=m
> CONFIG_DRM_SUN8I_DW_HDMI=m
> CONFIG_DRM_SUN8I_MIXER=m
> -CONFIG_DRM_MSM=m
> +CONFIG_DRM_MSM=y
> CONFIG_DRM_TEGRA=m
> CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
> CONFIG_DRM_PANEL_LVDS=m
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index a4fe77c..f591e63 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -35,6 +35,9 @@
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>
> +#define VIG_SC7280_MASK \
> + (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
> +
> #define DMA_SDM845_MASK \
> (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> @@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
> DRM_FORMAT_YVU420,
> };
>
> +static const u32 rotation_v2_formats[] = {
> + DRM_FORMAT_NV12,
> + /* TODO add formats after validation */
> +};
> +
> /*
> * DPU sub blocks config
> */
> @@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
> */
>
> /* SSPP common configuration */
> -
> -#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
> +#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
> { \
> .maxdwnscale = MAX_DOWNSCALE_RATIO, \
> .maxupscale = MAX_UPSCALE_RATIO, \
> @@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
> .num_formats = ARRAY_SIZE(plane_formats_yuv), \
> .virt_format_list = plane_formats, \
> .virt_num_formats = ARRAY_SIZE(plane_formats), \
> + .rotation_cfg = rot_cfg, \
> }
>
> #define _DMA_SBLK(num, sdma_pri) \
> @@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
> }
>
> static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
> - _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
> + _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3,
> NULL);
> static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
> - _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
> + _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3,
> NULL);
> static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
> - _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
> + _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3,
> NULL);
> static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
> - _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
> + _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3,
> NULL);
> +
> +static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
> +
[PATCH] drm/i915: round_up the size to the alignment value
handle instances when size is not aligned with the min_page_size.
Unigine Heaven has allocation requests for example required pages
are 161 and alignment request is 128. To allocate the left over
33 pages, continues the iteration to find the order value which
is 5 and 0 and when it compares with min_order = 7, triggers the
BUG_ON((order < min_order). To avoid this problem, round_up the
size to the alignment and enable the is_contiguous variable and
the block trimmed to the original size.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 129f668f21ff..318aa731de5b 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -40,6 +40,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
struct i915_ttm_buddy_resource *bman_res;
struct drm_buddy *mm = >mm;
unsigned long n_pages, lpfn;
+ bool is_contiguous = 0;
u64 min_page_size;
u64 size;
int err;
@@ -48,6 +49,9 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (!lpfn)
lpfn = man->size;
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS)
+ is_contiguous = 1;
+
bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
if (!bman_res)
return -ENOMEM;
@@ -71,7 +75,12 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
GEM_BUG_ON(min_page_size < mm->chunk_size);
- if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ if (!is_contiguous && !IS_ALIGNED(size, min_page_size)) {
+ size = round_up(size, min_page_size);
+ is_contiguous = 1;
+ }
+
+ if (is_contiguous) {
unsigned long pages;
size = roundup_pow_of_two(size);
@@ -106,7 +115,7 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (unlikely(err))
goto err_free_blocks;
- if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ if (is_contiguous) {
u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
mutex_lock(>lock);
base-commit: b37605de46fef48555bf0cf463cccf355c51fac0
--
2.25.1
Re: [PATCH] drm: remove min_order BUG_ON check
On 10/03/22 8:59 pm, Matthew Auld wrote: > On 10/03/2022 14:47, Arunpravin wrote: >> >> >> On 08/03/22 10:31 pm, Matthew Auld wrote: >>> On 08/03/2022 13:59, Arunpravin wrote: On 07/03/22 10:11 pm, Matthew Auld wrote: > On 07/03/2022 14:37, Arunpravin wrote: >> place BUG_ON(order < min_order) outside do..while >> loop as it fails Unigine Heaven benchmark. >> >> Unigine Heaven has buffer allocation requests for >> example required pages are 161 and alignment request >> is 128. To allocate the remaining 33 pages, continues >> the iteration to find the order value which is 5 and >> when it compares with min_order = 7, enables the >> BUG_ON(). To avoid this problem, placed the BUG_ON >> check outside of do..while loop. >> >> Signed-off-by: Arunpravin >> --- >> drivers/gpu/drm/drm_buddy.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c >> index 72f52f293249..ed94c56b720f 100644 >> --- a/drivers/gpu/drm/drm_buddy.c >> +++ b/drivers/gpu/drm/drm_buddy.c >> @@ -669,10 +669,11 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, >> order = fls(pages) - 1; >> min_order = ilog2(min_page_size) - ilog2(mm->chunk_size); >> >> +BUG_ON(order < min_order); > > Isn't the issue that we are allowing a size that is not aligned to the > requested min_page_size? Should we not fix the caller(and throw a normal > error here), or perhaps add the round_up() here instead? > CASE 1: when size is not aligned to the requested min_page_size, for instance, required size = 161 pages, min_page_size = 128 pages, here we have 3 possible options, a. AFAIK,This kind of situation is common in any workload,the first allocation (i.e) 128 pages is aligned to min_page_size, Should we just allocate the left over 33 pages (2 pow 5, 2 pow 0) since the caller does know the left over pages are not in min_page_size alignment? >>> >>> So IIUC looking at amdgpu_gem_create_ioctl(), userspace can specify some >>> arbitrary physical alignment for an object? Is that not meant to apply >>> to every page/chunk? The above example would only have the correct >>> physical alignment guaranteed for the first chunk, or so, is this the >>> expected ABI behaviour? >>> >> I gone through the function amdgpu_gem_create_ioctl(), it reads the >> physical alignment in bytes from userspace, does i915 round up the size >> value to the alignment or does i915 fails the allocation request if size >> is not aligned with min_page_size? If not, I think running unigine >> heaven or similar benchmark triggers BUG_ON() on current version of drm >> buddy > > i915 will always round_up the obj->base.size as per the > default_page_size. But in our case the default_page_size is selected by > the kernel, which is always either PAGE_SIZE, or 64K on some platforms, > due to the HW having some minimum GPU page-size for mapping VRAM pages. > We don't currently have anything similar to > amdgpu_gem_create_in.alignment, where userspace can request some > arbitrary physical alignment. > >>> Also looking at this some more, the other related bug here is the >>> order-- == min_order check, since it now won't bail when order == 0, >>> leading to order = -1, if we are unlucky... >> will add a fix >>> >>> Originally, if asking for min_page_size > chunk_size, then the >>> allocation was meant to fail if it can't fill the resource request with >>> pages of at least that size(and also alignment). Or at least that was >>> the original meaning in i915 IIRC. >> we can follow the same here too, failing the allocation request if size >> is not aligned with min_page_size? > > Yeah, seems reasonable to me. I had internal discussion with Christian and he suggested to round_up the size to the alignment and trim the block to the required original size. I have sent the patch, please review. Thanks, Arun > >> >> I added a debug print for requested num_pages from userspace and its >> alignment request and executed unigine heaven, I see many such instances >> where min_page_size is not aligned to the size, how i915 handles such >> requests? >>> b. There are many such instances in unigine heaven workload (there would be many such workloads), throwing a normal error would lower the FPS? is it possible to fix at caller application? c. adding the round_up() is possible, but in every such instances we end up allocating extra unused memory. For example, if required pages = 1028 and min_page_size = 1024 pages, we end up round up of left over 4 pages to the min_page_size, so the total size would be 2048 pages. > i.e if someone does: > > alloc_blocks(mm, 0, end, 4096, 1<<16, , flags); CASE 2: I think this case should be detected (i.e) when
Re: [PATCH v6 1/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
On Mon, 14 Mar 2022 at 17:47, Vinod Polimera wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Fixes: 25fdd5933("drm/msm: Add SDM845 DPU support")
> Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e29796c..9c346ce 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1202,7 +1202,9 @@ static int dpu_bind(struct device *dev, struct device
> *master, void *data)
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *ddev = priv->dev;
> struct dpu_kms *dpu_kms;
> + struct dev_pm_opp *opp;
> int ret = 0;
> + unsigned long max_freq = ULONG_MAX;
>
> dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), GFP_KERNEL);
> if (!dpu_kms)
> @@ -1225,6 +1227,12 @@ static int dpu_bind(struct device *dev, struct device
> *master, void *data)
> }
> dpu_kms->num_clocks = ret;
>
> + opp = dev_pm_opp_find_freq_floor(dev, _freq);
> + if (!IS_ERR(opp))
> + dev_pm_opp_put(opp);
> +
> + dev_pm_opp_set_rate(dev, max_freq);
> +
> platform_set_drvdata(pdev, dpu_kms);
>
> ret = msm_kms_init(_kms->base, _funcs);
> --
> 2.7.4
>
--
With best wishes
Dmitry
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
Hi Pekka,
On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen wrote:
> On Mon, 14 Mar 2022 14:30:18 +0100
> Geert Uytterhoeven wrote:
> > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > wrote:
> > > Introduce fourcc codes for color-indexed frame buffer formats with two,
> > > four, and sixteen colors, and provide a mapping from bit per pixel and
> > > depth to fourcc codes.
> > >
> > > As the number of bits per pixel is less than eight, these rely on proper
> > > block handling for the calculation of bits per pixel and pitch.
> > >
> > > Signed-off-by: Geert Uytterhoeven
> >
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -99,7 +99,10 @@ extern "C" {
> > > #define DRM_FORMAT_INVALID 0
> > >
> > > /* color index */
> > > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0]
> > > C */
> > > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /* [7:0]
> > > C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> > > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /* [7:0]
> > > C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /* [7:0]
> > > C0:C1 4:4 two pixels/byte */
> > > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0]
> > > C 8 one pixel/byte */
> > >
> > > /* 8 bpp Red */
> > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0]
> > > R */
> >
> > After replying to Ilia's comment[1], I realized the CFB drawing
> > operations use native byte and bit ordering, unless
> > FBINFO_FOREIGN_ENDIAN is set.
> > While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> > e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> > (sh7760fb configures ordering to match host order).
> > BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> > guess they are broken on big-endian.
> > Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> > on little-endian.
> >
> > Hence the above should become:
> >
> > #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> > [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> > #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> > [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> > #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> > [7:0] C1:C0 4:4 two pixels/byte */
> >
> > The same changes should be made for DRM_FORMAT_[RD][124].
> >
> > The fbdev emulation code should gain support for these with and without
> > DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian platforms?
> >
> > [1]
> > https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> > [2] See p.30 of the VIDC datasheet
> >
> > http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> > [3] See p.1178 of the SH7660 datasheet
> >
> > https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
>
> why would CPU endianess affect the order of bits in a byte?
It doesn't, but see below.
> Do you mean that bit 0 one machine is (1 << 0), and on another machine
> bit 0 is (1 << 7)?
No, I mean that in case of multiple pixels per byte, the display
hardware pumps out pixels to the CRTC starting from either the MSB
or the LSB of the first display byte. Which order depends on the
display hardware, not on the CPU.
> In C, we have only one way to address bits of a byte and that is with
> arithmetic. You cannot take the address of a bit any other way, can you?
>
> Can we standardise on "bit n of a byte is addressed as (1 << n)"?
BIT(n) in Linux works the same for little- and big-endian CPUs.
But display hardware may use a different bit order.
> I don't mind in which order the pixels are inside a byte, as long as it
> doesn't change by CPU endianess. If you need both directions, then use
> two different drm_fourcc codes that do not change their meaning by CPU
> endianess. Just like we have XRGB and BGRX formats.
OK.
> I would not like to see DRM_FORMAT_BIG_ENDIAN used for this, it would
> conflate a whole new concept into the mess that is little- vs.
> big-endian.
OK.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 3/4] drm/i915/selftest: Clear the output buffers before GPU writes
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a)
so that is both non-zero and distinct from the poison values used during
the test.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 32 ++
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 0a8ed4246082..b9cc89de01bf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1346,6 +1346,30 @@ static int compare_isolation(struct intel_engine_cs
*engine,
return err;
}
+static struct i915_vma *
+create_result_vma(struct i915_address_space *vm, unsigned long sz)
+{
+ struct i915_vma *vma;
+ void *ptr;
+
+ vma = create_user_vma(vm, sz);
+ if (IS_ERR(vma))
+ return vma;
+
+ /* Set the results to a known value distinct from the poison */
+ ptr = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+ if (IS_ERR(ptr)) {
+ i915_vma_put(vma);
+ return ERR_CAST(ptr);
+ }
+
+ memset(ptr, POISON_INUSE, vma->size);
+ i915_gem_object_flush_map(vma->obj);
+ i915_gem_object_unpin_map(vma->obj);
+
+ return vma;
+}
+
static int __lrc_isolation(struct intel_engine_cs *engine, u32 poison)
{
u32 *sema = memset32(engine->status_page.addr + 1000, 0, 1);
@@ -1364,13 +1388,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
goto err_A;
}
- ref[0] = create_user_vma(A->vm, SZ_64K);
+ ref[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[0])) {
err = PTR_ERR(ref[0]);
goto err_B;
}
- ref[1] = create_user_vma(A->vm, SZ_64K);
+ ref[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[1])) {
err = PTR_ERR(ref[1]);
goto err_ref0;
@@ -1392,13 +1416,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
i915_request_put(rq);
- result[0] = create_user_vma(A->vm, SZ_64K);
+ result[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[0])) {
err = PTR_ERR(result[0]);
goto err_ref1;
}
- result[1] = create_user_vma(A->vm, SZ_64K);
+ result[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[1])) {
err = PTR_ERR(result[1]);
goto err_result0;
--
2.20.1
[PATCH 4/4] drm/i915/selftest: Always cancel semaphore on error
From: Chris Wilson
Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index b9cc89de01bf..ae16668dd9d4 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1435,18 +1435,17 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
err = poison_registers(B, poison, sema);
- if (err) {
- WRITE_ONCE(*sema, -1);
- i915_request_put(rq);
- goto err_result1;
- }
-
- if (i915_request_wait(rq, 0, HZ / 2) < 0) {
- i915_request_put(rq);
+ if (err == 0 && i915_request_wait(rq, 0, HZ / 2) < 0) {
+ pr_err("%s(%s): wait for results timed out\n",
+ __func__, engine->name);
err = -ETIME;
- goto err_result1;
}
+
+ /* Always cancel the semaphore wait, just in case the GPU gets stuck */
+ WRITE_ONCE(*sema, -1);
i915_request_put(rq);
+ if (err)
+ goto err_result1;
err = compare_isolation(engine, ref, result, A, poison);
--
2.20.1
[PATCH 2/4] drm/i915/selftests: Check for incomplete LRI from the context image
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
interpretting context data as instructions. Eventually, as Daniele
discovered, this would lead us to find addition LRI as part of the data
and mistakenly add invalid LRI commands to the context probes.
Stop parsing after we see the first !MI command, as we know we will have
seen all the context registers by that point. (Mostly true for all gen so far,
though the render context does have LRI after the first page that we
have been ignoring so far. It would be useful to extract those as well
so that we have the full list of user accesisble registers.)
Similarly, emit a warning if we do try to emit an invalid zero-length
LRI.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 61 +++---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 13f57c7c4224..0a8ed4246082 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,6 +27,9 @@
#define NUM_GPR 16
#define NUM_GPR_DW (NUM_GPR * 2) /* each GPR is 2 dwords */
+#define LRI_HEADER MI_INSTR(0x22, 0)
+#define LRI_LENGTH_MASK GENMASK(7, 0)
+
static struct i915_vma *create_scratch(struct intel_gt *gt)
{
return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
@@ -180,7 +183,7 @@ static int live_lrc_layout(void *arg)
continue;
}
- if ((lri & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((lri & GENMASK(31, 23)) != LRI_HEADER) {
pr_err("%s: Expected LRI command at dword %d,
found %08x\n",
engine->name, dw, lri);
err = -EINVAL;
@@ -945,18 +948,40 @@ store_context(struct intel_context *ce, struct i915_vma
*scratch)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /*
+* Keep it simple, skip parsing complex commands
+*
+* At present, there are no more MI_LOAD_REGISTER_IMM
+* commands after the first 3D state command. Rather
+* than include a table (see i915_cmd_parser.c) of all
+* the possible commands and their instruction lengths
+* (or mask for variable length instructions), assume
+* we have gathered the complete list of registers and
+* bail out.
+*/
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
+ /* Assume all other MI commands match LRI length mask */
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+ break;
+ }
+
dw++;
len = (len + 1) / 2;
while (len--) {
@@ -1108,18 +1133,29 @@ static struct i915_vma *load_context(struct
intel_context *ce, u32 poison)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /* For simplicity, break parsing at the first complex command */
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+ break;
+ }
+
[PATCH 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
From: Chris Wilson
Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.
Testcase: igt/i915_selftests/gt_lrc
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 0bf8b45c9319..d6da3bbf66f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -109,6 +109,7 @@
#define RING_SBBSTATE(base)_MMIO((base) + 0x118) /* hsw+ */
#define RING_SBBADDR_UDW(base) _MMIO((base) + 0x11c) /* gen8+
*/
#define RING_BBADDR(base) _MMIO((base) + 0x140)
+#define RING_BB_OFFSET(base) _MMIO((base) + 0x158)
#define RING_BBADDR_UDW(base) _MMIO((base) + 0x168) /* gen8+
*/
#define CCID(base) _MMIO((base) + 0x180)
#define CCID_EN BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 07bef7128fdb..f673bae97a03 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -662,6 +662,18 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs
*engine)
return -1;
}
+static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)
+{
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
+ return 0x80;
+ else if (GRAPHICS_VER(engine->i915) >= 12)
+ return 0x70;
+ else if (GRAPHICS_VER(engine->i915) >= 9)
+ return 0x64;
+ else
+ return -1;
+}
+
static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
{
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
@@ -768,6 +780,7 @@ static void init_common_regs(u32 * const regs,
bool inhibit)
{
u32 ctl;
+ int loc;
ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -779,6 +792,10 @@ static void init_common_regs(u32 * const regs,
regs[CTX_CONTEXT_CONTROL] = ctl;
regs[CTX_TIMESTAMP] = ce->runtime.last;
+
+ loc = lrc_ring_bb_offset(engine);
+ if (loc != -1)
+ regs[loc + 1] = 0;
}
static void init_wa_bb_regs(u32 * const regs,
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 21c29d315cc0..13f57c7c4224 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -323,6 +323,11 @@ static int live_lrc_fixed(void *arg)
lrc_ring_cmd_buf_cctl(engine),
"RING_CMD_BUF_CCTL"
},
+ {
+
i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
+ lrc_ring_bb_offset(engine),
+ "RING_BB_OFFSET"
+ },
{ },
}, *t;
u32 *hw;
--
2.20.1
[PATCH 0/4] lrc selftest fixes
Few bug fixes for lrc selftest. Chris Wilson (4): drm/i915/gt: Explicitly clear BB_OFFSET for new contexts drm/i915/selftests: Check for incomplete LRI from the context image drm/i915/selftest: Clear the output buffers before GPU writes drm/i915/selftest: Always cancel semaphore on error drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 115 3 files changed, 113 insertions(+), 20 deletions(-) -- 2.20.1
[PATCH 0/4] lrc selftest fixes
Few bug fixes for lrc selftest. Chris Wilson (4): drm/i915/gt: Explicitly clear BB_OFFSET for new contexts drm/i915/selftests: Check for incomplete LRI from the context image drm/i915/selftest: Clear the output buffers before GPU writes drm/i915/selftest: Always cancel semaphore on error drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 115 3 files changed, 113 insertions(+), 20 deletions(-) -- 2.20.1
Re: [PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk
On 3/14/22 11:18, Sascha Hauer wrote: > On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote: >> On 3/11/22 11:33, Sascha Hauer wrote: >>> The rk3568 HDMI has an additional clock that needs to be enabled for the >>> HDMI controller to work. This clock is not needed for the HDMI >>> controller itself, but to make the SoC internal bus logic work. From the >>> reference manual: >>> 2.8.6 NIU Clock gating reliance A part of niu clocks have a dependence on another niu clock in order to sharing the internal bus. When these clocks are in use, another niu clock must be opened, and cannot be gated. These clocks and the special clock on which they are relied are as following: Clocks which have dependency The clock which can not be gated - ... pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu ... >>> The clock framework does not support turning on a clock whenever another >>> clock is turned on, so this patch adds support for the dependent clock >>> to the HDMI driver. We call it "NIU", which is for "Native Interface >>> Unit" >> >> This still doesn't make sense to me. You're saying that "pclk_vo_niu, >> hclk_vo_s_niu" depend on "hclk_vo_niu", but HDMI doesn't use pclk_vo, it >> uses pclk_hdmi. > > pclk_hdmi_host is a child clock of pclk_vo: > > aclk_vo 220 3 0 > 0 5 Y > aclk_hdcp 000 3 0 > 0 5 N > pclk_vo 2307500 0 > 0 5 Y >pclk_edp_ctrl 0007500 0 > 0 5 N >pclk_dsitx_1 0007500 0 > 0 5 N >pclk_dsitx_0 1207500 0 > 0 5 Y >pclk_hdmi_host 1207500 0 > 0 5 Y >pclk_hdcp 0007500 0 > 0 5 N > hclk_vo 250 15000 0 > 0 5 Y >hclk_hdcp 000 15000 0 > 0 5 N >hclk_vop 020 15000 0 > 0 5 N It was unclear that the pclk_hdmi is the child of pclk_vo by looking at the clk driver's code, thank you! Won't be better if the implicit clk dependency would be handled internally by the RK clk driver? For example, by making the common gate shared/refcounted. Have you considered this variant? Then we won't need to change the DT bindings.
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
On Mon, 14 Mar 2022 08:35:17 -0700, Tvrtko Ursulin wrote: > > >> Alternatively, all other uapi uses struct i915_engine_class_instance to > >> address engines which uses u16:u16. > >> > >> How ugly it is to stuff a struct into u32 flags is the question... But you > >> could at least use u16:u16 for consistency. Unless you wanted to leave some > >> bits free for the future? > > Originally when I wrote this I was wanting to leave space in case it was > > ever needed. I'm not particularly for or against keeping the space now. > > Yes, shrug... Neither I can't guess if we are ever likely to hit a problem > by having fewer bits for class:instance here compared to other uapi, or if > stuffing struct i915_engine_class_instance into flags would just be too > ugly. I mean there is option to define a new struct and not use flags at > all but that's probably to complicated for what it is. > > Anyone else with an opinion? Consistency or should be fine even like it is? Consistency. I'd prefer to stuff struct i915_engine_class_instance into flags, fwiw.
Re: [PATCH v1 1/1] staging: fbtft: Consider type of init sequence values in fbtft_init_display()
On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
> In the fbtft_init_display() the init sequence is printed for
> the debug purposes. Unfortunately the current code doesn't take
> into account that values in the buffer are of the s16 type.
>
> Consider that and replace the printing code with fbtft_par_dbg_hex()
> call.
>
> Fixes: b97014a9 ("staging/fbtft: Remove all strcpy() uses")
> Signed-off-by: Andy Shevchenko
> ---
> drivers/staging/fbtft/fbtft-core.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c
> b/drivers/staging/fbtft/fbtft-core.c
> index 4a35347b3020..b28a059ad3b4 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -1035,10 +1035,9 @@ int fbtft_init_display(struct fbtft_par *par)
> for (j = 0; par->init_sequence[i + 1 + j] >= 0; j++)
> ;
>
> - fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
> - "init: write(0x%02X) %*ph\n",
> - par->init_sequence[i], j,
> - >init_sequence[i + 1]);
> + fbtft_par_dbg_hex(DEBUG_INIT_DISPLAY, par,
> par->info->device,
> + s16, >init_sequence[i + 1], j,
> + "init: write(0x%02X)",
> par->init_sequence[i]);
>
> /* Write */
> j = 0;
> --
> 2.34.1
>
>
Any reason you didn't test build this?
drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_init_display’:
drivers/staging/fbtft/fbtft-core.c:1038:48: error: passing argument 3 of
‘fbtft_dbg_hex’ discards ‘const’ qualifier from pointer target type
[-Werror=discarded-qualifiers]
1038 | s16, >init_sequence[i +
1], j,
|
^~
drivers/staging/fbtft/fbtft.h:441:50: note: in definition of macro
‘fbtft_par_dbg_hex’
441 | fbtft_dbg_hex(dev, sizeof(type), buf,\
| ^~~
drivers/staging/fbtft/fbtft-core.c:52:26: note: expected ‘void *’ but argument
is of type ‘const s16 *’ {aka ‘const short int *’}
52 |void *buf, size_t len, const char *fmt, ...)
|~~^~~
LD [M] drivers/staging/gdm724x/gdmulte.o
cc1: all warnings being treated as errors
[PATCH v3] drm/msm/disp/dpu1: add inline rotation support for sc7280 target
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)
Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.
Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
---
arch/arm64/configs/defconfig | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 218 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 119 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
5 files changed, 253 insertions(+), 108 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 040420b..3bd91f7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -696,7 +696,7 @@ CONFIG_VIDEO_RCAR_DRIF=m
CONFIG_VIDEO_IMX219=m
CONFIG_VIDEO_OV5640=m
CONFIG_VIDEO_OV5645=m
-CONFIG_DRM=m
+CONFIG_DRM=y
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_MALI_DISPLAY=m
CONFIG_DRM_NOUVEAU=m
@@ -721,7 +721,7 @@ CONFIG_DRM_SUN4I=m
CONFIG_DRM_SUN6I_DSI=m
CONFIG_DRM_SUN8I_DW_HDMI=m
CONFIG_DRM_SUN8I_MIXER=m
-CONFIG_DRM_MSM=m
+CONFIG_DRM_MSM=y
CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
CONFIG_DRM_PANEL_LVDS=m
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..f591e63 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_SC7280_MASK \
+ (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
};
+static const u32 rotation_v2_formats[] = {
+ DRM_FORMAT_NV12,
+ /* TODO add formats after validation */
+};
+
/*
* DPU sub blocks config
*/
@@ -642,8 +650,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
*/
/* SSPP common configuration */
-
-#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
+#define _VIG_SBLK(num, sdma_pri, qseed_ver, rot_cfg) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
@@ -660,6 +667,7 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+ .rotation_cfg = rot_cfg, \
}
#define _DMA_SBLK(num, sdma_pri) \
@@ -676,22 +684,28 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
}
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_0 =
- _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_1 =
- _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("1", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
- _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("2", 0, DPU_SSPP_SCALER_QSEED3, NULL);
static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
- _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3, NULL);
+
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+ .rot_maxheight = 1088,
+ .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+ .rot_format_list = rotation_v2_formats,
+};
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
- _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
+ _VIG_SBLK("0",
[PATCH v9 00/13] Add GuC Error Capture Support
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 8th rev of this series with the first 3 revs labelled as RFC. Prior receipts of rvb's: - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received R-v-b's from Umesh Nerlige Ramappa - Patch #6, #7, #8, #9 has received an R-v-b from Matthew Brost . NOTE: some of these came in on the trybot series. https://patchwork.freedesktop.org/series/100831/ Changes from prior revs: v9: - Rebase on latest drm-tip to solve CI merge-build error. v8: - Fix a bug found by CI in rev7: Create a cached ADS capture list for null-header like the other lists. - Fixed a bug on the ggtt offset calculation in the ADS population loop. Thanks to Matt Brost. - Change the storage uses for initial allocation and caching of the ADS register lists so we only store a regular pointer instead of file handle. - Multiple improvements on code styling, variable names, comments and code reduction from Umesh suggestions across multiple patches. v7: - Rebased on lastest drm_tip that has the ADS now using shmem based ads_blob_write utilities. Stress test was performed with this patch included to fix a legacy bug: https://patchwork.freedesktop.org/series/100768/ v6: - In patch #1, ADS reg-list population, we now alloc regular memory to create the lists and cache them for simpler and faster use by GuC ADS module at init, suspend-resume and reset cycles. This was in response to review comments from Lucas De Marchi that also wanted to ensure the GuC ADS module owns the final copying into the ADS phyical memory. - Thanks to Jani Nikula for pointing out that patch #2 and #3 should ensure static tables as constant and dynamic lists should be allocated and cached but attached to the GT level for the case of multiple cards with different fusings for steered registers. These are addressed now along with multiple code style fixups (thanks to review comment from Umesh) and splitting the steered register list generation as a seperate patch. - The extraction functionality, Patch #10 and #11 (was patch #7), has fixed all of Umesh's review comments related to the code styling. Additionally, it was discovered during stress tests that the extraction function could be called by the ct processing thread at the same time as the start of a GT reset event. Thus, a redesign was done whereby the linked list of processed capture-output-nodes are allocated up front and reused throughout the driver's life to ensure no memory locks are taken during extraction. - For patch #6 (now 7, 8 and 9), updates to intel_guc_log was split into smaller chunks and the log_state structure was returned back to inside of the intel_guc_log struct as opposed to the intel_guc struct in prior rev. This is in response to review comments by Matt Brost. - #Patch 13 (previously #10) is mostly identical but addresses all of the code styling comments reviews from Umesh. v5: - Added Gen9->Gen11 register list for CI coverage that included Gen9 with GuC submission. - Redesigned the extraction of the GuC error-capture dumps by grouping them into complete per-engine-reset nodes. Complete here means each node includes the global, engine-class and engine-instance register lists in a single structure. - Extraction is decoupled from the print-out. We now do the extraction immediately when receiving the G2H for error-capture notification. A link list of nodes is maintained with a FIFO based threshold while awaiting retrieval from i915_gpu_coredump's capture_engine function. - Added
Re: [PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
On 2022-03-14 11:31, Robin Murphy wrote:
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu
26.01.2022, o godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after enabling the clock we set it in order for the hardware to
work as expected.
Warn on failure, in case this is a static clock that is slighty off.
Fixes hdmi-cec support on Rockchip devices.
Fixes: ebe32c3e282a ("drm/bridge: synopsys/dw-hdmi: Enable cec clock")
Signed-off-by: Peter Geis
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f..1a96da60e357 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -48,6 +48,9 @@
#define HDMI14_MAX_TMDSCLK 34000
+/* HDMI CEC needs a clock rate of 32khz */
+#define HDMI_CEC_CLK_RATE 32768
+
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -3347,6 +3350,10 @@ struct dw_hdmi *dw_hdmi_probe(struct
platform_device *pdev,
ret);
goto err_iahb;
}
+
+ ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
+ if (ret)
+ dev_warn(hdmi->dev, "Cannot set HDMI cec clock
rate: %d\n", ret);
}
/* Product and revision IDs */
--
2.25.1
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
Peter,
On my 5.17-rc7 with applied rk356x VOP2 v8 series - this patch makes
CEC working on rk3566.
Unfortunately it breaks working ok CEC on rk3399 rockpi-4b.
Reverting this patch brings back CEC on rk3399 - but rk3366 becomes
with non working CEC
I'm not sure how to move forward with this
I was worried about that, thanks for testing it.
Can you send me the cec_clk rate before and after this patch?
Hmm, looks like there might be a bug in the RK3399 clock driver -
although it's treated as having mux_pll_p as parents, according to the
public TRM the CEC clock appears unique in being backwards compared to
every other mux of those two inputs. I'm now tempted to test this on my
board tonight and see if I can see 24MHz on the CEC pin... :)
Nope, turns out that's an error in the TRM and the mux is fine. The bug
is between the clock driver blindly assuming xin32k is usable, and
nearly all RK3399 boards forgetting to claim the pinctrl to actually
enable the input :/
Robin.
[PATCH 2/2] drm: rcar-du: Add RZ/G2L DSI driver
This driver supports the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI mode only.
Signed-off-by: Biju Das
---
RFC->v1:
* Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
and dropped DRM as it is implied by DRM_BRIDGE
* Used devm_reset_control_get_exclusive() for reset handle
* Removed bool hsclkmode from struct rzg2l_mipi_dsi
* Added error check for pm, using pm_runtime_resume_and_get() instead of
pm_runtime_get_sync()
* Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
* Avoided read-modify-write stopping hsclock
* Used devm_platform_ioremap_resource for resource allocation
* Removed unnecessary assert call from probe and remove.
* wrap the line after the PTR_ERR() in probe()
* Updated reset failure messages in probe
* Fixed the typo arstc->prstc
* Made hex constants to lower case.
RFC:
*
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-23-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/Kconfig | 8 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 686 ++
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 147
4 files changed, 842 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 9e395d1f4572..fa5965dcad7a 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -64,6 +64,14 @@ config DRM_RCAR_MIPI_DSI
help
Enable support for the R-Car Display Unit embedded MIPI DSI encoders.
+config DRM_RZG2L_MIPI_DSI
+ tristate "RZ/G2L MIPI DSI Encoder Support"
+ depends on DRM_BRIDGE && OF
+ depends on ARCH_RENESAS || COMPILE_TEST
+ select DRM_MIPI_DSI
+ help
+ Enable support for the RZ/G2L Display Unit embedded MIPI DSI encoders.
+
config DRM_RCAR_VSP
bool "R-Car DU VSP Compositor Support" if ARM
default y if ARM64
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6580c78188f5..f2f2fe670e4d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
obj-$(CONFIG_DRM_RZG2L_LCDC) += rzg2l-lcdc-drm.o
+obj-$(CONFIG_DRM_RZG2L_MIPI_DSI) += rzg2l_mipi_dsi.o
# 'remote-endpoint' is fixed up at run-time
DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
new file mode 100644
index ..eb795c4b95bd
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
@@ -0,0 +1,686 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/G2L MIPI DSI Encoder Driver
+ *
+ * Copyright (C) 2022 Renesas Electronics Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rzg2l_mipi_dsi_regs.h"
+
+struct rzg2l_mipi_dsi {
+ struct device *dev;
+ void __iomem *link_mmio;
+ void __iomem *phy_mmio;
+
+ struct reset_control *rstc;
+ struct reset_control *arstc;
+ struct reset_control *prstc;
+
+ struct mipi_dsi_host host;
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+
+ struct clk *vclk;
+
+ enum mipi_dsi_pixel_format format;
+ unsigned int num_data_lanes;
+ unsigned int lanes;
+ unsigned long mode_flags;
+};
+
+static inline struct rzg2l_mipi_dsi *
+bridge_to_rzg2l_mipi_dsi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct rzg2l_mipi_dsi, bridge);
+}
+
+static inline struct rzg2l_mipi_dsi *
+host_to_rzg2l_mipi_dsi(struct mipi_dsi_host *host)
+{
+ return container_of(host, struct rzg2l_mipi_dsi, host);
+}
+
+static void rzg2l_mipi_dsi_write(void __iomem *mem, u32 reg, u32 data)
+{
+ iowrite32(data, mem + reg);
+}
+
+static u32 rzg2l_mipi_dsi_read(void __iomem *mem, u32 reg)
+{
+ return ioread32(mem + reg);
+}
+
+/*
-
+ * Hardware Setup
+ */
+
+static int rzg2l_mipi_dsi_startup(struct rzg2l_mipi_dsi *dsi,
+ const struct drm_display_mode *mode)
+{
+ unsigned long hsfreq;
+ u32 txsetr;
+ u32 clstptsetr;
+ u32 lptrnstsetr;
+ u8 max_num_lanes;
+ u32 clkkpt;
+ u32 clkbfht;
+ u32 clkstpt;
+ u32 golpbkt;
+ unsigned int bpp;
+ struct {
+ u32 tclk_miss;
+ u32 t_init;
+ u32 tclk_prepare;
+ u32 tclk_settle;
+
[PATCH 1/2] dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings
The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
can operate in DSI mode, with up to four data lanes.
Signed-off-by: Biju Das
---
RFC->v1:
* Added a ref to dsi-controller.yaml.
RFC:-
*
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-22-biju.das...@bp.renesas.com/
---
.../bindings/display/bridge/renesas,dsi.yaml | 146 ++
1 file changed, 146 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
new file mode 100644
index ..74bc3782d230
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/renesas,dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L MIPI DSI Encoder
+
+maintainers:
+ - Biju Das
+
+description: |
+ This binding describes the MIPI DSI encoder embedded in the Renesas
+ RZ/G2L family of SoC's. The encoder can operate in DSI mode with up
+ to four data lanes.
+
+allOf:
+ - $ref: ../dsi-controller.yaml#
+
+properties:
+ compatible:
+enum:
+ - renesas,rzg2l-mipi-dsi # RZ/G2L and RZ/V2L
+
+ reg:
+items:
+ - description: Link register
+ - description: D-PHY register
+
+ clocks:
+items:
+ - description: DSI D-PHY PLL multiplied clock
+ - description: DSI D-PHY system clock
+ - description: DSI AXI bus clock
+ - description: DSI Register access clock
+ - description: DSI Video clock
+ - description: DSI D_PHY Escape mode Receive clock
+
+ clock-names:
+items:
+ - const: pllclk
+ - const: sysclk
+ - const: aclk
+ - const: pclk
+ - const: vclk
+ - const: lpclk
+
+ power-domains:
+maxItems: 1
+
+ resets:
+items:
+ - description: MIPI_DSI_CMN_RSTB
+ - description: MIPI_DSI_ARESET_N
+ - description: MIPI_DSI_PRESET_N
+
+ reset-names:
+items:
+ - const: rst
+ - const: arst
+ - const: prst
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: DSI output port
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+ - data-lanes
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi0: dsi@1086 {
+compatible = "renesas,rzg2l-mipi-dsi";
+reg = <0x1086 0x1>,
+ <0x1085 0x1>;
+power-domains = <>;
+clocks = < CPG_MOD R9A07G044_MIPI_DSI_PLLCLK>,
+ < CPG_MOD R9A07G044_MIPI_DSI_SYSCLK>,
+ < CPG_MOD R9A07G044_MIPI_DSI_ACLK>,
+ < CPG_MOD R9A07G044_MIPI_DSI_PCLK>,
+ < CPG_MOD R9A07G044_MIPI_DSI_VCLK>,
+ < CPG_MOD R9A07G044_MIPI_DSI_LPCLK>;
+clock-names = "pllclk", "sysclk", "aclk", "pclk", "vclk", "lpclk";
+resets = < R9A07G044_MIPI_DSI_CMN_RSTB>,
+ < R9A07G044_MIPI_DSI_ARESET_N>,
+ < R9A07G044_MIPI_DSI_PRESET_N>;
+reset-names = "rst", "arst", "prst";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi0_in: endpoint {
+remote-endpoint = <_out_dsi0>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi0_out: endpoint {
+data-lanes = <1 2 3 4>;
+remote-endpoint = <_in>;
+};
+};
+};
+};
+...
--
2.17.1
[PATCH 0/2] Add RZ/G2L DSI driver
This patch series aims to support the MIPI DSI encoder found in the RZ/G2L SoC. It currently supports DSI mode only. This unit supports MIPI Alliance Specification for Display Serial Interface (DSI) Specification. This unit provides a solution for transmitting MIPI DSI compliant digital video and packets. Normative References are below. * MIPI Alliance Specification for Display Serial Interface Version 1.3.1 * MIPI Alliance Specification for D-PHY Version 2.1 The following are key features of this unit. * 1 channel * The number of Lane: 4-lane * Support up to Full HD (1920 × 1080), 60 fps (RGB888) * Maximum Bandwidth: 1.5 Gbps per lane * Support Output Data Format: RGB666 / RGB888 RFC->v1: * Added a ref to dsi-controller.yaml. * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG and dropped DRM as it is implied by DRM_BRIDGE * Used devm_reset_control_get_exclusive() for reset handle * Removed bool hsclkmode from struct rzg2l_mipi_dsi * Added error check for pm, using pm_runtime_resume_and_get() instead of pm_runtime_get_sync() * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach() * Avoided read-modify-write stopping hsclock * Used devm_platform_ioremap_resource for resource allocation * Removed unnecessary assert call from probe and remove. * wrap the line after the PTR_ERR() in probe() * Updated reset failure messages in probe * Fixed the typo arstc->prstc * Made hex constants to lower case. RFC: * https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-22-biju.das...@bp.renesas.com/ * https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-23-biju.das...@bp.renesas.com/ Biju Das (2): dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings drm: rcar-du: Add RZ/G2L DSI driver .../bindings/display/bridge/renesas,dsi.yaml | 146 drivers/gpu/drm/rcar-du/Kconfig | 8 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 686 ++ drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 147 5 files changed, 988 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h -- 2.17.1
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
On 12/03/2022 04:16, Matt Atwood wrote:
On Thu, Mar 10, 2022 at 12:26:12PM +, Tvrtko Ursulin wrote:
On 10/03/2022 05:18, Matt Atwood wrote:
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
v2: fix white space errors
Cc: Ashutosh Dixit
Cc: Matt Roper
Cc: Joonas Lahtinen
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_query.c | 68 ++-
include/uapi/drm/i915_drm.h | 24 +++
2 files changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..e4f35da28642 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_perf.h"
#include "i915_query.h"
+#include "gt/intel_engine_user.h"
#include
static int copy_query_item(void *query_hdr, size_t query_sz,
@@ -28,36 +29,30 @@ static int copy_query_item(void *query_hdr, size_t query_sz,
return 0;
}
-static int query_topology_info(struct drm_i915_private *dev_priv,
- struct drm_i915_query_item *query_item)
+static int fill_topology_info(const struct sseu_dev_info *sseu,
+ struct drm_i915_query_item *query_item,
+ const u8 *subslice_mask)
{
- const struct sseu_dev_info *sseu = _gt(dev_priv)->info.sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
int ret;
- if (query_item->flags != 0)
- return -EINVAL;
+ BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
if (sseu->max_slices == 0)
return -ENODEV;
- BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
-
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
- ret = copy_query_item(, sizeof(topo), total_length,
- query_item);
+ ret = copy_query_item(, sizeof(topo), total_length, query_item);
+
if (ret != 0)
return ret;
- if (topo.flags != 0)
- return -EINVAL;
-
memset(, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
@@ -69,27 +64,61 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.eu_stride = sseu->eu_stride;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
- , sizeof(topo)))
+, sizeof(topo)))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + sizeof(topo)),
- >slice_mask, slice_length))
+>slice_mask, slice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) + slice_length),
- sseu->subslice_mask, subslice_length))
+sizeof(topo) + slice_length),
+subslice_mask, subslice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) +
- slice_length + subslice_length),
- sseu->eu_mask, eu_length))
+sizeof(topo) +
+slice_length + subslice_length),
+sseu->eu_mask, eu_length))
return -EFAULT;
return total_length;
}
+static int query_topology_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu = _gt(dev_priv)->info.sseu;
+
+ if (query_item->flags != 0)
+ return -EINVAL;
+
+ return fill_topology_info(sseu, query_item, sseu->subslice_mask);
+}
+
+static int query_geometry_subslices(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu;
+ struct intel_engine_cs *engine;
+ u8 engine_class, engine_instance;
+
+ if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+ return -ENODEV;
+
+ engine_class = query_item->flags & 0xFF;
+ engine_instance
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Mon, 14 Mar 2022 10:23:27 -0400 Alex Deucher wrote: > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > Rob Clark wrote: > > > > > For something like just notifying a compositor that a gpu crash > > > happened, perhaps drm_event is more suitable. See > > > virtio_gpu_fence_event_create() for an example of adding new event > > > types. Although maybe you want it to be an event which is not device > > > specific. This isn't so much of a debugging use-case as simply > > > notification. > > > > Hi, > > > > for this particular use case, are we now talking about the display > > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? > > > > If the former, I wasn't aware that display device crashes are a thing. > > How should a userspace display server react to those? > > > > If the latter, don't we have EGL extensions or Vulkan API already to > > deliver that? > > > > The above would be about device crashes that directly affect the > > display server. Is that the use case in mind here, or is it instead > > about notifying the display server that some application has caused a > > driver/hardware crash? If the latter, how should a display server react > > to that? Disconnect the application? > > > > Shashank, what is the actual use case you are developing this for? > > > > I've read all the emails here so far, and I don't recall seeing it > > explained. > > > > The idea is that a support daemon or compositor would listen for GPU > reset notifications and do something useful with them (kill the guilty > app, restart the desktop environment, etc.). Today when the GPU > resets, most applications just continue assuming nothing is wrong, > meanwhile the GPU has stopped accepting work until the apps re-init > their context so all of their command submissions just get rejected. > > > Btw. somewhat relatedly, there has been work aiming to allow > > graceful hot-unplug of DRM devices. There is a kernel doc outlining how > > the various APIs should react towards userspace when a DRM device > > suddenly disappears. That seems to have some overlap here IMO. > > > > See > > https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug > > which also has a couple pointers to EGL and Vulkan APIs. > > The problem is most applications don't use the GL or VK robustness > APIs. Hi, how would this new event help with that? I mean, yeah, there could be a daemon that kills those GPU users, but then what? You still lose any unsaved work, and may need to manually restart them. Is the idea that it is better to have the app crash and disappear than to look like it froze while it otherwise still runs? If some daemon or compositor goes killing apps that trigger GPU resets, then how do we stop that for an app that actually does use the appropriate EGL or Vulkan APIs to detect and remedy that situation itself? > You could use something like that in the compositor, but those > APIs tend to be focused more on the application itself rather than the > GPU in general. E.g., Is my context lost. Which is fine for > restarting your context, but doesn't really help if you want to try > and do something with another application (i.e., the likely guilty > app). Also, on dGPU at least, when you reset the GPU, vram is usually > lost (either due to the memory controller being reset, or vram being > zero'd on init due to ECC support), so even if you are not the guilty > process, in that case you'd need to re-init your context anyway. Why should something like a compositor listen for this and kill apps that triggered GPU resets, instead of e.g. Mesa noticing that in the app and killing itself? Mesa in the app would know if robustness API is being used. Would be really nice to have the answers to all these questions to be collected and reiterated in the next version of this proposal. Thanks, pq pgpywmrz8z5sn.pgp Description: OpenPGP digital signature
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Mon, 14 Mar 2022 14:30:18 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> wrote:
> > Introduce fourcc codes for color-indexed frame buffer formats with two,
> > four, and sixteen colors, and provide a mapping from bit per pixel and
> > depth to fourcc codes.
> >
> > As the number of bits per pixel is less than eight, these rely on proper
> > block handling for the calculation of bits per pixel and pitch.
> >
> > Signed-off-by: Geert Uytterhoeven
>
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -99,7 +99,10 @@ extern "C" {
> > #define DRM_FORMAT_INVALID 0
> >
> > /* color index */
> > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C
> > */
> > +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /* [7:0]
> > C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> > +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /* [7:0]
> > C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> > +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /* [7:0]
> > C0:C1 4:4 two pixels/byte */
> > +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C
> > 8 one pixel/byte */
> >
> > /* 8 bpp Red */
> > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R
> > */
>
> After replying to Ilia's comment[1], I realized the CFB drawing
> operations use native byte and bit ordering, unless
> FBINFO_FOREIGN_ENDIAN is set.
> While Amiga, Atari, and Sun-3 use big-endian bit ordering,
> e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
> (sh7760fb configures ordering to match host order).
> BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
> guess they are broken on big-endian.
> Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
> on little-endian.
>
> Hence the above should become:
>
> #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
> [7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
> #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
> [7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
> #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
> [7:0] C1:C0 4:4 two pixels/byte */
>
> The same changes should be made for DRM_FORMAT_[RD][124].
>
> The fbdev emulation code should gain support for these with and without
> DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian platforms?
>
> [1]
> https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
> [2] See p.30 of the VIDC datasheet
>
> http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
> [3] See p.1178 of the SH7660 datasheet
>
> https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
Hi Geert,
why would CPU endianess affect the order of bits in a byte?
Do you mean that bit 0 one machine is (1 << 0), and on another machine
bit 0 is (1 << 7)?
In C, we have only one way to address bits of a byte and that is with
arithmetic. You cannot take the address of a bit any other way, can you?
Can we standardise on "bit n of a byte is addressed as (1 << n)"?
I don't mind in which order the pixels are inside a byte, as long as it
doesn't change by CPU endianess. If you need both directions, then use
two different drm_fourcc codes that do not change their meaning by CPU
endianess. Just like we have XRGB and BGRX formats.
I would not like to see DRM_FORMAT_BIG_ENDIAN used for this, it would
conflate a whole new concept into the mess that is little- vs.
big-endian.
Thanks,
pq
pgpFsKDfrZk04.pgp
Description: OpenPGP digital signature
Re: [PATCH 16/30] drm/sti: fix typos in comments
Hi Julia
thanks for the patch.
Reviewed-by: Alain Volmat
Alain
On Mon, Mar 14, 2022 at 12:53:40PM +0100, Julia Lawall wrote:
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/sti/sti_gdp.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index 3db3768a3241..b58415f2e4d8 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -406,7 +406,7 @@ static struct sti_gdp_node_list
> *sti_gdp_get_free_nodes(struct sti_gdp *gdp)
> (hw_nvn != gdp->node_list[i].top_field_paddr))
> return >node_list[i];
>
> - /* in hazardious cases restart with the first node */
> + /* in hazardous cases restart with the first node */
> DRM_ERROR("inconsistent NVN for %s: 0x%08X\n",
> sti_plane_to_str(>plane), hw_nvn);
>
>
RE: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk
> -Original Message-
> From: Doug Anderson
> Sent: Monday, March 14, 2022 7:28 PM
> To: dmitry.barysh...@linaro.org
> Cc: Vinod Polimera ; Stephen Boyd
> ; quic_vpolimer ;
> devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedr...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; robdcl...@gmail.com; quic_kalyant
>
> Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> rate property for mdp clk
>
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Hi,
>
> On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
> wrote:
> >
> > On Fri, 11 Mar 2022 at 11:06, Vinod Polimera
> wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Stephen Boyd
> > > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > > To: quic_vpolimer ;
> > > > devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > > freedr...@lists.freedesktop.org; linux-arm-...@vger.kernel.org
> > > > Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
> > > > diand...@chromium.org; quic_kalyant
> > > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-
> clock-
> > > > rate property for mdp clk
> > > >
> > > > WARNING: This email originated from outside of Qualcomm. Please be
> wary
> > > > of any links or attachments, and do not enable macros.
> > > >
> > > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > > Kernel clock driver assumes that initial rate is the
> > > > > max rate for that clock and was not allowing it to scale
> > > > > beyond the assigned clock value.
> > > >
> > > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies
> and
> > > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > > is preventing the frequency from changing beyond the assigned value.
> > >
> > > Folowing the comment of Stephen, i have checked a bit more. it appears
> that clock driver is not setting the max clock from assgined clocks, dpu
> driver
> is doing that.
> > > i am planning to fix it as below.
> > > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > > 2) remove unnecessary checks in the core_perf library. If rate doesn't
> match with the entries in the opp table, it will throw error, hence furthur
> checks are not needed.
> > > 3) no changes in dt are required. (we can drop all the posted ones)
> >
> > Why? They made perfect sense. The dts assignments should be replaced
> > by the opp setting in the bind function, as this would also set the
> > performance point of the respective power domain.
>
> Right. You should still _post_ the dts patches. It's nice to avoid
> unneeded "assigned-clocks" in the dts. The patch description should
> just be clear that it relies on the driver patch and shouldn't land /
> be backported without the driver patch.
>
>
- I have checked the latest msm/next based on your comment and found that
disp_io_util file
Is removed. From the latest origin, I have made changes to earlier patch series
to address the comments.
> > > Changes :
> > > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct
> drm_crtc *crtc)
> > > }
> > > }
> > >
> > > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64
> rate)
> > > -{
> > > - struct dss_clk *core_clk = kms->perf.core_clk;
> > > -
> > > - if (core_clk->max_rate && (rate > core_clk->max_rate))
> > > - rate = core_clk->max_rate;
> > > -
> > > - core_clk->rate = rate;
> > > - return dev_pm_opp_set_rate(>pdev->dev, core_clk->rate);
> > > -}
> > > -
> > > static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> > > {
> > > u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc
> *crtc,
> > >
> > > trace_dpu_core_perf_update_clk(kms->dev, stop_req,
> clk_rate);
> > >
> > > - ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > > + ret = dev_pm_opp_set_rate(>pdev->dev, clk_rate);
> > > if (ret) {
> > > DPU_ERROR("failed to set %s clock rate %llu\n",
> > > kms->perf.core_clk->clk_name,
> > > clk_rate);
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >
> > This file has been removed in msm/next
>
> To echo Dmitry, please make sure that your patch applies to msm-next,
> As I understand it, that means the branch msm-next on:
>
> https://gitlab.freedesktop.org/drm/msm.git
>
> -Doug
RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
> -Original Message- > From: Doug Anderson > Sent: Thursday, March 10, 2022 12:55 AM > To: quic_vpolimer > Cc: dri-devel ; linux-arm-msm m...@vger.kernel.org>; freedreno ; > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > ; LKML ; Rob > Clark ; Stephen Boyd ; > quic_kalyant > Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the > maximum frequency in opp table during probe > > WARNING: This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > Hi, > > On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera > wrote: > > > > use max clock during probe/bind sequence from the opp table. > > The clock will be scaled down when framework sends an update. > > > > Signed-off-by: Vinod Polimera > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++ > > 1 file changed, 3 insertions(+) > > In addition to Dmitry's requests, can you also make this patch #1 in > the series since the DTS stuff really ought to come _after_ this one. > > ...and actually, thinking about it further: > > 1. If we land this fix, we actually don't _need_ the dts patches, > right? Sure, the clock rate will get assigned before probe but then > we'll change it right away in probe, right? > > 2. If we land the dts patches _before_ the driver patch then it will > be a regression, right? > > 3. The dts patches and driver patch will probably land through > separate trees. The driver patch will go through the MSM DRM tree and > the device tree patches through the Qualcomm armsoc tree, right? > > > Assuming that the above is right, we should: > > 1. Put the driver patch first. > Moved driver patch first. > 2. Remove the "Fixes" tag on the dts patches. I guess in theory we > could have a FIxes tag on this patch? > - Removed fixed tag on dt patches and added on driver patch. > 3. Note in the dts patches commit messages that they depend on the driver > patch. > - Added dependency patch on driver patch for dt patch. > 4. Delay the dts patches until the driver change has made it to mainline. > > Does that sound reasonable?
RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
> -Original Message- > From: Dmitry Baryshkov > Sent: Tuesday, March 8, 2022 10:40 PM > To: quic_vpolimer > Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org; > swb...@chromium.org; quic_kalyant > Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the > maximum frequency in opp table during probe > > WARNING: This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > On Tue, 8 Mar 2022 at 19:55, Vinod Polimera > wrote: > > > > use max clock during probe/bind sequence from the opp table. > > The clock will be scaled down when framework sends an update. > > > > Signed-off-by: Vinod Polimera > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c > > index d550f90..d9922b9 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c > > @@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct > device *master, void *data) > > struct dpu_kms *dpu_kms; > > struct dss_module_power *mp; > > int ret = 0; > > + unsigned long max_freq = ULONG_MAX; > > > > dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), > GFP_KERNEL); > > if (!dpu_kms) > > @@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct > device *master, void *data) > > return ret; > > } > > > > + dev_pm_opp_find_freq_floor(dev, _freq); > > You leak a reference to the opp here. The function returns a value, > which should be dev_pm_opp_put(). > Moreover judging from the dev_pm_opp_set_rate() code I think you don't > have to find an exact frequency, as it will call > clk_round_rate()/_find_freq_ceil() anyway. > Could you please check that it works? clk_round_rate will get the max frequency in freq_table in clk driver and if that frequency is missing in opp table it will throw error. So, It will be optimal to get max freq in opp table and set it based on that freq. > > > + dev_pm_opp_set_rate(dev, max_freq); > > platform_set_drvdata(pdev, dpu_kms); > > > > ret = msm_kms_init(_kms->base, _funcs); > > -- > > 2.7.4 > > > > > -- > With best wishes > Dmitry
Re: [PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format
Hi Ilia,
On Mon, Mar 14, 2022 at 3:39 PM Ilia Mirkin wrote:
> On Mon, Mar 14, 2022 at 10:06 AM Geert Uytterhoeven
> wrote:
> > On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin wrote:
> > > On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven
> > > wrote:
> > > > On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> > > > wrote:
> > > > > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin
> > > > > wrote:
> > > > > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > > > > > wrote:
> > > > > > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > > > > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > > > > > --- a/tests/util/pattern.c
> > > > > > > +++ b/tests/util/pattern.c
> > > > > > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> > > > > > > util_rgb_info *rgb, void *mem,
> > > > > > > static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > > > > > static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12,
> > > > > > > 7 };
> > > > > > >
> > > > > > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned
> > > > > > > int pixel)
> > > > > > > +{
> > > > > > > + if (x & 1)
> > > > > > > + mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > > > > > + else
> > > > > > > + mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > > > > > +}
> > > > > >
> > > > > > The standard layout is MSB? i.e. first pixel goes in the upper bits
> > > > > > of
> > > > > > the first byte? It's been ages since I've dealt with C4 (or perhaps
> > > > > > I
> > > > > > never even touched it), but this seems a bit surprising.
> > > > Turns out I was wrong: fbdev ordering follows native ordering, and
> > > > there's also FBINFO_FOREIGN_ENDIAN :-(
> > >
> > > I haven't double-checked the meaning in fbdev, but ENDIAN-ness
> > > generally refers to the layout of *bytes*, not *bits*. Although one
> > > could also argue that it's the layout of "elements", and so in that
> > > way, upper/lower values could be considered flipped. I've never gone
> > > that far though.
> >
> > Yes, usually it refers to the ordering of bytes in a word.
> > Here, it's about the ordering of sub-byte pixels in a byte.
> > Note that with C2 and C4, there's a third ordering that comes into
> > play.
> > So we have:
> > 1. Ordering of bytes in a word, for bpp > 8,
> > 2. Ordering of pixels in a byte, for bpp < 8,
> > 3. Ordering of bits in a pixel, for bpp > 1.
> >
> > 1. Is handled by DRM_FORMAT_BIG_ENDIAN.
>
> OK. Note that DRM_FORMAT_BIG_ENDIAN flag for formats other than
> RGBX and very similar formats is basically broken in drm. So ...
> watch out. There are two setups supported for big-endian currently:
>
> 1. Legacy: radeon/nouveau, ignore the "little endian" comment about
> formats and only supports AddFB, not AddFB2. The former only has
> depth/bpp, not the actual format, anyways. This matches what current
> user-space expects too. (quirk_addfb_prefer_host_byte_order = 1)
> 2. AddFB2 support with proper formats. Only used for vmwgfx and virgl
> in practice for BE, IIRC. Only supports 32-bit 8bpc formats, and uses
> some helpers to just flip around DRM_FORMAT_BIG_ENDIAN bit to an
> equivalent format in the frontend api handling. This obviously won't
> work for other formats, but none of the helpers are ready to receive
> the BIG_ENDIAN bit.
I'm fully aware the DRM_FORMAT_BIG_ENDIAN flag is broken,
and it's on my list of things to fix (for 16-bpp Atari).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v6 2/5] arm64: dts: qcom: sm7280: remove assigned-clock-rate property for mdp clk
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on below patch https://patchwork.kernel.org/patch/12774067/ Signed-off-by: Vinod Polimera Reviewed-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index c07765d..a3c768c 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -3086,9 +3086,6 @@ "ahb", "core"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <3>; - interrupts = ; interrupt-controller; #interrupt-cells = <1>; @@ -3122,11 +3119,9 @@ "lut", "core", "vsync"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>, - < DISP_CC_MDSS_VSYNC_CLK>, + assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>, < DISP_CC_MDSS_AHB_CLK>; - assigned-clock-rates = <3>, - <1920>, + assigned-clock-rates = <1920>, <1920>; operating-points-v2 = <_opp_table>; power-domains = < SC7280_CX>; -- 2.7.4
[PATCH v6 3/5] arm64: dts: qcom: sm7180: remove assigned-clock-rate property for mdp clk
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on below patch https://patchwork.kernel.org/patch/12774067/ Signed-off-by: Vinod Polimera Reviewed-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index e1c46b8..eaab746 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -2900,9 +2900,6 @@ < DISP_CC_MDSS_MDP_CLK>; clock-names = "iface", "ahb", "core"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <3>; - interrupts = ; interrupt-controller; #interrupt-cells = <1>; @@ -2932,12 +2929,10 @@ < DISP_CC_MDSS_VSYNC_CLK>; clock-names = "bus", "iface", "rot", "lut", "core", "vsync"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>, - < DISP_CC_MDSS_VSYNC_CLK>, + assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>, < DISP_CC_MDSS_ROT_CLK>, < DISP_CC_MDSS_AHB_CLK>; - assigned-clock-rates = <3>, - <1920>, + assigned-clock-rates = <1920>, <1920>, <1920>; operating-points-v2 = <_opp_table>; -- 2.7.4
[PATCH v6 1/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe
use max clock during probe/bind sequence from the opp table.
The clock will be scaled down when framework sends an update.
Fixes: 25fdd5933("drm/msm: Add SDM845 DPU support")
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e29796c..9c346ce 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1202,7 +1202,9 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *ddev = priv->dev;
struct dpu_kms *dpu_kms;
+ struct dev_pm_opp *opp;
int ret = 0;
+ unsigned long max_freq = ULONG_MAX;
dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), GFP_KERNEL);
if (!dpu_kms)
@@ -1225,6 +1227,12 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
}
dpu_kms->num_clocks = ret;
+ opp = dev_pm_opp_find_freq_floor(dev, _freq);
+ if (!IS_ERR(opp))
+ dev_pm_opp_put(opp);
+
+ dev_pm_opp_set_rate(dev, max_freq);
+
platform_set_drvdata(pdev, dpu_kms);
ret = msm_kms_init(_kms->base, _funcs);
--
2.7.4
[PATCH v6 0/5] Update mdp clk to max supported value to support higher refresh rates
Drop the assigned clock rate property and vote on the mdp clock to max frequency during bind/probe sequence. Changes in v2: - Remove assigned-clock-rate property and set mdp clk during resume sequence. - Add fixes tag. Changes in v3: - Remove extra line after fixes tag.(Stephen Boyd) - Add similar changes for sc7180, sdm845 which uses opp table for voting mdp clk.(Stephen Boyd) - Drop patch: "drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table" Changes in v4: - Add similar change for sm8250.(Dmitry) Changes in v5: - Add change to set mdp clk to max frequency in opp table during mdp probe/bind. Changes in v6: - Remove change log in dt patch. - Fix the leak reference for opp by adding dev_pm_opp_put. (Dmitry) Vinod Polimera (5): drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe arm64: dts: qcom: sm7280: remove assigned-clock-rate property for mdp clk arm64: dts: qcom: sm7180: remove assigned-clock-rate property for mdp clk arm64: dts: qcom: sdm845: remove assigned-clock-rate property for mdp clk arm64: dts: qcom: sm8250: remove assigned-clock-rate property for mdp clk arch/arm64/boot/dts/qcom/sc7180.dtsi| 9 ++--- arch/arm64/boot/dts/qcom/sc7280.dtsi| 9 ++--- arch/arm64/boot/dts/qcom/sdm845.dtsi| 9 ++--- arch/arm64/boot/dts/qcom/sm8250.dtsi| 9 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 5 files changed, 16 insertions(+), 28 deletions(-) -- 2.7.4
[PATCH v6 4/5] arm64: dts: qcom: sdm845: remove assigned-clock-rate property for mdp clk
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on below patch https://patchwork.kernel.org/patch/12774067/ Signed-off-by: Vinod Polimera Reviewed-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index 41f4e46..c0771d2 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -4240,9 +4240,6 @@ < DISP_CC_MDSS_MDP_CLK>; clock-names = "iface", "core"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <3>; - interrupts = ; interrupt-controller; #interrupt-cells = <1>; @@ -4273,10 +4270,8 @@ < DISP_CC_MDSS_VSYNC_CLK>; clock-names = "gcc-bus", "iface", "bus", "core", "vsync"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>, - < DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates = <3>, - <1920>; + assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <1920>; operating-points-v2 = <_opp_table>; power-domains = < SDM845_CX>; -- 2.7.4
[PATCH v6 5/5] arm64: dts: qcom: sm8250: remove assigned-clock-rate property for mdp clk
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on below patch https://patchwork.kernel.org/patch/12774067/ Signed-off-by: Vinod Polimera Reviewed-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/sm8250.dtsi | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi index fdaf303..2105eb7 100644 --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi @@ -3164,9 +3164,6 @@ < DISP_CC_MDSS_MDP_CLK>; clock-names = "iface", "bus", "nrt_bus", "core"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <46000>; - interrupts = ; interrupt-controller; #interrupt-cells = <1>; @@ -3191,10 +3188,8 @@ < DISP_CC_MDSS_VSYNC_CLK>; clock-names = "iface", "bus", "core", "vsync"; - assigned-clocks = < DISP_CC_MDSS_MDP_CLK>, - < DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates = <46000>, - <1920>; + assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <1920>; operating-points-v2 = <_opp_table>; power-domains = < SM8250_MMCX>; -- 2.7.4
Re: [PATCH 1/2] dt-bindings: display: bridge: ldb: Implement simple NXP i.MX8M LDB bridge
On Sun, 13 Mar 2022 13:38:51 +0100, Marek Vasut wrote: > The i.MX8MP contains two syscon registers which are responsible > for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding > which represents this serializer as a bridge. > > Signed-off-by: Marek Vasut > Cc: Laurent Pinchart > Cc: Lucas Stach > Cc: Maxime Ripard > Cc: Peng Fan > Cc: Rob Herring > Cc: Robby Cai > Cc: Robert Foss > Cc: Sam Ravnborg > Cc: Thomas Zimmermann > Cc: devicet...@vger.kernel.org > To: dri-devel@lists.freedesktop.org > --- > .../bindings/display/bridge/nxp,ldb.yaml | 99 +++ > 1 file changed, 99 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/nxp,ldb.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/bridge/nxp,ldb.example.dt.yaml:0:0: /example-0/lvds-ldb: failed to match any schema with compatible: ['fsl,imx8mp-ldb'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1604767 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format
On Mon, Mar 14, 2022 at 10:06 AM Geert Uytterhoeven
wrote:
>
> Hi Ilia,
>
> On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin wrote:
> > On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven
> > wrote:
> > > On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> > > wrote:
> > > > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin
> > > > wrote:
> > > > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > > > > wrote:
> > > > > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > > > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > > > > --- a/tests/util/pattern.c
> > > > > > +++ b/tests/util/pattern.c
> > > > > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> > > > > > util_rgb_info *rgb, void *mem,
> > > > > > static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > > > > static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12, 7
> > > > > > };
> > > > > >
> > > > > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned
> > > > > > int pixel)
> > > > > > +{
> > > > > > + if (x & 1)
> > > > > > + mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > > > > + else
> > > > > > + mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > > > > +}
> > > > >
> > > > > The standard layout is MSB? i.e. first pixel goes in the upper bits of
> > > > > the first byte? It's been ages since I've dealt with C4 (or perhaps I
> > > > > never even touched it), but this seems a bit surprising.
> > > >
> > > > Exactly. All register documentation I've ever seen shows the MSB on
> > > > the left, i.e. for bytes:
> > > >
> > > > MSB LSB
> > > > +---+---+---+---+---+---+---+---+
> > > > | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> > > > +---+---+---+---+---+---+---+---+
> > > >
> > > > IBM used to count bits in the reverse order, but still had MSB left:
> > > >
> > > > MSB LSB
> > > > +---+---+---+---+---+---+---+---+
> > > > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> > > > +---+---+---+---+---+---+---+---+
> > > >
> > > > If the reverse ordering of pixels is ever needed, a new fourcc code can
> > > > be introduced. Note that the fbdev API has support for both orderings
> > > > (see fb_bitfield.msb_right), but no driver ever sets msb_right = 1,
> > > > hence the fbdev core doesn't support it yet.
> > >
> > > Turns out I was wrong: fbdev ordering follows native ordering, and
> > > there's also FBINFO_FOREIGN_ENDIAN :-(
> >
> > I haven't double-checked the meaning in fbdev, but ENDIAN-ness
> > generally refers to the layout of *bytes*, not *bits*. Although one
> > could also argue that it's the layout of "elements", and so in that
> > way, upper/lower values could be considered flipped. I've never gone
> > that far though.
>
> Yes, usually it refers to the ordering of bytes in a word.
> Here, it's about the ordering of sub-byte pixels in a byte.
> Note that with C2 and C4, there's a third ordering that comes into
> play.
> So we have:
> 1. Ordering of bytes in a word, for bpp > 8,
> 2. Ordering of pixels in a byte, for bpp < 8,
> 3. Ordering of bits in a pixel, for bpp > 1.
>
> 1. Is handled by DRM_FORMAT_BIG_ENDIAN.
OK. Note that DRM_FORMAT_BIG_ENDIAN flag for formats other than
RGBX and very similar formats is basically broken in drm. So ...
watch out. There are two setups supported for big-endian currently:
1. Legacy: radeon/nouveau, ignore the "little endian" comment about
formats and only supports AddFB, not AddFB2. The former only has
depth/bpp, not the actual format, anyways. This matches what current
user-space expects too. (quirk_addfb_prefer_host_byte_order = 1)
2. AddFB2 support with proper formats. Only used for vmwgfx and virgl
in practice for BE, IIRC. Only supports 32-bit 8bpc formats, and uses
some helpers to just flip around DRM_FORMAT_BIG_ENDIAN bit to an
equivalent format in the frontend api handling. This obviously won't
work for other formats, but none of the helpers are ready to receive
the BIG_ENDIAN bit.
Cheers,
-ilia
RE: [RFC 22/28] drm: rcar-du: Add RZ/G2L DSI driver
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [RFC 22/28] drm: rcar-du: Add RZ/G2L DSI driver
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Jan 12, 2022 at 05:46:06PM +, Biju Das wrote:
> > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > currently supports DSI mode only.
> >
> > Signed-off-by: Biju Das
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig | 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 676 ++
> > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151
> > 4 files changed, 835 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig index f6e6a6d5d987..ca87fb186f02
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -51,6 +51,13 @@ config DRM_RCAR_MIPI_DSI
> > help
> > Enable support for the R-Car Display Unit embedded MIPI DSI
> encoders.
> >
> > +config DRM_RZG2L_MIPI_DSI
> > + tristate "RZ/G2L MIPI DSI Encoder Support"
> > + depends on DRM && DRM_BRIDGE && OF
> > + select DRM_MIPI_DSI
> > + help
> > + Enable support for the RZ/G2L Display Unit embedded MIPI DSI
> encoders.
> > +
> > config DRM_RCAR_VSP
> > bool "R-Car DU VSP Compositor Support" if ARM
> > default y if ARM64
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index 286bc81b3e7c..3b5fd7610282 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
> > +obj-$(CONFIG_DRM_RZG2L_MIPI_DSI) += rzg2l_mipi_dsi.o
> >
> > # 'remote-endpoint' is fixed up at run-time
> > DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint diff --git
> > a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > new file mode 100644
> > index ..8a11fedd7cd7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > @@ -0,0 +1,676 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * RZ/G2L MIPI DSI Encoder Driver
> > + *
> > + * Copyright (C) 2021 Renesas Electronics Corporation */ #include
> > + #include #include #include
> > + #include #include
> > +#include #include #include
> > + #include #include
> > + #include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "rzg2l_mipi_dsi_regs.h"
> > +
> > +struct rzg2l_mipi_dsi {
> > + struct device *dev;
> > + void __iomem *link_mmio;
> > + void __iomem *phy_mmio;
> > +
> > + struct reset_control *rstc;
> > + struct reset_control *arstc;
> > + struct reset_control *prstc;
> > +
> > + struct mipi_dsi_host host;
> > + struct drm_bridge bridge;
> > + struct drm_bridge *next_bridge;
> > +
> > + struct clk *vclk;
> > +
> > + enum mipi_dsi_pixel_format format;
> > + unsigned int num_data_lanes;
> > + unsigned int lanes;
> > + unsigned long mode_flags;
> > +
> > + bool hsclkmode; /* 0 for non-continuous and 1 for continuous clock
> mode */
>
> Booleans should be true or false, not 0 or 1. A bool value named hsclkmode
> isn't very readable, without this comment, it's not easy to tell which
> value corresponds to which mode. I would drop this field, and replace its
> usage with mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS.
Agreed.
>
> > +};
> > +
> > +static inline struct rzg2l_mipi_dsi * bridge_to_rzg2l_mipi_dsi(struct
> > +drm_bridge *bridge) {
> > + return container_of(bridge, struct rzg2l_mipi_dsi, bridge); }
> > +
> > +static inline struct rzg2l_mipi_dsi * host_to_rzg2l_mipi_dsi(struct
> > +mipi_dsi_host *host) {
> > + return container_of(host, struct rzg2l_mipi_dsi, host); }
> > +
> > +static void rzg2l_mipi_dsi_write(void __iomem *mem, u32 reg, u32
> > +data) {
> > + iowrite32(data, mem + reg);
> > +}
> > +
> > +static u32 rzg2l_mipi_dsi_read(void __iomem *mem, u32 reg) {
> > + return ioread32(mem + reg);
> > +}
> > +
> > +static void rzg2l_mipi_dsi_clr(void __iomem *mem, u32 reg, u32 clr) {
> > + rzg2l_mipi_dsi_write(mem, reg, rzg2l_mipi_dsi_read(mem, reg) &
> > +~clr); }
> > +
> > +/*
> > +-
> > +
> > + * Hardware Setup
> > + */
> > +
> > +static int rzg2l_mipi_dsi_startup(struct rzg2l_mipi_dsi *dsi,
> > + const struct drm_display_mode *mode) {
> > + unsigned long hsfreq;
> > + u32 txsetr;
> > + u32 clstptsetr;
> > + u32 lptrnstsetr;
> > + u8
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > On Thu, 10 Mar 2022 11:56:41 -0800 > Rob Clark wrote: > > > For something like just notifying a compositor that a gpu crash > > happened, perhaps drm_event is more suitable. See > > virtio_gpu_fence_event_create() for an example of adding new event > > types. Although maybe you want it to be an event which is not device > > specific. This isn't so much of a debugging use-case as simply > > notification. > > Hi, > > for this particular use case, are we now talking about the display > device (KMS) crashing or the rendering device (OpenGL/Vulkan) crashing? > > If the former, I wasn't aware that display device crashes are a thing. > How should a userspace display server react to those? > > If the latter, don't we have EGL extensions or Vulkan API already to > deliver that? > > The above would be about device crashes that directly affect the > display server. Is that the use case in mind here, or is it instead > about notifying the display server that some application has caused a > driver/hardware crash? If the latter, how should a display server react > to that? Disconnect the application? > > Shashank, what is the actual use case you are developing this for? > > I've read all the emails here so far, and I don't recall seeing it > explained. > The idea is that a support daemon or compositor would listen for GPU reset notifications and do something useful with them (kill the guilty app, restart the desktop environment, etc.). Today when the GPU resets, most applications just continue assuming nothing is wrong, meanwhile the GPU has stopped accepting work until the apps re-init their context so all of their command submissions just get rejected. > Btw. somewhat relatedly, there has been work aiming to allow > graceful hot-unplug of DRM devices. There is a kernel doc outlining how > the various APIs should react towards userspace when a DRM device > suddenly disappears. That seems to have some overlap here IMO. > > See https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#device-hot-unplug > which also has a couple pointers to EGL and Vulkan APIs. The problem is most applications don't use the GL or VK robustness APIs. You could use something like that in the compositor, but those APIs tend to be focused more on the application itself rather than the GPU in general. E.g., Is my context lost. Which is fine for restarting your context, but doesn't really help if you want to try and do something with another application (i.e., the likely guilty app). Also, on dGPU at least, when you reset the GPU, vram is usually lost (either due to the memory controller being reset, or vram being zero'd on init due to ECC support), so even if you are not the guilty process, in that case you'd need to re-init your context anyway. Alex > > > Thanks, > pq
[PATCH v8 00/16] clk: provide new devm helpers for prepared and enabled clocks
Hello, this is another try to convince the relevant people that devm_clk_get_enabled() is a nice idea. Compared to v7 (back in May 2021) this series is rebased to v5.17-rc8 and converts quite some drivers that open code devm_clk_get_enabled() up to now (patches #3 - #11). A concern about devm_clk_get_enabled() in v7 was that it helps people to be lazy and I agree that in some situations when devm_clk_get_enabled() is used it would be more efficient and sensible to care to only enable the clk when really needed. On the other hand, the function is right for some users, e.g. the watchdog drivers. For the others it's not so simple to judge. Given that there are a lot of drivers that are lazy even if doing so is some effort (i.e. calling clk_prepare_enable() and devm_add_action()) convinces me, that introducing the function family is sensible. (And if you want to work on these drivers, grepping for devm_clk_get_enabled gives you a few candidates once the series is in :-) Otherwise looking at the diffstat of this series: 48 files changed, 257 insertions(+), 851 deletions(-) is quite convincing. Just the first two patches (which introduce the new functions) account for 2 files changed, 169 insertions(+), 17 deletions(-) . A rough third of the added lines is documentation. The rest is driver updates which then has: 46 files changed, 88 insertions(+), 834 deletions(-) which makes a really nice cleanup. The series is build-tested on arm64, m68k, powerpc, riscv, s390, sparc64 and x86_64 using an allmodconfig. Best regards Uwe Uwe Kleine-König (16): clk: generalize devm_clk_get() a bit clk: Provide new devm_clk helpers for prepared and enabled clocks hwmon: Make use of devm_clk_get_enabled() iio: Make use of devm_clk_get_enabled() hwrng: meson - Don't open-code devm_clk_get_optional_enabled() bus: bt1: Don't open code devm_clk_get_enabled() gpio: vf610: Simplify error handling in probe drm/meson: dw-hdmi: Don't open code devm_clk_get_enabled() rtc: ingenic: Simplify using devm_clk_get_enabled() clk: meson: axg-audio: Don't duplicate devm_clk_get_enabled() watchdog: Make use of devm_clk_get_enabled() pwm: atmel: Simplify using devm_clk_get_prepared() rtc: at91sam9: Simplify using devm_clk_get_enabled() i2c: imx: Simplify using devm_clk_get_enabled() spi: davinci: Simplify using devm_clk_get_enabled() dmaengine: lgm: Fix error handling drivers/bus/bt1-apb.c | 23 +-- drivers/bus/bt1-axi.c | 23 +-- drivers/char/hw_random/meson-rng.c| 20 +- drivers/clk/clk-devres.c | 96 ++- drivers/clk/meson/axg-audio.c | 36 ++ drivers/dma/lgm/lgm-dma.c | 8 +-- drivers/gpio/gpio-vf610.c | 45 +++-- drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +- drivers/hwmon/axi-fan-control.c | 15 + drivers/hwmon/ltc2947-core.c | 17 + drivers/hwmon/mr75203.c | 26 +--- drivers/hwmon/sparx5-temp.c | 19 +- drivers/i2c/busses/i2c-imx.c | 12 +--- drivers/iio/adc/ad7124.c | 15 + drivers/iio/adc/ad7768-1.c| 17 + drivers/iio/adc/ad9467.c | 17 + drivers/iio/adc/ingenic-adc.c | 15 + drivers/iio/adc/lpc18xx_adc.c | 18 + drivers/iio/adc/rockchip_saradc.c | 44 +--- drivers/iio/adc/ti-ads131e08.c| 19 +- drivers/iio/adc/xilinx-ams.c | 15 + drivers/iio/adc/xilinx-xadc-core.c| 18 + drivers/iio/frequency/adf4371.c | 17 + drivers/iio/frequency/admv1013.c | 15 + drivers/iio/frequency/adrf6780.c | 16 + drivers/iio/imu/adis16475.c | 15 + drivers/pwm/pwm-atmel.c | 16 + drivers/rtc/rtc-at91sam9.c| 22 ++ drivers/rtc/rtc-jz4740.c | 21 +- drivers/spi/spi-davinci.c | 11 +-- drivers/watchdog/cadence_wdt.c| 17 + drivers/watchdog/davinci_wdt.c| 18 + drivers/watchdog/imgpdc_wdt.c | 31 + drivers/watchdog/imx2_wdt.c | 15 + drivers/watchdog/imx7ulp_wdt.c| 15 + drivers/watchdog/loongson1_wdt.c | 17 + drivers/watchdog/lpc18xx_wdt.c| 30 + drivers/watchdog/meson_gxbb_wdt.c | 16 + drivers/watchdog/of_xilinx_wdt.c | 16 + drivers/watchdog/pic32-dmt.c | 15 + drivers/watchdog/pic32-wdt.c | 17 + drivers/watchdog/pnx4008_wdt.c| 15 + drivers/watchdog/qcom-wdt.c | 16 + drivers/watchdog/rtd119x_wdt.c| 16 + drivers/watchdog/st_lpc_wdt.c | 16 + drivers/watchdog/stm32_iwdg.c | 31 + drivers/watchdog/visconti_wdt.c | 18 + include/linux/clk.h | 90 - 48 files changed, 257 insertions(+), 851 deletions(-) base-commit:
[PATCH v8 02/16] clk: Provide new devm_clk helpers for prepared and enabled clocks
When a driver keeps a clock prepared (or enabled) during the whole
lifetime of the driver, these helpers allow to simplify the drivers.
Reviewed-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Signed-off-by: Uwe Kleine-König
---
drivers/clk/clk-devres.c | 31 ++
include/linux/clk.h | 90 +++-
2 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index fb7761888b30..4707fe718f0b 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -67,12 +67,43 @@ struct clk *devm_clk_get(struct device *dev, const char *id)
}
EXPORT_SYMBOL(devm_clk_get);
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id)
+{
+ return __devm_clk_get(dev, id, clk_get, clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_prepared);
+
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id)
+{
+ return __devm_clk_get(dev, id, clk_get,
+ clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_enabled);
+
struct clk *devm_clk_get_optional(struct device *dev, const char *id)
{
return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
}
EXPORT_SYMBOL(devm_clk_get_optional);
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const char *id)
+{
+ return __devm_clk_get(dev, id, clk_get_optional,
+ clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_prepared);
+
+struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id)
+{
+ return __devm_clk_get(dev, id, clk_get_optional,
+ clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_enabled);
+
struct clk_bulk_devres {
struct clk_bulk_data *clks;
int num_clks;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 266e8de3cb51..b011dbba7109 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -449,7 +449,7 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
* the clock producer. (IOW, @id may be identical strings, but
* clk_get may return different clock producers depending on @dev.)
*
- * Drivers must assume that the clock source is not enabled.
+ * Drivers must assume that the clock source is neither prepared nor enabled.
*
* devm_clk_get should not be called from within interrupt context.
*
@@ -458,6 +458,47 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
*/
struct clk *devm_clk_get(struct device *dev, const char *id);
+/**
+ * devm_clk_get_prepared - devm_clk_get() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno. The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer. (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared. Drivers must however assume that
the
+ * clock is not enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id);
+
+/**
+ * devm_clk_get_enabled - devm_clk_get() + clk_prepare_enable()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or valid IS_ERR()
+ * condition containing errno. The implementation uses @dev and @id to
+ * determine the clock consumer, and thereby the clock producer. (IOW, @id may
+ * be identical strings, but clk_get may return different clock producers
+ * depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared and enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be disabled, unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id);
+
/**
* devm_clk_get_optional - lookup and obtain a managed reference to an optional
*clock producer.
@@ -469,6 +510,29 @@ struct clk *devm_clk_get(struct device *dev, const char
*id);
*/
struct clk *devm_clk_get_optional(struct device *dev, const char *id);
+/**
+ * devm_clk_get_optional_prepared - devm_clk_get_optional() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Behaves the same as devm_clk_get_prepared() except where there is no clock
+ * producer. In this case, instead of returning -ENOENT, the function returns
+ * NULL.
+ */
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const
[PATCH v8 01/16] clk: generalize devm_clk_get() a bit
Allow to add an exit hook to devm managed clocks. Also use
clk_get_optional() in devm_clk_get_optional instead of open coding it.
The generalisation will be used in the next commit to add some more
devm_clk helpers.
Reviewed-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Signed-off-by: Uwe Kleine-König
---
drivers/clk/clk-devres.c | 67 ++--
1 file changed, 50 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index f9d5b7334341..fb7761888b30 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -4,39 +4,72 @@
#include
#include
+struct devm_clk_state {
+ struct clk *clk;
+ void (*exit)(struct clk *clk);
+};
+
static void devm_clk_release(struct device *dev, void *res)
{
- clk_put(*(struct clk **)res);
+ struct devm_clk_state *state = *(struct devm_clk_state **)res;
+
+ if (state->exit)
+ state->exit(state->clk);
+
+ clk_put(state->clk);
}
-struct clk *devm_clk_get(struct device *dev, const char *id)
+static struct clk *__devm_clk_get(struct device *dev, const char *id,
+ struct clk *(*get)(struct device *dev, const
char *id),
+ int (*init)(struct clk *clk),
+ void (*exit)(struct clk *clk))
{
- struct clk **ptr, *clk;
+ struct devm_clk_state *state;
+ struct clk *clk;
+ int ret;
- ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
+ state = devres_alloc(devm_clk_release, sizeof(*state), GFP_KERNEL);
+ if (!state)
return ERR_PTR(-ENOMEM);
- clk = clk_get(dev, id);
- if (!IS_ERR(clk)) {
- *ptr = clk;
- devres_add(dev, ptr);
- } else {
- devres_free(ptr);
+ clk = get(dev, id);
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ goto err_clk_get;
}
+ if (init) {
+ ret = init(clk);
+ if (ret)
+ goto err_clk_init;
+ }
+
+ state->clk = clk;
+ state->exit = exit;
+
+ devres_add(dev, state);
+
return clk;
+
+err_clk_init:
+
+ clk_put(clk);
+err_clk_get:
+
+ devres_free(state);
+ return ERR_PTR(ret);
}
-EXPORT_SYMBOL(devm_clk_get);
-struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+struct clk *devm_clk_get(struct device *dev, const char *id)
{
- struct clk *clk = devm_clk_get(dev, id);
+ return __devm_clk_get(dev, id, clk_get, NULL, NULL);
- if (clk == ERR_PTR(-ENOENT))
- return NULL;
+}
+EXPORT_SYMBOL(devm_clk_get);
- return clk;
+struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+{
+ return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
}
EXPORT_SYMBOL(devm_clk_get_optional);
--
2.35.1
[PATCH v8 08/16] drm/meson: dw-hdmi: Don't open code devm_clk_get_enabled()
devm_clk_get_enabled() returns a clock prepared and enabled and already
registers a devm exit handler to disable (and unprepare) the clock.
There is slight change in behavior as a failure to enable the clock
now results in an error message, too. Also the actual error code is added
to the message.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +--
1 file changed, 16 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 5cd2b2ebbbd3..6034e80c5b2e 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -670,29 +670,6 @@ static void meson_disable_regulator(void *data)
regulator_disable(data);
}
-static void meson_disable_clk(void *data)
-{
- clk_disable_unprepare(data);
-}
-
-static int meson_enable_clk(struct device *dev, char *name)
-{
- struct clk *clk;
- int ret;
-
- clk = devm_clk_get(dev, name);
- if (IS_ERR(clk)) {
- dev_err(dev, "Unable to get %s pclk\n", name);
- return PTR_ERR(clk);
- }
-
- ret = clk_prepare_enable(clk);
- if (!ret)
- ret = devm_add_action_or_reset(dev, meson_disable_clk, clk);
-
- return ret;
-}
-
static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -702,6 +679,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
struct drm_device *drm = data;
struct meson_drm *priv = drm->dev_private;
struct dw_hdmi_plat_data *dw_plat_data;
+ struct clk *clk;
int irq;
int ret;
@@ -763,17 +741,23 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
if (IS_ERR(meson_dw_hdmi->hdmitx))
return PTR_ERR(meson_dw_hdmi->hdmitx);
- ret = meson_enable_clk(dev, "isfr");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "isfr");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled isfr pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
- ret = meson_enable_clk(dev, "iahb");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "iahb");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled iahb pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
- ret = meson_enable_clk(dev, "venci");
- if (ret)
- return ret;
+ clk = devm_clk_get_enabled(dev, "venci");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get enabled venci pclk (%pe)\n", clk);
+ return PTR_ERR(clk);
+ }
dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
_dw_hdmi_regmap_config);
--
2.35.1
Re: [PATCH 2/4] drm/format-helper: Add drm_fb_gray8_to_mono_reversed()
Hello Geert, On 3/14/22 14:40, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas > wrote: >> Add support to convert 8-bit grayscale to reversed monochrome for drivers >> that control monochromatic displays, that only have 1 bit per pixel depth. >> >> This helper function was based on repaper_gray8_to_mono_reversed() from >> the drivers/gpu/drm/tiny/repaper.c driver. >> >> Signed-off-by: Javier Martinez Canillas > >> --- a/drivers/gpu/drm/drm_format_helper.c >> +++ b/drivers/gpu/drm/drm_format_helper.c >> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int >> dst_pitch, uint32_t dst_for >> return -EINVAL; >> } >> EXPORT_SYMBOL(drm_fb_blit_toio); >> + >> +/** >> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome >> + * @dst: reversed monochrome destination buffer > > What's the meaning of "reversed"? Originally I took this helper from the repaper driver and it was called repaper_gray8_to_mono_reversed(), so the naming just got carried over. > During the last few days, I've been balancing between (a) "reverse > video" and (b) "reverse bit order", but none of them seems to be true. > > (a) The code maps 0-127 to 0 and 8-255 to 1, which just reduces from > 256 to 2 grayscale levels, without inversion. The result is also > white-on-black on my ssd130x OLED. > (b) On little-endian, the CFB drawops use little-endian bit order, > which is what ends up in "byte" in the code below. > As far as I understand is (a) from the options since the repaper display uses black-on-white. But as you pointed out the ssd130x OLEDs instead do white-on-black. I should had probably just name the helper drm_fb_gray8_to_monochrome() or maybe drm_fb_gray8_to_gray1() ? -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format
Hi Ilia,
On Mon, Mar 14, 2022 at 2:44 PM Ilia Mirkin wrote:
> On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven
> wrote:
> > On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> > wrote:
> > > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin wrote:
> > > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > > > wrote:
> > > > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > > > --- a/tests/util/pattern.c
> > > > > +++ b/tests/util/pattern.c
> > > > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> > > > > util_rgb_info *rgb, void *mem,
> > > > > static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > > > static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12, 7 };
> > > > >
> > > > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned int
> > > > > pixel)
> > > > > +{
> > > > > + if (x & 1)
> > > > > + mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > > > + else
> > > > > + mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > > > +}
> > > >
> > > > The standard layout is MSB? i.e. first pixel goes in the upper bits of
> > > > the first byte? It's been ages since I've dealt with C4 (or perhaps I
> > > > never even touched it), but this seems a bit surprising.
> > >
> > > Exactly. All register documentation I've ever seen shows the MSB on
> > > the left, i.e. for bytes:
> > >
> > > MSB LSB
> > > +---+---+---+---+---+---+---+---+
> > > | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> > > +---+---+---+---+---+---+---+---+
> > >
> > > IBM used to count bits in the reverse order, but still had MSB left:
> > >
> > > MSB LSB
> > > +---+---+---+---+---+---+---+---+
> > > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> > > +---+---+---+---+---+---+---+---+
> > >
> > > If the reverse ordering of pixels is ever needed, a new fourcc code can
> > > be introduced. Note that the fbdev API has support for both orderings
> > > (see fb_bitfield.msb_right), but no driver ever sets msb_right = 1,
> > > hence the fbdev core doesn't support it yet.
> >
> > Turns out I was wrong: fbdev ordering follows native ordering, and
> > there's also FBINFO_FOREIGN_ENDIAN :-(
>
> I haven't double-checked the meaning in fbdev, but ENDIAN-ness
> generally refers to the layout of *bytes*, not *bits*. Although one
> could also argue that it's the layout of "elements", and so in that
> way, upper/lower values could be considered flipped. I've never gone
> that far though.
Yes, usually it refers to the ordering of bytes in a word.
Here, it's about the ordering of sub-byte pixels in a byte.
Note that with C2 and C4, there's a third ordering that comes into
play.
So we have:
1. Ordering of bytes in a word, for bpp > 8,
2. Ordering of pixels in a byte, for bpp < 8,
3. Ordering of bits in a pixel, for bpp > 1.
1. Is handled by DRM_FORMAT_BIG_ENDIAN.
2. Is what we need to handle here.
As bpp cannot be both < 8 and > 8, I think reusing
DRM_FORMAT_BIG_ENDIAN is OK.
3. Is handled by fb_bitfield.msb_right, and always false
(i.e. no driver ever set it).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc
On 11.03.2022 10:40, Lucas De Marchi wrote: > On Tue, Mar 08, 2022 at 10:17:42PM +0530, Balasubramani Vivekanandan wrote: > > This patch is continuation of the effort to move all pointers in i915, > > which at any point may be pointing to device memory or system memory, to > > iosys_map interface. > > More details about the need of this change is explained in the patch > > series which initiated this task > > https://patchwork.freedesktop.org/series/99711/ > > > > This patch converts all access to the lrc_desc through iosys_map > > interfaces. > > > > Cc: Lucas De Marchi > > Cc: John Harrison > > Cc: Matthew Brost > > Cc: Umesh Nerlige Ramappa > > Signed-off-by: Balasubramani Vivekanandan > > > > --- > > ... > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > @@ -2245,13 +2256,13 @@ static void > > prepare_context_registration_info(struct intel_context *ce) > > GEM_BUG_ON(i915_gem_object_is_lmem(guc->ct.vma->obj) != > >i915_gem_object_is_lmem(ce->ring->vma->obj)); > > > > - desc = __get_lrc_desc(guc, ctx_id); > > - desc->engine_class = engine_class_to_guc_class(engine->class); > > - desc->engine_submit_mask = engine->logical_mask; > > - desc->hw_context_desc = ce->lrc.lrca; > > - desc->priority = ce->guc_state.prio; > > - desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD; > > - guc_context_policy_init(engine, desc); > > + memset(, 0, sizeof(desc)); > > previously we would re-use whatever was left in > guc->lrc_desc_pool_vaddr. Here we are changing it to always zero > everything and set the fields we are interested in. > > As I'm not too familiar with this part and I see us traversing child > guc_process_desc > which may point to the same id, it doesn't _feel_ safe. Did you check if > this is not zero'ing what it shouldn't? > > Matt Brost / John / Daniele, could you clarify? > > thanks > Lucas De Marchi I verified that struct guc_lrc_desc is not updated anywhere else in the driver other than in prepare_context_registration_info. So I went ahead with clearing it before updating the fields. But I will still wait for comments from Matt Brost/ John / Daniele for their confirmation. Thanks Bala
Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk
Hi,
On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
wrote:
>
> On Fri, 11 Mar 2022 at 11:06, Vinod Polimera
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Stephen Boyd
> > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > To: quic_vpolimer ;
> > > devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > freedr...@lists.freedesktop.org; linux-arm-...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
> > > diand...@chromium.org; quic_kalyant
> > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > > rate property for mdp clk
> > >
> > > WARNING: This email originated from outside of Qualcomm. Please be wary
> > > of any links or attachments, and do not enable macros.
> > >
> > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > Kernel clock driver assumes that initial rate is the
> > > > max rate for that clock and was not allowing it to scale
> > > > beyond the assigned clock value.
> > >
> > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > is preventing the frequency from changing beyond the assigned value.
> >
> > Folowing the comment of Stephen, i have checked a bit more. it appears that
> > clock driver is not setting the max clock from assgined clocks, dpu driver
> > is doing that.
> > i am planning to fix it as below.
> > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > 2) remove unnecessary checks in the core_perf library. If rate doesn't
> > match with the entries in the opp table, it will throw error, hence furthur
> > checks are not needed.
> > 3) no changes in dt are required. (we can drop all the posted ones)
>
> Why? They made perfect sense. The dts assignments should be replaced
> by the opp setting in the bind function, as this would also set the
> performance point of the respective power domain.
Right. You should still _post_ the dts patches. It's nice to avoid
unneeded "assigned-clocks" in the dts. The patch description should
just be clear that it relies on the driver patch and shouldn't land /
be backported without the driver patch.
> > Changes :
> > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc
> > *crtc)
> > }
> > }
> >
> > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> > -{
> > - struct dss_clk *core_clk = kms->perf.core_clk;
> > -
> > - if (core_clk->max_rate && (rate > core_clk->max_rate))
> > - rate = core_clk->max_rate;
> > -
> > - core_clk->rate = rate;
> > - return dev_pm_opp_set_rate(>pdev->dev, core_clk->rate);
> > -}
> > -
> > static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> > {
> > u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> >
> > trace_dpu_core_perf_update_clk(kms->dev, stop_req,
> > clk_rate);
> >
> > - ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > + ret = dev_pm_opp_set_rate(>pdev->dev, clk_rate);
> > if (ret) {
> > DPU_ERROR("failed to set %s clock rate %llu\n",
> > kms->perf.core_clk->clk_name,
> > clk_rate);
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
>
> This file has been removed in msm/next
To echo Dmitry, please make sure that your patch applies to msm-next,
As I understand it, that means the branch msm-next on:
https://gitlab.freedesktop.org/drm/msm.git
-Doug
Re: [PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format
On Mon, Mar 14, 2022 at 9:07 AM Geert Uytterhoeven wrote:
>
> Hi Ilia,
>
> On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven
> wrote:
> > On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin wrote:
> > > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > > wrote:
> > > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > > --- a/tests/util/pattern.c
> > > > +++ b/tests/util/pattern.c
> > > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> > > > util_rgb_info *rgb, void *mem,
> > > > static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > > static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12, 7 };
> > > >
> > > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned int
> > > > pixel)
> > > > +{
> > > > + if (x & 1)
> > > > + mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > > + else
> > > > + mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > > +}
> > >
> > > The standard layout is MSB? i.e. first pixel goes in the upper bits of
> > > the first byte? It's been ages since I've dealt with C4 (or perhaps I
> > > never even touched it), but this seems a bit surprising.
> >
> > Exactly. All register documentation I've ever seen shows the MSB on
> > the left, i.e. for bytes:
> >
> > MSB LSB
> > +---+---+---+---+---+---+---+---+
> > | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> > +---+---+---+---+---+---+---+---+
> >
> > IBM used to count bits in the reverse order, but still had MSB left:
> >
> > MSB LSB
> > +---+---+---+---+---+---+---+---+
> > | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> > +---+---+---+---+---+---+---+---+
> >
> > If the reverse ordering of pixels is ever needed, a new fourcc code can
> > be introduced. Note that the fbdev API has support for both orderings
> > (see fb_bitfield.msb_right), but no driver ever sets msb_right = 1,
> > hence the fbdev core doesn't support it yet.
>
> Turns out I was wrong: fbdev ordering follows native ordering, and
> there's also FBINFO_FOREIGN_ENDIAN :-(
I haven't double-checked the meaning in fbdev, but ENDIAN-ness
generally refers to the layout of *bytes*, not *bits*. Although one
could also argue that it's the layout of "elements", and so in that
way, upper/lower values could be considered flipped. I've never gone
that far though.
Cheers,
-ilia
Re: [PATCH 2/4] drm/format-helper: Add drm_fb_gray8_to_mono_reversed()
Hi Javier,
On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
wrote:
> Add support to convert 8-bit grayscale to reversed monochrome for drivers
> that control monochromatic displays, that only have 1 bit per pixel depth.
>
> This helper function was based on repaper_gray8_to_mono_reversed() from
> the drivers/gpu/drm/tiny/repaper.c driver.
>
> Signed-off-by: Javier Martinez Canillas
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -584,3 +584,38 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
> +
> +/**
> + * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
> + * @dst: reversed monochrome destination buffer
What's the meaning of "reversed"?
During the last few days, I've been balancing between (a) "reverse
video" and (b) "reverse bit order", but none of them seems to be true.
(a) The code maps 0-127 to 0 and 8-255 to 1, which just reduces from
256 to 2 grayscale levels, without inversion. The result is also
white-on-black on my ssd130x OLED.
(b) On little-endian, the CFB drawops use little-endian bit order,
which is what ends up in "byte" in the code below.
> + * @src: 8-bit grayscale source buffer
> + * @clip: Clip rectangle area to copy
> + *
> + * DRM doesn't have native monochrome or grayscale support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use drm_fb_xrgb_to_gray8() to convert to grayscale and then this
> + * helper function to convert to the native format.
> + */
> +void drm_fb_gray8_to_mono_reversed(void *dst, void *src, const struct
> drm_rect *clip)
> +{
> + size_t width = drm_rect_width(clip);
> + size_t height = drm_rect_width(clip);
> +
> + u8 *mono = dst, *gray8 = src;
> + unsigned int y, xb, i;
> +
> + for (y = 0; y < height; y++)
> + for (xb = 0; xb < width / 8; xb++) {
> + u8 byte = 0x00;
> +
> + for (i = 0; i < 8; i++) {
> + int x = xb * 8 + i;
> +
> + byte >>= 1;
> + if (gray8[y * width + x] >> 7)
> + byte |= BIT(7);
> + }
> + *mono++ = byte;
> + }
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v7 22/24] drm: rockchip: Add VOP2 driver
Hi Andy, On Mon, 14 Mar 2022 at 11:02, Andy Yan wrote: >Remember you said our downstream vop2 driver is very slow on weston. > > Would you please share the case you run ? or how can i test frame rate > on weston? We were able to observe this by just using either waylandsink (using dmabuf from the V4L2 rkvdec/rkvpu drivers), or even weston-simple-egl. I have not been able to do a full review of Sascha's submission, but from what I've seen of it, it should have fixed those issues. (I don't have RK3568 hardware to hand anymore.) Cheers, Daniel
Re: [PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_C[124]
On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven wrote:
> Introduce fourcc codes for color-indexed frame buffer formats with two,
> four, and sixteen colors, and provide a mapping from bit per pixel and
> depth to fourcc codes.
>
> As the number of bits per pixel is less than eight, these rely on proper
> block handling for the calculation of bits per pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -99,7 +99,10 @@ extern "C" {
> #define DRM_FORMAT_INVALID 0
>
> /* color index */
> -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
> +#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /* [7:0]
> C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte */
> +#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /* [7:0]
> C0:C1:C2:C3 2:2:2:2 four pixels/byte */
> +#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /* [7:0]
> C0:C1 4:4 two pixels/byte */
> +#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C 8
> one pixel/byte */
>
> /* 8 bpp Red */
> #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
After replying to Ilia's comment[1], I realized the CFB drawing
operations use native byte and bit ordering, unless
FBINFO_FOREIGN_ENDIAN is set.
While Amiga, Atari, and Sun-3 use big-endian bit ordering,
e.g. Acorn VIDC[2] uses little endian, and SH7760[3] is configurable
(sh7760fb configures ordering to match host order).
BTW, ssd130{7fb,x}_update_rect() both assume little-endian, so I
guess they are broken on big-endian.
Fbtest uses big-endian bit ordering, so < 8 bpp is probably broken
on little-endian.
Hence the above should become:
#define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ') /*
[7:0] C7:C6:C5:C4:C3:C2:C1:C0 1:1:1:1:1:1:1:1 eight pixels/byte */
#define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ') /*
[7:0] C3:C2:C1:C0 2:2:2:2 four pixels/byte */
#define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ') /*
[7:0] C1:C0 4:4 two pixels/byte */
The same changes should be made for DRM_FORMAT_[RD][124].
The fbdev emulation code should gain support for these with and without
DRM_FORMAT_BIG_ENDIAN, the latter perhaps only on big-endian platforms?
[1]
https://lore.kernel.org/r/CAKb7UvgEdm9U=+ryrwl0tgrfa_qc7nbhcwozoft2dkdxggt...@mail.gmail.com/
[2] See p.30 of the VIDC datasheet
http://chrisacorns.computinghistory.org.uk/docs/Acorn/Misc/Acorn_VIDC_Datasheet.pdf
[3] See p.1178 of the SH7660 datasheet
https://datasheet.octopart.com/HD6417760BL200AV-Renesas-datasheet-14105759.pdf
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH libdrm 3/3] util: Add SMPTE pattern support for C4 format
Hi Ilia,
On Tue, Mar 8, 2022 at 8:57 AM Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2022 at 10:23 PM Ilia Mirkin wrote:
> > On Mon, Mar 7, 2022 at 3:53 PM Geert Uytterhoeven
> > wrote:
> > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> > > index 953bf95492ee150c..42d75d700700dc3d 100644
> > > --- a/tests/util/pattern.c
> > > +++ b/tests/util/pattern.c
> > > @@ -608,6 +608,46 @@ static void fill_smpte_rgb16fp(const struct
> > > util_rgb_info *rgb, void *mem,
> > > static unsigned int smpte_middle[7] = { 6, 7, 4, 7, 2, 7, 0 };
> > > static unsigned int smpte_bottom[8] = { 8, 9, 10, 7, 11, 7, 12, 7 };
> > >
> > > +static void write_pixel_4(uint8_t *mem, unsigned int x, unsigned int
> > > pixel)
> > > +{
> > > + if (x & 1)
> > > + mem[x / 2] = (mem[x / 2] & 0xf0) | (pixel & 0x0f);
> > > + else
> > > + mem[x / 2] = (mem[x / 2] & 0x0f) | (pixel << 4);
> > > +}
> >
> > The standard layout is MSB? i.e. first pixel goes in the upper bits of
> > the first byte? It's been ages since I've dealt with C4 (or perhaps I
> > never even touched it), but this seems a bit surprising.
>
> Exactly. All register documentation I've ever seen shows the MSB on
> the left, i.e. for bytes:
>
> MSB LSB
> +---+---+---+---+---+---+---+---+
> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> +---+---+---+---+---+---+---+---+
>
> IBM used to count bits in the reverse order, but still had MSB left:
>
> MSB LSB
> +---+---+---+---+---+---+---+---+
> | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
> +---+---+---+---+---+---+---+---+
>
> If the reverse ordering of pixels is ever needed, a new fourcc code can
> be introduced. Note that the fbdev API has support for both orderings
> (see fb_bitfield.msb_right), but no driver ever sets msb_right = 1,
> hence the fbdev core doesn't support it yet.
Turns out I was wrong: fbdev ordering follows native ordering, and
there's also FBINFO_FOREIGN_ENDIAN :-(
I'll reply to the thread that introduced the format.
https://lore.kernel.org/all/8d3c0cc370b0214244b01a64c588e5e506531716.1646683502.git.ge...@linux-m68k.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re:[PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Hi Sascha Hauer From: Sascha Hauer Date: 2022-03-11 16:33:21 To: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org,linux-rockc...@lists.infradead.org,devicet...@vger.kernel.org,ker...@pengutronix.de,Andy Yan ,Benjamin Gaignard ,Michael Riesch ,Sandy Huang ,"Heiko Stübner" ,Peter Geis ,Sascha Hauer Subject: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver>From: Andy Yan > >The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. >It replaces the VOP unit found in the older Rockchip SoCs. > >This driver has been derived from the downstream Rockchip Kernel and >heavily modified: > >- All nonstandard DRM properties have been removed >- dropped struct vop2_plane_state and pass around less data between > functions >- Dropped all DRM_FORMAT_* not known on upstream >- rework register access to get rid of excessively used macros >- Drop all waiting for framesyncs > >The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB >board. Overlay support is tested with the modetest utility. AFBC support >on the cluster windows is tested with weston-simple-dmabuf-egl on >weston using the (yet to be upstreamed) panfrost driver support. > >Signed-off-by: Andy Yan >Signed-off-by: Sascha Hauer >--- > >Notes: >Changes since v6: >- Drop device tree parsing during runtime >- Fix typo in Kconfig help text > >Changes since v5: >- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t >- Use spin_lock rather than spin_lock_irqsave >- replace printk with drm_dbg >- break some overlong lines > >Changes since v4: >- Avoid stack frame overflow by not allocating big array on the stack > >Changes since v3: >- Sort includes >- fix typos >- Drop spinlock >- Use regmap_set_bits()/regmap_clear_bits() >- simplify vop2_scale_factor() >- simplify vop2_afbc_transform_offset() > >Changes since v4: >- Sort nodes alphabetically > >Changes since v3: >- Fix HDMI connector type > >Changes since v4: >- Add Robs Ack > >Changes since v3: >- Bring back gamma_lut regs >- Drop redundant _vop suffix from clock names > >Changes since v5: >- Drop unnecessary #size-cells/#address-cells from nodes with only single > endpoint > >Changes since v5: >- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t >- Use spin_lock rather than spin_lock_irqsave >- replace printk with drm_dbg >- break some overlong lines > >Changes since v4: >- Avoid stack frame overflow by not allocating big array on the stack > >Changes since v3: >- Sort includes >- fix typos >- Drop spinlock >- Use regmap_set_bits()/regmap_clear_bits() >- simplify vop2_scale_factor() >- simplify vop2_afbc_transform_offset() > >Changes since v4: >- Sort nodes alphabetically > >Changes since v3: >- Fix HDMI connector type > > drivers/gpu/drm/rockchip/Kconfig |6 + > drivers/gpu/drm/rockchip/Makefile|1 + > drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 + > drivers/gpu/drm/rockchip/rockchip_drm_drv.h |6 +- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c |2 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 + > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2686 ++ > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 477 > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 281 ++ > 9 files changed, 3474 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c > >diff --git a/drivers/gpu/drm/rockchip/Kconfig >b/drivers/gpu/drm/rockchip/Kconfig >index b9b156308460a..f033971103610 100644 >--- a/drivers/gpu/drm/rockchip/Kconfig >+++ b/drivers/gpu/drm/rockchip/Kconfig >@@ -28,6 +28,12 @@ config ROCKCHIP_VOP > This selects support for the VOP driver. You should enable it > on all older SoCs up to RK3399. > >+config ROCKCHIP_VOP2 >+ bool "Rockchip VOP2 driver" >+ help >+This selects support for the VOP2 driver. You should enable it >+on all newer SoCs beginning from RK3568. >+ rockchip newer SoCs maybe still use the old vop driver, and we are designing the next VOP, i am not sure if we will use the vop2 driver. so we can't say: "You should enable it on all newer SoCs beginning from RK3568." thanks, sandy. > config ROCKCHIP_ANALOGIX_DP > bool "Rockchip specific extensions for Analogix DP driver" > depends on ROCKCHIP_VOP >diff --git a/drivers/gpu/drm/rockchip/Makefile >b/drivers/gpu/drm/rockchip/Makefile >index dfc5512fdb9f1..3ff7b21c04149 100644 >--- a/drivers/gpu/drm/rockchip/Makefile >+++ b/drivers/gpu/drm/rockchip/Makefile >@@ -6,6 +6,7 @@ > rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ >
Re: [PATCH] drm/msm/gpu: Fix crash on devices without devfreq support
Hi Rob and Linus,
On Mon, 7 Mar 2022 at 14:07, Naresh Kamboju wrote:
>
> Hi Rob,
>
> On Sun, 20 Feb 2022 at 00:02, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Avoid going down devfreq paths on devices where devfreq is not
> > initialized.
> >
> > Reported-by: Linux Kernel Functional Testing
> > Reported-by: Anders Roxell
> > Signed-off-by: Rob Clark
>
> I have tested this patch and the reported kernel crash is fixed [1].
>
> Tested-by: Linux Kernel Functional Testing
>
> > ---
> > drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31 +--
> > 1 file changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > index 9bf319be11f6..26a3669a97b3 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > @@ -83,12 +83,17 @@ static struct devfreq_dev_profile msm_devfreq_profile =
> > {
> > static void msm_devfreq_boost_work(struct kthread_work *work);
> > static void msm_devfreq_idle_work(struct kthread_work *work);
> >
> > +static bool has_devfreq(struct msm_gpu *gpu)
> > +{
> > + return !!gpu->funcs->gpu_busy;
> > +}
> > +
> > void msm_devfreq_init(struct msm_gpu *gpu)
> > {
> > struct msm_gpu_devfreq *df = >devfreq;
> >
> > /* We need target support to do devfreq */
> > - if (!gpu->funcs->gpu_busy)
> > + if (!has_devfreq(gpu))
> > return;
> >
> > dev_pm_qos_add_request(>pdev->dev, >idle_freq,
> > @@ -149,6 +154,9 @@ void msm_devfreq_cleanup(struct msm_gpu *gpu)
> > {
> > struct msm_gpu_devfreq *df = >devfreq;
> >
> > + if (!has_devfreq(gpu))
> > + return;
> > +
> > devfreq_cooling_unregister(gpu->cooling);
> > dev_pm_qos_remove_request(>boost_freq);
> > dev_pm_qos_remove_request(>idle_freq);
> > @@ -156,16 +164,24 @@ void msm_devfreq_cleanup(struct msm_gpu *gpu)
> >
> > void msm_devfreq_resume(struct msm_gpu *gpu)
> > {
> > - gpu->devfreq.busy_cycles = 0;
> > - gpu->devfreq.time = ktime_get();
> > + struct msm_gpu_devfreq *df = >devfreq;
> >
> > - devfreq_resume_device(gpu->devfreq.devfreq);
> > + if (!has_devfreq(gpu))
> > + return;
> > +
> > + df->busy_cycles = 0;
> > + df->time = ktime_get();
> > +
> > + devfreq_resume_device(df->devfreq);
> > }
> >
> > void msm_devfreq_suspend(struct msm_gpu *gpu)
> > {
> > struct msm_gpu_devfreq *df = >devfreq;
> >
> > + if (!has_devfreq(gpu))
> > + return;
> > +
> > devfreq_suspend_device(df->devfreq);
> >
> > cancel_idle_work(df);
> > @@ -185,6 +201,9 @@ void msm_devfreq_boost(struct msm_gpu *gpu, unsigned
> > factor)
> > struct msm_gpu_devfreq *df = >devfreq;
> > uint64_t freq;
> >
> > + if (!has_devfreq(gpu))
> > + return;
> > +
> > freq = get_freq(gpu);
> > freq *= factor;
> >
> > @@ -207,7 +226,7 @@ void msm_devfreq_active(struct msm_gpu *gpu)
> > struct devfreq_dev_status status;
> > unsigned int idle_time;
> >
> > - if (!df->devfreq)
> > + if (!has_devfreq(gpu))
> > return;
> >
> > /*
> > @@ -253,7 +272,7 @@ void msm_devfreq_idle(struct msm_gpu *gpu)
> > {
> > struct msm_gpu_devfreq *df = >devfreq;
> >
> > - if (!df->devfreq)
> > + if (!has_devfreq(gpu))
> > return;
> >
> > msm_hrtimer_queue_work(>idle_work, ms_to_ktime(1),
FYI,
This patch is missing on Linux 5.17-rc8 [1].
kernel crash log on arm64 db410c device [2] and details [3].
metadata:
git_describe: v5.17-rc8
git_ref: master
git_repo: https://gitlab.com/Linaro/lkft/mirrors/torvalds/linux-mainline
git_sha: 09688c0166e76ce2fb85e86b9d99be8b0084cdf9
kernel-config: https://builds.tuxbuild.com/26LbbVLHqxjh5w5ZtjBMjGmh92P/config
build: https://builds.tuxbuild.com/26LbbVLHqxjh5w5ZtjBMjGmh92P
- Naresh
[1]
https://lore.kernel.org/dri-devel/20220219183310.557435-1-robdcl...@gmail.com/
[2] https://lkft.validation.linaro.org/scheduler/job/4714905#L2795
[3]
https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v5.17-rc8/testrun/8446224/suite/linux-log-parser/test/check-kernel-oops-4714905/details/
>
> --
> Linaro LKFT
> https://lkft.linaro.org
>
> [1] https://lkft.validation.linaro.org/scheduler/job/4664600#L1894
[PATCH 5.16 118/121] drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
From: Thomas Zimmermann
commit 3755d35ee1d2454b20b8a1e20d790e56201678a4 upstream.
As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
the option to fix the build failure. The error message is shown
below.
arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function
`panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to
`drm_panel_dp_aux_backlight'
make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1
The issue has been reported before, when DisplayPort helpers were
hidden behind the option CONFIG_DRM_KMS_HELPER. [2]
v2:
* fix and expand commit description (Arnd)
Signed-off-by: Thomas Zimmermann
Fixes: 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency")
Reported-by: Naresh Kamboju
Reported-by: Linux Kernel Functional Testing
Reviewed-by: Lyude Paul
Acked-by: Sam Ravnborg
Link:
https://lore.kernel.org/dri-devel/CA+G9fYvN0NyaVkRQmA1O6rX7H8PPaZrUAD7=rdy33qy9ruu...@mail.gmail.com/
# [1]
Link: https://lore.kernel.org/all/2027062704.14671-1-rdun...@infradead.org/
# [2]
Cc: Thomas Zimmermann
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Link:
https://patchwork.freedesktop.org/patch/msgid/20220203093922.20754-1-tzimmerm...@suse.de
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/panel/Kconfig |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -95,6 +95,7 @@ config DRM_PANEL_EDP
depends on PM
select VIDEOMODE_HELPERS
select DRM_DP_AUX_BUS
+ select DRM_DP_HELPER
help
DRM panel driver for dumb eDP panels that need at most a regulator and
a GPIO to be powered up. Optionally a backlight can be attached so
[PATCH 5.15 105/110] drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
From: Thomas Zimmermann
commit 3755d35ee1d2454b20b8a1e20d790e56201678a4 upstream.
As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
the option to fix the build failure. The error message is shown
below.
arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function
`panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to
`drm_panel_dp_aux_backlight'
make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1
The issue has been reported before, when DisplayPort helpers were
hidden behind the option CONFIG_DRM_KMS_HELPER. [2]
v2:
* fix and expand commit description (Arnd)
Signed-off-by: Thomas Zimmermann
Fixes: 9d6366e743f3 ("drm: fb_helper: improve CONFIG_FB dependency")
Reported-by: Naresh Kamboju
Reported-by: Linux Kernel Functional Testing
Reviewed-by: Lyude Paul
Acked-by: Sam Ravnborg
Link:
https://lore.kernel.org/dri-devel/CA+G9fYvN0NyaVkRQmA1O6rX7H8PPaZrUAD7=rdy33qy9ruu...@mail.gmail.com/
# [1]
Link: https://lore.kernel.org/all/2027062704.14671-1-rdun...@infradead.org/
# [2]
Cc: Thomas Zimmermann
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Link:
https://patchwork.freedesktop.org/patch/msgid/20220203093922.20754-1-tzimmerm...@suse.de
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/panel/Kconfig |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -83,6 +83,7 @@ config DRM_PANEL_SIMPLE
depends on PM
select VIDEOMODE_HELPERS
select DRM_DP_AUX_BUS
+ select DRM_DP_HELPER
help
DRM panel driver for dumb panels that need at most a regulator and
a GPIO to be powered up. Optionally a backlight can be attached so
Re: [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface
On 13.03.2022 20:45, Andi Shyti wrote:
Hi Andrzej,
I'm sorry, but I'm not fully understanding,
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+ const char *name)
+{
+ struct kobject *kobj = >kobj;
+
+ /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+ if (!is_object_gt(kobj)) {
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+ pr_devel_ratelimited(DEPRECATED
+ "%s (pid %d) is accessing deprecated %s "
+ "sysfs control, please use gt/gt/%s instead\n",
+ current->comm, task_pid_nr(current), name, name);
+ return to_gt(i915);
+ }
+
+ return kobj_to_gt(kobj);
It took some time for me to understand what is going on here.
We have dev argument which sometimes can point to "struct device", sometimes
to "struct kobj_gt", but it's type suggests differently, quite ugly.
I wonder if wouldn't be better to use __ATTR instead of DEVICE_ATTR* as in
case of intel_engines_add_sysfs. This way abstractions would look better,
hopefully.
How would it help?
The difference is that I'm adding twice different interfaces with
the same name and different location (i.e. different object). The
legacy intrefaces inherit the object from drm and I'm preserving
that reference.
While the new objects would derive from the previous and they are
pretty much like intel_engines_add_sysfs().
I was not clear on the issue. Here in case of 'id' attribute it is defined
as device_attribute, but in kobj_type.sysfs_ops you assign formally
incompatible _sysfs_ops.
'kobj_sysfs_ops' is of the type 'kobj_type'.
Yes, but for example kobj_sysfs_ops.show points to function
kobj_attr_show, and kobj_attr_show expects that it's attr argument is
embedded in kobj_attribute[1], but this is not true in case of 'id'
attribute - it is embedded in device_attribute.
In short kobj_sysfs_ops should be used only with attrs embeded in
kobj_attribute, unless I missed sth.
[1]: https://elixir.bootlin.com/linux/latest/source/lib/kobject.c#L836
kobj_sysfs_ops expects kobj_attribute! Fortunately kobj_attribute is 'binary
compatible' with device_attribute and kobj is at beginning of struct device
as well, so it does not blow up, but I wouldn't say it is clean solution :)
If you look at intel_engines_add_sysfs you can see that all attributes are
defined as kobj_attribute.
That's exactly the approach I use in the next patches for the
power management files, I use "struct kobj_gt" wrapped around
"struct kobject". But I'm using that only for the GT files.
But attributes are still defined using DEVICE_ATTR* macros, ie they are
embedded in device_attribute, so the problem is the same - you are using
kobj_sysfs_ops with device_attribute.
Are you, btw, suggesting to use this same approache also for the
legacy files that for now have a pointer to the drm kobject? This
way I would need to add more information, like the pointer to
i915 and gt_id. This way I wouldn't need the files above that
look hacky to you. Is this what you mean?
Positive feedback is more difficult :)
I am little bit lost in possible solutions, after grepping other drivers
I have not good advice about proper handling of such situation, *beside
splitting the interface*.
For sure attrs used in device/power must be embedded in
device_attribute. So if you do not want to split interface, then it
implies GTs attrs must be also in device_attribute. Then maybe creating
custom sysfs_ops would help??? I am not sure.
Regards
Andrzej
Andi
Re: [PATCH 06/30] drm/bridge: analogix_dp: fix typos in comments
On Mon, Mar 14, 2022, 12:53 Julia Lawall wrote:
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index eb590fb8e8d0..c719cd5fba77 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -567,7 +567,7 @@ static int
> analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
> analogix_dp_get_adjust_training_lane(dp, adjust_request);
>
> if (!analogix_dp_channel_eq_ok(link_status, link_align,
> lane_count)) {
> - /* traing pattern Set to Normal */
> + /* training pattern Set to Normal */
> retval = analogix_dp_training_pattern_dis(dp);
> if (retval < 0)
> return retval;
> @@ -1254,7 +1254,7 @@ static int analogix_dp_bridge_attach(struct
> drm_bridge *bridge,
> /*
> * NOTE: the connector registration is implemented in analogix
> * platform driver, that to say connector would be exist after
> -* plat_data->attch return, that's why we record the connector
> +* plat_data->attach return, that's why we record the connector
> * point after plat attached.
> */
> if (dp->plat_data->attach) {
>
Acked-by: Robert Foss
>
[PATCH 23/30] drm/amdgpu/dc: fix typos in comments
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/amd/display/dc/bios/command_table.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index ad13e4e36d77..0e36cd800fc9 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -456,7 +456,7 @@ static enum bp_result transmitter_control_v2(
if ((CONNECTOR_ID_DUAL_LINK_DVII == connector_id) ||
(CONNECTOR_ID_DUAL_LINK_DVID == connector_id))
/* on INIT this bit should be set according to the
-* phisycal connector
+* physical connector
* Bit0: dual link connector flag
* =0 connector is single link connector
* =1 connector is dual link connector
@@ -468,7 +468,7 @@ static enum bp_result transmitter_control_v2(
cpu_to_le16((uint8_t)cntl->connector_obj_id.id);
break;
case TRANSMITTER_CONTROL_SET_VOLTAGE_AND_PREEMPASIS:
- /* votage swing and pre-emphsis */
+ /* voltage swing and pre-emphsis */
params.asMode.ucLaneSel = (uint8_t)cntl->lane_select;
params.asMode.ucLaneSet = (uint8_t)cntl->lane_settings;
break;
@@ -2120,7 +2120,7 @@ static enum bp_result program_clock_v5(
memset(, 0, sizeof(params));
if (!bp->cmd_helper->clock_source_id_to_atom(
bp_params->pll_id, _pll_id)) {
- BREAK_TO_DEBUGGER(); /* Invalid Inpute!! */
+ BREAK_TO_DEBUGGER(); /* Invalid Input!! */
return BP_RESULT_BADINPUT;
}
[PATCH 06/30] drm/bridge: analogix_dp: fix typos in comments
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index eb590fb8e8d0..c719cd5fba77 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -567,7 +567,7 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
analogix_dp_get_adjust_training_lane(dp, adjust_request);
if (!analogix_dp_channel_eq_ok(link_status, link_align, lane_count)) {
- /* traing pattern Set to Normal */
+ /* training pattern Set to Normal */
retval = analogix_dp_training_pattern_dis(dp);
if (retval < 0)
return retval;
@@ -1254,7 +1254,7 @@ static int analogix_dp_bridge_attach(struct drm_bridge
*bridge,
/*
* NOTE: the connector registration is implemented in analogix
* platform driver, that to say connector would be exist after
-* plat_data->attch return, that's why we record the connector
+* plat_data->attach return, that's why we record the connector
* point after plat attached.
*/
if (dp->plat_data->attach) {
[PATCH 00/30] fix typos in comments
Various spelling mistakes in comments. Detected with the help of Coccinelle. --- drivers/base/devres.c |4 ++-- drivers/clk/qcom/gcc-sm6125.c |2 +- drivers/clk/ti/clkctrl.c|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |4 ++-- drivers/gpu/drm/amd/display/dc/bios/command_table.c |6 +++--- drivers/gpu/drm/amd/pm/amdgpu_pm.c |2 +- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |4 ++-- drivers/gpu/drm/sti/sti_gdp.c |2 +- drivers/infiniband/hw/qib/qib_iba7220.c |4 ++-- drivers/leds/leds-pca963x.c |2 +- drivers/media/i2c/ov5695.c |2 +- drivers/mfd/rohm-bd9576.c |2 +- drivers/mtd/ubi/block.c |2 +- drivers/net/can/usb/ucan.c |4 ++-- drivers/net/ethernet/packetengines/yellowfin.c |2 +- drivers/net/wireless/ath/ath6kl/htc_mbox.c |2 +- drivers/net/wireless/cisco/airo.c |2 +- drivers/net/wireless/mediatek/mt76/mt7915/init.c|2 +- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c |6 +++--- drivers/platform/x86/uv_sysfs.c |2 +- drivers/s390/crypto/pkey_api.c |2 +- drivers/scsi/aic7xxx/aicasm/aicasm.c|2 +- drivers/scsi/elx/libefc_sli/sli4.c |2 +- drivers/scsi/lpfc/lpfc_mbox.c |2 +- drivers/scsi/qla2xxx/qla_gs.c |2 +- drivers/spi/spi-sun4i.c |2 +- drivers/staging/rtl8723bs/core/rtw_mlme.c |2 +- drivers/usb/gadget/udc/snps_udc_core.c |2 +- fs/kernfs/file.c|2 +- kernel/events/core.c|2 +- 30 files changed, 39 insertions(+), 39 deletions(-)
[PATCH 29/30] drm/amdgpu: fix typos in comments
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index fe660a8e150f..970b065e9a6b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -340,7 +340,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
if (free_vram >= 128 * 1024 * 1024 || free_vram >= total_vram / 8) {
s64 min_us;
- /* Be more aggresive on dGPUs. Try to fill a portion of free
+ /* Be more aggressive on dGPUs. Try to fill a portion of free
* VRAM now.
*/
if (!(adev->flags & AMD_IS_APU))
@@ -1280,7 +1280,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
continue;
/*
-* Work around dma_resv shortcommings by wrapping up the
+* Work around dma_resv shortcomings by wrapping up the
* submission in a dma_fence_chain and add it as exclusive
* fence.
*/
[PATCH 16/30] drm/sti: fix typos in comments
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/sti/sti_gdp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 3db3768a3241..b58415f2e4d8 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -406,7 +406,7 @@ static struct sti_gdp_node_list
*sti_gdp_get_free_nodes(struct sti_gdp *gdp)
(hw_nvn != gdp->node_list[i].top_field_paddr))
return >node_list[i];
- /* in hazardious cases restart with the first node */
+ /* in hazardous cases restart with the first node */
DRM_ERROR("inconsistent NVN for %s: 0x%08X\n",
sti_plane_to_str(>plane), hw_nvn);
[PATCH 01/30] drm/amd/pm: fix typos in comments
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/gpu/drm/amd/pm/amdgpu_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index cbbbd4079249..5cd67ddf8495 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -1870,7 +1870,7 @@ static ssize_t amdgpu_set_smartshift_bias(struct device *dev, amdgpu_smartshift_bias = bias; r = count; - /* TODO: upadte bias level with SMU message */ + /* TODO: update bias level with SMU message */ out: pm_runtime_mark_last_busy(ddev->dev);
