[PATCH v3, 08/15] drm/mediatek: check if fb is null
It's possible that state->base.fb is null. Add a check before access its
format.
Fixes: b6b1bb980ec4 ( drm/mediatek: Turn off Alpha bit when plane format has no
alpha)
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4934bee..8e7f494 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -279,7 +279,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
}
con = ovl_fmt_convert(ovl, fmt);
- if (state->base.fb->format->has_alpha)
+ if (state->base.fb && state->base.fb->format->has_alpha)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
if (pending->rotation & DRM_MODE_REFLECT_Y) {
--
1.8.1.1.dirty
[PATCH v3, 15/15] drm/mediatek: add support for mediatek SOC MT8192
add support for mediatek SOC MT8192
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c| 6
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 +
drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 1 +
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42
5 files changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 755e75b..da3fd98 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -221,9 +221,15 @@ static int mtk_disp_ccorr_remove(struct platform_device
*pdev)
.matrix_bits = CCORR_MATRIX_BITS,
};
+static const struct mtk_disp_ccorr_data mt8192_ccorr_driver_data = {
+ .matrix_bits = 13,
+};
+
static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
{ .compatible = "mediatek,mt8183-disp-ccorr",
.data = _ccorr_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ccorr",
+ .data = _ccorr_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8e7f494..4e6679e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -457,6 +457,22 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
+static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = _ovl_driver_data},
@@ -466,6 +482,10 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
.data = _ovl_driver_data},
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
.data = _ovl_2l_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl",
+ .data = _ovl_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl-2l",
+ .data = _ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
index 736224c..3b38157 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
@@ -145,6 +145,7 @@ static int mtk_disp_postmask_remove(struct platform_device
*pdev)
}
static const struct of_device_id mtk_disp_postmask_driver_dt_match[] = {
+ { .compatible = "mediatek,mt8192-disp-postmask"},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_postmask_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e914e3a..b160ebe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -364,6 +364,10 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
.fifo_size = 5 * SZ_1K,
};
+static const struct mtk_disp_rdma_data mt8192_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = _rdma_driver_data},
@@ -371,6 +375,8 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
.data = _rdma_driver_data},
{ .compatible = "mediatek,mt8183-disp-rdma",
.data = _rdma_driver_data},
+ { .compatible = "mediatek,mt8192-disp-rdma",
+ .data = _rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 79e86f7..24ce37c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -149,6 +149,25 @@
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_POSTMASK0,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DSI0,
+};
+
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL_2L2,
+ DDP_COMPONENT_RDMA4,
+ DDP_COMPONENT_DPI0,
+};
+
static const struct mtk_mmsys_driver_data
[PATCH v3, 01/15] dt-bindings: mediatek: add description for postmask
add description for postmask postmask is used control round corner for display frame Signed-off-by: Yongqiang Niu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index c562cda..9d9ab65 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -37,6 +37,7 @@ Required properties (all function blocks): "mediatek,-disp-aal" - adaptive ambient light controller "mediatek,-disp-gamma"- gamma correction "mediatek,-disp-merge"- merge streams from two RDMA sources + "mediatek,-disp-postmask" - control round corner for display frame "mediatek,-disp-split"- split stream to two encoders "mediatek,-disp-ufoe" - data compression engine "mediatek,-dsi" - DSI controller, see mediatek,dsi.txt -- 1.8.1.1.dirty
[PATCH v3, 13/15] drm/mediatek: add matrix bits private data for ccorr
matrix bits of mt8183 is 12
matrix bits of mt8192 is 13
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 63b3ef6..755e75b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -30,8 +30,10 @@
#define DISP_CCORR_COEF_3 0x008C
#define DISP_CCORR_COEF_4 0x0090
+#define CCORR_MATRIX_BITS 12
+
struct mtk_disp_ccorr_data {
- u32 reserved;
+ u32 matrix_bits;
};
/**
@@ -96,6 +98,8 @@ static void mtk_ccorr_ctm_set(struct mtk_ddp_comp *comp,
uint16_t coeffs[9] = { 0 };
int i;
struct cmdq_pkt *cmdq_pkt = NULL;
+ struct mtk_disp_ccorr *ccorr = comp_to_ccorr(comp);
+ u32 matrix_bits;
if (!blob)
return;
@@ -103,8 +107,16 @@ static void mtk_ccorr_ctm_set(struct mtk_ddp_comp *comp,
ctm = (struct drm_color_ctm *)blob->data;
input = ctm->matrix;
- for (i = 0; i < ARRAY_SIZE(coeffs); i++)
+ if (ccorr->data)
+ matrix_bits = ccorr->data->matrix_bits;
+ else
+ matrix_bits = CCORR_MATRIX_BITS;
+
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
coeffs[i] = mtk_ctm_s31_32_to_s1_10(input[i]);
+ if (matrix_bits > CCORR_MATRIX_BITS)
+ coeffs[i] <<= (matrix_bits - CCORR_MATRIX_BITS);
+ }
mtk_ddp_write(cmdq_pkt, coeffs[0] << 16 | coeffs[1],
comp, DISP_CCORR_COEF_0);
@@ -205,8 +217,13 @@ static int mtk_disp_ccorr_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
+ .matrix_bits = CCORR_MATRIX_BITS,
+};
+
static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
- { .compatible = "mediatek,mt8183-disp-ccorr"},
+ { .compatible = "mediatek,mt8183-disp-ccorr",
+ .data = _ccorr_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
--
1.8.1.1.dirty
Re: [PATCH] drm/hisilicon: Use drm_crtc_mask()
Hi
Am 11.01.21 um 04:30 schrieb Tian Tao:
Use drm_crtc_mask() where appropriate.
Signed-off-by: Tian Tao
Looks like the right thing to do.
Acked-by: Thomas Zimmermann
Best regards
Thomas
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index c76f996..1c5f2fa 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -96,6 +96,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
struct drm_device *dev = >dev;
struct hibmc_connector *hibmc_connector = >connector;
struct drm_encoder *encoder = >encoder;
+ struct drm_crtc *crtc = >crtc;
struct drm_connector *connector = _connector->base;
int ret;
@@ -105,7 +106,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
return ret;
}
- encoder->possible_crtcs = 0x1;
+ encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
if (ret) {
drm_err(dev, "failed to init encoder: %d\n", ret);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 2/2] platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot.
gentle ping on these two patches for EC_REBOOT_COLD_AP_OFF.
On Mon, Dec 21, 2020 at 12:12 PM Pi-Hsun Shih wrote:
>
> Add cold-ap-off to ChromeOS EC sysfs reboot file option, corresponds to
> the EC_REBOOT_COLD_AP_OFF flag, that will reset EC and keep AP off.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> drivers/platform/chrome/cros_ec_sysfs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_sysfs.c
> b/drivers/platform/chrome/cros_ec_sysfs.c
> index f521a5c65091..8210fb10e839 100644
> --- a/drivers/platform/chrome/cros_ec_sysfs.c
> +++ b/drivers/platform/chrome/cros_ec_sysfs.c
> @@ -28,7 +28,7 @@ static ssize_t reboot_show(struct device *dev,
> int count = 0;
>
> count += scnprintf(buf + count, PAGE_SIZE - count,
> - "ro|rw|cancel|cold|disable-jump|hibernate");
> +
> "ro|rw|cancel|cold|disable-jump|hibernate|cold-ap-off");
> count += scnprintf(buf + count, PAGE_SIZE - count,
>" [at-shutdown]\n");
> return count;
> @@ -46,6 +46,7 @@ static ssize_t reboot_store(struct device *dev,
> {"cancel", EC_REBOOT_CANCEL, 0},
> {"ro", EC_REBOOT_JUMP_RO, 0},
> {"rw", EC_REBOOT_JUMP_RW, 0},
> + {"cold-ap-off", EC_REBOOT_COLD_AP_OFF, 0},
> {"cold", EC_REBOOT_COLD, 0},
> {"disable-jump", EC_REBOOT_DISABLE_JUMP, 0},
> {"hibernate",EC_REBOOT_HIBERNATE, 0},
> --
> 2.29.2.684.gfbc64c5ab5-goog
>
[PATCH v4 5/5] f2fs: introduce sb_status sysfs node
Introduce /sys/fs/f2fs//stat/sb_status to show superblock
status in real time as a hexadecimal value.
value sb status macro description
0x1 SBI_IS_DIRTY, /* dirty flag for checkpoint */
0x2 SBI_IS_CLOSE, /* specify unmounting */
0x4 SBI_NEED_FSCK, /* need fsck.f2fs to fix */
0x8 SBI_POR_DOING, /* recovery is doing or not */
0x10SBI_NEED_SB_WRITE, /* need to recover superblock */
0x20SBI_NEED_CP,/* need to checkpoint */
0x40SBI_IS_SHUTDOWN,/* shutdown by ioctl */
0x80SBI_IS_RECOVERED, /* recovered orphan/data */
0x100 SBI_CP_DISABLED,/* CP was disabled last mount */
0x200 SBI_CP_DISABLED_QUICK, /* CP was disabled quickly */
0x400 SBI_QUOTA_NEED_FLUSH, /* need to flush quota info in
CP */
0x800 SBI_QUOTA_SKIP_FLUSH, /* skip flushing quota in
current CP */
0x1000 SBI_QUOTA_NEED_REPAIR, /* quota file may be corrupted
*/
0x2000 SBI_IS_RESIZEFS,/* resizefs is in process */
Signed-off-by: Chao Yu
---
v4:
- fix linux-next build (htmldocs) warning:
WARNING: Inline emphasis start-string without end-string.
- reformat to fit rendering in html.
Documentation/ABI/testing/sysfs-fs-f2fs | 23 +++
fs/f2fs/sysfs.c | 8
2 files changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 3dfee94e0618..e5918c93f3bf 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -377,3 +377,26 @@ Description: This gives a control to limit the bio
size in f2fs.
Default is zero, which will follow underlying block layer limit,
whereas, if it has a certain bytes value, f2fs won't submit a
bio larger than that size.
+
+What: /sys/fs/f2fs//stat/sb_status
+Date: December 2020
+Contact: "Chao Yu"
+Description: Show status of f2fs superblock in real time.
+
+ = = =
+ value sb status macro description
+ 0x1SBI_IS_DIRTY dirty flag for checkpoint
+ 0x2SBI_IS_CLOSE specify unmounting
+ 0x4SBI_NEED_FSCK need fsck.f2fs to fix
+ 0x8SBI_POR_DOING recovery is doing or not
+ 0x10 SBI_NEED_SB_WRITE need to recover superblock
+ 0x20 SBI_NEED_CP need to checkpoint
+ 0x40 SBI_IS_SHUTDOWN shutdown by ioctl
+ 0x80 SBI_IS_RECOVERED recovered orphan/data
+ 0x100 SBI_CP_DISABLED CP was disabled last mount
+ 0x200 SBI_CP_DISABLED_QUICK CP was disabled quickly
+ 0x400 SBI_QUOTA_NEED_FLUSH need to flush quota info in CP
+ 0x800 SBI_QUOTA_SKIP_FLUSH skip flushing quota in current CP
+ 0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted
+ 0x2000 SBI_IS_RESIZEFS resizefs is in process
+ == = =
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index bd1174ed2e6f..f39874d512ea 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -96,6 +96,12 @@ static ssize_t lifetime_write_kbytes_show(struct f2fs_attr
*a,
sbi->sectors_written_start) >> 1)));
}
+static ssize_t sb_status_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%lx\n", sbi->s_flag);
+}
+
static ssize_t features_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
{
@@ -702,7 +708,9 @@ static struct attribute *f2fs_feat_attrs[] = {
};
ATTRIBUTE_GROUPS(f2fs_feat);
+F2FS_GENERAL_RO_ATTR(sb_status);
static struct attribute *f2fs_stat_attrs[] = {
+ ATTR_LIST(sb_status),
NULL,
};
ATTRIBUTE_GROUPS(f2fs_stat);
--
2.29.2
Re: [PATCH v2 01/11] perf c2c: Add dimensions for total load hit
Hi Namhyung, On Wed, Jan 06, 2021 at 04:38:01PM +0900, Namhyung Kim wrote: > Hi, > > On Sun, Dec 13, 2020 at 10:39 PM Leo Yan wrote: > > > > Arm SPE trace data doesn't support HITM, but we still want to explore > > "perf c2c" tool to analyze cache false sharing. If without HITM tag, > > the tool cannot give out accurate result for cache false sharing, a > > candidate solution is to sort the total load operations and connect with > > the threads info, e.g. if multiple threads hit the same cache line for > > many times, this can give out the hint that it's likely to cause cache > > false sharing issue. > > > > Unlike having HITM tag, the proposed solution is not accurate and might > > introduce false positive reporting, but it's a pragmatic approach for > > detecting false sharing if memory event doesn't support HITM. > > > > To sort with the cache line hit, this patch adds dimensions for total > > load hit and the associated percentage calculation. > > > > Signed-off-by: Leo Yan > > --- > > tools/perf/builtin-c2c.c | 112 +++ > > 1 file changed, 112 insertions(+) > > > > diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c > > index c5babeaa3b38..3d5a2dc8b4fd 100644 > > --- a/tools/perf/builtin-c2c.c > > +++ b/tools/perf/builtin-c2c.c > > @@ -615,6 +615,47 @@ tot_hitm_cmp(struct perf_hpp_fmt *fmt __maybe_unused, > > return tot_hitm_left - tot_hitm_right; > > } > > > > +#define TOT_LD_HIT(stats) \ > > + ((stats)->ld_fbhit +\ > > +(stats)->ld_l1hit +\ > > +(stats)->ld_l2hit +\ > > +(stats)->ld_llchit + \ > > +(stats)->lcl_hitm +\ > > +(stats)->rmt_hitm +\ > > +(stats)->rmt_hit) > > It doesn't need to be a macro, why not use a static inline function? Yes, will change to use static inline function. As explained with Jiri, this patch series is mainly for Arm SPE, but so far we have a known issue for store operation, thus the store operation cannot be shown properly in the single cache view of perf c2c tool. For this reason, I will firstly send the refactoring patches in next version, but your comments for patches 01, 02, 03, 10, 11 will be addressed if later upstream them. Thanks a lot for review, Leo
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
Am Montag, 11. Januar 2021, 04:27:47 CET schrieb Chen-Yu Tsai:
> On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner wrote:
> >
> > Hi,
> >
> > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > > + vcc_sd: sdmmc-regulator {
> > > > > + compatible = "regulator-fixed";
> > > > > + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <_pin>;
> > > >
> > > > > + regulator-boot-on;
> > > > > + regulator-name = "vcc_sd";
> > > >
> > > > regulator-name above other regulator properties
> > >
> > > That is actually what I was used to, but some other rockchip dts files
> > > have all the properties sorted alphabetically. So I stuck with what I
> > > saw.
> >
> > I try to keep it alphabetical except for the exceptions :-D .
> >
> > regulator-name is such an exception. Similar to compatibles, the
> > regulator-name is an entry needed to see if you're at the right node,
> > so I really like it being the topmost regulator-foo property - just makes
> > reading easier.
> >
> > (same for the compatible first, then regs, interrupts parts, as well
> > as "status-last")
> >
> > But oftentimes, I just fix the ordering when applying - but seem to have
> > missed this somewhere in those "other Rockchip dts files" ;-) .
>
> I was slightly confused. I looked again and yes regulator-name is always the
> first regulator related property. What's off is that in some cases min/max
> voltage comes before always-on/boot-on, and in others vice versa.
>
> For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
> regulators, always-on/boot-on come before min/max voltage, while in the
> PMIC the other order is used.
That's likely undecidednes on my part ;-)
There could be an argument for a "name, voltages, flags" sorting, but on
the other hand just keeping it alphabetical with the naming on top
creates less special cases.
Heiko
Re: [PATCH 0/5] Optimize iommu_map_sg() performance
On 2021-01-11 11:52, Sai Prakash Ranjan wrote: Hi Isaac, I gave this series a go on chromebook and saw these warnings and several device probe failures, logs attached below: WARN corresponds to this code in arm_lpae_map_by_pgsize() if (WARN_ON(iaext || (paddr + size) >> cfg->oas)) return -ERANGE; Logs: [2.411391] [ cut here ] [2.416149] WARNING: CPU: 6 PID: 56 at drivers/iommu/io-pgtable-arm.c:492 arm_lpae_map_sg+0x234/0x248 [2.425606] Modules linked in: [2.428749] CPU: 6 PID: 56 Comm: kworker/6:1 Not tainted 5.10.5 #970 [2.440287] Workqueue: events deferred_probe_work_func [2.445563] pstate: 20c9 (nzCv daif +PAN +UAO -TCO BTYPE=--) [2.451726] pc : arm_lpae_map_sg+0x234/0x248 [2.456112] lr : arm_lpae_map_sg+0xe0/0x248 [2.460410] sp : ffc010513750 [2.463820] x29: ffc010513790 x28: ffb943332000 [2.469281] x27: 000ff000 x26: ffb943d14900 [2.474738] x25: 1000 x24: 000103465000 [2.480196] x23: 0001 x22: 000103466000 [2.485645] x21: 0003 x20: 0a20 [2.491103] x19: ffc010513850 x18: 0001 [2.496562] x17: 0002 x16: [2.502021] x15: x14: [2.507479] x13: 0001 x12: [2.512928] x11: 0010 x10: [2.518385] x9 : 0001 x8 : 40201000 [2.523844] x7 : 0a20 x6 : ffb943463000 [2.529302] x5 : 0003 x4 : 1000 [2.534760] x3 : 0001 x2 : ffb941f605a0 [2.540219] x1 : 0003 x0 : 0e40 [2.545679] Call trace: [2.548196] arm_lpae_map_sg+0x234/0x248 [2.552225] arm_smmu_map_sg+0x80/0xc4 [2.556078] __iommu_map_sg+0x6c/0x188 [2.559931] iommu_map_sg_atomic+0x18/0x20 [2.564144] iommu_dma_alloc_remap+0x26c/0x34c [2.568703] iommu_dma_alloc+0x9c/0x268 [2.572647] dma_alloc_attrs+0x88/0xfc [2.576503] gsi_ring_alloc+0x50/0x144 [2.580356] gsi_init+0x2c4/0x5c4 [2.583766] ipa_probe+0x14c/0x2b4 [2.587263] platform_drv_probe+0x94/0xb4 [2.591377] really_probe+0x138/0x348 [2.595145] driver_probe_device+0x80/0xb8 [2.599358] __device_attach_driver+0x90/0xa8 [2.603829] bus_for_each_drv+0x84/0xcc [2.607772] __device_attach+0xc0/0x148 [2.611713] device_initial_probe+0x18/0x20 [2.616012] bus_probe_device+0x38/0x94 [2.619953] deferred_probe_work_func+0x78/0xb0 [2.624611] process_one_work+0x210/0x3dc [2.628726] worker_thread+0x284/0x3e0 [2.632578] kthread+0x148/0x1a8 [2.635891] ret_from_fork+0x10/0x18 [2.639562] ---[ end trace 9bac18cad6a9862e ]--- [2.644414] ipa 1e4.ipa: error -12 allocating channel 0 event ring [2.651656] ipa: probe of 1e4.ipa failed with error -12 [2.660072] dwc3 a60.dwc3: Adding to iommu group 8 [2.668632] xhci-hcd xhci-hcd.13.auto: xHCI Host Controller [2.674680] xhci-hcd xhci-hcd.13.auto: new USB bus registered, assigned bus number 1 ... Isaac provided a fix which he will post as v2 and no warnings were observed with that fix. Tested-by: Sai Prakash Ranjan Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: linux-next: build warning after merge of the f2fs tree
Hi Jonathan, On 2021/1/11 7:35, Jonathan Corbet wrote: On Mon, 11 Jan 2021 07:33:54 +1100 Stephen Rothwell wrote: On Thu, 7 Jan 2021 19:28:19 +0800 Chao Yu wrote: On 2021/1/7 11:11, Stephen Rothwell wrote: After merging the f2fs tree, today's linux-next build (htmldocs) produced this warning: Documentation/ABI/testing/sysfs-fs-f2fs:382: WARNING: Inline emphasis start-string without end-string. IIUC, should I remove "/*" and "*/" for newly added entry in sysfs-fs-f2fs? Sorry, I don't know. Cc'ing Jon. > Removing the comment markers would make the warning go away, but won't lead to a satisfactory rendering in HTML. If you want that too, make the table look like the others immediately above it in the same file. Copied, thanks for your reminder. I've fixed it and resent the patch: https://lore.kernel.org/linux-f2fs-devel/20210111075017.82370-1-yuch...@huawei.com/T/#u Thanks, jon .
