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 .
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: [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
[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 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
>
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
[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
[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, 12/15] drm/mediatek: separate ccorr module
ccorr ctm matrix bits will be different in mt8192
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 222
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 92 +---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
5 files changed, 231 insertions(+), 95 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index ce5ad59..a02f534 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
-mediatek-drm-y := mtk_disp_color.o \
+mediatek-drm-y := mtk_disp_ccorr.o \
+ mtk_disp_color.o \
mtk_disp_gamma.o \
mtk_disp_ovl.o \
mtk_disp_postmask.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
new file mode 100644
index 000..63b3ef6
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -0,0 +1,222 @@
+/*
+ * SPDX-License-Identifier:
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define DISP_CCORR_EN 0x
+#define CCORR_EN BIT(0)
+#define DISP_CCORR_CFG 0x0020
+#define CCORR_RELAY_MODE BIT(0)
+#define CCORR_ENGINE_ENBIT(1)
+#define CCORR_GAMMA_OFFBIT(2)
+#define CCORR_WGAMUT_SRC_CLIP BIT(3)
+#define DISP_CCORR_SIZE0x0030
+#define DISP_CCORR_COEF_0 0x0080
+#define DISP_CCORR_COEF_1 0x0084
+#define DISP_CCORR_COEF_2 0x0088
+#define DISP_CCORR_COEF_3 0x008C
+#define DISP_CCORR_COEF_4 0x0090
+
+struct mtk_disp_ccorr_data {
+ u32 reserved;
+};
+
+/**
+ * struct mtk_disp_ccorr - DISP_CCORR driver structure
+ * @ddp_comp - structure containing type enum and hardware resources
+ * @crtc - associated crtc to report irq events to
+ */
+struct mtk_disp_ccorr {
+ struct mtk_ddp_comp ddp_comp;
+ const struct mtk_disp_ccorr_data*data;
+};
+
+static inline struct mtk_disp_ccorr *comp_to_ccorr(struct mtk_ddp_comp *comp)
+{
+ return container_of(comp, struct mtk_disp_ccorr, ddp_comp);
+}
+
+static void mtk_ccorr_config(struct mtk_ddp_comp *comp, unsigned int w,
+unsigned int h, unsigned int vrefresh,
+unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_CCORR_SIZE);
+ mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, comp, DISP_CCORR_CFG);
+}
+
+static void mtk_ccorr_start(struct mtk_ddp_comp *comp)
+{
+ writel(CCORR_EN, comp->regs + DISP_CCORR_EN);
+}
+
+static void mtk_ccorr_stop(struct mtk_ddp_comp *comp)
+{
+ writel_relaxed(0x0, comp->regs + DISP_CCORR_EN);
+}
+
+/* Converts a DRM S31.32 value to the HW S1.10 format. */
+static u16 mtk_ctm_s31_32_to_s1_10(u64 in)
+{
+ u16 r;
+
+ /* Sign bit. */
+ r = in & BIT_ULL(63) ? BIT(11) : 0;
+
+ if ((in & GENMASK_ULL(62, 33)) > 0) {
+ /* identity value 0x1 -> 0x400, */
+ /* if bigger this, set it to max 0x7ff. */
+ r |= GENMASK(10, 0);
+ } else {
+ /* take the 11 most important bits. */
+ r |= (in >> 22) & GENMASK(10, 0);
+ }
+
+ return r;
+}
+
+static void mtk_ccorr_ctm_set(struct mtk_ddp_comp *comp,
+ struct drm_crtc_state *state)
+{
+ struct drm_property_blob *blob = state->ctm;
+ struct drm_color_ctm *ctm;
+ const u64 *input;
+ uint16_t coeffs[9] = { 0 };
+ int i;
+ struct cmdq_pkt *cmdq_pkt = NULL;
+
+ if (!blob)
+ return;
+
+ ctm = (struct drm_color_ctm *)blob->data;
+ input = ctm->matrix;
+
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++)
+ coeffs[i] = mtk_ctm_s31_32_to_s1_10(input[i]);
+
+ mtk_ddp_write(cmdq_pkt, coeffs[0] << 16 | coeffs[1],
+ comp, DISP_CCORR_COEF_0);
+ mtk_ddp_write(cmdq_pkt, coeffs[2] << 16 | coeffs[3],
+ comp, DISP_CCORR_COEF_1);
+ mtk_ddp_write(cmdq_pkt, coeffs[4] << 16 | coeffs[5],
+ comp, DISP_CCORR_COEF_2);
+ mtk_ddp_write(cmdq_pkt, coeffs[6] << 16 | coeffs[7],
+ comp, DISP_CCORR_COEF_3);
+ mtk_ddp_write(cmdq_pkt, coeffs[8] << 16,
+ comp,
[PATCH v3, 14/15] drm/mediatek: add DDP support for MT8192
Add DDP support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 35 ++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 1308046..7aa7fc3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -40,6 +40,18 @@
#define MT8167_MUTEX_MOD_DISP_DITHER 15
#define MT8167_MUTEX_MOD_DISP_UFOE 16
+#define MT8192_MUTEX_MOD_DISP_OVL0 0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L 1
+#define MT8192_MUTEX_MOD_DISP_RDMA02
+#define MT8192_MUTEX_MOD_DISP_COLOR0 4
+#define MT8192_MUTEX_MOD_DISP_CCORR0 5
+#define MT8192_MUTEX_MOD_DISP_AAL0 6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0 7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK08
+#define MT8192_MUTEX_MOD_DISP_DITHER0 9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L 16
+#define MT8192_MUTEX_MOD_DISP_RDMA417
+
#define MT8183_MUTEX_MOD_DISP_RDMA00
#define MT8183_MUTEX_MOD_DISP_RDMA11
#define MT8183_MUTEX_MOD_DISP_OVL0 9
@@ -215,6 +227,20 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
};
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
+ [DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
+ [DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
+ [DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
+ [DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
+ [DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
+};
+
static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
[DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -275,6 +301,13 @@ struct mtk_ddp {
.no_clk = true,
};
+static const struct mtk_ddp_data mt8192_ddp_driver_data = {
+ .mutex_mod = mt8192_mutex_mod,
+ .mutex_sof = mt8183_mutex_sof,
+ .mutex_mod_reg = MT8183_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_DISP_MUTEX0_SOF0,
+};
+
struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int id)
{
struct mtk_ddp *ddp = dev_get_drvdata(dev);
@@ -497,6 +530,8 @@ static int mtk_ddp_remove(struct platform_device *pdev)
.data = _ddp_driver_data},
{ .compatible = "mediatek,mt8183-disp-mutex",
.data = _ddp_driver_data},
+ { .compatible = "mediatek,mt8192-disp-mutex",
+ .data = _ddp_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
--
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, 10/15] drm/mediatek: Add pm runtime support for color
color power domain need controled in the device.
Signed-off-by: Yongqiang Niu
Signed-off-by: Yidi Lin
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 6048cbc..14b9dd3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include "mtk_drm_crtc.h"
@@ -132,6 +133,8 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
+ pm_runtime_enable(dev);
+
ret = component_add(dev, _disp_color_component_ops);
if (ret)
dev_err(dev, "Failed to add component: %d\n", ret);
@@ -141,6 +144,8 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
static int mtk_disp_color_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(>dev);
+
component_del(>dev, _disp_color_component_ops);
return 0;
--
1.8.1.1.dirty
[PATCH v3, 11/15] drm/mediatek: fix aal size config
the orginal setting is not correct, fix it follow hardware data sheet.
if keep this error setting, mt8173/mt8183 display ok
but mt8192 display abnormal.
Fixes: 0664d1392c26 (drm/mediatek: Add AAL engine basic function)
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index fc01fea..6081800 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -174,7 +174,7 @@ static void mtk_aal_config(struct mtk_ddp_comp *comp,
unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
- mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_AAL_SIZE);
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_SIZE);
}
static void mtk_aal_start(struct mtk_ddp_comp *comp)
--
1.8.1.1.dirty
[PATCH v3, 07/15] drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index b47c238..4934bee 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -23,6 +23,7 @@
#define DISP_REG_OVL_RST 0x0014
#define DISP_REG_OVL_ROI_SIZE 0x0020
#define DISP_REG_OVL_DATAPATH_CON 0x0024
+#define OVL_LAYER_SMI_ID_ENBIT(0)
#define OVL_BGCLR_SEL_IN BIT(2)
#define DISP_REG_OVL_ROI_BGCLR 0x0028
#define DISP_REG_OVL_SRC_CON 0x002c
@@ -61,6 +62,7 @@ struct mtk_disp_ovl_data {
unsigned int gmc_bits;
unsigned int layer_nr;
bool fmt_rgb565_is_0;
+ bool smi_id_en;
};
/**
@@ -116,7 +118,17 @@ static void mtk_ovl_disable_vblank(struct mtk_ddp_comp
*comp)
static void mtk_ovl_start(struct mtk_ddp_comp *comp)
{
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+
writel_relaxed(0x1, comp->regs + DISP_REG_OVL_EN);
+
+ if(ovl->data->smi_id_en) {
+ unsigned int reg;
+
+ reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg | OVL_LAYER_SMI_ID_EN;
+ writel_relaxed(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ }
}
static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
--
1.8.1.1.dirty
[PATCH v3, 03/15] arm64: dts: mt8192: add display node
add display node
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 134 +++
1 file changed, 134 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index e12e024..dcf9fdf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -15,6 +15,11 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ ovl2-2l2 = _2l2;
+ rdma4 =
+ };
+
clk26m: oscillator0 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -508,5 +513,134 @@
#size-cells = <0>;
status = "disabled";
};
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt8192-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ //mboxes = < 0 CMDQ_THR_PRIO_HIGHEST 1>,
+ // < 1 CMDQ_THR_PRIO_HIGHEST 1>;
+ //mediatek,gce-client-reg = < SUBSYS_1400 0
0x1000>;
+ #clock-cells = <1>;
+ };
+
+mutex: mutex@14001000 {
+ compatible = "mediatek,mt8192-disp-mutex";
+ reg = <0 0x14001000 0 0x1000>;
+ interrupts = ;
+ //clocks = < CLK_MM_DISP_MUTEX0>;
+ //mediatek,gce-events =
,
+ //
;
+ };
+
+ ovl0: ovl@14005000 {
+ compatible = "mediatek,mt8192-disp-ovl";
+ reg = <0 0x14005000 0 0x1000>;
+ interrupts = ;
+ //clocks = < CLK_MM_DISP_OVL0>;
+ //iommus = < M4U_PORT_L0_OVL_RDMA0>;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0x5000 0x1000>;
+ };
+
+ ovl_2l0: ovl@14006000 {
+ compatible = "mediatek,mt8192-disp-ovl-2l";
+ reg = <0 0x14006000 0 0x1000>;
+ interrupts = ;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //clocks = < CLK_MM_DISP_OVL0_2L>;
+ //iommus = < M4U_PORT_L1_OVL_2L_RDMA0>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0x6000 0x1000>;
+ };
+
+ rdma0: rdma@14007000 {
+ compatible = "mediatek,mt8192-disp-rdma";
+ reg = <0 0x14007000 0 0x1000>;
+ interrupts = ;
+ //clocks = < CLK_MM_DISP_RDMA0>;
+ //iommus = < M4U_PORT_L0_DISP_RDMA0>;
+ //mediatek,larb = <>;
+ //mediatek,rdma-fifo-size = <5120>;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0x7000 0x1000>;
+ };
+
+ color0: color@14009000 {
+ compatible = "mediatek,mt8192-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //clocks = < CLK_MM_DISP_COLOR0>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0x9000 0x1000>;
+ };
+
+ ccorr0: ccorr@1400a000 {
+ compatible = "mediatek,mt8192-disp-ccorr";
+ reg = <0 0x1400a000 0 0x1000>;
+ interrupts = ;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //clocks = < CLK_MM_DISP_CCORR0>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0xa000 0x1000>;
+ };
+
+ aal0: aal@1400b000 {
+ compatible = "mediatek,mt8192-disp-aal";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //clocks = < CLK_MM_DISP_AAL0>;
+ //mediatek,gce-client-reg = < SUBSYS_1400
0xb000 0x1000>;
+ };
+
+ gamma0: gamma@1400c000 {
+ compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8192-disp-gamma";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+ //clocks = <
[PATCH v3, 06/15] drm/mediatek: add component RDMA4
This patch add component RDMA4
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index bc6b10a..fc01fea 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -392,6 +392,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
+ [DDP_COMPONENT_RDMA4] = { MTK_DISP_RDMA, 4, NULL },
[DDP_COMPONENT_UFOE]= { MTK_DISP_UFOE, 0, _ufoe },
[DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
[DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
--
1.8.1.1.dirty
[PATCH v3, 05/15] drm/mediatek: add component POSTMASK
This patch add component POSTMASK,
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/Makefile| 1 +
drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 160 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
6 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 17a08e2..ce5ad59 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -3,6 +3,7 @@
mediatek-drm-y := mtk_disp_color.o \
mtk_disp_gamma.o \
mtk_disp_ovl.o \
+ mtk_disp_postmask.o \
mtk_disp_rdma.o \
mtk_drm_crtc.o \
mtk_drm_ddp.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
new file mode 100644
index 000..736224c
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
@@ -0,0 +1,160 @@
+/*
+ * SPDX-License-Identifier:
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define DISP_POSTMASK_EN 0x
+#define POSTMASK_ENBIT(0)
+#define DISP_POSTMASK_CFG 0x0020
+#define POSTMASK_RELAY_MODEBIT(0)
+#define DISP_POSTMASK_SIZE 0x0030
+
+struct mtk_disp_postmask_data {
+ u32 reserved;
+};
+
+/**
+ * struct mtk_disp_postmask - DISP_postmask driver structure
+ * @ddp_comp - structure containing type enum and hardware resources
+ * @crtc - associated crtc to report irq events to
+ */
+struct mtk_disp_postmask {
+ struct mtk_ddp_comp ddp_comp;
+ const struct mtk_disp_postmask_data *data;
+};
+
+static inline struct mtk_disp_postmask *comp_to_postmask(struct mtk_ddp_comp
*comp)
+{
+ return container_of(comp, struct mtk_disp_postmask, ddp_comp);
+}
+
+static void mtk_postmask_config(struct mtk_ddp_comp *comp, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_POSTMASK_SIZE);
+ mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, comp, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct mtk_ddp_comp *comp)
+{
+ writel(POSTMASK_EN, comp->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct mtk_ddp_comp *comp)
+{
+ writel_relaxed(0x0, comp->regs + DISP_POSTMASK_EN);
+}
+
+static const struct mtk_ddp_comp_funcs mtk_disp_postmask_funcs = {
+ .config = mtk_postmask_config,
+ .start = mtk_postmask_start,
+ .stop = mtk_postmask_stop,
+};
+
+static int mtk_disp_postmask_bind(struct device *dev, struct device *master,
void *data)
+{
+ struct mtk_disp_postmask *priv = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
+ int ret;
+
+ ret = mtk_ddp_comp_register(drm_dev, >ddp_comp);
+ if (ret < 0) {
+ dev_err(dev, "Failed to register component %pOF: %d\n",
+ dev->of_node, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void mtk_disp_postmask_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct mtk_disp_postmask *priv = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
+
+ mtk_ddp_comp_unregister(drm_dev, >ddp_comp);
+}
+
+static const struct component_ops mtk_disp_postmask_component_ops = {
+ .bind = mtk_disp_postmask_bind,
+ .unbind = mtk_disp_postmask_unbind,
+};
+
+static int mtk_disp_postmask_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct mtk_disp_postmask *priv;
+ int comp_id;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_POSTMASK);
+ if (comp_id < 0) {
+ dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
+ return comp_id;
+ }
+
+ ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
+ _disp_postmask_funcs);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
+ return ret;
+ }
+
+ priv->data = of_device_get_match_data(dev);
+
+
Re: [PATCH] drm/ast: Disable fast reset after DRAM initial
Hi
Am 11.01.21 um 07:43 schrieb KuoHsiang Chou:
[Bug][AST2500]
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset mode is mainly designed for ARM ICE debugger.
Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be
first enabled to avoid system deadlock before disable fast reset mode.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_main.c | 4 ++
drivers/gpu/drm/ast/ast_post.c | 72 ++
3 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index da6dfb677540..8bdd1482370d 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -320,6 +320,7 @@ bool ast_is_vga_enabled(struct drm_device *dev);
void ast_post_gpu(struct drm_device *dev);
u32 ast_mindwm(struct ast_private *ast, u32 r);
void ast_moutdwm(struct ast_private *ast, u32 r, u32 v);
+void patch_ahb_ast2500(struct ast_private *ast);
The function name should be named ast_patch_ahb_2500() because it's not
static.
/* ast dp501 */
void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 size);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 3775fe26f792..3c072c6589a2 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -96,6 +96,10 @@ static void ast_detect_config_mode(struct drm_device *dev,
u32 *scu_rev)
jregd0 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
jregd1 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1, 0xff);
if (!(jregd0 & 0x80) || !(jregd1 & 0x10)) {
+ /* Patch AST2500 */
+ if (((dev->pdev->revision & 0xF0) == 0x40) && ((jregd0 & 0xC0)
== 0))
The field dev->pdev is considered deprecated. Instead, you can get the
CP device from dev->dev like this
struct pci_dev *pdev = to_pci_dev(dev->dev);
It's the same instance, but dev->pdev will removed soon.
+ patch_ahb_ast2500(ast);
+
/* Double check it's actually working */
data = ast_read32(ast, 0xf004);
if (data != 0x) {
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 8902c2f84bf9..2d121c5b2233 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2026,6 +2026,33 @@ static bool ast_dram_init_2500(struct ast_private *ast)
return true;
}
+void patch_ahb_ast2500(struct ast_private *ast)
+{
+ u32 data;
+
+patch_ahb_lock:
+ /* Clear bus lock condition */
+ ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
+ ast_moutdwm(ast, 0x1e600084, 0x0001);
+ ast_moutdwm(ast, 0x1e600088, 0x);
+ ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+ data = ast_mindwm(ast, 0x1e6e2070);
+ if (data & 0x0800) {/* check fast reset
*/
+
+ ast_moutdwm(ast, 0x1E785004, 0x0010);
+ ast_moutdwm(ast, 0x1E785008, 0x4755);
+ ast_moutdwm(ast, 0x1E78500c, 0x0033);
+ udelay(1000);
+ }
+ ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+ do {
+ data = ast_mindwm(ast, 0x1e6e2000);
+ if (data == 0x)
+ goto patch_ahb_lock;
+ } while (data != 1);
+ ast_moutdwm(ast, 0x1e6e207c, 0x0800); /* clear fast
reset */
+}
+
void ast_post_chip_2500(struct drm_device *dev)
{
struct ast_private *ast = to_ast_private(dev);
@@ -2033,39 +2060,32 @@ void ast_post_chip_2500(struct drm_device *dev)
u8 reg;
reg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
- if ((reg & 0x80) == 0) {/* vga only */
+ if ((reg & 0xC0) == 0) {/* vga only */
/* Clear bus lock condition */
- ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
- ast_moutdwm(ast, 0x1e600084, 0x0001);
- ast_moutdwm(ast, 0x1e600088, 0x);
- ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
- ast_write32(ast, 0xf004, 0x1e6e);
- ast_write32(ast, 0xf000, 0x1);
- ast_write32(ast, 0x12000, 0x1688a8a8);
- while (ast_read32(ast, 0x12000) != 0x1)
- ;
-
- ast_write32(ast, 0x1, 0xfc600309);
- while (ast_read32(ast, 0x1) != 0x1)
- ;
+ patch_ahb_ast2500(ast);
+
+ /* Disable watchdog */
+ ast_moutdwm(ast, 0x1E78502C, 0x);
+ ast_moutdwm(ast, 0x1E78504C, 0x);
+ /* Reset USB
[PATCH v3, 09/15] drm/mediatek: Add pm runtime support for gamma
gamma power domain need controled in the device.
Signed-off-by: Yongqiang Niu
Signed-off-by: Yidi Lin
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 3c1ea07..da93079 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "mtk_drm_crtc.h"
@@ -156,6 +157,8 @@ static int mtk_disp_gamma_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
+ pm_runtime_enable(dev);
+
ret = component_add(dev, _disp_gamma_component_ops);
if (ret)
dev_err(dev, "Failed to add component: %d\n", ret);
@@ -165,6 +168,8 @@ static int mtk_disp_gamma_probe(struct platform_device
*pdev)
static int mtk_disp_gamma_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(>dev);
+
component_del(>dev, _disp_gamma_component_ops);
return 0;
--
1.8.1.1.dirty
[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, 00/15] drm/mediatek: add support for mediatek SOC MT8192
This series are based on 5.11-rc1 and SoC MT8183, and provide 15 patch to support mediatek SOC MT8192 Changes since v2: - fix review comment in v2 - add pm runtime for gamma and color - move ddp path select patch to mmsys series - remove some useless patch Yongqiang Niu (15): dt-bindings: mediatek: add description for postmask dt-bindings: mediatek: add description for mt8192 display arm64: dts: mt8192: add display node drm/mediatek: add component OVL_2L2 drm/mediatek: add component POSTMASK drm/mediatek: add component RDMA4 drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase drm/mediatek: check if fb is null drm/mediatek: Add pm runtime support for gamma drm/mediatek: Add pm runtime support for color drm/mediatek: fix aal size config drm/mediatek: separate ccorr module drm/mediatek: add matrix bits private data for ccorr drm/mediatek: add DDP support for MT8192 drm/mediatek: add support for mediatek SOC MT8192 .../bindings/display/mediatek/mediatek,disp.txt| 3 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 134 +++ drivers/gpu/drm/mediatek/Makefile | 4 +- drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 245 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 + drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 5 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 34 ++- drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 161 ++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 35 +++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 98 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 52 - drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 + 14 files changed, 687 insertions(+), 98 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c -- 1.8.1.1.dirty
[PATCH v3, 04/15] drm/mediatek: add component OVL_2L2
This patch add component OVL_2L2
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 81ed076..a715127 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -383,6 +383,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
[DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, NULL },
+ [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
--
1.8.1.1.dirty
[PATCH v3, 02/15] dt-bindings: mediatek: add description for mt8192 display
add description for mt8192 display Signed-off-by: Yongqiang Niu Reviewed-by: Chun-Kuang Hu Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 9d9ab65..b47e1a0 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -44,7 +44,7 @@ Required properties (all function blocks): "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex"- display mutex "mediatek,-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173 and mt8183. + the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173, mt8183 and mt8192. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). -- 1.8.1.1.dirty
[PATCH 2/2][v2] cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available
Currently when turbo is disabled(either by BIOS or by the user), the
intel_pstate
driver reads the max frequency from the package-wide MSR_PLATFORM_INFO(0xce)
register.
However on asymmetric platforms it is possible in theory that small and big
core with
HWP enabled might have different max cpu frequency, because the
MSR_HWP_CAPABILITIES
is percpu scope according to Intel Software Developer Manual.
The turbo max freq is already percpu basis in current code, thus make similar
change
to the max non-turbo frequency as well.
Reported-by: Wendy Wang
Signed-off-by: Chen Yu
---
v2: per Srinivas' suggestion, avoid duplicated assignment of max_pstate.
--
drivers/cpufreq/intel_pstate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index bd3dd1be73ba..f2d18991d969 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1725,11 +1725,9 @@ static void intel_pstate_max_within_limits(struct
cpudata *cpu)
static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
{
cpu->pstate.min_pstate = pstate_funcs.get_min();
- cpu->pstate.max_pstate = pstate_funcs.get_max();
cpu->pstate.max_pstate_physical = pstate_funcs.get_max_physical();
cpu->pstate.turbo_pstate = pstate_funcs.get_turbo();
cpu->pstate.scaling = pstate_funcs.get_scaling();
- cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (hwp_active && !hwp_mode_bdw) {
unsigned int phy_max, current_max, guar_state;
@@ -1737,8 +1735,12 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
intel_pstate_get_hwp_max(cpu, _max, _max,
_state);
cpu->pstate.turbo_freq = phy_max * cpu->pstate.scaling;
cpu->pstate.turbo_pstate = phy_max;
+ cpu->pstate.max_pstate = guar_state;
+ cpu->pstate.max_freq = guar_state * cpu->pstate.scaling;
} else {
cpu->pstate.turbo_freq = cpu->pstate.turbo_pstate *
cpu->pstate.scaling;
+ cpu->pstate.max_pstate = pstate_funcs.get_max();
+ cpu->pstate.max_freq = cpu->pstate.max_pstate *
cpu->pstate.scaling;
}
if (pstate_funcs.get_aperf_mperf_shift)
--
2.17.1
[PATCH 1/2][v2] cpufreq: intel_pstate: Add parameter to get guarantee frequency
Add input parameter to receive guarantee pstate from intel_pstate_get_hwp_max()
for later use.
No functional change intended.
Signed-off-by: Chen Yu
---
drivers/cpufreq/intel_pstate.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index eaf32ef7a030..bd3dd1be73ba 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -830,7 +830,7 @@ static struct freq_attr *hwp_cpufreq_attrs[] = {
};
static void intel_pstate_get_hwp_max(struct cpudata *cpu, int *phy_max,
-int *current_max)
+int *current_max, int *guar_max)
{
u64 cap;
@@ -842,6 +842,7 @@ static void intel_pstate_get_hwp_max(struct cpudata *cpu,
int *phy_max,
*current_max = HWP_HIGHEST_PERF(cap);
*phy_max = HWP_HIGHEST_PERF(cap);
+ *guar_max = HWP_GUARANTEED_PERF(cap);
}
static void intel_pstate_hwp_set(unsigned int cpu)
@@ -1205,7 +1206,7 @@ static ssize_t store_no_turbo(struct kobject *a, struct
kobj_attribute *b,
static void update_qos_request(enum freq_qos_req_type type)
{
- int max_state, turbo_max, freq, i, perf_pct;
+ int max_state, turbo_max, guar_state, freq, i, perf_pct;
struct freq_qos_request *req;
struct cpufreq_policy *policy;
@@ -1223,7 +1224,7 @@ static void update_qos_request(enum freq_qos_req_type
type)
continue;
if (hwp_active)
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
else
turbo_max = cpu->pstate.turbo_pstate;
@@ -1731,9 +1732,9 @@ static void intel_pstate_get_cpu_pstates(struct cpudata
*cpu)
cpu->pstate.max_freq = cpu->pstate.max_pstate * cpu->pstate.scaling;
if (hwp_active && !hwp_mode_bdw) {
- unsigned int phy_max, current_max;
+ unsigned int phy_max, current_max, guar_state;
- intel_pstate_get_hwp_max(cpu, _max, _max);
+ intel_pstate_get_hwp_max(cpu, _max, _max,
_state);
cpu->pstate.turbo_freq = phy_max * cpu->pstate.scaling;
cpu->pstate.turbo_pstate = phy_max;
} else {
@@ -2209,7 +2210,7 @@ static void intel_pstate_update_perf_limits(struct
cpudata *cpu,
unsigned int policy_max)
{
int32_t max_policy_perf, min_policy_perf;
- int max_state, turbo_max;
+ int max_state, turbo_max, guar_state;
int max_freq;
/*
@@ -2218,7 +2219,7 @@ static void intel_pstate_update_perf_limits(struct
cpudata *cpu,
* rather than pure ratios.
*/
if (hwp_active) {
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
} else {
max_state = global.no_turbo || global.turbo_disabled ?
cpu->pstate.max_pstate : cpu->pstate.turbo_pstate;
@@ -2331,9 +2332,9 @@ static void intel_pstate_verify_cpu_policy(struct cpudata
*cpu,
update_turbo_state();
if (hwp_active) {
- int max_state, turbo_max;
+ int max_state, turbo_max, guar_state;
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
max_freq = max_state * cpu->pstate.scaling;
} else {
max_freq = intel_pstate_get_max_freq(cpu);
@@ -2691,7 +2692,7 @@ static void intel_cpufreq_adjust_perf(unsigned int cpunum,
static int intel_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int max_state, turbo_max, min_freq, max_freq, ret;
+ int max_state, turbo_max, guar_state, min_freq, max_freq, ret;
struct freq_qos_request *req;
struct cpudata *cpu;
struct device *dev;
@@ -2719,7 +2720,7 @@ static int intel_cpufreq_cpu_init(struct cpufreq_policy
*policy)
if (hwp_active) {
u64 value;
- intel_pstate_get_hwp_max(cpu, _max, _state);
+ intel_pstate_get_hwp_max(cpu, _max, _state,
_state);
policy->transition_delay_us =
INTEL_CPUFREQ_TRANSITION_DELAY_HWP;
rdmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, );
WRITE_ONCE(cpu->hwp_req_cached, value);
--
2.17.1
[PATCH 2/3] arm64: dtsi: ls1028a: Update flexcan properties
LS1028A supports two flexcan controllers similar to LX2160A.
There's already a compatible entry defined i.e "fsl,lx2160ar1-flexcan"
which can be further reused for LS1028A.
Please note, "fsl,ls1028ar1-flexcan" compatible entry doesn't exists and
can be safely removed.
LS1028A has a single peripheral clock (i.e platform clock) source
connected to both "ipg" and "per" and therefore, remove "sysclk" as
clock source from device-tree.
Signed-off-by: Kuldeep Singh
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 60ff19f..447d3b6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -395,19 +395,19 @@
};
can0: can@218 {
- compatible = "fsl,ls1028ar1-flexcan",
"fsl,lx2160ar1-flexcan";
+ compatible = "fsl,lx2160ar1-flexcan";
reg = <0x0 0x218 0x0 0x1>;
interrupts = ;
- clocks = <>, < 4 1>;
+ clocks = < 4 1>, < 4 1>;
clock-names = "ipg", "per";
status = "disabled";
};
can1: can@219 {
- compatible = "fsl,ls1028ar1-flexcan",
"fsl,lx2160ar1-flexcan";
+ compatible = "fsl,lx2160ar1-flexcan";
reg = <0x0 0x219 0x0 0x1>;
interrupts = ;
- clocks = <>, < 4 1>;
+ clocks = < 4 1>, < 4 1>;
clock-names = "ipg", "per";
status = "disabled";
};
--
2.7.4
[PATCH 0/2][v2] Get percpu max freq via HWP MSR register
Asymmetric platforms might have different max cpu frequency between small and big cores. Currently the intel_pstate driver uses package wide MSR register that can not distinguish max cpu frequency between small and big cores when turbo is disabled, which causes inconsistency compared to the scenario when turbo mode is enabled. This patch changes the logic from package wide MSR register to percpu HWP register so as to avoid this issue. This path is based on Rafael's previous patchset to clean up the intel_pstate_get_hwp_max() https://patchwork.kernel.org/project/linux-pm/patch/2241039.bdjsIDbar3@kreacher/ Chen Yu (2): cpufreq: intel_pstate: Add parameter to get guarantee cpufreq: intel_pstate: Get percpu max freq via HWP MSR register if available drivers/cpufreq/intel_pstate.c | 29 - 1 file changed, 16 insertions(+), 13 deletions(-) -- 2.17.1
[PATCH 1/3] arm64: dts: lx2160a: Add flexcan support
LX2160A supports two flexcan controllers. Add the support.
Enable support further for LX2160A-RDB/QDS.
Signed-off-by: Kuldeep Singh
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts | 8
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 16
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 20
3 files changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
index 16ae3b0..d858d9c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
@@ -33,6 +33,14 @@
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 6f82759..5dbf274 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -89,6 +89,22 @@
};
};
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
{
sd-uhs-sdr104;
sd-uhs-sdr50;
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 0d4bce1..63a3ef6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -878,6 +878,26 @@
status = "disabled";
};
+ can0: can@218 {
+ compatible = "fsl,lx2160ar1-flexcan";
+ reg = <0x0 0x218 0x0 0x1>;
+ interrupts = ;
+ clocks = < 4 7>, <>;
+ clock-names = "ipg", "per";
+ fsl,clk-source = <0>;
+ status = "disabled";
+ };
+
+ can1: can@219 {
+ compatible = "fsl,lx2160ar1-flexcan";
+ reg = <0x0 0x219 0x0 0x1>;
+ interrupts = ;
+ clocks = < 4 7>, <>;
+ clock-names = "ipg", "per";
+ fsl,clk-source = <0>;
+ status = "disabled";
+ };
+
uart0: serial@21c {
compatible = "arm,sbsa-uart","arm,pl011";
reg = <0x0 0x21c 0x0 0x1000>;
--
2.7.4
[PATCH 0/3] Enable flexcan support in LS1028A/LX2160A
This patch set adds device-tree support for LX2160A-RDB/QDS. Also, update flexcan entry for LS1028A and enable support further for LS1028A-RDB/QDS. Patch1: Add dtsi and dts properties for LX2160A Patch2: Update dtsi properties for LS1028A Patch3: Add dts properties for LS1028A. Kuldeep Singh (3): arm64: dts: lx2160a: Add flexcan support arm64: dtsi: ls1028a: Update flexcan properties arm64: dts: ls1028a: Enable flexcan support for LS1028A-RDB/QDS arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 8 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 16 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi| 8 arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts | 8 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 16 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 20 6 files changed, 72 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH 3/3] arm64: dts: ls1028a: Enable flexcan support for LS1028A-RDB/QDS
LS1028A-RDB/QDS provides support for flexcan. Add the properties.
Signed-off-by: Kuldeep Singh
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 8
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 16
2 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index c0786b7..fbcba9c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -109,6 +109,14 @@
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
bus-num = <0>;
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index c1d1ba4..41ae6e76 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -85,6 +85,22 @@
};
};
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
{
sd-uhs-sdr104;
sd-uhs-sdr50;
--
2.7.4
Re: [PATCH v1 3/7] perf cs-etm: Calculate per CPU metadata array size
On 1/9/21 7:44 AM, Leo Yan wrote: The metadata array can be extended over time and the tool, if using the predefined macro (like CS_ETMV4_PRIV_MAX for ETMv4) as metadata array size to copy data, it can cause compatible issue within different versions of perf tool. E.g. we recorded a data file with an old version tool, afterwards if use the new version perf tool to parse the file, since the metadata array has been extended and the macro CS_ETMV4_PRIV_MAX has been altered, if use it to parse the perf data with old format, this will lead to mismatch. To maintain backward compatibility, this patch calculates per CPU metadata array size on the runtime, the calculation is based on the info stored in the data file so that it's reliable. Signed-off-by: Leo Yan Looks good to me. Acked-by: Suzuki K Poulose
Re: [PATCH] usb/gadget: f_midi: Replace tasklet with work
Hi, Davidlohr Bueso writes: > Currently a tasklet is used to transmit input substream buffer > data. However, tasklets have long been deprecated as being too > heavy on the system by running in irq context - and this is not > a performance critical path. If a higher priority process wants > to run, it must wait for the tasklet to finish before doing so. > > Deferring work to a workqueue and executing in process context > should be fine considering the callback already does > f_midi_do_transmit() under the transmit_lock and thus changes in > semantics are ok regarding concurrency - tasklets being serialized > against itself. > > Cc: Takashi Iwai > Signed-off-by: Davidlohr Bueso Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
Re: [PATCH v4 0/5] imx8mq: updates for the interconnect fabric
On 11.01.21 05:51, Shawn Guo wrote: On Thu, Jan 07, 2021 at 01:17:49PM +0100, Martin Kepplinger wrote: revision history: v4: (thanks Shawn, Georgi and Greg) * reorder to have dt-bindings doc before code addition * add newline between dt nodes * removed "interconnect: imx8mq: Use icc_sync_state" from the patchset since it's part of gregkh/char-misc.git * Add acks v3: (thanks Krysztof and Georgi) * drop the defconfig cycling patch and fix the interconnect enable config * add the noc node to imx8mq only * add missing signed-off-by * https://lore.kernel.org/linux-arm-kernel/20201210100906.18205-1-martin.kepplin...@puri.sm/T/#t v2: (thanks Lucas) * reorder and clean up defconfig changes * use "dram" for the interconnect path name and document it * https://lore.kernel.org/linux-arm-kernel/20201201123932.12312-1-martin.kepplin...@puri.sm/T/#t v1: * https://lore.kernel.org/linux-arm-kernel/20201201100124.4676-1-martin.kepplin...@puri.sm/T/#t thanks, martin Leonard Crestez (1): arm64: dts: imx8mq: Add NOC node Martin Kepplinger (4): arm64: dts: imx8mq: Add interconnect provider property dt-bindings: mxsfb: Add interconnect bindings for LCDIF path arm64: dts: imx8mq: Add interconnect for lcdif arm64: defconfig: Enable interconnect for imx8mq I only received 3 patches, 1/5, 4/5 and 5/5. Shawn strange as they made it to the lists, see https://lore.kernel.org/linux-arm-kernel/20210107121754.3295-1-martin.kepplin...@puri.sm/ but I can resend into this thread. martin
Re: [PATCH 09/15] gpio: support ROHM BD71815 GPOs
On Mon, 2021-01-11 at 08:15 +0200, Matti Vaittinen wrote:
> On Sat, 2021-01-09 at 01:45 +0100, Linus Walleij wrote:
> > On Fri, Jan 8, 2021 at 2:39 PM Matti Vaittinen
> > wrote:
> >
> > > Support GPO(s) found from ROHM BD71815 power management IC. The
> > > IC
> > > has two
> > > GPO pins but only one is properly documented in data-sheet. The
> > > driver
> > > exposes by default only the documented GPO. The second GPO is
> > > connected to
> > > E5 pin and is marked as GND in data-sheet. Control for this
> > > undocumented
> > > pin can be enabled using a special DT property.
> > >
> > > This driver is derived from work by Peter Yang <
> > > yang...@embest-tech.com>
> > > although not so much of original is left.
> > >
> > > Signed-off-by: Matti Vaittinen > > >
// Snip
> > > + g->chip.parent = pdev->dev.parent;
> > > + g->chip.of_node = pdev->dev.parent->of_node;
> > > + g->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > > + g->dev = >dev;
> > > +
> > > + ret = devm_gpiochip_add_data(>dev, >chip, g);
> > > + if (ret < 0) {
> > > + dev_err(>dev, "could not register gpiochip,
> > > %d\n", ret);
> > > + return ret;
> > > + }
> >
> > It's a bit confusing how you use pdev->dev.parent for some stuff
> > and >dev for some.
> >
> > What about assinging
> >
> > struct device *dev = pdev->dev.parent;
> >
> > and use dev for all the calls, it looks like it'd work fine.
>
> I wouldn't bind the lifetime of devm functions to the parent device.
> I
> am not sure if it would work - what happens we bind lifetime of XX to
> parent device - and next call at probe fails (for example with
> DEFERRED?) I _assume_ the XX bound to parent is not released?
> (Please,
> do correct me if I am wrong!)
/*
* Bind devm lifetime to this platform device => use dev for devm.
* also the prints should originate from this device.
*/
dev = >dev;
/* The device-tree and regmap come from MFD => use parent for that */
parent = dev->parent;
Maybe adding dev and parent variables + comments would clear it up?
Br,
Matti Vaittinen
Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse
On 1/10/21 11:30 AM, Linus Torvalds wrote:
On Sat, Jan 9, 2021 at 7:51 PM Linus Torvalds
wrote:
Just having a bit in the page flags for "I already made this
exclusive, and fork() will keep it so" is I feel the best option. In a
way, "page is writable" right now _is_ that bit. By definition, if you
have a writable page in an anonymous mapping, that is an exclusive
user.
But because "writable" has these interactions with other operations,
it would be better if it was a harder bit than that "maybe_pinned()",
though. It would be lovely if a regular non-pinning write-GUP just
always set it, for example.
"maybe_pinned()" is good enough for the fork() case, which is the one
that matters for long-term pinning. But it's admittedly not perfect.
There is at least one way to improve this part of it--maybe.
IMHO, a lot of the bits in page _refcount are still being wasted (even
after GUP_PIN_COUNTING_BIAS overloading), because it's unlikely that
there are many callers of gup/pup per page. If anyone points out that
that is wrong, then the rest of this falls apart, but...if we were to
make a rule that "only a very few FOLL_GET or FOLL_PIN pins are ever
simultaneously allowed on a given page", then several things become
possible:
1) "maybe dma pinned" could become "very likely dma-pinned", by allowing
perhaps 23 bits for normal page refcounts (leaving just 8 bits for dma
pins), thus all but ensuring no aliasing between normal refcounts and
dma pins. The name change below to "likely" is not actually necessary,
I'm just using it to make the point clear:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ecdf8a8cd6ae..28f7f64e888f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1241,7 +1241,7 @@ static inline void put_page(struct page *page)
* get_user_pages and page_mkclean and other calls that race to set up page
* table entries.
*/
-#define GUP_PIN_COUNTING_BIAS (1U << 10)
+#define GUP_PIN_COUNTING_BIAS (1U << 23)
void unpin_user_page(struct page *page);
void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages,
@@ -1274,7 +1274,7 @@ void unpin_user_pages(struct page **pages, unsigned long
npages);
* @Return:True, if it is likely that the page has been "dma-pinned".
* False, if the page is definitely not dma-pinned.
*/
-static inline bool page_maybe_dma_pinned(struct page *page)
+static inline bool page_likely_dma_pinned(struct page *page)
{
if (hpage_pincount_available(page))
return compound_pincount(page) > 0;
2) Doing (1) allows, arguably, failing mprotect calls if
page_likely_dma_pinned() returns true, because the level of confidence
is much higher now.
3) An additional counter, for normal gup (FOLL_GET) is possible: divide
up the top 8 bits into two separate counters of just 4 bits each. Only
allow either FOLL_GET or FOLL_PIN (and btw, I'm now mentally equating
FOLL_PIN with FOLL_LONGTERM), not both, on a given page. Like this:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ecdf8a8cd6ae..ce5af27e3057 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1241,7 +1241,8 @@ static inline void put_page(struct page *page)
* get_user_pages and page_mkclean and other calls that race to set up page
* table entries.
*/
-#define GUP_PIN_COUNTING_BIAS (1U << 10)
+#define DMA_PIN_COUNTING_BIAS (1U << 23)
+#define GUP_PIN_COUNTING_BIAS (1U << 27)
void unpin_user_page(struct page *page);
void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages,
So:
FOLL_PIN: would use DMA_PIN_COUNTING_BIAS to increment page refcount.
These are long term pins for dma.
FOLL_GET: would use GUP_PIN_COUNTING_BIAS to increment page refcount.
These are not long term pins.
Doing (3) would require yet another release call variant:
unpin_user_pages() would need to take a flag to say which refcount to
release: FOLL_GET or FOLL_PIN. However, I think that's relatively easy
(compared to the original effort of teasing apart generic put_page()
calls, into unpin_user_pages() calls). We already have all the
unpin_user_pages() calls in place, and so it's "merely" a matter of
adding a flag to 74 call sites.
The real question is whether we can get away with supporting only a very
low count of FOLL_PIN and FOLL_GET pages. Can we?
thanks,
--
John Hubbard
NVIDIA
Re: linux-next: manual merge of the char-misc tree with the drivers-x86 tree
On Mon, Jan 11, 2021 at 01:08:51PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got conflicts in:
>
> include/linux/mod_devicetable.h
> scripts/mod/devicetable-offsets.c
> scripts/mod/file2alias.c
>
> between commit:
>
> eb0e90a82098 ("platform/surface: aggregator: Add dedicated bus and device
> type")
>
> from the drivers-x86 tree and commits:
>
> 9326eecd9365 ("fpga: dfl: move dfl_device_id to mod_devicetable.h")
> 4a224acec597 ("fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE()")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks, this looks correct, and expected as new subsystems add
auto-loading capabilities at the same time.
greg k-h
Re: [PATCH] USB: otg: Fix error 32 when enable hardware flow control.
On Mon, Jan 11, 2021 at 04:55:22AM +, Pho Tran wrote:
> When hardware flow control is enabled,
> don't allow host send MHS command to cp210x.
>
> Signed-off-by: Pho Tran
Nit, you need a ' ' before the '<' character.
And why didn't you send this to the maintainer of this file as described
by scripts/get_maintainer.pl?
Please do so when you fix things up and send the next version.
> ---
> drivers/usb/serial/cp210x.c | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index fbb10dfc56e3..f231cecdaf7d 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -1204,6 +1204,7 @@ static int cp210x_tiocmset(struct tty_struct *tty,
> unsigned int set, unsigned int clear)
> {
> struct usb_serial_port *port = tty->driver_data;
> +
> return cp210x_tiocmset_port(port, set, clear);
> }
>
Unneeded change :(
> @@ -1211,6 +1212,11 @@ static int cp210x_tiocmset_port(struct usb_serial_port
> *port,
> unsigned int set, unsigned int clear)
> {
> u16 control = 0;
> + struct cp210x_flow_ctl flow_ctl;
> + u32 ctl_hs = 0;
> + u32 flow_repl = 0;
> + bool auto_dtr = false;
> + bool auto_rts = false;
>
> if (set & TIOCM_RTS) {
> control |= CONTROL_RTS;
> @@ -1230,6 +1236,30 @@ static int cp210x_tiocmset_port(struct usb_serial_port
> *port,
> }
>
> dev_dbg(>dev, "%s - control = 0x%.4x\n", __func__, control);
> + /*
> + * Don't send MHS command if device in hardware flowcontrol mode
> + */
Why the giant comment?
> + cp210x_read_reg_block(port, CP210X_GET_FLOW, _ctl,
> + sizeof(flow_ctl));
> + ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
> + flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
> +
> + if (CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_FLOW_CTL)
> + == (ctl_hs & CP210X_SERIAL_DTR_MASK))
Very odd indentation :(
> + auto_dtr = true;
> + else
> + auto_dtr = false;
> +
> + if (CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL)
> + == (flow_repl & CP210X_SERIAL_RTS_MASK))
> + auto_rts = true;
> + else
> + auto_rts = false;
> +
> + if (auto_dtr || auto_rts) {
> + dev_dbg(>dev, "Don't set MHS when while device in flow
> control mode\n");
> + return 0;
> + }
>
> return cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
> }
> @@ -1256,7 +1286,7 @@ static int cp210x_tiocmget(struct tty_struct *tty)
> |((control & CONTROL_RTS) ? TIOCM_RTS : 0)
> |((control & CONTROL_CTS) ? TIOCM_CTS : 0)
> |((control & CONTROL_DSR) ? TIOCM_DSR : 0)
> - |((control & CONTROL_RING)? TIOCM_RI : 0)
> + |((control & CONTROL_RING) ? TIOCM_RI : 0)
Do not mix whitespace changes with logic changes in the same patch, that
is a sure way to get your patch rejected.
thanks,
greg k-h
Re: [PATCHv2] perf tools: Detect when pipe is passed as perf data
On Wed, Jan 6, 2021 at 1:49 AM Jiri Olsa wrote:
>
> On Tue, Jan 05, 2021 at 05:33:38PM -0800, Stephane Eranian wrote:
> > Hi,
> >
> > On Wed, Dec 30, 2020 at 3:09 AM Jiri Olsa wrote:
> > >
> > > Currently we allow pipe input/output only through '-' string
> > > being passed to '-o' or '-i' options, like:
> > >
> > It seems to me it would be useful to auto-detect that the perf.data
> > file is in pipe vs. file mode format.
> > Your patch detects the type of the file which is something different
> > from the format of its content.
>
> hi,
> it goes together with the format, once the output file
> is pipe, the format is pipe as well
>
What I was saying is if I do:
$ perf record -o - -a sleep 10 > perf.data
$ perf report -i perf.data
it should autodetect it is a pipe mode file.
Does it do that today?
> jirka
>
> > Thanks.
> >
> > > # mkfifo perf.pipe
> > > # perf record --no-buffering -e 'sched:sched_switch' -o - > perf.pipe &
> > > [1] 354406
> > > # cat perf.pipe | ./perf --no-pager script -i - | head -3
> > > perf 354406 [000] 168190.164921: sched:sched_switch:
> > > perf:354406..
> > > migration/012 [000] 168190.164928: sched:sched_switch:
> > > migration/0:..
> > > perf 354406 [001] 168190.164981: sched:sched_switch:
> > > perf:354406..
> > > ...
> > >
> > > This patch detects if given path is pipe and set the perf data
> > > object accordingly, so it's possible now to do above with:
> > >
> > > # mkfifo perf.pipe
> > > # perf record --no-buffering -e 'sched:sched_switch' -o perf.pipe &
> > > [1] 360188
> > > # perf --no-pager script -i ./perf.pipe | head -3
> > > perf 354442 [000] 168275.464895: sched:sched_switch:
> > > perf:354442..
> > > migration/012 [000] 168275.464902: sched:sched_switch:
> > > migration/0:..
> > > perf 354442 [001] 168275.464953: sched:sched_switch:
> > > perf:354442..
> > >
> > > It's of course possible to combine any of above ways.
> > >
> > > Signed-off-by: Jiri Olsa
> > > ---
> > > v2:
> > > - removed O_CREAT|O_TRUNC flags from pipe's write end
> > >
> > > tools/perf/util/data.c | 27 +--
> > > 1 file changed, 21 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> > > index f29af4fc3d09..4dfa9e0f2fec 100644
> > > --- a/tools/perf/util/data.c
> > > +++ b/tools/perf/util/data.c
> > > @@ -159,7 +159,7 @@ int perf_data__update_dir(struct perf_data *data)
> > > return 0;
> > > }
> > >
> > > -static bool check_pipe(struct perf_data *data)
> > > +static int check_pipe(struct perf_data *data)
> > > {
> > > struct stat st;
> > > bool is_pipe = false;
> > > @@ -172,6 +172,15 @@ static bool check_pipe(struct perf_data *data)
> > > } else {
> > > if (!strcmp(data->path, "-"))
> > > is_pipe = true;
> > > + else if (!stat(data->path, ) && S_ISFIFO(st.st_mode)) {
> > > + int flags = perf_data__is_read(data) ?
> > > + O_RDONLY : O_WRONLY;
> > > +
> > > + fd = open(data->path, flags);
> > > + if (fd < 0)
> > > + return -EINVAL;
> > > + is_pipe = true;
> > > + }
> > > }
> > >
> > > if (is_pipe) {
> > > @@ -190,7 +199,8 @@ static bool check_pipe(struct perf_data *data)
> > > }
> > > }
> > >
> > > - return data->is_pipe = is_pipe;
> > > + data->is_pipe = is_pipe;
> > > + return 0;
> > > }
> > >
> > > static int check_backup(struct perf_data *data)
> > > @@ -344,8 +354,11 @@ static int open_dir(struct perf_data *data)
> > >
> > > int perf_data__open(struct perf_data *data)
> > > {
> > > - if (check_pipe(data))
> > > - return 0;
> > > + int err;
> > > +
> > > + err = check_pipe(data);
> > > + if (err || data->is_pipe)
> > > + return err;
> > >
> > > /* currently it allows stdio for pipe only */
> > > data->use_stdio = false;
> > > @@ -410,8 +423,10 @@ int perf_data__switch(struct perf_data *data,
> > > {
> > > int ret;
> > >
> > > - if (check_pipe(data))
> > > - return -EINVAL;
> > > + ret = check_pipe(data);
> > > + if (ret || data->is_pipe)
> > > + return ret;
> > > +
> > > if (perf_data__is_read(data))
> > > return -EINVAL;
> > >
> > > --
> > > 2.26.2
> > >
> >
>
Re: [PATCH] blk-mq-debugfs: Add decode for BLK_MQ_F_TAG_HCTX_SHARED
On 1/8/21 9:55 AM, John Garry wrote:
Showing the hctx flags for when BLK_MQ_F_TAG_HCTX_SHARED is set gives
something like:
root@debian:/home/john# more /sys/kernel/debug/block/sda/hctx0/flags
alloc_policy=FIFO SHOULD_MERGE|TAG_QUEUE_SHARED|3
Add the decoding for that flag.
Fixes: 32bc15afed04b ("blk-mq: Facilitate a shared sbitmap per tagset")
Signed-off-by: John Garry
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index 3094542e12ae..ea4ab98e6b25 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -245,6 +245,7 @@ static const char *const hctx_flag_name[] = {
HCTX_FLAG_NAME(BLOCKING),
HCTX_FLAG_NAME(NO_SCHED),
HCTX_FLAG_NAME(STACKING),
+ HCTX_FLAG_NAME(TAG_HCTX_SHARED),
};
#undef HCTX_FLAG_NAME
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeKernel Storage Architect
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Re: linux-next: manual merge of the usb tree with the usb.current tree
On Wed, Jan 06, 2021 at 11:50:14AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the usb tree got a conflict in:
>
> drivers/usb/dwc3/gadget.c
>
> between commit:
>
> a1383b3537a7 ("usb: dwc3: gadget: Restart DWC3 gadget when enabling pullup")
>
> from the usb.current tree and commit:
>
> 77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
>
> from the usb tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/usb/dwc3/gadget.c
> index 25f654b79e48,85736dd6673b..
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@@ -2146,8 -2212,7 +2213,9 @@@ static int dwc3_gadget_pullup(struct us
> dwc->ev_buf->lpos = (dwc->ev_buf->lpos + count) %
> dwc->ev_buf->length;
> }
> + dwc->connected = false;
> +} else {
> +__dwc3_gadget_start(dwc);
> }
>
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
Thanks for this, should now be fixed up.
greg k-h
Re: [PATCH 1/2] soc: mediatek: Add regulator control for MT8192 MFG power domain
On Mon, Jan 4, 2021 at 10:44 AM Weiyi Lu wrote:
>
> Add regulator control support and specific power domain name of
> MT8192 MFG power domain for regulator lookup.
> Also power domain name can fix the debugfs warning.
> (e.g. debugfs: Directory 'power-domain' with parent 'pm_genpd'
> already present!)
> However, not every domain with name need to get the regulator,
> if we just want to fix the debugfs warning log by adding names to
> power domains. Considering this case, lookup regulator by
> regulator_get_optional() instead of getting a dummy regulator from
> regulator_get() to operate.
>
Hi,
sorry I didn't notice this patch before. I sent out a similar patch
for this problem here:
https://patchwork.kernel.org/project/linux-mediatek/cover/20210107104915.2888408-1-hsi...@chromium.org/
The difference is that
1) we store the requirement for quirks in caps instead of name.
2) regulators are under power-domain nodes instead of mfg devices in dts.
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mt8192-pm-domains.h | 1 +
> drivers/soc/mediatek/mtk-pm-domains.c| 42
> ++--
> drivers/soc/mediatek/mtk-pm-domains.h| 2 ++
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mt8192-pm-domains.h
> b/drivers/soc/mediatek/mt8192-pm-domains.h
> index 0fdf6dc..7db0ad3 100644
> --- a/drivers/soc/mediatek/mt8192-pm-domains.h
> +++ b/drivers/soc/mediatek/mt8192-pm-domains.h
> @@ -49,6 +49,7 @@
> .ctl_offs = 0x0308,
> .sram_pdn_bits = GENMASK(8, 8),
> .sram_pdn_ack_bits = GENMASK(12, 12),
> + .name = "mfg",
> },
> [MT8192_POWER_DOMAIN_MFG1] = {
> .sta_mask = BIT(3),
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c
> b/drivers/soc/mediatek/mtk-pm-domains.c
> index fb70cb3..a160800 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.c
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "mt8173-pm-domains.h"
> @@ -40,6 +41,7 @@ struct scpsys_domain {
> struct clk_bulk_data *subsys_clks;
> struct regmap *infracfg;
> struct regmap *smi;
> + struct regulator *supply;
> };
>
> struct scpsys {
> @@ -187,6 +189,22 @@ static int scpsys_bus_protect_disable(struct
> scpsys_domain *pd)
> return _scpsys_bus_protect_disable(pd->data->bp_infracfg,
> pd->infracfg);
> }
>
> +static int scpsys_regulator_enable(struct scpsys_domain *pd)
> +{
> + if (!pd->supply)
> + return 0;
> +
> + return regulator_enable(pd->supply);
> +}
> +
> +static int scpsys_regulator_disable(struct scpsys_domain *pd)
> +{
> + if (!pd->supply)
> + return 0;
> +
> + return regulator_disable(pd->supply);
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scpsys_domain *pd = container_of(genpd, struct scpsys_domain,
> genpd);
> @@ -194,9 +212,13 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> bool tmp;
> int ret;
>
> + ret = scpsys_regulator_enable(pd);
> + if (ret < 0)
> + return ret;
> +
> ret = clk_bulk_enable(pd->num_clks, pd->clks);
> if (ret)
> - return ret;
> + goto err_disable_regulator;
>
> /* subsys power on */
> regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_ON_BIT);
> @@ -232,6 +254,8 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
> err_pwr_ack:
> clk_bulk_disable(pd->num_clks, pd->clks);
> +err_disable_regulator:
> + scpsys_regulator_disable(pd);
> return ret;
> }
>
> @@ -267,6 +291,10 @@ static int scpsys_power_off(struct generic_pm_domain
> *genpd)
>
> clk_bulk_disable(pd->num_clks, pd->clks);
>
> + ret = scpsys_regulator_disable(pd);
> + if (ret < 0)
> + return ret;
> +
> return 0;
> }
>
> @@ -315,6 +343,16 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys
> *scpsys, struct device_no
> if (IS_ERR(pd->smi))
> return ERR_CAST(pd->smi);
>
> + if (pd->data->name) {
> + pd->supply = devm_regulator_get_optional(scpsys->dev,
> pd->data->name);
> + if (IS_ERR(pd->supply)) {
> + if (PTR_ERR(pd->supply) == -ENODEV)
> + pd->supply = NULL;
> + else
> + return ERR_CAST(pd->supply);
> + }
> + }
> +
> num_clks = of_clk_get_parent_count(node);
> if (num_clks > 0) {
> /* Calculate number of subsys_clks */
> @@ -397,7 +435,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys
> *scpsys, struct device_no
> goto err_unprepare_subsys_clocks;
>
Re: [PATCH v2] powerpc: fix alignment bug whithin the init sections
Le 02/01/2021 à 21:11, Ariel Marcovitch a écrit :
This is a bug that causes early crashes in builds with a
.exit.text section smaller than a page and a .init.text section that
ends in the beginning of a physical page (this is kinda random, which
might explain why this wasn't really encountered before).
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code might become read-only at runtime and because the
.init.text section can potentially reside on the same physical page as
.init.data, the beginning of .init.data might be mapped read-only along
with .init.text.
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, make _einittext page aligned and also align .exit.text
to make sure .init.data is always seperated from the text segments.
Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
Signed-off-by: Ariel Marcovitch
Reviewed-by: Christophe Leroy
---
arch/powerpc/kernel/vmlinux.lds.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 6db90cdf11da..b6c765d8e7ee 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -187,6 +187,11 @@ SECTIONS
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
+
+ /* .init.text might be RO so we must
+ * ensure this section ends in a page boundary.
+ */
+ . = ALIGN(PAGE_SIZE);
_einittext = .;
#ifdef CONFIG_PPC64
*(.tramp.ftrace.init);
@@ -200,6 +205,8 @@ SECTIONS
EXIT_TEXT
}
+ . = ALIGN(PAGE_SIZE);
+
.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
}
base-commit: 2c85ebc57b3e1817b6ce1a6b703928e113a90442
Re: [PATCH v1 06/15] powerpc: Remove address and errorcode arguments from do_break()
Le 27/12/2020 à 04:25, Nicholas Piggin a écrit : Excerpts from Christophe Leroy's message of December 22, 2020 11:28 pm: Let do_break() retrieve address and errorcode from regs. This simplifies the code and shouldn't impeed performance as address and errorcode are likely still hot in the cache. Suggested-by: Nicholas Piggin Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/debug.h | 3 +-- arch/powerpc/kernel/exceptions-64s.S | 2 -- arch/powerpc/kernel/head_8xx.S | 5 - arch/powerpc/kernel/process.c| 8 +++- 4 files changed, 4 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/include/asm/debug.h b/arch/powerpc/include/asm/debug.h index ec57daf87f40..0550eceab3ca 100644 --- a/arch/powerpc/include/asm/debug.h +++ b/arch/powerpc/include/asm/debug.h @@ -52,8 +52,7 @@ extern void do_send_trap(struct pt_regs *regs, unsigned long address, unsigned long error_code, int brkpt); #else -extern void do_break(struct pt_regs *regs, unsigned long address, -unsigned long error_code); +void do_break(struct pt_regs *regs); #endif #endif /* _ASM_POWERPC_DEBUG_H */ diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index cfbd1d690033..3ea067bcbb95 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -3262,8 +3262,6 @@ handle_page_fault: /* We have a data breakpoint exception - handle it */ handle_dabr_fault: - ld r4,_DAR(r1) - ld r5,_DSISR(r1) addir3,r1,STACK_FRAME_OVERHEAD bl do_break /* diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 52702f3db6df..81f3c984f50c 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -364,11 +364,6 @@ do_databreakpoint: addir3,r1,STACK_FRAME_OVERHEAD mfspr r4,SPRN_BAR stw r4,_DAR(r11) -#ifdef CONFIG_VMAP_STACK - lwz r5,_DSISR(r11) -#else - mfspr r5,SPRN_DSISR -#endif I didn't think you can do this (at leastuntil after your patch 10). I have my !VMAP path doing mfspr r5,DSISR ; stw r3,_DSISR(r11); Yes you are right, I went too quick. Christophe
Re: [PATCH 0/8] FPGA DFL Changes for 5.12
On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote: > > On 1/10/21 9:05 AM, Moritz Fischer wrote: > > Tom, > > > > On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote: > >> On 1/7/21 8:09 AM, Tom Rix wrote: > >>> On 1/6/21 8:37 PM, Moritz Fischer wrote: > This is a resend of the previous (unfortunately late) patchset of > changes for FPGA DFL. > >>> Is there something I can do to help ? > >>> > >>> I am paid to look after linux-fpga, so i have plenty of time. > >>> > >>> Some ideas of what i am doing now privately i can do publicly. > >>> > >>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in > >>> a pullable state. > > Is it not? It currently points to v5.11-rc1. If I start applying patches > > that require the changes that went into Greg's branch I can merge. > > I mean the window between when we have staged patches and when they go into > Greg's branch. > > We don't have any now, maybe those two trival ones. > > Since Greg's branch moves much faster than ours, our staging branch needs to > be rebased regularly until its merge. Ick, no! NEVER rebase a public branch. Why does it matter the speed of my branch vs. anyone elses? Git handles merges very well. Just like Linus's branches move much faster than mine, and I don't rebase my branches, you shouldn't rebase yours. Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no git pulls, so why does it matter at all for any of this? What is the problem you are trying to solve here? thanks, greg k-h
Re: [PATCH] block/rnbd-clt: improve find_or_create_sess() return check
On Sun, Jan 10, 2021 at 10:58 PM wrote:
>
> From: Tom Rix
>
> clang static analysis reports this problem
>
> rnbd-clt.c:1212:11: warning: Branch condition evaluates to a
> garbage value
> else if (!first)
> ^~
>
> This is triggered in the find_and_get_or_create_sess() call
> because the variable first is not initialized and the
> earlier check is specifically for
>
> if (sess == ERR_PTR(-ENOMEM))
>
> This is false positive.
>
> But the if-check can be reduced by initializing first to
> false and then returning if the call to find_or_creat_sess()
> does not set it to true. When it remains false, either
> sess will be valid or not. The not case is caught by
> find_and_get_or_create_sess()'s caller rnbd_clt_map_device()
>
> sess = find_and_get_or_create_sess(...);
> if (IS_ERR(sess))
> return ERR_CAST(sess);
>
> Since find_and_get_or_create_sess() initializes first to false
> setting it in find_or_create_sess() is not needed.
>
> Signed-off-by: Tom Rix
Less LOC is better :)
Acked-by: Jack Wang
Thanks Tom and Nathan!
> ---
> drivers/block/rnbd/rnbd-clt.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
> index 96e3f9fe8241..251f747cf10d 100644
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@ -919,6 +919,7 @@ static struct rnbd_clt_session *__find_and_get_sess(const
> char *sessname)
> return NULL;
> }
>
> +/* caller is responsible for initializing 'first' to false */
> static struct
> rnbd_clt_session *find_or_create_sess(const char *sessname, bool *first)
> {
> @@ -934,8 +935,7 @@ rnbd_clt_session *find_or_create_sess(const char
> *sessname, bool *first)
> }
> list_add(>list, _list);
> *first = true;
> - } else
> - *first = false;
> + }
> mutex_unlock(_lock);
>
> return sess;
> @@ -1203,13 +1203,11 @@ find_and_get_or_create_sess(const char *sessname,
> struct rnbd_clt_session *sess;
> struct rtrs_attrs attrs;
> int err;
> - bool first;
> + bool first = false;
> struct rtrs_clt_ops rtrs_ops;
>
> sess = find_or_create_sess(sessname, );
> - if (sess == ERR_PTR(-ENOMEM))
> - return ERR_PTR(-ENOMEM);
> - else if (!first)
> + if (!first)
> return sess;
>
> if (!path_cnt) {
> --
> 2.27.0
>
Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors
Hi Jonathan,
In section 4.7.2.5.1 of the specification, the following exponent is
the scale value
uint32 axis_attributes_high
Bits[15:11] Exponent: The power-of-10 multiplier in two’s-complement
format that is applied to the sensor unit
specified by the SensorType field.
and the resolution is
uint32 axis_resolution
Bits[31:27] Exponent: The power-of-10 multiplier in two’s-complement format
that is applied to the Res field. Bits[26:0] Res: The resolution of
the sensor axis.
>From code in scmi_protocol.h
/**
* scmi_sensor_axis_info - describes one sensor axes
* @id: The axes ID.
* @type: Axes type. Chosen amongst one of @enum scmi_sensor_class.
* @scale: Power-of-10 multiplier applied to the axis unit.
* @name: NULL-terminated string representing axes name as advertised by
* SCMI platform.
* @extended_attrs: Flag to indicate the presence of additional extended
*attributes for this axes.
* @resolution: Extended attribute representing the resolution of the axes.
* Set to 0 if not reported by this axes.
* @exponent: Extended attribute representing the power-of-10 multiplier that
* is applied to the resolution field. Set to 0 if not reported by
* this axes.
* @attrs: Extended attributes representing minimum and maximum values
* measurable by this axes. Set to 0 if not reported by this sensor.
*/
struct scmi_sensor_axis_info {
unsigned int id;
unsigned int type;
int scale; //This is the scale used for min/max range
char name[SCMI_MAX_STR_SIZE];
bool extended_attrs;
unsigned int resolution;
int exponent; // This is the scale used in resolution
struct scmi_range_attrs attrs;
};
The scale above is the Power-of-10 multiplier which is applied to the min range
and the max range value
but the resolution is equal to resolution and multiplied by
Power-of-10 multiplier
of exponent in the above struct.
So as can be seen above the value of the power of 10 multiplier used
for min/max range
can be different than the value of the power of 10 multiplier used for
the resolution.
Hence, if I have to use IIO_AVAIL_RANGE to specify min/max range and as well
as resolution, then I have to use the float format with the scale applied.
If there is another way which you know of and prefer, please let me know.
Thanks,
Jyoti
Thanks,
Jyoti
On Sat, Jan 9, 2021 at 11:01 AM Jonathan Cameron wrote:
>
> On Wed, 6 Jan 2021 21:23:53 +
> Jyoti Bhayana wrote:
>
> > Hi Jonathan,
> >
> > Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding
> > IIO_VAL_FRACTIONAL_LONG
> > or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can
> > be different
> > than the one used in resolution according to specification.
>
> That's somewhat 'odd'. Given min/max are inherently values the sensor is
> supposed to
> be able to return why give them different resolutions? Can you point me at a
> specific
> section of the spec? The axis_min_range_low etc fields don't seem to have
> units specified
> but I assumed they were in sensor units and so same scale factors?
>
> >
> > I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using
> > IIO_AVAIL_RANGE
> > and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
> > Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64
> > will use 4 values
> > val_high,val_low,and val2_high and val2_low.
>
> I'm not keen on the changing that internal kernel interface unless we
> absolutely
> have to. read_avail() is called from consumer drivers and they won't know
> anything
> about this new variant.
>
> >
> > Let me know if that is an acceptable solution.
>
> Hmm. It isn't a standard use of the ABI given the value in the buffer is (I
> assume)
> raw (needs scale applied). However, it isn't excluded by the ABI docs.
> Whether
> a standard userspace is going to expect it is not clear to me.
>
> I don't want to end up in a position where we end up with available being
> generally
> added for processed when what most people care about is what the value range
> they
> might get from a polled read is (rather than via a buffer).
>
> So I'm not that keen on this solution but if we can find a way to avoid it.
>
> Jonathan
>
>
> >
> >
> > Thanks,
> > Jyoti
> >
>
Re: [PATCH 3/5] af_vsock: send/receive loops for SOCK_SEQPACKET.
> Hmm, are you sure you need to convert > "err" to the pointer, just to return true/false > as the return value? > How about still returning "err" itself? In this case i need to reserve some value for "err" as success, because both 0 and negative values are passed to caller when this function returns false(check failed). May be i will inline this function. > Its not very clear (only for me perhaps) how > dequeue_total and len correlate. Are they > equal here? Would you need to check that > dequeued_total >= record_len? > I mean, its just a bit strange that you check > dequeued_total>0 and no longer use that var > inside the block. When "dequeued_total > 0" record copy is succeed. "len" is length of user buffer. I think i can replace "dequeued_total" to some flag, like "error", because in SOCK_SEQPACKET mode record could be copied whole or error returned.
[PATCH] drm/ast: Disable fast reset after DRAM initial
[Bug][AST2500]
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset mode is mainly designed for ARM ICE debugger.
Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be
first enabled to avoid system deadlock before disable fast reset mode.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_main.c | 4 ++
drivers/gpu/drm/ast/ast_post.c | 72 ++
3 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index da6dfb677540..8bdd1482370d 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -320,6 +320,7 @@ bool ast_is_vga_enabled(struct drm_device *dev);
void ast_post_gpu(struct drm_device *dev);
u32 ast_mindwm(struct ast_private *ast, u32 r);
void ast_moutdwm(struct ast_private *ast, u32 r, u32 v);
+void patch_ahb_ast2500(struct ast_private *ast);
/* ast dp501 */
void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 size);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 3775fe26f792..3c072c6589a2 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -96,6 +96,10 @@ static void ast_detect_config_mode(struct drm_device *dev,
u32 *scu_rev)
jregd0 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
jregd1 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1, 0xff);
if (!(jregd0 & 0x80) || !(jregd1 & 0x10)) {
+ /* Patch AST2500 */
+ if (((dev->pdev->revision & 0xF0) == 0x40) && ((jregd0 & 0xC0)
== 0))
+ patch_ahb_ast2500(ast);
+
/* Double check it's actually working */
data = ast_read32(ast, 0xf004);
if (data != 0x) {
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 8902c2f84bf9..2d121c5b2233 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2026,6 +2026,33 @@ static bool ast_dram_init_2500(struct ast_private *ast)
return true;
}
+void patch_ahb_ast2500(struct ast_private *ast)
+{
+ u32 data;
+
+patch_ahb_lock:
+ /* Clear bus lock condition */
+ ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
+ ast_moutdwm(ast, 0x1e600084, 0x0001);
+ ast_moutdwm(ast, 0x1e600088, 0x);
+ ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+ data = ast_mindwm(ast, 0x1e6e2070);
+ if (data & 0x0800) {/* check fast
reset */
+
+ ast_moutdwm(ast, 0x1E785004, 0x0010);
+ ast_moutdwm(ast, 0x1E785008, 0x4755);
+ ast_moutdwm(ast, 0x1E78500c, 0x0033);
+ udelay(1000);
+ }
+ ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+ do {
+ data = ast_mindwm(ast, 0x1e6e2000);
+ if (data == 0x)
+ goto patch_ahb_lock;
+ } while (data != 1);
+ ast_moutdwm(ast, 0x1e6e207c, 0x0800); /* clear fast
reset */
+}
+
void ast_post_chip_2500(struct drm_device *dev)
{
struct ast_private *ast = to_ast_private(dev);
@@ -2033,39 +2060,32 @@ void ast_post_chip_2500(struct drm_device *dev)
u8 reg;
reg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
- if ((reg & 0x80) == 0) {/* vga only */
+ if ((reg & 0xC0) == 0) {/* vga only */
/* Clear bus lock condition */
- ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
- ast_moutdwm(ast, 0x1e600084, 0x0001);
- ast_moutdwm(ast, 0x1e600088, 0x);
- ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
- ast_write32(ast, 0xf004, 0x1e6e);
- ast_write32(ast, 0xf000, 0x1);
- ast_write32(ast, 0x12000, 0x1688a8a8);
- while (ast_read32(ast, 0x12000) != 0x1)
- ;
-
- ast_write32(ast, 0x1, 0xfc600309);
- while (ast_read32(ast, 0x1) != 0x1)
- ;
+ patch_ahb_ast2500(ast);
+
+ /* Disable watchdog */
+ ast_moutdwm(ast, 0x1E78502C, 0x);
+ ast_moutdwm(ast, 0x1E78504C, 0x);
+ /* Reset USB port */
+ ast_moutdwm(ast, 0x1E6E2090, 0x2000); /* add
at V1.2 */
+ ast_moutdwm(ast, 0x1E6E2094, 0x4000); /* add
at V1.2 */
+ if (ast_mindwm(ast, 0x1E6E2070) & 0x0080) { /* add
at V1.2 */
+ ast_moutdwm(ast, 0x1E6E207C, 0x0080); /* add
at
Re: [PATCH v5 0/2] UIO support for dfl devices
On Sun, Jan 10, 2021 at 11:58:44AM -0800, Moritz Fischer wrote: > Hi Xu, > > On Sat, Jan 02, 2021 at 11:13:00AM +0800, Xu Yilun wrote: > > This patchset supports some dfl device drivers written in userspace. > > > > In the patchset v1, the "driver_override" interface should be used to bind > > the DFL UIO driver to DFL devices. But there is concern that the > > "driver_override" interface is not OK itself. > > > > In v2, we use a new matching algorithem. The "driver_override" interface > > is abandoned, the DFL UIO driver matches any DFL device which could not be > > handled by other DFL drivers. So the DFL UIO driver could be used for new > > DFL devices which are not supported by kernel. The concern is the UIO may > > not be suitable as a default/generic driver for all dfl features, such as > > features with multiple interrupts. > > > > In v4, we specify each matching device in the id_table of the UIO driver, > > just the same as other dfl drivers do. Now the UIO driver supports Ether > > Group feature. To support more DFL features, their feature ids should be > > added to the driver's id_table. > > I think this is what you want, yes. Instead of doing a driver override > or such, add devices that should always be bound to UIO to a device id > table. For those you temporarily want to bind, make sure you can unbind > them and use 'new_id' or 'bind' in sysfs, similar to what sysfs does. "new_id" is not generic to all bus drivers, we need to add the attr in dfl bus driver like pci do, actually I think quite similar to "driver_override", How do you think? I'm glad we restarted the discussion for the temporary binding of UIO driver. Thanks, Yilun
perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)
Hi, this e-mails is a follow-up of my report at: https://bugzilla.suse.com/show_bug.cgi?id=1180681 There is a problem with *@plt symbols in some libraries, they are unresolved by perf (memcmp@plt in this case): > 0.26% main2/usr/lib64/libstdc++.so.6.0.280xa51a0 l [.] 0x000a51a0 On the other hand, plt symbols in other libraries are fine (memset@plt in this case): > 0.17% main2/usr/lib64/libantlr4-runtime.so.4.8 0x4ed10 l [.] memset@plt I dumped memcmp's .plt.rela entries in perf: /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10 entry=10 /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10 entry=10 The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070 (perf's computed) = 0x4130. The problem is perf assumes nth entry of .plt.rela to correspond to nth function in .plt, but memcmp is in .plt.sec in libstdc++.so: > Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries: > Offset Info Type Symbol's Value Symbol's Name + Addend > ... > 001dc838 00780007 R_X86_64_JUMP_SLOT memcmp@GLIBC_2.2.5 + 0 Perf does this with the rela entries: https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385 It takes a symbol index from sym.r_info. Then it resolves its name from .dynsym, appending "@plt" to it. Then this name is added to perf's symbol table along with address which is computed as .rela.plt index multiplied by entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on x86_64 too). And from this comes (almost) the offset above: > $ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? ' > 12 .plt 3fb0 0009e020 0009e020 0009e020 2**4 > 14 .plt.sec 3fa0 000a2160 000a2160 000a2160 2**4 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry (header). Richard writes: == .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on the second call (and on). This is used / emitted for ELF object instrumented for Intel CET. The details escape me for the moment but I hope the x86 ABI documents this (and the constraints) in detail. == How should perf find out whether to consider .plt or .plt.sec? Or generally, how to properly find an address of *@plt symbols like memcmp@plt above? thanks, -- js suse labs
Re: [PATCH 5/5] Input: omap4-keypad - implement errata check for lost key-up events
On Mon, Jan 11, 2021 at 08:10:18AM +0200, Tony Lindgren wrote:
> * Tony Lindgren [210110 19:08]:
> > --- a/drivers/input/keyboard/omap4-keypad.c
> > +++ b/drivers/input/keyboard/omap4-keypad.c
> > +/*
> > + * Errata ID i689 "1.32 Keyboard Key Up Event Can Be Missed".
> > + * Interrupt may not happen for key-up events. We must clear stuck
> > + * key-up events after the keyboard hardware has auto-idled.
> > + */
> > +static int __maybe_unused omap4_keypad_runtime_suspend(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
> > + u32 active;
> > +
> > + active = kbd_readl(keypad_data, OMAP4_KBD_STATEMACHINE);
> > + if (active) {
> > + pm_runtime_mark_last_busy(dev);
> > + return -EBUSY;
> > + }
> > +
> > + omap4_keypad_scan_keys(keypad_data, true);
> > +
> > + return 0;
> > +}
>
> So with the improvments done, here we need to replace the true above with 0
> so when the hardware is idle we clear any stuck keys. Updated patch below.
Applied, thank you.
--
Dmitry
Re: [PATCH 4/5] Input: omap4-keypad - use PM runtime autosuspend
On Mon, Jan 11, 2021 at 08:02:50AM +0200, Tony Lindgren wrote:
> * Tony Lindgren [210111 05:13]:
> > * Dmitry Torokhov [210111 05:01]:
> > > Hi Tony,
> > >
> > > On Sun, Jan 10, 2021 at 09:05:28PM +0200, Tony Lindgren wrote:
> > > > @@ -350,15 +379,12 @@ static int omap4_keypad_probe(struct
> > > > platform_device *pdev)
> > > >
> > > > error = omap4_keypad_check_revision(>dev,
> > > > keypad_data);
> > > > - if (!error) {
> > > > - /* Ensure device does not raise interrupts */
> > > > - omap4_keypad_stop(keypad_data);
> > > > - }
> > > > -
> > > > - pm_runtime_put_sync(>dev);
> > >
> > > Why are we moving this down? The idea was to make sure the power usage
> > > counters are correct even if we exit probe early.
> >
> > Yes you are right, omap4_keypad_close() won't help with balancing the
> > get if we exit early.
> >
> > > Can we call pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
> > > here?
> >
> > Yes that should work as there's no more register access during the probe.
>
> Below is an updated version. I updated probe to use dev instead of
> >dev since we have it there. Does this look OK to you?
Yep, looks good, applied.
--
Dmitry
Re: [PATCH bpf-next 1/4] bpf: enable task local storage for tracing programs
On 1/8/21 3:19 PM, Song Liu wrote:
To access per-task data, BPF program typically creates a hash table with
pid as the key. This is not ideal because:
1. The use need to estimate requires size of the hash table, with may be
inaccurate;
2. Big hash tables are slow;
3. To clean up the data properly during task terminations, the user need
to write code.
Task local storage overcomes these issues and becomes a better option for
these per-task data. Task local storage is only available to BPF_LSM. Now
enable it for tracing programs.
Reported-by: kernel test robot
Signed-off-by: Song Liu
---
include/linux/bpf.h| 7 +++
include/linux/bpf_lsm.h| 22 --
include/linux/bpf_types.h | 2 +-
include/linux/sched.h | 5 +
kernel/bpf/Makefile| 3 +--
kernel/bpf/bpf_local_storage.c | 28 +---
kernel/bpf/bpf_lsm.c | 4
kernel/bpf/bpf_task_storage.c | 26 ++
kernel/fork.c | 5 +
kernel/trace/bpf_trace.c | 4
10 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 07cb5d15e7439..cf16548f28f7b 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1480,6 +1480,7 @@ struct bpf_prog *bpf_prog_by_id(u32 id);
struct bpf_link *bpf_link_by_id(u32 id);
const struct bpf_func_proto *bpf_base_func_proto(enum bpf_func_id func_id);
+void bpf_task_storage_free(struct task_struct *task);
#else /* !CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get(u32 ufd)
{
@@ -1665,6 +1666,10 @@ bpf_base_func_proto(enum bpf_func_id func_id)
{
return NULL;
}
+
+static inline void bpf_task_storage_free(struct task_struct *task)
+{
+}
#endif /* CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get_type(u32 ufd,
@@ -1860,6 +1865,8 @@ extern const struct bpf_func_proto bpf_per_cpu_ptr_proto;
extern const struct bpf_func_proto bpf_this_cpu_ptr_proto;
extern const struct bpf_func_proto bpf_ktime_get_coarse_ns_proto;
extern const struct bpf_func_proto bpf_sock_from_file_proto;
+extern const struct bpf_func_proto bpf_task_storage_get_proto;
+extern const struct bpf_func_proto bpf_task_storage_delete_proto;
const struct bpf_func_proto *bpf_tracing_func_proto(
enum bpf_func_id func_id, const struct bpf_prog *prog);
diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
index 0d1c33ace3987..479c101546ad1 100644
--- a/include/linux/bpf_lsm.h
+++ b/include/linux/bpf_lsm.h
@@ -38,21 +38,9 @@ static inline struct bpf_storage_blob *bpf_inode(
return inode->i_security + bpf_lsm_blob_sizes.lbs_inode;
}
-static inline struct bpf_storage_blob *bpf_task(
- const struct task_struct *task)
-{
- if (unlikely(!task->security))
- return NULL;
-
- return task->security + bpf_lsm_blob_sizes.lbs_task;
-}
-
extern const struct bpf_func_proto bpf_inode_storage_get_proto;
extern const struct bpf_func_proto bpf_inode_storage_delete_proto;
-extern const struct bpf_func_proto bpf_task_storage_get_proto;
-extern const struct bpf_func_proto bpf_task_storage_delete_proto;
void bpf_inode_storage_free(struct inode *inode);
-void bpf_task_storage_free(struct task_struct *task);
#else /* !CONFIG_BPF_LSM */
@@ -73,20 +61,10 @@ static inline struct bpf_storage_blob *bpf_inode(
return NULL;
}
-static inline struct bpf_storage_blob *bpf_task(
- const struct task_struct *task)
-{
- return NULL;
-}
-
static inline void bpf_inode_storage_free(struct inode *inode)
{
}
-static inline void bpf_task_storage_free(struct task_struct *task)
-{
-}
-
#endif /* CONFIG_BPF_LSM */
#endif /* _LINUX_BPF_LSM_H */
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index 99f7fd657d87a..b9edee336d804 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -109,8 +109,8 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKHASH, sock_hash_ops)
#endif
#ifdef CONFIG_BPF_LSM
BPF_MAP_TYPE(BPF_MAP_TYPE_INODE_STORAGE, inode_storage_map_ops)
-BPF_MAP_TYPE(BPF_MAP_TYPE_TASK_STORAGE, task_storage_map_ops)
#endif
+BPF_MAP_TYPE(BPF_MAP_TYPE_TASK_STORAGE, task_storage_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_CPUMAP, cpu_map_ops)
#if defined(CONFIG_XDP_SOCKETS)
BPF_MAP_TYPE(BPF_MAP_TYPE_XSKMAP, xsk_map_ops)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 51d535b69bd6f..4a173defa2010 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -42,6 +42,7 @@ struct audit_context;
struct backing_dev_info;
struct bio_list;
struct blk_plug;
+struct bpf_local_storage;
struct capture_control;
struct cfs_rq;
struct fs_struct;
@@ -1348,6 +1349,10 @@ struct task_struct {
/* Used by LSM modules for access restriction: */
void*security;
#endif
+#ifdef CONFIG_BPF_SYSCALL
+ /*
Re: [PATCH 3/5] Input: omap4-keypad - move rest of key scanning to a separate function
On Mon, Jan 11, 2021 at 07:57:39AM +0200, Tony Lindgren wrote: > * Dmitry Torokhov [210111 04:50]: > > On Sun, Jan 10, 2021 at 09:05:27PM +0200, Tony Lindgren wrote: > > > Let's move rest of the key scanning code to omap4_keypad_scan_keys(). > > > We will use omap4_keypad_scan_keys() also for implementing errata > > > handling to clear the stuck last key in the following patch. > > > > And this one will become then... > > Yes great, this works for me. OK, thanks, applied. -- Dmitry
Re: [PATCH 2/5] Input: omap4-keypad - scan keys in two phases and simplify with bitmask
On Mon, Jan 11, 2021 at 07:56:54AM +0200, Tony Lindgren wrote: > * Dmitry Torokhov [210111 04:48]: > > Technically speaking, userspace is free to accumulate the events until > > it receives EV_SYN/SYN_REPORT event and process the events in the event > > packet in order it sees fit. So to achieve what you want, I think we > > should issue 2 input_sync()s, one for the release block, and another is > > for press. I think we can also simplify the code if we pass into the new > > scan function exact set of keys that are being released or pressed. > > > > How about the version below? > > Yes that works nicely. Excellent, applied, thank you. -- Dmitry
Re: [RFC PATCH v2] selinux: security: Move selinux_state to a separate page
On 2021-01-08 20:55, Miguel Ojeda wrote: On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar wrote: We want to seek your suggestions and comments on the idea and the changes in the patch. Not sure why I was Cc'd, but I have a quick comment nevertheless. +#ifdef CONFIG_SECURITY_RTIC +struct selinux_state selinux_state __rticdata; +#else struct selinux_state selinux_state; +#endif If you define an empty __rticdata for the !CONFIG case, then we don't need #ifdefs for uses like this. Cheers, Miguel Thank you for the review! Will update this change in the next version of the patch soon. Thanks, Preeti
Re: [PATCH 1/5] Input: omap4-keypad - disable unused long interrupts
On Sun, Jan 10, 2021 at 09:05:25PM +0200, Tony Lindgren wrote: > We are not using the long events and they produce extra interrupts. > Let's not enable them at all. > > Note that also the v3.0.8 Linux Android kernel has long interrupts > disabled. > > Cc: Arthur Demchenkov > Cc: Carl Philipp Klemm > Cc: Merlijn Wajer > Cc: Pavel Machek > Cc: ruleh > Cc: Sebastian Reichel > Signed-off-by: Tony Lindgren Applied, thank you. -- Dmitry
Re: [PATCH 0/5] Optimize iommu_map_sg() performance
Hi Isaac, On 2021-01-09 07:20, Isaac J. Manjarres wrote: > The iommu_map_sg() code currently iterates through the given > scatter-gather list, and in the worst case, invokes iommu_map() > for each element in the scatter-gather list, which calls into > the IOMMU driver through an indirect call. For an IOMMU driver > that uses a format supported by the io-pgtable code, the IOMMU > driver will then call into the io-pgtable code to map the chunk. > > Jumping between the IOMMU core code, the IOMMU driver, and the > io-pgtable code and back for each element in a scatter-gather list > is not efficient. > > Instead, add a map_sg() hook in both the IOMMU driver ops and the > io-pgtable ops. iommu_map_sg() can then call into the IOMMU driver's > map_sg() hook with the entire scatter-gather list, which can call > into the io-pgtable map_sg() hook, which can process the entire > scatter-gather list, signficantly reducing the number of indirect > calls, and jumps between these layers, boosting performance. > > On a system that uses the ARM SMMU driver, and the ARM LPAE format, > the current implementation of iommu_map_sg() yields the following > latencies for mapping scatter-gather lists of various sizes. These > latencies are calculated by repeating the mapping operation 10 times: > > sizeiommu_map_sg latency > 4K0.624 us > 64K9.468 us > 1M 122.557 us > 2M 239.807 us > 12M 1435.979 us > 24M 2884.968 us > 32M 3832.979 us > > On the same system, the proposed modifications yield the following > results: > > sizeiommu_map_sg latency > 4K3.645 us > 64K4.198 us > 1M 11.010 us > 2M 17.125 us > 12M 82.416 us > 24M 158.677 us > 32M 210.468 us > > The procedure for collecting the iommu_map_sg latencies is > the same in both experiments. Clearly, reducing the jumps > between the different layers in the IOMMU code offers a > signficant performance boost in iommu_map_sg() latency. > 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 [
Re: [PATCH v5 1/2] fpga: dfl: add the userspace I/O device support for DFL devices
On Sun, Jan 10, 2021 at 12:11:17PM -0800, Moritz Fischer wrote:
> On Sat, Jan 02, 2021 at 11:13:01AM +0800, Xu Yilun wrote:
> > This patch supports the DFL drivers be written in userspace. This is
> > realized by exposing the userspace I/O device interfaces.
> >
> > The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
> > platform device with the DFL device's resources, and let the generic UIO
> > platform device driver provide support to userspace access to kernel
> > interrupts and memory locations.
> >
> > The driver now supports the ether group feature. To support a new DFL
> > feature been directly accessed via UIO, its feature id should be added to
> > the driver's id_table.
> >
> > Signed-off-by: Xu Yilun
> > Reviewed-by: Tom Rix
> > ---
> > v2: switch to the new matching algorithem. It matches DFL devices which
> > could not be handled by other DFL drivers.
> > refacor the code about device resources filling.
> > fix some comments.
> > v3: split the dfl.c changes out of this patch.
> > some minor fixes
> > v4: drop the idea of a generic matching algorithem, instead we specify
> > each matching device in id_table.
> > to make clear that only one irq is supported, the irq handling code
> > is refactored.
> > v5: refactor the irq resource code.
> > ---
> > drivers/fpga/Kconfig| 10 +
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/dfl-uio-pdev.c | 91
> > +
> > 3 files changed, 102 insertions(+)
> > create mode 100644 drivers/fpga/dfl-uio-pdev.c
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 5ff9438..61445be 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -203,6 +203,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
> > the card. It also instantiates the SPI master (spi-altera) for
> > the card's BMC (Board Management Controller).
> >
> > +config FPGA_DFL_UIO_PDEV
> > + tristate "FPGA DFL Driver for Userspace I/O platform devices"
> > + depends on FPGA_DFL && UIO_PDRV_GENIRQ
> > + help
> > + Enable this to allow some DFL drivers be written in userspace. It
> > + adds the uio_pdrv_genirq platform device with the DFL feature's
> > + resources, and lets the generic UIO platform device driver provide
> > + support for userspace access to kernel interrupts and memory
> > + locations.
> > +
> > config FPGA_DFL_PCI
> > tristate "FPGA DFL PCIe Device Driver"
> > depends on PCI && FPGA_DFL
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 18dc9885..8847fe0 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o
> > dfl-afu-dma-region.o
> > dfl-afu-objs += dfl-afu-error.o
> >
> > obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-nios.o
> > +obj-$(CONFIG_FPGA_DFL_UIO_PDEV)+= dfl-uio-pdev.o
> >
> > # Drivers for FPGAs which implement DFL
> > obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> > diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c
> > new file mode 100644
> > index 000..a4cd581
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio-pdev.c
> > @@ -0,0 +1,91 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DFL driver for Userspace I/O platform devices
> > + *
> > + * Copyright (C) 2020 Intel Corporation, Inc.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRIVER_NAME "dfl-uio-pdev"
> > +
> > +static int dfl_uio_pdev_probe(struct dfl_device *ddev)
> > +{
> > + struct platform_device_info pdevinfo = { 0 };
> > + struct uio_info uio_pdata = { 0 };
> > + struct platform_device *uio_pdev;
> > + struct device *dev = >dev;
> > + unsigned int num_res = 1;
> > + struct resource res[2];
> > +
> > + res[0].parent = >mmio_res;
> > + res[0].flags = IORESOURCE_MEM;
> > + res[0].start = ddev->mmio_res.start;
> > + res[0].end = ddev->mmio_res.end;
> > +
> > + if (ddev->num_irqs) {
> > + if (ddev->num_irqs > 1)
> > + dev_warn(>dev,
> > +"%d irqs for %s, but UIO only supports the
> > first one\n",
> > +ddev->num_irqs, dev_name(>dev));
> > +
> > + res[1].flags = IORESOURCE_IRQ;
> > + res[1].start = ddev->irqs[0];
> > + res[1].end = ddev->irqs[0];
> > + num_res++;
> > + }
> > +
> > + uio_pdata.name = DRIVER_NAME;
> > + uio_pdata.version = "0";
> > +
> > + pdevinfo.name = "uio_pdrv_genirq";
> > + pdevinfo.res = res;
> > + pdevinfo.num_res = num_res;
> > + pdevinfo.parent = >dev;
> > + pdevinfo.id = PLATFORM_DEVID_AUTO;
> > + pdevinfo.data = _pdata;
> > + pdevinfo.size_data = sizeof(uio_pdata);
> > +
> > + uio_pdev = platform_device_register_full();
> > + if (!IS_ERR(uio_pdev))
> > +
Re: [PATCH 09/15] gpio: support ROHM BD71815 GPOs
Hi Linus,
Thanks a lot for review!
On Sat, 2021-01-09 at 01:45 +0100, Linus Walleij wrote:
> On Fri, Jan 8, 2021 at 2:39 PM Matti Vaittinen
> wrote:
>
> > Support GPO(s) found from ROHM BD71815 power management IC. The IC
> > has two
> > GPO pins but only one is properly documented in data-sheet. The
> > driver
> > exposes by default only the documented GPO. The second GPO is
> > connected to
> > E5 pin and is marked as GND in data-sheet. Control for this
> > undocumented
> > pin can be enabled using a special DT property.
> >
> > This driver is derived from work by Peter Yang <
> > yang...@embest-tech.com>
> > although not so much of original is left.
> >
> > Signed-off-by: Matti Vaittinen
>
> Overall this looks good!
>
> > + depends on MFD_ROHM_BD71828
>
> I suppose this makes i possible to merge out-of-order with the
> core patches actually.
Actually not. MFD_ROHM_BD71828 is existing config as this BD71815 uses
same MFD driver with BD71828. So MFD headers should be in before
merging the depending sub-device drivers.
>
> > +#define DEBUG
>
> Why? Development artifact?
Ouch. Thanks for spotting it :) I'll get rid of that.
> > +#include
>
> You certainly do not need this.
>
> > +#include
> > +#include
>
> I guess registers come from these? Do you need both?
> Add a comment about what they provide.
Ok. Can do. (registers, I will recheck if I can get rid of including
the rohm-generic)
>
> > + g->chip.ngpio = 1;
> > + if (g->e5_pin_is_gpo)
> > + g->chip.ngpio = 2;
>
> Overwriting value, how not elegant.
>
> if (g->e5_pin_is_gpo)
> g->chip.ngpio = 2;
> else
> g->chip.ngpio = 1;
matter of taste I'd say :) As I would say about functions named like
_foo() ;) Not a poin I would fight over though - I can change this :]
> > + g->chip.parent = pdev->dev.parent;
> > + g->chip.of_node = pdev->dev.parent->of_node;
> > + g->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > + g->dev = >dev;
> > +
> > + ret = devm_gpiochip_add_data(>dev, >chip, g);
> > + if (ret < 0) {
> > + dev_err(>dev, "could not register gpiochip,
> > %d\n", ret);
> > + return ret;
> > + }
>
> It's a bit confusing how you use pdev->dev.parent for some stuff
> and >dev for some.
>
> What about assinging
>
> struct device *dev = pdev->dev.parent;
>
> and use dev for all the calls, it looks like it'd work fine.
I wouldn't bind the lifetime of devm functions to the parent device. I
am not sure if it would work - what happens we bind lifetime of XX to
parent device - and next call at probe fails (for example with
DEFERRED?) I _assume_ the XX bound to parent is not released? (Please,
do correct me if I am wrong!)
Br,
Matti Vaittinen
Re: [PATCH 5/5] Input: omap4-keypad - implement errata check for lost key-up events
* Tony Lindgren [210110 19:08]:
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> +/*
> + * Errata ID i689 "1.32 Keyboard Key Up Event Can Be Missed".
> + * Interrupt may not happen for key-up events. We must clear stuck
> + * key-up events after the keyboard hardware has auto-idled.
> + */
> +static int __maybe_unused omap4_keypad_runtime_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
> + u32 active;
> +
> + active = kbd_readl(keypad_data, OMAP4_KBD_STATEMACHINE);
> + if (active) {
> + pm_runtime_mark_last_busy(dev);
> + return -EBUSY;
> + }
> +
> + omap4_keypad_scan_keys(keypad_data, true);
> +
> + return 0;
> +}
So with the improvments done, here we need to replace the true above with 0
so when the hardware is idle we clear any stuck keys. Updated patch below.
Regards,
Tony
8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Thu, 17 Dec 2020 07:54:32 +0200
Subject: [PATCH] Input: omap4-keypad - implement errata check for lost
key-up events
We are still missing handling for errata i689 related issues for the
case where we never see a key up interrupt for the last pressed key.
To fix the issue, we must scan the key state again after the keyboard
controller has idled to check if a key up event was missed. This is
described in the omap4 silicon errata documentation for Errata ID i689
"1.32 Keyboard Key Up Event Can Be Missed":
"When a key is released for a time shorter than the debounce time,
in-between 2 key press (KP1 and KP2), the keyboard state machine will go
to idle mode and will never detect the key release (after KP1, and also
after KP2), and thus will never generate a new IRQ indicating the key
release."
We can use PM runtime autosuspend features to check the keyboard state
after it enters idle.
Cc: Arthur Demchenkov
Cc: Carl Philipp Klemm
Cc: Merlijn Wajer
Cc: Pavel Machek
Cc: ruleh
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/input/keyboard/omap4-keypad.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -60,6 +60,8 @@
dbms) * 1000) / ((1 << ((ptv) + 1)) * (100 / 32768))) - 1)
#define OMAP4_VAL_DEBOUNCINGTIME_16MS \
OMAP4_KEYPAD_DEBOUNCINGTIME_MS(16, OMAP4_KEYPAD_PTV_DIV_128)
+#define OMAP4_KEYPAD_AUTOIDLE_MS 50 /* Approximate measured time */
+#define OMAP4_KEYPAD_IDLE_CHECK_MS (OMAP4_KEYPAD_AUTOIDLE_MS / 2)
enum {
KBD_REVISION_OMAP4 = 0,
@@ -306,6 +308,32 @@ static int omap4_keypad_check_revision(struct device *dev,
return 0;
}
+/*
+ * Errata ID i689 "1.32 Keyboard Key Up Event Can Be Missed".
+ * Interrupt may not happen for key-up events. We must clear stuck
+ * key-up events after the keyboard hardware has auto-idled.
+ */
+static int __maybe_unused omap4_keypad_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
+ u32 active;
+
+ active = kbd_readl(keypad_data, OMAP4_KBD_STATEMACHINE);
+ if (active) {
+ pm_runtime_mark_last_busy(dev);
+ return -EBUSY;
+ }
+
+ omap4_keypad_scan_keys(keypad_data, 0);
+
+ return 0;
+}
+
+static const struct dev_pm_ops omap4_keypad_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap4_keypad_runtime_suspend, NULL, NULL)
+};
+
static void omap4_disable_pm(void *d)
{
pm_runtime_dont_use_autosuspend(d);
@@ -352,6 +380,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
return PTR_ERR(keypad_data->base);
pm_runtime_use_autosuspend(dev);
+ pm_runtime_set_autosuspend_delay(dev, OMAP4_KEYPAD_IDLE_CHECK_MS);
pm_runtime_enable(dev);
error = devm_add_action_or_reset(dev, omap4_disable_pm, dev);
@@ -464,6 +493,7 @@ static struct platform_driver omap4_keypad_driver = {
.driver = {
.name = "omap4-keypad",
.of_match_table = omap_keypad_dt_match,
+ .pm = _keypad_pm_ops,
},
};
module_platform_driver(omap4_keypad_driver);
--
2.30.0
Re: [PATCH 4/5] Input: omap4-keypad - use PM runtime autosuspend
* Tony Lindgren [210111 05:13]:
> * Dmitry Torokhov [210111 05:01]:
> > Hi Tony,
> >
> > On Sun, Jan 10, 2021 at 09:05:28PM +0200, Tony Lindgren wrote:
> > > @@ -350,15 +379,12 @@ static int omap4_keypad_probe(struct
> > > platform_device *pdev)
> > >
> > > error = omap4_keypad_check_revision(>dev,
> > > keypad_data);
> > > - if (!error) {
> > > - /* Ensure device does not raise interrupts */
> > > - omap4_keypad_stop(keypad_data);
> > > - }
> > > -
> > > - pm_runtime_put_sync(>dev);
> >
> > Why are we moving this down? The idea was to make sure the power usage
> > counters are correct even if we exit probe early.
>
> Yes you are right, omap4_keypad_close() won't help with balancing the
> get if we exit early.
>
> > Can we call pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
> > here?
>
> Yes that should work as there's no more register access during the probe.
Below is an updated version. I updated probe to use dev instead of
>dev since we have it there. Does this look OK to you?
Regards,
Tony
8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Sun, 10 Jan 2021 17:38:15 +0200
Subject: [PATCH] Input: omap4-keypad - use PM runtime autosuspend
Implement PM runtime autosuspend support to prepare for adding handling to
clear stuck last pressed key in the following patches. The hardware has
support for autoidle and can wake up to keypress events.
Let's also update omap4_keypad_probe() to use dev instead of >dev
since we already have it from the earlier changes.
Cc: Arthur Demchenkov
Cc: Carl Philipp Klemm
Cc: Merlijn Wajer
Cc: Pavel Machek
Cc: ruleh
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/input/keyboard/omap4-keypad.c | 51 ---
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -172,9 +172,17 @@ static irqreturn_t omap4_keypad_irq_handler(int irq, void
*dev_id)
static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
{
struct omap4_keypad *keypad_data = dev_id;
+ struct device *dev = keypad_data->input->dev.parent;
u32 low, high;
+ int error;
u64 keys;
+ error = pm_runtime_get_sync(dev);
+ if (error < 0) {
+ pm_runtime_put_noidle(dev);
+ return IRQ_NONE;
+ }
+
low = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
high = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
keys = low | (u64)high << 32;
@@ -185,14 +193,23 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq,
void *dev_id)
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
return IRQ_HANDLED;
}
static int omap4_keypad_open(struct input_dev *input)
{
struct omap4_keypad *keypad_data = input_get_drvdata(input);
+ struct device *dev = input->dev.parent;
+ int error;
- pm_runtime_get_sync(input->dev.parent);
+ error = pm_runtime_get_sync(dev);
+ if (error < 0) {
+ pm_runtime_put_noidle(dev);
+ return error;
+ }
disable_irq(keypad_data->irq);
@@ -211,6 +228,9 @@ static int omap4_keypad_open(struct input_dev *input)
enable_irq(keypad_data->irq);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
return 0;
}
@@ -228,14 +248,20 @@ static void omap4_keypad_stop(struct omap4_keypad
*keypad_data)
static void omap4_keypad_close(struct input_dev *input)
{
- struct omap4_keypad *keypad_data;
+ struct omap4_keypad *keypad_data = input_get_drvdata(input);
+ struct device *dev = input->dev.parent;
+ int error;
+
+ error = pm_runtime_get_sync(dev);
+ if (error < 0)
+ pm_runtime_put_noidle(dev);
- keypad_data = input_get_drvdata(input);
disable_irq(keypad_data->irq);
omap4_keypad_stop(keypad_data);
enable_irq(keypad_data->irq);
- pm_runtime_put_sync(input->dev.parent);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
}
static int omap4_keypad_parse_dt(struct device *dev,
@@ -282,6 +308,7 @@ static int omap4_keypad_check_revision(struct device *dev,
static void omap4_disable_pm(void *d)
{
+ pm_runtime_dont_use_autosuspend(d);
pm_runtime_disable(d);
}
@@ -314,6 +341,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
keypad_data->irq = irq;
mutex_init(_data->lock);
+ platform_set_drvdata(pdev, keypad_data);
error = omap4_keypad_parse_dt(dev, keypad_data);
if (error)
Re: [PATCH] scsi: ufs: should not override buffer lengh
Sorry, typo corrected.
Hi Jaegeuk,
I think the problem is that func ufshcd_read_desc_param() is not
expecting
one access unsupported descriptors on RPMB LU.
If we can get the right buf_len from func
ufshcd_map_desc_id_to_length(),
the issue won't happen. -
https://lore.kernel.org/patchwork/patch/1323421/.
What do you think if we update ufshcd_map_desc_id_to_length(add one
param - desc_index)
so that it can tell the correct buf_len in case of RPMB LU?
Thanks,
Can Guo.
On 2021-01-11 12:44, Jaegeuk Kim wrote:
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units
from
rpmb lun. The reason is the unit descriptor length is different per
LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, _buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2a715f13fe1d..722697b5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3293,8 +3293,12 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
- if (param_offset + param_size > buff_len)
- param_size = buff_len - param_offset;
+ if (param_offset + param_size > buff_len) {
+ if (buff_len > param_offset)
+ param_size = buff_len - param_offset;
+ else
+ param_size = 0;
+ }
memcpy(param_read_buf, _buf[param_offset], param_size);
}
out:
[PATCH V1 resend] dcookies: Make dcookies depend on CONFIG_OPROFILE
From: Arnd Bergmann The dcookies stuff is used only with OPROFILE and there is no need to build it if CONFIG_OPROFILE isn't enabled. Build it depending on CONFIG_OPROFILE instead of CONFIG_PROFILING. Reviewed-by: Christoph Hellwig Signed-off-by: Arnd Bergmann [ Viresh: Update the name in #endif part ] Signed-off-by: Viresh Kumar --- fs/Makefile | 2 +- include/linux/dcookies.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/Makefile b/fs/Makefile index 999d1a23f036..0e85d1ae20da 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -64,7 +64,7 @@ obj-$(CONFIG_SYSFS) += sysfs/ obj-$(CONFIG_CONFIGFS_FS) += configfs/ obj-y += devpts/ -obj-$(CONFIG_PROFILING)+= dcookies.o +obj-$(CONFIG_OPROFILE) += dcookies.o obj-$(CONFIG_DLM) += dlm/ # Do not add any filesystems before this line diff --git a/include/linux/dcookies.h b/include/linux/dcookies.h index ddfdac20cad0..8617c1871398 100644 --- a/include/linux/dcookies.h +++ b/include/linux/dcookies.h @@ -11,7 +11,7 @@ #define DCOOKIES_H -#ifdef CONFIG_PROFILING +#ifdef CONFIG_OPROFILE #include #include @@ -64,6 +64,6 @@ static inline int get_dcookie(const struct path *path, unsigned long *cookie) return -ENOSYS; } -#endif /* CONFIG_PROFILING */ +#endif /* CONFIG_OPROFILE */ #endif /* DCOOKIES_H */ -- 2.25.0.rc1.19.g042ed3e048af
Re: [PATCH 2/5] Input: omap4-keypad - scan keys in two phases and simplify with bitmask
* Dmitry Torokhov [210111 04:48]:
> Technically speaking, userspace is free to accumulate the events until
> it receives EV_SYN/SYN_REPORT event and process the events in the event
> packet in order it sees fit. So to achieve what you want, I think we
> should issue 2 input_sync()s, one for the release block, and another is
> for press. I think we can also simplify the code if we pass into the new
> scan function exact set of keys that are being released or pressed.
>
> How about the version below?
Yes that works nicely.
Thanks,
Tony
>
> Input: omap4-keypad - scan keys in two phases and simplify with bitmask
>
> From: Tony Lindgren
>
> Because of errata i689 the keyboard can idle with state where no key
> up interrupts are seen until after the next key press.
>
> This means we need to first check for any lost key up events before
> scanning for new down events.
>
> For example, rapidly pressing shift-shift-j can sometimes produce a J
> instead of j. Let's fix the issue by scanning the keyboard in two
> phases. First we scan for any key up events that we may have missed,
> and then we scan for key down events.
>
> Let's also simplify things with for_each_set_bit() as suggested by
> Dmitry Torokhov .
>
> Signed-off-by: Tony Lindgren
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/keyboard/omap4-keypad.c | 73
> -
> 1 file changed, 45 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/input/keyboard/omap4-keypad.c
> b/drivers/input/keyboard/omap4-keypad.c
> index ab761aa66b6d..6dcf27af856d 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -78,7 +78,7 @@ struct omap4_keypad {
> u32 irqreg_offset;
> unsigned int row_shift;
> bool no_autorepeat;
> - unsigned char key_state[8];
> + u64 keys;
> unsigned short *keymap;
> };
>
> @@ -107,6 +107,33 @@ static void kbd_write_irqreg(struct omap4_keypad
> *keypad_data,
>keypad_data->base + keypad_data->irqreg_offset + offset);
> }
>
> +static int omap4_keypad_report_keys(struct omap4_keypad *keypad_data,
> + u64 keys, bool down)
> +{
> + struct input_dev *input_dev = keypad_data->input;
> + unsigned int col, row, code;
> + DECLARE_BITMAP(mask, 64);
> + unsigned long bit;
> + int events = 0;
> +
> + bitmap_from_u64(mask, keys);
> +
> + for_each_set_bit(bit, mask, keypad_data->rows * BITS_PER_BYTE) {
> + row = bit / BITS_PER_BYTE;
> + col = bit % BITS_PER_BYTE;
> + code = MATRIX_SCAN_CODE(row, col, keypad_data->row_shift);
> +
> + input_event(input_dev, EV_MSC, MSC_SCAN, code);
> + input_report_key(input_dev, keypad_data->keymap[code], down);
> +
> + events++;
> + }
> +
> + if (events)
> + input_sync(input_dev);
> +
> + return events;
> +}
>
> /* Interrupt handlers */
> static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
> @@ -122,35 +149,25 @@ static irqreturn_t omap4_keypad_irq_handler(int irq,
> void *dev_id)
> static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
> {
> struct omap4_keypad *keypad_data = dev_id;
> - struct input_dev *input_dev = keypad_data->input;
> - unsigned char key_state[ARRAY_SIZE(keypad_data->key_state)];
> - unsigned int col, row, code, changed;
> - u32 *new_state = (u32 *) key_state;
> -
> - *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> - *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
> -
> - for (row = 0; row < keypad_data->rows; row++) {
> - changed = key_state[row] ^ keypad_data->key_state[row];
> - if (!changed)
> - continue;
> -
> - for (col = 0; col < keypad_data->cols; col++) {
> - if (changed & (1 << col)) {
> - code = MATRIX_SCAN_CODE(row, col,
> - keypad_data->row_shift);
> - input_event(input_dev, EV_MSC, MSC_SCAN, code);
> - input_report_key(input_dev,
> - keypad_data->keymap[code],
> - key_state[row] & (1 << col));
> - }
> - }
> - }
> + u32 low, high;
> + u64 keys, changed;
> +
> + low = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> + high = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
> + keys = low | (u64)high << 32;
> +
> + changed = keys ^ keypad_data->keys;
> +
> + /*
> + * Report key up events separately and first. This matters in case we
> + * lost key-up interrupt and just now catching up.
> + */
> + omap4_keypad_report_keys(keypad_data, changed & ~keys, false);
>
> - input_sync(input_dev);
> + /*
Re: [PATCH 3/5] Input: omap4-keypad - move rest of key scanning to a separate function
* Dmitry Torokhov [210111 04:50]:
> On Sun, Jan 10, 2021 at 09:05:27PM +0200, Tony Lindgren wrote:
> > Let's move rest of the key scanning code to omap4_keypad_scan_keys().
> > We will use omap4_keypad_scan_keys() also for implementing errata
> > handling to clear the stuck last key in the following patch.
>
> And this one will become then...
Yes great, this works for me.
Thanks,
Tony
>
> Input: omap4-keypad - move rest of key scanning to a separate function
>
> From: Tony Lindgren
>
> Let's move rest of the key scanning code to omap4_keypad_scan_keys().
> We will use omap4_keypad_scan_keys() also for implementing errata
> handling to clear the stuck last key in the following patch.
>
> Signed-off-by: Tony Lindgren
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/keyboard/omap4-keypad.c | 39
> ++---
> 1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/input/keyboard/omap4-keypad.c
> b/drivers/input/keyboard/omap4-keypad.c
> index 6dcf27af856d..c48705dd049b 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -71,6 +71,7 @@ struct omap4_keypad {
>
> void __iomem *base;
> unsigned int irq;
> + struct mutex lock; /* for key scan */
>
> unsigned int rows;
> unsigned int cols;
> @@ -135,6 +136,28 @@ static int omap4_keypad_report_keys(struct omap4_keypad
> *keypad_data,
> return events;
> }
>
> +static void omap4_keypad_scan_keys(struct omap4_keypad *keypad_data, u64
> keys)
> +{
> + u64 changed;
> +
> + mutex_lock(_data->lock);
> +
> + changed = keys ^ keypad_data->keys;
> +
> + /*
> + * Report key up events separately and first. This matters in case we
> + * lost key-up interrupt and just now catching up.
> + */
> + omap4_keypad_report_keys(keypad_data, changed & ~keys, false);
> +
> + /* Report key down events */
> + omap4_keypad_report_keys(keypad_data, changed & keys, true);
> +
> + keypad_data->keys = keys;
> +
> + mutex_unlock(_data->lock);
> +}
> +
> /* Interrupt handlers */
> static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
> {
> @@ -150,24 +173,13 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq,
> void *dev_id)
> {
> struct omap4_keypad *keypad_data = dev_id;
> u32 low, high;
> - u64 keys, changed;
> + u64 keys;
>
> low = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> high = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
> keys = low | (u64)high << 32;
>
> - changed = keys ^ keypad_data->keys;
> -
> - /*
> - * Report key up events separately and first. This matters in case we
> - * lost key-up interrupt and just now catching up.
> - */
> - omap4_keypad_report_keys(keypad_data, changed & ~keys, false);
> -
> - /* Report key down events */
> - omap4_keypad_report_keys(keypad_data, changed & keys, true);
> -
> - keypad_data->keys = keys;
> + omap4_keypad_scan_keys(keypad_data, keys);
>
> /* clear pending interrupts */
> kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
> @@ -300,6 +312,7 @@ static int omap4_keypad_probe(struct platform_device
> *pdev)
> }
>
> keypad_data->irq = irq;
> + mutex_init(_data->lock);
>
> error = omap4_keypad_parse_dt(dev, keypad_data);
> if (error)
Re: [PATCH] scsi: ufs: should not override buffer lengh
Hi Jaegeuk,
I think the problem is that func ufshcd_read_desc_param() is not
expecting
one access unsupported descriptors on all W-LUs, not just RPMB LU.
If we can get the right buf_len from func
ufshcd_map_desc_id_to_length(),
the issue won't happen. -
https://lore.kernel.org/patchwork/patch/1323421/.
What do you think if we update ufshcd_map_desc_id_to_length(add one
param - desc_index)
so that it can tell the correct buf_len in case of W-LUs?
Thanks,
Can Guo.
On 2021-01-11 12:44, Jaegeuk Kim wrote:
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units
from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, _buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2a715f13fe1d..722697b5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3293,8 +3293,12 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
- if (param_offset + param_size > buff_len)
- param_size = buff_len - param_offset;
+ if (param_offset + param_size > buff_len) {
+ if (buff_len > param_offset)
+ param_size = buff_len - param_offset;
+ else
+ param_size = 0;
+ }
memcpy(param_read_buf, _buf[param_offset], param_size);
}
out:
[PATCH net-next 0/2] dsa: add MT7530 GPIO support
MT7530's LED controller can be used as GPIO controller. Add support for it. DENG Qingfang (2): dt-bindings: net: dsa: add MT7530 GPIO controller binding drivers: net: dsa: mt7530: MT7530 optional GPIO support .../devicetree/bindings/net/dsa/mt7530.txt| 6 ++ drivers/net/dsa/mt7530.c | 96 +++ drivers/net/dsa/mt7530.h | 20 3 files changed, 122 insertions(+) -- 2.25.1
[PATCH net-next 2/2] drivers: net: dsa: mt7530: MT7530 optional GPIO support
MT7530's LED controller can drive up to 15 LED/GPIOs.
Add support for GPIO control and allow users to use its GPIOs by
setting gpio-controller property in device tree.
Signed-off-by: DENG Qingfang
---
drivers/net/dsa/mt7530.c | 96
drivers/net/dsa/mt7530.h | 20 +
2 files changed, 116 insertions(+)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index a67cac15a724..0686d8cbd086 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include "mt7530.h"
@@ -1639,6 +1640,95 @@ mtk_get_tag_protocol(struct dsa_switch *ds, int port,
}
}
+static u32
+mt7530_gpio_to_bit(unsigned int offset)
+{
+ return BIT(offset + offset / 3);
+}
+
+static int
+mt7530_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct mt7530_priv *priv = gpiochip_get_data(gc);
+ u32 bit = mt7530_gpio_to_bit(offset);
+
+ return !!(mt7530_read(priv, MT7530_LED_GPIO_DATA) & bit);
+}
+
+static void
+mt7530_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
+{
+ struct mt7530_priv *priv = gpiochip_get_data(gc);
+ u32 bit = mt7530_gpio_to_bit(offset);
+
+ if (value)
+ mt7530_set(priv, MT7530_LED_GPIO_DATA, bit);
+ else
+ mt7530_clear(priv, MT7530_LED_GPIO_DATA, bit);
+}
+
+static int
+mt7530_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct mt7530_priv *priv = gpiochip_get_data(gc);
+ u32 bit = mt7530_gpio_to_bit(offset);
+
+ return (mt7530_read(priv, MT7530_LED_GPIO_DIR) & bit) ?
+ GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
+}
+
+static int
+mt7530_gpio_direction_input(struct gpio_chip *gc, unsigned int offset)
+{
+ struct mt7530_priv *priv = gpiochip_get_data(gc);
+ u32 bit = mt7530_gpio_to_bit(offset);
+
+ mt7530_clear(priv, MT7530_LED_GPIO_DIR, bit);
+ mt7530_clear(priv, MT7530_LED_GPIO_OE, bit);
+
+ return 0;
+}
+
+static int
+mt7530_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int
value)
+{
+ struct mt7530_priv *priv = gpiochip_get_data(gc);
+ u32 bit = mt7530_gpio_to_bit(offset);
+
+ mt7530_set(priv, MT7530_LED_GPIO_DIR, bit);
+ mt7530_set(priv, MT7530_LED_GPIO_OE, bit);
+ mt7530_gpio_set(gc, offset, value);
+
+ return 0;
+}
+
+static int
+mt7530_setup_gpio(struct mt7530_priv *priv)
+{
+ struct device *dev = priv->dev;
+ struct gpio_chip *gc;
+
+ gc = devm_kzalloc(dev, sizeof(*gc), GFP_KERNEL);
+ if (!gc)
+ return -ENOMEM;
+
+ mt7530_write(priv, MT7530_LED_IO_MODE, 0);
+
+ gc->label = "mt7530";
+ gc->parent = dev;
+ gc->owner = THIS_MODULE;
+ gc->get_direction = mt7530_gpio_get_direction;
+ gc->direction_input = mt7530_gpio_direction_input;
+ gc->direction_output = mt7530_gpio_direction_output;
+ gc->get = mt7530_gpio_get;
+ gc->set = mt7530_gpio_set;
+ gc->base = -1;
+ gc->ngpio = 15;
+ gc->can_sleep = true;
+
+ return devm_gpiochip_add_data(dev, gc, priv);
+}
+
static int
mt7530_setup(struct dsa_switch *ds)
{
@@ -1781,6 +1871,12 @@ mt7530_setup(struct dsa_switch *ds)
}
}
+ if (of_property_read_bool(priv->dev->of_node, "gpio-controller")) {
+ ret = mt7530_setup_gpio(priv);
+ if (ret)
+ return ret;
+ }
+
mt7530_setup_port5(ds, interface);
/* Flush the FDB table */
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 32d8969b3ace..e7903ecc6a7c 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -554,6 +554,26 @@ enum mt7531_clk_skew {
#define MT7531_GPIO12_RG_RXD3_MASKGENMASK(19, 16)
#define MT7531_EXT_P_MDIO_12 (2 << 16)
+/* Registers for LED GPIO control (MT7530 only)
+ * All registers follow this pattern:
+ * [2:0]port 0
+ * [6:4]port 1
+ * [10:8] port 2
+ * [14:12] port 3
+ * [18:16] port 4
+ */
+
+/* LED enable, 0: Disable, 1: Enable (Default) */
+#define MT7530_LED_EN 0x7d00
+/* LED mode, 0: GPIO mode, 1: PHY mode (Default) */
+#define MT7530_LED_IO_MODE 0x7d04
+/* GPIO direction, 0: Input, 1: Output */
+#define MT7530_LED_GPIO_DIR0x7d10
+/* GPIO output enable, 0: Disable, 1: Enable */
+#define MT7530_LED_GPIO_OE 0x7d14
+/* GPIO value, 0: Low, 1: High */
+#define MT7530_LED_GPIO_DATA 0x7d18
+
#define MT7530_CREV0x7ffc
#define CHIP_NAME_SHIFT 16
#define MT7530_ID 0x7530
--
2.25.1
[PATCH net-next 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding
Add device tree binding to support MT7530 GPIO controller. Signed-off-by: DENG Qingfang --- Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index 560369efad6c..de04626a8e9d 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -76,6 +76,12 @@ phy-mode must be set, see also example 2 below! * mt7621: phy-mode = "rgmii-txid"; * mt7623: phy-mode = "rgmii"; +Optional properties: + +- gpio-controller: Boolean; if defined, MT7530's LED controller will run on + GPIO mode. +- #gpio-cells: Must be 2 if gpio-controller is defined. + See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must be specified. -- 2.25.1
[PATCH v3 1/4] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO
On at least one laptop (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. The GPIO related
information should be mapped to the rt5645 driver to enable the jack
detection also on non-DT platforms.
Signed-off-by: Chris Chiu
---
v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
v1 -> v2:
- none
sound/soc/codecs/rt5645.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 420003d062c7..af8f95644f11 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -42,6 +42,8 @@ static unsigned int quirk = -1;
module_param(quirk, uint, 0444);
MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
+static const struct acpi_gpio_mapping *cht_rt5645_gpios;
+
#define RT5645_DEVICE_ID 0x6308
#define RT5650_DEVICE_ID 0x6419
@@ -3848,6 +3850,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
}
+ if (cht_rt5645_gpios && has_acpi_companion(>dev))
+ if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+ dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->gpiod_hp_det = devm_gpiod_get_optional(>dev, "hp-detect",
GPIOD_IN);
--
2.20.1
[PATCH v3 3/4] ASoC: rt5645: add inv_hp_det flag
The ECS EF20EA laptop use gpio for jack detection instead of rt5645
rt5645 JD. However, the GPIO polarity is inverse for hp-detect based
on the _DSD property of the RTK2 device.
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"hp-detect-gpio", Package() {^RTK2, 0, 0, 1 }},
}
})
This flag will invert the hp-detect gpio polarity.
Signed-off-by: Chris Chiu
---
v2 -> v3:
- none
v1 -> v2:
- none
include/sound/rt5645.h| 2 ++
sound/soc/codecs/rt5645.c | 4
2 files changed, 6 insertions(+)
diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h
index 39a77c7cea36..710c95be5509 100644
--- a/include/sound/rt5645.h
+++ b/include/sound/rt5645.h
@@ -22,6 +22,8 @@ struct rt5645_platform_data {
bool level_trigger_irq;
/* Invert JD1_1 status polarity */
bool inv_jd1_1;
+ /* Invert HP detect status polarity */
+ bool inv_hp_pol;
/* Value to asign to snd_soc_card.long_name */
const char *long_name;
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 770801de42a6..4fd91ee3cfaa 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -34,6 +34,7 @@
#define QUIRK_INV_JD1_1(q) ((q) & 1)
#define QUIRK_LEVEL_IRQ(q) (((q) >> 1) & 1)
#define QUIRK_IN2_DIFF(q) (((q) >> 2) & 1)
+#define QUIRK_INV_HP_POL(q)(((q) >> 3) & 1)
#define QUIRK_JD_MODE(q) (((q) >> 4) & 7)
#define QUIRK_DMIC1_DATA_PIN(q)(((q) >> 8) & 3)
#define QUIRK_DMIC2_DATA_PIN(q)(((q) >> 12) & 3)
@@ -3263,6 +3264,8 @@ static void rt5645_jack_detect_work(struct work_struct
*work)
case 0: /* Not using rt5645 JD */
if (rt5645->gpiod_hp_det) {
gpio_state = gpiod_get_value(rt5645->gpiod_hp_det);
+ if (rt5645->pdata.inv_hp_pol)
+ gpio_state ^= 1;
dev_dbg(rt5645->component->dev, "gpio_state = %d\n",
gpio_state);
report = rt5645_jack_detect(rt5645->component,
gpio_state);
@@ -3872,6 +3875,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.in2_diff = QUIRK_IN2_DIFF(quirk);
rt5645->pdata.level_trigger_irq = QUIRK_LEVEL_IRQ(quirk);
rt5645->pdata.inv_jd1_1 = QUIRK_INV_JD1_1(quirk);
+ rt5645->pdata.inv_hp_pol = QUIRK_INV_HP_POL(quirk);
rt5645->pdata.jd_mode = QUIRK_JD_MODE(quirk);
rt5645->pdata.dmic1_data_pin = QUIRK_DMIC1_DATA_PIN(quirk);
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
--
2.20.1
[PATCH v3 2/4] ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series
Add the hp-detect gpio for ECS EF20 series laptops based on the
_CRS defined in DSDT table.
Method (_CRS, 0, NotSerialized)
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004F
}
})
Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}
Signed-off-by: Chris Chiu
---
v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
v1 -> v2:
- Invoke callback() of the DMI quirk if it exists.
sound/soc/codecs/rt5645.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index af8f95644f11..770801de42a6 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3653,6 +3653,19 @@ static const struct rt5645_platform_data
kahlee_platform_data = {
.jd_mode = 3,
};
+static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
+ { "hp-detect-gpios", _hp_detect, 1 },
+ { },
+};
+
+static int cht_rt5645_ef20_quirk_cb(const struct dmi_system_id *id)
+{
+ cht_rt5645_gpios = cht_rt5645_ef20_gpios;
+ return 1;
+}
+
static const struct dmi_system_id dmi_platform_data[] = {
{
.ident = "Chrome Buddy",
@@ -3782,6 +3795,20 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
+ {
+ .ident = "EF20",
+ .callback = cht_rt5645_ef20_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
+ },
+ },
+ {
+ .ident = "EF20EA",
+ .callback = cht_rt5645_ef20_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+ },
+ },
{ }
};
--
2.20.1
[PATCH v3 4/4] ASoC: rt5645: Enable internal microphone and JD on ECS EF20
On ECS EF20 series laptops, the internal mic is on DMIC2/IN2P.
And they need the inv_hp_det to make jack detection to work as
exoected.
Signed-off-by: Chris Chiu
---
v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
v1 -> v2:
- none
sound/soc/codecs/rt5645.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 4fd91ee3cfaa..3c082c4ac3fc 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3656,6 +3656,12 @@ static const struct rt5645_platform_data
kahlee_platform_data = {
.jd_mode = 3,
};
+static const struct rt5645_platform_data ecs_ef20_platform_data = {
+ .dmic1_data_pin = RT5645_DMIC1_DISABLE,
+ .dmic2_data_pin = RT5645_DMIC_DATA_IN2P,
+ .inv_hp_pol = 1,
+};
+
static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
@@ -3804,6 +3810,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
},
+ .driver_data = (void *)_ef20_platform_data,
},
{
.ident = "EF20EA",
@@ -3811,6 +3818,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
},
+ .driver_data = (void *)_ef20_platform_data,
},
{ }
};
--
2.20.1
[PATCH v3 0/4] ASoC: rt5645: Enable internal mic and headset on ECS EF20
These patches are trying to fix the jack detection and internal microphone problems on ECS EF20 series laptops which are empowered by Intel Atom x5-Z8350 CPU (CherryTrail) with Realtek rt5645 audio codec. --- v2 -> v3: Restore the accidentally removed terminator of the dmi_platform_data[]. v1 -> v2: Invoke callback() of the DMI quirk if it exists, because the dmi_first_match() doesn't. --- Chris Chiu (4): ASoC: rt5645: Introduce mapping for ACPI-defined GPIO ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series ASoC: rt5645: add inv_hp_det flag ASoC: rt5645: Enable internal microphone and JD on ECS EF20 include/sound/rt5645.h| 2 ++ sound/soc/codecs/rt5645.c | 45 +++ 2 files changed, 47 insertions(+) -- 2.20.1
Re: [PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices
Jiri Kosina 於 2021年1月7日 週四 下午5:23寫道： > > On Wed, 23 Dec 2020, Jian-Hong Pan wrote: > > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > > > This patch maps the event as KEY_RFKILL. > > I don't know how exactly does the report descriptor of that device look > like, but is this not doable from userspace via setkeycode() (udev/systemd > is shipping a lot of such mappings already -- see evdev/keyboard > definitions in hwdb). Thanks for your suggestion! I have tested the key with evtest. But it has no response from all inputs. Nor response from xev. So, I tried usb monitor to see what does it send: $ lsusb -d 04f2:1236 Bus 001 Device 002: ID 04f2:1236 Chicony Electronics Co., Ltd $ sudo modprobe usbmon $ sudo cat /sys/kernel/debug/usb/usbmon/1u 9145e0dea6c0 348311963 C Ii:1:002:1 0:8 8 = 9145e0dea6c0 348311996 S Ii:1:002:1 -115:8 8 < 9145e0deaf00 352852533 C Ii:1:002:2 0:4 2 = 1101 9145e0deaf00 352852547 S Ii:1:002:2 -115:4 3 < It sends 0x1101 for the hotkey. The same response from hid events: $ sudo cat /sys/kernel/debug/hid/0003\:04F2\:1236.0002/events report (size 2) (numbered) = 11 01 Then, I notice there is the RFKILL event listed on the "Chicony USB Receiver Wireless Radio Control" device: $ sudo evtest /dev/input/event8 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x4f2 product 0x1236 version 0x111 Input device name: "Chicony USB Receiver Wireless Radio Control" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 103 (KEY_UP) Event code 105 (KEY_LEFT) Event code 106 (KEY_RIGHT) Event code 108 (KEY_DOWN) Event code 116 (KEY_POWER) Event code 138 (KEY_HELP) Event code 139 (KEY_MENU) Event code 142 (KEY_SLEEP) Event code 143 (KEY_WAKEUP) Event code 148 (KEY_PROG1) Event code 174 (KEY_EXIT) Event code 227 (KEY_SWITCHVIDEOMODE) Event code 247 (KEY_RFKILL) Event code 314 (BTN_SELECT) Event code 315 (BTN_START) Event code 353 (KEY_SELECT) Event code 356 (KEY_POWER2) Event code 408 (KEY_RESTART) Event code 438 (KEY_CONTEXT_MENU) Event type 2 (EV_REL) Event code 9 (REL_MISC) Event type 3 (EV_ABS) ... Also, after debugging, I found its HID application ID is HID_GD_WIRELESS_RADIO_CTLS 0x0001000c [1]. Then, I searched HID_GD_WIRELESS_RADIO_CTLS in the kernel. I found HID_GD_RFKILL_BTN [2] is mapped in hid-input. However, this key press on the Chicony keyboard maps to nothing, nor HID_GD_RFKILL_BTN. Only have the HID report with raw data 0x11 0x00 as mentioned above. It is more like ignored by the kernel and it even has no scancode. That's why I try to map it as KEY_RFKILL in the driver. [1] https://elixir.bootlin.com/linux/v5.10/source/include/linux/hid.h#L181 [2] https://elixir.bootlin.com/linux/v5.10/source/drivers/hid/hid-input.c#L743 Regards, Jian-Hong Pan
Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
On 11/01/2021 05:23, Chaitanya Kulkarni wrote:
> On 1/10/21 18:32, Pavel Begunkov wrote:
>> On 11/01/2021 02:06, Chaitanya Kulkarni wrote:
>>> On 1/9/21 13:29, Pavel Begunkov wrote:
On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
> On 1/9/21 12:40, Pavel Begunkov wrote:
>> I expect you won't find any, but such little things can pile up
>> into a not-easy-to-spot overhead over time.
> That is what I suspected with the resulting assembly. The commit log
> needs to document that there is no direct impact on the performance
It's obvious that 3-4 extra mov $0 off(%reg) won't change performance
but still hasn't been formally confirmed ...
>>> This is obvious for you and me since we spent time into looking into
>>> resulting assembly not every reviewer is expected to do that see [1].
> which can be seen with this patch, but this is nice to have
... so if you don't mind, I won't be resending just for that.
>>> As per commit log guidelines [1] you have to quantify the optimization.
>>>
>>> Since you cannot quantify the optimization modify the commit log explaining
>> And then you see "Optimizations usually aren’t free but trade-offs
>> between", and the patch doesn't fall under it.
> First part applies to all the optimizations with and without tradeoffs
> "Quantify optimizations and trade-offs."
> The later part doesn't mean optimizations without trade-offs should be
> allowed without having any supportive data.
>>
>> Let me be frank, I see it more like as a whim. If the maintainer agrees
>> with that strange requirement of yours and want to bury it under
>> bureaucracy, fine by me, don't take it, I don't care, but I haven't
>> ever been asked here to do that for patches as this.
> I didn't write the commit log guidelines, as a reviewer I'm following them.
> The patch commit log claims optimization with neither having any data nor
> having the supporting fact ("possibly no observable difference but in the
> long term it matters") for the completeness.
>> It's not "I cannot" but rather "I haven't even tried to and expect...".
>> Don't mix, there is a huge difference between.
> Then provide the numbers to support your claim.
What claim? I didn't make any regarding performance, you may want to
re-read the commit message.
Anyway, I'll halt replying to this topic. Nothing personal, but it's
getting annoying.
--
Pavel Begunkov
Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
On 1/10/21 18:32, Pavel Begunkov wrote:
> On 11/01/2021 02:06, Chaitanya Kulkarni wrote:
>> On 1/9/21 13:29, Pavel Begunkov wrote:
>>> On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
On 1/9/21 12:40, Pavel Begunkov wrote:
> I expect you won't find any, but such little things can pile up
> into a not-easy-to-spot overhead over time.
That is what I suspected with the resulting assembly. The commit log
needs to document that there is no direct impact on the performance
>>> It's obvious that 3-4 extra mov $0 off(%reg) won't change performance
>>> but still hasn't been formally confirmed ...
>> This is obvious for you and me since we spent time into looking into
>> resulting assembly not every reviewer is expected to do that see [1].
which can be seen with this patch, but this is nice to have
>>> ... so if you don't mind, I won't be resending just for that.
>> As per commit log guidelines [1] you have to quantify the optimization.
>>
>> Since you cannot quantify the optimization modify the commit log explaining
> And then you see "Optimizations usually aren’t free but trade-offs
> between", and the patch doesn't fall under it.
First part applies to all the optimizations with and without tradeoffs
"Quantify optimizations and trade-offs."
The later part doesn't mean optimizations without trade-offs should be
allowed without having any supportive data.
>
> Let me be frank, I see it more like as a whim. If the maintainer agrees
> with that strange requirement of yours and want to bury it under
> bureaucracy, fine by me, don't take it, I don't care, but I haven't
> ever been asked here to do that for patches as this.
I didn't write the commit log guidelines, as a reviewer I'm following them.
The patch commit log claims optimization with neither having any data nor
having the supporting fact ("possibly no observable difference but in the
long term it matters") for the completeness.
> It's not "I cannot" but rather "I haven't even tried to and expect...".
> Don't mix, there is a huge difference between.
Then provide the numbers to support your claim.
Re: [PATCH mips-fixes] MIPS: relocatable: fix possible boot hangup with KASLR enabled
On Sun, Jan 10, 2021 at 02:21:05PM +, Alexander Lobakin wrote:
> LLVM-built Linux triggered a boot hangup with KASLR enabled.
>
> arch/mips/kernel/relocate.c:get_random_boot() uses linux_banner,
> which is a string constant, as a random seed, but accesses it
> as an array of unsigned long (in rotate_xor()).
> When the address of linux_banner is not aligned to sizeof(long),
> such access emits unaligned access exception and hangs the kernel.
>
> Use PTR_ALIGN() to align input address to sizeof(long) and also
> align down the input length to prevent possible access-beyond-end.
>
> Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
> Cc: sta...@vger.kernel.org # 4.7+
> Signed-off-by: Alexander Lobakin
Apologies for not being familiar enough with the issue to give a review
but I did reproduce the hang that the commit mentions with
malta_kvm_guest_defconfig + CONFIG_RELOCATABLE=y +
CONFIG_RANDOMIZE_BASE=y and this patch does resolve it so:
Tested-by: Nathan Chancellor
> ---
> arch/mips/kernel/relocate.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
> index 47aeb3350a76..0e365b7c742d 100644
> --- a/arch/mips/kernel/relocate.c
> +++ b/arch/mips/kernel/relocate.c
> @@ -187,8 +187,14 @@ static int __init relocate_exception_table(long offset)
> static inline __init unsigned long rotate_xor(unsigned long hash,
> const void *area, size_t size)
> {
> - size_t i;
> - unsigned long *ptr = (unsigned long *)area;
> + const typeof(hash) *ptr = PTR_ALIGN(area, sizeof(hash));
> + size_t diff, i;
> +
> + diff = (void *)ptr - area;
> + if (unlikely(size < diff + sizeof(hash)))
> + return hash;
> +
> + size = ALIGN_DOWN(size - diff, sizeof(hash));
>
> for (i = 0; i < size / sizeof(hash); i++) {
> /* Rotate by odd number of bits and XOR. */
> --
> 2.30.0
>
>
Re: INFO: trying to register non-static key in l2cap_sock_teardown_cb
syzbot has bisected this issue to:
commit 4680a7ee5db27772af40d83393fa0fb955b745b7
Author: Miklos Szeredi
Date: Sat Oct 1 05:32:33 2016 +
fuse: remove duplicate cs->offset assignment
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11fc80e750
start commit: 73b7a604 net: dsa: bcm_sf2: support BCM4908's integrated s..
git tree: net-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=13fc80e750
console output: https://syzkaller.appspot.com/x/log.txt?x=15fc80e750
kernel config: https://syzkaller.appspot.com/x/.config?x=9ce34124da4c882b
dashboard link: https://syzkaller.appspot.com/bug?extid=a41dfef1d2e04910eb2e
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=166ee4cf50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1337172f50
Reported-by: syzbot+a41dfef1d2e04910e...@syzkaller.appspotmail.com
Fixes: 4680a7ee5db2 ("fuse: remove duplicate cs->offset assignment")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH 1/2] f2fs: introduce checkpoint=merge mount option
From: Daeho Jeong
We've added a new mount option "checkpoint=merge", which creates a
kernel daemon and makes it to merge concurrent checkpoint requests as
much as possible to eliminate redundant checkpoint issues. Plus, we
can eliminate the sluggish issue caused by slow checkpoint operation
when the checkpoint is done in a process context in a cgroup having
low i/o budget and cpu shares, and The below verification result
explains this.
The basic idea has come from https://opensource.samsung.com.
[Verification]
Android Pixel Device(ARM64, 7GB RAM, 256GB UFS)
Create two I/O cgroups (fg w/ weight 100, bg w/ wight 20)
In "fg" cgroup,
- thread A => trigger 1000 checkpoint operations
"for i in `seq 1 1000`; do touch test_dir1/file; fsync test_dir1;
done"
- thread B => gererating async. I/O
"fio --rw=write --numjobs=1 --bs=128k --runtime=3600 --time_based=1
--filename=test_img --name=test"
In "bg" cgroup,
- thread C => trigger repeated checkpoint operations
"echo $$ > /dev/blkio/bg/tasks; while true; do touch test_dir2/file;
fsync test_dir2; done"
We've measured thread A's execution time.
[ w/o patch ]
Elapsed Time: Avg. 68 seconds
[ w/ patch ]
Elapsed Time: Avg. 48 seconds
Signed-off-by: Daeho Jeong
Signed-off-by: Sungjong Seo
---
Documentation/filesystems/f2fs.rst | 6 +
fs/f2fs/checkpoint.c | 176 +
fs/f2fs/debug.c| 6 +
fs/f2fs/f2fs.h | 24
fs/f2fs/super.c| 53 -
5 files changed, 261 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..bccc021bf31a 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -247,6 +247,12 @@ checkpoint=%s[:%u[%]] Set to "disable" to turn off
checkpointing. Set to "enabl
hide up to all remaining free space. The actual space
that
would be unusable can be viewed at
/sys/fs/f2fs//unusable
This space is reclaimed once checkpoint=enable.
+Here is another option "merge", which creates a kernel
daemon
+and makes it to merge concurrent checkpoint requests
as much
+as possible to eliminate redundant checkpoint issues.
Plus,
+we can eliminate the sluggish issue caused by slow
checkpoint
+operation when the checkpoint is done in a process
context in
+a cgroup having low i/o budget and cpu shares.
compress_algorithm=%s Control compress algorithm, currently f2fs supports
"lzo",
"lz4", "zstd" and "lzo-rle" algorithm.
compress_log_size=%uSupport configuring compress cluster size, the size
will
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 897edb7c951a..11288f435dbe 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "node.h"
@@ -20,6 +21,8 @@
#include "trace.h"
#include
+#define DEFAULT_CHECKPOINT_IOPRIO (IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 3))
+
static struct kmem_cache *ino_entry_slab;
struct kmem_cache *f2fs_inode_entry_slab;
@@ -1707,3 +1710,176 @@ void f2fs_destroy_checkpoint_caches(void)
kmem_cache_destroy(ino_entry_slab);
kmem_cache_destroy(f2fs_inode_entry_slab);
}
+
+static int __write_checkpoint_sync(struct f2fs_sb_info *sbi)
+{
+ struct cp_control cpc = { .reason = CP_SYNC, };
+ int err;
+
+ down_write(>gc_lock);
+ err = f2fs_write_checkpoint(sbi, );
+ up_write(>gc_lock);
+
+ return err;
+}
+
+static void __checkpoint_and_complete_reqs(struct f2fs_sb_info *sbi)
+{
+ struct ckpt_req_control *cprc = sbi->cprc_info;
+ struct ckpt_req *req, *next;
+ struct llist_node *dispatch_list;
+ int ret;
+
+ dispatch_list = llist_del_all(>issue_list);
+ if (!dispatch_list)
+ return;
+ dispatch_list = llist_reverse_order(dispatch_list);
+
+ ret = __write_checkpoint_sync(sbi);
+ atomic_inc(>issued_ckpt);
+
+ llist_for_each_entry_safe(req, next, dispatch_list, llnode) {
+ atomic_dec(>queued_ckpt);
+ atomic_inc(>total_ckpt);
+ req->complete_time = jiffies;
+ req->ret = ret;
+ complete(>wait);
+ }
+}
+
+static int issue_checkpoint_thread(void *data)
+{
+ struct f2fs_sb_info *sbi = data;
+ struct ckpt_req_control *cprc = sbi->cprc_info;
+ wait_queue_head_t *q = >ckpt_wait_queue;
+repeat:
+ if (kthread_should_stop())
+ return 0;
+
+ sb_start_intwrite(sbi->sb);
+
+ if (!llist_empty(>issue_list))
+ __checkpoint_and_complete_reqs(sbi);
+
+ sb_end_intwrite(sbi->sb);
+
+
[PATCH 2/2] f2fs: add ckpt_thread_ioprio sysfs node
From: Daeho Jeong
Added "ckpt_thread_ioprio" sysfs node to give a way to change checkpoint
merge daemon's io priority. Its default value is "be,3", which means
"BE" I/O class and I/O priority "3". We can select the class between "rt"
and "be", and set the I/O priority within valid range of it.
"," delimiter is necessary in between I/O class and priority number.
Signed-off-by: Daeho Jeong
---
Documentation/ABI/testing/sysfs-fs-f2fs | 8
fs/f2fs/checkpoint.c| 3 +-
fs/f2fs/f2fs.h | 1 +
fs/f2fs/sysfs.c | 51 +
4 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 3dfee94e0618..0c48b2e7dfd4 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -377,3 +377,11 @@ 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//ckpt_thread_ioprio
+Date: January 2021
+Contact: "Daeho Jeong"
+Description: Give a way to change checkpoint merge daemon's io priority.
+ Its default value is "be,3", which means "BE" I/O class and
+ I/O priority "3". We can select the class between "rt" and "be",
+ and set the I/O priority within valid range of it. "," delimiter
+ is necessary in between I/O class and priority number.
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 11288f435dbe..37a393f97d5d 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1839,6 +1839,7 @@ int f2fs_create_ckpt_req_control(struct f2fs_sb_info *sbi)
atomic_set(>issued_ckpt, 0);
atomic_set(>total_ckpt, 0);
atomic_set(>queued_ckpt, 0);
+ cprc->ckpt_thread_ioprio = DEFAULT_CHECKPOINT_IOPRIO;
init_waitqueue_head(>ckpt_wait_queue);
init_llist_head(>issue_list);
sbi->cprc_info = cprc;
@@ -1859,7 +1860,7 @@ int f2fs_create_ckpt_req_control(struct f2fs_sb_info *sbi)
return err;
}
- set_task_ioprio(cprc->f2fs_issue_ckpt, DEFAULT_CHECKPOINT_IOPRIO);
+ set_task_ioprio(cprc->f2fs_issue_ckpt, cprc->ckpt_thread_ioprio);
return 0;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 4de5285df17d..957bf4c42d40 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -278,6 +278,7 @@ struct ckpt_req {
struct ckpt_req_control {
struct task_struct *f2fs_issue_ckpt;/* checkpoint task */
+ int ckpt_thread_ioprio; /* checkpoint merge thread
ioprio */
wait_queue_head_t ckpt_wait_queue; /* waiting queue for wake-up */
atomic_t issued_ckpt; /* # of actually issued ckpts */
atomic_t total_ckpt;/* # of total ckpts */
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 30bae57428d1..295ebd84986b 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "segment.h"
@@ -34,6 +35,7 @@ enum {
FAULT_INFO_TYPE,/* struct f2fs_fault_info */
#endif
RESERVED_BLOCKS,/* struct f2fs_sb_info */
+ CPRC_INFO, /* struct ckpt_req_control */
};
struct f2fs_attr {
@@ -70,6 +72,8 @@ static unsigned char *__struct_ptr(struct f2fs_sb_info *sbi,
int struct_type)
else if (struct_type == STAT_INFO)
return (unsigned char *)F2FS_STAT(sbi);
#endif
+ else if (struct_type == CPRC_INFO)
+ return (unsigned char *)sbi->cprc_info;
return NULL;
}
@@ -255,6 +259,23 @@ static ssize_t f2fs_sbi_show(struct f2fs_attr *a,
return len;
}
+ if (!strcmp(a->attr.name, "ckpt_thread_ioprio")) {
+ struct ckpt_req_control *cprc = sbi->cprc_info;
+ int len = 0;
+ int class = IOPRIO_PRIO_CLASS(cprc->ckpt_thread_ioprio);
+ int data = IOPRIO_PRIO_DATA(cprc->ckpt_thread_ioprio);
+
+ if (class == IOPRIO_CLASS_RT)
+ len += scnprintf(buf + len, PAGE_SIZE - len, "rt,");
+ else if (class == IOPRIO_CLASS_BE)
+ len += scnprintf(buf + len, PAGE_SIZE - len, "be,");
+ else
+ return -EINVAL;
+
+ len += scnprintf(buf + len, PAGE_SIZE - len, "%d\n", data);
+ return len;
+ }
+
ui = (unsigned int *)(ptr + a->offset);
return sprintf(buf, "%u\n", *ui);
@@ -308,6 +329,34 @@ static ssize_t __sbi_store(struct f2fs_attr *a,
return ret ? ret : count;
}
+ if (!strcmp(a->attr.name, "ckpt_thread_ioprio")) {
+
Re: [PATCH] block/rnbd-clt: improve find_or_create_sess() return check
On Sun, Jan 10, 2021 at 01:57:26PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis reports this problem
>
> rnbd-clt.c:1212:11: warning: Branch condition evaluates to a
> garbage value
> else if (!first)
> ^~
Ah, is it complaining that the 'if (IS_ERR(sess)) {' section in
find_or_create_sess() does not initialize first even though that will be
caught by the 'if (sess == ERR_PTR(-ENOMEM))' in
find_and_get_or_create_sess() because alloc_sess() only returns an
-ENOMEM error pointer?
> This is triggered in the find_and_get_or_create_sess() call
> because the variable first is not initialized and the
> earlier check is specifically for
>
> if (sess == ERR_PTR(-ENOMEM))
>
> This is false positive.
>
> But the if-check can be reduced by initializing first to
> false and then returning if the call to find_or_creat_sess()
> does not set it to true. When it remains false, either
> sess will be valid or not. The not case is caught by
> find_and_get_or_create_sess()'s caller rnbd_clt_map_device()
>
> sess = find_and_get_or_create_sess(...);
> if (IS_ERR(sess))
> return ERR_CAST(sess);
>
> Since find_and_get_or_create_sess() initializes first to false
> setting it in find_or_create_sess() is not needed.
>
> Signed-off-by: Tom Rix
Every maintainer has their preference for where and how stuff gets
initialized but this makes sense to me. I am not sure the commit above
find_or_create_sess() is needed but again, personal preference.
Reviewed-by: Nathan Chancellor
> ---
> drivers/block/rnbd/rnbd-clt.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
> index 96e3f9fe8241..251f747cf10d 100644
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@ -919,6 +919,7 @@ static struct rnbd_clt_session *__find_and_get_sess(const
> char *sessname)
> return NULL;
> }
>
> +/* caller is responsible for initializing 'first' to false */
> static struct
> rnbd_clt_session *find_or_create_sess(const char *sessname, bool *first)
> {
> @@ -934,8 +935,7 @@ rnbd_clt_session *find_or_create_sess(const char
> *sessname, bool *first)
> }
> list_add(>list, _list);
> *first = true;
> - } else
> - *first = false;
> + }
> mutex_unlock(_lock);
>
> return sess;
> @@ -1203,13 +1203,11 @@ find_and_get_or_create_sess(const char *sessname,
> struct rnbd_clt_session *sess;
> struct rtrs_attrs attrs;
> int err;
> - bool first;
> + bool first = false;
> struct rtrs_clt_ops rtrs_ops;
>
> sess = find_or_create_sess(sessname, );
> - if (sess == ERR_PTR(-ENOMEM))
> - return ERR_PTR(-ENOMEM);
> - else if (!first)
> + if (!first)
> return sess;
>
> if (!path_cnt) {
> --
> 2.27.0
>
Re: [PATCH 4/5] Input: omap4-keypad - use PM runtime autosuspend
* Dmitry Torokhov [210111 05:01]:
> Hi Tony,
>
> On Sun, Jan 10, 2021 at 09:05:28PM +0200, Tony Lindgren wrote:
> > @@ -350,15 +379,12 @@ static int omap4_keypad_probe(struct platform_device
> > *pdev)
> >
> > error = omap4_keypad_check_revision(>dev,
> > keypad_data);
> > - if (!error) {
> > - /* Ensure device does not raise interrupts */
> > - omap4_keypad_stop(keypad_data);
> > - }
> > -
> > - pm_runtime_put_sync(>dev);
>
> Why are we moving this down? The idea was to make sure the power usage
> counters are correct even if we exit probe early.
Yes you are right, omap4_keypad_close() won't help with balancing the
get if we exit early.
> Can we call pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
> here?
Yes that should work as there's no more register access during the probe.
Regards,
Tony
Re: [RFC PATCH 5/8] entry: Explicitly flush pending rcuog wakeup before last rescheduling points
On Mon, Jan 11, 2021 at 01:40:14AM +0100, Frederic Weisbecker wrote: > On Sat, Jan 09, 2021 at 03:05:33AM +0100, Frederic Weisbecker wrote: > > Following the idle loop model, cleanly check for pending rcuog wakeup > > before the last rescheduling point on resuming to user mode. This > > way we can avoid to do it from rcu_user_enter() with the last resort > > self-IPI hack that enforces rescheduling. > > > > Signed-off-by: Frederic Weisbecker > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: Paul E. McKenney > > Cc: Rafael J. Wysocki > > --- > > kernel/entry/common.c | 6 ++ > > kernel/rcu/tree.c | 12 +++- > > 2 files changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/entry/common.c b/kernel/entry/common.c > > index 378341642f94..8f3292b5f9b7 100644 > > --- a/kernel/entry/common.c > > +++ b/kernel/entry/common.c > > @@ -178,6 +178,9 @@ static unsigned long exit_to_user_mode_loop(struct > > pt_regs *regs, > > /* Architecture specific TIF work */ > > arch_exit_to_user_mode_work(regs, ti_work); > > > > + /* Check if any of the above work has queued a deferred wakeup > > */ > > + rcu_nocb_flush_deferred_wakeup(); > > So this needs to be moved to the IRQs disabled section, just a few lines > later, > otherwise preemption may schedule another task that in turn do call_rcu() and > create > new deferred wake up (thank Paul for the warning). Not to mention moving to > another CPU with its own deferred wakeups to flush... > > I'll fix that for the next version. Ah, so it was not just my laptop dying, then! ;-) Thanx, Paul
Re: [PATCH 4/5] Input: omap4-keypad - use PM runtime autosuspend
Hi Tony,
On Sun, Jan 10, 2021 at 09:05:28PM +0200, Tony Lindgren wrote:
> @@ -350,15 +379,12 @@ static int omap4_keypad_probe(struct platform_device
> *pdev)
>
> error = omap4_keypad_check_revision(>dev,
> keypad_data);
> - if (!error) {
> - /* Ensure device does not raise interrupts */
> - omap4_keypad_stop(keypad_data);
> - }
> -
> - pm_runtime_put_sync(>dev);
Why are we moving this down? The idea was to make sure the power usage
counters are correct even if we exit probe early.
Can we call pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
here?
> if (error)
> return error;
>
> + /* Ensure device does not raise interrupts */
> + omap4_keypad_stop(keypad_data);
> +
> /* input device allocation */
> keypad_data->input = input_dev = devm_input_allocate_device(dev);
> if (!input_dev)
> @@ -419,7 +445,8 @@ static int omap4_keypad_probe(struct platform_device
> *pdev)
> if (error)
> dev_warn(dev, "failed to set up wakeup irq: %d\n", error);
>
> - platform_set_drvdata(pdev, keypad_data);
> + pm_runtime_mark_last_busy(>dev);
> + pm_runtime_put_autosuspend(>dev);
>
> return 0;
> }
> --
> 2.30.0
Thanks.
--
Dmitry
Re: [PATCH] iommu/io-pgtable-arm: Allow non-coherent masters to use system cache
On 2021-01-08 23:48, Will Deacon wrote:
On Fri, Jan 08, 2021 at 11:17:25AM +0530, Sai Prakash Ranjan wrote:
On 2021-01-07 22:27, isa...@codeaurora.org wrote:
> On 2021-01-06 03:56, Will Deacon wrote:
> > On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
> > > commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY
> > > flag")
> > > removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
> > > the memory type setting required for the non-coherent masters to use
> > > system cache. Now that system cache support for GPU is added, we will
> > > need to mark the memory as normal sys-cached for GPU to use
> > > system cache.
> > > Without this, the system cache lines are not allocated for GPU.
> > > We use
> > > the IO_PGTABLE_QUIRK_ARM_OUTER_WBWA quirk instead of a page
> > > protection
> > > flag as the flag cannot be exposed via DMA api because of no in-tree
> > > users.
> > >
> > > Signed-off-by: Sai Prakash Ranjan
> > > ---
> > > drivers/iommu/io-pgtable-arm.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/iommu/io-pgtable-arm.c
> > > b/drivers/iommu/io-pgtable-arm.c
> > > index 7c9ea9d7874a..3fb7de8304a2 100644
> > > --- a/drivers/iommu/io-pgtable-arm.c
> > > +++ b/drivers/iommu/io-pgtable-arm.c
> > > @@ -415,6 +415,9 @@ static arm_lpae_iopte
> > > arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
> > > else if (prot & IOMMU_CACHE)
> > > pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
> > > << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> > > +else if (data->iop.cfg.quirks &
IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
> > > +pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE
> > > +<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
> > > }
> >
> While this approach of enabling system cache globally for both page
> tables and other buffers
> works for the GPU usecase, this isn't ideal for other clients that use
> system cache. For example,
> video clients only want to cache a subset of their buffers in the
> system cache, due to the sizing constraint
> imposed by how much of the system cache they can use. So, it would be
> ideal to have
> a way of expressing the desire to use the system cache on a per-buffer
> basis. Additionally,
> our video clients use the DMA layer, and since the requirement is for
> caching in the system cache
> to be a per buffer attribute, it seems like we would have to have a
> DMA attribute to express
> this on a per-buffer basis.
>
I did bring this up initially [1], also where is this video client
in upstream? AFAIK, only system cache user in upstream is GPU.
We cannot add any DMA attribute unless there is any user upstream
as per [2], so when the support for such a client is added, wouldn't
((data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA) ||
PROT_FLAG)
work?
Hmm, I think this is another case where we need to separate out the
page-table walker attributes from the access attributes. Currently,
IO_PGTABLE_QUIRK_ARM_OUTER_WBWA applies _only_ to the page-table walker
and I don't think it makes any sense for that to be per-buffer (how
would
you even manage that?). However, if we want to extend this to data
accesses
and we know that there are valid use-cases where this should be
per-buffer,
then shoe-horning it in with the walker quirk does not feel like the
best
thing to do.
As a starting point, we could:
1. Rename IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to IO_PGTABLE_QUIRK_PTW_LLC
2. Add a new prot flag IOMMU_LLC
3. Have the GPU pass the new prot for its buffer mappings
This looks good to me, I will work on this and post something soon.
Does that work? One thing I'm not sure about is whether IOMMU_CACHE
should
imply IOMMU_LLC, or whether there is a use-case for inner-cacheable,
outer
non-cacheable mappings for a coherent device. Have you ever seen that
sort
of thing before?
I don't think there is such a usecase as Isaac mentioned.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] USB: otg: Fix error 32 when enable hardware flow control.
When hardware flow control is enabled,
don't allow host send MHS command to cp210x.
Signed-off-by: Pho Tran
---
drivers/usb/serial/cp210x.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fbb10dfc56e3..f231cecdaf7d 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -1204,6 +1204,7 @@ static int cp210x_tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear)
{
struct usb_serial_port *port = tty->driver_data;
+
return cp210x_tiocmset_port(port, set, clear);
}
@@ -1211,6 +1212,11 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
unsigned int set, unsigned int clear)
{
u16 control = 0;
+ struct cp210x_flow_ctl flow_ctl;
+ u32 ctl_hs = 0;
+ u32 flow_repl = 0;
+ bool auto_dtr = false;
+ bool auto_rts = false;
if (set & TIOCM_RTS) {
control |= CONTROL_RTS;
@@ -1230,6 +1236,30 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
}
dev_dbg(>dev, "%s - control = 0x%.4x\n", __func__, control);
+ /*
+* Don't send MHS command if device in hardware flowcontrol mode
+*/
+ cp210x_read_reg_block(port, CP210X_GET_FLOW, _ctl,
+ sizeof(flow_ctl));
+ ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
+ flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
+
+ if (CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_FLOW_CTL)
+ == (ctl_hs & CP210X_SERIAL_DTR_MASK))
+ auto_dtr = true;
+ else
+ auto_dtr = false;
+
+ if (CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL)
+ == (flow_repl & CP210X_SERIAL_RTS_MASK))
+ auto_rts = true;
+ else
+ auto_rts = false;
+
+ if (auto_dtr || auto_rts) {
+ dev_dbg(>dev, "Don't set MHS when while device in flow
control mode\n");
+ return 0;
+ }
return cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
}
@@ -1256,7 +1286,7 @@ static int cp210x_tiocmget(struct tty_struct *tty)
|((control & CONTROL_RTS) ? TIOCM_RTS : 0)
|((control & CONTROL_CTS) ? TIOCM_CTS : 0)
|((control & CONTROL_DSR) ? TIOCM_DSR : 0)
- |((control & CONTROL_RING)? TIOCM_RI : 0)
+ |((control & CONTROL_RING) ? TIOCM_RI : 0)
|((control & CONTROL_DCD) ? TIOCM_CD : 0);
dev_dbg(>dev, "%s - control = 0x%.2x\n", __func__, control);
--
2.17.1
Re: [PATCH v4 0/5] imx8mq: updates for the interconnect fabric
On Thu, Jan 07, 2021 at 01:17:49PM +0100, Martin Kepplinger wrote: > revision history: > v4: (thanks Shawn, Georgi and Greg) > * reorder to have dt-bindings doc before code addition > * add newline between dt nodes > * removed "interconnect: imx8mq: Use icc_sync_state" from the patchset >since it's part of gregkh/char-misc.git > * Add acks > > v3: (thanks Krysztof and Georgi) > * drop the defconfig cycling patch and fix the interconnect enable config > * add the noc node to imx8mq only > * add missing signed-off-by > * > https://lore.kernel.org/linux-arm-kernel/20201210100906.18205-1-martin.kepplin...@puri.sm/T/#t > > v2: (thanks Lucas) > * reorder and clean up defconfig changes > * use "dram" for the interconnect path name and document it > * > https://lore.kernel.org/linux-arm-kernel/20201201123932.12312-1-martin.kepplin...@puri.sm/T/#t > > v1: > * > https://lore.kernel.org/linux-arm-kernel/20201201100124.4676-1-martin.kepplin...@puri.sm/T/#t > > thanks, > martin > > > Leonard Crestez (1): > arm64: dts: imx8mq: Add NOC node > > Martin Kepplinger (4): > arm64: dts: imx8mq: Add interconnect provider property > dt-bindings: mxsfb: Add interconnect bindings for LCDIF path > arm64: dts: imx8mq: Add interconnect for lcdif > arm64: defconfig: Enable interconnect for imx8mq I only received 3 patches, 1/5, 4/5 and 5/5. Shawn
Re: [PATCH 3/5] Input: omap4-keypad - move rest of key scanning to a separate function
On Sun, Jan 10, 2021 at 09:05:27PM +0200, Tony Lindgren wrote:
> Let's move rest of the key scanning code to omap4_keypad_scan_keys().
> We will use omap4_keypad_scan_keys() also for implementing errata
> handling to clear the stuck last key in the following patch.
And this one will become then...
--
Dmitry
Input: omap4-keypad - move rest of key scanning to a separate function
From: Tony Lindgren
Let's move rest of the key scanning code to omap4_keypad_scan_keys().
We will use omap4_keypad_scan_keys() also for implementing errata
handling to clear the stuck last key in the following patch.
Signed-off-by: Tony Lindgren
Signed-off-by: Dmitry Torokhov
---
drivers/input/keyboard/omap4-keypad.c | 39 ++---
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index 6dcf27af856d..c48705dd049b 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -71,6 +71,7 @@ struct omap4_keypad {
void __iomem *base;
unsigned int irq;
+ struct mutex lock; /* for key scan */
unsigned int rows;
unsigned int cols;
@@ -135,6 +136,28 @@ static int omap4_keypad_report_keys(struct omap4_keypad
*keypad_data,
return events;
}
+static void omap4_keypad_scan_keys(struct omap4_keypad *keypad_data, u64 keys)
+{
+ u64 changed;
+
+ mutex_lock(_data->lock);
+
+ changed = keys ^ keypad_data->keys;
+
+ /*
+* Report key up events separately and first. This matters in case we
+* lost key-up interrupt and just now catching up.
+*/
+ omap4_keypad_report_keys(keypad_data, changed & ~keys, false);
+
+ /* Report key down events */
+ omap4_keypad_report_keys(keypad_data, changed & keys, true);
+
+ keypad_data->keys = keys;
+
+ mutex_unlock(_data->lock);
+}
+
/* Interrupt handlers */
static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
{
@@ -150,24 +173,13 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq,
void *dev_id)
{
struct omap4_keypad *keypad_data = dev_id;
u32 low, high;
- u64 keys, changed;
+ u64 keys;
low = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
high = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
keys = low | (u64)high << 32;
- changed = keys ^ keypad_data->keys;
-
- /*
-* Report key up events separately and first. This matters in case we
-* lost key-up interrupt and just now catching up.
-*/
- omap4_keypad_report_keys(keypad_data, changed & ~keys, false);
-
- /* Report key down events */
- omap4_keypad_report_keys(keypad_data, changed & keys, true);
-
- keypad_data->keys = keys;
+ omap4_keypad_scan_keys(keypad_data, keys);
/* clear pending interrupts */
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
@@ -300,6 +312,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
}
keypad_data->irq = irq;
+ mutex_init(_data->lock);
error = omap4_keypad_parse_dt(dev, keypad_data);
if (error)
Re: [PATCH 2/5] Input: omap4-keypad - scan keys in two phases and simplify with bitmask
Hi Tony,
On Sun, Jan 10, 2021 at 09:05:26PM +0200, Tony Lindgren wrote:
> Because of errata i689 the keyboard can idle with state where no key
> up interrupts are seen until after the next key press.
>
> This means we need to first check for any lost key up events before
> scanning for new down events.
>
> For example, rapidly pressing shift-shift-j can sometimes produce a J
> instead of j. Let's fix the issue by scanning the keyboard in two
> phases. First we scan for any key up events that we may have missed,
> and then we scan for key down events.
>
> Let's also simplify things with for_each_set_bit() as suggested by
> Dmitry Torokhov .
>
> Cc: Arthur Demchenkov
> Cc: Carl Philipp Klemm
> Cc: Merlijn Wajer
> Cc: Pavel Machek
> Cc: ruleh
> Cc: Sebastian Reichel
> Signed-off-by: Tony Lindgren
> ---
> drivers/input/keyboard/omap4-keypad.c | 69 ++-
> 1 file changed, 46 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/input/keyboard/omap4-keypad.c
> b/drivers/input/keyboard/omap4-keypad.c
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -78,7 +78,7 @@ struct omap4_keypad {
> u32 irqreg_offset;
> unsigned int row_shift;
> bool no_autorepeat;
> - unsigned char key_state[8];
> + u64 keys;
> unsigned short *keymap;
> };
>
> @@ -107,6 +107,41 @@ static void kbd_write_irqreg(struct omap4_keypad
> *keypad_data,
>keypad_data->base + keypad_data->irqreg_offset + offset);
> }
>
> +static int omap4_keypad_scan_state(struct omap4_keypad *keypad_data, u64
> keys,
> +bool down)
> +{
> + struct input_dev *input_dev = keypad_data->input;
> + unsigned int col, row, code;
> + DECLARE_BITMAP(mask, 64);
> + unsigned long bit;
> + int events = 0;
> + bool key_down;
> + u64 changed;
> +
> + changed = keys ^ keypad_data->keys;
> + bitmap_from_u64(mask, changed);
> +
> + for_each_set_bit(bit, mask, keypad_data->rows * BITS_PER_BYTE) {
> + row = bit / BITS_PER_BYTE;
> + col = bit % BITS_PER_BYTE;
> + code = MATRIX_SCAN_CODE(row, col, keypad_data->row_shift);
> +
> + if (BIT_ULL(bit) & keys)
> + key_down = true;
> + else
> + key_down = false;
> +
> + if (key_down != down)
> + continue;
> +
> + input_event(input_dev, EV_MSC, MSC_SCAN, code);
> + input_report_key(input_dev, keypad_data->keymap[code],
> + key_down);
> + events++;
> + }
> +
> + return events;
> +}
>
> /* Interrupt handlers */
> static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
> @@ -123,34 +158,22 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq,
> void *dev_id)
> {
> struct omap4_keypad *keypad_data = dev_id;
> struct input_dev *input_dev = keypad_data->input;
> - unsigned char key_state[ARRAY_SIZE(keypad_data->key_state)];
> - unsigned int col, row, code, changed;
> - u32 *new_state = (u32 *) key_state;
> + u32 low, high;
> + u64 keys;
>
> - *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> - *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
> + low = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> + high = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
> + keys = low | (u64)high << 32;
>
> - for (row = 0; row < keypad_data->rows; row++) {
> - changed = key_state[row] ^ keypad_data->key_state[row];
> - if (!changed)
> - continue;
> + /* Scan for key up events for lost key-up interrupts */
> + omap4_keypad_scan_state(keypad_data, keys, false);
>
> - for (col = 0; col < keypad_data->cols; col++) {
> - if (changed & (1 << col)) {
> - code = MATRIX_SCAN_CODE(row, col,
> - keypad_data->row_shift);
> - input_event(input_dev, EV_MSC, MSC_SCAN, code);
> - input_report_key(input_dev,
> - keypad_data->keymap[code],
> - key_state[row] & (1 << col));
> - }
> - }
> - }
> + /* Scan for key down events */
> + omap4_keypad_scan_state(keypad_data, keys, true);
>
> input_sync(input_dev);
Technically speaking, userspace is free to accumulate the events until
it receives EV_SYN/SYN_REPORT event and process the events in the event
packet in order it sees fit. So to achieve what you want, I think we
should issue 2 input_sync()s, one for the release block, and another is
for press. I think we can also simplify the code if we pass into the new
scan function exact set of keys that are being
Re: [PATCH] ASoC: audio-graph-card: Drop remote-endpoint as required property
Hi Rob, On 12/10/2020 8:14 PM, Sameer Pujar wrote: Hi Rob, The remote-endpoint may not be available if it is part of some pluggable module. One such example would be an audio card, the Codec endpoint will not be available until it is plugged in. Hence drop 'remote-endpoint' as a required property. Please hold off on this. I have more changes coming. Sorry to bother you again. Is it possible if we take this patch now and your remaining changes can come later? This would help to unblock below series, which is pending quite some time now. OK, I will wait for your patch. Kindly note that this is currently blocking series https://patchwork.kernel.org/project/alsa-devel/list/?series=391735=*
Re: [PATCH V4 0/3] arm64: topology: improvements
On 08-01-21, 15:53, Ionela Voinescu wrote: > On Friday 08 Jan 2021 at 16:46:50 (+0530), Viresh Kumar wrote: > > Hi, > > > > Here is the V4 with the general improvements for topology stuff. This > > cleans up the code and makes it work with cpufreq modules. > > > > V4: > > - Added Rby from Ionela. > > - In 3/3, Print cpus instead of amu_fie_cpus and make it pr_debug > > instead. > > > > Viresh Kumar (3): > > arm64: topology: Avoid the have_policy check > > arm64: topology: Reorder init_amu_fie() a bit > > arm64: topology: Make AMUs work with modular cpufreq drivers > > > > arch/arm64/kernel/topology.c | 115 +-- > > 1 file changed, 56 insertions(+), 59 deletions(-) > > > > Tested-by: Ionela Voinescu > > ..for the full set. Thanks, Ionela. -- viresh
linux-next: Tree for Jan 11
Hi all,
Changes since 20210108:
The btrfs tree gained a conflict against the btrfs-fixes tree.
The drm tree still had its build failure so I used the version from
next-20210107.
The amdgpu tree lost its build failure.
The drm-intel tree gained a build failure from merging the drm tree,
so I have used the version from next-20210108.
The drm-misc tree still had its build failure from merging the drm tree,
so I have used the version from next-20210107.
The char-misc tree gained a conflict against the drivers-x86 tree.
Non-merge commits (relative to Linus' tree): 1931
2062 files changed, 84028 insertions(+), 30807 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 330 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (0653161f0fac Merge tag 'arc-5.11-rc3-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (5625dcfbbcf8 Documentation: kbuild: Fix section
reference)
Merging arc-current/for-curr (e8deee4f1543 ARC: [hsdk]: Enable FPU_SAVE_RESTORE)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (83b5bd628f65 arm64: Move PSTATE.TCO setting
to separate functions)
Merging arm-soc-fixes/arm/fixes (bac717171971 ARM: picoxcell: fix missing
interrupt-parent properties)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (3ce47d95b734 powerpc: Handle
.text.{hot,unlikely}.* in linker script)
Merging s390-fixes/fixes (129975e75b9a s390/Kconfig: sort config S390 select
list once again)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (f97844f9c518 dt-bindings: net: renesas,etheravb: RZ/G2H
needs tx-internal-delay-ps)
Merging bpf/master (286e95eed12e Merge branch 's390-qeth-fixes-2021-01-07')
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in
xfrm_policy_addr_delta())
Merging netfilter/master (c49243e88982 Merge branch
'net-fix-issues-around-register_netdevice-failures')
Merging ipvs/master (a8f33c038f4e Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging wireless-drivers/master (bfe55584713b MAINTAINERS: switch to different
email address)
Merging mac80211/master (51d62f2f2c50 cfg80211: Save the regulatory domain with
a lock)
Merging rdma-fixes/for-rc (f2bc3af6353c RDMA/ocrdma: Fix use after free in
ocrdma_dealloc_ucontext_pd())
Merging sound-current/for-linus (167c9dc84ec3 ALSA: usb-audio: Fix implicit
feedback sync setup for Pioneer devices)
Merging sound-asoc-fixes/for-linus (ed37719f60ff Merge remote-tracking branch
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (72962ebcdd45 Merge remote-tracking branch
'regmap/for-5.11' into regmap-linus)
Merging regulator-fixes/for-linus (cd66a1589b7c Merge remote-tracking branch
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (d7d09a547aac Merge remote-tracking branch
'spi/for-5.11' into spi-linus)
[PATCH] scsi: ufs: should not override buffer lengh
From: Jaegeuk Kim
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, _buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel
stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2a715f13fe1d..722697b5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3293,8 +3293,12 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
- if (param_offset + param_size > buff_len)
- param_size = buff_len - param_offset;
+ if (param_offset + param_size > buff_len) {
+ if (buff_len > param_offset)
+ param_size = buff_len - param_offset;
+ else
+ param_size = 0;
+ }
memcpy(param_read_buf, _buf[param_offset], param_size);
}
out:
--
2.30.0.284.gd98b1dd5eaa7-goog
5.11-rc device reordering breaks ThinkPad rmi4 suspend
Hi Rafael,
Synaptics RMI4 SMBus touchpad on ThinkPad X1 Carbon (5th generation)
fails to suspend when running 5.11-rc kernels: bisected to
5b6164d3465f ("driver core: Reorder devices on successful probe"),
and reverting that fixes it. dmesg.xz attached, but go ahead and ask
me to switch on a debug option to extract further info if that may help.
Thanks,
Hugh
dmesg.xz
Description: application/xz
Re: [PATCH 4/6] hugetlb: avoid allocation failed when page reporting is on going
> > > Please don't use this email address for me anymore. Either use
> > > alexander.du...@gmail.com or alexanderdu...@fb.com. I am getting
> > > bounces when I reply to this thread because of the old address.
> >
> > No problem.
> >
> > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > index eb533995cb49..0fccd5f96954 100644
> > > > --- a/mm/hugetlb.c
> > > > +++ b/mm/hugetlb.c
> > > > @@ -2320,6 +2320,12 @@ struct page *alloc_huge_page(struct
> > > > vm_area_struct *vma,
> > > > goto out_uncharge_cgroup_reservation;
> > > >
> > > > spin_lock(_lock);
> > > > + while (h->free_huge_pages <= 1 && h->isolated_huge_pages) {
> > > > + spin_unlock(_lock);
> > > > + mutex_lock(>mtx_prezero);
> > > > + mutex_unlock(>mtx_prezero);
> > > > + spin_lock(_lock);
> > > > + }
> > >
> > > This seems like a bad idea. It kind of defeats the whole point of
> > > doing the page zeroing outside of the hugetlb_lock. Also it is
> > > operating on the assumption that the only way you might get a page is
> > > from the page zeroing logic.
> > >
> > > With the page reporting code we wouldn't drop the count to zero. We
> > > had checks that were going through and monitoring the watermarks and
> > > if we started to hit the low watermark we would stop page reporting
> > > and just assume there aren't enough pages to report. You might need to
> > > look at doing something similar here so that you can avoid colliding
> > > with the allocator.
> >
> > For hugetlb, things are a little different, Just like Mike points out:
> > "On some systems, hugetlb pages are a precious resource and
> > the sysadmin carefully configures the number needed by
> > applications. Removing a hugetlb page (even for a very short
> > period of time) could cause serious application failure."
> >
> > Just keeping some pages in the freelist is not enough to prevent that from
> > happening, because these pages may be allocated while zero out is on
> > going, and application may still run into a situation for not available free
> > pages.
>
> I get what you are saying. However I don't know if it is acceptable
> for the allocating thread to be put to sleep in this situation. There
> are two scenarios where I can see this being problematic.
>
> One is a setup where you put the page allocator to sleep and while it
> is sleeping another thread is then freeing a page and your thread
> cannot respond to that newly freed page and is stuck waiting on the
> zeroed page.
>
> The second issue is that users may want a different option of just
> breaking up the request into smaller pages rather than waiting on the
> page zeroing, or to do something else while waiting on the page. So
> instead of sitting on the request and waiting it might make more sense
> to return an error pointer like EAGAIN or EBUSY to indicate that there
> is a page there, but it is momentarily tied up.
It seems returning EAGAIN or EBUSY will still change the application's
behavior, I am not sure if it's acceptable.
Thanks
Liang
[PATCH] usb/c67x00: Replace tasklet with work
Tasklets have long been deprecated as being too heavy on the system
by running in irq context - and this is not a performance critical
path. If a higher priority process wants to run, it must wait for
the tasklet to finish before doing so.
c67x00_do_work() will now run in process context and have further
concurrency (tasklets being serialized among themselves), but this
is done holding the c67x00->lock, so it should be fine. Furthermore,
this patch fixes the usage of the lock in the callback as otherwise
it would need to be irq-safe.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/c67x00/c67x00-hcd.h | 2 +-
drivers/usb/c67x00/c67x00-sched.c | 12 +++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-hcd.h b/drivers/usb/c67x00/c67x00-hcd.h
index 6b6b04a3fe0f..6332a6b5dce6 100644
--- a/drivers/usb/c67x00/c67x00-hcd.h
+++ b/drivers/usb/c67x00/c67x00-hcd.h
@@ -76,7 +76,7 @@ struct c67x00_hcd {
u16 next_td_addr;
u16 next_buf_addr;
- struct tasklet_struct tasklet;
+ struct work_struct work;
struct completion endpoint_disable;
diff --git a/drivers/usb/c67x00/c67x00-sched.c
b/drivers/usb/c67x00/c67x00-sched.c
index e65f1a0ae80b..af60f4fdd340 100644
--- a/drivers/usb/c67x00/c67x00-sched.c
+++ b/drivers/usb/c67x00/c67x00-sched.c
@@ -1123,24 +1123,26 @@ static void c67x00_do_work(struct c67x00_hcd *c67x00)
/* --
*/
-static void c67x00_sched_tasklet(struct tasklet_struct *t)
+static void c67x00_sched_work(struct work_struct *work)
{
- struct c67x00_hcd *c67x00 = from_tasklet(c67x00, t, tasklet);
+ struct c67x00_hcd *c67x00;
+
+ c67x00 = container_of(work, struct c67x00_hcd, work);
c67x00_do_work(c67x00);
}
void c67x00_sched_kick(struct c67x00_hcd *c67x00)
{
- tasklet_hi_schedule(>tasklet);
+queue_work(system_highpri_wq, >work);
}
int c67x00_sched_start_scheduler(struct c67x00_hcd *c67x00)
{
- tasklet_setup(>tasklet, c67x00_sched_tasklet);
+INIT_WORK(>work, c67x00_sched_work);
return 0;
}
void c67x00_sched_stop_scheduler(struct c67x00_hcd *c67x00)
{
- tasklet_kill(>tasklet);
+cancel_work_sync(>work);
}
--
2.26.2
Re: [PATCH] iommu/io-pgtable-arm: Allow non-coherent masters to use system cache
On 2021-01-08 23:39, isa...@codeaurora.org wrote:
On 2021-01-07 21:47, Sai Prakash Ranjan wrote:
On 2021-01-07 22:27, isa...@codeaurora.org wrote:
On 2021-01-06 03:56, Will Deacon wrote:
On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY
flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it
went
the memory type setting required for the non-coherent masters to
use
system cache. Now that system cache support for GPU is added, we
will
need to mark the memory as normal sys-cached for GPU to use system
cache.
Without this, the system cache lines are not allocated for GPU. We
use
the IO_PGTABLE_QUIRK_ARM_OUTER_WBWA quirk instead of a page
protection
flag as the flag cannot be exposed via DMA api because of no
in-tree
users.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/io-pgtable-arm.c
b/drivers/iommu/io-pgtable-arm.c
index 7c9ea9d7874a..3fb7de8304a2 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -415,6 +415,9 @@ static arm_lpae_iopte
arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
+ else if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE
+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
}
While this approach of enabling system cache globally for both page
tables and other buffers
works for the GPU usecase, this isn't ideal for other clients that
use
system cache. For example,
video clients only want to cache a subset of their buffers in the
system cache, due to the sizing constraint
imposed by how much of the system cache they can use. So, it would be
ideal to have
a way of expressing the desire to use the system cache on a
per-buffer
basis. Additionally,
our video clients use the DMA layer, and since the requirement is for
caching in the system cache
to be a per buffer attribute, it seems like we would have to have a
DMA attribute to express
this on a per-buffer basis.
I did bring this up initially [1], also where is this video client
in upstream? AFAIK, only system cache user in upstream is GPU.
We cannot add any DMA attribute unless there is any user upstream
Right, there wouldn't be an upstream user, which would be problematic,
but I was thinking of having it so that when video or any of our other
clients that use this attribute on a per buffer basis upstreams their
code, it's not too much of a stretch to add the support.
Agreed.
as per [2], so when the support for such a client is added, wouldn't
((data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA) ||
PROT_FLAG)
work?
I don't think that will work, because we currently have clients who use
the
system cache as follows:
-cache only page tables in the system cache
-cache only data buffers in the system cache
-cache both page tables and all buffers in the system cache
-cache both page tables and some buffers in the system cache
The approach you're suggesting doesn't allow for the last case, as
caching the
page tables in the system cache involves setting
IO_PGTABLE_QUIRK_ARM_OUTER_WBWA,
so we will end up losing the flexibility to cache some data buffers in
the system cache.
Ah yes, you are right, I believe Jordan mentioned the same [1].
[1]
https://lore.kernel.org/lkml/20200709161352.gc21...@jcrouse1-lnx.qualcomm.com/
Ideally, the page table quirk would drive the settings for the TCR,
and the prot flag
drives the PTE for the mapping, as is done with the page table walker
being dma-coherent,
while buffers are mapped as cacheable based on IOMMU_CACHE. Thoughts?
Right, mixing the two is not correct. Will's suggestion for a new prot
flag sounds good to me, I will work on that.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
